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

$ go version
go version go1.14.3 linux/amd64

Does this issue reproduce with the latest release?

Yes.

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

$ go env
GO111MODULE="on"
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/mero/.cache/go-build"
GOENV="/home/mero/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/mero"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/mero/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/mero/go/pkg/tool/linux_amd64"
GCCGO="/usr/bin/gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/dev/null"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build637886539=/tmp/go-build -gno-record-gcc-switches"

What did you do?

I used unsafe to create a []int with len/cap 1 and data pointing at 0:

Program 1

func main() {
	x := *(*[]int)(unsafe.Pointer(&reflect.SliceHeader{Len: 1, Cap: 1}))
	p := &x[0]
	fmt.Println(p, p == nil, interface{}(p) == (*int)(nil))
}

Program 2

func main() {
	x := *(*[]int)(unsafe.Pointer(&reflect.SliceHeader{Len: 1, Cap: 1}))
	p := x[0]
	fmt.Println(p)
}

What did you expect to see?

According to the spec, both programs should panic:

If the evaluation of x would cause a run-time panic, then the evaluation of &x does too.

What did you see instead?

Only Program 2 panics. Also, even though p is nil in Program 1, comparing it to nil evaluates to false. I assume this is due to the compiler seeing how p is initialized and optimizing the comparison out - if you pass it through interface{}, the comparison ends up returning true (presumably fooling this optimization).

Now, arguably it is fine to violate the spec in this case, as we're using unsafe to trick the compiler. I haven't tested if something similar happens if we'd, say, create a PROT_NONE mapping and do the same addressing (I assume it does, though). I just wanted to tell you about it after I found it.