Please answer these questions before submitting your issue. Thanks!

What version of Go are you using (go version)?

go tip

What operating system and processor architecture are you using (go env)?

Ubuntu ppc64le

What did you do?

Built a golang from master, then tried to use it to do 'go get' on a ppc64le machine.

What did you expect to see?

Correct execution

What did you see instead?

go get -u golang.org/x/sys/unix
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x0]

goroutine 35 [running]:
panic(0x3b50a0, 0x684fd0)
/home/boger/golang/base/go/src/runtime/panic.go:531 +0x3e4
runtime.panicmem()
/home/boger/golang/base/go/src/runtime/panic.go:63 +0x64
runtime.sigpanic()
/home/boger/golang/base/go/src/runtime/signal_unix.go:348 +0x258
created by net/http.(*http2Transport).newClientConn
/home/boger/golang/base/go/src/net/http/h2_bundle.go:6003 +0x568

After much debugging, I found that the generated code for LoweredMove when the target is unaligned and the size is 4 or 8 the golang assembler is generating incorrect instructions, i.e., it is setting fields in the instruction that shouldn't be set. In the above case, the bad code was found in processPing prior to the call to WritePing:

2ea5f8: 0c 00 a5 e8 ld r5,12(r5)
2ea5fc: 29 00 a1 f8 stdu r5,40(r1)
2ea600: 20 00 81 f8 std r4,32(r1)
2ea604: 01 00 80 38 li r4,1
2ea608: 28 00 81 98 stb r4,40(r1)
2ea60c: 1d f6 fe 4b bl 2d9c28 <net/http.(*http2Framer).WritePing>

Doing a stdu based off r1 is really bad at this point because the stack gets messed up. I found other cases where the assembler generates illegal instructions that result in a SIGILL at runtime. This happens because some loads and stores are DS form instructions, while others are D form instructions. Those with DS form instructions have a different sized field for the offset value, and require offsets that are a multiple of 4, but the D form instructions allow any offsets. The assembler was treating all loads and stores as D form instructions and was not checking the offset's alignment.

There are two parts to this problem which I plan to fix with 2 CLs:

1. Fix PPC64.rules so it no longer generates asm with incorrect offsets when the load or store is a DS form. That fixes the regression, and I am continuing to test.
2. Fix the assembler to detect the cases where loads and stores are DS form but are using incorrect offset values and generate an error.

There probably should be some additional testcases for this problem but not sure on the best place to put those.