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.
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=gcc=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
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=gcc=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
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.
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.
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=edit expvar assembler file
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91035 Richard Biener changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |10.0
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?