Re: Bogus unresolved references to vtable when building with lto

["lh mouse"<lh_mouse at 126 dot com>]

Would you please try moving the definition of the virtual destructor out of the header (into some cpp file). This is practically a bad idea as it bloats each object file that uses the header with RTTI and can lead to unexpected results when using dynamic_cast or exceptions.

------------------				 
Best regards,
lh_mouse
2016-06-15

-------------------------------------------------------------
åääïDave Gittins <dave.gittins@gmail.com>
åéææï2016-06-15 20:29
æääïgcc-help@gcc.gnu.org
æéï
äéïBogus unresolved references to vtable when building with lto

Hi,

I have a program that unexpectedly hit a linker error when building on
x86_64 Linux with ld / gcc 6 and using LTO.

Sorry but I have not managed to extract a sensible test case so far
due to the large size (and sensitivity) of the code base. I am still
trying to chop it down without losing the result. Meanwhile I'll
describe the setup and hope someone can help me.

 * the main program builds with LTO and aggressive optimisation
 * it links against a library libfoo, built elsewhere with gcc but without LTO
 * foo.h contains:
class Foo { virtual ~Foo() {}; virtual blah() = 0; };
 * libfoo.a contains the vtable for Foo in multiple object files
(using comdat groups)
 * classes that inherit from Foo are used in the program

Result:
 1. with gcc 5.2 using -flto -O3: OK
 2. with gcc 6.1 using -O3 (no LTO): OK
 3. with gcc 6.1 using -flto -O3 -fno-strict-aliasing: OK
 4. with gcc 6.1 using -flto -O3: linker error: unresolved reference
to vtable for Foo


I am not very familiar with the inner workings of LTO, but re-running
the link step with --save-temps and looking at the output files, I can
see one difference between cases 3 and 4: in case 3 the vtable symbol
is present in a .s file for the target (e.g. _ZTVN3FooE seems to be
defined) but in the failing case 4 it is called
_ZTVN3FooE.lto_priv.7288. In both cases, the lm.res file contains
something like this:

lm.res:194 857f97bd35affadb PREVAILING_DEF _ZTVN3FooE
lm.res:9895 38fe32bfc94fb92d PREEMPTED_IR _ZTVN3FooE
lm.res:461 979b2bacd9a23781 PREEMPTED_IR _ZTVN3FooE
lm.res:403 d7cb462ac76ae78f PREEMPTED_IR _ZTVN3FooE
lm.res:1625 1c237136eccb8e22 PREEMPTED_IR _ZTVN3FooE
lm.res:194 dc12ecd964eef823 PREEMPTED_IR _ZTVN3FooE
lm.res:194 b0ceb27c32d02e6b PREEMPTED_IR _ZTVN3FooE
lm.res:194 f7293254f09d2c44 PREEMPTED_IR _ZTVN3FooE
lm.res:9490 fa5a2b6c2738a867 PREEMPTED_IR _ZTVN3FooE

I also added this as a comment on this bug report but now I am not
sure if it's really directly related:
https://sourceware.org/bugzilla/show_bug.cgi?id=19842

I think the LTO script is telling the linker that it will provide this
symbol, and then providing it as a global symbol in the working case,
but then in the failing case it is making it local, or something like
that? I assume the optimiser came to some relevant conclusion about
the required visibility of the vtable...?

Any help appreciated.

Dave