From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16780 invoked by alias); 16 Jan 2012 17:51:29 -0000 Received: (qmail 16770 invoked by uid 22791); 16 Jan 2012 17:51:28 -0000 X-SWARE-Spam-Status: No, hits=-2.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 16 Jan 2012 17:51:16 +0000 From: "ro at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug go/51874] New: Many libgo testsuite failures on Solaris, IRIX Date: Mon, 16 Jan 2012 18:11:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: go X-Bugzilla-Keywords: X-Bugzilla-Severity: major X-Bugzilla-Who: ro at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: ian at airs dot com X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2012-01/txt/msg01816.txt.bz2 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