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

go version devel +616c39f6a6 Thu Sep 26 20:45:09 2019 +0000 linux/amd64

Does this issue reproduce with the latest release?

Yes

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

$ go env

GOARCH="ppc64"
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="aix"
GOPPC64="power8"

What did you do?

Cross-compilation of this program on aix/ppc64 by setting GOOS and GOARCH:

package main

func main() {
	testDuffZero()
}

var glob = 3
var globp *int64

// Compile with GOARCH=ppc64 and GOOS=aix

//go:noinline
func testDuffZero() (r, s, t, u int64) {
	defer func() {
		glob = 4
	}()
	// Force the output params to be heap allocated. The pointer to each output
	// param must be zeroed in the prologue (see plive.go:epilogue()). So we
	// will get a block of stack slots that needs to be zeroed. For size >= 32
	// and <= 1024, this leads to a obj.ADUFFZERO call on ppc64 (see
	// ppc64/ggen.go:zerorange), which then leads to a bug because of AIX's
	// use of obj9.go. It looks like progedit() changes the ADUFFZERO to have
	// a To.Type of TYPE_BRANCH, which then causes diagnostic in
	// rewriteToUseTOC()
	//
	// Error is:
	// tmp.go:19:2: do not know how to handle 00121 (tmp.go:11)        DUFFZERO        runtime.duffzero(SB) without TYPE_MEM

	globp = &r
	globp = &s
	globp = &t
	globp = &u
	return
}

What did you expect to see?

For the .go file to compile. It compiles fine on linux/amd64 architecture.

What did you see instead?

test.go:33:2: do not know how to handle 00121 (test.go:13)        DUFFZERO        runtime.duffzero(SB) without TYPE_MEM

I constructed this test case, after I ran into a similar problem when testing my open-coded defers CL https://go-review.googlesource.com/c/go/+/190098 . The open-coded defer implementation may require zeroing stack slots storing defer args, so the use of Arch.ZeroRange with larger ranges is more likely.

As described in the comments above, the pointer to each output param must be zeroed in the prologue (see plive.go:epilogue()). So we will get a block of stack slots that needs to be zeroed, and the compiler generates a call to obj.ADUFFZERO of size 32 on aix/ppc64 (see ppc64/ggen.go/zerorange). AIX uses obj9.go, which leads to the bug. It looks like progedit() changes the ADUFFZERO to have a To.Type of TYPE_BRANCH (see the first case), which then causes diagnostic in rewriteToUseTOC(). (under the 'p.To.Name == obj.NAME_EXTERN' if branch)

Seems most likely a fix would be in progedit(), but could also be in rewriteToUseTOC(), or we could change ppc64/ggen.co/zerorange to not use ADUFFZERO (use the other two zeroing methods exclusively).