[Bug tree-optimization/98117] New: wrong code with "-O3 -fno-tree-scev-cprop"

[Bug tree-optimization/98117] New: wrong code with "-O3 -fno-tree-scev-cprop"

[suochenyao at 163 dot com]

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

            Bug ID: 98117
           Summary: wrong code with "-O3 -fno-tree-scev-cprop"
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: suochenyao at 163 dot com
  Target Milestone: ---

*******************************************************************************
OS and Platform:
CentOS Linux release 7.8.2003 (Core), x86_64 GNU/Linux
*******************************************************************************
Program:
$ cat a.c
int printf(const char *, ...);
int a=0;
char b=0, c=0;
short d=0;
void e() {
  for (; b; b++)
    d = a + 8;
  for (; d;)
    ;
f:
  c++;
  if (c)
    goto f;
}
int main() {
  e();
  printf("%d\n", c);
}
*******************************************************************************
gcc version:
$ gcc --version
gcc (GCC) 11.0.0 20201203 (experimental)
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
*******************************************************************************
Command Lines:
$ gcc a.c -o a1.o
$ gcc -Wall -Wextra -fno-strict-aliasing -fwrapv -O3 -fno-tree-scev-cprop  a.c
-o a2.o
$ ./a1.o
0
$ ./a2.o
-32

[Bug tree-optimization/98117] [8/9/10/11 Regression] wrong code with "-O3 -fno-tree-scev-cprop" since r8-1163-g7078979b291419f3

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |amker at gcc dot gnu.org,
                   |                            |marxin at gcc dot gnu.org
            Summary|wrong code with "-O3        |[8/9/10/11 Regression]
                   |-fno-tree-scev-cprop"       |wrong code with "-O3
                   |                            |-fno-tree-scev-cprop" since
                   |                            |r8-1163-g7078979b291419f3
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2020-12-03
             Status|UNCONFIRMED                 |NEW

--- Comment #1 from Martin Liška <marxin at gcc dot gnu.org> ---
Started with r8-1163-g7078979b291419f3.
One needs only the following options: -O3 -fno-tree-scev-cprop

[Bug tree-optimization/98117] [8/9/10/11 Regression] wrong code with "-O3 -fno-tree-scev-cprop" since r8-1163-g7078979b291419f3

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu.org
           Keywords|                            |wrong-code
             Blocks|                            |53947
   Target Milestone|---                         |8.5
           Priority|P3                          |P2


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations

[Bug tree-optimization/98117] [8/9/10/11 Regression] wrong code with "-O3 -fno-tree-scev-cprop" since r8-1163-g7078979b291419f3

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot gnu.org

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
Simplified testcase, fails with -O3 -fno-tree-scev-cprop

unsigned char c;
void __attribute__((noipa))
e()
{
  do
    {
    }
  while (++c);
}
int main()
{
  e();
  if (c != 0)
    __builtin_abort ();
  return 0;
}


It's the first new set_range_info that causes the miscompile.

[Bug tree-optimization/98117] [8/9/10/11 Regression] wrong code with "-O3 -fno-tree-scev-cprop" since r8-1163-g7078979b291419f3

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
  <bb 2> [local count: 118111600]:
  c_lsm.6_7 = c;
  niters.8_1 = -c_lsm.6_7;
  if (c_lsm.6_7 > 240)
    goto <bb 11>; [10.00%]
  else
    goto <bb 6>; [90.00%]

  <bb 6> [local count: 106300440]:
  _18 = niters.8_1 + 240;
  _19 = _18 >> 4;
  # RANGE [1, 15] NONZERO 15
  bnd.9_17 = _19 + 1;

but here c == 0 and thus _19 + 1 is 16.  The number of latch invocations is 255
but the number of iterations is that + 1 and thus zero in the IVs type.  This
is why we have num_itersm1 and so I guess

      /* Peeling algorithm guarantees that vector loop bound is at least ONE,
         we set range information to make niters analyzer's life easier.  */
      if (stmts != NULL && log_vf)
        set_range_info (niters_vector, VR_RANGE,
                        wi::to_wide (build_int_cst (type, 1)),
                        wi::to_wide (fold_build2 (RSHIFT_EXPR, type,
                                                  TYPE_MAX_VALUE (type),
                                                  log_vf)));

needs to use TYPE_MAX_VALUE + 1 >> log_vf here to be on the safe side for the
"non-representable" niter value.

