[FFmpeg-devel] r9017 breaks WMA decoding on Intel Macs

[Loren Merritt]

On Tue, 29 May 2007, matthieu castet wrote:
> Zuxy Meng wrote:
>>
>>> L32:
>>>       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'
>> instead.
>>
>> 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.

--Loren Merritt