[LLVMbugs] [Bug 12881] New: Explicit template instantiation causes inline members to have default visibility

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Fri May 18 10:49:46 PDT 2012


http://llvm.org/bugs/show_bug.cgi?id=12881

             Bug #: 12881
           Summary: Explicit template instantiation causes inline members
                    to have default visibility
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: nicolasweber at gmx.de
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Consider these two files, which are identical except that point.ii has an
explicit instantiation of PointBase which tween.ii just uses the Point type:

hummer:src thakis$ cat point.ii
namespace gfx {

template<typename Class, typename Type>
class __attribute__((visibility("default"))) PointBase {
 public:
  Type x() const { return 0; }
};

class __attribute__((visibility("default"))) Point
    : public PointBase<Point, int> {};

template class PointBase<Point, int>;

}
hummer:src thakis$ cat tween.ii
namespace gfx {

template<typename Class, typename Type>
class __attribute__((visibility("default"))) PointBase {
 public:
  Type x() const { return 0; }
};

class __attribute__((visibility("default"))) Point
    : public PointBase<Point, int> {};

void f(const gfx::Point& start_bounds) {
  (void)start_bounds.x();
}

}



GCC produces a hidden symbol for PointBase:x() for both files:

hummer:src thakis$ gcc -c -fvisibility=hidden -fvisibility-inlines-hidden
tween.ii point.ii && (nm -m point.o | grep __ZNK3gfx9PointBaseINS_5PointEiE1xEv
; nm -m tween.o | grep __ZNK3gfx9PointBaseINS_5PointEiE1xEv)
0000000000000000 (__TEXT,__text) private external
__ZNK3gfx9PointBaseINS_5PointEiE1xEv
0000000000000030 (__TEXT,__eh_frame) private external
__ZNK3gfx9PointBaseINS_5PointEiE1xEv.eh
0000000000000018 (__TEXT,__textcoal_nt) weak private external
__ZNK3gfx9PointBaseINS_5PointEiE1xEv
0000000000000048 (__TEXT,__eh_frame) weak private external
__ZNK3gfx9PointBaseINS_5PointEiE1xEv.eh


clang produces a visible symbol for the first file:

hummer:src thakis$ third_party/llvm-build/Release+Asserts/bin/clang -c
-fvisibility=hidden -fvisibility-inlines-hidden tween.ii point.ii && (nm -m
point.o | grep __ZNK3gfx9PointBaseINS_5PointEiE1xEv ; nm -m tween.o | grep
__ZNK3gfx9PointBaseINS_5PointEiE1xEv)
0000000000000000 (__TEXT,__textcoal_nt) weak external
__ZNK3gfx9PointBaseINS_5PointEiE1xEv
0000000000000028 (__TEXT,__eh_frame) weak external
__ZNK3gfx9PointBaseINS_5PointEiE1xEv.eh
0000000000000020 (__TEXT,__textcoal_nt) weak private external
__ZNK3gfx9PointBaseINS_5PointEiE1xEv
0000000000000070 (__TEXT,__eh_frame) weak private external
__ZNK3gfx9PointBaseINS_5PointEiE1xEv.eh


(it looks like -fvisibility-inlines-hidden wins over explicit class-level
visibility annotations in gcc, but not in clang)

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.



More information about the llvm-bugs mailing list