[Bug go/51874] New: Many libgo testsuite failures on Solaris, IRIX

[Bug go/51874] New: Many libgo testsuite failures on Solaris, IRIX

[ro at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51874

             Bug #: 51874
           Summary: Many libgo testsuite failures on Solaris, IRIX
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: go
        AssignedTo: ian@airs.com
        ReportedBy: ro@gcc.gnu.org
              Host: i386-pc-solaris2.1[01], mips-sgi-irix6.5
            Target: i386-pc-solaris2.1[01], mips-sgi-irix6.5
             Build: i386-pc-solaris2.1[01], mips-sgi-irix6.5


Since the introduction of

runtime: Multiplex goroutines onto OS threads.

go and libgo testsuite results on Solaris and IRIX have become terrible to the
point that Go is unusable on both platforms:

* On Solaris 10 and 11/x86, all 64-bit libgo tests FAIL now, while the 32-bit
  tests are fine.  64-bit go.test results show several failures too:

FAIL: ./select5-out.go compilation,  -O2 -g 
FAIL: go.test/test/chan/doubleselect.go execution,  -O2 -g 
FAIL: go.test/test/chan/nonblock.go execution,  -O2 -g 
FAIL: go.test/test/chan/select2.go execution,  -O2 -g 
FAIL: go.test/test/chan/select3.go execution,  -O2 -g 
FAIL: go.test/test/mallocfin.go execution,  -O2 -g 
FAIL: go.test/test/stack.go execution,  -O2 -g 
WARNING: program timed out.
WARNING: program timed out.

* The situation on Solaris/SPARC is similar: about half of both 32-bit and
64-bit
  libgo tests FAIL.  The set of failing go.tests is also much larger than on
x86.

* On IRIX 6.5, all libgo tets FAIL, both 32 and 64-bit.  The set of failing
  go.test tests seems similar to the Solaris/SPARC case.

Initially, I've tried to investigate an existing 64-bit Solaris/x86 testcase
(mallocfin), but that proved to be difficult.

I've now found a far simpler one: an empty main.go fails if run with
GOMAXPROCS=2:

panic: runtime error: invalid memory address or nil pointer dereference

I find that g->entry is NULL at the first kickstart call, while it has been
initialized to mainstart before.  I've not yet found how this happens.

  Rainer

[Bug go/51874] Many libgo testsuite failures on Solaris, IRIX

[ro at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51874

Rainer Orth <ro at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|i386-pc-solaris2.1[01],     |i386-pc-solaris2.1[01],
                   |mips-sgi-irix6.5            |mips-sgi-irix6.5,
                   |                            |sparc-sun-solaris2*
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2012-01-27
               Host|i386-pc-solaris2.1[01],     |i386-pc-solaris2.1[01],
                   |mips-sgi-irix6.5            |mips-sgi-irix6.5,
                   |                            |sparc-sun-solaris2*
   Target Milestone|---                         |4.7.0
     Ever Confirmed|0                           |1
              Build|i386-pc-solaris2.1[01],     |i386-pc-solaris2.1[01],
                   |mips-sgi-irix6.5            |mips-sgi-irix6.5,
                   |                            |sparc-sun-solaris2*

--- Comment #1 from Rainer Orth <ro at gcc dot gnu.org> 2012-01-27 11:37:09 UTC ---
Ian has now provided a detailed investigation of the problem:

  http://gcc.gnu.org/ml/gcc-patches/2012-01/msg00918.html

For the 64-bit Solaris/x86 case, Solaris engineering has identified and fixed
the bug:

7133114 fsbase (%fs:0) is not set properly after makecontext()/setcontext()

The fix will be in Solaris 11 Update 1, and I've requested a Solaris 10
Update 10 backport, which will be delivered as a patch on top of patch
144501-19.

  Rainer

[Bug go/51874] Many libgo testsuite failures on Solaris, IRIX

[ro at CeBiTec dot Uni-Bielefeld.DE]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51874

--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> 2012-01-27 11:45:17 UTC ---
I've also had a look at the Solaris/SPARC failures, which are unrelated
to the 64-bit Solaris/x86 problem previously identified.  I could trace
it to the most trivial testcase with channels:

package main

func send(ch chan<- int) {
    ch <- 1
}

func main() {
    ch := make(chan int)
    go send(ch)
    recv := <-ch
    if recv != 1 {
        panic (recv)
    }
    print(recv, "\n")
}

On Solaris/SPARC (both 32 and 64-bit), this fails with

panic: 0

I've still to closer investigate why this happens.  I suspect that this
is also the cause of the IRIX failures (a libgo build is currently
running).  Maybe this is just and endianess problem: it's interesting
that 32-bit Solaris/x86 works (little-endian), while 32-bit
Solaris/SPARC and IRIX (both big-endian) don't.

    Rainer

[Bug go/51874] Many libgo testsuite failures on Solaris, IRIX

[ro at CeBiTec dot Uni-Bielefeld.DE]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51874

--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> 2012-01-27 12:52:29 UTC ---
The chan.go testcase also fails on 32-bit IRIX, but in a different way:

> ./chan.x
panic: runtime error: invalid memory address or nil pointer dereference

Running it under gdb, I find:

Program received signal SIGSEGV, Segmentation fault.
runtime_mcall (pfn=0x823198 <schedule>)
    at /vol/gcc/src/hg/trunk/local/libgo/runtime/proc.c:283
283             if (g == nil || !g->fromgogo) {
(gdb) where
#0  runtime_mcall (pfn=0x823198 <schedule>)
    at /vol/gcc/src/hg/trunk/local/libgo/runtime/proc.c:283
#1  0x0081b9e0 in runtime_chanrecv (t=<optimized out>, c=0x2030b000, 
    ep=0x20102f60 "", selected=0x0, received=0x0)
    at /vol/gcc/src/hg/trunk/local/libgo/runtime/chan.c:333
#2  0x0081bae0 in __go_receive_small (t=<optimized out>, c=<optimized out>)
    at /vol/gcc/src/hg/trunk/local/libgo/runtime/chan.c:432
#3  0x10002418 in main.main () at /vol/gcc/src/doc/bugs/chan.go:10
#4  0x00822994 in runtime_main ()
    at /vol/gcc/src/hg/trunk/local/libgo/runtime/proc.c:371
#5  0x00823960 in kickoff ()
    at /vol/gcc/src/hg/trunk/local/libgo/runtime/proc.c:237
#6  0x0faee6d0 in _sethostname () from /usr/lib32/libc.so.1
#7  0x008225f4 in runtime_mcall (pfn=0x823198 <schedule>)
    at /vol/gcc/src/hg/trunk/local/libgo/runtime/proc.c:281
#8  0x00000000 in ?? ()

It may be an issue that IRIX is an emutls target.

On 64-bit IRIX, I get

> ./chan.x64
panic: 0

as on Solaris/SPARC.

    Rainer

[Bug go/51874] Many libgo testsuite failures on Solaris, IRIX

[ro at CeBiTec dot Uni-Bielefeld.DE]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51874

--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> 2012-01-31 18:27:32 UTC ---
> I've still to closer investigate why this happens.  I suspect that this
> is also the cause of the IRIX failures (a libgo build is currently
> running).  Maybe this is just and endianess problem: it's interesting
> that 32-bit Solaris/x86 works (little-endian), while 32-bit
> Solaris/SPARC and IRIX (both big-endian) don't.

I see now what's happening, and it's indeed an endianess problem:

In runtime/chan.c (__go_send_small), when sending an int (1) on a
big-endian system, the __builtin_memcpy copies the 4 low bytes from val
(0 in the case of val = 1) into b[], and runtime_chansend copies those
to the reciever.  Similarly, in __go_receive_small even when a 4-byte
int had been received correctly, it would have been placed into the 4
low bytes of u.b by runtime_chanrecv, but the function returns all 8
bytes of u.v (0x10000 in this case).

This code cannot possibly work on a big-endian system, but I'm undecided
how to solve this in a clean way.

    Rainer

[Bug go/51874] Many libgo testsuite failures on Solaris, IRIX

[ian at airs dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51874

Ian Lance Taylor <ian at airs dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Depends on|                            |52205

--- Comment #5 from Ian Lance Taylor <ian at airs dot com> 2012-02-11 00:07:07 UTC ---
I just committed a patch to fix the channel endian problem, but forgot to put
the PR note in the commit message.

http://gcc.gnu.org/ml/gcc-patches/2012-02/msg00533.html
http://gcc.gnu.org/ml/gcc-cvs/2012-02/msg00335.html

On x86 and x86_64 Solaris 2.11, all tests now pass for me.

On SPARC Solaris 2.11, there are still some failures.  At least some are due to
PR 52205.

No idea about Irix.

[Bug go/51874] Many libgo testsuite failures on Solaris, IRIX

[ian at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51874

--- Comment #6 from ian at gcc dot gnu.org <ian at gcc dot gnu.org> 2012-02-12 06:00:42 UTC ---
Author: ian
Date: Sun Feb 12 06:00:34 2012
New Revision: 184137

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184137
Log:
    PR go/51874
    * go.test/go-test.exp (go-gc-tests): Don't run nilptr test on
    SPARC Solaris.  Don't run the test at all on systems where it may
    not work, rather than xfailing it.

Modified:
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/go.test/go-test.exp

[Bug go/51874] Many libgo testsuite failures on Solaris, IRIX

[ian at airs dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51874

--- Comment #7 from Ian Lance Taylor <ian at airs dot com> 2012-02-12 06:04:42 UTC ---
In current mainline I'm not aware of any test failures on Solaris.  The SPARC
Solaris system I am using is very slow and I do see some timeouts.  However, I
do not see any more actual failures.

I have not tested on Irix.  To be honest I am far less interested in Irix than
I am in Solaris.  Can you still buy a new Irix system?

If you agree that Solaris working, can you either close this PR or make it
Irix-specific?  Thanks.

[Bug go/51874] Many libgo testsuite failures on Solaris, IRIX

[ian at airs dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51874

--- Comment #8 from Ian Lance Taylor <ian at airs dot com> 2012-02-12 06:05:36 UTC ---
Sorry, I should clarify that I don't see any failures on Solaris if I patch the
compiler to avoid PR 51921.

[Bug go/51874] Many libgo testsuite failures on Solaris, IRIX

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51874

--- Comment #9 from Andrew Pinski <pinskia at gcc dot gnu.org> 2012-02-12 06:55:18 UTC ---
(In reply to comment #7)
> I have not tested on Irix.  To be honest I am far less interested in Irix than
> I am in Solaris.  Can you still buy a new Irix system?

Not know I know of.  There are some mips64-linux-gnu machines around which run
pretty fast though (I can do some runs on an 6 core 1.3GHz MIPS64 Linux if
needed).

[Bug go/51874] Many libgo testsuite failures on Solaris, IRIX

[ian at airs dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51874

Ian Lance Taylor <ian at airs dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING

--- Comment #10 from Ian Lance Taylor <ian at airs dot com> 2012-02-14 18:20:28 UTC ---
Waiting for feedback.

[Bug go/51874] Many libgo testsuite failures on Solaris, IRIX

[ro at CeBiTec dot Uni-Bielefeld.DE]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51874

--- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> 2012-02-14 18:31:28 UTC ---
> --- Comment #7 from Ian Lance Taylor <ian at airs dot com> 2012-02-12 06:04:42 UTC ---
> In current mainline I'm not aware of any test failures on Solaris.  The SPARC
> Solaris system I am using is very slow and I do see some timeouts.  However, I
> do not see any more actual failures.

Right, I'm currently running Solaris 8-11 bootstraps.  Solaris 11
results look excellent so far: while I'm still seeing the 3 timeouts
from PR go/48501, this bootstrap predates your patches for this.
Solaris 10 is only slightly worse, but I think it's best to file a
separate PR for the issue(s) I'm seeing there.

Solaris 8 and 9 suffer from two problems:

* Initially, bootstrap failed since the setcontext TLS test failed.  I
  could trace this to the wrong (non-standard) interpretation of
  uc_stack.ss_sp as top of stack on Solaris 8 and 9/SPARC.  I've got a
  patch (hack for that) which I'll post once testing completes.

* All execution tests fail since Solaris 8 and 9/SPARC libm.so lacks
  log2 and trunc, so all tests die with undefined references.  Should I
  file a separate PR for that?

> I have not tested on Irix.  To be honest I am far less interested in Irix than
> I am in Solaris.  Can you still buy a new Irix system?

No, and I'm obsoleting IRIX 6.5 support in 4.7 for a reason :-)  Still,
given that Go support worked reasonably well some time ago, I'd like to
get it working again if possible.  An IRIX bootstrap with the latest
patches is currently running.  It also need a hack around the setcontext
TLS test, which SEGVs somewhere in the depths of pthread_join.  I've no
idea yet why this happens.

> If you agree that Solaris working, can you either close this PR or make it
> Irix-specific?  Thanks.

I'll make it IRIX-specific once the Solaris bootstraps have finished.

Thanks a lot for all your help.

    Rainer

[Bug go/51874] Many libgo testsuite failures on Solaris, IRIX

[ian at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51874

--- Comment #12 from ian at gcc dot gnu.org <ian at gcc dot gnu.org> 2012-02-16 07:17:15 UTC ---
Author: ian
Date: Thu Feb 16 07:17:03 2012
New Revision: 184300

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=184300
Log:
    PR go/51874
math: Don't use libc log2 and trunc functions.

Modified:
    trunk/libgo/go/math/floor.go
    trunk/libgo/go/math/log10.go

[Bug go/51874] Many libgo testsuite failures on IRIX

[ro at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51874

Rainer Orth <ro at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|i386-pc-solaris2.1[01],     |mips-sgi-irix6.5
                   |mips-sgi-irix6.5,           |
                   |sparc-sun-solaris2*         |
             Status|WAITING                     |ASSIGNED
               Host|i386-pc-solaris2.1[01],     |mips-sgi-irix6.5
                   |mips-sgi-irix6.5,           |
                   |sparc-sun-solaris2*         |
            Summary|Many libgo testsuite        |Many libgo testsuite
                   |failures on Solaris, IRIX   |failures on IRIX
              Build|i386-pc-solaris2.1[01],     |mips-sgi-irix6.5
                   |mips-sgi-irix6.5,           |
                   |sparc-sun-solaris2*         |
           Severity|major                       |normal

--- Comment #13 from Rainer Orth <ro at gcc dot gnu.org> 2012-02-16 19:41:40 UTC ---
No fundamental issues left on Solaris (either SPARC or x86), so making IRIX
specific. While the big-endian chan patch improved IRIX results a bit, there's
still something quite wrong.  Need to investigate.

  Rainer

[Bug go/51874] Many libgo testsuite failures on IRIX

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51874

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.7.0                       |4.7.1

--- Comment #14 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-03-22 08:26:16 UTC ---
GCC 4.7.0 is being released, adjusting target milestone.

[Bug go/51874] Many libgo testsuite failures on IRIX

[ro at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51874

--- Comment #15 from Rainer Orth <ro at gcc dot gnu.org> 2012-04-04 11:48:45 UTC ---
(In reply to comment #1)
> For the 64-bit Solaris/x86 case, Solaris engineering has identified and fixed
> the bug:
> 
> 7133114 fsbase (%fs:0) is not set properly after makecontext()/setcontext()
> 
> The fix will be in Solaris 11 Update 1, and I've requested a Solaris 10
> Update 10 backport, which will be delivered as a patch on top of patch
> 144501-19.

Just FYI, the fix for the bug above is now available in Solaris 11 SRU 5 and
Solaris 10/x86 patch 147441-14.  It's also included in a beta of Solaris 11
Update 1.

  Rainer

[Bug go/51874] Many libgo testsuite failures on IRIX

[ian at airs dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51874

--- Comment #16 from Ian Lance Taylor <ian at airs dot com> 2012-04-24 16:33:13 UTC ---
At some point, can you update this bug with the current set of test failures
using Go on Irix?  No rush.

[Bug go/51874] Many libgo testsuite failures on IRIX

[ro at CeBiTec dot Uni-Bielefeld.DE]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51874

--- Comment #17 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> 2012-05-08 15:08:13 UTC ---
> --- Comment #16 from Ian Lance Taylor <ian at airs dot com> 2012-04-24 16:33:13 UTC ---
> At some point, can you update this bug with the current set of test failures
> using Go on Irix?  No rush.

I've just finished a 4.7 branch bootstrap on IRIX.  Test results are at

    http://gcc.gnu.org/ml/gcc-testresults/2012-05/msg00776.html

You can look at the complete build at
columba:/var/gcc/regression/gcc-4.7-branch/6.5-gcc/build.

There are two issues currently breaking the IRIX Go build:

* The configure test for libgo_cv_lib_setcontext_clobbers_tls currently
  SEGVs in pthread_join; I don't really know why.  I'm currently hacking
  around this with the attached patch.

* The last bootstrap failed building libgo:

sysinfo.go:338:78: error: use of undefined type '_rtentry'
make[4]: *** [syscall/syscall.lo] Error 1

  _rtentry is only used in

type _llinfo_arp struct { la_next *_llinfo_arp; la_prev *_llinfo_arp; la_rt
*_rtentry; la_hold *_mbuf; la_data *byte; la_asked int32; }
type _route struct { ro_rt *_rtentry; ro_dst _sockaddr; }

  both of which seem to be unused otherwise.  As another hack, I've
  manually commented both lines to allow the bootstrap (which takes
  ca. 36 hours) to complete.

After this, the majority of testcases (both gcc and libgo) fail with

throw: gogo setcontext returned

I haven't yet started to investigate what's going on.

    Rainer

[Bug go/51874] Many libgo testsuite failures on IRIX

[ro at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51874

--- Comment #18 from Rainer Orth <ro at gcc dot gnu.org> 2012-05-08 15:09:32 UTC ---
Created attachment 27349
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27349
Hack to avoid IRIX 6.5 libgo_cv_lib_setcontext_clobbers_tls failure

[Bug go/51874] Many libgo testsuite failures on IRIX

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51874

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.7.1                       |---

[Bug go/51874] Many libgo testsuite failures on IRIX

[ro at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51874

Rainer Orth <ro at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #19 from Rainer Orth <ro at gcc dot gnu.org> ---
4.7 branch closed.