https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121209
--- Comment #8 from uecker at gcc dot gnu.org ---
(In reply to Halalaluyafail3 from comment #7)
> (In reply to uecker from comment #6)
> > (In reply to Halalaluyafail3 from comment #5)
> > > Is it not required that the composite type of two types has to be the same
> > > when obtaining it twice, or that the order is irrelevant?
> >
> > The intention was that this is not required. My plan was to propose a
> > change
> > to typedef so that this becomes irrelevant.
> Even if typedef is changed it would still be relevant with structure and
> union redefinitions in the same scope.
True.
>
> > > Here is an example
> > > of where it could be an issue when not using typedef:
> > >
> > > #include<stdio.h>
> > > enum A:int{a};
> > > enum B:int{b};
> > > int main(){
> > > puts(_Generic(1?(enum A*)0:(int*)0,enum B*:"yes",default:"no"));
> > > puts(_Generic(1?(enum A*)0:(int*)0,enum B*:"yes",default:"no"));
> > > }
> > >
> > > Each call to puts prints yes if the composite type of enum A and int is
> > > int,
> > > and no otherwise. If the composite type can change, then can this print
> > > both
> > > yes and no, in either order?
> >
> > For enum and integer, it is implementation defined whether the composite
> > type
> > is the integer or the enum. So here it does not depend on the order but
> > on how this is defined by the implementation.
> So the implementation can define it to randomly choose whether to use the
> enumerated type or the integer type?
No, it has to make a decision and document it. For GCC this is here:
https://gcc.gnu.org/onlinedocs/gcc/Types-implementation.html
