https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72827
--- Comment #7 from Bill Schmidt <wschmidt at gcc dot gnu.org> ---
It does look possible that this is an LRA issue. Here's the code right before
failure:
100dae08: f8 95 22 39 addi r9,r2,-27144
100dae0c: 01 00 40 39 li r10,1
100dae10: 00 00 49 99 stb r10,0(r9)
100dae14: b8 04 20 39 li r9,1208
100dae18: 14 4a 7f 7c add r3,r31,r9
100dae1c: 08 00 83 e8 ld r4,8(r3)
100dae20: 00 00 63 e8 ld r3,0(r3)
100dae24: 3d 86 14 48 bl 10223460
<system__secondary_stack__ss_re
lease>
100dae28: 00 00 00 60 nop
At the call, r3 has a value of 0. It looks quite possible that the stack load
at 0x100dae20 is from a spill slot. I don't see offset 1208 used for a
corresponding store anywhere in the function. There is, however, some odd code
that uses that constant to fiddle with the frame pointer and then set it back
to where it was:
100da5d8: b8 04 20 39 li r9,1208
100da5e4: 14 4a ff 7f add r31,r31,r9
100da5e8: 50 f8 e9 7f subf r31,r9,r31
Whatever's going on there looks like a bug.
