2011/12/7 Måns Rullgård <[email protected]>: > "Ronald S. Bultje" <[email protected]> writes: > >> Hi, >> >> On Wed, Dec 7, 2011 at 2:28 PM, Sean McGovern <[email protected]> wrote: >> >>> 2011/12/7 Måns Rullgård <[email protected]>: >>> > Janne Grunau <[email protected]> writes: >>> > >>> >> On 2011-07-25 19:57:38 -0400, Sean McGovern wrote: >>> >>> non-GNU compilers may have difficulty with the cpuid() macro, so >>> >>> get the results and then store each member separately. >>> >>> --- >>> >>> libavutil/x86/cpu.c | 5 ++++- >>> >>> 1 files changed, 4 insertions(+), 1 deletions(-) >>> >>> >>> >>> diff --git a/libavutil/x86/cpu.c b/libavutil/x86/cpu.c >>> >>> index 78aeadf..618d2c2 100644 >>> >>> --- a/libavutil/x86/cpu.c >>> >>> +++ b/libavutil/x86/cpu.c >>> >>> @@ -74,7 +74,10 @@ int ff_get_cpu_flags_x86(void) >>> >>> return 0; /* CPUID not supported */ >>> >>> #endif >>> >>> >>> >>> - cpuid(0, max_std_level, vendor.i[0], vendor.i[2], vendor.i[1]); >>> >>> + cpuid(0, max_std_level, ebx, ecx, edx); >>> >>> + vendor.i[0] = ebx; >>> >>> + vendor.i[1] = edx; >>> >>> + vendor.i[2] = ecx; >>> >>> >>> >>> if(max_std_level >= 1){ >>> >>> cpuid(1, eax, ebx, ecx, std_caps); >>> >> >>> >> should be ok >>> > >>> > I don't mind the patch, but it is a compiler bug. >>> > >>> >>> Would you prefer I #ifdef'ed it for suncc only? >> >> No, that would only be if this were a significant slowdown - that doesn't >> apply here. > > Indeed, but a note in the commit message that it's a workaround for a > suncc bug would be nice. AFAIK it's the only compiler that doesn't > handle this (of those supporting gcc inline asm at all). >
Agreed. OK I will resubmit it. -- Sean McG. _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
