@josharian sorry about that. What is compilebench? Where are its sources? I'll send you a PR.

https://godoc.org/rsc.io/compilebench

@josharian I'm not able to repro your failure. Do you mind double checking that your source tree is in a consistent state?

In particular, that error message only looks possible if only half of CL 20350 was applied to your source tree somehow: CL 20350 both changed obj.AJMP's type to obj.As and changed Gbranch's first parameter from int to obj.As.

Huh. Looks like compilebench needs to be compiled with (roughly) the same Go version as it is benchmarking. Mine was built with 1.6. Pity, because I'd rather use a stable release to build my tools, but...I'm going to call this wontfix for now.

@josharian FYI, I'm able to reproduce your failure if I build compilebench using ~/go15 (which is not on my PATH), but then try to use it to benchmark the compiler from ~/go (which is).

What seems to happen is:

1. compilebench uses go/build to find the compiler sources for benchmarking. Because I don't set GOROOT, it uses the path string compiled into package runtime. And since it was built from ~/go15, that path is ~/go15.
2. compilebench then finds the compiler sources in ~/go15/src/cmd/compile/internal/gc.
3. However, when compilebench actually invokes the Go compiler, it uses ~/go/pkg/tool/linux_amd64/compile, which does the opposite: again since GOROOT is unset, it uses the hardcoded ~/go path in package runtime, and tries compiling ~/go15's package gc sources against ~/go/pkg/linux_amd64/cmd/internal/obj.a, etc.

One workaround is to run compilebench as "GOROOT=$(go env GOROOT) compilebench".