The following error happens only with 32bit /usr/bin/clang but not via -m32. I'm using a custom kernel which is (re)based on drm-next but it doesn't exhibit issues on 10.3 i386 or 11.0 i386. FAILED: tools/lld/ELF/CMakeFiles/lldELF.dir/OutputSections.cpp.o /usr/bin/c++ -DGTEST_HAS_RTTI=0 -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Itools/lld/ELF -I/wrkdirs/usr/ports/devel/llvm39/work/llvm-3.9.1.src/tools/lld/ELF -I/wrkdirs/usr/ports/devel/llvm39/work/llvm-3.9.1.src/tools/lld/include -Itools/lld/include -Iinclude -I/wrkdirs/usr/ports/devel/llvm39/work/llvm-3.9.1.src/include -I/usr/local/include -O2 -pipe -fstack-protector -isystem /usr/local/include -fno-strict-aliasing -isystem /usr/local/include -fPIC -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Werror=date-time -std=c++11 -fcolor-diagnostics -ffunction-sections -fdata-sections -O2 -pipe -fstack-protector -isystem /usr/local/include -fno-strict-aliasing -isystem /usr/local/include -fno-exceptions -fno-rtti -MD -MT tools/lld/ELF/CMakeFiles/lldELF.dir/OutputSections.cpp.o -MF tools/lld/ELF/CMakeFiles/lldELF.dir/OutputSections.cpp.o.d -o tools/lld/ELF/CMakeFiles/lldELF.dir/OutputSections.cpp.o -c /wrkdirs/usr/ports/devel/llvm39/work/llvm-3.9.1.src/tools/lld/ELF/OutputSections.cpp c++: error: unable to execute command: Segmentation fault c++: error: clang frontend command failed due to signal (use -v to see invocation) FreeBSD clang version 4.0.0 (branches/release_40 292009) (based on LLVM 4.0.0) Target: i386-unknown-freebsd12.0 Thread model: posix InstalledDir: /usr/bin c++: note: diagnostic msg: PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and include the crash backtrace, preprocessed source, and associated run script. c++: note: diagnostic msg: ******************** PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: c++: note: diagnostic msg: /tmp/OutputSections-f012c9.cpp c++: note: diagnostic msg: /tmp/OutputSections-f012c9.sh c++: note: diagnostic msg:
Oops, this is for /projects/clang400-import@312229.
Created attachment 178923 [details] OutputSections-8d5025.cpp (compressed)
Created attachment 178924 [details] OutputSections-8d5025.sh
Hm, yes, I'm seeing this too, while building llvm38 even. Something is rotten, but it's hard to figure out what. For some reason, a cleanly built release_40 r292009 on universe12a.f.o works fine, but on my local system, it doesn't. I'm trying valgrind to figure out what is going wrong, and it gives me: ==1793== Invalid read of size 8 ==1793== at 0x227C9BE: llvm::ValueHandleBase::AddToUseList() (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/clang/clang.full) ==1793== by 0x29A3F2D: llvm::AssumptionCache::AffectedValueCallbackVH::allUsesReplacedWith(llvm::Value*) (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/clang/clang.full) ==1793== by 0x227A884: llvm::ValueHandleBase::ValueIsRAUWd(llvm::Value*, llvm::Value*) (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/clang/clang.full) ==1793== by 0x227A504: llvm::Value::doRAUW(llvm::Value*, bool) (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/clang/clang.full) ==1793== by 0x1C9791E: llvm::sroa::AllocaSliceRewriter::visitLoadInst(llvm::LoadInst&) (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/clang/clang.full) ==1793== by 0x1C880FD: llvm::sroa::AllocaSliceRewriter::visit((anonymous namespace)::Slice const*) (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/clang/clang.full) ==1793== by 0x1C86C9A: llvm::SROA::rewritePartition(llvm::AllocaInst&, llvm::sroa::AllocaSlices&, llvm::sroa::Partition&) (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/clang/clang.full) ==1793== by 0x1C88584: llvm::SROA::splitAlloca(llvm::AllocaInst&, llvm::sroa::AllocaSlices&) (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/clang/clang.full) ==1793== by 0x1C89A1D: llvm::SROA::runOnAlloca(llvm::AllocaInst&) (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/clang/clang.full) ==1793== by 0x1C8B309: llvm::SROA::runImpl(llvm::Function&, llvm::DominatorTree&, llvm::AssumptionCache&) (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/clang/clang.full) ==1793== by 0x1C9C239: llvm::sroa::SROALegacyPass::runOnFunction(llvm::Function&) (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/clang/clang.full) ==1793== by 0x22B78D9: llvm::FPPassManager::runOnFunction(llvm::Function&) (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/clang/clang.full) ==1793== Address 0x5a5a5a5a5a5a5a62 is not stack'd, malloc'd or (recently) free'd ==1793== pid 1793 (memcheck-amd64-free): sigreturn rflags = 0x4 ==1793== ==1793== Process terminating with default action of signal 10 (SIGBUS): dumping core ==1793== Hardware error at address 0x40F7A495F ==1793== at 0x227C9BE: llvm::ValueHandleBase::AddToUseList() (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/clang/clang.full) ==1793== by 0x29A3F2D: llvm::AssumptionCache::AffectedValueCallbackVH::allUsesReplacedWith(llvm::Value*) (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/clang/clang.full) ==1793== by 0x227A884: llvm::ValueHandleBase::ValueIsRAUWd(llvm::Value*, llvm::Value*) (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/clang/clang.full) ==1793== by 0x227A504: llvm::Value::doRAUW(llvm::Value*, bool) (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/clang/clang.full) ==1793== by 0x1C9791E: llvm::sroa::AllocaSliceRewriter::visitLoadInst(llvm::LoadInst&) (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/clang/clang.full) ==1793== by 0x1C880FD: llvm::sroa::AllocaSliceRewriter::visit((anonymous namespace)::Slice const*) (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/clang/clang.full) ==1793== by 0x1C86C9A: llvm::SROA::rewritePartition(llvm::AllocaInst&, llvm::sroa::AllocaSlices&, llvm::sroa::Partition&) (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/clang/clang.full) ==1793== by 0x1C88584: llvm::SROA::splitAlloca(llvm::AllocaInst&, llvm::sroa::AllocaSlices&) (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/clang/clang.full) ==1793== by 0x1C89A1D: llvm::SROA::runOnAlloca(llvm::AllocaInst&) (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/clang/clang.full) ==1793== by 0x1C8B309: llvm::SROA::runImpl(llvm::Function&, llvm::DominatorTree&, llvm::AssumptionCache&) (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/clang/clang.full) ==1793== by 0x1C9C239: llvm::sroa::SROALegacyPass::runOnFunction(llvm::Function&) (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/clang/clang.full) ==1793== by 0x22B78D9: llvm::FPPassManager::runOnFunction(llvm::Function&) (in /usr/obj/share/dim/src/freebsd/base/projects/clang400-import/usr.bin/clang/clang/clang.full)
I managed to figure out that upstream https://reviews.llvm.org/rL291671 caused a use-after-free issue, which is why it doesn't always crash. I had to run it under valgrind to see relatively clearly where it came from. Hal Finkel has put up a review for a fix here: https://reviews.llvm.org/D28749
A commit references this bug: Author: dim Date: Mon Jan 16 19:53:19 UTC 2017 New revision: 312308 URL: https://svnweb.freebsd.org/changeset/base/312308 Log: Pull in r292133 from upstream llvm trunk (by Hal Finkel): Fix use-after-free bug in AffectedValueCallbackVH::allUsesReplacedWith When transferring affected values in the cache from an old value, identified by the value of the current callback, to the specified new value we might need to insert a new entry into the DenseMap which constitutes the cache. Doing so might delete the current callback object. Move the copying logic into a new function, a member of the assumption cache itself, so that we don't run into UB should the callback handle itself be removed mid-copy. Differential Revision: https://reviews.llvm.org/D28749 This should fix crashes when building lld (as part of the llvmXY ports). Reported by: jbeich PR: 216117 Changes: projects/clang400-import/contrib/llvm/include/llvm/Analysis/AssumptionCache.h projects/clang400-import/contrib/llvm/lib/Analysis/AssumptionCache.cpp
Should be fixed now, as of r312308.