Re: Broken ./configure checks for __cpuid() and __cpuidex()

On Tue, Jul 29, 2025 at 12:21:32AM -0700, Lukas Fittl wrote:
> Its worth noting that __get_cpuid_count and __cpuidex are not fully
> equivalent (which is part of why GCC added __cpuidex despite already
> having __get_cpuid_count), but in any case the current code doesn't care
> about that, since it prefers __get_cpuid_count if available, and I think
> that difference only applies to special leafs like the VM Hypervisor
> information (not used yet).

Yes, do you think that there would be a case in the future where it
makes sense to be able to detect both at the same time?  Based on what
I see in the tree like bitutils.c, I really doubt so.  We could always
deal with that if it shows as a problem later, as required.

> Thanks, to be clear, I have CI enabled but the MinGW tasks were always
> paused (presumably because of the trigger type being manual). But I think
> "ci-os-only" as noted in the README should do the trick, I'll go
> investigate that.

My failures were detected in the Compiler Warnings job.

> FWIW, I looked again at the MinGW sources and I think you're right that
> intrin.h is likely also correct for MinGW. I originally thought that
> cpuid.h would be correct, given that's whats used by GCC/clang, but I think
> the MinGW source itself is authoritative here (vs the compiler in use), and
> that has a intrin.h include ([0]) but no cpuid.h.

Yeah.  I have a close of MinGW locally, and that matches what I saw.

Applied on all the branches.  Let's wait for the buildfarm to report,
now.
--
Michael