[FFmpeg-devel] r9017 breaks WMA decoding on Intel Macs
Tue May 29 20:56:55 CEST 2007
On Tue, 29 May 2007, matthieu castet wrote:
> Zuxy Meng wrote:
>>> addl $4, %ebx
>>> movaps (%eax), %xmm0
>>> movaps 16+(%eax), %xmm4
>>> movlps (%ecx), %xmm1
>>> movlps 8+(%ecx), %xmm5
>> Actually gcc -S can't help diagnostic here: we don't know how
>> "16+(%eax)" will be assembled so you should have done an 'objdump -d'
>> I'm sorry I don't access to any OS X boxes so I can't really help you
>> much in shooting down the problem although it's me who introduced this
>> regression. I hope you don't feel annoyed.
> It's may be a stupid question, but why can't we use "movaps -16%0,
> %%xmm4 \n\t" instead of "movaps -16%0, %%xmm4 \n\t" ?
> It seems to generate the correct thing for me.
What if %0 already has an offset? It's an "m" constraint, so any
addressing mode is allowed, e.g. 8(%edx)
-16%0 = -168(%edx)
-16+%0 = -16+8(%edx) = -8(%edx)
gcc devs must have intended to let one offset a memory address, there's
even a "o" (offsettable) constraint (which is identical to "m" on x86).
But I can't find any syntax for an offset that won't generate a warning
some of the time.
More information about the ffmpeg-devel