Re: [RFC] Proposal for tagged_by attribute to describe union discriminators

Am Dienstag, dem 28.07.2026 um 08:31 +0200 schrieb Richard Biener:
> On Tue, Jul 28, 2026 at 1:20=E2=80=AFAM Ashton Warner via Gcc <[email protected]=
u.org> wrote:
> >=20
> > On Thu, Jul 16, 2026 at 09:59:26AM +0200, Martin Uecker wrote:
> > > Am Donnerstag, dem 16.07.2026 um 09:17 +1200 schrieb Ashton Warner vi=
a Gcc:
> > > > Hello,
> > > >=20
> > > > I would like to discuss the possibility of adding a GCC attribute f=
or
> > > > describing tagged unions (discriminated unions) to improve static
> > > > analysis diagnostics.
> > > >=20
> > > > The motivation is to allow programmers to explicitly describe a
> > > > relationship between an enum discriminator and a union member. C ha=
s a
> > > > common pattern of representing variants using a struct containing a=
n
> > > > enum and a union:
> > > >=20
> > > > enum num_type {
> > > >   T_INT,
> > > >   T_FLOAT,
> > > > };
> > > >=20
> > > > struct number {
> > > >   enum num_type type;
> > > >=20
> > > >   union {
> > > >     int ival;
> > > >     float fval;
> > > >   };
> > > > };
> > > >=20
> > > > I propose the GCC attribute __attribute__((tagged_by(...))) with th=
e
> > > > following syntax:
> > > >=20
> > > > tagged_by(discriminator, mapping-list)
> > > >=20
> > > > where:
> > > >=20
> > > > - discriminator is an identifier
> > > > - mapping-list is a comma-separated list of one or more mappings.
> > > > - Each mapping has the form:
> > > >     (enumerator, union-member)
> > > >=20
> > > > For example:
> > > >=20
> > > > struct number {
> > > >   enum num_type type;
> > > >=20
> > > >   union {
> > > >     int ival;
> > > >     float fval;
> > > >   } __attribute__((tagged_by(type,
> > > >     (T_INT, ival),
> > > >     (T_FLOAT, fval)
> > > >   )));
> > > > };
> > > >=20
> > > > The mapping is intentionally explicit rather than inferred from the
> > > > declaration order of enum values and union members. This avoids
> > > > changing the meaning of the attribute if either the enum or union
> > > > members are reordered.
> > > >=20
> > > > The attribute does not change the representation or runtime behavio=
ur
> > > > of the union. It provides additional information that GCC can use f=
or
> > > > diagnostics and static analysis.
> > > >=20
> > > > For example:
> > > >=20
> > > > struct number n;
> > > >=20
> > > > n.type =3D T_INT;
> > > > n.fval =3D 1.0f;
> > > >=20
> > > > could produce a diagnostic because fval is not the member associate=
d
> > > > with the current discriminator value.
> > > >=20
> > > > The implementation should diagnose invalid mappings, such as an
> > > > enumerator that is not part of the discriminator's enum type or a
> > > > member that does not exist in the union.
> > > >=20
> > > > The attribute is intended to provide semantic information in a simi=
lar
> > > > way to existing attributes such as counted_by, where the compiler i=
s
> > > > given information about a relationship that already exists in the
> > > > program.
> > > >=20
> > >=20
> > > I agree with this proposal.  There is an existing enhancement
> > > request: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D112840
> > >=20
> > > I like an attribute on the member more than the attribute on the
> > > union type.
> > >=20
> > > > Open questions:
> > > >=20
> > > > - How should enumerators without an associated union member be
> > > >   represented? One possibility is allowing a mapping without a memb=
er,
> > > >   for example (T_UNKNOWN), to explicitly indicate that an enumerato=
r
> > > >   represents a valid discriminator state with no active union membe=
r.
> > > >   Enumerators that are not mentioned in the attribute could then be
> > > >   diagnosed.
> > > > - Should diagnostics based on this attribute be implemented as part=
 of
