This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Proposed semantics for attributes in C++ (and in C?)
Jason Merrill wrote:
I don't think my patch changed the handling of class typedefs; certainly
my intent was only to change how we handle
class __attribute ((foo)) C
Previously we rejected it, now we apply the attributes to the class.
OK, that certainly makes sense. (That's one of the items in the
proposal I wrote up: that you can apply attributes at the point of
declaration of a class.)
Which PRs are you referring to?
One example is:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28558
However, this is a problem with non-semantic attributes, and not related
to your patch. So, I apologize for any aspersions cast. But, it does
motivate for writing something down about what we want semantics we
want. Here, what I think we want is (as per the proposal) to create a
new anonymous typedef for "__attribute__((unused)) A", but consider that
the same type as "A".
I was pretty sure there were other PRs, but I'm not able to find them
now, so perhaps I was dreaming. I thought there were also PRs about
typeid and mangling failing (and/or doing the wrong thing) for types
with attributes (including scalars with attributes).
I'd be inclined to prohibit semantic attributes on typedefs in general.
That's certainly simpler. I'm happy to be talked out of that idea. :-)
Extending the type system to handle attribute types seems excessively
complicated. I think we should define a set of attributes which prevent
us from taking the address of a variable with that attribute
(packed...anything else?) and check for them at the same places we check
for taking the address of a bitfield.
That seems like a good idea to me. However, one consequence is that a
packed class cannot have member functions (since you'd never be able to
get a "this" pointer for them); do you think that's OK?
--
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713