https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85673
Alexander Monakov <amonakov at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |ASSIGNED Last reconfirmed| |2018-05-06 CC| |abel at gcc dot gnu.org, | |amonakov at gcc dot gnu.org Blocks| |84301 Assignee|unassigned at gcc dot gnu.org |amonakov at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Alexander Monakov <amonakov at gcc dot gnu.org> --- PR 84301 is related (not backported to 6/7 so failure is expected there). The fix was incomplete because 'cant_move' insn flag only restricts inter-block motion (argh!), so sel-sched is still free to move %eax assignment up. Oops. Perhaps we can additionally set sched_group_p in add_branch_dependences for pre-RA sel-sched to ensure insns stay at the end of basic block; after reload that would also pin mutex_p cond-exec insns to BB end as well. (apropos: flag_sched_group_heuristic should be removed, the way it's used in rank_for_schedule is not a heuristic, but a correctness requirement) Overall I'm concerned that mode-switching is making unreasonable assumptions, if it really needs that some insns stay in sequence just before function return, they should be arranged to have a barrier insn or SCHED_GROUP_P from the beginning. So maybe it's better to adjust mode-switching instead, but unfortunately it's not quite obvious how it works :) Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84301 [Bug 84301] [6/7 Regression] ICE in create_pre_exit, at mode-switching.c:451