Akira Hatanaka
44cb124f60
When a target's `getVTableUniqueness()` is `UniqueIfStrongLinkage`, as on Apple Mach-O, the platform may emit a class's weak vtable as a separate copy in more than one linkage unit. A symbol that can legitimately exist at several addresses has no meaningful address, so such a vtable can be marked `unnamed_addr`. On Mach-O, a weak vtable that is `unnamed_addr` lowers to a `.weak_def_can_be_hidden` definition, which the static linker coalesces and then drops from the dynamic export trie. Keeping these vtables out of the exported symbol set cuts the work dyld has to do at load time. #200108 dropped `unnamed_addr` from vtables because the exact `dynamic_cast` optimization compares an object's vtable pointer against a known vtable address and depends on that address being unique. Adding `unnamed_addr` is safe here because that optimization is never performed for these weak vtables, so nothing relies on them having a unique address. rdar://179929460
34 lines
772 B
C++
34 lines
772 B
C++
// RUN: %clang_cc1 %s -triple=x86_64-apple-darwin10 -emit-llvm -o - | FileCheck %s
|
|
// PR5697
|
|
namespace PR5697 {
|
|
struct A {
|
|
virtual void f() { }
|
|
A();
|
|
A(int);
|
|
};
|
|
|
|
// A does not have a key function, so the first constructor we emit should
|
|
// cause the vtable to be defined (without assertions.)
|
|
// CHECK: @_ZTVN6PR56971AE = linkonce_odr unnamed_addr constant
|
|
A::A() { }
|
|
A::A(int) { }
|
|
}
|
|
|
|
// Make sure that we don't assert when building the vtable for a class
|
|
// template specialization or explicit instantiation with a key
|
|
// function.
|
|
template<typename T>
|
|
struct Base {
|
|
virtual ~Base();
|
|
};
|
|
|
|
template<typename T>
|
|
struct Derived : public Base<T> { };
|
|
|
|
template<>
|
|
struct Derived<char> : public Base<char> {
|
|
virtual void anchor();
|
|
};
|
|
|
|
void Derived<char>::anchor() { }
|