This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug go/64876] Regressions in gcc-testresults for powerpc64 gccgo in 5.0 due to change for static chain for closures (219776)
- From: "amodra at gmail dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Tue, 03 Feb 2015 03:52:44 +0000
- Subject: [Bug go/64876] Regressions in gcc-testresults for powerpc64 gccgo in 5.0 due to change for static chain for closures (219776)
- Auto-submitted: auto-generated
- References: <bug-64876-4 at http dot gcc dot gnu dot org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64876
Alan Modra <amodra at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2015-02-03
Ever confirmed|0 |1
--- Comment #3 from Alan Modra <amodra at gmail dot com> ---
Confirmed. libffi does not appear to be involved here. If I look at the
escape.go testcase Lynn singles out, the code generated with the patch (or with
-mno-pointers-to-nested-functions) is the following for the call that dies
without the patch.
Breakpoint 2, main.for_escapes3 (y=106, x=105) at
/home/amodra/src/gcc-virgin/gcc/testsuite/go.test/test/escape.go:155
155 return f[0](), f[1]()
(gdb) disass $pc,$pc+0x3f
Dump of assembler code from 0x1000267c to 0x100026bb:
=> 0x000000001000267c <main.for_escapes3+172>: ld r11,112(r1)
0x0000000010002680 <main.for_escapes3+176>: ld r9,0(r11)
0x0000000010002684 <main.for_escapes3+180>: std r2,40(r1)
0x0000000010002688 <main.for_escapes3+184>: ld r10,0(r9)
0x000000001000268c <main.for_escapes3+188>: mtctr r10
0x0000000010002690 <main.for_escapes3+192>: ld r2,8(r9)
0x0000000010002694 <main.for_escapes3+196>: bctrl
0x0000000010002698 <main.for_escapes3+200>: ld r2,40(r1)
(gdb) stepi 7
main.$nested0 () at
/home/amodra/src/gcc-virgin/gcc/testsuite/go.test/test/escape.go:152
152 f[n] = func() *int { return p }
(gdb) disass
Dump of assembler code for function main.$nested0:
=> 0x0000000010001960 <+0>: ld r9,8(r11)
0x0000000010001964 <+4>: ld r3,0(r9)
0x0000000010001968 <+8>: blr
Clearly r11 is expected to hold the address of a struct on entry to
main.$nested0.
(gdb) x/2xg $r11
0xc2080000e0: 0x0000000010014470 0x000000c20903c000
(gdb) x 0x000000c20903c000
0xc20903c000: 0x000000c2080000d8
(gdb) x 0x000000c2080000d8
0xc2080000d8: 0x0000000000000069
Yup, there's our 105, so the value returned is as expected.
If I compile the testcase without -mno-pointers-to-nested-functions then the
code for the call in main.for_escapes3 is:
0x000000001000267c <+172>: ld r9,112(r1)
---Type <return> to continue, or q <return> to quit---
0x0000000010002680 <+176>: ld r9,0(r9)
0x0000000010002684 <+180>: std r2,40(r1)
0x0000000010002688 <+184>: ld r10,0(r9)
0x000000001000268c <+188>: ld r11,16(r9)
0x0000000010002690 <+192>: mtctr r10
0x0000000010002694 <+196>: ld r2,8(r9)
0x0000000010002698 <+200>: bctrl
=> 0x000000001000269c <+204>: ld r2,40(r1)
So r11 is not loaded with the proper parameter from 112(r1), but instead set up
with a zero from the function descriptor.