MIME-Version: 1.0
References: <E1tz8dY-001tOE-31@gemulon.postgresql.org>
 <CANWCAZYRbrAyUG29SyVZdamEaSfX0FG=TuyhMaGyqJhpdTN=vg@mail.gmail.com>
 <CANWCAZbA+sDBdSQFcyp_-1T-r5HKFMbLhjM0uwZWZNZ+T9R85A@mail.gmail.com>
In-Reply-To: 
 <CANWCAZbA+sDBdSQFcyp_-1T-r5HKFMbLhjM0uwZWZNZ+T9R85A@mail.gmail.com>
From: John Naylor <johncnaylorls@gmail.com>
Date: Mon, 31 Mar 2025 18:16:47 +0700
Message-ID: 
 <CANWCAZZSxs3a1YRKehkgk2OHKbrVn+xZ+AWW8Co2R_f70NqqmA@mail.gmail.com>
Subject: Re: pgsql: Inline CRC computation for small fixed-length input on x86
To: John Naylor <john.naylor@postgresql.org>
Cc: pgsql-committers@lists.postgresql.org, cookt@blackduck.com
Content-Type: multipart/mixed; boundary="00000000000014ccc30631a18f8a"
Archived-At: 
 <https://www.postgresql.org/message-id/CANWCAZZSxs3a1YRKehkgk2OHKbrVn%2BxZ%2BAWW8Co2R_f70NqqmA%40mail.gmail.com>
Precedence: bulk

--00000000000014ccc30631a18f8a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Mar 31, 2025 at 3:07=E2=80=AFPM John Naylor <johncnaylorls@gmail.co=
m> wrote:
>
> On Mon, Mar 31, 2025 at 2:18=E2=80=AFPM 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=3Dskimmer=
&dt=3D2025-03-31%2007%3A00%3A27&stg=3Dconfigure
> >
> > "checking which CRC-32C implementation to use... SSE 4.2"
> >
> >  I'm now looking for clues as to what could be causing the build failur=
e.
>
> 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=3D71991
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D84926

...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

--00000000000014ccc30631a18f8a
Content-Type: text/x-patch; charset="US-ASCII";
	name="v1-workaround-possible-lto-gcc-bug.patch"
Content-Disposition: attachment;
	filename="v1-workaround-possible-lto-gcc-bug.patch"
Content-Transfer-Encoding: base64
Content-ID: <f_m8wywk6y0>
X-Attachment-Id: f_m8wywk6y0

ZGlmZiAtLWdpdCBhL3NyYy9pbmNsdWRlL3BvcnQvcGdfY3JjMzJjLmggYi9zcmMvaW5jbHVkZS9w
b3J0L3BnX2NyYzMyYy5oCmluZGV4IDBhYjc1MTNmNTIzLi5iNDE5ODk3NWZhNiAxMDA2NDQKLS0t
IGEvc3JjL2luY2x1ZGUvcG9ydC9wZ19jcmMzMmMuaAorKysgYi9zcmMvaW5jbHVkZS9wb3J0L3Bn
X2NyYzMyYy5oCkBAIC01Myw2ICs1Myw3IEBAIHR5cGVkZWYgdWludDMyIHBnX2NyYzMyYzsKIGV4
dGVybiBwZ19jcmMzMmMgcGdfY29tcF9jcmMzMmNfc3NlNDIocGdfY3JjMzJjIGNyYywgY29uc3Qg
dm9pZCAqZGF0YSwgc2l6ZV90IGxlbik7CiAKIHBnX2F0dHJpYnV0ZV9ub19zYW5pdGl6ZV9hbGln
bm1lbnQoKQorcGdfYXR0cmlidXRlX3RhcmdldCgic3NlNC4yIikKIHN0YXRpYyBpbmxpbmUKIHBn
X2NyYzMyYwogcGdfY29tcF9jcmMzMmNfZGlzcGF0Y2gocGdfY3JjMzJjIGNyYywgY29uc3Qgdm9p
ZCAqZGF0YSwgc2l6ZV90IGxlbikK
--00000000000014ccc30631a18f8a--