[LLVMbugs] [Bug 19229] New: linker error passing const static field as template argument

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Sat Mar 22 08:44:26 PDT 2014


            Bug ID: 19229
           Summary: linker error passing const static field as template
           Product: clang
           Version: trunk
          Hardware: Macintosh
                OS: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: jds.register at icloud.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 12268
  --> http://llvm.org/bugs/attachment.cgi?id=12268&action=edit
LLVM IR of sample

The error is reproducible with:

struct MyStr {
  static const int ConstVal = 1;
  int AnInt;

static bool operator==(MyStr LHS, int RHS) { return LHS.AnInt == RHS; }

template <class T, class U>
bool operator!=(const T& LHS, const U& RHS) { return !(LHS == RHS); }

void foo() {
  MyStr S { MyStr::ConstVal };
  bool b1 = S == MyStr::ConstVal;
  // Actually only this line is needed for the error:
  bool b2 = S != MyStr::ConstVal;

The code compiles fine, but the linking stage fails:

Undefined symbols for architecture x86_64:
  "__ZN5MyStr8ConstValE", referenced from:
      __Z3foov in main.o

I'm using the trunk version, but the error occurred in Xcode as well.

I looked myself around a bit and found the following:
If you look at the LLVM IR (see my attachment; only mem2reg applied, to save a
few lines), there are two things to notice:
First: @_ZN5MyStr8ConstValE is defined as an external i32 (the origin of the
linker error!)
Second: Although @_Zeq5MyStri (operator==) is called directly with the 1 (line
21) and the variable S is directly initialized/build up with the 1 (line 7 &
14/15), @_ZneI5MyStriEbRKT_RKT0_ (operator!=) is called with a pointer to
@_ZN5MyStr8ConstValE. Why is not simply passed 1 here as well?

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/20140322/fc6da56a/attachment.html>

More information about the llvm-bugs mailing list