This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: Help in tracking down unusual apparent 5.2.0 LTO issue
- From: Matt Godbolt <matt at godbolt dot org>
- To: Markus Trippelsdorf <markus at trippelsdorf dot de>
- Cc: "gcc-help at gcc dot gnu dot org" <gcc-help at gcc dot gnu dot org>
- Date: Thu, 17 Mar 2016 12:12:12 -0500
- Subject: Re: Help in tracking down unusual apparent 5.2.0 LTO issue
- Authentication-results: sourceware.org; auth=none
- References: <CAFWXXN0fD0JXwt66dVz8=JPvH6V+w43uO9G5ASNg3MNEf6aA2w at mail dot gmail dot com> <CAFWXXN2Cz0p-1uCPPg6xxKz0HdEz6Mbh7SzvoeLrpbL+THXe+Q at mail dot gmail dot com> <CAFWXXN0fi92MD=ZimWpj+oeK+g3tV5rNKEnpbfnO62UEimYqUg at mail dot gmail dot com> <20160317134222 dot GA311 at x4> <CAFWXXN247A7rJYe2r91urOOBOv4d2GW7nCvSZgKd0S=AgHpchw at mail dot gmail dot com> <CAFWXXN0wEuUTQJci9g+oX-D43_cOkJH=gQBHw=VgKR4O8YaoeA at mail dot gmail dot com> <20160317161735 dot GB311 at x4> <CAFWXXN3sgPr+kVjZ=dv5VzMKBoLxYiYpaiJQejy4nPuZATMqjw at mail dot gmail dot com> <20160317170313 dot GC311 at x4> <CAFWXXN3wu0DUOUuButbDdAKZbPsZjvWDi=s5RkFhFykNsYutrg at mail dot gmail dot com>
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