[Bug tree-optimization/51721] -Warray-bounds false positives and inconsistencies

["rguenth at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51721

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2012-01-02
     Ever Confirmed|0                           |1

--- Comment #4 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-01-02 10:19:13 UTC ---
(In reply to comment #2)
> This is a common problem with the -Warray-bounds warning, first jump threading
> (during vrp1) optimizes it into just a single s == 17 check, followed by
> a[11] = 0; b[11] = 0; c[17] = 0; d[11] = 0; if true and a[s] = 0; etc. if false
> (well, at the end of vrp1 the constants aren't in the array refs yet, but they
> are propagated there afterwards), and as no optimization figures out the weird
> if (s >> 1 == 0) check (if (s < 2) would DTRT) to determine that s is not 17,
> vrp2 warns about those accesses.
> Perhaps for -Warray-bounds (at least if not -Warray-bounds=2 or similar) we
> shouldn't warn on code that has been jump threaded, anyway, I don't think that
> is solvable for 4.7 easily.
> 
> What we perhaps could do more easily for this testcase (and could improve code
> too) is during VRP for:
> <bb 2>:
>   D.1716_2 = s_1(D) >> 1;
>   if (D.1716_2 == 0)
>     goto <bb 3>;
>   else
>     goto <bb 12>;
> (or any other constant after >>, both signed and unsigned right shift, and ==
> or !=) insert ASSERT_EXPRs into both bbs, saying that the SSA_NAME in rhs1 of
> the
> shift is in/out of second ==/!= operand << rhs2 of shift, -""- + ((1 << rhs2) -
> 1) range.  In this case it would be ASSERT_EXPRs that s_1(D) <= 1 at the start
> of bb 3 (and if bb 12 had only one predecessor, also that s_1(D) > 1 at bb 12
> start).  Richard, what do you think about that?

Yeah, if that turns out to be a common pattern, though maybe restrict it to
==/!= 0 tests?  (if that simplifies the patch)