This is the mail archive of the
mailing list for the GCC project.
Re: gcc vs clang for non-power-2 atomic structures
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Iain Sandoe <idsandoe at googlemail dot com>
- Cc: Jonathan Wakely <jwakely dot gcc at gmail dot com>, Jim Wilson <jimw at sifive dot com>, GCC Development <gcc at gcc dot gnu dot org>
- Date: Fri, 23 Aug 2019 16:14:25 +0000
- Subject: Re: gcc vs clang for non-power-2 atomic structures
- Ironport-sdr: ycECLODs1D1wmeP4UpgZLoiPnbQeUQsknoAQM2kbhmInhyEMVv8ZsttGCLXIUTZrRXbccnJLtO 9NI2z7K/nLAuj4Y50suwIkW1B1nxdNeROhSTA/wF4bN1iAQbgoP+LoBXDoErBAUq8qWy77DywT pT9vCtERY7VmAlEhp39VDpmMZvd+OGaj3I6J/HJPxr5QTMS5q4n/g5iaAoDUsMAs8E8xSYeo9J ANLag+PfqC9LhzpwYqX2fo6hpYoppYhzzqeV3I+3xw6Rsgnoc/LQLRW+c9RAW5P+0NwHtEwMjy CBI=
- Ironport-sdr: OWWo3CALZWx4jPNoj/s62LxhWpjEXnxXKs4ciiiP7EUGQIOd2alfNzquQf1ZdN37OStpK1cQlc INC6uFA3A1NV/0H34KxLFOJcnYTW6+GeHqcA0dKrAXIUs0GLx78thFbupdXLl95xpC+B9+hmTu tSBcRSnXZ8Zbw1sQEYM6+61zH+oGzbv52YqsxJDpiX1SejgrZNrcG6/rzSvZmtKRfQCkGA5gMJ LokAlWctk5m1fSdzMRyzKyshVFHTvVDRu9O+68HFHjBG7Nw7AeFQDc95tqgsmLpwPQAZo19G27 u7c=
- References: <CAFyWVaZq1zxqvPrre0630iNuk9-9O9iTBAae2eazjQ8Hcup94A@mail.gmail.com> <4B203FA6-1E0F-4DA2-B86E-D51A0105138E@googlemail.com> <CAH6eHdTe3jAUgP7WZYOtbmnubB6=V1mMVKe7cac-+gD+sZOh6w@mail.gmail.com> <1B1B7543-E830-43C6-B996-7FE51E4540E1@googlemail.com>
On Fri, 23 Aug 2019, Iain Sandoe wrote:
> absolutely, it’s the psABI that’s lacking here - the compilers (as commented
> by Richard Smith in a referenced thread) should not be making ABI up…
With over 50 target architectures supported in GCC, most of which probably
don't have anyone maintaining a psABI for them, you don't get support for
new language features that require an ABI without making some reasonable
default choice that allows the features to work everywhere and then
letting architecture maintainers liaise with ABI maintainers in the case
where such exist.
(ABIs for atomics have the further tricky issue that there can be multiple
choices for how to map the memory model onto a given architecture; see
<https://www.cl.cam.ac.uk/~pes20/cpp/cpp0xmappings.html>. So it's not
just a matter of type sizes and alignment.)
There *is* a clear GCC bug (bug 65146) in the specific case of _Atomic
long long / _Atomic double in structures on 32-bit x86; those need to be
forced to 8-byte alignment when atomic as they are outside structures.
Size / alignment for _Atomic versions of types whose size isn't (2, 4, 8,
16) bytes is another matter; the GCC default (don't change size /
alignment when making atomic) seems perfectly reasonable, but where psABIs
specify something we do of course need to follow it (and the choice may be
OS-specific, not just processor-specific, where the ABI is defined by the
default compiler for some OS).
Note: it's likely some front-end code, and stdatomic.h, might have to
change to handle the possibility of atomic types being larger than
non-atomic, as those end up using type-generic atomic load / store
built-in functions, and those certainly expect pointers to arguments of
the same size (when one argument is the atomic type and one non-atomic).
Joseph S. Myers