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: [email protected]
ReportedBy: [email protected]
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
