Help in tracking down unusual apparent 5.2.0 LTO issue

Matt Godbolt matt@godbolt.org
Wed Mar 16 20:34:00 GMT 2016


Hi all,

I've just lost a day to tracking down an unusual crash which I've
traced back to what seems to be an LTO issue.

I'm linking a large application against some open source libraries.
All are built with the same version of GCC (5.2.0). We have been using
LTO for a long time, since 4.9.x, without issue.

Recently I upgraded one of our dependencies
(https://github.com/mattgodbolt/seasocks). One change was that this
dependency now uses std::function<void()> in its API. This library is
built *without* LTO.

In our application we now get a crash when the destructor for
std::function<void()> is called. We have a std::list<> of such
functions and the code generated now looks like this:

gdb out/dist/lib-haswell/hippo -ex "disassemble
'std::_List_node<std::function<void ()> >::~_List_node()'"
Dump of assembler code for function std::_List_node<std::function<void
()> >::~_List_node():
   0x0000000000763a40 <+0>: push   %rbp
   0x0000000000763a41 <+1>: mov    %rsp,%rbp
   0x0000000000763a44 <+4>: sub    $0x10,%rsp
   0x0000000000763a48 <+8>: mov    %rdi,-0x8(%rbp)
   0x0000000000763a4c <+12>: mov    -0x8(%rbp),%rax
   0x0000000000763a50 <+16>: add    $0x10,%rax
   0x0000000000763a54 <+20>: mov    %rax,%rdi
   0x0000000000763a57 <+23>: callq  0x0
   0x0000000000763a5c <+28>: nop
   0x0000000000763a5d <+29>: leaveq
   0x0000000000763a5e <+30>: retq
End of assembler dump.

The spot where the "call std::function::~function<void()>" should be
has a "callq 0x0".  If I build with LTO off globally, the callq is
indeed correctly generated/linked.

It's as if the linker has just plain not done its job there with LTO on.

If I take the source of Seasocks and bring it into the project (and
thus the files are built with LTO), all compiles fine. We run using
-fuse-ld=gold -flto -fuse-linker-plugin, amongst many other options.

Despite trying my hardest I was unable to reproduce this issue using
two files calling each other (one with LTO on, one not). Can anyone
give suggestions as to what I might try to figure out what's going on?
I have just tried with GCC 5.3 too, and have had no success either.

Many thanks in advance,

Matt



More information about the Gcc-help mailing list