This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: may_alias attribute and type identity (PR c++/34935)
- From: "Richard Guenther" <richard dot guenther at gmail dot com>
- To: "Mark Mitchell" <mark at codesourcery dot com>
- Cc: "Doug Gregor" <doug dot gregor at gmail dot com>, "GCC Development" <gcc at gcc dot gnu dot org>
- Date: Thu, 7 Feb 2008 10:53:48 +0100
- Subject: Re: may_alias attribute and type identity (PR c++/34935)
- References: <24b520d20801240658t34a3fbf1gbcfabe24fdaa8dd7@mail.gmail.com> <47AA4C90.4000404@codesourcery.com>
On Feb 7, 2008 1:10 AM, Mark Mitchell <mark@codesourcery.com> wrote:
> Doug Gregor 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);
>
> > 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
>
> The may_alias attribute is a semantic attribute as it is specifically
> designed to affect code-generation.
>
> Using the message you mention, this means that "X" is distinct from
> "int" -- which is what Richard and Jakub indicate as well, based on what
> the middle-end does.
>
> Also, that message says:
>
> > It is invalid to do anything that would require either type_info or a mangled name for "Q", including using it as an argument to typeid, thowing an exception of a type involving "Q", or declaring a template to take a parameter of a type involving "Q".
>
> So, that means that you can't have any C++ functions with external
> linkage involving "X". Of course, as that message says:
>
> > We could relax some of these restrictions in future, if we add mangling support for attributes.
>
> But, yes, if we need to mangle these types, we need to have a mangling
> for attributes.
I don't think that may_alias is an attribute that needs to be mangled, as its
semantics affect code generation but not interfacing. For example:
void foo(int *x __attribute__((may_alias));
and
void foo(int *x);
are not distinguishable at the point of the caller -- but only affect code
generation in foo() itself. (leaving aside the issue of applying may_alias
to a data type and not a pointer type, which IMHO doesn't make sense)
Richard.