CC @griesemer

gccgo prints 1 1.

It looks like the type checker is computing the correct order. Here is the initorder trace for the above code:

== initOrder ==
Computing initialization order for package p ("p")

Object dependency graph:
        x has no dependencies
        a depends on
                foo
        b depends on
                x
        foo depends on
                x
        main depends on
                a
                b

Transposed object dependency graph (functions eliminated):
        x depends on 0 nodes
                b is dependent
                a is dependent
        a depends on 1 nodes
        b depends on 1 nodes

Processing nodes:
        x (src pos 1) depends on 0 nodes now
        a (src pos 2) depends on 0 nodes now
        b (src pos 3) depends on 0 nodes now

Initialization order:
        x = 0
        a = foo()
        b = x

Yes, this looks like cmd/compile/internal/staticinit not getting it right somehow.
Initorder is generally computed and passed through unified IR export/import correctly. But then we don't use it? Something is odd here.

I'd like to dig further into this issue if no one else is claiming it.

change to this

var x = 0
var a = foo()
var b = x

func foo() int {
	x = x + 1       // diferent
	return x
}

func main() {
	println(a, b)
        // 1 1 # go1.22
        // 1 0 # go1.21
}

This is a bug in staticinit, where the compiler try optimizing:

var x = 0
var a = foo()
var b = x

to:

var x = 0
var a = ~r0
var b = 0

without recognizing that the optimization is unsafe, because foo was inlined.

Change https://go.dev/cl/575175 mentions this issue: cmd/compile: add missing OINLCAll case in mayModifyPkgVar

Reopening since the fix in CL 575175 was rolled back in CL 575316.

Change https://go.dev/cl/575216 mentions this issue: cmd/compile: add missing OASOP case in mayModifyPkgVar

@randall77 Should we backport this issue? Though it's not a regression, it causes mis-compilation and make binary behaves wrongly.

Change https://go.dev/cl/575336 mentions this issue: cmd/compile: check ODEREF for safe lhs in assignment during static init

I don't think we should backport this. It is not a problem that any realistic program runs into, and it is easy to work around if it does.