Content-Type: multipart/alternative;
 boundary="------------rTIxH1y0EjiCo40nu96mHOSF"
Message-ID: <9e0a13b4-2402-4df0-a515-47153119e80c@postgrespro.ru>
Date: Thu, 12 Sep 2024 09:30:06 +0700
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
From: "a.kozhemyakin" <a.kozhemyakin@postgrespro.ru>
Subject: Re: BUG #18610: llvm error: __aarch64_swp4_acq_rel which could not be
 resolved
To: Thomas Munro <thomas.munro@gmail.com>, pgsql-bugs@lists.postgresql.org
References: <18610-37bf303f904fede3@postgresql.org>
 <CA+hUKGKwzv9bbDD2c=Ugv62PVinVUopxRgL8pKxyiBPHsrgWog@mail.gmail.com>
Content-Language: ru
In-Reply-To: 
 <CA+hUKGKwzv9bbDD2c=Ugv62PVinVUopxRgL8pKxyiBPHsrgWog@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/9e0a13b4-2402-4df0-a515-47153119e80c%40postgrespro.ru>
Precedence: bulk

This is a multi-part message in MIME format.
--------------rTIxH1y0EjiCo40nu96mHOSF
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

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...
--------------rTIxH1y0EjiCo40nu96mHOSF
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Thank you, the error no longer occurs after adding
      -mno-outline-atomics or -march=armv8.1-a</p>
    <p>I installed packages on debian-12 (arm64) from <a
        class="moz-txt-link-freetext"
        href="https://apt.postgresql.org/pub/repos/apt">https://apt.postgresql.org/pub/repos/apt</a>,
      the error is repeated.</p>
    <p><br>
    </p>
    <div class="moz-cite-prefix">11.09.2024 16:55, Thomas Munro пишет:<br>
    </div>
    <blockquote type="cite"
cite="mid:CA+hUKGKwzv9bbDD2c=Ugv62PVinVUopxRgL8pKxyiBPHsrgWog@mail.gmail.com">
      <pre>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...</pre>
    </blockquote>
  </body>
</html>

--------------rTIxH1y0EjiCo40nu96mHOSF--