From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Mathew Heard <mat999(at)gmail(dot)com> |
Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #18839: ARMv7 builds fail due to missing __crc32cw and similar |
Date: | 2025-03-14 03:46:10 |
Message-ID: | 2974260.1741923970@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Mathew Heard <mat999(at)gmail(dot)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 (march
> 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=... (cached) no
checking for __crc32cb, __crc32ch, __crc32cw, and __crc32cd with CFLAGS=-march=armv8-a+crc+simd... (cached) yes
checking which CRC-32C implementation to use... ARMv8 CRC instructions with runtime check
and then in the build log we find
ccache gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Werror=vla -Wendif-labels -Wmissing-format-attribute -Wimplicit-fallthrough=3 -Wcast-function-type -Wshadow=compatible-local -Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -Wno-format-truncation -Wno-stringop-truncation -g -O2 -march=armv8-a+crc+simd -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 like
> 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=grison&dt=2025-03-14%2000%3A04%3A12
From | Date | Subject | |
---|---|---|---|
Next Message | PG Bug reporting form | 2025-03-14 07:58:45 | BUG #18845: DEREF_OF_NULL.RET guc_malloc possibly returns NULL |
Previous Message | Mathew Heard | 2025-03-14 03:12:35 | Re: BUG #18839: ARMv7 builds fail due to missing __crc32cw and similar |