cmd/compile: impossible slice access is compiled in spite of always panicking

[mariecurried]

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

go version go1.11 windows/amd64

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

set GOARCH=amd64
set GOBIN=
set GOCACHE=...
set GOEXE=.exe
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOOS=windows
set GOPATH=...
set GOPROXY=
set GORACE=
set GOROOT=C:\Go
set GOTMPDIR=
set GOTOOLDIR=C:\Go\pkg\tool\windows_amd64
set GCCGO=gccgo
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 -fdebug-prefix-map=... -gno-record-gcc-switches

What did you do?

I compiled the following function: https://play.golang.org/p/Opd10xBfZKu

What did you expect to see?

I expected the code not to compile, because the position len(slice)*2 can never be a valid position in the slice.

What did you see instead?

The code was compiled with bounds checks and always panics because of index out of range (the code produced is correct, but what I think is that it shouldn't be compiled in the first place - always results in panic).

Edit: after further testing, I noticed that the same happens for len(slice)+n, where n is a positive integer.

[cherrymui]

The spec (https://golang.org/ref/spec#Index_expressions) says

For a of slice type S:
if x is out of range at run time, a run-time panic occurs

So it should be a run-time panic, instead of compile-time error. I think this works as intended.

[ianlancetaylor]

Yes, this is correct behavior. We don't want to be a compilation error; the statement might never be executed.