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

[David Conrad]

On Jun 18, 2009, at 12:18 PM, Reimar Döffinger wrote:

> 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

I just tried it and got

gcc-4.2 -arch x86_64 -Wundef -Wdisabled-optimization -Wno-pointer-sign  
-Wdeclaration-after-statement -std=gnu99 -Wall -Wno-switch -Wpointer- 
arith -Wredundant-decls -O4 -march=core2 -mtune=core2 -pipe -ffast- 
math -fomit-frame-pointer -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 - 
D_LARGEFILE64_SOURCE -Ilibdvdread4 -mdynamic-no-pic -falign-loops=16 - 
shared-libgcc -I.  -I/opt/local/include  -I/usr/X11/include -I/opt/ 
local/include  -c -o libmpcodecs/vf_fspp.o libmpcodecs/vf_fspp.c
{standard input}:8441:32-bit absolute addressing is not supported for  
x86-64
/usr/libexec/gcc/i686-apple-darwin9/4.2.1/as: fatal error in /usr/ 
bin/../libexec/gcc/darwin/x86_64/as
make: *** [libmpcodecs/vf_fspp.o] Error 1

as the error fixed.

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

Past experience leads me to assume gcc is extremely dumb when it comes  
to inline asm, so I thought gcc would happily truncate > 32 bits if it  
chose to use "e". But a quick test indicates that gcc will complain  
about impossible constraints if you force a 64-bit constant in "e".