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: pgsql-ports(at)postgresql(dot)org, martin(at)piware(dot)de, Peter Eisentraut <peter_e(at)gmx(dot)net>
Subject: Re: Build failure on m68k and ia64: inconsistent operand constraints in an `asm'
Date: 2004-06-10 19:15:31
Message-ID: 3030.1086894931@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-ports

Martin Pitt <martin(at)piware(dot)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

In response to

Responses

Browse pgsql-ports by date

  From Date Subject
Next Message Martin Pitt 2004-06-13 08:22:52 Re: Build failure on m68k and ia64: inconsistent operand constraints in an `asm'
Previous Message Martin Pitt 2004-06-10 10:26:19 Re: Build failure on m68k and ia64: inconsistent operand constraints in an `asm'