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
signature.asc
Description: PGP signature
