This is the mail archive of the gcc-patches@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: RFC (attributes): PATCH for c++/50800 to set affects_type_identity for may_alias


On Jun 27, 2016 12:53 PM, "Richard Biener" <richard.guenther@gmail.com> wrote:
>
> On Thu, Jun 23, 2016 at 9:39 PM, Jason Merrill <jason@redhat.com> wrote:
> > My earlier patch for 50800 fixed the ICE by consistently stripping
> > non-mangled attributes from template arguments, and mangling those that
> > affect type identity.  At the C++ meeting this week someone pointed out to
> > me that this is a real problem for x86 vector code, which relies on
> > may_alias semantics: if may_alias is stripped from __m128, users can't use
> > templates with vectors.
> >
> > So, it seems that the solution is to mangle may_alias by saying that it
> > affects type identity.  But since we still want to be able to convert back
> > and forth, I thought that it would make sense to treat the may_alias version
> > of a type as a variant, rather than a new distinct type.  So the first patch
> > creates a new category of attributes that are treated as type variants.
> >
> > An alternative patch just sets affects_type_identity and adjusts the C++
> > front end to allow conversion between pointers to add or discard may_alias.
> >
> > Thoughts?
>
> As may_alias purely affects semantics in the implementation of an API
> but not the ABI it shouldn't effect mangling.  In the middle-end we use
> TYPE_REF_CAN_ALIAS_ALL and that and the unqualified pointer
> share the same canonical type (but it's not a variant type, pointer types
> are chained via TYPE_POINTER_TO).
>
> Not sure if you can make use of the canonicalness in the C++ FE
> and maybe drop the attribute early there.

We already drop the attribute; the problem is that users want it to
affect template instantiations. For that to work it needs to affect
mangling of template arguments, at least, so that A<__m128d> and
A<__v2df> can be different types, as they need to be; if they are the
same, one or the other has the wrong semantics.

But to answer Florian's question, mangling of structs would not be
affected, only attribute-qualified built-in types.

Or perhaps we could make __m128* somehow mangle using those names
rather than the underlying vectors, maybe by wrapping them in a
struct.

Jason


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