Re: BUG #18610: llvm error: __aarch64_swp4_acq_rel which could not be resolved - Mailing list pgsql-bugs

From a.kozhemyakin
Subject Re: BUG #18610: llvm error: __aarch64_swp4_acq_rel which could not be resolved
Date
Msg-id 9e0a13b4-2402-4df0-a515-47153119e80c@postgrespro.ru
Whole thread Raw
In response to Re: BUG #18610: llvm error: __aarch64_swp4_acq_rel which could not be resolved  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: BUG #18610: llvm error: __aarch64_swp4_acq_rel which could not be resolved
List pgsql-bugs

Thank you, the error no longer occurs after adding -mno-outline-atomics or -march=armv8.1-a

I installed packages on debian-12 (arm64) from https://apt.postgresql.org/pub/repos/apt, the error is repeated.


11.09.2024 16:55, Thomas Munro пишет:
Hmm, I think it is inlining spinlock code from
pg_last_wal_receive_lsn()'s call to GetWalRcvFlushRecPtr(), and then
failing to find fallbacks for pre-ARMv8.1 systems that didn't have the
LSE atomic instructions.  I wonder if there could be some mismatch in
the default -march for parts of your toolchain, so that it doesn't
link the library that has that stuff, but then the clang that built
walreceiverfuncs.bc expects it to be found.  I wonder if it goes away
if you add "-mno-outline-atomics" or "-march=armv8.1-a" or
"-march=armv8-a+lse" to BITCODE_CXXFLAGS (not saying that's a fix,
just trying to understand what's happening...).  Assuming you're using
GCC, maybe "gcc -Q --help=target | grep march" could show what Ubuntu
24 has set as the baseline, and "clang -### -c -x c /dev/null" might
show what clang is selecting... just ideas, I'm not sure, I don't have
such a system, I just noticed a few distros cranking up the baseline
instruction sets recently...

pgsql-bugs by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: pl/perl extension fails on Windows
Next
From: PG Bug reporting form
Date:
Subject: BUG #18611: Postgres service crashes continuously in loop of reinitialization if disk partition is full