Bug 91035 - [10 Regression] gotools fails to build on s390x-linux-gnu
Summary: [10 Regression] gotools fails to build on s390x-linux-gnu
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 10.0
: P4 normal
Target Milestone: 10.0
Assignee: Andreas Krebbel
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-06-29 14:32 UTC by Matthias Klose
Modified: 2019-10-14 09:18 UTC (History)
3 users (show)

See Also:
Host:
Target: s390x-linux-gnu
Build:
Known to work: 9.1.1
Known to fail: 10.0
Last reconfirmed: 2019-09-05 00:00:00


Attachments
expvar assembler file (51.89 KB, application/x-xz)
2019-08-15 15:39 UTC, Matthias Klose
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Matthias Klose 2019-06-29 14:32:44 UTC
seen with trunk r272790, using a binutils build from trunK:

/<<PKGBUILDDIR>>/build/./gcc/gccgo -B/<<PKGBUILDDIR>>/build/./gcc/ -B/usr/lib/gcc-snapshot/s390x-linux-gnu/bin/ -B/usr/lib/gcc-sna
pshot/s390x-linux-gnu/lib/ -isystem /usr/lib/gcc-snapshot/s390x-linux-gnu/include -isystem /usr/lib/gcc-snapshot/s390x-linux-gnu/s
ys-include   -g -O2 -I ../s390x-linux-gnu/libgo -static-libstdc++ -static-libgcc -Wl,-z,relro -L ../s390x-linux-gnu/libgo -L ../s3
90x-linux-gnu/libgo/.libs -o buildid ../../src/gotools/../libgo/go/cmd/buildid/buildid.go ../../src/gotools/../libgo/go/cmd/buildi
d/doc.go ../s390x-linux-gnu/libgo/libgotool.a  
/usr/bin/s390x-linux-gnu-ld: ../s390x-linux-gnu/libgo/.libs/libgo.so: undefined reference to `.L37'
collect2: error: ld returned 1 exit status
make[4]: *** [Makefile:827: vet] Error 1
make[4]: *** Waiting for unfinished jobs....
/usr/bin/s390x-linux-gnu-ld: ../s390x-linux-gnu/libgo/.libs/libgo.so: undefined reference to `.L37'
collect2: error: ld returned 1 exit status
make[4]: *** [Makefile:829: buildid] Error 1
/usr/bin/s390x-linux-gnu-ld: ../s390x-linux-gnu/libgo/.libs/libgo.so: undefined reference to `.L37'
collect2: error: ld returned 1 exit status
make[4]: *** [Makefile:821: go] Error 1
/usr/bin/s390x-linux-gnu-ld: ../s390x-linux-gnu/libgo/.libs/libgo.so: undefined reference to `.L37'
collect2: error: ld returned 1 exit status
make[4]: *** [Makefile:823: gofmt] Error 1
make[4]: Leaving directory '/<<PKGBUILDDIR>>/build/gotools'
make[3]: *** [Makefile:14968: all-gotools] Error 2
make[3]: Leaving directory '/<<PKGBUILDDIR>>/build'
make[2]: *** [Makefile:25314: bootstrap] Error 2
make[2]: Leaving directory '/<<PKGBUILDDIR>>/build'
TTTTT Sat, 29 Jun 2019 10:04:47 +0000
Comment 1 Ian Lance Taylor 2019-06-30 04:24:13 UTC
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?
Comment 2 Matthias Klose 2019-08-15 15:27:29 UTC
confirmed with trunk 20190815

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

.L37 referenced in expvar.o
Comment 3 Matthias Klose 2019-08-15 15:39:31 UTC
Created attachment 46718 [details]
expvar assembler file
Comment 4 Matthias Klose 2019-08-15 15:52:08 UTC
looks like .L34 should be referenced instead of of .L37.
Comment 5 Ian Lance Taylor 2019-08-16 05:07:05 UTC
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.
Comment 6 Andreas Krebbel 2019-09-05 14:31:38 UTC
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
Comment 7 Andreas Krebbel 2019-10-10 07:56:56 UTC
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  <krebbel@linux.ibm.com>

	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_<mode>", "split_stack_cond_call")
	("split_stack_cond_call_<mode>"): Remove.
	("@split_stack_call<mode>", "@split_stack_cond_call<mode>"): 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
Comment 8 Andreas Krebbel 2019-10-10 07:59:59 UTC
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.
Comment 9 Andreas Krebbel 2019-10-14 09:18:27 UTC
I've just posted two patches to fix the remaining GO build problems on S/390. Ian could you please pick those up to make GO build again on S/390?

Sync hardware facility names with other files in os_linux_s390x.go
https://gcc.gnu.org/ml/gcc-patches/2019-10/msg00963.html

GO S/390: Add kdsaQuery function
https://gcc.gnu.org/ml/gcc-patches/2019-10/msg00964.html