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.