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.