> On May 6, 2015, at 9:49 AM, Richard Smith <[email protected]> wrote:
>
> On 5 May 2015 at 18:17, Jason Merrill <[email protected]
> <mailto:[email protected]>> wrote:
> On 05/05/2015 05:31 PM, John McCall wrote:
> These qualifiers aren’t order-sensitive, so we need to specify the order;
> alphabetical order is the most obvious, which I think would make this
> mangling U11regparmLi3EU7stdcallFviiE rather than the other way around.
>
> For member pointer types, this would become part of the member type. That’s
> also where we put ref-qualifiers and CV-qualifiers, so we need to specify an
> order; I suggest putting these attributes after the CV/ref qualifiers.
>
> I was working from the passage in the ABI that says, "In cases where multiple
> order-insensitive qualifiers are present, they should be ordered 'K' (closest
> to the base type), 'V', 'r', and 'U' (farthest from the base type), with the
> 'U' qualifiers in alphabetical order by the vendor name (with alphabetically
> earlier names closer to the base type)."
>
> So I think reverse alphabetical order before the CV-qualifiers is what we
> want.
>
> Should we mangle these as part of an entity’s type? It’s not possible to
> directly overload using the CC of a function itself, so it’s not strictly
> necessary. There’s a general issue with overloading function templates by
> the types of non-type template parameters, but I don’t think it affects us in
> this specific case because the argument itself resolves the ambiguity.
>
> Microsoft mangles functions differently based on the calling convention, but
> I agree that it doesn't seem to be necessary.
>
> On 05/05/2015 06:40 PM, Richard Smith wrote:
> It seems a little weird to nest a mangling within a source-name like that.
>
> Fair enough, I was experimenting with something that wouldn't require any
> changes to the ABI or demanglers.
>
> We had some previous discussion of arguments for vendor extensions here:
>
> http://sourcerytools.com/pipermail/cxx-abi-dev/2014-January/002660.html
> <http://sourcerytools.com/pipermail/cxx-abi-dev/2014-January/002660.html>
>
> Thanks for the reminder.
>
> It looks like we ended up mangling
>
> void f(bool b) __attribute__((enable_if(b, "foo"))) {}
>
> as
>
> _Z1fUa9enable_ifIXfL0p_EEb
>
> ... where Ua means roughly "vendor attribute", and is followed by
> <source-name> <template-args>. With that approach, those attributes would
> mangle as Ua7regparmIXLi3EE and Ua7stdcallIE
>
> What I see in that thread is "U", not "Ua". And indeed, that seems
> unambiguous; no type can begin with 'I'.
>
> The reason we chose Ua rather than U was that the ABI suggests that U4blah
> should demangle as 'blah', whereas we want something that demanglers know
> should become '__attribute__((blah))'. I have no particular strong feelings
> here.
I think that’s a worthwhile addition to the mangling vocabulary.
Daveed
>
> So, changing
> ::= U <source-name> <type> # vendor extended type qualifier
> to
> ::= U <source-name> <type> [ <template-args> ]
>
> Also, I think the 3 should use the expr-primary mangling, and it doesn't seem
> necessary to attach the "IE" to stdcall. So,
>
> U7regparmILi3EE
> U7stdcall
>
> Make sense?
>
> Jason
>
>
> _______________________________________________
> cxx-abi-dev mailing list
> [email protected] <mailto:[email protected]>
> http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev
> <http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev>
>
> _______________________________________________
> cxx-abi-dev mailing list
> [email protected] <mailto:[email protected]>
> http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev
> <http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev>
_______________________________________________
cxx-abi-dev mailing list
[email protected]
http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev
