https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110955
--- Comment #15 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> --- > --- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot > Uni-Bielefeld.DE> --- >> --- Comment #7 from Rainer Orth <ro at gcc dot gnu.org> --- >> (In reply to Petr Sumbera from comment #3) >>> (In reply to Andrew Pinski from comment #1) >>> > Are you sure this is NOT a LLVM JIT issue? >>> > There was a similar issue on aarch64 too; PR 108994 which was fixed in >>> > LLVM >>> > side. >>> >>> Don't really know. But the binary gnome-shell which was compiled by GCC 12 >>> doesn't run with GCC 13 runtime. >>> >>> Also when I copy gcc/libgcc/unwind-dw2-fde.(c|h) from GCC 12 to GCC 13 it >>> doesn't crash then. >> >> I'm not sure if we taked about this before: have you tried building SPARC >> LLVM >> without the JIT patch (033-solaris-LLVM-JIT.patch)? It may be worth a try >> until someone fixes and integrates SPARC JIT support for real. > > Another question: do you have a way to reliably reproduce that SEGV? > When I run gnome-shell with X11 forwarding (i.e. without a full GNOME > session), I get this instead: I've now done some more digging and found a way to reproduce the issue without gnome-shell. To do this, I refreshed the SPARC RuntimeDyLD patch to apply to current LLVM main. Then I built and ran the whole thing with both GCC 13 and GCC 12 (and the corresponding versions of libgcc_s.so.1). The set of failures is almost the same between those two trials, however the exact error conditions vary. I've now got some of the failing tests that fail in classify_object_over_fdes with GCC 13, but run into SIGILL with GCC 12. clang/unittests/Interpreter/ExceptionTests/./ClangReplInterpreterExceptionTests is an example: * GCC 13: 0 ClangReplInterpreterExceptionTests 0x0000000102561a6c llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) + 36 1 ClangReplInterpreterExceptionTests 0x000000010256234c SignalHandler(int) + 896 2 libc.so.1 0xffffffff7eec57c8 __sighndlr + 12 3 libc.so.1 0xffffffff7eeb8070 call_user_handler + 1024 4 libc.so.1 0xffffffff7eeb8430 sigacthandler + 160 5 libc.so.1 0xffffffff7edd7ab8 strlen + 24 6 libgcc_s.so.1 0xffffffff383127a4 classify_object_over_fdes + 96 7 libgcc_s.so.1 0xffffffff383132a8 __register_frame_info_bases + 72 8 ClangReplInterpreterExceptionTests 0x0000000102c10ff4 llvm::RTDyldMemoryManager::registerEHFrames(unsigned char*, unsigned long, unsigned long) + 20 9 ClangReplInterpreterExceptionTests 0x0000000102c299b4 llvm::RuntimeDyldELF::registerEHFrames() + 144 10 ClangReplInterpreterExceptionTests 0x0000000102c1c608 llvm::RuntimeDyldImpl::finalizeAsync(std::unique_ptr<llvm::RuntimeDyldImpl, std::default_delete<llvm::RuntimeDyldImpl>>, llvm::unique_function<void (llvm::object::OwningBinary<llvm::object::ObjectFile>, std::unique_ptr<llvm::RuntimeDyld::LoadedObjectInfo, std::default_delete<llvm::RuntimeDyld::LoadedObjectInfo>>, llvm::Error)>, llvm::object::OwningBinary<llvm::object::ObjectFile>, std::unique_ptr<llvm::RuntimeDyld::LoadedObjectInfo, std::default_delete<llvm::RuntimeDyld::LoadedObjectInfo>>)::$_0::operator()(llvm::Expected<std::map<llvm::StringRef, llvm::JITEvaluatedSymbol, std::less<llvm::StringRef>, std::allocator<std::pair<llvm::StringRef const, llvm::JITEvaluatedSymbol>>>>) + 348 [...] * GCC 12: 0 ClangReplInterpreterExceptionTests 0x0000000102561b4c llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) + 36 1 ClangReplInterpreterExceptionTests 0x000000010256242c SignalHandler(int) + 896 2 libc.so.1 0xffffffff7e2c57c8 __sighndlr + 12 3 libc.so.1 0xffffffff7e2b8070 call_user_handler + 1024 4 libc.so.1 0xffffffff7e2b8460 sigacthandler + 208 5 libc.so.1 0xffffffff7f5ec508 sigacthandler + 20136312 6 libc.so.1 0xffffffff7f5ec01c sigacthandler + 20135052 7 ClangReplInterpreterExceptionTests 0x000000010213b308 (anonymous namespace)::InterpreterTest_CatchException_Test::TestBody() + 1884 8 ClangReplInterpreterExceptionTests 0x000000010257f198 testing::Test::Run() + 432 [...] So there was definitely something amiss before, only exact failure mode changed with GCC 13. Definitely easier to investigate than gnome-shell, but still pretty much a nightmare.
