This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC libatomic ABI specification draft
- From: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- To: Bin Fan <bin dot x dot fan at oracle dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Cc: <nd at arm dot com>
- Date: Tue, 29 Nov 2016 11:11:58 +0000
- Subject: Re: GCC libatomic ABI specification draft
- Authentication-results: sourceware.org; auth=none
- Authentication-results: spf=none (sender IP is ) smtp.mailfrom=Szabolcs dot Nagy at arm dot com;
- Nodisclaimer: True
- References: <cbd2c83a-b50b-b2ac-b62d-b2d26178c2b1@oracle.com> <db02a1bf-0eee-15a5-0e1f-f8124021e45d@redhat.com> <a73c2aa3-31d4-05a6-19e6-f9efa98fbfe3@redhat.com> <8764e547-1dd2-3ebd-2723-6568b4b54092@oracle.com> <ac2d60ed-a659-f018-1f11-63fa8f5847f5@oracle.com> <1470412312.14544.4.camel@localhost.localdomain> <4a182edd-41a8-4ad9-444a-bf0af567ae98@oracle.com> <8317ec9d-41ad-d806-9144-eac2984cdd38@oracle.com> <c2d90b1a-0b0e-0460-d28f-a02ad15f5ab3@oracle.com>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
On 17/11/16 20:12, Bin Fan wrote:
>
> Although this ABI specification specifies that 16-byte properly aligned atomics are inlineable on platforms
> supporting cmpxchg16b, we document the caveats here for further discussion. If we decide to change the
> inlineable attribute for those atomics, then this ABI, the compiler and the runtime implementation should be
> updated together at the same time.
>
>
> The compiler and runtime need to check the availability of cmpxchg16b to implement this ABI specification.
> Here is how it would work: The compiler can get the information either from the compiler flags or by
> inquiring the hardware capabilities. When the information is not available, the compiler should assume that
> cmpxchg16b instruction is not supported. The runtime library implementation can also query the hardware
> compatibility and choose the implementation at runtime. Assuming the user provides correct compiler options
with this abi the runtime implementation *must* query the hardware
(because there might be inlined cmpxchg16b in use in another module
on a hardware that supports it and the runtime must be able to sync
with it).
currently gcc libatomic does not guarantee this which is dangerously
broken: if gcc is configured with --disable-gnu-indirect-function
(or on targets without ifunc support: solaris, bsd, android, musl,..)
the compiler may inline cmpxchg16b in one translation unit but use
incompatible runtime function in another.
there is PR 70191 but this issue has wider scope.
> and the inquiry returns the correct information, on a platform that supports cmpxchg16b, the code generated
> by the compiler will both use cmpxchg16b; on a platform that does not support cmpxchg16b, the code generated
> by the compiler, including the code generated for a generic platform, always call the support function, so
> there is no compatibility problem.