cmd/compile: internal compiler error in unaligned pointer write

[brutalsavage]

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

$ go version
go version devel go1.21-6260049fa2

Does this issue reproduce with the latest release?

Reproduces on the most recent developer release branch, can see the later go-playground link

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

go env Output

$ go env
GO111MODULE=''
GOARCH='amd64'
GOBIN=''
GOCACHE='/home/.cache/go-build'
GOENV='/home/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMODCACHE='/home/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/home/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/home/goroot'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/home/goroot/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='devel go1.21-6260049fa2'
GCCGO='gccgo'
GOAMD64='v1'
AR='ar'
CC='gcc'
CXX='g++'
CGO_ENABLED='1'
GOMOD='/dev/null'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build531354456=/tmp/go-build -gno-record-gcc-switches'

What did you do?

modifying unsafe.Pointer data leads to internal compiler error. (i.e go build the following code)

package main

import (
	"fmt"
	"reflect"
	"unsafe"
)

var slice = []byte{'H', 'e', 'l', 'l', 'o', ','}

func main() {
	ptr := uintptr(unsafe.Pointer(&slice)) + 100
	header := (*reflect.SliceHeader)(unsafe.Pointer(ptr))
	header.Data += 1 // comment this line does not lead to internal compiler error
	fmt.Printf("%d %d\n", cap(slice), header.Cap)
}

go.dev link to reproduce.

What did you expect to see?

Does not lead to internal compiler error

What did you see instead?

<unknown line number>: internal compiler error: 'main': unaligned pointer write

goroutine 9 [running]:
runtime/debug.Stack()
	/usr/local/go/src/runtime/debug/stack.go:24 +0x5e
cmd/compile/internal/base.FatalfAt({0x431324?, 0xc0?}, {0xc0006b3168, 0x1d}, {0xc0006b3190, 0x1, 0x1})
	/usr/local/go/src/cmd/compile/internal/base/print.go:230 +0x1d7
cmd/compile/internal/base.Fatalf(...)
	/usr/local/go/src/cmd/compile/internal/base/print.go:199
cmd/compile/internal/ssagen.(*ssafn).Fatalf(0xc0006b31f8?, {0xcc3080?, 0x0?}, {0xd7d5f0, 0x17}, {0x0, 0x0, 0x6?})
	/usr/local/go/src/cmd/compile/internal/ssagen/ssa.go:7997 +0x16a
cmd/compile/internal/ssa.(*Value).Fatalf(...)
	/usr/local/go/src/cmd/compile/internal/ssa/value.go:454
cmd/compile/internal/ssa.mightContainHeapPointer(0xc0003daae0?, 0x8, 0xc0005e86f0, 0x1?)
	/usr/local/go/src/cmd/compile/internal/ssa/writebarrier.go:57 +0x12f
cmd/compile/internal/ssa.needwb(...)
	/usr/local/go/src/cmd/compile/internal/ssa/writebarrier.go:95
cmd/compile/internal/ssa.writebarrier(0xc00043bba0)
	/usr/local/go/src/cmd/compile/internal/ssa/writebarrier.go:201 +0x47ba
cmd/compile/internal/ssa.Compile(0xc00043bba0)
	/usr/local/go/src/cmd/compile/internal/ssa/compile.go:97 +0x9ab
cmd/compile/internal/ssagen.buildssa(0xc000486000, 0x3)
	/usr/local/go/src/cmd/compile/internal/ssagen/ssa.go:568 +0x2b09
cmd/compile/internal/ssagen.Compile(0xc000486000, 0x0?)
	/usr/local/go/src/cmd/compile/internal/ssagen/pgen.go:187 +0x45
cmd/compile/internal/gc.compileFunctions.func5.1(0xc000401ac0?)
	/usr/local/go/src/cmd/compile/internal/gc/compile.go:184 +0x34
cmd/compile/internal/gc.compileFunctions.func3.1()
	/usr/local/go/src/cmd/compile/internal/gc/compile.go:166 +0x30
created by cmd/compile/internal/gc.compileFunctions.func3 in goroutine 8
	/usr/local/go/src/cmd/compile/internal/gc/compile.go:165 +0x23a


Go build failed.

[randall77]

We could theoretically allow this to pass by removing the "offset must be a multiple of the pointer size" check. But there's really a multiple of invalid uses of unsafe here, so I'm not inclined to do that for this case. (Unless this example came up in a more realistic case? Please reopen if you have such a case.)

Note that this code doesn't obviously need a write barrier, as it is storing only uintptrs. The reason a write barrier appears is that the compiler promotes reflect.SliceHeader.Data from a uintptr to an unsafe.Pointer internally. Define your own similar type and this won't happen.

[ianlancetaylor]

This is not, perhaps, an important bug, but it is a bug. The compiler should not crash. We don't need to compile this kind of code but we should print an error message, not crash.

[gopherbot]

Change https://go.dev/cl/508555 mentions this issue: cmd/compile: don't ICE on unaligned offsets for pointer writes