>> 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
_______________________________________________
cxx-abi-dev mailing list
[email protected]
http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev
