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]

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


On Jan 24, 2008 3:58 PM, Doug Gregor <doug.gregor@gmail.com> 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
>


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