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