On Jun 27, 2016 12:53 PM, "Richard Biener" <richard.guent...@gmail.com> wrote: > > On Thu, Jun 23, 2016 at 9:39 PM, Jason Merrill <ja...@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