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. :)

> 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
, 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?.

Anyone have any ideas? I'm still an extreme novice when it comes to
x86 assembly.

-- Sean McG.
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to