cmd/compile (and gccgo): wrong package initialization order

[mdempsky]

For the program below, my reading of the Go spec is that the output should be e a b c d. This is what go/types computes for its InitOrder.

cmd/compile instead prints a d e b c.

gccgo prints a b d e c.

package main

var sp = ""

func f(name string, _ ...interface{}) int {
	print(sp, name)
	sp = " "
	return 0
}

var a = f("a", x)
var b = f("b", y)
var c = f("c", z)
var d = func() int {
	if false {
		_ = z
	}
	return f("d")
}()
var e = f("e")

var x int
var y int = 42
var z int = func() int { return 42 }()

func main() { println() }

/cc @griesemer @ianlancetaylor

[mdempsky]

For cmd/compile, there are two issues here:

1. The Go spec says (emphasis added): "More precisely, a package-level variable is considered ready for initialization if it is not yet initialized and either has no initialization expression or its initialization expression has no dependencies on uninitialized variables." That is, even variables without initialization expressions still start out not yet initialized and have to wait their turn for initialization just like a variable declaration that uses an explicit zero initializer.

   cmd/compile gets this wrong because it doesn't emit assignments to zero initialize the variables (since package-level variables are zero initialized anyway), but then the sorting algorithm treats a variable without any pending assignments as already initialized. Consequently, cmd/compile fails to respect a's dependency on x.

2. cmd/compile applies its early deadcode optimization before applying the sorting algorithm. Consequently, cmd/compile fails to respect d's dependency on z.

I suspect gccgo's issues are similar.

[gopherbot]

Change https://golang.org/cl/280976 mentions this issue: [dev.regabi] cmd/compile: fix package-initialization order