This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

may_alias attribute and type identity (PR c++/34935)


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]