Re: Help in tracking down unusual apparent 5.2.0 LTO issue

[Matt Godbolt <matt at godbolt dot org>]

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@trippelsdorf.de> 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