cmd/compile: incorrect boolean value passed to function

[toolateforteddy]

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

go version go1.8rc2 darwin/amd64

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

GOARCH="amd64"
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"

What did you do?

https://play.golang.org/p/hebuAYQ6eo
Take the program above, that on go 1.7.4 prints out "The right thing.", and run that with a go compiler of version 1.8rc2. You now find that it prints out "The wrong thing." Additionally interesting, if you comment out line 15, the second call to "panicWhen", then the first call behaves correctly.

What did you expect to see?

I expect the program to panic with "The right thing."

What did you see instead?

The first call to panicWhen gets the argument cond as false, and panics with "The wrong thing."

[robpike]

Confirmed. This is a bug that appeared in 1.8.

[bradfitz]

/cc @randall77 @mdempsky @griesemer

[cherrymui]

The bug is in nilcheck phase, where there is a NilCheck Op in the same block as IsNonNil and happened to be stored before it (since values are not stored in order, until the scheduling phase). But logically NilCheck is after the IsNonNil.

[cherrymui]

I think we should explicitly check the memory to set/clear nonNilValues.

[dsnet]

If it helps, git-bisect shows the offending commit as: 3134ab3, which is a trivial change of only a thousand or so lines ;)

[cherrymui]

@dsnet, yes, that is it. Before that commit, NilCheck always introduces a new block (BlockCheck) which enforces the value ordering. After that, it no longer introduces new block, so NilCheck could affect values in the same block but logically before it.

[tzneal]

Not sure where gopherbot is, there's a CL at http://golang.org/cl/35495

[randall77]

Also proposed CLs at https://golang.org/cl/35496 (Cherry's) and https://golang.org/cl/35485 (mine).