This looks like a bug with unsafe.Add of smaller-than-word offsets.
The generated code is:

	0x0068 00104 (/Users/khr/gowork/issue48536.go:19)	SETHI	CL
	0x006b 00107 (/Users/khr/gowork/issue48536.go:23)	ADDQ	"".dstNext+64(SP), CX
	0x0070 00112 (/Users/khr/gowork/issue48536.go:23)	MOVQ	CX, "".dstNext+64(SP)

But SETHI only writes the low byte of CX. The upper portions are junk, which in this case happen to be some other pointer. We end up adding two pointers together, which is not a valid pointer.

@mdempsky

I think we just need to convert the len to uintptr.

@randall77 darwin/arm64 does not fail, the generated code:

	0x0078 00120 (p.go:19)	CSET	HI, R4
	0x007c 00124 (p.go:23)	ADD	R4, R2, R2
	0x0080 00128 (p.go:23)	MOVD	R2, "".dstNext-8(SP)

any idea why?

x86 has weird legacy semantics for instructions like SETHI CL, where they only partially overwrite the CX register, leaving the rest of the bytes alone.

I'd assume that just doesn't apply to arm64 and instructions there always overwrite the full register.

@gopherbot Please open a backport issue to Go 1.17.

This appears to be a bug in the implementation of unsafe.Add. This should be fixed to avoid silent miscompilation of valid code.

Backport issue(s) opened: #48561 (for 1.17).

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

Simplified test case:

package main

import "unsafe"

var i = 257

func main() {
	var buf [10]byte
	p0 := unsafe.Pointer(&buf[0])
	p1 := unsafe.Pointer(&buf[1])

	if p := unsafe.Add(p0, uint8(i)); p != p1 {
		println("FAIL:", p, "!=", p1)
	}

	var x uint8
	if i != 0 {
		x = 1
	}
	if p := unsafe.Add(p0, x); p != p1 {
		println("FAIL:", p, "!=", p1)
	}
}

@cuonglm @mdempsky yes, ARM64 CSET instruction writes the full register.

Change https://golang.org/cl/351592 mentions this issue: cmd/compile: fix unsafe.Add with small-size offsets operands