On Thu, Jul 18, 2024 at 9:50 AM Jakub Jelinek <ja...@redhat.com> wrote: > > On Thu, Jul 18, 2024 at 09:34:14AM +0200, Uros Bizjak wrote: > > > > + unsigned int ecx2 = 0, family = 0; > > > > No need to initialize these two variables. > > The function ignores __get_cpuid result, so at least the > FEAT1_REGISTER = 0; is needed before the first __get_cpuid. > Do you mean the ecx2 = 0 initialization is useless because > __get_cpuid (0, ...) on x86_64 will always succeed (especially > when __get_cpuid (1, ...) had to succeed otherwise FEAT1_REGISTER > would be zero)? > I guess that is true, but won't that cause -Wmaybe-uninitialized warnings?
Yes, if the __get_cpuid (1, ...) works OK, then we are sure that __get_cpuid (0, ...) will also work. > I agree initializing family to 0 is not needed, but I don't understand > why it isn't just > unsigned family = (eax >> 8) & 0x0f; > Though, guess even that might fail with -Wmaybe-uninitialized too, as > eax isn't unconditionally initialized. Perhaps we should check the result of __get_cpuid (1, ...) and use eax only if the function returns 1? IMO, this would solve the uninitialized issue, and we could use __cpuid in the second case (we would know that leaf 0 is supported, because leaf 1 support was checked with __get_cpuid (1, ...)). Uros.
