Hi, I confirmed we're passing -std=c++1y in both cases (yes; this has bitten us before so we're sensitive to this! :). That said; I believe the list ABI change was guarded with new namespaces (as was the std::string changes that came alongside). There's no ODR violations that we can find. We build with -Wall -Wextra -Werror and have seen ODR errors reported during LTO before, but do not have any in this project. We run (a debug version) with -fsanitize=undefined (or at least a subset of undefined behaviour), and that's clean. The subset does not include "taking reference to a null pointer" as this is something parts of our code do. (None involving std::function or any lists). Thanks for taking the time to reply: I'll try again to reproduce and file a bug, but so far I've not had much luck. Regards, Matt On Thu, Mar 17, 2016 at 11:17 AM, Markus Trippelsdorf <markus@xxxxxxxxxxxxxxx> wrote: > On 2016.03.17 at 16:04 +0000, Matt Godbolt wrote: >> Hi again, >> >> I managed to get GCC5.2.0 building against binutils 2.26: >> >> $ ~/.fighome/runtime/gcc/5.2.0-2/bin/ld.gold --version >> GNU gold (DRW-internal-build 2.26.20160125) 1.11 >> >> Sadly the problem remains: >> >> Dump of assembler code for function std::_List_node<std::function<void ()> >> >::~_List_node(): >> 0x0000000000762240 <+0>: push %rbp >> 0x0000000000762241 <+1>: mov %rsp,%rbp >> 0x0000000000762244 <+4>: sub $0x10,%rsp >> 0x0000000000762248 <+8>: mov %rdi,-0x8(%rbp) >> 0x000000000076224c <+12>: mov -0x8(%rbp),%rax >> 0x0000000000762250 <+16>: add $0x10,%rax >> 0x0000000000762254 <+20>: mov %rax,%rdi >> 0x0000000000762257 <+23>: callq 0x0 >> 0x000000000076225c <+28>: nop >> 0x000000000076225d <+29>: leaveq >> 0x000000000076225e <+30>: retq >> End of assembler dump. >> >> Any thoughts on what flags I might give to gold to try and track this down? >> I tried -Wl,--debug,all and there didn't seem to be all that much debug >> information. > > Before digging into gold I would rule out other possible issues first: > > - Are both projects using the same libstdc++ ABI? There was a new > implementation of std::list for gcc-5. See: > http://gcc.gnu.org/gcc-5/changes.html#libstdcxx > > - Are there any one-definition-rule issues? Or any other possible > undefined behavior? Try building everything with -fsanitize=undefined > and see if anything pops up. > > If nothing helps then please try again to come up with a testcase and > open a http://sourceware.org/bugzilla/ gold bug. > > -- > Markus -- Matt
