Skip site navigation (1) Skip section navigation (2)

Re: Build failure on m68k and ia64: inconsistent operand constraints in an `asm'

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Martin Pitt <martin(at)piware(dot)de>
Cc: pgsql-ports(at)postgresql(dot)org, Roland Zippel <zippel(at)linux-m68k(dot)org>
Subject: Re: Build failure on m68k and ia64: inconsistent operand constraints in an `asm'
Date: 2004-06-13 17:38:43
Message-ID: 26524.1087148323@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-ports
Martin Pitt <martin(at)piware(dot)de> writes:
> On 2004-06-11 10:10 +0200, Roman Zippel wrote:
>> gcc developers disagree, we had same problem with the kernel, e.g. see:
>>
>> http://marc.theaimsgroup.com/?l=3Dlinux-kernel&m=3D107475162200773&w=3D2

Yeah, and notice who he's arguing with ;-).

I'm with Linus on this one.  Every version of the gcc asm documentation
that I've looked at says I *must* use a match constraint to ensure that
input and output operands are in the same location.  I'm not inclined to
take one person's claim to the contrary as authoritative, especially not
when his argument is based on a statement about lvalues that isn't in
the docs at all.

BTW, if I read this message correctly, it's also saying that "+m"(*lock)
wouldn't work, which moves it out of the realm of reasonability
altogether.  Why in the world would an asm facility not support the
concept of a read-write operand in memory?

I was about to propose switching over to "+m" on the basis of some
advice I'd gotten internally at Red Hat, but now I think I will sit and
wait until some gcc developer shows me updated documentation that
actually explains what they think asm code should look like.

			regards, tom lane

In response to

Responses

pgsql-ports by date

Next:From: Roman ZippelDate: 2004-06-13 23:06:49
Subject: Re: Build failure on m68k and ia64: inconsistent operand
Previous:From: Martin PittDate: 2004-06-13 08:22:52
Subject: Re: Build failure on m68k and ia64: inconsistent operand constraints in an `asm'

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group