cmd/compile: internal compiler error: out of range for go.shape.int64

[rokkerruslan]

internal compiler error: 9223372036854775808 out of range for go.shape.int64

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

Short program - https://go.dev/play/p/moV9U70P1pd

I am not attaching any information about the environment because it is reproduced on play.golang.org.

Yes, code is not ok, but compiler asks for a report.

[cuonglm]

Simpler reproducer:

package p

import (
	"unsafe"
)

func f[T int64](a T) T {
	return 1 << ((unsafe.Sizeof(a) * 8) - 1)
}

func g() {
	f(int64(1))
}

This seems to be a bug in Unified IR:

• go1.18 and go1.19 compile ok, but failed with GOEXPERIMENT=unified.
• go1.20 compile failed, but ok with GOEXPERIMENT=nounified.
• go1.21 compile ok after https://go-review.googlesource.com/c/go/+/469595

IIUC, Unified IR does constant folding for 1 << ((unsafe.Sizeof(a) * 8) - 1), which shoudn't be, because a is a type parameter, so the result of unsafe.Sizeof is not a Go constant:

The return value of Sizeof is a Go constant if the type of the argument x does not have variable size. (A type has variable size if it is a type parameter or if it is an array or struct type with elements of variable size).

In https://go-review.googlesource.com/c/go/+/469595, typecheck.EvalConst is removed, so the expression is not constant evaluated by the compiler anymore.

cc @mdempsky @griesemer

[griesemer]

Since 1.21 seems ok, is this a backport issue at this point?

[cuonglm]

Since 1.21 seems ok, is this a backport issue at this point?

I'm afraid not.

Removing typecheck.EvalConst is the final CL in a chain, which the main purpose is simplifying the code base, but fixed this bug un-intentionally.

Backport the CL is too risky.

Users who face this issue can use GOEXPERIMENT=nounified to workaround this issue, so I'm leaning to not backport this.

[mdempsky]

I think we can probably just suppress the overflow errors in typecheck for 1.20. types2 will have already errored about any spec-required overflows.

[gopherbot]

Change https://go.dev/cl/501735 mentions this issue: cmd/compile: supress overflow error in ir.IntVal

[cuonglm]

@gopherbot please backport this issue to go1.20, it's a compiler crash for legal user code.

[gopherbot]

Backport issue(s) opened: #60675 (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.

[cuonglm]

Requested freeze exception for this.

cc @golang/release

[dmitshur]

@cuonglm Thanks for letting us know, but I don't see what aspect of this needs a freeze exception and why. This seems to be a recently reported bug.

Please see https://golang.org/s/release#freeze-exceptions (we've made clarifying edits there recently) and if you still think a freeze exception is needed, please file it as a new issue with a detailed rationale. Thanks.

[mdempsky]

I don't think this needs a freeze exception for Go 1.21.

It's only an issue with Go 1.20. We can commit a fix directly to release-branch.go1.20.

I think adding the regress test case to master for 1.21 is fine though.

[cuonglm]

@dmitshur @mdempsky Ah, thanks for the clarification.

I think the change to ir.IntVal needs to be land to master then backport, so that would require freeze exception. If we can commit change directly to 1.20 branch, then it does not.

[cuonglm]

I found a reproducer for 1.21, too:

package p

import (
	"unsafe"
)

func shift[T any]() int64 {
	return 1 << unsafe.Sizeof(*new(T))
}

func div[T any]() uintptr {
	return 1 / unsafe.Sizeof(*new(T))
}

func add[T any]() int64 {
	return 1<<63 - 1 + int64(unsafe.Sizeof(*new(T)))
}

func f() {
	shift[[62]byte]()
	shift[[63]byte]()
	shift[[64]byte]()
	shift[[100]byte]()
	shift[[1e6]byte]()

	div[[0]byte]()
	add[[1]byte]()
}

[mknyszek]

Hey all, I'm doing a sweep of the Go 1.21 milestone compiler/runtime issues. Sounds like this is both a Go 1.21 and Go 1.20 issue. Do y'all still plan to work on it for Go 1.21? Thanks.

[cuonglm]

Hey all, I'm doing a sweep of the Go 1.21 milestone compiler/runtime issues. Sounds like this is both a Go 1.21 and Go 1.20 issue. Do y'all still plan to work on it for Go 1.21? Thanks.

Hey @mknyszek , yes, https://go.dev/cl/501735 will fix this.