[cxx-abi-dev] Literal operator functions with 'li<length, ID>'

[Mike Herrick]

>> Why is the 'on' ever necessary when the operator is the callee of a 'cl'?
> 
> 
> Because it's an <unresolved-name>?  Also, in the case of a literal operator, bare operators in expressions only occur for unary, binary, and ternary operators, but arguably a literal operator (or a literal operator template) isn't any of those?
> 
> 
>> It appears that Clang never emits it, and just uses the operator-name
>> directly.
>> 
>> Also, what about this:
>> 
>> struct X{}; void operator+(X);
>> template<typename ...T> auto f4(T... x) -> decltype(operator+(x...));
>> int main() {
>>   f4(X{});
>> }
>> 
>> Should we use 'pl' or 'ps' for the operator+ here? Clang uses 'clps', EDG
>> uses 'clonps', and GCC uses 'clonpl'.
> 
> 
> Good catch.  My vote is to go with the GCC mangling (i.e., if it could be unary or binary, go with binary).

This ambiguity is already discussed in the ABI:

If the <unresolved-name> refers to an operator for which both unary and binary manglings are available, the mangling chosen is the mangling for the binary version. For example:

          template<class T> auto f(T p)->decltype(&T::operator-);
            // The return type in the mangling of the template signature
            // is encoded as "DTadsrT_onmiE".

So it looks like GCC's mangling is correct.

> 
> (Here too, I don't see how to read it as not requiring the <unresolved-name> production.)
> 
>> 
>> Also, what about this:
>> 
>> struct X {}; void operator+(X);
>> struct Y; void operator+(Y);
>> template<typename T> void g(void(*)(T), T);
>> template<typename T> auto f(T x) -> decltype(g(operator+, x));
>> void h() { f(X{}); }
>> 
>> Here, GCC and Clang produce _Z1fI1XEDTcl1gplfp_EET_
>> EDG produces the surprising _Z1fI1XEDTcl1gL_Z9operator+Efp_EET_
>> 
>> Both manglings are malformed -- this looks like a case where we really do
>> need the 'on', and yet no-one emits it.
> 
> 
> Agreed.

Ditto.

Mike Herrick
Edison Design Group