https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111822
--- Comment #16 from Hongtao Liu <liuhongt at gcc dot gnu.org> --- (In reply to Uroš Bizjak from comment #11) > (In reply to Richard Biener from comment #10) > > The easiest fix would be to refuse applying STV to a insn that > > can_throw_internal () (that's an insn that has associated EH info). > > Updating > > in this case would require splitting the BB or at least moving the now > > no longer throwing insn to the next block (along the fallthru edge). > > This would be simply: > > --cut here-- > diff --git a/gcc/config/i386/i386-features.cc > b/gcc/config/i386/i386-features.cc > index 1de2a07ed75..90acb33db49 100644 > --- a/gcc/config/i386/i386-features.cc > +++ b/gcc/config/i386/i386-features.cc > @@ -437,6 +437,10 @@ scalar_chain::add_insn (bitmap candidates, unsigned int > insn_uid, > && !HARD_REGISTER_P (SET_DEST (def_set))) > bitmap_set_bit (defs, REGNO (SET_DEST (def_set))); > > + if (cfun->can_throw_non_call_exceptions > + && can_throw_internal (insn)) > + return false; > + > /* ??? The following is quadratic since analyze_register_chain > iterates over all refs to look for dual-mode regs. Instead this > should be done separately for all regs mentioned in the chain once. */ > --cut here-- > > But I think, we could do better. Adding CC. It looks like the similar issue we have solved in PR89650 with r9-6543-g12fb7712a8a20f. We manually split the block after insn.
