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

[Argyrios Kyrtzidis]

On 11 Oct 2010, at 14:15, Douglas Gregor wrote:

> 
> 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?

Yes, exactly.

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

No, it gets instantiated at a library outside of the executable.

-Argiris

> 
>>> 
>>>> "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