Re: Build failure on m68k and ia64: inconsistent operand constraints in an `asm' - Mailing list pgsql-ports

From Tom Lane
Subject Re: Build failure on m68k and ia64: inconsistent operand constraints in an `asm'
Date
Msg-id 3030.1086894931@sss.pgh.pa.us
Whole thread Raw
In response to Build failure on m68k and ia64: inconsistent operand constraints in an `asm'  (Martin Pitt <martin@piware.de>)
Responses Re: Build failure on m68k and ia64: inconsistent operand constraints in an `asm'  (Martin Pitt <martin@piware.de>)
List pgsql-ports
Martin Pitt <martin@piware.de> writes:
> A Debian porter suggested that "1"(*lock) is an obsolete syntax and
> should be replaced by "m"(*lock) in both cases; however, I would like
> to get a second opinion about this.

Having now re-read the gcc asm info, I think the above suggestion is
completely wrong.  I looked at gcc 2.95, 3.2, and 3.3.4 texinfo
documentation (the versions I have handy) and they all say exactly
the same thing:

: Only a number in the constraint can guarantee that one operand will
: be in the same place as another.  The mere fact that `foo' is the value
: of both operands is not enough to guarantee that they will be in the
: same place in the generated assembler code.

There is no hint that using a number is deprecated or might go away
in the future.

There is a mention that "+" is an alternative syntax for specifying
read-write operands, but considering that none of our ports have
ever used this, I do not know what sorts of problems we might be in for
if we switch over to that approach.  We will definitely risk breakage
if we don't have any constraint that the spinlock input and output values
are the same operand.

I think Debian broke their compiler and they ought to un-break it.

            regards, tom lane

pgsql-ports by date:

Previous
From: Martin Pitt
Date:
Subject: Re: Build failure on m68k and ia64: inconsistent operand constraints in an `asm'
Next
From: Martin Pitt
Date:
Subject: Re: Build failure on m68k and ia64: inconsistent operand constraints in an `asm'