This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Attributes on structs
Jason Merrill wrote:
> 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.
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.
If we can mandate that all semantic type attributes apply only at the
point of definition, then we can dodge all these issues; there will
always be only one "class X", whatever attributes it might happen to
have. So, I like that answer.
--
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713