[Bug go/89123] Too many go test failures on s390x-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89123 Ian Lance Taylor changed: What|Removed |Added CC||doko at debian dot org --- Comment #15 from Ian Lance Taylor --- *** Bug 89277 has been marked as a duplicate of this bug. ***
[Bug go/89123] Too many go test failures on s390x-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89123 --- Comment #14 from Ian Lance Taylor --- OK, patch committed. Should we leave this bug report open?
[Bug go/89123] Too many go test failures on s390x-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89123 --- Comment #13 from ian at gcc dot gnu.org --- Author: ian Date: Fri Feb 15 14:51:10 2019 New Revision: 268941 URL: https://gcc.gnu.org/viewcvs?rev=268941=gcc=rev Log: PR go/89123 internal/cpu, runtime: add S/390 CPU capability support Patch by Robin Dapp. Updates https://gcc.gnu.org/PR89123 Reviewed-on: https://go-review.googlesource.com/c/162887 Modified: trunk/gcc/go/gofrontend/MERGE trunk/libgo/go/internal/cpu/cpu_gccgo.c trunk/libgo/go/internal/cpu/cpu_s390x.go trunk/libgo/go/runtime/os_linux_s390x.go
[Bug go/89123] Too many go test failures on s390x-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89123 --- Comment #12 from Ian Lance Taylor --- Sorry for the delay, will look at the patch now. You can test a single target libgo target by using make to build the /check target. For example, to test the bytes package, cd to the libgo build directory and run "make bytes/check".
[Bug go/89123] Too many go test failures on s390x-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89123 --- Comment #11 from rdapp at linux dot ibm.com --- Ping.
[Bug go/89123] Too many go test failures on s390x-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89123 --- Comment #10 from rdapp at linux dot ibm.com --- Created attachment 45621 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45621=edit Tentative patch for libgo on s390x I didn't manage to make much progress with analyzing the remaining FAILs but I guess this can wait until after this bug. Is there an easy/preferred way to build and debug a single test case without having to manually add a plethora of dependency arguments? Attached is a tentative patch that works for me on s390x and reduces the number of FAILs significantly. Does it look reasonable?
[Bug go/89123] Too many go test failures on s390x-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89123 --- Comment #9 from rdapp at linux dot ibm.com --- Thanks for the pointer, I implemented the functions and now the startup seems to be fully functional again. I'm still checking whether the remaining 50ish libgo test suite failures I see are due to my changes or something else.
[Bug go/89123] Too many go test failures on s390x-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89123 --- Comment #8 from Ian Lance Taylor --- Created attachment 45590 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45590=edit Sketch of patch Thanks. That does make the problem obvious. I've attached a sketch of what a patch should look like. Basically, we want to call instructions like stfle and km. As far as I can tell these are not available as GCC intrinsics, and as such will have to be invoked using __asm__. I'm not sure quite what that would look like on S/390. Hopefully this patch sketch will let you make some forward progress. Let me know if I can help.
[Bug go/89123] Too many go test failures on s390x-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89123
--- Comment #7 from rdapp at linux dot ibm.com ---
I did a full debug build of libgo and noticed that this changes the behavior of
the executable. When it would segfault with default -O2 before, it now seems
to rapidly allocate gigabytes of memory.
This happens in
doInit() in cpu_s390x.go:121
where we detect the CPU facilities.
Apparently the stfle call used to be in cpu_s390x.s which does not exist
anymore. Hence, the
{ panic("not implemented for gccgo") }
gets triggers and we end up in
panic.go:133
if len(pp.deferpool) == 0 && sched.deferpool != nil {
pp is 0x0 here and "__go_runtime_error" tries to handle this by a
runtime_panicstring which itself tries to defer again and so on.
Is cpu_s390x.s missing on purpose i.e. should it have been replaced by
something else?
[Bug go/89123] Too many go test failures on s390x-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89123 --- Comment #6 from Ian Lance Taylor --- Thanks. I could have predicted that that would be the change. Unfortunately that isn't useful as that is a huge change, bringing in a large number of upstream changes from the master Go library. While anything is possible I think it's relatively unlikely to be an endianness problem. The Go code works on a range of different processors, including big-endian ones like SPARC. It seems that programs are crashing fairly early in their run, so I recommend that you build a failing program and run it under the debugger so see where it crashes. That will probably suggest something. Or I'm willing to look at it if there is guest access available on an S/390 GNU/Linux system.
[Bug go/89123] Too many go test failures on s390x-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89123 --- Comment #5 from rdapp at linux dot ibm.com --- I performed a bisect using const-1.go as check and got the following likely culprit: b0751b120f1b83d8e48a7c2cac831aabbb0bc048 is the first bad commit commit b0751b120f1b83d8e48a7c2cac831aabbb0bc048 Author: ian Date: Mon Sep 24 21:46:21 2018 + libgo: update to Go 1.11 Reviewed-on: https://go-review.googlesource.com/136435 (rev. 264546) Dominik Vogt is no longer with IBM, so I'm going to look into it. I have no experience with go yet, though. Might this simply be a case of an oversight regarding big endian? Do we have another big-endian backend where go works?
[Bug go/89123] Too many go test failures on s390x-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89123 rdapp at linux dot ibm.com changed: What|Removed |Added CC||rdapp at linux dot ibm.com --- Comment #4 from rdapp at linux dot ibm.com --- I'm going to have a look.
[Bug go/89123] Too many go test failures on s390x-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89123 Ian Lance Taylor changed: What|Removed |Added CC||vogt at linux dot vnet.ibm.com --- Comment #3 from Ian Lance Taylor --- Clearly something is badly broken, but I don't know how to find out what it is. There is no S/390 machine on the GCC compile farm. Added Dominik Vogt who contributed the initial S/390 support to gccgo.
[Bug go/89123] Too many go test failures on s390x-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89123 --- Comment #2 from Jakub Jelinek --- For comparison, in pretty much the same build environment (20 days earlier) with 8.2.1 20190109 I see === go tests === Running target unix/ FAIL: ./index0-out.go execution, -O0 -g -fno-var-tracking-assignments FAIL: go.test/test/ken/cplx2.go execution, -O2 -g === go Summary for unix/ === # of expected passes7278 # of unexpected failures2 # of expected failures 1 # of untested testcases 7 # of unsupported tests 3 === libgo Summary === # of expected passes163 # of unexpected failures163 where the unexpected failures for libgo are with -m31 (only very few 31-bit libraries around).
[Bug go/89123] Too many go test failures on s390x-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89123 Jakub Jelinek changed: What|Removed |Added Target||s390x-linux CC||krebbel at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Most of the tests don't print anything interesting into the go.log, just Execution timeout is: 300 spawn [open ...] FAIL: go.go-torture/execute/const-1.go execution, -O2 and similar.
