Re: BUG #18610: llvm error: __aarch64_swp4_acq_rel which could not be resolved

From: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
To: "a(dot)kozhemyakin" <a(dot)kozhemyakin(at)postgrespro(dot)ru>
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #18610: llvm error: __aarch64_swp4_acq_rel which could not be resolved
Date: 2024-11-08 05:15:30
Message-ID: CA+hUKG+4S=v27MQ=6H-KQ95w_BWSmXCVuz9RRL0bW=_qQf4=9g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

While hacking on ARM problems this week, I remembered this one.

I see now that this is not new: all Debian clang versions at least as
far back as 14, including the default one on Debian stable, have it on
by default. That is out of sync with their gcc package. So unless
you also set CC to clang, you get:

postgres=# set jit_inline_above_cost = 0;
SET
postgres=# set jit_above_cost = 0;
SET
postgres=# select pg_last_wal_receive_lsn();
WARNING: failed to resolve name __aarch64_swp4_acq_rel
FATAL: fatal llvm error: Program used external function
'__aarch64_swp4_acq_rel' which could not be resolved!

I suspect some other distros might have turned this on in their gcc
too but I am not sure which ones.

Some options:

1. Somehow figure out if $CC is using -moutline-atomics, then make
BITCODE_CFLAGS agree. I haven't thought of a nice way to do it...

2. Tell $CC to use it. That was already kinda rejected in that other
thread, leaving this up to the toolchain people. If we ever change
our minds on that, it I guess it would be master only, so not help
with this problem.

3. Disable it in BITCODE_CFLAGS, whether or not $CC is using it. It
might be fairly rare for inlined functions to use relevant atomic ops,
so perhaps it's not such a big deal to be conservative here for now.

Here's a patch for approach #3. This is low-urgency and a code freeze
begins in a day or two, so I'm *not* proposing it for next week's
release.

Attachment Content-Type Size
0001-jit-Use-mno-outline-atomics-for-bitcode.patch application/octet-stream 6.8 KB

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message David Pavlíček 2024-11-08 07:51:36 Re: BUG #18694: DISCARD ALL does not reset execution counters for plpgsql functions
Previous Message Tom Lane 2024-11-08 05:10:54 Re: BUG #18692: Segmentation fault when extending a varchar column with a gist index with custom signal length