`asm' in natObject.cc

Mon Dec 3 11:05:00 GMT 2001

I think the memory clobber is necessary, since it's used to acquire or
release a lock. Thus gcc shouldn't move other memory operations across the
compare_and_swap, since that might move them out of the region in which the
lock is held.
To be honest, I'm not sure why the __volatile__ is needed, or whether it has
any real effect beyond the memory clobber. I think I put it there as the
result of paranoia inspired by the code in
http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/linuxthreads/sysdeps/i386/
pt-machine.h?rev=1.10&content-type=text/x-cvsweb-markup&cvsroot=glibc .
That code appantly started out with __volatile__ and then added the memory
clobber as a bug fix, going from 1.6 to 1.7.
Hans
> -----Original Message-----
> From: Andrew Haley [mailto:aph@cambridge.redhat.com]
> Sent: Monday, December 03, 2001 5:38 AM
> To: Boehm, Hans
> Cc: 'Bryce McKinlay '; 'tromey@redhat.com '; 'Java Discuss List '
> Subject: RE: `asm' in natObject.cc
>>> Boehm, Hans writes:
> > > 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.
>> That's better, I think.
>> > So far, I'm not convinced that there is anything wrong 
> with natObject.cc.
>> Neither am I.
>> What is the memory clobber for?
>> Andrew.
>