Another example:

package main

import "fmt"

func f(p *int) int {
	*p++
	return *p
}

func main() {
	var x int
	x, z := f(&x), f(&x)
	fmt.Println(x, z) // gc: 1 2.  gccgo: 2 1
}

It looks this order is specified in Go spec and it looks the order in gccgo is wrong.

But the behaviors of the following one are the same.

package main

import "fmt"

func f(p *int) int {
	*p++
	return *p
}

func main() {
	var x int
	y, z := f(&x), f(&x)
	fmt.Println(y, z) // both: 1 2
}

BTW, the example provided in Go spec is not perfect.
It looks the indexing of x can only happen after i() and before j(), it is not not specified.
The description will be better it is modified as (by removing indexing of)

the function calls and communication happen in the order f(), h(), i(), j(), <-c, g(), and k().
However, the order of those events compared to the evaluation and x and
the evaluation of y is not specified. 

/cc @mdempsky @ianlancetaylor

To be honest, it's confusing when you use several different test cases with different behaviors in the same issue.

It's not yet clear to me that there are any bugs here at all. What matters with regard to order of evaluation is what the spec says. When the order of evaluation is not specified the spec, any order is permitted. So in the original message, although you say that gccgo is not consistent with itself, that may be true but it is not a bug. It would also not be a bug if gccgo chose one implementation one time and a different implementation another time; at least, it would not be a bug in how gccgo implements the spec.

So the only question here is: what does the spec require? And do the compilers implement that?

For the first example,

x, z := x, f(&x)

the spec doesn't specify whether x or f(&x) is evaluated first. That is, either of these two orderings are permitted:

1.  t0 := x
    t1 := f(&x)
    x, z := t0, t1
   

2.  t1 := f(&x)
    t0 := x
    x, z := t0, t1
   

gccgo uses the former, and gc uses the latter.

As for the second example,

x, z := f(&x), f(&x)

the spec requires they be evaluated left to right. That is, it must be equivalent to

t0 := f(&x)
t1 := f(&x)
x, z := t0, t1

It sounds like gc gets this right, but gccgo does not.

Just for clarity, this is the example that I believe gc gets right, but gccgo is misevaluating:

package main

import "fmt"

func f(p *int) int {
	*p++
	return *p
}

func main() {
	var x int
	x, z := f(&x), f(&x)
	fmt.Println(x, z) // gc: 1 2.  gccgo: 2 1
}