[Bug tree-optimization/86991] [8/9 Regression] ICE in vectorizable_reduction, at tree-vect-loop.c:6919

2018-11-13 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86991

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Tue Nov 13 16:14:37 2018
New Revision: 266081

URL: https://gcc.gnu.org/viewcvs?rev=266081=gcc=rev
Log:
2018-11-13  Richard Biener  

PR tree-optimization/86991
* tree-vect-loop.c (vect_is_slp_reduction): Delay reduction
group building until we have successfully detected the SLP
reduction.
(vect_is_simple_reduction): Remove fixup code here.

* gcc.dg/pr86991.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/pr86991.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-loop.c

[Bug tree-optimization/86991] [8/9 Regression] ICE in vectorizable_reduction, at tree-vect-loop.c:6919

2018-11-13 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86991

--- Comment #4 from Richard Biener  ---
So the reason in the end is failure to tear down a half-built reduction chain. 
I have a fix (finally).

[Bug tree-optimization/86991] [8/9 Regression] ICE in vectorizable_reduction, at tree-vect-loop.c:6919

2018-08-27 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86991

--- Comment #3 from Richard Biener  ---
Hmm.  To me it looks like the assert that triggers:

  if (orig_stmt_info)
gcc_assert (tmp == orig_stmt_info
|| REDUC_GROUP_FIRST_ELEMENT (tmp) == orig_stmt_info);
  else
/* We changed STMT to be the first stmt in reduction chain, hence we
   check that in this case the first element in the chain is STMT.  */
gcc_assert (tmp == stmt_info
|| REDUC_GROUP_FIRST_ELEMENT (tmp) == stmt_info);


doesn't work this way for SLP reductions with a reduction path since
tmp (STMT_VINFO_REDUC_DEF) is obviously different from stmt_info
(the first non-PHI).  But what the vectorizer tries to do makes sense.

Maybe test coverage was too low to uncover this up until now.  It looks like
the testcase relies on some unfortunate invariant code in the IL.

Did you have a testcase that computed sth more meaningful?

[Bug tree-optimization/86991] [8/9 Regression] ICE in vectorizable_reduction, at tree-vect-loop.c:6919

2018-08-22 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86991

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #2 from Richard Biener  ---
I will have a look.

[Bug tree-optimization/86991] [8/9 Regression] ICE in vectorizable_reduction, at tree-vect-loop.c:6919

2018-08-21 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86991

Martin Liška  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-08-21
 CC||marxin at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
   Target Milestone|--- |8.3
Summary|internal compiler error: in |[8/9 Regression] ICE in
   |vectorizable_reduction, at  |vectorizable_reduction, at
   |tree-vect-loop.c:6919   |tree-vect-loop.c:6919
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, started with r250382.