This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: [patch] Provide a can_compare_and_swap_p target hook.
- From: Andrew Haley <aph at redhat dot com>
- To: Andrew MacLeod <amacleod at redhat dot com>, Richard Biener <richard dot guenther at gmail dot com>, Richard Henderson <rth at redhat dot com>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Cc: Jeff Law <law at redhat dot com>, java at gcc dot gnu dot org
- Date: Thu, 06 Nov 2014 18:23:33 +0000
- Subject: Re: [patch] Provide a can_compare_and_swap_p target hook.
- Authentication-results: sourceware.org; auth=none
- References: <5458FE9C dot 2090409 at redhat dot com> <54590C19 dot 40208 at redhat dot com> <54591348 dot 1010904 at redhat dot com> <545913A4 dot 5010400 at redhat dot com> <54591B3A dot 8030908 at redhat dot com> <70044BE8-9F38-4BDB-B73F-6E2FC9AC2629 at gmail dot com> <54593352 dot 2000700 at redhat dot com> <545BB682 dot 9000209 at redhat dot com>
On 11/06/2014 05:57 PM, Andrew MacLeod wrote:
> It looks like java is deciding whether or not GCC can inline atomic
> operations or not, and if it can't, doesn't want the atomic
> operations... which presumably means there is no dependency on
> libatomic at runtime.
>
> A call to can_compare_and_swap_p(mode) is analogous to a compile time
> version of folding atomic_always_lock_free(mode) to a constant...
> Frankly that seems like a reasonable question for some front end to
> ask... and elect not to emit atomic calls if so desired. (which is what
> java is doing I think)
>
> whether it still needs to do that is a question for some java person.
I did it because some targets did not have library support for some
builtins, so a compile would fail with a (to a Java programmer)
baffling error message.
The Java operations certainly should use the generic builtins.
Andrew.