This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
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: java-owner@gcc.gnu.org [mailto:java-owner@gcc.gnu.org] On Behalf
> Of Andrew Haley
> Sent: Sunday, September 12, 2010 10:08 AM
> To: Joseph S. Myers
> Cc: gcc@gcc.gnu.org; java@gcc.gnu.org
> 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.
>