https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103908
--- Comment #11 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The releases/gcc-9 branch has been updated by Jakub Jelinek <ja...@gcc.gnu.org>: https://gcc.gnu.org/g:e875dc9f975ee0a1f9468fda9ee29533cca77181 commit r9-10117-ge875dc9f975ee0a1f9468fda9ee29533cca77181 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)
