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.
