On Thu, 30 May 2019, Jim Wilson wrote:
> > Here are the test results:
> > http://gcc.gnu.org/ml/gcc-testresults/2019-05/msg02903.html
>
> I tried running RISC-V go checks on my system. I see 7 unexpected
> failures for gcc check-go, 6 unexpected failures for check-gotools,
> and 1 unexpected failure for check-target-libgo. I haven't tried
> building and testing the go support before so I don't have any old
> results to compare against. It seems reasonable for a first attempt
> though.
I have results as at r270765, taken with QEMU run in the user emulation
mode (I have patches outstanding for configury/Makefiles to correctly
support libgo and other library testing with a build sysroot in such a
setup, pending the completion of my WDC copyright assignment paperwork
with FSF):
FAIL: go.test/test/args.go execution, -O2 -g
FAIL: go.test/test/fixedbugs/bug347.go execution, -O0 -g
FAIL: go.test/test/fixedbugs/bug348.go execution, -O0 -g
FAIL: go.test/test/fixedbugs/issue4562.go execution, -O2 -g
FAIL: go.test/test/fixedbugs/issue6055.go execution, -O2 -g
FAIL: go.test/test/method5.go execution, -O2 -g
FAIL: go.test/test/nil.go execution, -O2 -g
FAIL: go.test/test/recover3.go execution, -O2 -g
=== go Summary ===
# of expected passes 3188
# of unexpected failures 8
# of expected failures 1
# of untested testcases 32
# of unsupported tests 3
I don't know why the number of passes (effectively # of tests run) is
reduced by more than a half with otherwise similar figures; it could be
due to the use of a simulator vs native test setup.
For some reason I haven't looked into libgo tests are deliberatly run
individually and results, concatenated into libgo-all.sum, have to be
processed manually to get a summary. Here's one I have come up with:
WARNING: program timed out.
FAIL: archive/zip
FAIL: cmd/go/internal/lockedfile/internal/filelock
FAIL: compress/flate
FAIL: compress/lzw
FAIL: compress/zlib
WARNING: program timed out.
FAIL: crypto/dsa
FAIL: crypto/tls
FAIL: database/sql
FAIL: html/template
FAIL: image/draw
FAIL: image/jpeg
FAIL: internal/cpu
FAIL: internal/x/crypto/cryptobyte
FAIL: internal/x/net/http/httpproxy
FAIL: log/syslog
FAIL: net
FAIL: net/http
FAIL: net/http/cgi
FAIL: net/http/internal
FAIL: net/http/pprof
FAIL: os
FAIL: os/exec
FAIL: os/signal
FAIL: reflect
WARNING: program timed out.
FAIL: regexp
WARNING: program timed out.
FAIL: runtime
FAIL: runtime/pprof
FAIL: sync
FAIL: sync/atomic
FAIL: syscall
FAIL: text/template
FAIL: time
=== libgo Summary ===
# of expected passes 136
# of unexpected failures 32
These are significantly worse, but I suspect the use of the user emulation
mode of QEMU may have contributed here.
No gotools tests run in my setup for some reason:
make[2]: Entering directory '.../gcc/gotools'
make[2]: Nothing to be done for 'check'.
make[2]: Leaving directory '.../gcc/gotools'
-- maybe this is not supported with a cross-toolchain.
I have current test results (also for the other frontends/libraries, e.g.
GNAT) with the same setup as well in case someone is interested. There
are minor differences.
Maciej
