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

[Richard Smith]

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>