[cfe-commits] r116186 - in /cfe/trunk: lib/CodeGen/CGRTTI.cpp lib/CodeGen/CGVTables.cpp lib/CodeGen/CGVTables.h test/CodeGenCXX/vtable-linkage.cpp

[Douglas Gregor]

On Oct 11, 2010, at 2:03 PM, Argyrios Kyrtzidis wrote:

> On 11 Oct 2010, at 13:42, Douglas Gregor wrote:
> 
>> 
>> On Oct 11, 2010, at 11:22 AM, Argyrios Kyrtzidis wrote:
>> 
>>> $ cat t.cpp
>>> template <typename T>
>>> struct S {
>>> 	virtual void m();
>>> };
>>> 
>>> void f() {
>>> 	S<int> *s = new S<int>;
>>> }
>>> 
>>> $ clang -S -emit-llvm t.cpp -o -
>>> [...]
>>> @_ZTV1SIiE = external constant [3 x i8*]
>>> [...]
>>> 
>>> $ llvm-gcc -S -emit-llvm t.cpp -o -
>>> [...]
>>> %struct.__class_type_info_pseudo = type { %struct.__type_info_pseudo }
>>> %struct.__type_info_pseudo = type { i8*, i8* }
>>> 
>>> @_ZTV1SIiE = weak_odr constant [3 x i32 (...)*] [i32 (...)* null, i32 (...)* bitcast (%struct.__class_type_info_pseudo* @_ZTI1SIiE to i32 (...)*), i32 (...)* bitcast (void (%"struct.S<int>"*)* @_ZN1SIiE1mEv to i32 (...)*)], align 16 ; <[3 x i32 (...)*]*> [#uses=1]
>>> @_ZTI1SIiE = weak_odr constant %struct.__class_type_info_pseudo { %struct.__type_info_pseudo { i8* inttoptr (i64 add (i64 ptrtoint ([0 x i32 (...)*]* @_ZTVN10__cxxabiv117__class_type_infoE to i64), i64 16) to i8*), i8* getelementptr inbounds ([6 x i8]* @_ZTS1SIiE, i64 0, i64 0) } }, align 16 ; <%struct.__class_type_info_pseudo*> [#uses=1]
>>> @_ZTVN10__cxxabiv117__class_type_infoE = external constant [0 x i32 (...)*] ; <[0 x i32 (...)*]*> [#uses=1]
>>> @_ZTS1SIiE = weak_odr constant [6 x i8] c"1SIiE\00" ; <[6 x i8]*> [#uses=2]
>>> [..]
>>> 
>>> 
>>> This resulted in an unresolved symbol linker error in Qt.
>> 
>> This should only happen if the method S<int>::m is not instantiated anywhere else in Qt. Is that really the case?
> 
> To be more clear, when using clang, the specific executable being linked fails with linker error because the VTable symbol is not defined in the object files being linked.
> With gcc, the VTable is emitted (as in the test case I posted) and the key function is resolved dynamically when the executable is run.

But where does the body of the key function come from? Some other library that's loaded dynamically?

More importantly, did the key function get instantiated somewhere and we failed to emit the vtables + RTTI at that point?

>> 
>>> "C++ ABI 5.2.6 Instantiated Templates" says that template instantiations emit the virtual table in the object where instantiated, it doesn't mention the key function.
>> 
>> Hrm, strange. I guess one could interpret this paragraph as overriding the general rule for emitting vtables, but that's rather unfortunate: it'll mean that we end up emitting vtables and RTTI in many more translation units than we do.
> 
> I don't think it will make that much difference in real code, since in the majority of cases the key function of templates has a body.


Okay, I buy that. I still want to know whether they're doing something weird (not instantiating the key function anywhere) or whether we have a different bug on our hands. 

	- Doug