[Bug tree-optimization/111878] [14 Regression] ICE: in get_loop_exit_edges, at cfgloop.cc:1204 with -O3 -fgraphite-identity -fsave-optimization-record/-fdump-tree-graphite/-fopt-info since r14-4708-gd

2023-10-31 Thread sjames at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111878

Sam James  changed:

   What|Removed |Added

 CC||tnfchris at gcc dot gnu.org
Summary|[14 Regression] ICE: in |[14 Regression] ICE: in
   |get_loop_exit_edges, at |get_loop_exit_edges, at
   |cfgloop.cc:1204 with -O3|cfgloop.cc:1204 with -O3
   |-fgraphite-identity |-fgraphite-identity
   |-fsave-optimization-record/ |-fsave-optimization-record/
   |-fdump-tree-graphite/-fopt- |-fdump-tree-graphite/-fopt-
   |info|info since
   ||r14-4708-gd65e38e616e7ac

--- Comment #6 from Sam James  ---
d65e38e616e7ac8157ef04b55beb6670f2c0f142 is the first bad commit
commit d65e38e616e7ac8157ef04b55beb6670f2c0f142
Author: Tamar Christina 
Date:   Wed Oct 18 09:02:12 2023 +0100

middle-end: Refactor vectorizer loop conditionals and separate out IV to
new variables

i.e. r14-4708-gd65e38e616e7ac

[Bug tree-optimization/111878] [14 Regression] ICE: in get_loop_exit_edges, at cfgloop.cc:1204 with -O3 -fgraphite-identity -fsave-optimization-record/-fdump-tree-graphite/-fopt-info since r14-4708-gd

2023-10-31 Thread tnfchris at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111878

Tamar Christina  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |tnfchris at gcc dot 
gnu.org

--- Comment #7 from Tamar Christina  ---
Thanks for the report.

Graphite is feeding it a junk loop.  The loop's latch block is invalid. In fact
the block isn't even part of the loop.

Since the loop structure Graphite passes it is broken, get_loop_exit_edges (..)
asserts.

Previously for this situation the call would silently return NULL for such
loops.
I'd argue this is a bug in Graphite, but will restore the return NULL for
broken loops.

[Bug tree-optimization/111878] [14 Regression] ICE: in get_loop_exit_edges, at cfgloop.cc:1204 with -O3 -fgraphite-identity -fsave-optimization-record/-fdump-tree-graphite/-fopt-info since r14-4708-gd

2023-11-16 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111878

--- Comment #8 from CVS Commits  ---
The master branch has been updated by Tamar Christina :

https://gcc.gnu.org/g:7a496b7ce105185be12e023e749c90d5f7561879

commit r14-5529-g7a496b7ce105185be12e023e749c90d5f7561879
Author: Tamar Christina 
Date:   Thu Nov 16 12:11:22 2023 +

middle-end: skip checking loop exits if loop malformed [PR111878]

Before my refactoring if the loop->latch was incorrect then
find_loop_location
skipped checking the edges and would eventually return a dummy location.

It turns out that a loop can have
loops_state_satisfies_p (LOOPS_HAVE_RECORDED_EXITS) but also not have a
latch
in which case get_loop_exit_edges traps.

This restores the old behavior.

gcc/ChangeLog:

PR tree-optimization/111878
* tree-vect-loop-manip.cc (find_loop_location): Skip edges check if
latch incorrect.

gcc/testsuite/ChangeLog:

PR tree-optimization/111878
* gcc.dg/graphite/pr111878.c: New test.

[Bug tree-optimization/111878] [14 Regression] ICE: in get_loop_exit_edges, at cfgloop.cc:1204 with -O3 -fgraphite-identity -fsave-optimization-record/-fdump-tree-graphite/-fopt-info since r14-4708-gd

2023-11-16 Thread tnfchris at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111878

Tamar Christina  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #9 from Tamar Christina  ---
Fixed, thanks for the report.