Re: [Gc] Re: Patch ping (boehm-gc)

[Michael Meissner <meissner at linux dot vnet dot ibm dot com>]

On Fri, Jul 17, 2009 at 07:36:30PM +0000, Boehm, Hans wrote:
> The situation here seems a bit messy, in that the upstream GC code is quite different (it uses libatomic_ops), but superficially it looks to me like that has similar issues.  You might check http://bdwgc.cvs.sourceforge.net/viewvc/bdwgc/bdwgc/libatomic_ops-1.2/src/atomic_ops/sysdeps/gcc/powerpc.h?revision=1.8&view=markup

I looked at it, and it looks like it fixes the problem by using the "r"
constraint instead of the "p" constraint.  The bug is in using the "p"
constraint allows reg+reg or reg+offset addressing, but the insn as used is
only expecting a single register.

> I'm still behind with the upstream patches, but I don't recall one that fixes
> this.  If it's not fixed there, this is likely to get broken again in the
> future.
> 
> Has gcc supported %y for a long time?  One concern is that the upstream
> version often gets used with ancient compilers.  Thus compatibility with old
> gcc versions is much more of a concern than for the version in the gcc tree.

%y came in in 2001 when Aldy added the initial altivec support.  However, it is
probably safer to use the r constraint, like you have in the upstream patches.

It would be a good idea to add support using the GCC __sync builtins if you are
building with GCC 4.4 or later, that way you don't have to go mucking about
with asm.  Unfortunately, when they added the __sync builtins, they didn't add
macros to say whether a machine supports a particular function or not.

In my code that was:

#     if (__GNUC__>4)||((__GNUC__==4)&&(__GNUC_MINOR__>=4))
#       define GC_test_and_set(addr) __sync_lock_test_and_set (addr, 1)
#       define GC_clear(addr) __sync_lock_release (addr)

-- 
Michael Meissner, IBM
4 Technology Place Drive, MS 2203A, Westford, MA, 01886, USA
meissner@linux.vnet.ibm.com