https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108519
--- Comment #5 from Kewen Lin <linkw at gcc dot gnu.org> --- (In reply to Alexander Monakov from comment #1) > We diverge in sched1 due to extra calls to advance_one_cycle when scheduling > a BB that is empty apart from one debug insn. The following patch adds a > hexdump of automaton state to make the problem evident: > > diff --git a/gcc/sched-rgn.cc b/gcc/sched-rgn.cc > index 420c45dff..c09398897 100644 > --- a/gcc/sched-rgn.cc > +++ b/gcc/sched-rgn.cc > @@ -3098,8 +3098,14 @@ save_state_for_fallthru_edge (basic_block last_bb, > state_t state) > memcpy (bb_state[f->dest->index], state, > dfa_state_size); > if (sched_verbose >= 5) > - fprintf (sched_dump, "saving state for edge %d->%d\n", > - f->src->index, f->dest->index); > + { > + fprintf (sched_dump, "saving state for edge %d->%d\n", > + f->src->index, f->dest->index); > + for (size_t i = 0; i < dfa_state_size; i++) > + fprintf (sched_dump, "%02x%c", i[(unsigned char *)state], > + (i+1) % 16 ? ' ' : '\n'); > + fprintf(sched_dump, "\n---\n"); > + } > } > } > > With the above patch it's obvious we advance the automaton state a few extra > times when scheduling BB 3, and then inherit the modified state to BB 4. Nice tips for dumping! > > I think we don't need to schedule blocks that only contain debug insns. IBM > folks, care to test the following? Yes, I agree. I attached one patch in PR108273 which also proposed to consider DEBUG_INSN_P in no_real_insns_p, it's bootstrapped and regress-tested on powerpc64 and powerpc64le, I'm going to test it on x86 and aarch64 if it's on the right track. As to your proposed change in free_block_dependencies, I also tried that before (it can make this test case compilation happy, yes :)), but unfortunately it gets abort at 383│ free_deps_list (deps_list_t l) 384│ { 385├─> gcc_assert (deps_list_empty_p (l)); for some cases in building libgcc, the root cause is that some block can have more than one debug insn, there are some deps between them, I think the current free_block_dependencies has the assumption that the deps which need to be resolved would be handled during scheduling insn, so it calls sched_free_deps with resolved_p "true", then it still leaves the deps like INSN_FORW_DEPS uncleared, which is unexpected and caused the ICE.