This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug go/64876] Regressions in gcc-testresults for powerpc64 gccgo in 5.0 due to change for static chain for closures (219776)


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]