[RFC TREE-WIDE] gcc: stop using 'int' to represent sets of qualifiers

[Martin Uecker]

Am Montag, dem 29.06.2026 um 13:32 +0200 schrieb Arsen Arsenović:
> Joseph Myers <josmyers@redhat.com> writes:
> 
> > Note that there is an active discussion in WG14 of possibly
> > introducing the term "access qualifier" for const / volatile /
> > restrict, with a view to integrating named address spaces into the C
> > standard.
> 
> Ah, that seems useful.
> 
> > _Atomic is only syntactically a qualifier in the C standard, not 
> > semantically, although of course in implementation terms it's like const / 
> > volatile / restrict to the extent that it's either present or absent on a 
> > type.  It's possible that if the "access qualifier" concept is introduced, 
> > it would make sense to redefine _Atomic in the C standard as being a 
> > qualifier that's not an access qualifier; it has the property of 
> > qualifiers that it has no meaning for rvalues, but not the access 
> > qualifier properties that the layout is the same as for the unqualified 
> > type (_Atomic can increase size and alignment) or, thus, that it's safe to 
> > convert a pointer to one to a more-qualified type.  (Hence various places 
> > that use e.g. TYPE_QUALS_NO_ADDR_SPACE_NO_ATOMIC because they want to deal 
> > with access qualifiers only.)
> 
> Likewise I imagine address spaces wouldn't be an access qualifier, if
> those get added.
> 
> But, address space qualifiers can, sometimes, participate in implicit
> conversion.   T AS1* can implicitly convert into T AS2* if AS1 is a
> superset of AS2.
> 
> But, this certainly means that I was wrong in saying:
> 
>   /* Returns true if qualifiers in SUBSET are completely included in SUPERSET.
>   
>      In general, this means that an object qualified per SUBSET can be used as if
>      it was qualified per SUPERSET safely (e.g. 'T' as 'const T', or 'const T' as
>      'const volatile AS1 T', presuming that AS1 is a superset of the generic
>      address space).  */
>   bool quals_includes_p (qualifier_set superset, qualifier_set subset);
> 
> ... as that isn't true if _Atomic is involved.
> 
> On further reflection, it is a bit strange to have TYPE_QUAL_ATOMIC.
> Perhaps it'd make more sense to have an ATOMIC_TYPE type constructor,
> where a (possibly cvr-AS-qualified) ATOMIC_TYPE wraps an unqualified
> type.  I mostly don't look at the C standard too much, but ISTM at a
> glance that _Atomic is much more similar to a type constructor than a
> qualifier generally.
> 
> TYPE_ATOMIC is used in ~70 locations, so it may be a doable change.
> 
> Note that the C++ FE never uses TYPE_ATOMIC.

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.

It would be really useful to have a true atomic qualifier where the
qualified type is ABI-compatible to the unqualified (same representatio
and alignment), but this probably would need a new qualifier to avoid
breaking changes.

Martin