Seems like it affects all 32-bit architectures. E.g., reproduce locally with:

$ cd $GOROOT/test
$ go build run.go
$ GOARCH=386 ./run -- fixedbugs/issue39292.go
$ GOARCH=arm ./run -- fixedbugs/issue39292.go
$ GOARCH=mips ./run -- fixedbugs/issue39292.go
$ GOARCH=mipsle ./run -- fixedbugs/issue39292.go

Seems like it affects all 32-bit architectures. E.g., reproduce locally with:

$ cd $GOROOT/test
$ go build run.go
$ GOARCH=386 ./run -- fixedbugs/issue39292.go
$ GOARCH=arm ./run -- fixedbugs/issue39292.go
$ GOARCH=mips ./run -- fixedbugs/issue39292.go
$ GOARCH=mipsle ./run -- fixedbugs/issue39292.go

Only freebsd 11_2 386 passed.

Oh, lol, it's because the threshold for forcing heap allocations is 64kB, and an array of [10000]*int has size 80kB (>64kB) on 64-bit architectures, but 40kB (<64kB) on 32-bit architectures.

I think bumping the array length from 10,000 to 20,000 should be fine.

Only freebsd 11_2 386 passed.

I wouldn't be surprised if that builder skips running regression tests.

Change https://golang.org/cl/248697 mentions this issue: Revert "cmd/compile: handle OCLOSURE/OCALLPART in mustHeapAlloc check"

Change https://golang.org/cl/248680 mentions this issue: test: bump array size in fixedbugs/issue39292.go

Change https://golang.org/cl/248698 mentions this issue: test: bump array length to 20000 for testing issue 39292

@cuonglm Thanks for flagging this.