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 |
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 |