cmd/compile: inconsistent shift operator type check

[hajimehoshi]

Go version

go version go1.22.0 darwin/arm64

Output of go env in your module/workspace:

GO111MODULE=''
GOARCH='arm64'
GOBIN=''
GOCACHE='/Users/hajimehoshi/Library/Caches/go-build'
GOENV='/Users/hajimehoshi/Library/Application Support/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='arm64'
GOHOSTOS='darwin'
GOINSECURE=''
GOMODCACHE='/Users/hajimehoshi/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='darwin'
GOPATH='/Users/hajimehoshi/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/usr/local/go'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/usr/local/go/pkg/tool/darwin_arm64'
GOVCS=''
GOVERSION='go1.22.0'
GCCGO='gccgo'
AR='ar'
CC='clang'
CXX='clang++'
CGO_ENABLED='1'
GOMOD='/dev/null'
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 -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -ffile-prefix-map=/var/folders/cj/73zbb35j0qx5t4b6rnqq0__h0000gn/T/go-build2140543503=/tmp/go-build -gno-record-gcc-switches -fno-common'

What did you do?

Run this:

package main

import "fmt"

func main() {
	s := 1
	a := 2.0 << s
	b := 2.0<<s + s<<3.0
	fmt.Println(a, b)
}

What did you see happen?

./main.go:7:7: invalid operation: shifted operand 2.0 (type float64) must be integer

What did you expect to see?

Both are errors, or both are correct. (I hope both are correct). Actually this program worked:

package main

import "fmt"

func main() {
	s := 1
	b := 2.0<<s + s<<3.0
	fmt.Println(b)
}

[hajimehoshi]

https://go.dev/play/p/OHnUA3weL8w might be a more minimized case:

package main

import "fmt"

func main() {
	a := 1
	b := 1.0<<a + 0 // Error
	c := 1.0<<a + int(0) // Not error
	fmt.Println(b, c)
}

[hajimehoshi]

The spec says:

If the left operand of a non-constant shift expression is an untyped constant, it is first implicitly converted to the type it would assume if the shift expression were replaced by its left operand alone.

So this seems an expected behavior. However, I feel like this caused counter-intuitive behaviors. Another example is:

package main

import "fmt"

func main() {
	s := 1
	a := int(1 << s)
	b := float32(1 << s) // Fail
	fmt.Println(a, b)
}

[zigo101]

Yes, it is not a bug.

There is indeed some counter-intuitive sometimes:

package main

const s = "Go101.org" // len(s) == 9
var a byte = 1 << len(s) / 128 // len(s) is a constant
var b byte = 1 << len(s[:]) / 128 // s[:] is not a constant, so not len(s[;]) too.

func main() {
	println(a, b) // 4 0
}

The reason for the design is to make the evaluation of y be consistent between 32-bit and 64-bit archs.

var n = 32
var y = int64(1 << n)

[hajimehoshi]

var n = 32
var y = int64(1 << n)

Hmm, but this varies between 32bits and 64bits. I was wondering why a shift operator is treated in a special way.

var n = 0x40000000
var y = int64(4 * n)

[zigo101]

var n = 32
var y = int64(1 << n)

Hmm, but this varies between 32bits and 64bits.

R u sure?

[hajimehoshi]

Yes, I am sure. On Windows:

> cat main.go
package main

import "fmt"

func main() {
        var n = 0x40000000
        var y = int64(4 * n)
        fmt.Println(y)
}
> go run main.go
4294967296
> & (Get-Process -Id $PID).Path { $env:GOARCH="386"; go run main.go }
0

[zigo101]

R u sure the '0' is the output of go run main.go?

[hajimehoshi]

Yes.

> cat main.go
package main

import (
       "fmt"
       "runtime"
)

func main() {
        fmt.Printf("GOARCH is %s\n", runtime.GOARCH)
        var n = 0x40000000
        var y = int64(4 * n)
        fmt.Println(y)
}

> go run main.go
GOARCH is arm64
4294967296

> & (Get-Process -Id $PID).Path { $env:GOARCH="386"; go run main.go }
GOARCH is 386
0

[hajimehoshi]

So, usually a binary operator determines an untyped value's type if the other is a typed value. However, a shift operator behaves in a very special way ignoring the right side value's type and using other contexts.

[ianlancetaylor]

This is how the language works, it is documented in the spec, and we aren't going to change it now.

There have been extensive discussions of this issue in the past on golang-nuts and in issues like #14844.

[zigo101]

If you are sure Windows 32-bit prints 0, then it might be a bug in my opinion.
(I think so, but @griesemer and @ianlancetaylor can give an authoritative answer.)

However, a shift operator behaves in a very special way ignoring the right side value's type and using other contexts.

Only when the right side is not a constant.