Re: [RFC] Sanitize rtx_addr_can_trap_p_1

[Richard Biener <richard.guenther@gmail.com>]

On Thu, Jun 11, 2015 at 12:38 PM, Bernd Edlinger
<bernd.edlinger@hotmail.de> wrote:
> Hi,
>
> On Thu, 11 Jun 2015 10:02:03, Jakub Jelinek wrote:
>>
>> IMHO the
>> #if 0
>> #endif
>> stuff doesn't belong to the patch.
>>
>
> I just wanted to leave a hint, how I debugged this function, and how
> to assess the performance of the decision that is taken here.
>
> I mean, the boot-strap would certainly pass, if I always return 0 here,
> but Eric would'nt like it.
>
> I believe that, when the offset lies within the bounds that are implied by
> the current function's stack frame, the access will always be safe.
>
> But there are some very rare false positives, when this function returns 0
> on "normal" code, like gcc source code itself, and they are interesting to debug.
>
> Should I better change the #if 0 block into a comment?

Yes.  If you have testcases for those rare false positives it would be nice to
reduce them and at least archieve them in bugzilla.

>
>> Other than that, as I said already in the PR, I'm in favor of applying it to
>> the trunk (only, not release branches) and watching for performance and/or
>> wrong-code issues, but Eric is against it. What do others think about it?
>>
>> From John Regehr's talk at GCC Summit a few years ago I got the
>> impression that for people to be able to effectively report bugs in the
>> compiler through code generator it is important that discovered bugs in the
>> compiler are fixed timely, otherwise it makes life to the reporters much
>> harder, because then they'll run into the same still unfixed issue all the
>> time.
>>
>
> On that, I totally agree.

I also think we need to be conservative.  I didn't look at the patch in detail
to check whether we are indeed conservative here (what about offsets
that are not visibly constant like for if (n > m) ... a[m];?).

Richard.

>
> Thanks
> Bernd.
>