`asm' in natObject.cc

Sun Dec 2 18:31:00 GMT 2001

> From: Bryce McKinlay

> I'm guessing that its a libgcj bug, but a g++ bug that it doesn't get 
> reported at -O2. I'm no "asm" expert, but this fixed it for me:

The "0" constraint specifies that the input argument must be in the same
location as the zeroth output operand. This is very similar to one of the
examples in the gcc manual. (See
http://gcc.gnu.org/onlinedocs/gcc_6.html#SEC117.) This seems more accurate
to me than the patched version. The manual suggests that it would also be
OK to use "+m" instead of "=m" as the constraint for the 0th operand, and
then delete the second mention of (*addr)). If we need a workaround, I
think that would be preferable.
So far, I'm not convinced that there is anything wrong with natObject.cc.
It would be nice if g++ at least generated a more informative message.
Hans

> Index: natObject.cc
> ===================================================================
> RCS file: /cvs/gcc/gcc/libjava/java/lang/natObject.cc,v
> retrieving revision 1.20
> diff -u -r1.20 natObject.cc
> --- natObject.cc 2001年10月31日 00:48:16 1.20
> +++ natObject.cc 2001年12月02日 04:52:01
> @@ -328,7 +328,8 @@
> char result;
> __asm__ __volatile__("lock; cmpxchgl %2, %0; setz %1"
> : "=m"(*(addr)), "=q"(result)
> - : "r" (new_val), "0"(*(addr)), "a"(old) : "memory");
> + : "r" (new_val), "m"(*(addr)), "a"(old)
> + : "memory");
> return (bool) result;
> }

> I think it is complaining about "*(addr)" not having the same set of 
> constraints each time it is used.