[Bug tree-optimization/98117] [8/9/10/11 Regression] wrong code with "-O3 -fno-tree-scev-cprop" since r8-1163-g7078979b291419f3

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rsandifo at gcc dot gnu.org

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
In fact there is alrady

      /* Create: niters >> log2(vf) */
      /* If it's known that niters == number of latch executions + 1 doesn't
         overflow, we can generate niters >> log2(vf); otherwise we generate
         (niters - vf) >> log2(vf) + 1 by using the fact that we know ratio
         will be at least one.  */

so we know about this "defect".  The computation method translates easily
to the range case (unconditionally).  Unfortunately for some 'degenerate'
cases where we arrive with const_vf == 1 we'll compute [1, 0] "ranges"
this way which ICEs in niter compute.

The question is whether we can construct cases we miscompile with such
large niter and VF == 1 (full SLP).  As noted when I added niter_m1 all
uses of 'niter' would have to go away :/

For now I'm testing the "ugly"

diff --git a/gcc/tree-vect-loop-manip.c b/gcc/tree-vect-loop-manip.c
index 36179188f6d..36f218e7f6e 100644
--- a/gcc/tree-vect-loop-manip.c
+++ b/gcc/tree-vect-loop-manip.c
@@ -2034,13 +2034,21 @@ vect_gen_vector_loop_niters (loop_vec_info loop_vinfo,
tree niters,
       niters_vector = force_gimple_operand (niters_vector, &stmts, true, var);
       gsi_insert_seq_on_edge_immediate (pe, stmts);
       /* Peeling algorithm guarantees that vector loop bound is at least ONE,
-        we set range information to make niters analyzer's life easier.  */
+        we set range information to make niters analyzer's life easier.
+        Note the number of latch iteration value can be TYPE_MAX_VALUE so
+        we have to represent the vector niter TYPE_MAX_VALUE + 1 >> log_vf. 
*/
       if (stmts != NULL && log_vf)
        set_range_info (niters_vector, VR_RANGE,
-                       wi::to_wide (build_int_cst (type, 1)),
-                       wi::to_wide (fold_build2 (RSHIFT_EXPR, type,
-                                                 TYPE_MAX_VALUE (type),
-                                                 log_vf)));
+                       wi::one (TYPE_PRECISION (type)),
+                       /* ???  Avoid creating [1, 0].  */
+                       const_vf == 1
+                       ? wi::max_value (TYPE_PRECISION (type),
+                                        TYPE_SIGN (type))
+                       : (wi::rshift (wi::max_value (TYPE_PRECISION (type),
+                                                     TYPE_SIGN (type))
+                                      - (const_vf - 1),
+                                      exact_log2 (const_vf), TYPE_SIGN (type))
+                          + 1));
     }
   *niters_vector_ptr = niters_vector;
   *step_vector_ptr = step_vector;

[Bug tree-optimization/98117] [8/9/10/11 Regression] wrong code with "-O3 -fno-tree-scev-cprop" since r8-1163-g7078979b291419f3

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Richard Biener <rguenth@gcc.gnu.org>:

https://gcc.gnu.org/g:cdcbef3c3310a14f2994982b44cb1f8e14c77232

commit r11-5820-gcdcbef3c3310a14f2994982b44cb1f8e14c77232
Author: Richard Biener <rguenther@suse.de>
Date:   Mon Dec 7 10:29:07 2020 +0100

    tree-optimization/98117 - fix range set by vectorization on niter IVs

    This avoids the degenerate case of a TYPE_MAX_VALUE latch iteration
    count value causing wrong range info for the vector IV.  There's
    still the case of VF == 1 where if we don't know whether we hit the
    above case we cannot emit a range.

    2020-12-07  Richard Biener  <rguenther@suse.de>

            PR tree-optimization/98117
            * tree-vect-loop-manip.c (vect_gen_vector_loop_niters):
            Properly handle degenerate niter when setting the vector
            loop IV range.

            * gcc.dg/torture/pr98117.c: New testcase.

[Bug tree-optimization/98117] [8/9/10 Regression] wrong code with "-O3 -fno-tree-scev-cprop" since r8-1163-g7078979b291419f3

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[8/9/10/11 Regression]      |[8/9/10 Regression] wrong
                   |wrong code with "-O3        |code with "-O3
                   |-fno-tree-scev-cprop" since |-fno-tree-scev-cprop" since
                   |r8-1163-g7078979b291419f3   |r8-1163-g7078979b291419f3
      Known to work|                            |11.0
      Known to fail|                            |10.2.0

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed on trunk sofar.

