Go version
go version go1.28-devel_9d8bad3bbd Wed Jul 29 20:42:23 2026 -0700 X:runtimefreegc windows/amd64
Output of go env in your module/workspace:
set AR=ar
set CC=gcc
set CGO_CFLAGS=-O2 -g
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-O2 -g
set CGO_ENABLED=1
set CGO_FFLAGS=-O2 -g
set CGO_LDFLAGS=-O2 -g
set CXX=g++
set GCCGO=gccgo
set GO111MODULE=
set GOAMD64=v1
set GOARCH=amd64
set GOAUTH=netrc
set GOBIN=C:\Users\HUAWEI\go\bin
set GOCACHE=C:\Users\HUAWEI\AppData\Local\go-build
set GOCACHEPROG=
set GODEBUG=
set GOENV=C:\Users\HUAWEI\AppData\Roaming\go\env
set GOEXE=.exe
set GOEXPERIMENT=runtimefreegc
set GOFIPS140=off
set GOFLAGS=
set GOGCCFLAGS=-m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=C:\Users\HUAWEI\AppData\Local\Temp\go-build934324432=/tmp/go-build -gno-record-gcc-switches
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GOMOD=NUL
set GOMODCACHE=C:\Users\HUAWEI\go\pkg\mod
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPACKAGESDRIVER=
set GOPATH=C:\Users\HUAWEI\go
set GOPRIVATE=
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=D:\go_runtimefree\go-runtimefree-issue-repro
set GOSUMDB=sum.golang.org
set GOTELEMETRY=local
set GOTELEMETRYDIR=C:\Users\HUAWEI\AppData\Roaming\go\telemetry
set GOTMPDIR=
set GOTOOLCHAIN=auto
set GOTOOLDIR=D:\go_runtimefree\go-runtimefree-issue-repro\pkg\tool\windows_amd64
set GOVCS=
set GOVERSION=go1.28-devel_9d8bad3bbd Wed Jul 29 20:42:23 2026 -0700 X:runtimefreegc
set GOWORK=
set PKG_CONFIG=pkg-config
What did you do?
I built the Go toolchain with GOEXPERIMENT=runtimefreegc and compiled the following program:
package p
func f(n int) ([]int, []int) {
r := make([]int, n, n)
var old []int
r, old = append(r, n), r
return r, old
}The slice is created with len(r) == cap(r), so the append must grow the backing array.
On PowerShell:
$env:GOEXPERIMENT = "runtimefreegc"
go tool compile -S multiassign.go
What did you see happen?
The compiler lowers the append to:
CALL runtime.growsliceNoAlias(SB)
This append is not actually no-alias.
The right-hand-side expressions of the multi-assignment are evaluated before the assignments are performed. Therefore, the second RHS retains the old slice header in old.
The alias analysis currently records the first self-append as a NoAlias append immediately. When the later RHS r invalidates the candidate, the already-recorded decision cannot be revoked.
With runtimefreegc, growsliceNoAlias may release the old pointer-free backing array even though old still refers to it.
What did you expect to see?
The compiler should use the ordinary growslice path:
CALL runtime.growslice(SB)
The NoAlias decision should only be committed after all operands of the assignment have been analyzed and the slice is still a valid candidate.
Additional information
This is related to the runtimefreegc tracking issue #74299.
It is different from #79909, which involves a range statement retaining the slice backing store.
Go version
go version go1.28-devel_9d8bad3bbd Wed Jul 29 20:42:23 2026 -0700 X:runtimefreegc windows/amd64
Output of
go envin your module/workspace:What did you do?
I built the Go toolchain with GOEXPERIMENT=runtimefreegc and compiled the following program:
The slice is created with len(r) == cap(r), so the append must grow the backing array.
On PowerShell:
What did you see happen?
The compiler lowers the append to:
This append is not actually no-alias.
The right-hand-side expressions of the multi-assignment are evaluated before the assignments are performed. Therefore, the second RHS retains the old slice header in old.
The alias analysis currently records the first self-append as a NoAlias append immediately. When the later RHS r invalidates the candidate, the already-recorded decision cannot be revoked.
With runtimefreegc, growsliceNoAlias may release the old pointer-free backing array even though old still refers to it.
What did you expect to see?
The compiler should use the ordinary growslice path:
CALL runtime.growslice(SB)
The NoAlias decision should only be committed after all operands of the assignment have been analyzed and the slice is still a valid candidate.
Additional information
This is related to the runtimefreegc tracking issue #74299.
It is different from #79909, which involves a range statement retaining the slice backing store.