https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98439
--- Comment #6 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Jakub Jelinek <ja...@gcc.gnu.org>: https://gcc.gnu.org/g:05402ca65a6696a8f20a3dbcb18f47ba3bdfa268 commit r11-7235-g05402ca65a6696a8f20a3dbcb18f47ba3bdfa268 Author: Jakub Jelinek <ja...@redhat.com> Date: Sat Feb 13 16:08:29 2021 +0100 passes: Enable split4 with selective scheduling 2 [PR98439] As mentioned in the PR, we have 5 split passes (+ splitting during final). split1 is before RA and is unconditional, split2 is after RA and is gated on optimize > 0, split3 is before sched2 and is gated on defined(INSN_SCHEDULING) && optimize > 0 && flag_schedule_insns_after_reload split4 is before regstack and is gated on HAVE_ATTR_length && defined (STACK_REGS) && !gate (split3) split5 is before shorten_branches and is gated on HAVE_ATTR_length && !defined (STACK_REGS) and the splitting during final works only when !HAVE_ATTR_length. STACK_REGS is a macro enabled only on i386/x86_64. The problem with the following testcase is that split3 before sched2 is the last splitting pass for the target/command line options set, but selective scheduling unlike normal scheduling can create new instructions that need to be split, which means we ICE during final as there are insns that require splitting but nothing split them. This patch fixes it by doing split4 also when -fselective-scheduling2 is enabled on x86 and split3 has been run. As that option isn't on by default, it should slow down compilation only for those that enable that option. 2021-02-13 Jakub Jelinek <ja...@redhat.com> PR rtl-optimization/98439 * recog.c (pass_split_before_regstack::gate): Enable even when pass_split_before_sched2 is enabled if -fselective-scheduling2 is on. * gcc.target/i386/pr98439.c: New test.