cmd/compile: Value live at entry

[DrJosh9000]

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

$ go version
go version go1.19.1 darwin/amd64

Does this issue reproduce with the latest release?

Yes.

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

go env Output

$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/josh/Library/Caches/go-build"
GOENV="/Users/josh/Library/Application Support/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/josh/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/josh/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GOVCS=""
GOVERSION="go1.19.1"
GCCGO="gccgo"
GOAMD64="v1"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/josh/Code/adventofcode/go.mod"
GOWORK="/Users/josh/Code/adventofcode/go.work"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -arch x86_64 -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/nd/p9vyzdbj1r1_1_wpyd3k_lvr0000gn/T/go-build4128977174=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

https://go.dev/play/p/LgwHMT5v_EV

What did you expect to see?

Compile without error.

What did you see instead?

./prog.go:12:19: internal compiler error: 'Set[go.shape.int_0].Copy': Value live at entry. It shouldn't be. func Set[go.shape.int_0].Copy, node .dict0, value nil

Please file a bug report including a short program that triggers the error.
https://go.dev/issue/new

Go build failed.

[DrJosh9000]

The backport on that issue has milestone 1.19.1, which is the version I'm on, so either the backport is incomplete or this is a separate bug.

[cuonglm]

The backport on that issue has milestone 1.19.1, which is the version I'm on, so either the backport is incomplete or this is a separate bug.

go1.19.1 is a security release, so it's likely not include the backport.

cc @golang/release

Hmm, wait, I see the fix in go1.19.1: https://github.com/golang/go/commits/go1.19.1

Seems strange, on tip, it compiles ok in non-unified IR

go tool compile -d=unified=0 -p=main main.go

[cuonglm]

So #53702 is the issue with non-generic, this is about generic.

Surprisingly, https://go-review.googlesource.com/c/go/+/422196 fixes it.

Should we backport that fix? cc @mdempsky @randall77

[mdempsky]

Yeah, I think CL 422196 is safe to backport if it fixes a regression in 1.19.

[gopherbot]

Change https://go.dev/cl/428758 mentions this issue: test: add regression test for issue 54911

[cuonglm]

@gopherbot please backport this to go1.19

[gopherbot]

Backport issue(s) opened: #54917 (for 1.19).

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

[cuonglm]

@gopherbot please backport this to go1.18

[cuonglm]

Yeah, I think CL 422196 is safe to backport if it fixes a regression in 1.19.

Ack.

You're the owner of that CL, so please backport it when you have time 👍

[mdempsky]

So this issue affects both Go 1.18 and 1.19, including all of their point releases. So this isn't a regression per se; it's functionality that's never worked.

However, the underlying issue isn't generics specific. It was a latent issue in packages ir and inline, and merely exposed when the generics frontend started using ir.InitExpr to add init statements to OCLOSURE nodes to support certain generic expressions.

Theoretically, the issue here could lead to silent miscompilation of non-generics code. But looking at how we use ir.InitExpr in Go 1.18 and 1.19, it doesn't look like that can actually happen. I believe the only way the failure can manifest is as ICEs affecting generics code like reported in this issue.

Finally, the "no backports to Go 1.18 generics" policy is really about noder/stencil.go. That file is not really well understood by current team members, and attempts to fix issues in it have repeatedly introduced new issues. Those concerns don't apply here.

I'm weakly leaning towards backporting to both Go 1.18 and 1.19. I think the fix is safe and has real benefit to users; but I also don't think that's essential if we want to be conservative.