At least when cross-compiling from amd64 with GOARCH=s390x, math/pow10.go seems to compile identically before and after.

Change https://golang.org/cl/273271 mentions this issue: go/constant: add test for #42838

It looks like math/big.Rat.SetString is misbehaving on s390x. For SetString("1e192"), it's producing "3027621884171471837698311284263877940814570137795579187554254752777931419931368381990738248285955635616430044818426562647473833981586768834462721163780572037404681705524261520844063170669576192/1".

In hex, 1e192 should be (big-endian, 64 bits per line):

381c3de34e49d55a
a16ef894fd1ec505
c3c46289d6388cec
73add001e6a2cf4c
fea73c80f1b8a046
769dbb7e6412e125
a9e17e1fac815d01
0000000000000000
0000000000000000
0000000000000000

But the incorrect value that s390x is producing is:

a9e17e1fac815d01
fea73c80f1b8a046
769dbb7e6412e125
a9e17e1fac815d01
fea73c80f1b8a046
769dbb7e6412e125
a9e17e1fac815d01
0000000000000000
0000000000000000
0000000000000000

Notably, the last 6 words are correct, but then the first four words are words 5--7 repeating in cycle. It reminds me of the kind of data corruption you get when you use memcpy() instead of memmove() for overlapping data.

More reduced test case. Fails on s390x, but passes with -tags=math_big_pure_go:

func TestIssue42838_2(t *testing.T) {
	i := new(big.Int)
	i.SetString("159309191113245227702888039776771180559110455519261878607388585338616290151305816094308987472018268594098344692611135542392730712890625", 0)
	i = i.Lsh(i, 192)
	got := i.String()
	want := "1" + strings.Repeat("0", 192)
	if got != want {
		t.Errorf("got %v, want %v", got, want)
	}
}

Notably, changing i = i.Lsh(i, 192) to i = i.Lsh(new(big.Int).Set(i), 192) also makes it pass. So s390x's shlVU implementation appears not to handle when the x and z arguments alias.

Thanks for the detailed bug report @mdempsky. The problem is a forward copy in shlVU that is performed when the shift amount is 0. A member of my team is preparing a fix. Most likely we will simply remove the assembly implementation since compiler is generating pretty good code for shlVU_g these days.

@mundaym You may also want to verify that shrVU is doing the right thing (or likewise use the Go implementation).

Change https://golang.org/cl/274442 mentions this issue: math/big: remove the s390x assembly for shlVU and shrVU

@gopherbot please backport to Go 1.15. This was included in the latest release, but remains an issue without workaround in the previous one.

Backport issue(s) opened: #45335 (for 1.15).

Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://golang.org/wiki/MinorReleases.