From: Tom Lane <tgl@sss.pgh.pa.us>
To: Mathew Heard <mat999@gmail.com>
Cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18839: ARMv7 builds fail due to missing __crc32cw and similar
Date: Thu, 13 Mar 2025 21:45:39 -0400
Message-ID: <2962250.1741916739@sss.pgh.pa.us> (raw)
In-Reply-To: <2958437.1741914536@sss.pgh.pa.us>
References: <CAE5sJtTG7ZTZqPHW003AuLEi6yO8vqY04vVXx5jZbPt1FRViXQ@mail.gmail.com>
<2953389.1741911582@sss.pgh.pa.us>
<CAE5sJtSzqXVNzCdU1P+2YYSZ2yO4ceN11wUmZg5-gAGSrnwEWw@mail.gmail.com>
<2958437.1741914536@sss.pgh.pa.us>
I wrote:
> The configure script isn't "identifying" anything. It's just seeing
> whether references to __crc32cb() etc will compile with different
> -march flags. It's not apparent why a successful test of that sort
> would not lead to a successful compilation with the same flags later
> on.
Actually ... looking harder at the test code, perhaps I see a way.
We're testing this:
unsigned int crc = 0;
crc = __crc32cb(crc, 0);
crc = __crc32ch(crc, 0);
crc = __crc32cw(crc, 0);
crc = __crc32cd(crc, 0);
/* return computed value, to prevent the above being optimized away */
return crc == 0;
but that "prevent the above being optimized away" looks mighty leaky.
Specifically, there's nothing stopping the compiler from folding all
these CRC calls to constants, since the input is constant. So in
an environment where the compiler knows these functions but glibc
doesn't have them, perhaps we could get a false pass --- and then
the real code with non-constant inputs could fail?
I'm not very convinced of this theory, because I checked with gcc
12.2.0 and it wouldn't do that even at max -O level. But maybe
your compiler is different. Could you try the attached patch
for configure and see if it arrives at the right conclusions?
regards, tom lane
Attachments:prevent-constant-folding-in-CRC-probes.patch (text/x-diff, 1.8K) downloaddiff --git a/config/c-compiler.m4 b/config/c-compiler.m4index d3562d6feee..a4b005d07ca 100644--- a/config/c-compiler.m4+++ b/config/c-compiler.m4@@ -659,9 +659,9 @@ AC_DEFUN([PGAC_ARMV8_CRC32C_INTRINSICS],
AC_CACHE_CHECK([for __crc32cb, __crc32ch, __crc32cw, and __crc32cd with CFLAGS=$1], [Ac_cachevar],
[pgac_save_CFLAGS=$CFLAGS
CFLAGS="$pgac_save_CFLAGS $1"
-AC_LINK_IFELSE([AC_LANG_PROGRAM([#include <arm_acle.h>],- [unsigned int crc = 0;- crc = __crc32cb(crc, 0);+AC_LINK_IFELSE([AC_LANG_PROGRAM([#include <arm_acle.h>+unsigned int crc;],+ [crc = __crc32cb(crc, 0);
crc = __crc32ch(crc, 0);
crc = __crc32cw(crc, 0);
crc = __crc32cd(crc, 0);
diff --git a/configure b/configureindex fa9085b1c0d..3f89837e031 100755--- a/configure+++ b/configure@@ -18741,11 +18741,11 @@ CFLAGS="$pgac_save_CFLAGS "
cat confdefs.h - <<_ACEOF >conftest.$ac_ext
/* end confdefs.h. */
#include <arm_acle.h>
+unsigned int crc;
int
main ()
{
-unsigned int crc = 0;- crc = __crc32cb(crc, 0);+crc = __crc32cb(crc, 0);
crc = __crc32ch(crc, 0);
crc = __crc32cw(crc, 0);
crc = __crc32cd(crc, 0);
@@ -18782,11 +18782,11 @@ CFLAGS="$pgac_save_CFLAGS -march=armv8-a+crc+simd"
cat confdefs.h - <<_ACEOF >conftest.$ac_ext
/* end confdefs.h. */
#include <arm_acle.h>
+unsigned int crc;
int
main ()
{
-unsigned int crc = 0;- crc = __crc32cb(crc, 0);+crc = __crc32cb(crc, 0);
crc = __crc32ch(crc, 0);
crc = __crc32cw(crc, 0);
crc = __crc32cd(crc, 0);
@@ -18823,11 +18823,11 @@ CFLAGS="$pgac_save_CFLAGS -march=armv8-a+crc"
cat confdefs.h - <<_ACEOF >conftest.$ac_ext
/* end confdefs.h. */
#include <arm_acle.h>
+unsigned int crc;
int
main ()
{
-unsigned int crc = 0;- crc = __crc32cb(crc, 0);+crc = __crc32cb(crc, 0);
crc = __crc32ch(crc, 0);
crc = __crc32cw(crc, 0);
crc = __crc32cd(crc, 0);
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: tgl@sss.pgh.pa.us, mat999@gmail.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18839: ARMv7 builds fail due to missing __crc32cw and similar
In-Reply-To: <2962250.1741916739@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox