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.