Re: Failures with gcd functions with GCC snapshots GCC and -O3 (?) - Mailing list pgsql-hackers
From | Tom Lane |
---|---|
Subject | Re: Failures with gcd functions with GCC snapshots GCC and -O3 (?) |
Date | |
Msg-id | 1234630.1624042279@sss.pgh.pa.us Whole thread Raw |
In response to | Re: Failures with gcd functions with GCC snapshots GCC and -O3 (?) (Alvaro Herrera <alvherre@alvh.no-ip.org>) |
Responses |
Re: Failures with gcd functions with GCC snapshots GCC and -O3 (?)
|
List | pgsql-hackers |
Alvaro Herrera <alvherre@alvh.no-ip.org> writes: > Hello, this problem is still happening; serinus' configure output says > it's running a snapshot from 20210527, and Fabien mentioned downthread > that his compiler stopped complaining on 2021-06-05. Andres, maybe the > compiler in serinus is due for an update too? Yeah, serinus is visibly still running one of the broken revisions: configure: using compiler=gcc (Debian 20210527-1) 12.0.0 20210527 (experimental) [master revision 262e75d22c3:7bb6b9b2f47:9d3a953ec4d2695e9a6bfa5f22655e2aea47a973] It'd sure be nice if seawasp stopped spamming the buildfarm failure log, too. That seems to be a different issue: Program terminated with signal SIGABRT, Aborted. #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 #1 0x00007f3827947859 in __GI_abort () at abort.c:79 #2 0x00007f3827947729 in __assert_fail_base (fmt=0x7f3827add588 "%s%s%s:%u: %s%sAssertion `%s' failed.\\n%n", assertion=0x7f381c3ce4c8"S->getValue() && \\"Releasing SymbolStringPtr with zero ref count\\"", file=0x7f381c3ce478 "/home/fabien/llvm-src/llvm/include/llvm/ExecutionEngine/Orc/SymbolStringPool.h",line=91, function=<optimized out>) at assert.c:92 #3 0x00007f3827958f36 in __GI___assert_fail (assertion=0x7f381c3ce4c8 "S->getValue() && \\"Releasing SymbolStringPtr withzero ref count\\"", file=0x7f381c3ce478 "/home/fabien/llvm-src/llvm/include/llvm/ExecutionEngine/Orc/SymbolStringPool.h",line=91, function=0x7f381c3ce570 "llvm::orc::SymbolStringPtr::~SymbolStringPtr()")at assert.c:101 #4 0x00007f381c23c98d in llvm::orc::SymbolStringPtr::~SymbolStringPtr (this=0x277a8b0, __in_chrg=<optimized out>) at /home/fabien/llvm-src/llvm/include/llvm/ExecutionEngine/Orc/SymbolStringPool.h:91 #5 0x00007f381c24f879 in std::_Destroy<llvm::orc::SymbolStringPtr> (__pointer=0x277a8b0) at /home/fabien/gcc-10-bin/include/c++/10.3.1/bits/stl_construct.h:140 #6 0x00007f381c24d10c in std::_Destroy_aux<false>::__destroy<llvm::orc::SymbolStringPtr*> (__first=0x277a8b0, __last=0x277a998)at /home/fabien/gcc-10-bin/include/c++/10.3.1/bits/stl_construct.h:152 #7 0x00007f381c2488a6 in std::_Destroy<llvm::orc::SymbolStringPtr*> (__first=0x277a8b0, __last=0x277a998) at /home/fabien/gcc-10-bin/include/c++/10.3.1/bits/stl_construct.h:185 #8 0x00007f381c243c51 in std::_Destroy<llvm::orc::SymbolStringPtr*, llvm::orc::SymbolStringPtr> (__first=0x277a8b0, __last=0x277a998)at /home/fabien/gcc-10-bin/include/c++/10.3.1/bits/alloc_traits.h:738 #9 0x00007f381c23f1c3 in std::vector<llvm::orc::SymbolStringPtr, std::allocator<llvm::orc::SymbolStringPtr> >::~vector (this=0x7ffc73440a10,__in_chrg=<optimized out>) at /home/fabien/gcc-10-bin/include/c++/10.3.1/bits/stl_vector.h:680 #10 0x00007f381c26112c in llvm::orc::JITDylib::removeTracker (this=0x18b4240, RT=...) at /home/fabien/llvm-src/llvm/lib/ExecutionEngine/Orc/Core.cpp:1464 #11 0x00007f381c264cb9 in operator() (__closure=0x7ffc73440d00) at /home/fabien/llvm-src/llvm/lib/ExecutionEngine/Orc/Core.cpp:2054 #12 0x00007f381c264d29 in llvm::orc::ExecutionSession::runSessionLocked<llvm::orc::ExecutionSession::removeResourceTracker(llvm::orc::ResourceTracker&)::<lambda()> >(struct{...} &&) (this=0x187d110, F=...) at /home/fabien/llvm-src/llvm/include/llvm/ExecutionEngine/Orc/Core.h:1291 #13 0x00007f381c264ebc in llvm::orc::ExecutionSession::removeResourceTracker (this=0x187d110, RT=...) at /home/fabien/llvm-src/llvm/lib/ExecutionEngine/Orc/Core.cpp:2051 #14 0x00007f381c25734c in llvm::orc::ResourceTracker::remove (this=0x1910c30) at /home/fabien/llvm-src/llvm/lib/ExecutionEngine/Orc/Core.cpp:53 #15 0x00007f381c25a9c1 in llvm::orc::JITDylib::clear (this=0x18b4240) at /home/fabien/llvm-src/llvm/lib/ExecutionEngine/Orc/Core.cpp:622 #16 0x00007f381c26305e in llvm::orc::ExecutionSession::endSession (this=0x187d110) at /home/fabien/llvm-src/llvm/lib/ExecutionEngine/Orc/Core.cpp:1777 #17 0x00007f381c3373a3 in llvm::orc::LLJIT::~LLJIT (this=0x18a73b0, __in_chrg=<optimized out>) at /home/fabien/llvm-src/llvm/lib/ExecutionEngine/Orc/LLJIT.cpp:1002 #18 0x00007f381c38af48 in LLVMOrcDisposeLLJIT (J=0x18a73b0) at /home/fabien/llvm-src/llvm/lib/ExecutionEngine/Orc/OrcV2CBindings.cpp:561 #19 0x00007f381c596612 in llvm_shutdown (code=<optimized out>, arg=140722242323824) at llvmjit.c:892 #20 0x00000000007d4385 in proc_exit_prepare (code=code@entry=0) at ipc.c:209 #21 0x00000000007d4288 in proc_exit (code=code@entry=0) at ipc.c:107 regards, tom lane
pgsql-hackers by date: