Re: [RFC] Sanitize rtx_addr_can_trap_p_1

[Jakub Jelinek <jakub at redhat dot com>]

On Thu, Jun 11, 2015 at 01:17:47PM +0200, Eric Botcazou wrote:
> > 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?
> 
> Yes, I'm against it, I think that the patch will introduce more issues, and on 
> real-life software this time, than it fixes, but you just need to a second 
> maintainer to overrule me.
> 
> > 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.
> 
> This one is very peculiar though, you need a blatantly out-of-bounds array 
> access that is unreachable, so you can avoid it if you avoid generating 
> nonsensical code with your code generator.

But it doesn't have to be any out of bounds array access in the source actually.
It can be array access indexed by variable that just can be compared to a
very large value and compiler for some reason decides to jump-thread it.
Say an integral variable holding array indexes or a special value (think
0xdeadbeef) for some special handling.  It is enough for the GIMPLE
optimizers not to be able to figure out more complicated control flow
and suddenly you have a dead array[0xdeadbeef] access somewhere, which can
be if-converted to a crashing instruction if things just go wrong.  Just
look how many -Warray-bounds warning false-positives we used to emit before
that warning has been turn off in VRP2 - where the warning used to warn on
out of bounds accesses in dead code.

	Jakub