Re: LLVM 16 (opaque pointers)

Hi,

On 2023-10-24 10:17:22 +1300, Thomas Munro wrote:
> This POWER animal fails, unexpectedly to me:
> 
> > bonito: 7.0.1 Fedora 29
> 
> We could try to chase that down, or we could rejoice that at least it
> works on current release.  It must begin working somewhere between 7
> and 11, but when I checked which LLVM releases I could easily install
> on eg cascabel (if I could get access) using the repo at apt.llvm.org,
> I saw that they don't even have anything older than 11.  So someone
> with access who wants to figure this out might have many days or weeks
> of compiling ahead of them.

I could reproduce the failure on bonito. The stack trace is:
#0  0x00007fffb83541e8 in raise () from /lib64/libc.so.6
#1  0x00007fffb833448c in abort () from /lib64/libc.so.6
#2  0x00007fff9c68dd78 in std::__replacement_assert (_file=<optimized out>, _line=<optimized out>, _function=<optimized
out>,_condition=<optimized out>)
 
    at /usr/include/c++/8/ppc64le-redhat-linux/bits/c++config.h:447
#3  0x00007fff9df90838 in std::unique_ptr<llvm::orc::JITCompileCallbackManager,
std::default_delete<llvm::orc::JITCompileCallbackManager>>::operator* (
 
    this=0x1b946cb8) at ../include/llvm/Support/MemAlloc.h:29
#4  llvm::OrcCBindingsStack::OrcCBindingsStack(llvm::TargetMachine&,
std::function<std::unique_ptr<llvm::orc::IndirectStubsManager,std::default_delete<llvm::orc::IndirectStubsManager> >
()>)(this=0x1b946be0, TM=..., IndirectStubsMgrBuilder=...) at ../lib/ExecutionEngine/Orc/OrcCBindingsStack.h:242
 
#5  0x00007fff9df90940 in LLVMOrcCreateInstance (TM=0x1b933ae0) at /usr/include/c++/8/bits/move.h:182
#6  0x00007fffa0618f8c in llvm_session_initialize () at /home/andres/src/postgres/src/backend/jit/llvm/llvmjit.c:981
#7  0x00007fffa06179a8 in llvm_create_context (jitFlags=25) at
/home/andres/src/postgres/src/backend/jit/llvm/llvmjit.c:219
#8  0x00007fffa0626cbc in llvm_compile_expr (state=0x1b8ef390) at
/home/andres/src/postgres/src/backend/jit/llvm/llvmjit_expr.c:142
#9  0x0000000010a76fc8 in jit_compile_expr (state=0x1b8ef390) at /home/andres/src/postgres/src/backend/jit/jit.c:177
#10 0x0000000010404550 in ExecReadyExpr (state=0x1b8ef390) at
/home/andres/src/postgres/src/backend/executor/execExpr.c:875

with this assertion message printed:
/usr/include/c++/8/bits/unique_ptr.h:328: typename std::add_lvalue_reference<_Tp>::type std::unique_ptr<_Tp,
Dp>::operator*()const [with Tp = llvm::orc::JITCompileCallbackManager; _Dp =
std::default_delete<llvm::orc::JITCompileCallbackManager>;typename std::add_lvalue_reference<_Tp>::type =
llvm::orc::JITCompileCallbackManager&]:Assertion 'get() != pointer()' failed.
 


I wanted to use a debug build to investigate in more detail, but bonito is a
small VM. Thus I built llvm 7 on a more powerful gcc cfarm machine, running on
AlmaLinux 9.2.  The problem doesn't reproduce there.

Given the crash in some c++ standard library code, that the fc29 patches to
llvm look harmless, that building/using llvm 7 on a newer distro does not show
issues on PPC, it seems likely that this is a compiler / standard library
issue.

FC 29 is well out of support, so I don't think it makes sense to invest any
further time in this. Personally, I don't think it's useful to have years old
fedora in the buildfarm...

Greetings,

Andres Freund