https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111411
--- Comment #7 from Richard Sandiford <rsandifo at gcc dot gnu.org> ---
It's proving difficult to generate a reliable reproducer from
pure C code, due to the ways in which we handle out-of-range
offsets. But FWIW, here's one that uses the RTL frontend,
compiled with -O -fdisable-rtl-postreload -fpeephole2:
extern int data[];
void __RTL (startwith ("ira")) foo (void *ptr)
{
(function "foo"
(param "ptr"
(DECL_RTL (reg/v:DI <0> [ ptr ]))
(DECL_RTL_INCOMING (reg/v:DI x0 [ ptr ]))
) ;; param "ptr"
(insn-chain
(block 2
(edge-from entry (flags "FALLTHRU"))
(cnote 3 [bb 2] NOTE_INSN_BASIC_BLOCK)
(insn 4 (set (reg:DI <0>) (reg:DI x0)))
(insn 5 (set (reg:DI <1>)
(plus:DI (reg:DI <0>) (const_int 768))))
(insn 6 (set (mem:SI (plus:DI (reg:DI <0>)
(const_int 508)) [1 &data+508 S4 A4])
(const_int 0)))
(insn 7 (set (mem:SI (plus:DI (reg:DI <1>)
(const_int -256)) [1 &data+512 S4 A4])
(const_int 0)))
(edge-to exit (flags "FALLTHRU"))
) ;; block 2
) ;; insn-chain
) ;; function
}
(This one doesn't rely on -fstack-protector-strong, or on the recent
patches.)
The problem is that the LDP/STP formation code is too loose in the
check for valid addresses: it thinks it's enough for the second address
to be valid, even though that's not the one used in the STP.
