[Bug target/113510] [14 Regression] [ARM Thumb] ICE in extract_constrain_insn with CPU cortex-m23

["vmakarov at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

Vladimir Makarov <vmakarov at gcc dot gnu.org> changed:

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

--- Comment #4 from Vladimir Makarov <vmakarov at gcc dot gnu.org> ---
This is not a RA bug.  I believe it is a bug in peephole optimization.

Right after LRA and before peephole2 we have:

(insn 28 13 15 2 (set (reg:SI 12 ip [127])
        (const_int 8 [0x8]))
"../../gcc/gcc/testsuite/gcc.c-torture/compile/nested-3.c":17:10 959
{*thumb1_movsi_insn}
     (nil))
(insn 15 28 16 2 (set (reg:SI 12 ip [127])
        (plus:SI (reg:SI 12 ip [127])
            (reg/f:SI 13 sp)))
"../../gcc/gcc/testsuite/gcc.c-torture/compile/nested-3.c":17:10 935
{*thumb1_addsi3}
     (nil))

and peephole2 combines these two insns into

(insn 39 13 16 2 (set (reg:SI 12 ip [127])
        (plus:SI (reg/f:SI 13 sp)
            (const_int 8 [0x8])))
"../../gcc/gcc/testsuite/gcc.c-torture/compile/nested-3.c":17:10 -1
     (nil))

which is wrong as output and the 1st operand of *thumb1_addsi3 should be a low
register but r12 is not a low register.  If peephole2 took this into account,
it would have not combined the 2 insns and we would have not this PR.