[Bug tree-optimization/59564] False positive array -Warray-bounds check with -O2

2021-08-03 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59564

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
   Target Milestone|--- |4.9.3
 Resolution|--- |FIXED

--- Comment #3 from Andrew Pinski  ---
So this was fixed by r5-6842 which was backported for GCC 4.9.3 also.

[Bug tree-optimization/59564] False positive array -Warray-bounds check with -O2

2013-12-20 Thread rguenth at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59564

Richard Biener rguenth at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-12-20
  Component|c   |tree-optimization
Version|unknown |4.9.0
 Ever confirmed|0   |1
  Known to fail||4.8.2, 4.9.0

--- Comment #2 from Richard Biener rguenth at gcc dot gnu.org ---
DOM optimizes this to

  if (n = 0)
{
  n = 0;
  arr[0] = 0;
}
  else
arr[n] = 0;

after which value-range propagation warns for the arr[n] on the else
branch because there n = 1 and thus the access is out-of-bounds.

Fixing the obfuscation by doing

  if (n  0) n = 0;

instead of

  if (n = 0) n = 0;

fixes the warning.

The warning is basically that n is not constrained to be  1 which is
of course kind-of-useless.  We don't warn for a plain arr[n] either.
But as you give VRP a half-useful range you make it emit the warning.

Common to these kind of bogus warnings is that we have duplicated the
memory access and warn about the bad half of it.  But we have no way
of tracking whether there are now two pieces instead of just one ...
(apart from maybe using source location info and making sure that VRP
computes the same warning for equal source location accesses).