Hi Joseph, > On 23 Aug 2019, at 17:14, Joseph Myers <jos...@codesourcery.com> wrote: > > 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.
yes. That’s perfectly reasonable However, it’s more than a little disappointing that X86, for which I would hope that the psABI _was_ considered supported, remains silent on the issue so long after it arose (I guess the interested parties with $ need to sponsor some work to update it). > (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.) Indeed, I have tangled a bit with that trying to adapt libatomic to be better behaved on Darwin. > 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). agreed .. it seems highly likely for X86 as things stand - since there’s a bunch of things already out there with different ABIs baked in. > > 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). It seems to me that whatever might be chosen for the definitive psABI / platform (i.e. arch + OS + version) going forward, we will need to support what has been emitted in the past. So a recommendation for suitable FE hooks (and preferably a way to make the C11 atomic match the std::atomic, even if this is “only” a QoI issue), would be worth addressing. thanks Iain > > -- > Joseph S. Myers > jos...@codesourcery.com