[Bug tree-optimization/65258] Wrong array bounds warning

rguenth at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Mon Mar 2 09:14:00 GMT 2015


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65258

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |diagnostic,
                   |                            |missed-optimization
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2015-03-02
          Component|c                           |tree-optimization
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot gnu.org
     Ever confirmed|0                           |1
      Known to fail|                            |4.8.3, 4.9.2, 5.0

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Early unrolling peels the a[i] = 0 loop 10 times.  VRP where we perform the
array bound warning still isn't able to prove that the last iterations are
not executed.  So we end up with

  <bb 3>:
  # j_12 = PHI <j_3(7), j_13(9)>
  i_9 = j_12 >> 3;
  i_25 = i_9 + 4294967295;
  a[i_25] = 0;
  i_29 = i_9 + 4294967294;
  a[i_29] = 0;
  i_33 = i_9 + 4294967293;
  if (i_29 != 0)
    goto <bb 4>;
  else
    goto <bb 6>;

  <bb 4>:
  a[i_33] = 0;
  i_37 = i_9 + 4294967292;
  if (i_33 != 0)
    goto <bb 5>;
  else
    goto <bb 6>;

  <bb 5>:
  a[i_37] = 0;
  i_41 = i_9 + 4294967291;
  a[i_41] = 0;
  i_45 = i_9 + 4294967290;
  a[i_45] = 0;
...

I believe that's also partly because we have propagated the increments
to be based on the initial value and thus we don't get any additional
asserts registered after the preceeding checks for != 0.

Let me see if I can do anything about this.



More information about the Gcc-bugs mailing list