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.