RE: RFH: optabs code in the java front end

I'm not up on the details here.  But I want to point out that C++0x and C1x require atomic operations on all platforms, with the expectation that they will be emulated (most likely with an address-indexed table of locks) on platforms that don't provide them.  If I understand this correctly, it sounds to me like some generalization of the Java mechanism will also be needed for C++ (and eventually C).

Hans

> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf
> Of Andrew Haley
> Sent: Sunday, September 12, 2010 10:08 AM
> To: Joseph S. Myers
> Cc: [email protected]; [email protected]
> Subject: Re: RFH: optabs code in the java front end
> 
> On 11/09/10 21:21, Joseph S. Myers wrote:
> > On Sat, 11 Sep 2010, Andrew Haley wrote:
> >
> >> The test tells us whether the back-end has atomic builtins.  If it
> doesn't
> >> then we generate calls to the libgcj back end.  I really don't want
> gcj
> >> to generate calls to nonexistent __compare_and_swap_4 or somesuch.
> >
> > Maybe not to nonexistent functions, but if the functions exist - say
> the
> > kernel-assisted libgcc functions used on Linux on SH, PA and older
> ARM
> > processors - then certainly they should be used.  So optabs are
> hardly the
> > right thing to check; if you need to know whether this functionality
> is
> > supported, you need a hook that will say whether there is a library
> > fallback when code for __sync_* isn't generated inline.
> 
> Sure, that would be nice.  However, my first goal is correctness, so
> if we end up using slower workarounds in libgcj I can live with that,
> but
> not failure to link because of missing library routines.
> 
> In the case of ARM GNU/Linux we work around the problem with a compile-
> time option, -fuse-atomic-builtins, which overrides the optabs check.
> 
> Andrew.
>