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

Arsen Arsenović <[email protected]> Mon, 29 Jun 2026 13:32:27 +0200

Newsgroups	gmane.comp.gcc.patches,gmane.comp.gcc.devel
Organization	BayLibre
Message-ID	<[email protected]>

Joseph Myers <[email protected]> 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.
-- 
Arsen Arsenović

signature.asc (application/pgp-signature, 430 B)