RFH: optabs code in the java front end

Sun Sep 12 17:08:00 GMT 2010

On 11/09/10 21:21, Joseph S. Myers wrote:
> On 2010年9月11日, 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.