User Details
- User Since
- Nov 7 2017, 12:52 AM (281 w, 4 d)
Mon, Mar 27
I'm not a reviewer, but I can confirm the patch fixes the issue as it was filed.
Wed, Mar 22
Thu, Mar 9
Wed, Mar 8
The crash comes from D143225.
This is causing crashes when building Skia. See https://reviews.llvm.org/D141188#4179444
The crash is actually happening without the patch too. It happens both in Firefox and Chrome because both are using Skia, and the source that triggers the crash is in Skia.
Thu, Mar 2
FYI this patch also caused some of Firefox's unit tests to fail, e.g. https://treeherder.mozilla.org/logviewer?job_id=407511605&repo=toolchains&lineNumber=32470
Jan 31 2023
Could you add before/after figures of the numbers of symbols in, say, clang.symbols in the summary?
Jan 25 2023
Updated per feedback.
Jan 24 2023
Switched to skipping X86GenMnemonicTables functions instead of private methods.
Jan 23 2023
Jan 19 2023
with -DLLVM_LINK_LLVM_DYLIB=ON, in case it matters.
I'm still seeing the build error on clangd-fuzzer on a commit that clearly has e84d69f52d9a9fab9162128d8fe8ebec99ea60da in its history.
Oh yes, we're using -DLLVM_LINK_LLVM_DYLIB=ON too, so that would be the main trigger.
Jan 18 2023
This broke our mac builds with errors like:
ld64.lld: error: undefined symbol: CFRunLoopRun >>> referenced by tools/clang/tools/clang-stat-cache/CMakeFiles/clang-stat-cache.dir/clang-stat-cache.cpp.o:(symbol main+0x11be)
(and many more symbols)
Dec 28 2022
@epastor could you land this for me?
Dec 26 2022
Dec 22 2022
FWIW, I'm seeing targetAtom != NULL assertions in function Fixup in ld.hpp in ld64 when build Firefox with LTO since this change (I can only guess the crashes mentioned in the revert are the same?).
Dec 8 2022
I can reproduce with this:
cmake -G Ninja -S llvm -B stage1 -DLLVM_LINK_LLVM_DYLIB=ON -DLLVM_ENABLE_PROJECTS=clang -DCMAKE_BUILD_TYPE=Release ninja -C stage1 cmake -G Ninja -S llvm -B stage2 -DLLVM_LINK_LLVM_DYLIB=ON -DLLVM_ENABLE_PROJECTS=clang -DCMAKE_BUILD_TYPE=Release -DCMAKE_C_COMPILER=$PWD/stage1/bin/clang -DLLVM_BUILD_INSTRUMENTED=IR -DCMAKE_SHARED_LINKER_FLAGS="-fuse-ld=gold" ninja -C stage2
The key is to be using GNU gold.
ld.lld: error: version script assignment of 'LLVM_16' to symbol 'LLVMCreateDisasm' failed: symbol not defined ld.lld: error: version script assignment of 'LLVM_16' to symbol 'LLVMCreateDisasmCPU' failed: symbol not defined ld.lld: error: version script assignment of 'LLVM_16' to symbol 'LLVMDisasmDispose' failed: symbol not defined ld.lld: error: version script assignment of 'LLVM_16' to symbol 'LLVMDisasmInstruction' failed: symbol not defined ld.lld: error: version script assignment of 'LLVM_16' to symbol 'LLVMSetDisasmOptions' failed: symbol not defined ld.lld: error: version script assignment of 'LLVM_16' to symbol 'LLVMCreateDisasmCPUFeatures' failed: symbol not defined
This is happening reliably when linking libLTO in a build with LLVM_LINK_LLVM_DYLIB=ON and LLVM_ENABLE_LLD=ON because in that case these symbols are in libLLVM instead of libLTO.
The errors from the comment https://reviews.llvm.org/D137982#3929427 are back after the relanding.
Nov 29 2022
I can't dig into this at the moment, but I opened an issue with a reproducer (https://github.com/llvm/llvm-project/issues/59259)
Nov 22 2022
Almost there, but not quite:
[task 2022-11-22T23:55:36.341Z] /builds/worker/fetches/llvm-project/llvm/tools/gold/gold-plugin.cpp:1106:6: error: no matching function for call to object of type '(lambda at /builds/worker/fetches/llvm-project/llvm/tools/gold/gold-plugin.cpp:1095:7)' [task 2022-11-22T23:55:36.341Z] *AddStream(Task)->OS << MB->getBuffer(); [task 2022-11-22T23:55:36.341Z] ^~~~~~~~~ [task 2022-11-22T23:55:36.341Z] /builds/worker/fetches/llvm-project/llvm/tools/gold/gold-plugin.cpp:1095:7: note: candidate function not viable: requires 2 arguments, but 1 was provided [task 2022-11-22T23:55:36.341Z] [&](size_t Task, [task 2022-11-22T23:55:36.341Z] ^ [task 2022-11-22T23:55:36.341Z] 1 error generated.
Still broken:
task 2022-11-22T22:09:00.912Z] /usr/lib/llvm-11/bin/clang++ --sysroot=/builds/worker/fetches/sysroot -DGTEST_HAS_RTTI=0 -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Itools/gold -I/builds/worker/fetches/llvm-project/llvm/tools/gold -Iinclude -I/builds/worker/fetches/llvm-project/llvm/include -fPIC -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wc++98-compat-extra-semi -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wsuggest-override -Wstring-conversion -Wmisleading-indentation -Wctad-maybe-unsupported -fdiagnostics-color -ffunction-sections -fdata-sections -O3 -DNDEBUG -fPIC -fno-exceptions -fno-rtti -std=c++17 -MD -MT tools/gold/CMakeFiles/LLVMgold.dir/gold-plugin.cpp.o -MF tools/gold/CMakeFiles/LLVMgold.dir/gold-plugin.cpp.o.d -o tools/gold/CMakeFiles/LLVMgold.dir/gold-plugin.cpp.o -c /builds/worker/fetches/llvm-project/llvm/tools/gold/gold-plugin.cpp [task 2022-11-22T22:09:00.912Z] /builds/worker/fetches/llvm-project/llvm/tools/gold/gold-plugin.cpp:1111:18: error: no viable conversion from '(lambda at /builds/worker/fetches/llvm-project/llvm/tools/gold/gold-plugin.cpp:1094:20)' to 'llvm::AddStreamFn' (aka 'function<Expected<std::unique_ptr<CachedFileStream>> (unsigned int, const llvm::Twine &)>') [task 2022-11-22T22:09:00.912Z] check(Lto->run(AddStream, Cache)); [task 2022-11-22T22:09:00.912Z] ^~~~~~~~~ [task 2022-11-22T22:09:00.912Z] /builds/worker/fetches/sysroot/usr/lib/gcc/x86_64-linux-gnu/7.5.0/../../../../include/c++/7.5.0/bits/std_function.h:421:7: note: candidate constructor not viable: no known conversion from '(lambda at /builds/worker/fetches/llvm-project/llvm/tools/gold/gold-plugin.cpp:1094:20)' to 'std::nullptr_t' (aka 'nullptr_t') for 1st argument [task 2022-11-22T22:09:00.912Z] function(nullptr_t) noexcept [task 2022-11-22T22:09:00.912Z] ^ [task 2022-11-22T22:09:00.912Z] /builds/worker/fetches/sysroot/usr/lib/gcc/x86_64-linux-gnu/7.5.0/../../../../include/c++/7.5.0/bits/std_function.h:432:7: note: candidate constructor not viable: no known conversion from '(lambda at /builds/worker/fetches/llvm-project/llvm/tools/gold/gold-plugin.cpp:1094:20)' to 'const std::function<llvm::Expected<std::unique_ptr<llvm::CachedFileStream, std::default_delete<llvm::CachedFileStream>>> (unsigned int, const llvm::Twine &)> &' for 1st argument [task 2022-11-22T22:09:00.912Z] function(const function& __x); [task 2022-11-22T22:09:00.912Z] ^ [task 2022-11-22T22:09:00.912Z] /builds/worker/fetches/sysroot/usr/lib/gcc/x86_64-linux-gnu/7.5.0/../../../../include/c++/7.5.0/bits/std_function.h:441:7: note: candidate constructor not viable: no known conversion from '(lambda at /builds/worker/fetches/llvm-project/llvm/tools/gold/gold-plugin.cpp:1094:20)' to 'std::function<llvm::Expected<std::unique_ptr<llvm::CachedFileStream, std::default_delete<llvm::CachedFileStream>>> (unsigned int, const llvm::Twine &)> &&' for 1st argument [task 2022-11-22T22:09:00.912Z] function(function&& __x) noexcept : _Function_base() [task 2022-11-22T22:09:00.913Z] ^ [task 2022-11-22T22:09:00.913Z] /builds/worker/fetches/sysroot/usr/lib/gcc/x86_64-linux-gnu/7.5.0/../../../../include/c++/7.5.0/bits/std_function.h:465:2: note: candidate template ignored: substitution failure [with _Functor = (lambda at /builds/worker/fetches/llvm-project/llvm/tools/gold/gold-plugin.cpp:1094:20), $1 = void]: no type named 'type' in 'std::result_of<(lambda at /builds/worker/fetches/llvm-project/llvm/tools/gold/gold-plugin.cpp:1094:20) &(unsigned int, const llvm::Twine &)>' [task 2022-11-22T22:09:00.913Z] function(_Functor); [task 2022-11-22T22:09:00.913Z] ^ [task 2022-11-22T22:09:00.913Z] /builds/worker/fetches/llvm-project/llvm/include/llvm/LTO/LTO.h:278:25: note: passing argument to parameter 'AddStream' here [task 2022-11-22T22:09:00.913Z] Error run(AddStreamFn AddStream, FileCache Cache = nullptr); [task 2022-11-22T22:09:00.913Z] ^ [task 2022-11-22T22:09:00.913Z] 1 error generated.
This broke the gold plugin:
[task 2022-11-22T21:03:29.486Z] /builds/worker/fetches/llvm-project/llvm/tools/gold/gold-plugin.cpp:1108:19: error: no matching function for call to 'localCache' [task 2022-11-22T21:03:29.486Z] Cache = check(localCache("ThinLTO", "Thin", options::cache_dir, AddBuffer)); [task 2022-11-22T21:03:29.487Z] ^~~~~~~~~~ [task 2022-11-22T21:03:29.487Z] /builds/worker/fetches/llvm-project/llvm/include/llvm/Support/Caching.h:72:21: note: candidate function not viable: no known conversion from '(lambda at /builds/worker/fetches/llvm-project/llvm/tools/gold/gold-plugin.cpp:1102:20)' to 'llvm::AddBufferFn' (aka 'function<void (unsigned int, const llvm::Twine &, std::unique_ptr<MemoryBuffer>)>') for 4th argument [task 2022-11-22T21:03:29.487Z] Expected<FileCache> localCache( [task 2022-11-22T21:03:29.488Z] ^ [task 2022-11-22T21:03:29.488Z] /builds/worker/fetches/llvm-project/llvm/tools/gold/gold-plugin.cpp:1110:18: error: no viable conversion from '(lambda at /builds/worker/fetches/llvm-project/llvm/tools/gold/gold-plugin.cpp:1094:20)' to 'llvm::AddStreamFn' (aka 'function<Expected<std::unique_ptr<CachedFileStream>> (unsigned int, const llvm::Twine &)>') [task 2022-11-22T21:03:29.488Z] check(Lto->run(AddStream, Cache)); [task 2022-11-22T21:03:29.488Z] ^~~~~~~~~ [task 2022-11-22T21:03:29.488Z] /builds/worker/fetches/sysroot/usr/lib/gcc/x86_64-linux-gnu/7.5.0/../../../../include/c++/7.5.0/bits/std_function.h:421:7: note: candidate constructor not viable: no known conversion from '(lambda at /builds/worker/fetches/llvm-project/llvm/tools/gold/gold-plugin.cpp:1094:20)' to 'std::nullptr_t' (aka 'nullptr_t') for 1st argument [task 2022-11-22T21:03:29.488Z] function(nullptr_t) noexcept [task 2022-11-22T21:03:29.488Z] ^ [task 2022-11-22T21:03:29.489Z] /builds/worker/fetches/sysroot/usr/lib/gcc/x86_64-linux-gnu/7.5.0/../../../../include/c++/7.5.0/bits/std_function.h:432:7: note: candidate constructor not viable: no known conversion from '(lambda at /builds/worker/fetches/llvm-project/llvm/tools/gold/gold-plugin.cpp:1094:20)' to 'const std::function<llvm::Expected<std::unique_ptr<llvm::CachedFileStream, std::default_delete<llvm::CachedFileStream>>> (unsigned int, const llvm::Twine &)> &' for 1st argument [task 2022-11-22T21:03:29.489Z] function(const function& __x); [task 2022-11-22T21:03:29.489Z] ^ [task 2022-11-22T21:03:29.489Z] /builds/worker/fetches/sysroot/usr/lib/gcc/x86_64-linux-gnu/7.5.0/../../../../include/c++/7.5.0/bits/std_function.h:441:7: note: candidate constructor not viable: no known conversion from '(lambda at /builds/worker/fetches/llvm-project/llvm/tools/gold/gold-plugin.cpp:1094:20)' to 'std::function<llvm::Expected<std::unique_ptr<llvm::CachedFileStream, std::default_delete<llvm::CachedFileStream>>> (unsigned int, const llvm::Twine &)> &&' for 1st argument [task 2022-11-22T21:03:29.489Z] function(function&& __x) noexcept : _Function_base() [task 2022-11-22T21:03:29.489Z] ^ [task 2022-11-22T21:03:29.489Z] /builds/worker/fetches/sysroot/usr/lib/gcc/x86_64-linux-gnu/7.5.0/../../../../include/c++/7.5.0/bits/std_function.h:465:2: note: candidate template ignored: substitution failure [with _Functor = (lambda at /builds/worker/fetches/llvm-project/llvm/tools/gold/gold-plugin.cpp:1094:20), $1 = void]: no type named 'type' in 'std::result_of<(lambda at /builds/worker/fetches/llvm-project/llvm/tools/gold/gold-plugin.cpp:1094:20) &(unsigned int, const llvm::Twine &)>' [task 2022-11-22T21:03:29.489Z] function(_Functor); [task 2022-11-22T21:03:29.489Z] ^ [task 2022-11-22T21:03:29.489Z] /builds/worker/fetches/llvm-project/llvm/include/llvm/LTO/LTO.h:278:25: note: passing argument to parameter 'AddStream' here [task 2022-11-22T21:03:29.489Z] Error run(AddStreamFn AddStream, FileCache Cache = nullptr); [task 2022-11-22T21:03:29.489Z] ^ [task 2022-11-22T21:03:29.489Z] 2 errors generated.
Nov 21 2022
(using a sysroot that contains glibc 2.19)
Also getting errors when building compiler-rt standalone:
[task 2022-11-21T21:07:28.272Z] In file included from /builds/worker/fetches/llvm-project/libcxx/src/mutex.cpp:11: [task 2022-11-21T21:07:28.272Z] In file included from include/c++/v1/mutex:192: [task 2022-11-21T21:07:28.272Z] In file included from include/c++/v1/__mutex_base:20: [task 2022-11-21T21:07:28.272Z] In file included from include/c++/v1/system_error:154: [task 2022-11-21T21:07:28.272Z] In file included from include/c++/v1/string:561: [task 2022-11-21T21:07:28.272Z] In file included from include/c++/v1/__string/char_traits.h:24: [task 2022-11-21T21:07:28.272Z] include/c++/v1/cstdio:160:9: error: target of using declaration conflicts with declaration already in scope [task 2022-11-21T21:07:28.272Z] using ::remove _LIBCPP_USING_IF_EXISTS; [task 2022-11-21T21:07:28.272Z] ^ [task 2022-11-21T21:07:28.272Z] include/c++/v1/cstdio:160:1: note: target of using declaration [task 2022-11-21T21:07:28.272Z] using ::remove _LIBCPP_USING_IF_EXISTS; [task 2022-11-21T21:07:28.272Z] ^ [task 2022-11-21T21:07:28.272Z] include/c++/v1/__algorithm/remove.h:25:1: note: conflicting declaration [task 2022-11-21T21:07:28.272Z] remove(_ForwardIterator __first, _ForwardIterator __last, const _Tp& __value) [task 2022-11-21T21:07:28.272Z] ^ [task 2022-11-21T21:07:28.272Z] In file included from /builds/worker/fetches/llvm-project/libcxx/src/mutex.cpp:11: [task 2022-11-21T21:07:28.272Z] In file included from include/c++/v1/mutex:192: [task 2022-11-21T21:07:28.272Z] In file included from include/c++/v1/__mutex_base:20: [task 2022-11-21T21:07:28.272Z] In file included from include/c++/v1/system_error:154: [task 2022-11-21T21:07:28.272Z] In file included from include/c++/v1/string:561: [task 2022-11-21T21:07:28.272Z] include/c++/v1/__string/char_traits.h:81:26: error: use of undeclared identifier 'EOF' [task 2022-11-21T21:07:28.272Z] {return int_type(EOF);} [task 2022-11-21T21:07:28.272Z] ^ [task 2022-11-21T21:07:28.272Z] include/c++/v1/__string/char_traits.h:80:47: error: no return statement in constexpr function [task 2022-11-21T21:07:28.272Z] static inline _LIBCPP_CONSTEXPR int_type eof() _NOEXCEPT [task 2022-11-21T21:07:28.272Z] ^ [task 2022-11-21T21:07:28.272Z] include/c++/v1/__string/char_traits.h:257:26: error: use of undeclared identifier 'EOF' [task 2022-11-21T21:07:28.272Z] {return int_type(EOF);} [task 2022-11-21T21:07:28.272Z] ^ [task 2022-11-21T21:07:28.272Z] include/c++/v1/__string/char_traits.h:256:47: error: no return statement in constexpr function [task 2022-11-21T21:07:28.272Z] static inline _LIBCPP_CONSTEXPR int_type eof() _NOEXCEPT [task 2022-11-21T21:07:28.272Z] ^ [task 2022-11-21T21:07:28.272Z] include/c++/v1/__string/char_traits.h:482:26: error: use of undeclared identifier 'EOF' [task 2022-11-21T21:07:28.272Z] {return int_type(EOF);} [task 2022-11-21T21:07:28.272Z] ^ [task 2022-11-21T21:07:28.272Z] include/c++/v1/__string/char_traits.h:481:38: error: no return statement in constexpr function [task 2022-11-21T21:07:28.272Z] static inline constexpr int_type eof() noexcept [task 2022-11-21T21:07:28.272Z] ^ [task 2022-11-21T21:07:28.272Z] 7 errors generated. [task 2022-11-21T21:07:28.577Z] [880/906] Building CXX object libcxx/src/CMakeFiles/cxx_static.dir/random_shuffle.cpp.o
Nov 16 2022
Can you push this for me?
Nov 15 2022
FWIW, we've had this happen recently on non-optimized builds of Firefox with the 256 value (although it's not happening anymore as of writing, whatever made it disappear)... is there a point where increasing the slop is going to be a problem?
Try building clang with -DLLVM_BUILD_INSTRUMENTED=IR with a clang that contains your patch. If that's not enough, try adding -DLLVM_LINK_LLVM_DYLIB=ON. If that's not enough, I'll try to find the right set of flags from what we're using here.
This is broken with lld too:
ld.lld: error: relocation refers to a discarded section: .text._ZNK4llvm6object7ELFFileINS0_7ELFTypeILNS_7support10endiannessE1ELb0EEEE19getRelocationSymbolERKNS0_12Elf_Rel_ImplIS5_Lb0EEEPKNS0_13Elf_Shdr_ImplIS5_EE >>> defined in lib/libLLVMJITLink.a(ELF_i386.cpp.o) >>> section group signature: _ZNK4llvm6object7ELFFileINS0_7ELFTypeILNS_7support10endiannessE1ELb0EEEE19getRelocationSymbolERKNS0_12Elf_Rel_ImplIS5_Lb0EEEPKNS0_13Elf_Shdr_ImplIS5_EE >>> prevailing definition is in lib/libLLVMObject.a(ELF.cpp.o) >>> referenced by ELF_i386.cpp >>> ELF_i386.cpp.o:(__llvm_prf_data+0x18) in archive lib/libLLVMJITLink.a
This broke (at least) building clang itself with PGO (note this is using the gold linker, not lld):
ib/libLLVMObject.a(ELF.cpp.o):ELF.cpp:__profd__ZNK4llvm6object7ELFFileINS0_7ELFTypeILNS_7support10endiannessE1ELb0EEEE14getStringTableERKNS0_13Elf_Shdr_ImplIS5_EENS_12function_refIFNS_5ErrorERKNS_5TwineEEEE: error: relocation refers to local symbol "" [534], which is defined in a discarded section section group signature: "_ZNK4llvm6object7ELFFileINS0_7ELFTypeILNS_7support10endiannessE1ELb0EEEE14getStringTableERKNS0_13Elf_Shdr_ImplIS5_EENS_12function_refIFNS_5ErrorERKNS_5TwineEEEE" prevailing definition is from lib/libLLVMRuntimeDyld.a(RuntimeDyldELF.cpp.o) lib/libLLVMObject.a(ELF.cpp.o):ELF.cpp:__profd__ZNK4llvm6object7ELFFileINS0_7ELFTypeILNS_7support10endiannessE1ELb0EEEE8sectionsEv: error: relocation refers to local symbol "" [551], which is defined in a discarded section section group signature: "_ZNK4llvm6object7ELFFileINS0_7ELFTypeILNS_7support10endiannessE1ELb0EEEE8sectionsEv" prevailing definition is from lib/libLLVMRuntimeDyld.a(RuntimeDyldELF.cpp.o) lib/libLLVMObject.a(ELF.cpp.o):ELF.cpp:__profd__ZNK4llvm6object7ELFFileINS0_7ELFTypeILNS_7support10endiannessE1ELb0EEEE10getSectionEj: error: relocation refers to local symbol "" [560], which is defined in a discarded section section group signature: "_ZNK4llvm6object7ELFFileINS0_7ELFTypeILNS_7support10endiannessE1ELb0EEEE10getSectionEj" prevailing definition is from lib/libLLVMRuntimeDyld.a(RuntimeDyldELF.cpp.o) lib/libLLVMObject.a(ELF.cpp.o):ELF.cpp:__profd__ZNK4llvm6object7ELFFileINS0_7ELFTypeILNS_7support10endiannessE1ELb0EEEE13getSHNDXTableERKNS0_13Elf_Shdr_ImplIS5_EE: error: relocation refers to local symbol "" [561], which is defined in a discarded section section group signature: "_ZNK4llvm6object7ELFFileINS0_7ELFTypeILNS_7support10endiannessE1ELb0EEEE13getSHNDXTableERKNS0_13Elf_Shdr_ImplIS5_EE" prevailing definition is from lib/libLLVMRuntimeDyld.a(RuntimeDyldELF.cpp.o) lib/libLLVMObject.a(ELF.cpp.o):ELF.cpp:__profd__ZNK4llvm6object7ELFFileINS0_7ELFTypeILNS_7support10endiannessE1ELb0EEEE13getSHNDXTableERKNS0_13Elf_Shdr_ImplIS5_EENS_8ArrayRefIS8_EE: error: relocation refers to local symbol "" [562], which is defined in a discarded section section group signature: "_ZNK4llvm6object7ELFFileINS0_7ELFTypeILNS_7support10endiannessE1ELb0EEEE13getSHNDXTableERKNS0_13Elf_Shdr_ImplIS5_EENS_8ArrayRefIS8_EE" prevailing definition is from lib/libLLVMRuntimeDyld.a(RuntimeDyldELF.cpp.o) lib/libLLVMObject.a(ELF.cpp.o):ELF.cpp:__profd__ZNK4llvm6object7ELFFileINS0_7ELFTypeILNS_7support10endiannessE1ELb0EEEE21getRelocationTypeNameEjRNS_15SmallVectorImplIcEE: error: relocation refers to local symbol "" [590], which is defined in a discarded section section group signature: "_ZNK4llvm6object7ELFFileINS0_7ELFTypeILNS_7support10endiannessE1ELb0EEEE21getRelocationTypeNameEjRNS_15SmallVectorImplIcEE" prevailing definition is from lib/libLLVMRuntimeDyld.a(RuntimeDyldELF.cpp.o) lib/libLLVMObject.a(ELF.cpp.o):ELF.cpp:__profd__ZN4llvm6object7ELFFileINS0_7ELFTypeILNS_7support10endiannessE1ELb0EEEE6createENS_9StringRefE: error: relocation refers to local symbol "" [713], which is defined in a discarded section section group signature: "_ZN4llvm6object7ELFFileINS0_7ELFTypeILNS_7support10endiannessE1ELb0EEEE6createENS_9StringRefE" prevailing definition is from lib/libLLVMRuntimeDyld.a(RuntimeDyldELF.cpp.o) lib/libLLVMObject.a(ELF.cpp.o):ELF.cpp:__profd__ZNK4llvm6object7ELFFileINS0_7ELFTypeILNS_7support10endiannessE1ELb0EEEE21getSectionStringTableENS_8ArrayRefINS0_13Elf_Shdr_ImplIS5_EEEENS_12function_refIFNS_5ErrorERKNS_5TwineEEEE: error: relocation refers to local symbol "" [749], which is defined in a discarded section section group signature: "_ZNK4llvm6object7ELFFileINS0_7ELFTypeILNS_7support10endiannessE1ELb0EEEE21getSectionStringTableENS_8ArrayRefINS0_13Elf_Shdr_ImplIS5_EEEENS_12function_refIFNS_5ErrorERKNS_5TwineEEEE" prevailing definition is from lib/libLLVMRuntimeDyld.a(RuntimeDyldELF.cpp.o) lib/libLLVMObject.a(ELF.cpp.o):ELF.cpp:__profd__ZNK4llvm6object7ELFFileINS0_7ELFTypeILNS_7support10endiannessE1ELb0EEEE15getSectionIndexERKNS0_12Elf_Sym_ImplIS5_EENS_8ArrayRefIS8_EENS0_10DataRegionINS3_6detail31packed_endian_specific_integralIjLS4_1ELm1ELm1EEEEE: error: relocation refers to local symbol "" [753], which is defined in a discarded section section group signature: "_ZNK4llvm6object7ELFFileINS0_7ELFTypeILNS_7support10endiannessE1ELb0EEEE15getSectionIndexERKNS0_12Elf_Sym_ImplIS5_EENS_8ArrayRefIS8_EENS0_10DataRegionINS3_6detail31packed_endian_specific_integralIjLS4_1ELm1ELm1EEEEE" prevailing definition is from lib/libLLVMRuntimeDyld.a(RuntimeDyldELF.cpp.o)
etc.
Nov 1 2022
FWIW, I tested replacing CreateAdd with CreateSub on the original commit yesterday, and it fixed the issues I had.
Oct 31 2022
you're using the SDK libc++ with a ToT clang, which is technically not a supported combination.
Oct 28 2022
Reproducer: https://drive.google.com/file/d/1n7KPlKCydCgSdtnp6990Zn5_Yjbbss8L/view?usp=sharing (command in testcase/cmd)
Building Firefox with LTO for any aarch64 target (linux, macos, windows) enters in some sort of infinite loop since this change (linking never ends).
Oct 26 2022
I can confirm that applying the following (derived from 849c60541b630ddf8cabf9179fa771b3f4207):
diff --git a/clang/lib/AST/ASTContext.cpp b/clang/lib/AST/ASTContext.cpp index a8585a6d84ad..f07c40cb6c5d 100644 --- a/clang/lib/AST/ASTContext.cpp +++ b/clang/lib/AST/ASTContext.cpp @@ -6774,7 +6774,7 @@ ASTContext::getCanonicalTemplateArgument(const TemplateArgument &Arg) const {
Reduced testcase:
cc1 command line: clang-16 -cc1 -triple x86_64-unknown-linux-gnu -emit-obj -o Unified_cpp_editor_txmgr0.o -x c++-cpp-output Unified_cpp_editor_txmgr0.ii
source file content:
class nsCycleCollectionParticipant; class nsCycleCollectingAutoRefCnt; extern "C" void NS_CycleCollectorSuspect3(void *, nsCycleCollectionParticipant *, nsCycleCollectingAutoRefCnt *, bool *); class nsCycleCollectingAutoRefCnt { public: typedef void Suspect(void *, nsCycleCollectionParticipant *, nsCycleCollectingAutoRefCnt *, bool *); template <Suspect suspect = NS_CycleCollectorSuspect3> void incr(int *aOwner) { incr<suspect>(aOwner, nullptr); } template <Suspect = NS_CycleCollectorSuspect3> unsigned long incr(void *, nsCycleCollectionParticipant *) {} }; class TransactionItem { int Release(); nsCycleCollectingAutoRefCnt mRefCnt; }; int TransactionItem::Release() { mRefCnt.incr(this, 0); mRefCnt.incr(0); }
I'm running it through creduce (as well as the one for D136564. It's going to take a little while. Thank you for the revert.
Oct 25 2022
This broke building Firefox with:
In file included from Unified_cpp_dom_canvas0.cpp:65: /tmp/gecko/dom/canvas/ClientWebGLContext.cpp:355:19: error: call to deleted function 'IdByMethod' const auto id = IdByMethod<MethodType, method>(); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /tmp/gecko/dom/canvas/ClientWebGLContext.cpp:438:3: note: in instantiation of function template specialization 'mozilla::ClientWebGLContext::Run<void (mozilla::HostWebGLContext::*)(unsigned long, mozilla::layers::TextureType, bool, const mozilla::webgl::SwapChainOptions &) const, &mozilla::HostWebGLContext::Present, unsigned long, const mozilla::layers::TextureType &, const bool &, mozilla::webgl::SwapChainOptions &>' requested here Run<RPROC(Present)>(xrFb ? xrFb->mId : 0, type, webvr, asyncOptions); ^ /tmp/gecko/dom/canvas/WebGLMethodDispatcher.h:20:8: note: candidate function [with MethodT = void (mozilla::HostWebGLContext::*)(unsigned long, mozilla::layers::TextureType, bool, const mozilla::webgl::SwapChainOptions &) const, Method = &mozilla::HostWebGLContext::Present] has been explicitly deleted size_t IdByMethod() = delete; ^ In file included from Unified_cpp_dom_canvas0.cpp:65: /tmp/gecko/dom/canvas/ClientWebGLContext.cpp:355:19: error: call to deleted function 'IdByMethod' const auto id = IdByMethod<MethodType, method>(); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /tmp/gecko/dom/canvas/ClientWebGLContext.cpp:447:3: note: in instantiation of function template specialization 'mozilla::ClientWebGLContext::Run<void (mozilla::HostWebGLContext::*)(unsigned long, mozilla::layers::TextureType, const mozilla::webgl::SwapChainOptions &) const, &mozilla::HostWebGLContext::CopyToSwapChain, unsigned long, const mozilla::layers::TextureType &, mozilla::webgl::SwapChainOptions &>' requested here Run<RPROC(CopyToSwapChain)>(fb ? fb->mId : 0, texType, asyncOptions); ^ /tmp/gecko/dom/canvas/WebGLMethodDispatcher.h:20:8: note: candidate function [with MethodT = void (mozilla::HostWebGLContext::*)(unsigned long, mozilla::layers::TextureType, const mozilla::webgl::SwapChainOptions &) const, Method = &mozilla::HostWebGLContext::CopyToSwapChain] has been explicitly deleted size_t IdByMethod() = delete; ^
(etc.)
This broke building Firefox with:
In file included from Unified_cpp_editor_txmgr0.cpp:2: In file included from /tmp/gecko/editor/txmgr/TransactionItem.cpp:6: In file included from /tmp/gecko/editor/txmgr/TransactionItem.h:9: In file included from /tmp/gecko/obj-x86_64-pc-linux-gnu/dist/include/nsCOMPtr.h:31: In file included from /tmp/gecko/obj-x86_64-pc-linux-gnu/dist/include/nsISupportsUtils.h:16: /tmp/gecko/obj-x86_64-pc-linux-gnu/dist/include/nsISupportsImpl.h:238:31: error: definition with same mangled name '_ZN27nsCycleCollectingAutoRefCnt4incrIXadL_Z25NS_CycleCollectorSuspect3EEEEmPvP28nsCycleCollectionParticipant' as another definition MOZ_ALWAYS_INLINE uintptr_t incr(void* aOwner, ^ /tmp/gecko/obj-x86_64-pc-linux-gnu/dist/include/nsISupportsImpl.h:238:31: note: previous definition is here /tmp/gecko/obj-x86_64-pc-linux-gnu/dist/include/nsISupportsImpl.h:266:31: error: definition with same mangled name '_ZN27nsCycleCollectingAutoRefCnt4decrIXadL_Z25NS_CycleCollectorSuspect3EEEEmPvP28nsCycleCollectionParticipantPb' as another definition MOZ_ALWAYS_INLINE uintptr_t decr(void* aOwner, ^ /tmp/gecko/obj-x86_64-pc-linux-gnu/dist/include/nsISupportsImpl.h:266:31: note: previous definition is here 2 errors generated.
(And specifically, FuzzerFork.cpp doesn't use any of those declared things. Its only sin is to #include <fstream>, which happens to have /some/ methods (std::filesystem-related) only available on macos 10.15+.)
In either case, this seems to be an issue with libc++ that is out there in the wild.
Oct 24 2022
This breaks compiling many things on macOS, including compiler-rt:
/tmp/llvm2/obj/bin/clang++ --target=aarch64-apple-darwin -I/tmp/llvm2/compiler-rt/lib/fuzzer/../../include -Wall -Wno-unused-parameter -O3 -DNDEBUG -arch arm64 -isysroot /tmp/MacOSX11.3.sdk -stdlib=libc++ -mmacosx-version-min=10.10 -isysroot /tmp/MacOSX11.3.sdk -fPIC -fno-builtin -fno-exceptions -funwind-tables -fno-stack-protector -fno-sanitize=safe-stack -fvisibility=hidden -fno-lto -Wthread-safety -Wthread-safety-reference -Wthread-safety-beta -O3 -g -Wno-gnu -Wno-variadic-macros -Wno-c99-extensions -fno-omit-frame-pointer -std=c++17 -MD -MT lib/fuzzer/CMakeFiles/RTfuzzer.osx.dir/FuzzerFork.cpp.o -MF lib/fuzzer/CMakeFiles/RTfuzzer.osx.dir/FuzzerFork.cpp.o.d -o lib/fuzzer/CMakeFiles/RTfuzzer.osx.dir/FuzzerFork.cpp.o -c /tmp/llvm2/compiler-rt/lib/fuzzer/FuzzerFork.cpp In file included from /tmp/llvm2/compiler-rt/lib/fuzzer/FuzzerFork.cpp:11: In file included from /tmp/llvm2/compiler-rt/lib/fuzzer/FuzzerCommand.h:15: In file included from /tmp/llvm2/compiler-rt/lib/fuzzer/FuzzerDefs.h:18: In file included from /tmp/MacOSX11.3.sdk/usr/include/c++/v1/memory:667: /tmp/MacOSX11.3.sdk/usr/include/c++/v1/type_traits:1672:66: error: 'type' is unavailable: introduced in macOS 10.15 typedef _LIBCPP_NODEBUG_TYPE typename remove_reference<_Tp>::type _Up; ^ /tmp/MacOSX11.3.sdk/usr/include/c++/v1/filesystem:603:47: note: in instantiation of template class 'std::decay<std::filesystem::path>' requested here template <class _Source, class _DS = typename decay<_Source>::type, ^ /tmp/MacOSX11.3.sdk/usr/include/c++/v1/filesystem:648:31: note: in instantiation of default argument for '__is_pathable_char_array<std::filesystem::path>' required here bool _IsCharIterT = __is_pathable_char_array<_Tp>::value, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /tmp/MacOSX11.3.sdk/usr/include/c++/v1/filesystem:741:26: note: in instantiation of default argument for '__is_pathable<std::filesystem::path, false>' required here typename enable_if<__is_pathable<_SourceOrIter>::value, _Tp>::type; ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ /tmp/MacOSX11.3.sdk/usr/include/c++/v1/filesystem:861:29: note: in instantiation of template type alias '_EnableIfPathable' requested here _LIBCPP_INLINE_VISIBILITY _EnableIfPathable<_Source> ^ /tmp/MacOSX11.3.sdk/usr/include/c++/v1/filesystem:965:19: note: while substituting deduced template arguments into function template 'operator/=' [with _Source = path] return (*this /= __replacement); ^ /tmp/MacOSX11.3.sdk/usr/include/c++/v1/filesystem:738:24: note: 'path' has been explicitly marked unavailable here class _LIBCPP_TYPE_VIS path { ^
Oct 22 2022
@nikic can you push this for me?
Oct 21 2022
Removed -mtriple ; Restricted conversions from byval as well.
Oct 20 2022
Removed datalayout/Ran update_test_checks
Oct 19 2022
Would you reconsider this patch? Sure, it doesn't address the issue generally, but it does fix the cases that were actively broken by 6c8adc5.
Oct 12 2022
Added a null check.
Example for the case @efriedma mentions: https://llvm.godbolt.org/z/oPzWv9sr4
From a quick try, the same is true for argument promotion (https://llvm.godbolt.org/z/8We7dvYvT), we mix up the levels of indirection.
It looks like it's not a problem:
cat <<EOF | opt --O3 -S target datalayout = "e-m:e-p:32:32-p270:32:32-p271:32:32-p272:64:64-f64:32:64-f80:32-n8:16:32-S128" target triple = "i686-unknown-linux-gnu"
Oct 11 2022
Added missing datalayout and target.
Adjustment to the comment.
InstCombine test.
Refreshed test case to match what's in the issue.
Added testcase.
Oct 6 2022
Thank you. Could you publish this for me (I don't have commit access)?
Adding a testcase that crashes without the patch and passes with the patch.
Oct 3 2022
@rnk ping
Sep 25 2022
Sep 23 2022
Sep 20 2022
This didn't change the default for msvc targets, was that expected?
Aug 22 2022
FWIW, it also broke compiler-rt standalone builds:
CMake Error at lib/builtins/CMakeLists.txt:702 (add_security_warnings): Unknown CMake command "add_security_warnings".
Aug 18 2022
Thank you
Aug 17 2022
@smeenai I see you pushed something similar in 5737f6a527d782e6577e5cc1e0c743df2c98546a, but missing the config-ix.cmake part, would you mind pushing that cleanup too?
Aug 15 2022
@MaskRay This Dockerfile reproduces it with Debian testing: https://gist.github.com/glandium/6c130dee608f9585b425c4a40a084d27
Aug 14 2022
For what it's worth, this break building compiler-rt with clang-cl:
In file included from /builds/worker/fetches/llvm-project/compiler-rt/lib/orc/coff_platform.cpp:16: In file included from /builds/worker/fetches/llvm-project/compiler-rt/lib/orc/coff_platform.h:17: In file included from /builds/worker/fetches/llvm-project/compiler-rt/lib/orc/executor_address.h:20: /builds/worker/fetches/llvm-project/compiler-rt/lib/orc/simple_packed_serialization.h(403,58): error: no member named 'string_view' in namespace 'std' template <> class SPSSerializationTraits<SPSString, std::string_view> { ~~~~~^ /builds/worker/fetches/llvm-project/compiler-rt/lib/orc/coff_platform.cpp(109,21): error: no type named 'string_view' in namespace ' std' void *dlopen(std::string_view Name, int Mode); ~~~~~^ /builds/worker/fetches/llvm-project/compiler-rt/lib/orc/coff_platform.cpp(111,34): error: no type named 'string_view' in namespace ' std' void *dlsym(void *Header, std::string_view Symbol); ~~~~~^ /builds/worker/fetches/llvm-project/compiler-rt/lib/orc/coff_platform.cpp(118,34): error: no member named 'string_view' in namespace 'std' std::vector<std::pair<std::string_view, ExecutorAddrRange>> Secs, ~~~~~^ /builds/worker/fetches/llvm-project/compiler-rt/lib/orc/coff_platform.cpp(122,34): error: no member named 'string_view' in namespace 'std' std::vector<std::pair<std::string_view, ExecutorAddrRange>> Secs); ~~~~~^ /builds/worker/fetches/llvm-project/compiler-rt/lib/orc/coff_platform.cpp(135,36): error: no type named 'string_view' in namespace ' std' Expected<void *> dlopenImpl(std::string_view Path, int Mode); ~~~~~^ /builds/worker/fetches/llvm-project/compiler-rt/lib/orc/coff_platform.cpp(143,46): error: no type named 'string_view' in namespace ' std' JITDylibState *getJITDylibStateByName(std::string_view Path); ~~~~~^ /builds/worker/fetches/llvm-project/compiler-rt/lib/orc/coff_platform.cpp(145,54): error: no type named 'string_view' in namespace ' std' std::string_view Symbol); ~~~~~^ /builds/worker/fetches/llvm-project/compiler-rt/lib/orc/coff_platform.cpp(156,27): error: no member named 'string_view' in namespace 'std' std::unordered_map<std::string_view, void *> JDNameToHeader; ~~~~~^ /builds/worker/fetches/llvm-project/compiler-rt/lib/orc/coff_platform.cpp(173,55): error: no type named 'string_view' in namespace ' std'
etc.
Aug 11 2022
Having looked around in the Firefox codebase for cases that now fail to build because of this, and looking at the clarification in DR2338, I wonder if enums in extern "C" sections should be treated as if they had an explicit type of int as if it were e.g. enum Foo: int { ... }.
Aug 10 2022
Also not caught: a cast of 0 when 0 is not a valid value in the enum.