[Bug tree-optimization/92955] [10 regression] gcc.dg/vect/pr60505.c fails starting with r279392

[law at redhat dot com]

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

--- Comment #8 from Jeffrey A. Law <law at redhat dot com> ---
Just to be clear, it's not DOM or threading that introduces any out of bounds
accesses or overflows here.

So the testcase:

/* { dg-do compile } */
/* { dg-additional-options "-Wall -Werror" } */

void foo(char *in, char *out, int num)
{
  int i;
  char ovec[16] = {0};

  for(i = 0; i < num ; ++i)
    out[i] = (ovec[i] = in[i]);
  out[num] = ovec[num/2];
}

Compiled for powerpc64-linux-gnu with:

./cc1 -O3 j.c -I./ -Wall -maltivec -fdump-tree-all-blocks-details
-fno-vect-cost-model


The first warning comes from this statement in block #5:

  ovec[tmp.8_58] = _207;

The block looks like this in the .thread3 (ie, before dom3) dump:


;;   basic block 5, loop depth 0, count 78839494 (estimated locally), maybe hot
;;    prev block 4, next block 6, flags: (NEW, REACHABLE, VISITED)
;;    pred:       4 [93.8% (guessed)]  count:78839494 (estimated locally)
(FALSE_VALUE,EXECUTABLE)
  _205 = (sizetype) tmp.8_58;
[ ... ]
  ovec[tmp.8_58] = _207;
[ ... ]


THe definition of tmp.8_58 comes from bb#4:

;;   basic block 4, loop depth 0, count 84095460 (estimated locally), maybe hot
;;    prev block 3, next block 5, flags: (NEW, REACHABLE, VISITED)
;;    pred:       3 [80.0% (guessed)]  count:84095460 (estimated locally)
(TRUE_VALUE,EXECUTABLE)
  bnd.6_56 = _10 >> 4;
[ ... ]
  niters_vector_mult_vf.7_57 = bnd.6_56 << 4;
  tmp.8_58 = (int) niters_vector_mult_vf.7_57;
  if (_10 == niters_vector_mult_vf.7_57)
    goto <bb 36>; [6.25%]
  else
    goto <bb 5>; [93.75%]


The definition of _10 comes from bb3:

;;   basic block 3, loop depth 0, count 105119324 (estimated locally), maybe
hot
;;    prev block 2, next block 4, flags: (NEW, VISITED)
;;    pred:       2 [89.0% (guessed)]  count:105119324 (estimated locally)
(TRUE_VALUE,EXECUTABLE)
  _10 = (unsigned int) num_13(D);
[ ... ]


So let's compute tmp.8_58 :-) assuming that num_13 is an incoming parameter and
we have no information about it other than its type (int).

Visiting statement:
_10 = (unsigned int) num_13(D);
Intersecting
  unsigned int [1, 2147483647]
and
  unsigned int VARYING

Which feeds into:

Visiting statement:
bnd.6_56 = _10 >> 4;
Intersecting
  unsigned int [1, 134217727]
and
  unsigned int [1, 268435455]
to
  unsigned int [1, 134217727]

So bnd.6_56 can have the value [1, 0x7ffffff] Which makes perfect sense.  That
feeds into:


Visiting statement:
niters_vector_mult_vf.7_57 = bnd.6_56 << 4;
Intersecting
  unsigned int [16, 2147483632]
and
  unsigned int VARYING
to
  unsigned int [16, 2147483632]

So ninters_vector_mult_vf.7_57 can have the values [16, 0x7ffffff0].  Which
also makes perfect sense and feeds into:

Visiting statement:
tmp.8_58 = (int) niters_vector_mult_vf.7_57;
Intersecting
  int [16, 2147483632]
and
  int VARYING
to
  int [16, 2147483632]

So tmp.8_58 also has values in the range [16, 0x7ffffff0]

So when used in this statement:


  ovec[tmp.8_58] = _207;

We get the out of bounds access.  Pretty simple.

THis is caused either by vectorization or loop unrolling or the combination
thereof (most likely loop unrolling).  DOM/threading have nothing to do with
what's going on in here.