Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

cmd/compile: obj.As type broke compilebench #14720

Closed
josharian opened this issue Mar 8, 2016 · 5 comments
Closed

cmd/compile: obj.As type broke compilebench #14720

josharian opened this issue Mar 8, 2016 · 5 comments
Labels
FrozenDueToAge

Comments

@josharian
Copy link
Contributor

CL 20350 broke compilebench. As of that CL:

$ make.bash && compilebench
[snip make.bash output]
BenchmarkTemplate 1 459519466 ns/op
BenchmarkGoTypes 1 1593749048 ns/op
cgen.go:809: cannot use obj.AJMP (type obj.As) as type int in argument to Gbranch
cgen.go:1758: cannot use obj.AJMP (type obj.As) as type int in argument to Gbranch
cgen.go:1761: cannot use obj.AJMP (type obj.As) as type int in argument to Gbranch
cgen.go:1868: cannot use obj.AJMP (type obj.As) as type int in argument to Gbranch
cgen.go:1875: cannot use obj.AJMP (type obj.As) as type int in argument to Gbranch
cgen.go:1876: cannot use obj.AJMP (type obj.As) as type int in argument to Gbranch
cgen.go:1879: cannot use obj.AJMP (type obj.As) as type int in argument to Gbranch
cgen.go:1888: cannot use obj.AJMP (type obj.As) as type int in argument to Gbranch
cgen.go:1889: cannot use obj.AJMP (type obj.As) as type int in argument to Gbranch
cgen.go:1893: cannot use obj.AJMP (type obj.As) as type int in argument to Gbranch
cgen.go:1893: too many errors
compilebench: BenchmarkCompiler: exit status 2

cc @mdempsky @davecheney @bradfitz
@davecheney
Copy link
Contributor

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

@josharian
Copy link
Contributor Author

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

@mdempsky mdempsky self-assigned this Mar 8, 2016
@mdempsky
Copy link
Member

mdempsky commented Mar 8, 2016

@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.

@josharian
Copy link
Contributor Author

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.

@mdempsky
Copy link
Member

mdempsky commented Mar 9, 2016

@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".

@golang golang locked and limited conversation to collaborators Mar 13, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@davecheney @mdempsky @josharian @gopherbot