[LLVMbugs] [Bug 22584] New: Itanium ABI: incorrect mangling of unresolved operator name

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Fri Feb 13 17:06:52 PST 2015


            Bug ID: 22584
           Summary: Itanium ABI: incorrect mangling of unresolved operator
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
          Assignee: unassignedclangbugs at nondot.org
          Reporter: Wolfgang_Pieb at playstation.sony.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Given the following case:

  struct S4 {
      S4 operator-(S4 rhs) { return rhs; }
  template<class T> auto kkk(T p)->decltype(&T::operator-){}
  template<> decltype(&S4::operator-) kkk(S4 x) { return nullptr; }

clang (r229188) mangles the explicit instantiation of kkk() as:

when the correct mangling should be:

_Z3kkkI2S4EDTadsrT_onmiES1_  (note the additional "on")

The crux is here that T::operator- is an unresolved name and the ABI (chapter
5.1.5) gives the following:

  <base-unresolved-name> ::= <simple-id>             # unresolved name
                         ::= on <operator-name>      # unresolved
                         ::= on <operator-name> <template-args>    # unresolved
operator template-id

and, later, in an 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".

gcc 4.8.2 is inconsistent. With the above example, it matches clang's
mangling, but with the following example

  struct S4 {
      S4(int a) {}
  S4 operator+(S4 lhs, S4 rhs) { return rhs; }
  template <class T> auto g(T p1) -> decltype(operator+(p1,p1));
  template <> auto g<S4>(S4 p1) -> decltype(operator+(p1,p1)) { return 0; }

gcc mangles the instantiation of g() correctly to:

whereas clang leaves out the "on"

You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20150214/d11aa74b/attachment.html>

More information about the llvm-bugs mailing list