[Bug tree-optimization/98117] [8/9/10 Regression] wrong code with "-O3 -fno-tree-scev-cprop" since r8-1163-g7078979b291419f3

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Richard Biener
<rguenth@gcc.gnu.org>:

https://gcc.gnu.org/g:69894ce172412996c10c89838717980ede7c9003

commit r10-9247-g69894ce172412996c10c89838717980ede7c9003
Author: Richard Biener <rguenther@suse.de>
Date:   Mon Dec 7 10:29:07 2020 +0100

    tree-optimization/98117 - fix range set by vectorization on niter IVs

    This avoids the degenerate case of a TYPE_MAX_VALUE latch iteration
    count value causing wrong range info for the vector IV.  There's
    still the case of VF == 1 where if we don't know whether we hit the
    above case we cannot emit a range.

    2020-12-07  Richard Biener  <rguenther@suse.de>

            PR tree-optimization/98117
            * tree-vect-loop-manip.c (vect_gen_vector_loop_niters):
            Properly handle degenerate niter when setting the vector
            loop IV range.

            * gcc.dg/torture/pr98117.c: New testcase.

    (cherry picked from commit cdcbef3c3310a14f2994982b44cb1f8e14c77232)

[Bug tree-optimization/98117] [8/9 Regression] wrong code with "-O3 -fno-tree-scev-cprop" since r8-1163-g7078979b291419f3

[cvs-commit at gcc dot gnu.org]

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

--- Comment #8 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-9 branch has been updated by Richard Biener
<rguenth@gcc.gnu.org>:

https://gcc.gnu.org/g:4db478784807708c031a77ae11850529fa5ecff1

commit r9-9288-g4db478784807708c031a77ae11850529fa5ecff1
Author: Richard Biener <rguenther@suse.de>
Date:   Mon Dec 7 10:29:07 2020 +0100

    tree-optimization/98117 - fix range set by vectorization on niter IVs

    This avoids the degenerate case of a TYPE_MAX_VALUE latch iteration
    count value causing wrong range info for the vector IV.  There's
    still the case of VF == 1 where if we don't know whether we hit the
    above case we cannot emit a range.

    2020-12-07  Richard Biener  <rguenther@suse.de>

            PR tree-optimization/98117
            * tree-vect-loop-manip.c (vect_gen_vector_loop_niters):
            Properly handle degenerate niter when setting the vector
            loop IV range.

            * gcc.dg/torture/pr98117.c: New testcase.

    (cherry picked from commit 69894ce172412996c10c89838717980ede7c9003)

[Bug tree-optimization/98117] [8 Regression] wrong code with "-O3 -fno-tree-scev-cprop" since r8-1163-g7078979b291419f3

[cvs-commit at gcc dot gnu.org]

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

--- Comment #9 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-8 branch has been updated by Richard Biener
<rguenth@gcc.gnu.org>:

https://gcc.gnu.org/g:c6da7015827a0557108a65f384419cddd6f8ba57

commit r8-10920-gc6da7015827a0557108a65f384419cddd6f8ba57
Author: Richard Biener <rguenther@suse.de>
Date:   Mon Dec 7 10:29:07 2020 +0100

    tree-optimization/98117 - fix range set by vectorization on niter IVs

    This avoids the degenerate case of a TYPE_MAX_VALUE latch iteration
    count value causing wrong range info for the vector IV.  There's
    still the case of VF == 1 where if we don't know whether we hit the
    above case we cannot emit a range.

    2020-12-07  Richard Biener  <rguenther@suse.de>

            PR tree-optimization/98117
            * tree-vect-loop-manip.c (vect_gen_vector_loop_niters):
            Properly handle degenerate niter when setting the vector
            loop IV range.

            * gcc.dg/torture/pr98117.c: New testcase.

    (cherry picked from commit 69894ce172412996c10c89838717980ede7c9003)

[Bug tree-optimization/98117] [8 Regression] wrong code with "-O3 -fno-tree-scev-cprop" since r8-1163-g7078979b291419f3

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|                            |8.4.1
      Known to fail|                            |8.4.0
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed.