cmd/compile: constant overflows when assigned to package level var (Go 1.20 regression) #58293

tklauser · 2023-02-03T14:24:00Z

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

$ go version
go version go1.20 linux/amd64

Does this issue reproduce with the latest release?

Yes, however it does not reproduce with Go 1.19 or earlier. So this looks like a regression in Go 1.20.

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

go env Output

$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/tklauser/.cache/go-build"
GOENV="/home/tklauser/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/tklauser/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/tklauser/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.20"
GCCGO="gccgo"
GOAMD64="v1"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/tklauser/src/go/src/go.mod"
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 -fdebug-prefix-map=/tmp/go-build1006501225=/tmp/go-build -gno-record-gcc-switches"

What did you do?

Some unit tests in the github.com/cilium/cilium/cilium/cmd package no longer built with a constant overflow error when being build with Go 1.20. They built fine and passed with Go 1.19 and earlier:

https://github.com/cilium/cilium/actions/runs/4083992015/jobs/7040172384

@ti-mo managed to come up with a minimal reproducer:

https://go.dev/play/p/ClBVgMEVVhG?v=gotip

What did you expect to see?

The reproducer (and the tests in package github.com/cilium/cilium/cmd) to build without errors using Go 1.20.

What did you see instead?

./prog.go:8:30: constant 3476277 overflows uint16
./prog.go:8:30: constant 3476224 overflows uint16

Go build failed.

The error only seems to occur if the result of bits.ReverseBytes16(13579) is assigned to a package level var. It builds fine if the result is assigned e.g. to a func level var.

Thanks to @ti-mo for helping me analyze this error and coming up with a minimal reproducer for playground.

The text was updated successfully, but these errors were encountered:

cuonglm · 2023-02-03T15:05:51Z

The problem is with inline static init, you can pass -d=inlstaticinit=0 to workaround this issue.

gopherbot · 2023-02-04T05:04:23Z

Change https://go.dev/cl/465096 mentions this issue: cmd/compile: fix inline static init for constant expression

tklauser · 2023-02-04T11:47:54Z

@gopherbot please consider this for backport to 1.20, it's a regression.

gopherbot · 2023-02-04T11:48:15Z

Backport issue(s) opened: #58319 (for 1.20).

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

….20.0" This reverts commit 80de240. The Golang v1.20.0 release includes a regression [1]. We should wait for a new patch release before updating. 1 - golang/go#58293 Reported-by: Tobias Klauser <tobias@cilium.io> Signed-off-by: Paul Chaignon <paul@cilium.io>

gopherbot · 2023-02-09T17:50:21Z

Change https://go.dev/cl/466277 mentions this issue: cmd/compile: rename EvalConst to EvalExpr

gopherbot · 2023-02-09T19:17:29Z

Change https://go.dev/cl/467015 mentions this issue: cmd/compile: disable inline static init optimization

gopherbot · 2023-02-09T19:25:00Z

Change https://go.dev/cl/467016 mentions this issue: cmd/compile: reenable inline static init

There are a plenty of regression in 1.20 with this optimization. This CL disable inline static init, so it's safer to backport to 1.20 branch. The optimization will be enabled again during 1.21 cycle. Updates #58293 Updates #58339 For #58293 Change-Id: If5916008597b46146b4dc7108c6b389d53f35e95 Reviewed-on: https://go-review.googlesource.com/c/go/+/467015 Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com> Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>

Since go1.19, these errors are already reported by types2 for any user's Go code. Compiler generated code, which looks like constant expression should be evaluated as non-constant semantic, which allows overflows. Fixes golang#58293 Change-Id: I6f0049a69bdb0a8d0d7a0db49c7badaa92598ea2 Reviewed-on: https://go-review.googlesource.com/c/go/+/465096 Reviewed-by: Matthew Dempsky <mdempsky@google.com> Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com> Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com> Reviewed-by: David Chase <drchase@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>

There are a plenty of regression in 1.20 with this optimization. This CL disable inline static init, so it's safer to backport to 1.20 branch. The optimization will be enabled again during 1.21 cycle. Updates golang#58293 Updates golang#58339 For golang#58293 Change-Id: If5916008597b46146b4dc7108c6b389d53f35e95 Reviewed-on: https://go-review.googlesource.com/c/go/+/467015 Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com> Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Auto-Submit: Cuong Manh Le <cuong.manhle.vn@gmail.com>

Static init inliner is using typecheck.EvalConst to handle string concatenation expressions. But static init inliner may reveal constant expressions after substitution, and the compiler needs to evaluate those expressions in non-constant semantic. Using typecheck.EvalConst, which always evaluates expressions in constant semantic, is not the right choice. For safety, this CL fold the logic to handle string concatenation to static init inliner, so there won't be regression in handling constant expressions in non-constant semantic. And also, future CL can simplify typecheck.EvalConst logic. Updates #58293 Updates #58339 Fixes #58439 Change-Id: I74068d99c245938e576afe9460cbd2b39677bbff Reviewed-on: https://go-review.googlesource.com/c/go/+/466277 Reviewed-by: Keith Randall <khr@google.com> Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Keith Randall <khr@golang.org>

Updates #58293 Updates #58339 Fixes #58439 Change-Id: I06d2d92f86fa4a672d69515c4066d69d3e0fc75b Reviewed-on: https://go-review.googlesource.com/c/go/+/467016 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Keith Randall <khr@golang.org> Run-TryBot: Cuong Manh Le <cuong.manhle.vn@gmail.com>

tklauser changed the title ~~cmd/compile/internal/typecheck: constant overflows when assinged to package level var (Go 1.20 regression)~~ cmd/compile/internal/typecheck: constant overflows when assigned to package level var (Go 1.20 regression) Feb 3, 2023

tklauser added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Feb 3, 2023

tklauser mentioned this issue Feb 3, 2023

Update Go to 1.20 cilium/cilium#23559

Closed

tklauser changed the title ~~cmd/compile/internal/typecheck: constant overflows when assigned to package level var (Go 1.20 regression)~~ cmd/compile: constant overflows when assigned to package level var (Go 1.20 regression) Feb 3, 2023

gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Feb 3, 2023

cuonglm mentioned this issue Feb 4, 2023

x/build: passing a const to a function which << it causes go1.20 to error in some contexts but not others. go1.19 didn't error. #58316

Closed

cuonglm self-assigned this Feb 4, 2023

cuonglm added this to the Go1.21 milestone Feb 4, 2023

cuonglm added NeedsFix The path to resolution is known, but the work has not been done. and removed NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Feb 4, 2023

gopherbot mentioned this issue Feb 4, 2023

cmd/compile: constant overflows when assigned to package level var (Go 1.20 regression) [1.20 backport] #58319

Closed

pchaigno mentioned this issue Feb 8, 2023

v1.13: revert golang 1.20.0 cilium/cilium#23626

Merged

gopherbot closed this as completed in fd208c8 Feb 9, 2023

cuonglm mentioned this issue Feb 9, 2023

cmd/compile: inline static init cause compile time error #58439

Closed

golang locked and limited conversation to collaborators Feb 9, 2024

gopherbot added the FrozenDueToAge label Feb 9, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

cmd/compile: constant overflows when assigned to package level var (Go 1.20 regression) #58293

cmd/compile: constant overflows when assigned to package level var (Go 1.20 regression) #58293

tklauser commented Feb 3, 2023 •

edited

cuonglm commented Feb 3, 2023

gopherbot commented Feb 4, 2023

tklauser commented Feb 4, 2023

gopherbot commented Feb 4, 2023

gopherbot commented Feb 9, 2023

gopherbot commented Feb 9, 2023

gopherbot commented Feb 9, 2023

cmd/compile: constant overflows when assigned to package level var (Go 1.20 regression) #58293

cmd/compile: constant overflows when assigned to package level var (Go 1.20 regression) #58293

Comments

tklauser commented Feb 3, 2023 • edited

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

Does this issue reproduce with the latest release?

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

What did you do?

What did you expect to see?

What did you see instead?

cuonglm commented Feb 3, 2023

gopherbot commented Feb 4, 2023

tklauser commented Feb 4, 2023

gopherbot commented Feb 4, 2023

gopherbot commented Feb 9, 2023

gopherbot commented Feb 9, 2023

gopherbot commented Feb 9, 2023

tklauser commented Feb 3, 2023 •

edited

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

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