cmd/compile: incorrect assembly output for 386

[ericlagergren]

Please answer these questions before submitting your issue. Thanks!

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

1.6.2 (on my laptop and Vagrant; unsure about play.golang.org)

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

Vagrant:

GOARCH="386"
GOBIN=""
GOEXE=""
GOHOSTARCH="386"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/vagrant/gopath"
GORACE=""
GOROOT="/usr/lib/go"
GOTOOLDIR="/usr/lib/go/pkg/tool/linux_386"
GO15VENDOREXPERIMENT="1"
CC="gcc"
GOGCCFLAGS="-fPIC -m32 -pthread -fmessage-length=0"
CXX="g++"
CGO_ENABLED="1"

Laptop:

GOARCH="amd64"
GOBIN="/home/eric/gopath/bin"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/eric/gopath"
GORACE=""
GOROOT="/usr/lib/go"
GOTOOLDIR="/usr/lib/go/pkg/tool/linux_amd64"
GO15VENDOREXPERIMENT="1"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0"
CXX="g++"
CGO_ENABLED="1"

1. What did you do?
   If possible, provide a recipe for reproducing the error.
   A complete runnable program is good.
   A link on play.golang.org is best.

I ran this (https://play.golang.org/p/HNidlIeDdb) in three separate environments:

My laptop
Vagrant
play.golang.org

1. What did you expect to see?

All three of them return 1 when +1 is passed.

1. What did you see instead?

• play.golang.org returned 1
• my laptop returned 1
• vagrant returned 0

I spoke with Tv` in #go-nuts to make sure I wasn't, well, going nuts and he came up with this repro: https://play.golang.org/p/VgyYHJAYu2

Here's the generated assembly from Vagrant:
objdump: https://gist.github.com/EricLagergren/8a53922a0f58dfef8d62710b062b637a
gcflags -S: https://gist.github.com/EricLagergren/93392d4977c63c74b0039c122b3d9b0b

Here's proof I didn't just goof up the Vagrant code 😀 : https://gist.github.com/EricLagergren/af4215805a0d88e426fde0c55696df3c

[randall77]

Looks like a bug in the 386 backend. (vagrant is 32-bit Go, the others are 64-bit Go).
Minimal repro:

package main

func main() {
    println(s(1))
}

//go:noinline
func s(x int64) int64 {
    return (-x) >> 63
}

[ericlagergren]

Aside: Is the playground not 32 bits? Its int caps out at 1 << 32 - 1

[randall77]

@ericlagergren , good question. I think maybe because the playground is amd64p32, or because it runs with -N. Not sure what its current state is.

[josharian]

Not a regression from 1.6, so while this is unfortunate, I think it should wait for 1.8 (where SSA will very likely fix it for free).

[randall77]

Yes, this is fixed with the 386 SSA backend. Should be in master momentarily.