https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89123
Ian Lance Taylor changed:
What|Removed |Added
CC||doko at debian dot org
--- Comment
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?
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89123
--- Comment #11 from rdapp at linux dot ibm.com ---
Ping.
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
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
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
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
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
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
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
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
---
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/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89123
Jakub Jelinek changed:
What|Removed |Added
Target||s390x-linux
CC|
15 matches
Mail list logo
