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

Joseph Myers <[email protected]> writes:

> 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.)

That's true; it would convolute the implementation somewhat.

Then, maybe, making 'includes_p' (the predicate that was checking
whether QS1 includes all qualifiers of QS2) actually be called
usable_as_p or such, and having it reject TYPE_QUAL_ATOMIC differences
makes sense?  (I'd prefer a better name, because 'usable as' sounds like
it implies a NOP_EXPR suffices for conversion, but that may not be true
due to address spaces, but I'm coming up blank)

Given this special nature of TYPE_QUAL_ATOMIC, I'm not sure in which
cases it would be applicable to have a "pure" includes predicate.

What do you think?
-- 
Arsen Arsenović

-----BEGIN PGP SIGNATURE-----

iQEKBAEWCgCyFiEE/uKz0RP8AKMWLWBhUsKUMB6ixJMFAmpDxD8bFIAAAAAABAAO
bWFudTIsMi41KzEuMTIsMiwyXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25z
Lm9wZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGRUUyQjNEMTEzRkMwMEEzMTYyRDYw
NjE1MkMyOTQzMDFFQTJDNDkzGBxhYXJzZW5vdmljQGJheWxpYnJlLmNvbQAKCRBS
wpQwHqLEkxD2AP9fqQYG43ZMQjjQHitK38JXiqytxoYHGzq89lAsp9xRRAD/RqL1
2pzHz2gd8pbjixHYJuW8k8qtGh7ZCFVvzehv9gg=
=/3cA
-----END PGP SIGNATURE-----