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

["rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.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.