From: Tom Lane <tgl@sss.pgh.pa.us>
To: John Naylor <johncnaylorls@gmail.com>
cc: Andres Freund <andres@anarazel.de>, pgsql-committers@lists.postgresql.org,
        cookt@blackduck.com
Subject: Re: pgsql: Inline CRC computation for small fixed-length input on x86
In-reply-to: 
 <CANWCAZZSxs3a1YRKehkgk2OHKbrVn+xZ+AWW8Co2R_f70NqqmA@mail.gmail.com>
References: <E1tz8dY-001tOE-31@gemulon.postgresql.org>
 <CANWCAZYRbrAyUG29SyVZdamEaSfX0FG=TuyhMaGyqJhpdTN=vg@mail.gmail.com>
 <CANWCAZbA+sDBdSQFcyp_-1T-r5HKFMbLhjM0uwZWZNZ+T9R85A@mail.gmail.com>
 <CANWCAZZSxs3a1YRKehkgk2OHKbrVn+xZ+AWW8Co2R_f70NqqmA@mail.gmail.com>
Comments: In-reply-to John Naylor <johncnaylorls@gmail.com>
	message dated "Mon, 31 Mar 2025 18:16:47 +0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3837989.1743423175.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Mon, 31 Mar 2025 08:12:55 -0400
Message-ID: <3837990.1743423175@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/3837990.1743423175%40sss.pgh.pa.us>
Precedence: bulk

John Naylor <johncnaylorls@gmail.com> writes:
> 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 have reproduced it on a genuine-Red-Hat RHEL 9 x86_64 machine,
but only when compiling with --with-llvm, and the error goes away
if I select CC=3Dclang.  Furthermore, configure reports

checking which CRC-32C implementation to use... SSE 4.2

with CC=3Dgcc but it says

checking which CRC-32C implementation to use... SSE 4.2 with runtime check

with CC=3Dclang.  Furthermore, the failure doesn't occur when gcc
compiles a file, but it does occur when clang compiles the same
file to produce a .bc file:

[transam]$ make twophase.o
gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-stateme=
nt -Werror=3Dvla -Wendif-labels -Wmissing-format-attribute -Wimplicit-fall=
through=3D3 -Wcast-function-type -Wshadow=3Dcompatible-local -Wformat-secu=
rity -fno-strict-aliasing -fwrapv -fexcess-precision=3Dstandard -Wno-forma=
t-truncation -Wno-stringop-truncation -g -O2 -I../../../../src/include   -=
D_GNU_SOURCE   -c -o twophase.o twophase.c
[transam]$ make twophase.bc
/usr/lib64/ccache/clang -Wno-ignored-attributes -fno-strict-aliasing -fwra=
pv -fexcess-precision=3Dstandard -Wno-unused-command-line-argument -Wno-co=
mpound-token-split-by-macro -Wno-format-truncation -O2  -I../../../../src/=
include   -D_GNU_SOURCE  -flto=3Dthin -emit-llvm -c -o twophase.bc twophas=
e.c
In file included from twophase.c:79:
In file included from ../../../../src/include/access/commit_ts.h:16:
In file included from ../../../../src/include/replication/origin.h:15:
In file included from ../../../../src/include/access/xlogreader.h:41:
In file included from ../../../../src/include/access/xlogrecord.h:16:
../../../../src/include/port/pg_crc32c.h:70:10: error: always_inline funct=
ion '_mm_crc32_u64' requires target feature 'crc32', but would be inlined =
into function 'pg_comp_crc32c_dispatch' that is compiled without support f=
or 'crc32'
   70 |                         crc =3D _mm_crc32_u64(crc, *(const uint64 =
*) p);
      |                               ^
../../../../src/include/port/pg_crc32c.h:73:10: error: always_inline funct=
ion '_mm_crc32_u32' requires target feature 'crc32', but would be inlined =
into function 'pg_comp_crc32c_dispatch' that is compiled without support f=
or 'crc32'
   73 |                         crc =3D _mm_crc32_u32(crc, *(const uint32 =
*) p);
      |                               ^
../../../../src/include/port/pg_crc32c.h:75:10: error: always_inline funct=
ion '_mm_crc32_u8' requires target feature 'crc32', but would be inlined i=
nto function 'pg_comp_crc32c_dispatch' that is compiled without support fo=
r 'crc32'
   75 |                         crc =3D _mm_crc32_u8(crc, *p++);
      |                               ^
3 errors generated.
make: *** [../../../../src/Makefile.global:1097: twophase.bc] Error 1

What I conclude is that Red Hat hot-wired gcc to assume -msse4.2,
but they didn't hot-wire clang the same way.

This seems kind of problematic for us.  Quite aside from the build
failure, doesn't it mean that the .bc files are not very
representative of what is in the .o files?

			regards, tom lane