rjmccall added a comment. > I disagree with the assessment that _Atomic behaves exactly like a qualifier. > It *should* (IMHO), but it doesn't. C allows the size and alignment of an > atomic type be *different* from its unqualified version, to allow for > embedded locks and such. Because the size and alignment can be different, to > my mind, _Atomic int and int are different types in the same way as _Complex > float and float -- the object representations can (must, in the case of > _Complex) be different, so they're different types. The same is not true for > const, volatile, or restrict qualifiers -- those are required to have the > same size and alignment as the unqualified type.
I think our apparent disagreement here is rooted in something quite simple: you seem to be assuming that a qualified type by definition cannot have a different size and alignment from the unqualified type, and I think that's a property that's *guaranteed* for the CVR qualifiers and merely *happens to be true* for our current set of extended qualifiers, and only really because we don't represent `_Atomic` as a qualifier. Many of our extended qualifiers completely change the ABI of the type they qualify, and they can change the basic semantic properties of types they're nested within. I don't see why we'd draw a line here about what counts as a qualifier and what doesn't. ObjC ARC happens to implement `__weak` references without using extra inline storage, but it would certainly be a reasonable ABI choice to make them larger than just a pointer — Swift does with its native weak references, for example. That ABI choice wouldn't make `__weak` suddenly not a qualifier. > 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.) That seems like a terrible 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
