go: cmd/compile: closure (non-inlined code in general) integer conversions broken in go1.10beta1

Please answer these questions before submitting your issue. Thanks!

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

go version devel +9ce6b5c Thu Dec 7 17:38:51 2017 +0000 linux/amd64

a.k.a “go1.10beta1”

Does this issue reproduce with the latest release?

No, it can not be reproduced on go1.9 release.

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

GOARCH=“amd64” GOBIN=“/work/go/go/bin/” GOCACHE=“/home/user/.cache/go-build” GOEXE=“” GOHOSTARCH=“amd64” GOHOSTOS=“linux” GOOS=“linux” GOPATH=“/work/user/go” GORACE=“” GOROOT=“/work/go/go” GOTMPDIR=“” GOTOOLDIR=“/work/go/go/pkg/tool/linux_amd64” GCCGO=“/usr/bin/gccgo” CC=“gcc” CXX=“g++” CGO_ENABLED=“1” 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-build975595394=/tmp/go-build -gno-record-gcc-switches”

What did you do?

Ran the following (abstracted/extracted from my production code).

https://play.golang.org/p/jBT07pKiFE2

What did you expect to see?

I expected to see the identical functions, generate identical results, and so the example linked should print nothing.

In particular I expect an int32 value cast to uint32 cast to uint64, to produce an output that is representable in 32b, with the top 32b always 0.

What did you see instead?

What I see instead is that the function inside the closure produces an extended result; it appears the that something happens to the conversion --> uint64(uint32(int32)). I end up with a result where the top 32b are not zero, which looks broken to me, with reference to the language spec discussion on conversion.

In anycase I’d expect both the closure-generated function (via generator L17) and the function mask (L7) to produce identical results.

About this issue

  • Original URL
  • State: closed
  • Created 6 years ago
  • Comments: 20 (19 by maintainers)

Most upvoted comments

I’ve just checked and generating NEGL instead of NEGQ for DIVL also fixes this issue. But this can wait for go1.11

Should we open a new issue or queue up a CL for 1.11 to re-enable and fix the optimization?

@mdempsky, no need for re-open. We don’t branch Go 1.10 until the rc1. It’s not there yet: https://go.googlesource.com/go/+refs

In theory, zeroUpper32Bits could look into the argument of a Select. As it is late in release cycle, we would probably just disable this optimization for Select for now.

Introduced from https://go-review.googlesource.com/c/go/+/58090. cc @TocarIP