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.
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
cmd/go: GODEBUGCPU does not affect caching #25659
Comments
Moving to Go 1.12. It's explicitly behind a GOEXPERIMENT flag because this isn't for users (yet?). It's for the build system to increase CPU coverage. |
@josharian: GODEBUGCPU itself should not effect compiler output as internal/cpu AFAIK is not used by the compiler to generate different code (the experiment flag does). Can you clarify that or how GODEBUGCPU (not GOEXPERIMENT) leads to different compiler output not just different runtime behaviour? Its experimental as it was started before but committed into the freeze and is for the go build infrastructure and devs to test around in go1.11 without committing to e.g. syntax or flag vs environment variable. For go1.11 not all features have options yet, not all runtime cpu feature variables have been migrated to internal/cpu and only Darwin and Linux are supported currently. Most of the these can be resolved for go1.12. For go1.11 I think adding GOEXPERIMENT? to the list of magic env variables is the easier fix for caching than making it a flag. For go1.12: I would be happy if we can remove the experiment protection and will write an issue to get agreement that this can be made permanent (possibly as a flag). |
I guess we should add GOEXPERIMENT to the build cache invalidation magic but not GODEBUGCPU: smoke test with sha1sum ../bin/go for:
|
running
|
actually the GOEXPERIMENT=debugcpu change is included in the compile buildID:
which is taken into account here: go/src/cmd/go/internal/work/exec.go Line 220 in 30b6bc3
go cache -clean Closing this bug. |
Thanks, and sorry for the noise. |
https://golang.org/cl/91737 added a new environment variable that controls compiler output. However, cmd/go does not know about it. It should probably either migrate to a command line flag or be added to the list at
go/src/cmd/go/internal/work/exec.go
Line 226 in 30b6bc3
(Aside: Why does this need to be protected by a GOEXPERIMENT build flag? Not obvious to me. I thought we were trying to move away from those.)
cc @martisch @bradfitz
The text was updated successfully, but these errors were encountered: