Help in tracking down unusual apparent 5.2.0 LTO issue

[Matt Godbolt]

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