> > > >   existing warning infrastructure, -fanalyzer, or another analysis
> > > >   pass?
> > > > - Could this information be useful to future runtime checking tools=
?
> > >=20
> > > Yes, I think this would be useful for checking at run-time similar
> > > to sanitizers.  This would be easy to implement.
> > >=20
> > > > - Are there existing GCC mechanisms that overlap with this
> > > >   functionality?
> > > > - Are there additional constraints or semantics that would be neede=
d
> > > >   for GCC to implement this attribute?
> > >=20
> > > The issue similar to counted_by are the exact semantics for when
> > > the constraints are in effect relative to when the members are
> > > accessed / changed.
> > >=20
> > > Martin
> >=20
> >=20
> > > I agree with this proposal.  There is an existing enhancement
> > > request: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D112840
> > >=20
> > > I like an attribute on the member more than the attribute on the
> > > union type.
> >=20
> > This proposal looks interesting and more readable than my initial
> > proposal. The one semantics that is missing from this proposal is a
> > system to allow the user to be notified when a union field does not
> > contain a tag, or when there is no field for a given enum value.
> >=20
> > Would an attribute that enables warning on these issues be achievable?
> >=20
> > An example of this attribute
> >=20
> > struct number {
> >   enum num_type type;
> >=20
> >   union {
> >     int ival __attribute__((guard(.type =3D=3D T_INT));
>=20
> I also think that attributes on the individual fields are better, but pos=
sibly
> combined with an attribute on the union?
>=20
>    union {
>       int ival __attribute__(tag_value(T_INT));
>       float fval __attribute__((tag_value(T_FLOAT));
>    } __attribute__((tagged_by(type)));
>=20
> ?

I guess the question is whether you want to have a more constraint feature
or a more general, or both. =20

I like "guard" because you can express a lot of different constraints
and tagged unions are just one possible use case.

>=20
> In principle the QUAL_UNION facility would allow having different
> tag members for different fields or even complex combined expressions
> or constants.  Do we want/need
>=20
>   union {
>       int ival __attribute__(tag_value(T_INT));
>       float fval __attribute__(tag_value(T_FLOAT));
>       char pad[sizeof(union)] __attribute__((tag_default));
>    } __attribute__((tagged_by(type)));
>=20
> aka a fallback active element?  For QUAL_UNION it would be the
> last member with a true qualifier.  The behavior when no field
> is active isn't explicitly documented but you could read it to be
> that the union is empty then.

I agree that a default tag makes sense. If we add a more constraint
version like this, I would would probably use an even shorter syntax
and reuse the "default" keyword:

enum num_type type;
[[gnu::tagged_by(type)]] union {
      [[gnu::tag(T_INT)]] int ival;
      [[gnu::tag(T_FLOAT)] float fval;
      [[gnu::tag(default)]] char pad[sizeof(union)];
};

If the underlying feature is QUAL_UNION and this changes the size of
the union depending on the tag, I would not use attributes at all
but introduce a new __tagged_union type or something.

Martin

>=20
> >     float fval;
> >   } __attribute__((warn_untagged));
> > };
> >=20
> > Warning: union <anonymous> member 'fval' is untagged. <warn_untagged>
> >=20
> >=20
> > Another example showing unused enum field
> >=20
> > struct number {
> >   enum num_type type;
> >=20
> >   union {
> >     int ival __attribute__((guard(.type =3D=3D T_INT));
> >   } __attribute__((warn_untagged(enum num_type, T_UNKNOWN)));
> > };
> >=20
> > Warning: union <anonymous> missing enum value 'T_FLOAT'. <warn_untagged=
>
> >=20
> >=20
> > The above showing a warn_untagged that ignores the T_UNKNOWN value.
> >=20
> > The only issue I have with my current proposed syntax for warn_untagged
> > would be that it would be complex with the syntax of the guard attribut=
e
> >=20
> > Ashton