Mark Mitchell wrote:
That seems reasonable to me. The transparent_union trick (copying the
fields, along with making a new TYPE_MAIN_VARIANT) might work, but even
there you have to worry about making sure you a different type_info
object, how do you mangle the name, etc. You're also likely to get
messages like "can't convert X to X" because one of them has an attribute.
Yep. That sort of thing seems reasonable for C, but not for C++, and so
my inclination would be to disallow it for both.
Incidentally, while poking at this I noticed that build_duplicate_type
has been broken since the gomp merge; it just returns the same type. I
would be inclined to just reject transparent_union as well, but it seems
that existing practice is to write
typedef union { ... } U __attribute ((transparent_union));
which modifies the typedef copy of the union rather than the original
type. That is, if build_duplicate_type were doing its job.
I'm not sure what to do about this. I'm reluctant to break the existing
code that does this (such as the glibc stdlib.h). Perhaps just passing
the attribute through to the original type is appropriate for this case,
but seems wrong for
union U2_ { ... };
typedef union U_ U2 __attribute ((transparent_union));
and I'm not sure how to distinguish the two in the compiler. Of course,
we could just pass it through in all cases and tell people who want to
use both the original union and its transparent variant that they're
crazy and need to write another union.
Note that when I fix build_duplicate_type to work properly, the C++
compiler rejects the first usage because U doesn't refer to the original
type, so it isn't used for linkage. Perhaps that's why
build_duplicate_type got broken.
Jason
