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

Re: Build failure on m68k and ia64: inconsistent operand

From: Roman Zippel <zippel(at)linux-m68k(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Martin Pitt <martin(at)piware(dot)de>, pgsql-ports(at)postgresql(dot)org
Subject: Re: Build failure on m68k and ia64: inconsistent operand
Date: 2004-06-13 23:06:49
Message-ID: Pine.LNX.4.58.0406132124390.13079@scrub.local (view raw or flat)
Thread:
Lists: pgsql-ports
Hi,

On Sun, 13 Jun 2004, Tom Lane wrote:

> 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 ;-).

But even Linus can't change the facts (if you follow the discussion, 
you'll notice that he doesn't even try), that gcc cannot guarantee that 
one memory expression is identical with another one without a reload into 
a different location what would break the atomic behaviour which is needed 
by many asm inline instructions (which is btw not documented either and 
without it the asm at hand wouldn't work at all), so newer gcc releases 
don't even pretend to do this anymore.

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

He is a leading gcc developer and Linus does take his "claim" as 
authoritative. Please take this to the gcc developers, but don't leave 
certain machines broken.

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

"+m" does work too, but gcc 3.4.0 will produce a warning for this (it's 
fixed in 3.4.1, that simply will internally produce "=m"/"m" for this) 
and it's doesn't work with gcc older than 2.95. (I don't know the compiler 
requirements of postgresql).
Where is the problem with changing it simply into "=m"/"m"? It is a 
correct solution, if something is wrong with it, so would it be for "+m" 
or "=m"/"0", so I'm a bit puzzled what you're trying to discuss here...

bye, Roman

In response to

pgsql-ports by date

Next:From: Stergios ZissakisDate: 2004-06-22 14:32:08
Subject: Problems compiling on Solaris 5.7 (7)
Previous:From: Tom LaneDate: 2004-06-13 17:38:43
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