Sean McGovern <[email protected]> writes: > 2011/11/7 Sean McGovern <[email protected]>: >> Hi folks, >> >> I wanted to summarize the current status of the Solaris Studio FATE build as >> I know the output can sometimes be overwhelming, particularly with V=1 set. >> I've been focussing more of my time recently on assisting with gcc 4.7 on >> Solaris. >> >> The following errors in the build are the most immediately apparent: >> >> 1. libavcodec/h264_cabac.c: it seems to be puking on the >> decode_significance* stuff in x86/h264_i386.h. It's currently conditionally >> compiled with an #if ARCH_X86 && HAVE_7REGS && !defined(BROKEN_RELOCATIONS), >> should it actually be ARCH_X86_32, or should this work equally well on >> 64-bit? > > This looks to have been fixed. Thank you very much, Mans. :)
Yeah, I got rid of the 'a' modifiers in the operand substitutions. >> 2. libavcodec/motion_est.c: not too sure on this one yet -- the compiler >> complains about "invalid instruction argument" in the generated assembly, >> I'm thinking it may have some correlation to the x86/mathops.h "impossible >> constraint" warnings peppered through the build logs. > > I have at least discovered what is going on here -- but am totally > unsure of how to fix it. > > motion_est uses a macro from x86/mathops.h called COPY3_IF_LT. > According to > http://blogs.oracle.com/x86be/entry/gcc_style_asm_inlining_support Scary stuff. Suncc inline asm is actually _incompatible_ with gcc, not just incomplete. The linked document says this about substitution modifiers: Type letter Register size b 8-bits h 16-bits l 32-bits q 64-bits For gcc: b -- print the QImode name of the register for the indicated operand. %b0 would print %al if operands[0] is reg 0. w -- likewise, print the HImode name of the register. k -- likewise, print the SImode name of the register. q -- likewise, print the DImode name of the register. h -- print the QImode name for a "high" register, either ah, bh, ch or dh. Note the difference in meaning of the 'h' modifier. > , Solaris Studio does not have the same level of heuristics when > choosing registers for inline assembly. The COPY3_IF_LT macro has 6 > arguments, and the last 2 are put into rcx and rdx on 64-bit x86. So > in the macro expansion, we get: > > cmpl %eax,%ebx > cmovl %ebx,%eax > cmovl %ebp,%rcx > cmovl %esi,%rdx > > which is incorrect. GNU GAS would have "heuristically" fixed the last > 2 instructions (or the whole inline asm block) up using cmpq & cmovq > with the proper 64-bit registers %rbp and %rsi I *think* -- can > someone provide me the asm dump from 64-bit x86 linux to confirm?. Not quite. Some of these arguments are integer constants, and gcc puts those in 32-bit registers while suncc (apparently) uses 64-bit registers for constant operands with and "r" constraint. Try this patch: diff --git a/libavcodec/x86/mathops.h b/libavcodec/x86/mathops.h index 50b0283..e1e7ccb 100644 --- a/libavcodec/x86/mathops.h +++ b/libavcodec/x86/mathops.h @@ -95,7 +95,7 @@ __asm__ volatile(\ "cmovl %4, %1 \n\t"\ "cmovl %5, %2 \n\t"\ : "+&r" (x), "+&r" (a), "+r" (c)\ - : "r" (y), "r" (b), "r" (d)\ + : "r" (y), "r" ((int)b), "r" ((int)d)\ ); #endif -- Måns Rullgård [email protected] _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
