Skip to content

testdata: compare NaN results with the same machine's scalar build - #8

Merged
mauri870 merged 1 commit into
mauri870:masterfrom
thesyncim:nan-goldens-per-arch
Nov 3, 2026
Merged

mauri870 merged 1 commit into
mauri870:masterfrom
thesyncim:nan-goldens-per-arch

Conversation

@thesyncim

@thesyncim thesyncim commented Nov 1, 2026 •

Copy link
Copy Markdown
Contributor

abs_sqrt.txt, activation_temp.txt and invariant_call.txt compare both builds against testmain/output, which was recorded on amd64. A NaN produced by an operation (sqrt of a negative number, 0 × Inf) has the sign bit set on amd64 (0xffc00000) and clear on arm64 (0x7fc00000). So on arm64 even the scalar run differs from the recording, and the scripts fail before they get to the simd build.

What these scripts check is that the rewrite gives the same bits as the scalar loop on the machine running it. Now the recording is only compared on amd64, and on every target the simd output is compared against the scalar output saved on the same machine. -update only rewrites sections that already exist, so scalar.out never becomes a golden.

Found while running the suite on an M4 for goav1.

abs_sqrt.txt, activation_temp.txt and invariant_call.txt compare both
builds with testmain/output, which was recorded on amd64. A NaN that an
operation creates (the square root of a negative number, 0 times
infinity) has the sign bit set on amd64 and clear on arm64, so on arm64
the scalar program itself does not match the recording and the scripts
fail before the simd build runs.

The recording is now compared only on amd64. On every target the simd
build is compared with the scalar build of the same machine, which is
the property these scripts check: the rewrite produces the same bits
the scalar loop does there.
@thesyncim
thesyncim force-pushed the nan-goldens-per-arch branch from 93bfd01 to 0833715 Compare November 1, 2026 13:36
@mauri870

mauri870 commented Nov 3, 2026

Copy link
Copy Markdown
Owner

Thanks! I was under the impression arm64 tests were running on CI via QEMU emulation. I have to confirm if qemu emulation is broken or simply doesn't run for the baseline tests.

@mauri870
mauri870 merged commit 5687235 into mauri870:master Nov 3, 2026
1 of 2 checks passed
mauri870 added a commit that referenced this pull request Nov 3, 2026
The only arm64 coverage in CI was tsvc-test-qemu-arm64, which runs
TestGolden in ./tsvc. The testdata scripts never ran on arm64, so
abs_sqrt.txt, activation_temp.txt and invariant_call.txt compared
arm64 output against an amd64 recording, and nothing caught it until
the suite was run on an M4 (fixed in #8).

This change adds test-qemu-arm64, which runs go test ./... for
GOARCH=arm64 under qemu-aarch64-static, the same way the tsvc target
does. It is make test without -race, which needs cgo. Unlike TestGolden,
the scripts and tsvc's TestCoverage run the arm64 binaries they build,
so the target also needs an aarch64 binfmt handler; on Ubuntu,
installing qemu-user-static registers one. The target is added to ci
and to the workflow, after qemu is installed.
mauri870 added a commit that referenced this pull request Nov 3, 2026
`flag_diff.txt` fails on macOS. The `-d` headers carry `diff`'s
timestamp, and BSD diff prints it differently from GNU diff (no
fractional seconds, no zone). It's the timestamp of a temp file anyway,
so it doesn't tell the reader anything.

This passes `-L path` for both sides (GNU, BSD and busybox diff all have
it), so the headers are just `--- path` / `+++ path` like `gofmt -d`,
and the filename replacement goes away. The four diff scripts now expect
the path alone.

It's one of three small fixes to get the suite passing on macOS, along
with #8 and #9, which I needed while trying loopvec on
[goav1](https://github.com/thesyncim/goav1).

Co-authored-by: Mauri de Souza Meneguzzo <mauri870@gmail.com>
mauri870 added a commit that referenced this pull request Nov 3, 2026
…alar build (#17)

`activation_functions.txt` hashes float bits and compares both builds
with `testmain/output`, which was recorded on amd64. It passes on arm64
only because none of its loops creates a NaN: they just pass the input
NaN through. With an alpha of 0, `LeakyReLU` computes `0 * -Inf`. The
resulting NaN has the sign bit set on amd64 and clear on arm64, so the
script fails on arm64 against the recording. This change gives it #8's
treatment: the recording is compared only on amd64, and on every target
the simd build is compared with the scalar build of the same machine.

It also changes the three scripts from #8:

- They compared the simd build with the recording on amd64 as well. That
adds nothing: on amd64 the scalar build matches the recording and the
simd build matches the scalar build.
- That comparison came last, so it was the one `-update` recorded. A
simd build that differed from the scalar one would have been written
into the recording. Now only the scalar build is compared with the
recording, and that's what `-update` records.
- Two of their comments named the square root of a negative number,
though those scripts have no square root.

Tested locally:

- I made temporary copies of the old and new `activation_functions.txt`
with alpha set to 0, recorded the expected output on amd64, and ran both
on arm64 under qemu. The old script fails at `cmp stdout
testmain/output`, and the new one passes.
- The four scripts pass on amd64 and on arm64 under qemu, and `-update`
leaves them unchanged.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants