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
