Re: Help in tracking down unusual apparent 5.2.0 LTO issue

[Matt Godbolt <matt at godbolt dot org>]

I've just spent a good few hours trying to reproduce, with no success.
I've also tried tracing the symbol with "-y" in both my (attempted)
repro case and the error case.

In the repro case, the ~function() is not even generated with LTO: it
seems the trivial destructor is inlined in all cases. The non-LTO copy
is generated and is the one that's linked with. (I'm using -O3 for LTO
objects and -O0 for non-LTO like my error case has).

In the error case, the symbol is defined in two places:
out/haswell/main/SystemExit.o: definition of _ZNSt8functionIFvvEED1Ev
lib/libseasocks.a(Server.cpp.o): definition of _ZNSt8functionIFvvEED1Ev

std::function<void()> is used all over the code; so I suspect the
"SystemExit.o" file is just the place the LTO decided to generate it.
That said; I could only find references to the symbol in any of the
-save-temps *ltrans.*.s files. There's a "    .set
_ZNSt8functionIFvvEED1Ev,_ZNSt8functionIFvvEED2Ev" in that file;
c++filt demangles the latter as the same as the former; and the latter
*is* defined. I wonder if this apparent "rename" (or whatever .set is)
is confusing the linker further on. That said; the "1" and "2" version
are both seemingly present in the library (libseasocks.a) too (as a
weak reference, according to nm).

I really wish I could reproduce this! I'm posting this follow-up just
in case anything I've done or seen above jogs someone's memory or if
anyone has any further thoughts on what the root cause may be.

Thanks again all, Matt

On Thu, Mar 17, 2016 at 12:12 PM, Matt Godbolt <matt@godbolt.org> wrote:
> Compiling the LTO half with -fno-delete-null-pointer-check made no
> difference in this case. (Recompiling the non-LTO side seems
> unnecessary: that side is already code-generated with apparently
> correct code).
>
> Thanks, Matt
>
> On Thu, Mar 17, 2016 at 12:05 PM, Matt Godbolt <matt@godbolt.org> wrote:
>> I can give that a go: but I'd be very surprised. I'm no expert
>> (clearly!) but I can't see how a null-pointer check could be involved
>> anywhere here. Even if a pointer check was erased, I can't see how
>> "callq 0" could ever be valid: the linker seemingly just has left the
>> stub "callq 0" in from the (non-LTO) .o file.
>>
>> I will test with -fno-delete-null-pointer-checks though.
>>
>> On Thu, Mar 17, 2016 at 12:03 PM, Markus Trippelsdorf
>> <markus@trippelsdorf.de> wrote:
>>> On 2016.03.17 at 11:50 -0500, Matt Godbolt wrote:
>>>> 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).
>>>
>>> Hmm, this sounds like -fno-delete-null-pointer-checks may help.
>>>
>>> --
>>> Markus
>>
>>
>>
>> --
>> Matt
>
>
>
> --
> Matt



-- 
Matt