PR c++/34935 illustrates a problem with the way attributes interact with type identity. The example in question looks something like this:
typedef int X __attribute((may_alias)); void foo(X); void foo(int); The fundamental question here is whether 'X' is a new type distinct from 'int', or whether 'X' is really just a typedef of 'int' that adds the 'may_alias' attribute. The failure in PR c++/34935 comes from the canonical types system having a different answer to this question than the normal type-comparison function in the C++ front end (structural_comptypes). Canonical types says that 'int' and 'X' are the same type, which says that this code is fine: we're just declaring the function "foo" twice in the same way. structural_comptypes says that 'int' and 'X' are distinct types, which says that this code is still fine... we're declaring two overloaded functions named "foo". The oddity, for me, is that structural_comptypes isn't deciding that 'X' and 'int' are different because it's looking at attributes or anything like that: it decides they are different because they have different TYPE_MAIN_VARIANTs, and it doesn't bother to look at the guts of the INTEGER_TYPE nodes to see that they are the same. So, I *think* that structural_comptypes need to compare the guts of INTEGER_TYPE nodes, but Richard Guenther's comment on the PR indicates that it's canonical types that are wrong. Which one is it? Note that this is pretty tied up with Mark Mitchell's discussion of semantic and non-semantic attributes, here: http://gcc.gnu.org/ml/gcc/2006-10/msg00318.html - Doug
