Comment 1:

The order seems semi-arbitrary. If it were fully dependent on makeOrder, then the output
should be `6 2 4 5 3 1`, not `6 2 5 3 4 1`.
Is the reason gccgo produces the correct order that it's optimizing away the blank
assignment?

Comment 2:

gccgo is not optimizing away the blank assignment.
It's clear that the blank assignment depends on a,b,c,d,e,f, therefore it must be
initialized after they are all initialized.  However, there are no dependencies among
a,b,c,d,e,f, therefore they must be initialized in source code order.  So the spec only
permits one order for this program, and gccgo implements the spec correctly.

Comment 3:

Here's another (simpler) example of diverging initialization order:
http://play.golang.org/p/aYAWMqmJZU
The f() calls are simply to illustrate the initialization order - they do not (should
not) affect the order in this case. All three front-ends produce different (!) results:
1) gc produces: cbda
2) gccgo produces: abcd
3) go/types produces: bcda
d depends on b and c so d comes after b, c. b and c are independent, so they appear in
source order, leading to the subsequence bcd for 2) and 3). For 1) the ordering of b and
c is as they appear "in the source" of the expression, while for 2) and 3) the ordering
is as b and c appear "in the source" of their declarations. Arguably, the interpretation
chosen by 2), 3) is more sensible (e.g. independent of different orderings of the same
variables in different expressions); and 1) is incorrect.
d appears before a in the source, leading to interpretation 3), but a appears before b
and c in the source, leading to interpretation 2) (and a is independent of b, c, d).
Both 2) and 3) seem valid interpretations of the spec.
See also issue #7137 (related, but not the same).

Status changed to Accepted.

Comment 4:

Status changed to Duplicate.

Merged into issue #7320.