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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
