[MPlayer-cvslog] r29352 - trunk/libmpcodecs/vf_fspp.c

[Reimar Döffinger]

On Sun, Jun 07, 2009 at 08:02:23PM -0400, David Conrad wrote:
> On Jun 7, 2009, at 10:53 AM, Reimar Döffinger wrote:
>> On Sun, Jun 07, 2009 at 05:48:53PM +0300, Uoti Urpala wrote:
>>> On Sun, 2009-06-07 at 16:42 +0200, gpoirier wrote:
>>>> replace "g" asm constraint by "erm" since "g" allows 64bit  
>>>> immediates while
>>>> the operator (cmp) using the "g"-constrained operand doesn't  
>>>> support 64bit
>>>> immediates.
>>>
>>>> -	: "m" (width), "m" (src_stride), "g" (od), "m" (dst_stride), "g" 
>>>> (end),
>>>> +	: "m" (width), "m" (src_stride), "erm" (od), "m" (dst_stride),  
>>>> "erm" (end),
>>>
>>> Only "end" is used with cmp, not "od".
>>
>> As I understood it (in which case the commit message is wrong), Apple
>> gcc just does not allow "g" for 64 bit variables/values.
>
> The opposite - "g" works fine for 64 bit variables/values/immediates,  
> but cmp doesn't support a 64-bit immediate (Intel's manual says cmp r/ 
> m64, imm32 at best.)
>
> Apple's gcc happens to choose to use an immediate; I'm guessing that FSF 
> gcc chooses to use a register instead (both of which are valid for "g")

Well, I'll have to look at the report again, but it seemed to me that the error
was from the C compiler, not the assembler, which IMO invalidates this explanation
and is the reason why I concluded the compiler stupidly does "g" + 64 bit pointer = error

> Also it seems like this won't work if dither is given an address > 32  
> bits since REG_d is rdx; and changing it to edx wouldn't work if gcc  
> chose to use "r" or "m" (since I think those would be implied to be 64  
> bit.)

Huh? If dither is given and address > 32 bit the address of "end" obviously
isn't a 32 bit constant, so where is the issue supposed to be?