Horton

Re: LLVM 16 (opaque pointers)

Andres Freund <andres@anarazel.de>

View thread
From: Andres Freund <andres@anarazel.de>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: Mark Wong <markwkm@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Ronan Dunklau <ronan.dunklau@aiven.io>, Devrim Gündüz <devrim@gunduz.org>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Fabien COELHO <coelho@cri.ensmp.fr>, Dmitry Dolgov <9erthalion6@gmail.com>
Date: 2023-10-24T02:40:07Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. jit: Adjust back-patch of f90b4a84 to 12 and 13.

  2. Log LLVM library version in configure output.

  3. jit: Changes for LLVM 17.

  4. jit: Supply LLVMGlobalGetValueType() for LLVM < 8.

  5. jit: Support opaque pointers in LLVM 16.

  6. jit: Reference function pointer types via llvmjit_types.c.

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