libgo tests failing on AArch64

[Matthias Klose]

  === libgo tests ===

Running target unix
FAIL: io
FAIL: math
FAIL: net
FAIL: os
FAIL: reflect
FAIL: runtime
FAIL: sync
FAIL: time
FAIL: database/sql
FAIL: go/doc
FAIL: go/printer
FAIL: log/syslog
FAIL: net/http/cgi
FAIL: net/http/httputil
FAIL: net/rpc
FAIL: net/rpc/jsonrpc
FAIL: old/template
FAIL: os/exec
FAIL: os/signal
FAIL: sync/atomic
FAIL: text/template

  === libgo Summary ===

# of expected passes 101
# of unexpected failures 21

[Matthias Klose (doko)]

on armhf:

  === libgo tests ===

Running target unix
FAIL: bufio
FAIL: fmt
FAIL: log
FAIL: reflect
FAIL: runtime
FAIL: sync
FAIL: time
FAIL: crypto/cipher
FAIL: encoding/gob
FAIL: encoding/json
FAIL: html/template
FAIL: math/big
FAIL: net/http
FAIL: net/rpc
FAIL: old/regexp
FAIL: old/template
FAIL: text/template
FAIL: text/template/parse

  === libgo Summary for unix ===

# of expected passes 104
# of unexpected failures 18

[Matthias Klose (doko)]

all tests fail on powerpc

  === libgo Summary for unix ===

# of expected passes 1
# of unexpected failures 121

[Michael Hudson-Doyle (mwhudson)]

Should the armhf and powerpc bits be different reports?

I ran the testsuite on a newer version of 4.8 and a newer kernel and got better results:

                === libgo tests ===

Running target unix
FAIL: math
FAIL: net
FAIL: reflect

                === libgo Summary ===

# of expected passes 119
# of unexpected failures 3
/home/mwhudson/gcc-4.8-4.8.2/build/./gcc/gccgo version 4.8.2 (Ubuntu/Linaro 4.8.2-10ubuntu2)

[Michael Hudson-Doyle (mwhudson)]

These failures are all quite interesting.

----------------------------------------------------------------------------
--- FAIL: TestLog2 (0.00 seconds)
        all_test.go:2281: Log2(1) = 4.756597398230631e-17, want 0
        all_test.go:2288: Log2(2**0) = 4.756597398230631e-17, want 0
FAIL
FAIL: math
----------------------------------------------------------------------------

That certainly looks worrying!

----------------------------------------------------------------------------
runtime: memory allocated by OS (0x2012c3e000) not in usable range [0x8500000,0x88500000)
runtime: out of memory: cannot allocate 2097152-byte block (536870912 in use)
fatal error: out of memory

goroutine 114 [running]:
runtime_dopanic
        ../../../src/libgo/runtime/panic.c:71
runtime_throw
        ../../../src/libgo/runtime/panic.c:106
runtime_mallocgc
        ../../../src/libgo/runtime/malloc.goc:83
runtime_malg
        ../../../src/libgo/runtime/proc.c:1910
__go_go
        ../../../src/libgo/runtime/proc.c:1965
net.TestDialTimeoutFDLeak
        /home/mwhudson/gcc-4.8-4.8.2/build/aarch64-linux-gnu/libgo/gotest29428/test/dial_test.go:276
testing.tRunner
        ../../../src/libgo/go/testing/testing.go:353
kickoff
        ../../../src/libgo/runtime/proc.c:229

        :0
panic during panic
FAIL: net
----------------------------------------------------------------------------

I actually know what's going on here, it's related to the reservation fixes for statically linked binaries in the latest gcc-4.8 upload. I'll try to propose a fix for this too (I got distracted with arguin^Wdiscussing the fix with go core devs)

----------------------------------------------------------------------------
all_test.go: In function 'reflect_test.takesEmpty':
all_test.go:1443:1: error: total size of local objects too large
 func takesEmpty(e emptyStruct) {
 ^
FAIL: reflect
----------------------------------------------------------------------------

This is the same problem as bug 1263806

[Michael Hudson-Doyle (mwhudson)]

The Log2 bug has been filed as https://code.google.com/p/go/issues/detail?id=7074

[Michael Hudson-Doyle (mwhudson)]

Turns out the compiler bug making the reflect tests fail to compile were masking another failure:

--- FAIL: TestFunc (0.00 seconds)
panic: runtime error: invalid memory address or nil pointer dereference [recovered]
 panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xb code=0x1 addr=0x28]

goroutine 37 [running]:
testing.$nested3
 ../../../src/libgo/go/testing/testing.go:342
reflect_test.dummy
 /build/buildd/gcc-4.8-4.8.2/build/aarch64-linux-gnu/libgo/gotest11948/test/all_test.go:1402
reflect.call
 ../../../src/libgo/runtime/go-reflect-call.c:527
reflect.call.N13_reflect.Value
 /build/buildd/gcc-4.8-4.8.2/build/aarch64-linux-gnu/libgo/gotest11948/test/value.go:483
reflect.Call.N13_reflect.Value
 /build/buildd/gcc-4.8-4.8.2/build/aarch64-linux-gnu/libgo/gotest11948/test/value.go:342
reflect_test.TestFunc
 /build/buildd/gcc-4.8-4.8.2/build/aarch64-linux-gnu/libgo/gotest11948/test/all_test.go:1407
testing.tRunner
 ../../../src/libgo/go/testing/testing.go:353
created by testing.RunTests
 ../../../src/libgo/go/testing/testing.go:433

goroutine 1 [chan receive]:
testing.RunTests
 ../../../src/libgo/go/testing/testing.go:434
testing.Main
 ../../../src/libgo/go/testing/testing.go:365
main.main
 /build/buildd/gcc-4.8-4.8.2/build/aarch64-linux-gnu/libgo/gotest11948/test/_testmain.go:110

goroutine 36 [sleep]:
reflect_test.selectWatcher
 /build/buildd/gcc-4.8-4.8.2/build/aarch64-linux-gnu/libgo/gotest11948/test/all_test.go:1346
created by reflect_test.$nested2
 /build/buildd/gcc-4.8-4.8.2/build/aarch64-linux-gnu/libgo/gotest11948/test/all_test.go:1076
FAIL: reflect

[Michael Hudson-Doyle (mwhudson)]

The reflect failure is a disagreement about ABI details: https://code.google.com/p/go/issues/detail?id=7120

[Michael Hudson-Doyle (mwhudson)]

The reflect test is fixed by the patch on http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59799. doko, can you pull that into your next gcc uploads?

The math test should probably be xfailed.

The net failure is still a real issue, I hope to have a fix soon.

[Matthias Klose (doko)]

won't fix in 4.8, gccgo-5 looks better