[Bug go/91035] [10 Regression] gotools fails to build on s390x-linux-gnu

2019-10-10 Thread krebbel at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91035

--- Comment #8 from Andreas Krebbel  ---
With that patch GCCGO bootstraps fine until r275473 where libgo got updated to
version 1.13beta1. Then there are a few problems with hardware crypto support
on Z. I'll try to address these with separate patches and BZs.

I plan to commit the patch also to GCC 9 and 8 after giving it some time on
master.

[Bug go/91035] [10 Regression] gotools fails to build on s390x-linux-gnu

2019-10-10 Thread krebbel at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91035

--- Comment #7 from Andreas Krebbel  ---
Author: krebbel
Date: Thu Oct 10 07:56:25 2019
New Revision: 276790

URL: https://gcc.gnu.org/viewcvs?rev=276790&root=gcc&view=rev
Log:
S/390: PR91035 Fix call to __morestack

For the call to __morestack we use a special ABI in the S/390 back-end
which requires us to emit a parameter block to the .rodata section.
It contains the label whereto __morestack needs to return.  The
parameter block needs to be explicit in RTL since we also need to take
the address of it loaded into r1 in order to pass its address to
__morestack.  In order to express correctly what __morestack does its
RTX also contained the return label. Hence we had the return label to
occur twice in the insn stream.  This is problematic when it comes to
redirecting edges.  The correlation between these two occurrences of
the label cannot be expressed so when doing a redirect only the label
in the jump RTX gets modified while the parameter block label stays as
is.

The patch avoids having two instancs of the label by merging the
parameter block generation and the __morestack call RTX into one. By
doing this I could also get rid of the unspec which was required for
the parameter block generation so far.

gcc/ChangeLog:

2019-10-10  Andreas Krebbel  

PR target/91035
* config/s390/s390-protos.h (s390_output_split_stack_data): Add
prototype.
* config/s390/s390.md (UNSPECV_SPLIT_STACK_DATA): Remove.
("split_stack_data", "split_stack_call")
("split_stack_call_", "split_stack_cond_call")
("split_stack_cond_call_"): Remove.
("@split_stack_call", "@split_stack_cond_call"): New
insn definition.
* config/s390/s390.c (s390_output_split_stack_data): New function.
(s390_expand_split_stack_prologue): Use the merged expander.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/s390/s390-protos.h
trunk/gcc/config/s390/s390.c
trunk/gcc/config/s390/s390.md

[Bug go/91035] [10 Regression] gotools fails to build on s390x-linux-gnu

2019-09-05 Thread krebbel at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91035

Andreas Krebbel  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-09-05
 Ever confirmed|0   |1

--- Comment #6 from Andreas Krebbel  ---
Bisect indicates that the problem might be related to that change:

Author: ian
Date: Thu May 30 17:26:46 2019
New Revision: 271784

URL: https://gcc.gnu.org/viewcvs?rev=271784&root=gcc&view=rev
Log:
compiler: intrinsify sync/atomic functions

Let the Go frontend recognize sync/atomic functions and turn them
into intrinsics.

Also make sure not to intrinsify calls in go or defer statements.

Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/178937

Modified:
trunk/gcc/go/gofrontend/MERGE
trunk/gcc/go/gofrontend/expressions.cc
trunk/gcc/go/gofrontend/statements.cc

[Bug go/91035] [10 Regression] gotools fails to build on s390x-linux-gnu

2019-08-15 Thread ian at airs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91035

--- Comment #5 from Ian Lance Taylor  ---
It's hard to see how this could be a bug in the Go frontend.  At first glance
this looks like a problem with the split-stack support on S/390.

[Bug go/91035] [10 Regression] gotools fails to build on s390x-linux-gnu

2019-08-15 Thread doko at debian dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91035

--- Comment #4 from Matthias Klose  ---
looks like .L34 should be referenced instead of of .L37.

[Bug go/91035] [10 Regression] gotools fails to build on s390x-linux-gnu

2019-08-15 Thread doko at debian dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91035

--- Comment #3 from Matthias Klose  ---
Created attachment 46718
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46718&action=edit
expvar assembler file

[Bug go/91035] [10 Regression] gotools fails to build on s390x-linux-gnu

2019-08-15 Thread doko at debian dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91035

--- Comment #2 from Matthias Klose  ---
confirmed with trunk 20190815

build dir on
https://people.debian.org/~doko/tmp/tst-gotools.tar.xz

.L37 referenced in expvar.o

[Bug go/91035] [10 Regression] gotools fails to build on s390x-linux-gnu

2019-07-01 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91035

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4
   Target Milestone|--- |10.0

[Bug go/91035] [10 Regression] gotools fails to build on s390x-linux-gnu

2019-06-29 Thread ian at airs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91035

--- Comment #1 from Ian Lance Taylor  ---
As far as I know I don't have access to an S/390 system.  Anything you can do
to narrow down the problem would be helpful.  Like, for example, which function
has the undefined reference?