[Bug tree-optimization/79159] [7 regression] spurious array-bounds warning

2017-01-24 Thread law at redhat dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79159

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #8 from Jeffrey A. Law  ---
Fixed by Bin's change on the trunk.

[Bug tree-optimization/79159] [7 regression] spurious array-bounds warning

2017-01-24 Thread amker at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79159

--- Comment #7 from amker at gcc dot gnu.org ---
Author: amker
Date: Tue Jan 24 13:09:27 2017
New Revision: 244868

URL: https://gcc.gnu.org/viewcvs?rev=244868=gcc=rev
Log:
PR tree-optimization/79159
* tree-ssa-loop-niter.c (get_cst_init_from_scev): New function.
(record_nonwrapping_iv): Imporve boundary using above function if no
value range information.

gcc/testsuite
PR tree-optimization/79159
* g++.dg/tree-ssa/pr79159.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/tree-ssa/pr79159.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-loop-niter.c

[Bug tree-optimization/79159] [7 regression] spurious array-bounds warning

2017-01-23 Thread amker at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79159

--- Comment #6 from amker at gcc dot gnu.org ---
(In reply to amker from comment #5)
> (In reply to amker from comment #4)
> > Discussed with richi, and conclusion is that vrp issue is hard to fix at the
> > moment.  Easy way out is to investigate why cunrolli peels one additional
> > 
> > There are two possible fixes here. One is to investigate why evrp doesn't
> > compute correct range for j_11:
> > 
> > _1: VARYING
> > _3: VARYING
> > i_4: [0, +INF]
> > j_5: [j_13, +INF]
> > n_12(D): ~[0, 0]
> > j_13: VARYING    > j_15: [-2147483647, +INF]
> > 
> Looks like evrp only computes vrp for parameters or like?

Testing a patch in tree-ssa-loop-niter.c.

[Bug tree-optimization/79159] [7 regression] spurious array-bounds warning

2017-01-23 Thread amker at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79159

--- Comment #5 from amker at gcc dot gnu.org ---
(In reply to amker from comment #4)
> Discussed with richi, and conclusion is that vrp issue is hard to fix at the
> moment.  Easy way out is to investigate why cunrolli peels one additional
> 
> There are two possible fixes here. One is to investigate why evrp doesn't
> compute correct range for j_11:
> 
> _1: VARYING
> _3: VARYING
> i_4: [0, +INF]
> j_5: [j_13, +INF]
> n_12(D): ~[0, 0]
> j_13: VARYING    j_15: [-2147483647, +INF]
> 
Looks like evrp only computes vrp for parameters or like?

[Bug tree-optimization/79159] [7 regression] spurious array-bounds warning

2017-01-23 Thread amker at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79159

--- Comment #4 from amker at gcc dot gnu.org ---
Discussed with richi, and conclusion is that vrp issue is hard to fix at the
moment.  Easy way out is to investigate why cunrolli peels one additional
iteration than necessary.  Note cunrolli computes unrolling number using niter
information, which in turn is inferred from local array bound for this case :
"tmpCorr[9][9]".  
The problem is in function record_nonwrapping_iv, as below code:
  wide_int min, max;
  extreme = fold_convert (unsigned_type, high);
  if (TREE_CODE (orig_base) == SSA_NAME
  && TREE_CODE (low) == INTEGER_CST
  && INTEGRAL_TYPE_P (TREE_TYPE (orig_base))
  && get_range_info (orig_base, , ) == VR_RANGE
  && wi::gts_p (min, low))
base = wide_int_to_tree (unsigned_type, min);
  else if (TREE_CODE (base) != INTEGER_CST
   && dominated_by_p (CDI_DOMINATORS,
  loop->latch, gimple_bb (stmt)))
base = fold_convert (unsigned_type, low);
  delta = fold_build2 (MINUS_EXPR, unsigned_type, extreme, base);

When analyzing "tmpCorr[i_3][j_4]" in below dump:

   [15.00%]:
  j_11 = i_3 + 1;

   [100.00%]:
  # j_4 = PHI 
  if (_1 <= j_4)
goto ; [15.00%]
  else
goto ; [85.00%]

   [15.00%]:
  goto ; [100.00%]

   [85.00%]:
  _2 = tmpCorr[i_3][j_4];
  bar = _2;
  j_13 = j_4 + 1;
  goto ; [100.00%]

The SCEV for j_4 in loop_2 is {j_11, 1}_2, aforementioned code fails to check
that j_11 is larger than 0, instead it uses "low = 0" as starting iteration,
resulting in peeling one additional iteration.

There are two possible fixes here. One is to investigate why evrp doesn't
compute correct range for j_11:

_1: VARYING
_3: VARYING
i_4: [0, +INF]
j_5: [j_13, +INF]
n_12(D): ~[0, 0]
j_13: VARYING

[Bug tree-optimization/79159] [7 regression] spurious array-bounds warning

2017-01-20 Thread law at redhat dot com 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79159

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P2
 CC||law at redhat dot com

[Bug tree-optimization/79159] [7 regression] spurious array-bounds warning

2017-01-20 Thread rguenth at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79159

Richard Biener  changed:

   What|Removed |Added

 CC||amker at gcc dot gnu.org

--- Comment #3 from Richard Biener  ---
Suspiciously similar to PR71437 we have different ASSERT_EXPR order for the
first if (i_1 < _9) / if (_2 > _i_3) condition which downthread leads to
different value numbers.  In this case the "good" order is the other one
though...
(but it produces the same good symbolic range):

here i_1 = [0, 0] and _9 is VARYING.

Visiting statement:
i_2 = ASSERT_EXPR ;
Applying pattern match.pd:695, generic-match.c:64
Applying pattern match.pd:732, generic-match.c:10709
Intersecting
  [-INF, _9 + -1]  EQUIVALENCES: { i_1 } (1 elements)
and
  [0, 0]
Applying pattern match.pd:1771, generic-match.c:1258
Applying pattern match.pd:1771, generic-match.c:1258
to
  [-INF, _9 + -1]  EQUIVALENCES: { i_1 } (1 elements)
Found new range for i_2: [-INF, _9 + -1]

Visiting statement:
_36 = ASSERT_EXPR <_9, _9 > i_2>;
Intersecting
  [i_2 + 1, +INF]  EQUIVALENCES: { _9 } (1 elements)
and
  VARYING
to
  [i_2 + 1, +INF]  EQUIVALENCES: { _9 } (1 elements)
Found new range for _36: [i_2 + 1, +INF]


and for the bad case, i_3 is [0, 0], _2 is VARYING:

Visiting statement:
_40 = ASSERT_EXPR <_2, _2 > i_3>;
Intersecting
  [1, +INF]  EQUIVALENCES: { _2 } (1 elements)
and
  VARYING
to
  [1, +INF]  EQUIVALENCES: { _2 } (1 elements)
Found new range for _40: [1, +INF]

Visiting statement:
i_36 = ASSERT_EXPR ;
Intersecting
  [-INF, 2147483646]  EQUIVALENCES: { i_3 } (1 elements)
and
  [0, 0]
to
  [0, 0]  EQUIVALENCES: { i_3 } (1 elements)
Intersecting
  [0, 0]  EQUIVALENCES: { i_3 } (1 elements)
and
  [0, +INF]
to
  [0, 0]  EQUIVALENCES: { i_3 } (1 elements)
Found new range for i_36: [0, 0]

Final ranges are

i_2: [-INF, _9 + -1]  EQUIVALENCES: { i_1 } (1 elements)
_36: [i_2 + 1, +INF]  EQUIVALENCES: { _9 } (1 elements)

vs.

i_36: [0, 2147483646]  EQUIVALENCES: { i_3 } (1 elements)
_40: [1, +INF]  EQUIVALENCES: { _2 } (1 elements)

and the array ref we warn for has

j_11: [-INF, _56 + -1]  EQUIVALENCES: { j_54 } (1 elements)

vs.

j_1: [9, 2147483646]  EQUIVALENCES: { j_54 } (1 elements)

where we simply give up for the symbolic range case on the GCC 6 branch.

So the issue is not really VRP but that peeling of the inner loop
sometimes produces an extra copy with an out-of-bound access and even
VRP cannot prove the block is never reached.  It's guarded by if (_4 > j_54)
and we have

_4: [9, +INF]  EQUIVALENCES: { _2 _40 _41 _45 _46 _50 _51 _55 _56 } (9
elements)
j_54: [9, +INF(OVF)]

[Bug tree-optimization/79159] [7 regression] spurious array-bounds warning

2017-01-20 Thread rguenth at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79159

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

--- Comment #2 from Richard Biener  ---
I will have a looksee.

[Bug tree-optimization/79159] [7 regression] spurious array-bounds warning

2017-01-19 Thread msebor at gcc dot gnu.org 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79159

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||6.3.0
   Keywords||diagnostic
   Last reconfirmed||2017-01-20
  Component|c++ |tree-optimization
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||7.0

--- Comment #1 from Martin Sebor  ---
Confirmed.  r235817 is the first revision that issues the warning.  Changing
finalDigits to take n by value eliminates the warning,