This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug target/72827] [7 Regression] gnat bootstrap broken on powerpc64le-linux-gnu
- From: "wschmidt at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Tue, 30 Aug 2016 02:57:25 +0000
- Subject: [Bug target/72827] [7 Regression] gnat bootstrap broken on powerpc64le-linux-gnu
- Auto-submitted: auto-generated
- References: <bug-72827-4@http.gcc.gnu.org/bugzilla/>
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.