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-ow...@gcc.gnu.org [mailto:java-ow...@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; j...@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. >
