On Feb 7, 2008 1:10 AM, Mark Mitchell <[EMAIL PROTECTED]> 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.
