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.
