This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: RFH: optabs code in the java front end
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Andrew Haley <aph at redhat dot com>
- Cc: gcc at gcc dot gnu dot org, java at gcc dot gnu dot org
- Date: Sat, 11 Sep 2010 20:21:05 +0000 (UTC)
- Subject: Re: RFH: optabs code in the java front end
- References: <AANLkTinHc64kSLFEdwD+qzrZFZMQxHtV5PNDnfVh0wKV@mail.gmail.com> <4C8BCF0F.1070104@redhat.com>
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.
--
Joseph S. Myers
joseph@codesourcery.com