[Bug rtl-optimization/105231] New: [12 Regression] ICE: in rtl_verify_bb_insns, at cfgrtl.cc:2797 (flow control insn inside a basic block) with custom flags

[Bug rtl-optimization/105231] New: [12 Regression] ICE: in rtl_verify_bb_insns, at cfgrtl.cc:2797 (flow control insn inside a basic block) with custom flags

[zsojka at seznam dot cz]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231

            Bug ID: 105231
           Summary: [12 Regression] ICE: in rtl_verify_bb_insns, at
                    cfgrtl.cc:2797 (flow control insn inside a basic
                    block) with custom flags
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Keywords: ice-on-valid-code
          Severity: normal
          Priority: P3
         Component: rtl-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: zsojka at seznam dot cz
  Target Milestone: ---
              Host: x86_64-pc-linux-gnu
            Target: x86_64-pc-linux-gnu

Created attachment 52784
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52784&action=edit
reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-gcc -Os -fsanitize-coverage=trace-pc
-fnon-call-exceptions --param=max-cse-insns=1 -frounding-math -mstack-arg-probe
-fsanitize=thread -m32 testcase.c
testcase.c: In function 'foo':
testcase.c:7:1: error: in basic block 3:
    7 | }
      | ^
testcase.c:7:1: error: flow control insn inside a basic block
(insn 78 22 24 3 (set (reg:XF 99)
        (float_extend:XF (mem/u/c:SF (symbol_ref/u:SI ("*.LC0") [flags 0x2]) [0
 S4 A32]))) 166 {*extendsfxf2_i387}
     (expr_list:REG_EH_REGION (const_int 1 [0x1])
        (nil)))
during RTL pass: combine
testcase.c:7:1: internal compiler error: in rtl_verify_bb_insns, at
cfgrtl.cc:2797
0x76ddbe _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
        /repo/gcc-trunk/gcc/rtl-error.cc:108
0xe954e3 rtl_verify_bb_insns
        /repo/gcc-trunk/gcc/cfgrtl.cc:2797
0xe9ea5c rtl_verify_flow_info_1
        /repo/gcc-trunk/gcc/cfgrtl.cc:2883
0xe83dfa verify_flow_info()
        /repo/gcc-trunk/gcc/cfghooks.cc:282
0x22a4bb8 checking_verify_flow_info
        /repo/gcc-trunk/gcc/cfghooks.h:214
0x22a4bb8 try_optimize_cfg
        /repo/gcc-trunk/gcc/cfgcleanup.cc:2980
0x22a4bb8 cleanup_cfg(int)
        /repo/gcc-trunk/gcc/cfgcleanup.cc:3143
0x22d0820 rest_of_handle_combine
        /repo/gcc-trunk/gcc/combine.cc:14942
0x22d0820 execute
        /repo/gcc-trunk/gcc/combine.cc:14976
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

$ x86_64-pc-linux-gnu-gcc -v                                                   
                                          Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r12-8090-20220411190659-g1774ab84863-checking-yes-rtl-df-extra-nobootstrap-pr105211-pr105214-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r12-8090-20220411190659-g1774ab84863-checking-yes-rtl-df-extra-nobootstrap-pr105211-pr105214-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.1 20220411 (experimental) (GCC)

Both vanilla gcc r12-8090 and with pr105211 and pr105214 patches applies ICE
the same way.

[Bug target/105231] [12 Regression] ICE: in rtl_verify_bb_insns, at cfgrtl.cc:2797 (flow control insn inside a basic block) with custom flags

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|rtl-optimization            |target
   Target Milestone|---                         |12.0

