Repository navigation
cmd/loopvec-toolexec: require the toolchain's exact Go version - #13
Merged
Merged
Conversation
ubuntu-latest is now ubuntu-26.04, which has no qemu-user-static package, so every run fails at the install step and skips the arm64 tsvc run, the golden check, fmt and lint. qemu-user ships the static emulators there; link qemu-aarch64-static to it when the name is missing, as the Makefile runs that name.
Go tip writes export data in iexport version 4, which encodes float constants exactly. x/tools v0.51.0, and the v0.52.0 release, read only up to version 3, so on tip go/packages fails for every package: cannot import "math" (unstable iexport format version 4, just rebuild compiler and std library), export data is newer version - update tool and every script that runs loopvec fails in the tip job. x/tools master reads version 4 (golang/tools@966056e2637c). Update to it until a release includes it. The pinned toolchain is unaffected.
go1.27.3 is the latest 1.27 release. Its simd package is the same as go1.27.1's, so the capability table only changes in its header, and the -methods crash (golang/go#80657) is still there, as flag_methods_ice.txt checks. go.mod keeps go 1.27.1: that is the first release whose simd package loopvec's output compiles against (go1.27.0's ShiftAllRight takes a uint8).
thesyncim
force-pushed
the
toolexec-exact-version
branch
from
October 31, 2026 22:10
a17e43f to
3b7b5a3
Compare
The wrapper rewrites a package only when it was built with the same Go release as the toolchain running the build, and compared releases as go1.27. But the simd package can change in a patch release without go/types seeing it: go1.27.0 declares ShiftAllRight(uint64) in its stubs and compiles it as taking a uint8, go1.27.1 takes a uint64. A wrapper built with go1.27.1 or later rewrote a go1.27.0 build into code that type-checked here and then failed to compile, so the build failed: cannot use uint64(31) (constant 31 of type uint64) as uint8 value in argument to _v1.ShiftAllRight The wrapper now compares the whole version word (go1.27.3, go1.28rc1, a development build's go1.28-6ae0b1f8a9, or a vendor's go1.27.3-acme), as toolexec.md already asks: build loopvec-toolexec with the same Go toolchain that runs the build. Experiments are left out of it: the compiler reports go1.27.3 X:simd, while a wrapper built with GOEXPERIMENT=simd reports go1.27.3-X:simd. A version it cannot find never matches.
thesyncim
force-pushed
the
toolexec-exact-version
branch
from
October 31, 2026 23:20
3b7b5a3 to
fb09951
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Stacked on #4.
I tried the wrapper on goav1, which was still on go1.27.0, with a wrapper built by 1.27.1, and the build failed instead of falling back:
go1.27.0's simd stubs declare
ShiftAllRight(uint64), but the compiler implements it with auint8(1.27.1 fixed that). go/types only sees the stubs, so the rewritten package type-checks in the wrapper and then fails in the compiler. The release check comparedgo1.27togo1.27, so nothing stopped it.This compares the whole version word instead:
go1.27.3,go1.28rc1, tip'sgo1.28-<hash>, or a vendor build such asgo1.27.3-acme. Experiments are left out, and the two sides spell them differently: the compiler saysgo1.27.3 X:simd, while a wrapper built withGOEXPERIMENT=simdreportsgo1.27.3-X:simd. A version it can't find never matches. toolexec.md already says to build the wrapper with the toolchain that runs the build; now a mismatch leaves packages unchanged with the existing debug message.toolexec_toolchain_mismatch.txtgets a same-release, different-patch case, and a unit test covers the version strings (releases, prereleases, tip, vendor builds, with and without experiments). The scripts build the wrapper withoutGOEXPERIMENT, so I also checked by hand that a wrapper built withGOEXPERIMENT=simdrewrites under go1.27.3 and skips under go1.27.1.