https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111601
--- Comment #19 from Jakub Jelinek <jakub at gcc dot gnu.org> --- When using current trunk (r14-5889), I can see it even in x86_64-linux -> powerpc64le-linux cross-compiler. diff -U300 pr111601.s{1,2} will show std 9,0(10) mr 10,9 + addi 10,10,96 li 26,0 - li 28,0 ld 7,.LANCHOR0+136@toc@l(11) + li 28,0 addi 6,6,1 addi 12,12,1 addi 7,7,1 ld 9,96(9) std 7,.LANCHOR0+136@toc@l(11) li 11,0 li 7,1 std 9,0(8) - std 11,96(10) + std 11,0(10) stb 7,0(5) - ori 2,2,0 ld 9,0(8) cmpdi 0,9,0 bne 0,.L104 .p2align 4,,15 and earlier .L104: lwz 7,104(9) li 11,1 li 29,1 cmpwi 0,7,1 b .L54 and even earlier .L54: beq 0,.L48 and .L48: std 9,0(10) mr 10,9 li 11,0 + addi 10,10,96 li 7,1 addi 6,6,1 addi 12,12,1 ld 9,96(9) std 9,0(8) - std 11,96(10) + std 11,0(10) which is where the r10 value which with -fno-fold-mem-offsets was modified with the 96 addend and with -ffold-mem-offsets no longer is is used without on the std 9,0(10) store and because that store wasn't adjusted, it stores into incorrect spot.