On Mon, 29 Jun 2026, Martin Uecker via Gcc wrote: > Yes, atomic as specified should not be a qualifier. It is a mess both > from a standardization and also from an implementation point of view. > And with my "user hat" on, I can say it is also a pain because it > prevents the use of standard atomics in many applications.
I suspect it *should* be a qualifier (that's not an access qualifier) in the standard - that making it such would mean fewer special cases referring to "atomic, qualified or unqualified" and similar than you get at present with it not being a qualifier but having qualifier-like properties regarding not being possible for rvalues. In implementation terms, not being a qualfier would mean that everything that checks for a particular kind of type (e.g. POINTER_TYPE) would suddenly be more complicated because of needing to check for being an atomic type wrapper round that kind of type as well. (We do already have some awkward cases like that. For example, enumerations with fixed underlying type bool need checking for everywhere concerned with the special semantics of conversion to bool - but if atomic types were no longer represented as qualifiers, suddenly you get the extra complication that first you need to remove atomic, then move from enumeration to underlying type, and only then check for a boolean type. The standard text has a similar issue of not having any convenient term for "integer type that behaves like bool" - or for that matter for signed-behavior and unsigned-behavior types.) -- Joseph S. Myers [email protected]
