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:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: A few nuances about specifying the timeline with START_REPLICATION
Next
From: Alexey Kondratov
Date:
Subject: Re: Supply restore_command to pg_rewind via CLI argument