[MPlayer-cvslog] r29352 - trunk/libmpcodecs/vf_fspp.c
Reimar.Doeffinger at gmx.de
Thu Jun 18 18:18:24 CEST 2009
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
>>>> - : "m" (width), "m" (src_stride), "g" (od), "m" (dst_stride), "g"
>>>> + : "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
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?
More information about the MPlayer-cvslog