-
Notifications
You must be signed in to change notification settings - Fork 12.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SIGSEGV with -flto #118725
Comments
Could you please try 19 or |
I don't think 19 is packaged for arch yet. I'll see if I can build trunk later in the week. Is it possible to just to disable this optimizeGlobalCtorsList or all of globalopt. I looked through --hidden-help and could not see an option like this. |
@illiminable While it is not packaged by Arch yet, you could try the linked toolchain instead and use it via an environment variable which points llvm to the new path: https://mirrors.edge.kernel.org/pub/tools/llvm/ |
OK thanks I'll try. FWIW this is the approximate code pattern. And presumably its trying to optimize the fact that there are N unique symbols that "register" assigns true to but then never get used.
|
@ms178 The toolchain didn't work because it doesn't contain LLVMgold.so I was able to build from the 19.1.5 branch in debug and can repro. It's only on one target. This is the assert output ld.gold: /mnt/local/src/third_party/github/llvm/llvm-project/llvm/include/llvm/Support/Casting.h:109: static bool llvm::isa_impl_cl<To, const From*>::doit(const From*) [with To = llvm::ConstantVector; From = llvm::Constant]: Assertion `Val && "isa<> used on a null pointer"' failed. And a better symbolized stack #0 0x00007c11cae473f4 in ?? () from /usr/lib/libc.so.6 |
@illiminable Thanks for letting me know. Unfortunately I am not a developer and cannot help you to debug this problem further. |
I debugged a little bit, but I don't fully understand this code. In EvaluateBlock the issue is that after the various branches the code falls out to this block at 609 with InstResult still null. All the other branches usually check InstResult and return false. ConstantFoldConstant will assert or crash if the first parameter is null in the call from 610. I also tried just guarding this conditino with !InstResult but that doesn't seem right since it triggers another assert later "Assertion `R && "Reference to an uncomputed value!"'. The bug only only occurs when the code hits the branch on 556. Strangely the debug log here says both branches of the if are success. I don't know if it's a copy paste error or if maybe the code should just return true after 558, but given the rest of the code this doesn't seem right. But returning false in the line 556 branch seems to fix the crash and the resulting program seems to work fine. Someone who understands the code better should evaluate though. |
I used llvm-reduce to reduce the bitcode and when i looked at what was left it was basically __cxa_guard_acquire and I realized that while bootstrapping i defined it with the wrong return type. So since I violated the ABI I guess my fault. Not sure if there is still an underlying issue here someone wants to fix. ie. would be better to error or ignore than crash. But it seems pretty unlikely someone else will hit at least this specific cause of the problem. Can probably close if this corner case is not important. |
Could you please share the reduced bitcode? (Or IR after running it through llvm-dis.) |
This is the reduced.bc |
The global ctor evaluator tries to evalute function calls where the call function type and function type do not match, by performing bitcasts. This currently causes a crash when calling a void function with non-void return type. I've opted to remove this functionality entirely rather than fixing this specific case. With opaque pointers, there shouldn't be a legitimate use case for this anymore, as we don't need to look through pointer type casts. Doing other bitcasts is very iffy because it ignores ABI considerations. We should at least leave adjusting the signatures to make them line up to InstCombine (which also does some iffy things, but is at least somewhat more constrained). Fixes llvm#118725.
…119548) The global ctor evaluator tries to evalute function calls where the call function type and function type do not match, by performing bitcasts. This currently causes a crash when calling a void function with non-void return type. I've opted to remove this functionality entirely rather than fixing this specific case. With opaque pointers, there shouldn't be a legitimate use case for this anymore, as we don't need to look through pointer type casts. Doing other bitcasts is very iffy because it ignores ABI considerations. We should at least leave adjusting the signatures to make them line up to InstCombine (which also does some iffy things, but is at least somewhat more constrained). Fixes #118725.
Static linking with -flto on Arch linux with clang 18.1.8
Not able to get a minimal repro at the moment. Other possibly less common options
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007ee06170e69c in llvm::ConstantFoldConstant(llvm::Constant const*, llvm::DataLayout const&, llvm::TargetLibraryInfo const*) () from /usr/lib/libLLVM.so.18.1
#0 0x00007ee06170e69c in llvm::ConstantFoldConstant(llvm::Constant const*, llvm::DataLayout const&, llvm::TargetLibraryInfo const*) () from /usr/lib/libLLVM.so.18.1
#1 0x00007ee060abea1a in llvm::Evaluator::EvaluateBlock(llvm::ilist_iterator_w_bits<llvm::ilist_detail::node_options<llvm::Instruction, false, false, void, true>, false, false>, llvm::BasicBlock*&, bool&) () from /usr/lib/libLLVM.so.18.1
#2 0x00007ee060ac14e4 in llvm::Evaluator::EvaluateFunction(llvm::Function*, llvm::Constant*&, llvm::SmallVectorImplllvm::Constant* const&) () from /usr/lib/libLLVM.so.18.1
#3 0x00007ee061307930 in ?? () from /usr/lib/libLLVM.so.18.1
#4 0x00007ee061308634 in ?? () from /usr/lib/libLLVM.so.18.1
#5 0x00007ee060aa7649 in llvm::optimizeGlobalCtorsList(llvm::Module&, llvm::function_ref<bool (unsigned int, llvm::Function*)>) () from /usr/lib/libLLVM.so.18.1
#6 0x00007ee0613135f9 in llvm::GlobalOptPass::run(llvm::Module&, llvm::AnalysisManagerllvm::Module&) () from /usr/lib/libLLVM.so.18.1
#7 0x00007ee06411d177 in ?? () from /usr/lib/libLLVM.so.18.1
#8 0x00007ee05fbd767e in llvm::PassManager<llvm::Module, llvm::AnalysisManagerllvm::Module>::run(llvm::Module&, llvm::AnalysisManagerllvm::Module&) () from /usr/lib/libLLVM.so.18.1
#9 0x00007ee061a57995 in ?? () from /usr/lib/libLLVM.so.18.1
#10 0x00007ee061a591ff in llvm::lto::opt(llvm::lto::Config const&, llvm::TargetMachine*, unsigned int, llvm::Module&, bool, llvm::ModuleSummaryIndex*, llvm::ModuleSummaryIndex const*, std::vector<unsigned char, std::allocator > const&) () from /usr/lib/libLLVM.so.18.1
#11 0x00007ee061a5a582 in llvm::lto::backend(llvm::lto::Config const&, std::function<llvm::Expected<std::unique_ptr<llvm::CachedFileStream, std::default_deletellvm::CachedFileStream > > (unsigned int, llvm::Twine const&)>, unsigned int, llvm::Module&, llvm::ModuleSummaryIndex&) () from /usr/lib/libLLVM.so.18.1
#12 0x00007ee061a4ed49 in llvm::lto::LTO::runRegularLTO(std::function<llvm::Expected<std::unique_ptr<llvm::CachedFileStream, std::default_deletellvm::CachedFileStream > > (unsigned int, llvm::Twine const&)>) () from /usr/lib/libLLVM.so.18.1
#13 0x00007ee061a4f241 in llvm::lto::LTO::run(std::function<llvm::Expected<std::unique_ptr<llvm::CachedFileStream, std::default_deletellvm::CachedFileStream > > (unsigned int, llvm::Twine const&)>, std::function<llvm::Expected<std::function<llvm::Expected<std::unique_ptr<llvm::CachedFileStream, std::default_deletellvm::CachedFileStream > > (unsigned int, llvm::Twine const&)> > (unsigned int, llvm::StringRef, llvm::Twine const&)>) () from /usr/lib/libLLVM.so.18.1
#14 0x00007ee0678ce067 in ?? () from /usr/bin/../lib/LLVMgold.so
#15 0x00007ee0678cfd12 in ?? () from /usr/bin/../lib/LLVMgold.so
#16 0x000056f827567837 in ?? ()
#17 0x000056f82756f75f in ?? ()
#18 0x00007ee067a00e08 in ?? () from /usr/lib/libc.so.6
#19 0x00007ee067a00ecc in __libc_start_main () from /usr/lib/libc.so.6
#20 0x000056f82756ea65 in ?? ()
The text was updated successfully, but these errors were encountered: