[PATCH] D125919: Drop qualifiers from return types in C (DR423)

[Richard Smith - zygoloid via Phabricator via cfe-commits]

rsmith added a comment.

In D125919#3556418 <https://reviews.llvm.org/D125919#3556418>, @aaron.ballman wrote:

> In D125919#3556319 <https://reviews.llvm.org/D125919#3556319>, @rjmccall wrote:
>
>> Now, the standard has chosen not to talk about `_Atomic` as a qualifier, I assume because there's a fair number of rules in the standard that assume that qualifiers can be freely added to pointers and don't change layout and so on, none of which apply to `_Atomic`.  But those rules also don't apply to a large number of other extended qualifiers, like address spaces and the ARC ownership qualifiers and `__ptrauth`.  The committee should probably just come to terms with the fact that it's the relatively easy-come-easy-go nature of the CVR qualifiers which is the special case.  I've thought for awhile that Clang should really be representing `_Atomic` as a qualifier instead of having to treat `AtomicType` as a special case in a million places.
>
> I'm not certain if we can get away with that. IIRC, Microsoft uses embedded locks on Windows in some circumstances. However, cl doesn't support `_Atomic` and so maybe we can get away with it on the assumption we have no other targets where the size/alignment would be different for an atomic type vs a non-atomic type?

That assumption does not hold. Given `struct A { char c[3]; };`, `struct A` has size 3 and align 1, but `_Atomic struct A` has size 4 and align 4 across many (perhaps all?) of our targets. (This is an ABI divergence between GCC and Clang, which as far as I know the psABI owners have so far not succeeded in resolving.)

I saw some talk in WG14 of separating `_Atomic(T)` and `_Atomic T` so that `_Atomic T` would be a qualifier that doesn't affect size or alignment, only what code is generated to access the value, and `_Atomic(T)` would be a distinct type with potentially a different representation in order to support lock-free atomic access. Did that go anywhere? (I'd assume not, it seems to be at least a decade too late for such an idea.)


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D125919/new/

https://reviews.llvm.org/D125919