[Bug tree-optimization/66623] Unsafe FP math reduction used in strict math mode

[Bug tree-optimization/66623] Unsafe FP math reduction used in strict math mode

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2015-06-22
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
So this boils down to the vectorizer disabling the associative math test if
it does outer-loop vectorization:

      nested_cycle = (loop != LOOP_VINFO_LOOP (loop_vinfo));
      reduc_stmt = vect_force_simple_reduction (loop_vinfo, phi, !nested_cycle,
                                                &double_reduc);

but I agree with your assessment that even with outer loop vectorization
it is not safe.  A patch as simple as

Index: gcc/tree-vect-loop.c
===================================================================
--- gcc/tree-vect-loop.c        (revision 224723)
+++ gcc/tree-vect-loop.c        (working copy)
@@ -2610,14 +2610,14 @@ vect_is_simple_reduction_1 (loop_vec_inf
   /* Check that it's ok to change the order of the computation.
      Generally, when vectorizing a reduction we change the order of the
      computation.  This may change the behavior of the program in some
-     cases, so we need to check that this is ok.  One exception is when
-     vectorizing an outer-loop: the inner-loop is executed sequentially,
-     and therefore vectorizing reductions in the inner-loop during
-     outer-loop vectorization is safe.  */
+     cases, so we need to check that this is ok.  Even when
+     vectorizing an outer-loop and the inner-loop is executed sequentially,
+     vectorizing reductions in the inner-loop during outer-loop vectorization
+     is _not_ safe as the final reduction in the outer loop associates
+     the inner loop results.  */

   /* CHECKME: check for !flag_finite_math_only too?  */
-  if (SCALAR_FLOAT_TYPE_P (type) && !flag_associative_math
-      && check_reduction)
+  if (SCALAR_FLOAT_TYPE_P (type) && !flag_associative_math)
     {
       /* Changing the order of operations changes the semantics.  */
       if (dump_enabled_p ())
@@ -2625,8 +2625,7 @@ vect_is_simple_reduction_1 (loop_vec_inf
                        "reduction: unsafe fp math optimization: ");
       return NULL;
     }
-  else if (INTEGRAL_TYPE_P (type) && TYPE_OVERFLOW_TRAPS (type)
-          && check_reduction)
+  else if (INTEGRAL_TYPE_P (type) && TYPE_OVERFLOW_TRAPS (type))
     {
       /* Changing the order of operations changes the semantics.  */
       if (dump_enabled_p ())
@@ -2634,7 +2633,7 @@ vect_is_simple_reduction_1 (loop_vec_inf
                        "reduction: unsafe int math optimization: ");
       return NULL;
     }
-  else if (SAT_FIXED_POINT_TYPE_P (type) && check_reduction)
+  else if (SAT_FIXED_POINT_TYPE_P (type))
     {
       /* Changing the order of operations changes the semantics.  */
       if (dump_enabled_p ())


Might have some testsuite fallout though.

[Bug tree-optimization/66623] Unsafe FP math reduction used in strict math mode

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
It's supposed to handle cases like (vect-outer-fir-big-array.c):

 for (k = 0; k < 4; k++) {
  for (i = 0; i < N; i++) {
    diff = 0;
    for (j = k; j < M; j+=4) {
      diff += in[j+i]*coeff[j];
    }
    out[i] += diff;
  }
 }

where indeed there is no association in the outer loop.  So it indeed _is_
about double-reductions only.  The current code setup isn't prepared to
detect the situation in question easily (and the patch is too strict).

[Bug tree-optimization/66623] Unsafe FP math reduction used in strict math mode

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED
      Known to fail|                            |7.5.0

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed in GCC 8+.