[Bug rtl-optimization/105231] [12 Regression] ICE: in rtl_verify_bb_insns, at cfgrtl.cc:2797 (flow control insn inside a basic block) with custom flags

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |segher at gcc dot gnu.org
          Component|target                      |rtl-optimization
           Keywords|                            |needs-bisection

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
As a quick guess combine eventually doesn't honor non-call EH and combines
insns in a way that puts a trapping insn before another one.  Could also be a
x86 target specific pattern/splitter issue of course (not sure if passes are
supposed to split blocks - a splitter definitely can't).

[Bug rtl-optimization/105231] [12 Regression] ICE: in rtl_verify_bb_insns, at cfgrtl.cc:2797 (flow control insn inside a basic block) with custom flags since r12-4767-g81342e95827f77c0

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
                 CC|                            |marxin at gcc dot gnu.org,
                   |                            |rguenth at gcc dot gnu.org
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2022-04-12
            Summary|[12 Regression] ICE: in     |[12 Regression] ICE: in
                   |rtl_verify_bb_insns, at     |rtl_verify_bb_insns, at
                   |cfgrtl.cc:2797 (flow        |cfgrtl.cc:2797 (flow
                   |control insn inside a basic |control insn inside a basic
                   |block) with custom flags    |block) with custom flags
                   |                            |since
                   |                            |r12-4767-g81342e95827f77c0
           Keywords|needs-bisection             |

--- Comment #2 from Martin Liška <marxin at gcc dot gnu.org> ---
Started with r12-4767-g81342e95827f77c0.

[Bug rtl-optimization/105231] [12 Regression] ICE: in rtl_verify_bb_insns, at cfgrtl.cc:2797 (flow control insn inside a basic block) with custom flags since r12-4767-g81342e95827f77c0

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
Before combine we had

(insn 22 17 78 3 (set (reg:SF 92)
        (mem/u/c:SF (symbol_ref/u:SI ("*.LC0") [flags 0x2]) [0  S4 A32]))
"t.c":6:3 142 {*movsf_internal}
     (expr_list:REG_EQUAL (const_double:SF 1.8446744073709551616e+19
[0x0.8p+65])
        (nil)))
(insn 78 22 24 3 (set (reg:XF 99)
        (float_extend:XF (reg:SF 92))) 166 {*extendsfxf2_i387}
     (expr_list:REG_DEAD (reg:SF 92)
        (expr_list:REG_EQUAL (const_double:XF 1.8446744073709551616e+19
[0x0.8p+65])
            (nil))))
(insn 24 78 65 3 (set (reg:XF 90)
        (plus:XF (reg:XF 90)
            (reg:XF 99))) "t.c":6:3 1070 {*fop_xf_comm_i387}
     (expr_list:REG_EH_REGION (const_int 1 [0x1])
        (nil)))
;;  succ:       9 [never]  count:0 (precise) (ABNORMAL,EH)

after:

(note 22 17 78 3 NOTE_INSN_DELETED)
(insn 78 22 24 3 (set (reg:XF 99)
        (float_extend:XF (mem/u/c:SF (symbol_ref/u:SI ("*.LC0") [flags 0x2]) [0
 S4 A32]))) 166 {*extendsfxf2_i387}
     (expr_list:REG_EH_REGION (const_int 1 [0x1])
        (nil)))
(insn 24 78 26 3 (set (reg:XF 90)
        (mem/u/c:XF (symbol_ref/u:SI ("*.LC3") [flags 0x2]) [0  S12 A128]))
"t.c":6:3 140 {*movxf_internal}
     (nil))
(insn 26 24 27 3 (set (reg:DF 83 [ _2 ])
        (float_truncate:DF (reg:XF 90))) "t.c":6:3 170 {truncxfdf2}
     (expr_list:REG_DEAD (reg:XF 90)
        (expr_list:REG_EH_REGION (const_int 1 [0x1])
            (nil))))
;;  succ:       9 [never]  count:0 (precise) (ABNORMAL,EH)

now sure where the REG_EH_REGION note on insn 78 comes from.  I suppose it's
from

Trying 78, 17 -> 24:
   78: r99:XF=float_extend([`*.LC0'])
      REG_EQUAL 1.8446744073709551616e+19
   17: r90:XF=[`*.LC1']
      REG_EQUAL -1.444529636382101633e+18
   24: r90:XF=r90:XF+r99:XF
      REG_EH_REGION 0x1
...
Successfully matched this instruction:
(set (reg:XF 99)
    (float_extend:XF (mem/u/c:SF (symbol_ref/u:SI ("*.LC0") [flags 0x2]) [0  S4
A32])))
Successfully matched this instruction:
(set (reg:XF 90)
    (mem/u/c:XF (symbol_ref/u:SI ("*.LC3") [flags 0x2]) [0  S12 A128]))
allowing combination of insns 17, 78 and 24
original costs 12 + 4 + 4 = 20
replacement costs 4 + 12 = 16
deferring deletion of insn with uid = 17.
modifying insn i2    78: r99:XF=float_extend([`*.LC0'])
      REG_EH_REGION 0x1
deferring rescan insn with uid = 78.
modifying insn i3    24: r90:XF=[`*.LC3']
deferring rescan insn with uid = 24.

(removed failing matches)

So it does look like a combine problem to me which moves the EH note to
a random place.  Also insn 26 still shows up from nowhere... (maybe that's
CFG cleanup).

[Bug rtl-optimization/105231] [12 Regression] ICE: in rtl_verify_bb_insns, at cfgrtl.cc:2797 (flow control insn inside a basic block) with custom flags since r12-4767-g81342e95827f77c0

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ebotcazou at gcc dot gnu.org

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
So interestingly distribute_notes sees

(gdb) p debug_rtx (i2)
(insn 78 22 24 3 (set (reg:XF 99)
        (float_extend:XF (mem/u/c:SF (symbol_ref/u:SI ("*.LC0") [flags 0x2]) [0
 S4 A32]))) 166 {*extendsfxf2_i387}
     (nil))

as may_trap_p (), but we did not place an EH note on this previously.  I'm not
sure how the RTL IL is sanitized but eventually we simply take what RTL
expansion yields as granted.

Given combine doesn't split blocks (otherwise it would have "fixed" this),
it might make more sense to always put the note on i3 or drop it if i3
cannot trap?

Alternatively we can of course fail the combination if there's any EH note
and it's not (only) i3 that may_trap_p ().

diff --git a/gcc/combine.cc b/gcc/combine.cc
index 53dcac92abc..65e11c3e682 100644
--- a/gcc/combine.cc
+++ b/gcc/combine.cc
@@ -14185,8 +14185,8 @@ distribute_notes (rtx notes, rtx_insn *from_insn,
rtx_insn *i3, rtx_insn *i2,
              gcc_assert (cfun->can_throw_non_call_exceptions);
              if (may_trap_p (i3))
                place = i3;
-             else if (i2 && may_trap_p (i2))
-               place = i2;
+             /* ???  Even if i2 may trap we cannot throw from there since
+                it will be not last in the BB.  Drop the EH in this case.  */
              /* ??? Otherwise assume we've combined things such that we
                 can now prove that the instructions can't trap.  Drop the
                 note in this case.  */

fixes the testcase (and loses the EH).

As said, I'm not sure about the EH state on RTL, insn_nothrow_p is false
on the original float_extent.

[Bug rtl-optimization/105231] [12 Regression] ICE: in rtl_verify_bb_insns, at cfgrtl.cc:2797 (flow control insn inside a basic block) with custom flags since r12-4767-g81342e95827f77c0

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
may_trap_p triggers on the (float_extend:XF ...) because

      /* Any floating arithmetic may trap.  */
      if (FLOAT_MODE_P (GET_MODE (x)) && flag_trapping_math)
        return 1;

with all that I think the proposed change is reasonable.

[Bug rtl-optimization/105231] [12 Regression] ICE: in rtl_verify_bb_insns, at cfgrtl.cc:2797 (flow control insn inside a basic block) with custom flags since r12-4767-g81342e95827f77c0

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231

--- Comment #6 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> So interestingly distribute_notes sees
> 
> (gdb) p debug_rtx (i2)
> (insn 78 22 24 3 (set (reg:XF 99)
>         (float_extend:XF (mem/u/c:SF (symbol_ref/u:SI ("*.LC0") [flags 0x2])
> [0  S4 A32]))) 166 {*extendsfxf2_i387}
>      (nil))
> 
> as may_trap_p (), but we did not place an EH note on this previously.  I'm
> not sure how the RTL IL is sanitized but eventually we simply take what RTL
> expansion yields as granted.

This is the insn before combine though:

(insn 78 22 24 3 (set (reg:XF 99)
        (float_extend:XF (reg:SF 92))) 166 {*extendsfxf2_i387}
     (expr_list:REG_DEAD (reg:SF 92)
        (expr_list:REG_EQUAL (const_double:XF 1.8446744073709551616e+19
[0x0.8p+65])
            (nil))))

so combine apparently forced the constant into the constant pool.

[Bug rtl-optimization/105231] [12 Regression] ICE: in rtl_verify_bb_insns, at cfgrtl.cc:2797 (flow control insn inside a basic block) with custom flags since r12-4767-g81342e95827f77c0

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231

--- Comment #7 from rguenther at suse dot de <rguenther at suse dot de> ---
On Tue, 12 Apr 2022, ebotcazou at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231
> 
> --- Comment #6 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> > So interestingly distribute_notes sees
> > 
> > (gdb) p debug_rtx (i2)
> > (insn 78 22 24 3 (set (reg:XF 99)
> >         (float_extend:XF (mem/u/c:SF (symbol_ref/u:SI ("*.LC0") [flags 0x2])
> > [0  S4 A32]))) 166 {*extendsfxf2_i387}
> >      (nil))
> > 
> > as may_trap_p (), but we did not place an EH note on this previously.  I'm
> > not sure how the RTL IL is sanitized but eventually we simply take what RTL
> > expansion yields as granted.
> 
> This is the insn before combine though:
> 
> (insn 78 22 24 3 (set (reg:XF 99)
>         (float_extend:XF (reg:SF 92))) 166 {*extendsfxf2_i387}
>      (expr_list:REG_DEAD (reg:SF 92)
>         (expr_list:REG_EQUAL (const_double:XF 1.8446744073709551616e+19
> [0x0.8p+65])
>             (nil))))
> 
> so combine apparently forced the constant into the constant pool.

Yes, but still the float_extend:XF would have made may_trap_p say
the insn possibly traps but there's no EH on it despite
-fnon-call-exceptions.

[Bug rtl-optimization/105231] [12 Regression] ICE: in rtl_verify_bb_insns, at cfgrtl.cc:2797 (flow control insn inside a basic block) with custom flags since r12-4767-g81342e95827f77c0

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231

--- Comment #8 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> Yes, but still the float_extend:XF would have made may_trap_p say
> the insn possibly traps but there's no EH on it despite
> -fnon-call-exceptions.

The REG_EH note is added by make_reg_eh_region_note but then removed by
purge_dead_edges because of the REG_EQUAL note:

  /* If this instruction cannot trap, remove REG_EH_REGION notes.  */
  if (NONJUMP_INSN_P (insn)
      && (note = find_reg_note (insn, REG_EH_REGION, NULL)))
    {
      rtx eqnote;

      if (! may_trap_p (PATTERN (insn))
          || ((eqnote = find_reg_equal_equiv_note (insn))
              && ! may_trap_p (XEXP (eqnote, 0))))
        remove_note (insn, note);
    }

[Bug rtl-optimization/105231] [12 Regression] ICE: in rtl_verify_bb_insns, at cfgrtl.cc:2797 (flow control insn inside a basic block) with custom flags since r12-4767-g81342e95827f77c0

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231

--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
Initially we generate

(insn 36 35 37 (set (reg:XF 95)
        (float_extend:XF (reg:SF 96))) "t.c":6:3 -1
     (expr_list:REG_EH_REGION (const_int 1 [0x1])
        (expr_list:REG_EQUAL (const_double:XF 1.8446744073709551616e+19
[0x0.8p+65])
            (nil))))

(insn 37 36 38 (set (reg:XF 94)
        (plus:XF (reg:XF 94)
            (reg:XF 95))) "t.c":6:3 -1
     (expr_list:REG_EH_REGION (const_int 1 [0x1])
        (nil)))

but then when creating BBs we end up with

(insn 36 35 37 12 (set (reg:XF 95)
        (float_extend:XF (reg:SF 96))) "t.c":6:3 -1
     (expr_list:REG_EQUAL (const_double:XF 1.8446744073709551616e+19
[0x0.8p+65])
        (nil)))
(insn 37 36 38 12 (set (reg:XF 94)
        (plus:XF (reg:XF 94)
            (reg:XF 95))) "t.c":6:3 -1
     (expr_list:REG_EH_REGION (const_int 1 [0x1])
        (nil)))
;;  succ:       17 [never]  count:0 (precise) (ABNORMAL,EH)

so it seems we retain the GIMPLE BB structure which just had

  _3 = (double) 18446744073709551614;
;;    succ:       7
;;                5

rather than splitting the EH into the now two possibly throwing stmts?

Maybe it's also specially handled because of the REG_EQUAL note?  At least
find_many_sub_basic_blocks via control_flow_insn_p doesn't consider
insns with a REG_EH_REGION note as ending a BB but it only checks
can_throw_internal which may or may not be enough here.

[Bug rtl-optimization/105231] [12 Regression] ICE: in rtl_verify_bb_insns, at cfgrtl.cc:2797 (flow control insn inside a basic block) with custom flags since r12-4767-g81342e95827f77c0

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231

--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Eric Botcazou from comment #8)
> > Yes, but still the float_extend:XF would have made may_trap_p say
> > the insn possibly traps but there's no EH on it despite
> > -fnon-call-exceptions.
> 
> The REG_EH note is added by make_reg_eh_region_note but then removed by
> purge_dead_edges because of the REG_EQUAL note:
> 
>   /* If this instruction cannot trap, remove REG_EH_REGION notes.  */
>   if (NONJUMP_INSN_P (insn)
>       && (note = find_reg_note (insn, REG_EH_REGION, NULL)))
>     {
>       rtx eqnote;
> 
>       if (! may_trap_p (PATTERN (insn))
> 	  || ((eqnote = find_reg_equal_equiv_note (insn))
> 	      && ! may_trap_p (XEXP (eqnote, 0))))
> 	remove_note (insn, note);
>     }

Interesting - so should combine maybe have this exception as well when it
tests for may_trap_p?  Not sure if the above makes sense.

[Bug rtl-optimization/105231] [12 Regression] ICE: in rtl_verify_bb_insns, at cfgrtl.cc:2797 (flow control insn inside a basic block) with custom flags since r12-4767-g81342e95827f77c0

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #10)
> (In reply to Eric Botcazou from comment #8)
> > > Yes, but still the float_extend:XF would have made may_trap_p say
> > > the insn possibly traps but there's no EH on it despite
> > > -fnon-call-exceptions.
> > 
> > The REG_EH note is added by make_reg_eh_region_note but then removed by
> > purge_dead_edges because of the REG_EQUAL note:
> > 
> >   /* If this instruction cannot trap, remove REG_EH_REGION notes.  */
> >   if (NONJUMP_INSN_P (insn)
> >       && (note = find_reg_note (insn, REG_EH_REGION, NULL)))
> >     {
> >       rtx eqnote;
> > 
> >       if (! may_trap_p (PATTERN (insn))
> > 	  || ((eqnote = find_reg_equal_equiv_note (insn))
> > 	      && ! may_trap_p (XEXP (eqnote, 0))))
> > 	remove_note (insn, note);
> >     }
> 
> Interesting - so should combine maybe have this exception as well when it
> tests for may_trap_p?  Not sure if the above makes sense.

That code was added by Jakub in r0-38443-g89753b3a903366, reverting the
reg-equal note part fixes the testcase as well.

[Bug rtl-optimization/105231] [12 Regression] ICE: in rtl_verify_bb_insns, at cfgrtl.cc:2797 (flow control insn inside a basic block) with custom flags since r12-4767-g81342e95827f77c0

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231

--- Comment #12 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #11)
> (In reply to Richard Biener from comment #10)
> > (In reply to Eric Botcazou from comment #8)
> > > > Yes, but still the float_extend:XF would have made may_trap_p say
> > > > the insn possibly traps but there's no EH on it despite
> > > > -fnon-call-exceptions.
> > > 
> > > The REG_EH note is added by make_reg_eh_region_note but then removed by
> > > purge_dead_edges because of the REG_EQUAL note:
> > > 
> > >   /* If this instruction cannot trap, remove REG_EH_REGION notes.  */
> > >   if (NONJUMP_INSN_P (insn)
> > >       && (note = find_reg_note (insn, REG_EH_REGION, NULL)))
> > >     {
> > >       rtx eqnote;
> > > 
> > >       if (! may_trap_p (PATTERN (insn))
> > > 	  || ((eqnote = find_reg_equal_equiv_note (insn))
> > > 	      && ! may_trap_p (XEXP (eqnote, 0))))
> > > 	remove_note (insn, note);
> > >     }
> > 
> > Interesting - so should combine maybe have this exception as well when it
> > tests for may_trap_p?  Not sure if the above makes sense.
> 
> That code was added by Jakub in r0-38443-g89753b3a903366, reverting the
> reg-equal note part fixes the testcase as well.

Oh, and checking for REG_EQUAL notes on i2/i3 doesn't work since they do not
exist there.  Likewise REG_EQUAL notes can be simply dropped which would
make the IL "invalid" so I think what purge_dead_edges does is premature?

[Bug rtl-optimization/105231] [12 Regression] ICE: in rtl_verify_bb_insns, at cfgrtl.cc:2797 (flow control insn inside a basic block) with custom flags since r12-4767-g81342e95827f77c0

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231

--- Comment #13 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> Oh, and checking for REG_EQUAL notes on i2/i3 doesn't work since they do not
> exist there.  Likewise REG_EQUAL notes can be simply dropped which would
> make the IL "invalid" so I think what purge_dead_edges does is premature?

Everything is consistent until combine messes things up, so I'd rather find a
fix/kludge in combine if possible.  Penalizing everyone because of an
artificial testcase exercising a nonsensical set of options is IMO not the way
to go.

[Bug rtl-optimization/105231] [12 Regression] ICE: in rtl_verify_bb_insns, at cfgrtl.cc:2797 (flow control insn inside a basic block) with custom flags since r12-4767-g81342e95827f77c0

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231

--- Comment #14 from rguenther at suse dot de <rguenther at suse dot de> ---
On Tue, 12 Apr 2022, ebotcazou at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231
> 
> --- Comment #13 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> > Oh, and checking for REG_EQUAL notes on i2/i3 doesn't work since they do not
> > exist there.  Likewise REG_EQUAL notes can be simply dropped which would
> > make the IL "invalid" so I think what purge_dead_edges does is premature?
> 
> Everything is consistent until combine messes things up, so I'd rather find a
> fix/kludge in combine if possible.  Penalizing everyone because of an
> artificial testcase exercising a nonsensical set of options is IMO not the way
> to go.

So my original patch still works - since combine doesn't split the block,
transfering EH edges, when it moves the note to i2 it should simply
never do that but instead drop it on the floor.

Which of course is a kludge and possibly wrong-code.

Alternatively we could mark as non-trapping

(insn 36 35 37 (set (reg:XF 95)
        (float_extend:XF (reg:SF 96))) "t.c":6:3 -1
     (expr_list:REG_EH_REGION (const_int 1 [0x1])
        (expr_list:REG_EQUAL (const_double:XF 1.8446744073709551616e+19 
[0x0.8p+65])
            (nil))))

at the point we remove the REG_EH_REGION note because of the
REG_EQUAL note?  Because we know it won't trap.

[Bug rtl-optimization/105231] [12 Regression] ICE: in rtl_verify_bb_insns, at cfgrtl.cc:2797 (flow control insn inside a basic block) with custom flags since r12-4767-g81342e95827f77c0

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231

--- Comment #15 from Richard Biener <rguenth at gcc dot gnu.org> ---
But looking at all the distribute_notes calls I'm not sure that i2 and i3 are
passed in execution order or that i3 is always the last instruction in the
set of insns that are combined?

[Bug rtl-optimization/105231] [12 Regression] ICE: in rtl_verify_bb_insns, at cfgrtl.cc:2797 (flow control insn inside a basic block) with custom flags since r12-4767-g81342e95827f77c0

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231

--- Comment #16 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
i3 is always the last, that is the ultimate insn into which the other insns are
combined into.

[Bug rtl-optimization/105231] [12 Regression] ICE: in rtl_verify_bb_insns, at cfgrtl.cc:2797 (flow control insn inside a basic block) with custom flags since r12-4767-g81342e95827f77c0

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231

--- Comment #17 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
For the testcase, again no reason for -fsanitize=thread,
void baz (int *);
void bar (double, double, _Decimal64);

void
foo (void)
{
  int s __attribute__((cleanup (baz)));
  bar (0xfffffffffffffffe, 0xebf3fff2fbebaf7f, 0xffffffffffffff);
}

will ICE even with just
-Os -fsanitize-coverage=trace-pc -fnon-call-exceptions --param=max-cse-insns=1
-frounding-math -mstack-arg-probe -m32

[Bug rtl-optimization/105231] [12 Regression] ICE: in rtl_verify_bb_insns, at cfgrtl.cc:2797 (flow control insn inside a basic block) with custom flags since r12-4767-g81342e95827f77c0

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231

--- Comment #18 from rguenther at suse dot de <rguenther at suse dot de> ---
On Tue, 12 Apr 2022, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231
> 
> --- Comment #16 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> i3 is always the last, that is the ultimate insn into which the other insns are
> combined into.

OK, and in case the other insns are always from the same basic-block(?)
they cannot have thrown previously.  Only ever i3 can retain the
EH note then or, if it no longer traps, we need to remove it?

[Bug rtl-optimization/105231] [12 Regression] ICE: in rtl_verify_bb_insns, at cfgrtl.cc:2797 (flow control insn inside a basic block) with custom flags since r12-4767-g81342e95827f77c0

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231

--- Comment #19 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
It is true that float_extend from a constant or constant pool memory if the
constant isn't NaN should never raise any kind of exception or trap.
Shouldn't we handle that in may_trap_p_1 or whatever considers the RTL
potentially trapping or raising exception?
At least assuming it is a conversion between modes where the outer mode can
represent all the values of the inner mode.

[Bug rtl-optimization/105231] [12 Regression] ICE: in rtl_verify_bb_insns, at cfgrtl.cc:2797 (flow control insn inside a basic block) with custom flags since r12-4767-g81342e95827f77c0

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231

--- Comment #20 from rguenther at suse dot de <rguenther at suse dot de> ---
On Tue, 12 Apr 2022, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231
> 
> --- Comment #19 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> It is true that float_extend from a constant or constant pool memory if the
> constant isn't NaN should never raise any kind of exception or trap.
> Shouldn't we handle that in may_trap_p_1 or whatever considers the RTL
> potentially trapping or raising exception?
> At least assuming it is a conversion between modes where the outer mode can
> represent all the values of the inner mode.

I'm not sure that's a general enough fix though since we seem to drop
the REG_EQUAL note and as soon as we do that there's a disconnect
between what CFG generation thinks throws and what combine thinks
is good enough to put a REG_EH_REGION note on.

It also looks like on RTL there's no way to mark an RTX as not
trapping/throwing.

[Bug rtl-optimization/105231] [12 Regression] ICE: in rtl_verify_bb_insns, at cfgrtl.cc:2797 (flow control insn inside a basic block) with custom flags since r12-4767-g81342e95827f77c0

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231

--- Comment #21 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> I'm not sure that's a general enough fix though since we seem to drop
> the REG_EQUAL note and as soon as we do that there's a disconnect
> between what CFG generation thinks throws and what combine thinks
> is good enough to put a REG_EH_REGION note on.

Yes, we actually drop 2 REG_EQUAL notes:

(insn 22 17 78 3 (set (reg:SF 92)
        (mem/u/c:SF (symbol_ref/u:SI ("*.LC0") [flags 0x2]) [0  S4 A32]))
"pr105231.c":6:3 142 {*movsf_internal}
     (expr_list:REG_EQUAL (const_double:SF 1.8446744073709551616e+19
[0x0.8p+65])
        (nil)))

(insn 78 22 24 3 (set (reg:XF 99)
        (float_extend:XF (reg:SF 92))) 166 {*extendsfxf2_i387}
     (expr_list:REG_DEAD (reg:SF 92)
        (expr_list:REG_EQUAL (const_double:XF 1.8446744073709551616e+19
[0x0.8p+65])
            (nil))))

-->

(insn 78 22 24 3 (set (reg:XF 99)
        (float_extend:XF (mem/u/c:SF (symbol_ref/u:SI ("*.LC0") [flags 0x2]) [0
 S4 A32]))) 166 {*extendsfxf2_i387}
     (expr_list:REG_EH_REGION (const_int 1 [0x1])
        (nil)))

so an immediate solution would be to preserve the one on insn 78 (and arrange
for the purge_dead_edge magic to trigger again).

[Bug rtl-optimization/105231] [12 Regression] ICE: in rtl_verify_bb_insns, at cfgrtl.cc:2797 (flow control insn inside a basic block) with custom flags since r12-4767-g81342e95827f77c0

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231

--- Comment #22 from rguenther at suse dot de <rguenther at suse dot de> ---
On Wed, 13 Apr 2022, ebotcazou at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231
> 
> --- Comment #21 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> > I'm not sure that's a general enough fix though since we seem to drop
> > the REG_EQUAL note and as soon as we do that there's a disconnect
> > between what CFG generation thinks throws and what combine thinks
> > is good enough to put a REG_EH_REGION note on.
> 
> Yes, we actually drop 2 REG_EQUAL notes:
> 
> (insn 22 17 78 3 (set (reg:SF 92)
>         (mem/u/c:SF (symbol_ref/u:SI ("*.LC0") [flags 0x2]) [0  S4 A32]))
> "pr105231.c":6:3 142 {*movsf_internal}
>      (expr_list:REG_EQUAL (const_double:SF 1.8446744073709551616e+19
> [0x0.8p+65])
>         (nil)))
> 
> (insn 78 22 24 3 (set (reg:XF 99)
>         (float_extend:XF (reg:SF 92))) 166 {*extendsfxf2_i387}
>      (expr_list:REG_DEAD (reg:SF 92)
>         (expr_list:REG_EQUAL (const_double:XF 1.8446744073709551616e+19
> [0x0.8p+65])
>             (nil))))
> 
> -->
> 
> (insn 78 22 24 3 (set (reg:XF 99)
>         (float_extend:XF (mem/u/c:SF (symbol_ref/u:SI ("*.LC0") [flags 0x2]) [0
>  S4 A32]))) 166 {*extendsfxf2_i387}
>      (expr_list:REG_EH_REGION (const_int 1 [0x1])
>         (nil)))
> 
> so an immediate solution would be to preserve the one on insn 78 (and arrange
> for the purge_dead_edge magic to trigger again).

Yes.  If i3 is always the insn we combine into any REG_EQUAL note
on that insn can always prevail.  I suppose the purge_dead_edge magic
would need to be postponed until we distributed all notes - not sure
where a safe place would be to remove EH_REGION notes in combine
after note distribution finalized?

[Bug rtl-optimization/105231] [12 Regression] ICE: in rtl_verify_bb_insns, at cfgrtl.cc:2797 (flow control insn inside a basic block) with custom flags since r12-4767-g81342e95827f77c0

[segher at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231

--- Comment #23 from Segher Boessenkool <segher at gcc dot gnu.org> ---
i3 is not always the sole instruction that results from the combine: if a
single insn does not work, two are tried, and one of them is placed at i2.
It's something to consider, it has to be checked for in a zillion places,
but it doesn't constrain you much in the end :-)

Btw, the only cases where combine splits blocks is when it has made an
unconditional trap; but in that case, it just ignores the second resulting
block (this is PR82386).  Also, combine *can* work on insns from different
BBs, in some cases (but always from the same EBB).

[Bug rtl-optimization/105231] [12 Regression] ICE: in rtl_verify_bb_insns, at cfgrtl.cc:2797 (flow control insn inside a basic block) with custom flags since r12-4767-g81342e95827f77c0

[segher at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231

--- Comment #24 from Segher Boessenkool <segher at gcc dot gnu.org> ---
Wrt keeping REG_EQUAL notes...  If you want to keep them you need to make sure
they still are valid.  GCC keeps those on i3, it is much too hard in general to
validate other such notes.

[Bug rtl-optimization/105231] [12 Regression] ICE: in rtl_verify_bb_insns, at cfgrtl.cc:2797 (flow control insn inside a basic block) with custom flags since r12-4767-g81342e95827f77c0

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231

--- Comment #25 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Segher Boessenkool from comment #24)
> Wrt keeping REG_EQUAL notes...  If you want to keep them you need to make
> sure
> they still are valid.  GCC keeps those on i3, it is much too hard in general
> to
> validate other such notes.

It seems to be that the REG_EQUAL notes of the SET dests in the final
instruction we combine into, so 24 for

Trying 78, 17 -> 24:

are better always valid even after the combination - at least when they
are not refering to pseudos set by insns combined (78, 17 here) and always
when the REG_EQUAL is constant.  When there are multiple sets in the final
insn (24) then which note ends up where is determined by the SET dests.

For this particular case preserving _constant_ REG_EQUAL notes would be
important.  And for this case only handling single-set would be good enough.

Of course if i3 is not always '24' (in this case) then we have to find
a better place to preserve these than distribute_notes.

[Bug rtl-optimization/105231] [12 Regression] ICE: in rtl_verify_bb_insns, at cfgrtl.cc:2797 (flow control insn inside a basic block) with custom flags since r12-4767-g81342e95827f77c0

[segher at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231

--- Comment #26 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #25)
> (In reply to Segher Boessenkool from comment #24)
> > Wrt keeping REG_EQUAL notes...  If you want to keep them you need to make
> > sure
> > they still are valid.  GCC keeps those on i3, it is much too hard in general
> > to
> > validate other such notes.
> 
> It seems to be that the REG_EQUAL notes of the SET dests in the final
> instruction we combine into, so 24 for
> 
> Trying 78, 17 -> 24:
> 
> are better always valid even after the combination - at least when they
> are not refering to pseudos set by insns combined (78, 17 here) and always
> when the REG_EQUAL is constant.  When there are multiple sets in the final
> insn (24) then which note ends up where is determined by the SET dests.

In the *resulting* final insn.  And some of those notes may have to be moved
to i2 -- when there are multiple sets in the *resulting* insn, and it is split.

> For this particular case preserving _constant_ REG_EQUAL notes would be
> important.  And for this case only handling single-set would be good enough.

You can *never* require REG_EQUAL notes for correctness.  It is always correct
to delete REG_EQUAL notes.  They exist to make optimisation easier, and for
nothing else.

> Of course if i3 is not always '24' (in this case) then we have to find
> a better place to preserve these than distribute_notes.

Or fix the bug: that which requires REG_EQUAL notes to not be deleted.  This
is a problem whether or not we hide the problem here (by making things
optimised better).

[Bug rtl-optimization/105231] [12 Regression] ICE: in rtl_verify_bb_insns, at cfgrtl.cc:2797 (flow control insn inside a basic block) with custom flags since r12-4767-g81342e95827f77c0

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231

--- Comment #27 from rguenther at suse dot de <rguenther at suse dot de> ---
On Thu, 14 Apr 2022, segher at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231
> 
> --- Comment #26 from Segher Boessenkool <segher at gcc dot gnu.org> ---
> (In reply to Richard Biener from comment #25)
> > (In reply to Segher Boessenkool from comment #24)
> > > Wrt keeping REG_EQUAL notes...  If you want to keep them you need to make
> > > sure
> > > they still are valid.  GCC keeps those on i3, it is much too hard in general
> > > to
> > > validate other such notes.
> > 
> > It seems to be that the REG_EQUAL notes of the SET dests in the final
> > instruction we combine into, so 24 for
> > 
> > Trying 78, 17 -> 24:
> > 
> > are better always valid even after the combination - at least when they
> > are not refering to pseudos set by insns combined (78, 17 here) and always
> > when the REG_EQUAL is constant.  When there are multiple sets in the final
> > insn (24) then which note ends up where is determined by the SET dests.
> 
> In the *resulting* final insn.  And some of those notes may have to be moved
> to i2 -- when there are multiple sets in the *resulting* insn, and it is split.
> 
> > For this particular case preserving _constant_ REG_EQUAL notes would be
> > important.  And for this case only handling single-set would be good enough.
> 
> You can *never* require REG_EQUAL notes for correctness.  It is always correct
> to delete REG_EQUAL notes.  They exist to make optimisation easier, and for
> nothing else.
> 
> > Of course if i3 is not always '24' (in this case) then we have to find
> > a better place to preserve these than distribute_notes.
> 
> Or fix the bug: that which requires REG_EQUAL notes to not be deleted.  This
> is a problem whether or not we hide the problem here (by making things
> optimised better).

Then the bug is in combine itself - it places a REG_EH_REGION note
but fails to split the basic-block after the affected 
instruction.  Or it even considers placing it on the not last
instruction.  Maybe there's already the constraint that combine
never combines an insns with a REG_EH_REGION note (aka a possibly
throwing insn) with another but only combines not throwing insns
into a throwing one.  Then the correct action is to always place
the REG_EH_REGION note on the last insn, or if that cannot throw,
throw it away.  If we somehow created an intermediate throwing/trapping
insn we should then reject the combination.

Richard.

[Bug rtl-optimization/105231] [12 Regression] ICE: in rtl_verify_bb_insns, at cfgrtl.cc:2797 (flow control insn inside a basic block) with custom flags since r12-4767-g81342e95827f77c0

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot gnu.org

--- Comment #28 from Richard Biener <rguenth at gcc dot gnu.org> ---
I'm testing a patch along comment #4 after discussing on IRC with Segher.

[Bug rtl-optimization/105231] [12 Regression] ICE: in rtl_verify_bb_insns, at cfgrtl.cc:2797 (flow control insn inside a basic block) with custom flags since r12-4767-g81342e95827f77c0

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1

--- Comment #29 from Richard Biener <rguenth at gcc dot gnu.org> ---
Technically P1.

[Bug rtl-optimization/105231] [12 Regression] ICE: in rtl_verify_bb_insns, at cfgrtl.cc:2797 (flow control insn inside a basic block) with custom flags since r12-4767-g81342e95827f77c0

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231

--- Comment #30 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Richard Biener <rguenth@gcc.gnu.org>:

https://gcc.gnu.org/g:4f77738c3b44cb6b7bfe2a7ef823a5d9d75c0e79

commit r12-8239-g4f77738c3b44cb6b7bfe2a7ef823a5d9d75c0e79
Author: Richard Biener <rguenther@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  <rguenther@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.

[Bug rtl-optimization/105231] [12 Regression] ICE: in rtl_verify_bb_insns, at cfgrtl.cc:2797 (flow control insn inside a basic block) with custom flags since r12-4767-g81342e95827f77c0

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|ASSIGNED                    |RESOLVED

--- Comment #31 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed.  Probably not worth fixing the latent issue on branches unless it comes
up in real code.

[Bug rtl-optimization/105231] [12 Regression] ICE: in rtl_verify_bb_insns, at cfgrtl.cc:2797 (flow control insn inside a basic block) with custom flags since r12-4767-g81342e95827f77c0

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231
Bug 105231 depends on bug 106082, which changed state.

Bug 106082 Summary: [13 Regression] Recent change broke m68k
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106082

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED