[Bug tree-optimization/113590] New: The vectorizer introduces signed overflow

[Bug tree-optimization/113590] New: The vectorizer introduces signed overflow

[kristerw at gcc dot gnu.org]

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

            Bug ID: 113590
           Summary: The vectorizer introduces signed overflow
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: kristerw at gcc dot gnu.org
  Target Milestone: ---

The vectorizer introduces new signed overflow in the function below when
compiled with -O3 for x86_64:


__attribute__ ((noinline)) int
liveloop (int start, int n, int *x, int *y)
{
  int i = start;
  int j;
  int ret;

  for (j = 0; j < n; ++j)
    {
      i += 1;
      x[j] = i;
      ret = y[j];
    }
  return ret;
}


The vectorized loop looks like:

  <bb 3> [local count: 860067200]:
  # vect_vec_iv_.9_57 = PHI <_58(6), _55(9)>
  # vectp_x.11_61 = PHI <vectp_x.11_62(6), x_14(D)(9)>
  # ivtmp_64 = PHI <ivtmp_65(6), 0(9)>
  _58 = vect_vec_iv_.9_57 + { 4, 4, 4, 4 };
  vect_i_13.10_60 = vect_vec_iv_.9_57 + { 1, 1, 1, 1 };
  MEM <vector(4) int> [(int *)vectp_x.11_61] = vect_i_13.10_60;
  vectp_x.11_62 = vectp_x.11_61 + 16;
  ivtmp_65 = ivtmp_64 + 1;
  if (ivtmp_65 < bnd.5_47)
    goto <bb 6>; [89.00%]
  else
    goto <bb 11>; [11.00%]

 <bb 6> [local count: 765459809]:
  goto <bb 3>; [100.00%]

The problem arises from _58, which may overflow in the last iteration. For
example, if the function is called as
  liveloop(0x7ffffff1, 12, p, q);

[Bug tree-optimization/113590] The vectorizer introduces signed overflow

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot gnu.org
   Last reconfirmed|                            |2024-01-25
     Ever confirmed|0                           |1

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed.  Should be reasonably easy to fix - we either move all induction
variable updates to the latch or compute them with unsigned arithmetic
(we usually prefer an empty latch).