On Jan 24, 2008 3:58 PM, Doug Gregor <[EMAIL PROTECTED]> wrote: > 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?
The middle-end type system (useless_type_conversion_p) says that pointers to int and pointers to int __attribute__((may_alias)) are distinct (you can't use one in place of the other without changning semantics) - because the pointed to types have different alias sets. Now, for rvalues that doesn't matter, so indeed a value of type int and a value of type int __attribute__((may_alias)) can be used in place of each other. So I stand corrected and they should indeed have the same canonical type. RIchard. > 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 >