[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