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@xxxxxxxxxxx> 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@xxxxxxxxxxxxxxx> 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
