What version of Go are you using (go version)?
$ go version
go version go1.20 darwin/arm64
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="arm64"
GOBIN="/Users/eric/gopath/bin"
GOCACHE="/Users/eric/Library/Caches/go-build"
GOENV="/Users/eric/Library/Application Support/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="arm64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/eric/gopath/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/eric/gopath"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_arm64"
GOVCS=""
GOVERSION="go1.20"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/tmp/prove/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 -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/2f/2_yz21b92h94_pvr2m00gzh80000gn/T/go-build1716388533=/tmp/go-build -gno-record-gcc-switches -fno-common"
What did you do?
https://go.dev/play/p/OZrfW7G5A6i
What did you expect to see?
No bounds checking for the array lookup in B.
What did you see instead?
Bounds checking because the index variable is signed.
While the result of LeadingZeros64 is signed, the compiler should know that the possible range is [0, 64] and deduce that n (and therefore i) will always be positive. (Even better would be using the result of LeadingZeros64 directly since the the n == 0 case reduces the range to [0, 63].)
What version of Go are you using (
go version)?Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env)?go envOutputWhat did you do?
https://go.dev/play/p/OZrfW7G5A6i
What did you expect to see?
No bounds checking for the array lookup in
B.What did you see instead?
Bounds checking because the index variable is signed.
While the result of
LeadingZeros64is signed, the compiler should know that the possible range is [0, 64] and deduce thatn(and thereforei) will always be positive. (Even better would be using the result ofLeadingZeros64directly since the then == 0case reduces the range to [0, 63].)