On Mon, Mar 31, 2025 at 3:07 PM John Naylor <johncnaylorls@gmail.com> wrote:
>
> On Mon, Mar 31, 2025 at 2:18 PM John Naylor <johncnaylorls@gmail.com> wrote:
>
> > Hmm, skimmer doesn't like this, and it's one of the animals that
> > builds with -msse4.2:
> >
> > https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=skimmer&dt=2025-03-31%2007%3A00%3A27&stg=configure
> >
> > "checking which CRC-32C implementation to use... SSE 4.2"
> >
> > I'm now looking for clues as to what could be causing the build failure.
>
> Looking at the configure output, I don't see -msee4.2 (or equivalent),
> so it shouldn't be reporting that it's targeting SSE 4.2.
Another clue: A few RHEL 9 x86_64 machines have reported in (webworm,
shikra) with successful builds, and they also report targeting SSE 4.2
and also don't have special CFLAG's. We do know RHEL 9 has a policy of
always targeting x86_64-v2, and it seems that they don't require
user/packager intervention to achieve that, so I imagine their
packaged compiler always defines __SSE4_2__ etc.
The two problem systems are CentOS stream 9 (apparently using LTO),
and Rocky Linux 9 (still awaiting details). Both of these are supposed
to be like RHEL 9.
I found these old gcc bug reports for a similar symptom when using LTO:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71991
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84926
...so one theory is that the OS's with failing builds have let a
similar bug back in.
A possible workaround would be add a normally-superfluous
"pg_attribute_target("sse4.2")" to the inlined function, as in the
attached.
--
John Naylor
Amazon Web Services
