https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106082
Bug ID: 106082 Summary: [13 Regression] Recent change broke m68k Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: law at gcc dot gnu.org Target Milestone: --- Target: m68k This change: commit 4f77738c3b44cb6b7bfe2a7ef823a5d9d75c0e79 (HEAD, refs/bisect/bad) Author: Richard Biener <rguent...@suse.de> Date: Thu Apr 14 14:06:22 2022 +0200 rtl-optimization/105231 - distribute_notes and REG_EH_REGION The following mitigates a problem in combine distribute_notes which places an original REG_EH_REGION based on only may_trap_p which is good to test whether a non-call insn can possibly throw but not if actually it does or we care. That's something we decided at RTL expansion time where we possibly still know the insn evaluates to a constant. In fact, the REG_EH_REGION note with lp > 0 can only come from the original i3 and an assert is added to that effect. That means we only need to retain the note on i3 or, if that cannot trap, drop it but we should never move it to i2. The following places constraints on the insns to combine with non-call exceptions since we cannot handle the case where we have more than one EH side-effect in the IL. The patch also makes sure we can accumulate that on i3 and do not split a possible exception raising part of it to i2. As a special case we do not place any restriction on all externally throwing insns when there is no REG_EH_REGION present. 2022-04-22 Richard Biener <rguent...@suse.de> PR rtl-optimization/105231 * combine.cc (distribute_notes): Assert that a REG_EH_REGION with landing pad > 0 is from i3. Put any REG_EH_REGION note on i3 or drop it if the insn can not trap. (try_combine): Ensure that we can merge REG_EH_REGION notes with non-call exceptions. Ensure we are not splitting a trapping part of an insn with non-call exceptions when there is any REG_EH_REGION note to preserve. * gcc.dg/torture/pr105231.c: New testcase. Broke various tests on the m68k. This is from nested-func-5.c: ./xgcc -B./ -O2 j.c -c j.c: In function ‘recursive’: j.c:28:1: error: in basic block 2: 28 | } | ^ j.c:28:1: error: flow control insn inside a basic block (call_insn 23 22 24 2 (call (mem:QI (symbol_ref:SI ("__clear_cache")) [0 S1 A8]) (const_int 8 [0x8])) "j.c":6:13 406 {*call} (expr_list:REG_CALL_DECL (symbol_ref:SI ("__clear_cache")) (nil)) (expr_list (use (mem:SI (plus:SI (reg/f:SI 15 %sp) (scratch:SI)) [0 S4 A8])) (nil))) during RTL pass: combine j.c:28:1: internal compiler error: in rtl_verify_bb_insns, at cfgrtl.cc:2797 This can be seen with a m68k-linux-gnu cross compiler. Sorry I took so long to report this. I'd assumed the failures were a result of the binutils work which started warning for bogus rwx segments which happened about the same time.