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:05:38 -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>
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