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
mauri870
added a commit
that referenced
this pull request
Nov 3, 2026
) Follow-up to #2. #2 started replacing every constant start or limit with its value, so that the checks parsing `Trip.Start`/`Trip.Limit` as text would also see named constants. The emitted file is compiled for every build, though, and a named constant can have a different value in another one. With `const width = 32` for amd64 and `64` for arm64, `loopvec -split` on amd64 hard-coded `32` into the vector loop of `for i := 0; i < width; i++`, while the scalar fallback kept `width`. The arm64 build would then vectorize only half the elements. `plusOne` and `i > low` loops had always done the same for `<=` limits and loops that count down. What changes: - **Constant names are kept.** `Trip` carries the values of a constant start and limit. The checks read those values instead of parsing text: the negative-index check, the short-loop rule and the copy check. A constant is written as its value only when it's built from literals alone (`16`, `1 - 1`). A constant that uses a name keeps the name. `i <= width-1` comes out as `width`. - **Dead code removed.** `negativeSource` could no longer return true after #2. - **The negative-index check can't overflow.** It negates the offset instead of adding it to the bound. It also runs in the same pass over the loop body as the stored-offset checks. - **Bounds pushed past the largest int are rejected.** A positive offset that pushes a constant start or limit past the largest int is rejected as that bound. `for i := 0; i < math.MaxInt64; i++ { dst[i] = a[i+1] }` used to produce an overlap window of `math.MaxInt64 + 1`, which doesn't compile. - **Tests:** - `offset_negative_constant.txt` now checks the rewritten source and runs the loops under both builds. - The rejected loops moved to `offset_negative_constant_no_rewrite.txt`, which adds a loop counting down to 0, a range over a slice, and the two loops pushed past the largest int. - `bound_arch_constant.txt` covers the GOARCH case for `<`, `<=`, counting down and `>`. - **AGENTS.md** documents the new rejections and the rule for keeping names. Tested locally: - `bound_arch_constant.txt` fails against #2's `internal/loopir`, which writes `_ = dst[32-1]` where the test expects `_ = dst[width-1]`. - `make test` and `make test-qemu-arm64` pass. - `make test-update` and `make fix` leave no diff, and `make lint` reports 0 issues. - `loopvec -json` gives identical output before and after over std (1663 loops) and gonum (3252 loops).
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.