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
In-reply-to: 
 <CAE5sJtRk6KcjfwPfi_r2h3iCyihBdkBamR74-MJqevp9qnnyYg@mail.gmail.com>
References: 
 <CAE5sJtTG7ZTZqPHW003AuLEi6yO8vqY04vVXx5jZbPt1FRViXQ@mail.gmail.com>
 <2953389.1741911582@sss.pgh.pa.us>
 <CAE5sJtSzqXVNzCdU1P+2YYSZ2yO4ceN11wUmZg5-gAGSrnwEWw@mail.gmail.com>
 <2958437.1741914536@sss.pgh.pa.us>
 <CAE5sJtSXjvmHdM1Rp3DBi1o3sQmxN0jEdjA_nB6qx0u7CkpKCQ@mail.gmail.com>
 <2964086.1741917658@sss.pgh.pa.us>
 <CAE5sJtR=Vk7MM=EAoZtXqQN6w9Lnu7eWT9D46cBX9HWk8x7igw@mail.gmail.com>
 <2965436.1741918726@sss.pgh.pa.us>
 <CAE5sJtRk6KcjfwPfi_r2h3iCyihBdkBamR74-MJqevp9qnnyYg@mail.gmail.com>
Comments: In-reply-to Mathew Heard <mat999@gmail.com>
	message dated "Fri, 14 Mar 2025 14:12:35 +1100"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2974259.1741923970.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Thu, 13 Mar 2025 23:46:10 -0400
Message-ID: <2974260.1741923970@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2974260.1741923970%40sss.pgh.pa.us>
Precedence: bulk

Mathew Heard <mat999@gmail.com> writes:
> When the configure test is running its forcing armv8-a+crc+simd (has
> __crc32cb, etc)  rather than testing for the feature against target
> architecture (no __crc32cb, etc). While make is compiling for the target
> architecture armv7ve+simd (no __crc32cb, etc). During the make it is of
> course failing to find __crc32cb etc, they only existed during the
> configure test due to the custom cflags used for that feature test (marc=
h
> armv8-a+crc+simd).

No, because when pg_crc32c_armv8.c is compiled, that same -march
setting is used for that one specific file -- trace through the
use of CFLAGS_CRC in the Makefiles.  For instance, on buildfarm
member grison[1] which seems like it should be a pretty close match
for your situation, the configure log shows

checking for __crc32cb, __crc32ch, __crc32cw, and __crc32cd with CFLAGS=3D=
... (cached) no
checking for __crc32cb, __crc32ch, __crc32cw, and __crc32cd with CFLAGS=3D=
-march=3Darmv8-a+crc+simd... (cached) yes
checking which CRC-32C implementation to use... ARMv8 CRC instructions wit=
h runtime check

and then in the build log we find

ccache gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-=
statement -Werror=3Dvla -Wendif-labels -Wmissing-format-attribute -Wimplic=
it-fallthrough=3D3 -Wcast-function-type -Wshadow=3Dcompatible-local -Wform=
at-security -fno-strict-aliasing -fwrapv -fexcess-precision=3Dstandard -Wn=
o-format-truncation -Wno-stringop-truncation -g -O2 -march=3Darmv8-a+crc+s=
imd -I../../src/port -DFRONTEND -I../../src/include  -D_GNU_SOURCE -I/usr/=
include/libxml2   -c -o pg_crc32c_armv8.o pg_crc32c_armv8.c

(note the -march flag) so that's expected to compile, and does,
even though the platform is armv7l in general.  I have no idea whether
grison's underlying hardware is v7 or v8, and it shouldn't matter for
this purpose, because the only thing at stake is the build toolchain's
behavior.

> I'm not really sure what's so confusing about this situation. It seems l=
ike
> a configure feature test that will always detect CRC support on any ARM =
gcc
> (that supports those functions). I'm mostly surprised your arm build
> environment is passing.

I'm not sure how I can put this any more plainly: it works fine for
everyone but you, including ARMv7 machines.  I have no intention of
regressing performance for everyone who runs on mixed ARMv7/v8
platforms in order to un-break your build.  We need to figure out what
is unusual about your build environment that is causing this mechanism
not to work as-expected.

			regards, tom lane

[1] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=3Dgrison&dt=3D=
2025-03-14%2000%3A04%3A12