https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103908
--- Comment #10 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The releases/gcc-10 branch has been updated by Jakub Jelinek <ja...@gcc.gnu.org>: https://gcc.gnu.org/g:8df8eb6dd5b02d2a5b950a00c09590da423db8cc commit r10-10664-g8df8eb6dd5b02d2a5b950a00c09590da423db8cc Author: Jakub Jelinek <ja...@redhat.com> Date: Thu Jan 6 09:29:34 2022 +0100 ifcvt: Check for asm goto at the end of then_bb/else_bb in ifcvt [PR103908] On the following testcase, RTL ifcvt sees then_bb (note 7 6 8 3 [bb 3] NOTE_INSN_BASIC_BLOCK) (insn 8 7 9 3 (set (mem/c:SI (symbol_ref:DI ("b") [flags 0x2] <var_decl 0x7fdccf5b0cf0 b>) [1 b+0 S4 A32]) (const_int 1 [0x1])) "pr103908.c":6:7 81 {*movsi_internal} (nil)) (jump_insn 9 8 13 3 (parallel [ (asm_operands/v ("# insn 1") ("") 0 [] [] [ (label_ref:DI 21) ] pr103908.c:7) (clobber (reg:CC 17 flags)) ]) "pr103908.c":7:5 -1 (expr_list:REG_UNUSED (reg:CC 17 flags) (nil)) -> 21) and similarly else_bb (just with a different asm_operands template). It checks that those basic blocks have a single successor and uses last_active_insn which intentionally skips over JUMP_INSNs, sees both basic blocks contain the same set and merges them (or if the sets are different, attempts some other noce optimization). But we can't assume that the jump, even when it has only a single successor, has no side-effects. The following patch fixes it by punting if test_bb ends with a JUMP_INSN that isn't onlyjump_p. 2022-01-06 Jakub Jelinek <ja...@redhat.com> PR rtl-optimization/103908 * ifcvt.c (bb_valid_for_noce_process_p): Punt on bbs ending with asm goto. * gcc.target/i386/pr103908.c: New test. (cherry picked from commit 80ad67e2af0620d58d57d0406dc22693cf5b8ca9)
