Re: Not-terribly-safe checks for CRC intrinsic support - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Not-terribly-safe checks for CRC intrinsic support
Date
Msg-id 1116844.1742502433@sss.pgh.pa.us
Whole thread Raw
In response to Re: Not-terribly-safe checks for CRC intrinsic support  (John Naylor <johncnaylorls@gmail.com>)
List pgsql-hackers
John Naylor <johncnaylorls@gmail.com> writes:
> On Sat, Mar 15, 2025 at 6:04 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> In short, I think we ought to apply and perhaps back-patch something
>> like the attached.

> Seems like reasonable defensive coding and consistency.

Thanks for looking at it.

> I'd be okay with keeping the original comment, though, since it seems
> to be explaining the choice well enough.

Okay.

>> BTW, it looks to me like PGAC_AVX512_POPCNT_INTRINSICS is at similar
>> hazard, but I'm not entirely sure how to fix that one.

> "buf" is the variable there that we're loading from, so that would be
> the one to make global.

Ah.  I was confused by the "const" decoration, but we can remove that.

After thinking for a bit, I pushed this just to master rather than
back-patching.  We can do a back-patch if anyone discovers that this
is a live issue on any current platform, but I rather suspect that
it isn't.  Compiler not matched to platform is a situation that's
gone away for most people.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Ilia Evdokimov
Date:
Subject: Remove redundant if-else in EXPLAIN by using ExplainPropertyText
Next
From: Tom Lane
Date:
Subject: Re: Have postgres.bki self-identify