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 jos...@codesourcery.com
