Go: cmd/compile: incorrect boolean value passed to function

Created on 20 Jan 2017  路  9Comments  路  Source: golang/go

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."

FrozenDueToAge NeedsFix

Most helpful comment

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

All 9 comments

Confirmed. This is a bug that appeared in 1.8.

/cc @randall77 @mdempsky @griesemer

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.

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

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

@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.

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

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

CL https://golang.org/cl/35496 mentions this issue.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

stub42 picture stub42  路  3Comments

natefinch picture natefinch  路  3Comments

gopherbot picture gopherbot  路  3Comments

jayhuang75 picture jayhuang75  路  3Comments

ajstarks picture ajstarks  路  3Comments