This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH, MPX, 2/X] Pointers Checker [2/25] Builtins
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: Ilya Enkovich <enkovich dot gnu at gmail dot com>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 29 Oct 2013 11:17:49 +0100
- Subject: Re: [PATCH, MPX, 2/X] Pointers Checker [2/25] Builtins
- Authentication-results: sourceware.org; auth=none
- References: <20131021114918 dot GB37888 at msticlxl57 dot ims dot intel dot com> <526A01DC dot 4080000 at redhat dot com> <CAMbmDYZLOiBp=h8up2u1S+-DOv1KY9KsG1UwMnyPrOKcyYgc0Q at mail dot gmail dot com> <526ED55F dot 7030305 at redhat dot com>
On Mon, Oct 28, 2013 at 10:21 PM, Jeff Law <law@redhat.com> wrote:
> On 10/25/13 11:57, Ilya Enkovich wrote:
>
>>
>> There are currently two known issues with LTO. The first one is ICE in
>> LTO streamer when it reads instrumented code. The second one is
>> unitialized flag_check_pointers when code is compiled by lto1 (do you
>> know why it may happen BTW?). It also causes ICE beacause instrumented
>> code is met when not expected. Of course, I'll fix these problems
>> anyway, but I was going to allow '-fcheck-pointers -flto' only when
>> checker testsuite has 100% pass rate with lto.
>
> No idea about why LTO would be failing in this way -- my experience with LTO
> is virtually nil.
>
> I'm OK with the restriction as a temporary measure. But we really dislike
> this kidn of stuff, so I need a commitment from you to dive into these
> problems and sort out what's really going on.
I'm not ok with adding such arbitrary restrictions. LTO support should
be trivial.
Richard.
>
>>
>> Ilya
>>
>