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.