Re: Broken ./configure checks for __cpuid() and __cpuidex()
| От | Lukas Fittl |
|---|---|
| Тема | Re: Broken ./configure checks for __cpuid() and __cpuidex() |
| Дата | |
| Msg-id | CAP53PkyKyDMzrjKepMoeECQ90ay2dRjh38+cqFb0EFdHsfpzJQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Broken ./configure checks for __cpuid() and __cpuidex() (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: Broken ./configure checks for __cpuid() and __cpuidex()
|
| Список | pgsql-hackers |
On Mon, Jul 28, 2025 at 8:40 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> How isn't that a bug in MinGW itself? I'm puzzled my the macro
> definition of __cpuid() that reports a conflict. __cpuidex() and
> __cpuid() are both detected by ./configure, the PG use of __cpuid() in
> pg_crc32c_sse42_choose.c causes a failure.
Why is the configure probe succeeding? Maybe pg_crc32c_sse42_choose.c
is including something the configure check isn't?
Could it be that the problem only happens when including both cpuid.h and intrin.h, because they both define __cpuid? (the configure check only includes intrin.h)
My theory when I worked on the patch that Michael referenced in the original email was that intrin.h is only for MSVC (for GCC at least, __cpuidex is defined in cpuid.h).
I'm not sure how to get CI to run MinGW (it appears paused for me?), so I can't test this myself easily.
But the relevant change would be to change "defined(HAVE__CPUIDEX)" to "(defined(HAVE__CPUIDEX) && defined(_MSC_VER))" for the guard on both intrin.h includes.
Thanks,
Lukas
Lukas Fittl
В списке pgsql-hackers по дате отправления: