[cxx-abi-dev] Literal operator functions with 'li<length, ID>'
Richard Smith
richardsmith at google.com
Sat Aug 10 02:23:07 UTC 2013
On Fri, Aug 9, 2013 at 7:10 PM, David Vandevoorde <daveed at edg.com> wrote:
>
> On Aug 9, 2013, at 9:46 PM, Richard Smith <richardsmith at google.com> wrote:
>
> > On Fri, Aug 9, 2013 at 8:42 AM, Mike Herrick <mjh at edg.com> wrote:
> [...]
> >> typedef __SIZE_TYPE__ size_t;
> >> void *operator "" _s(unsigned long long) {}
> >> void *operator new(size_t) {}
> >> void *f(unsigned long long) {}
> >> template<typename T> auto f1(T x)->decltype(operator "" _s(x));
> >> template<typename T> auto f2(T x)->decltype(operator new(x));
> >> template<typename T> auto f3(T x)->decltype(f(x));
> >> int main() {
> >> f1(0); // neither g++ nor clang use <unresolved-name> for operator
> ""
> >> _s
> >> // g++: _Z2f1IiEDTclli2_sfp_EET_
> >> // clang: _Z2f1IiEDTclli2_sfp_EET_
> >> // expected: _Z2f1IiEDTclonli2_sfp_EET_
> >> f2(0); // g++ uses <unresolved-name> for operator new
> >> // g++: _Z2f2IiEDTclonnwfp_EET_
> >> // clang: _Z2f2IiEDTclnwfp_EET_
> >> // expected: _Z2f2IiEDTclonnwfp_EET_
> >> f3(0); // g++ and clang use <unresolved-name> for f
> >> // g++: _Z2f3IiEDTcl1ffp_EET_
> >> // clang: _Z2f3IiEDTcl1ffp_EET_
> >> // expected: _Z2f3IiEDTcl1ffp_EET_
> >> }
> >>
> >> [Mangled names are from g++ 4.8.1 and clang 3.3.] We believe
> >> <unresolved-name> should be used for all of these cases.
> [...]
> > 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?
I meant more abstractly, what ambiguity does the 'on' solve? But I answered
this for myself; without it,
operator+(a, b)
and
(a+b)()
would have the same mangling. And indeed, in Clang, they do.
> 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).
>
> (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.
>
> Daveed
>
>
> _______________________________________________
> cxx-abi-dev mailing list
> cxx-abi-dev at codesourcery.com
> http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/cxx-abi-dev/attachments/20130809/0bdaa464/attachment.html>
More information about the cxx-abi-dev
mailing list