This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gcc vs clang for non-power-2 atomic structures


Hi Joseph,

> On 23 Aug 2019, at 17:14, Joseph Myers <joseph@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
> joseph@codesourcery.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]