This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug tree-optimization/68549] [6 Regression] ICE: in verify_loop_structure, at cfgloop.c:1669
- From: "rguenth at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Thu, 26 Nov 2015 10:46:23 +0000
- Subject: [Bug tree-optimization/68549] [6 Regression] ICE: in verify_loop_structure, at cfgloop.c:1669
- Auto-submitted: auto-generated
- References: <bug-68549-4 at http dot gcc dot gnu dot org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68549
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2015-11-26
CC| |vries at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
It's a different cause though as it is from rtl_loop_init checking for
the case LOOPS_NEED_FIXUP is not set. Thus a pass preceeding isn't
updating loop->latch.
I think that was by design (LOOPS_MAY_HAVE_MULTIPLE_LATCHES was supposed
to be "->latch doesn't matter, only keep header correct" which is what
we require from passes not having initialized loops).
Of course that's a somewhat conflicting requirement and thus the cleanest
approach would be to split the latch flags even more. LOOPS_HAVE_LATCHES
(otherwise ->latch cannot be relied on), LOOPS_MAY_HAVE_MULTIPLE_LATCHES
(->latch may be NULL and do not disambiguate such loops),
~LOOPS_MAY_HAVE_MULTIPLE_LATCHES (disambiguate, all loops have ->latch
non-NULL), LOOPS_HAVE_SIMPLE_LATCHES (latches are forwarders).
The current state is really broken though in case we have
LOOPS_MAY_HAVE_MULTIPLE_LATCHES users that rely on ->latch reflecting
reality. The flag is not explicitely requested by any pass though
so a simple option would be to revert the checking bits for now
and revisit the whole issue in stage1.