Am Mittwoch, den 10.02.2021, 18:51 +0000 schrieb Joseph Myers:
> On Wed, 10 Feb 2021, Uecker, Martin via Liaison wrote:
>
> > > Whatever system you might add for atomic operations on non-atomic data, I
> > > think making the syntactic-qualifier _Atomic into something semantically a
> > > qualifier would be an unreasonably incompatible way of adding such a
> > > feature.
> >
> > A qualifier is exactly what is needed if you want to
> > express atomic operations on non-atomic data as it has
> > exactly the right right semantics. Qualifiers affect
>
> You need the various *operations* from stdatomic.h in forms that can be
> applied to non-atomic data.

I am not sure I understand what you mean.

On a fundamental level on architectures supported by C there
is no atomic or non-atomic memory. Only accesses are atomic or
not (this is why a qualifier is a natural choice for "lockless"
accesses). So having the qualifier would imply atomic accesses
and not having the qualifier would imply accesses which may
be not atomic. We support atomic for all types, so we need
a fallback mechanism if the hardware can not do a "lockless"
access.

But I probably missed your point.

> Whether you need to be able to use the cases
> of direct assignment implying seq_cst for atomic accesses to non-atomic
> data, or just the operations in stdatomic.h, seems less clear to me.
>
> (I realise that some things that can be done with direct assignment
> operators have no corresponding stdatomic.h operations; for example,
> atomic compound assignment for floating-point types with all the
> corresponding implications for handling floating-point exception state.
> However, such operations could be added to stdatomic.h, so allowing an
> explicit memory order to be specified, independent of any way to apply
> atomic operations to non-atomic data.)
>
> > If the problem is only alignment, then I think this could
> > be made backwards compatible (as pointed out in my
> > other email).
>
> Alignment differences imply size differences once you include the atomic
> object into a larger struct.

A struct having an atomic member is not compatible to the
same struct having the corresponding type as non-atomic
member. So adding some padding and increasing the size
of the struct would still be ok for a compiler to do
even when we required T and _Atomic T to have the same
representation. Such structs could then stay compatible.

> (And I think some implementations may e.g.
> enlarge _Atomic struct { char x[3]; } to 4 bytes, adding padding in order
> to increase its alignment.)

Yes, some change size and alignment of this struct.
But this is incompatible to others. So some compilers
need to make an ABI breaking change anyway. If we
required _Atomic T and T to have the same
representation then this ABI is fixed and it clear
what needs to be changed. If not, somebody else
needs to decide which is the right ABI. Apparently
nobody did this in the last decade.

Best,
Martin