Mark Mitchell wrote:
> We had a discussion about this a while back:
>
> http://gcc.gnu.org/ml/gcc/2006-10/msg00318.html
Ah right, I forgot about that. Thanks.
Joseph S. Myers wrote:
There's an additional issue to deal with now: proposals to include some
form of attributes in C++0x and C1x and any semantics those may define.
None of the proposals I've seen seem to do much about addressing the type
system issues.
Nope, none of them seem to include type attributes other than at class
definition time.
Looking over the status quo, the current attributes which are meaningful
on a type are:
packed
unused
aligned
deprecated
transparent_union
visibility
may_alias
plus target-specific attributes.
The first 4 don't create a separate TYPE_MAIN_VARIANT, so they don't
cause the kind of problems we've been seeing. packed and aligned are
semantic attributes, but this isn't a problem because they really only
have semantics at declaration time, not for later code generation.
transparent_union creates a separate TYPE_MAIN_VARIANT using
build_duplicate_type, which copies the fields as well as the type node
itself. I imagine that this also avoids some of the problems.
visibility can only be applied at class definition time, so it isn't an
issue.
may_alias and target attributes are the problematic case. Most of these
just get added to the TYPE_ATTRIBUTES list, and
build_type_attribute_qual_variant creates a new TYPE_MAIN_VARIANT
without copying the fields, which is why things break.
A simple solution might be to just have
build_type_attribute_qual_variant refuse to make a variant of
record/enum types. This will reject the may_alias cases that break, but
leave existing use of aligned/packed/unused/deprecated alone.
Jason
