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

From: "a(dot)kozhemyakin" <a(dot)kozhemyakin(at)postgrespro(dot)ru>
To: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, 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-09-12 02:30:06
Message-ID: 9e0a13b4-2402-4df0-a515-47153119e80c@postgrespro.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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...

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message PG Bug reporting form 2024-09-12 07:10:39 BUG #18611: Postgres service crashes continuously in loop of reinitialization if disk partition is full
Previous Message Junwang Zhao 2024-09-11 14:56:33 Re: BUG #18598: AddressSanitizer detects use after free inside json_unique_hash_match()