fix(vector): batched Dot in the scalar VectorF32 fallback #2

Closed

jorijnvdgraaf wants to merge 1 commit from claude/scalar-fallback-dot into master

jorijnvdgraaf commented

2026-10-06 14:52:26 +00:00

Owner

MatrixRowMajor calls the batched VectorF32<Len, 1>::Dot(a0, b0, a1, b1, …). The x86, wasm and RISC-V backends define it; the scalar fallback did not, so Crafter.Math failed to compile on every target without an intrinsic backend:

Crafter.Math-MatrixRowMajor.cppm:81:53: error: no member named 'Dot' in 'Crafter::VectorF32<'\x04', '\x01'>'

Found cross-building Crafter.Graphics for aarch64-alpine-linux-musl. This adds the same Dot to the fallback, written like the RISC-V one (one lane per pair, only the first Len lanes of each input summed).

Verification

With this change Crafter.Graphics cross-builds for aarch64 musl and its UI runs on a Fairphone 6.
No test in this repository covers the scalar fallback (the suite builds the x86 and RISC-V tiers), so the new function is compiled and run only through that cross-build.

Note on overlap

There is uncommitted work on a NEON backend in a local checkout that touches the same file. This PR is only the 22-line fallback fix on top of master; it stays valid for targets that still have no intrinsic backend.

🤖 Generated with Claude Code

`MatrixRowMajor` calls the batched `VectorF32<Len, 1>::Dot(a0, b0, a1, b1, …)`. The x86, wasm and RISC-V backends define it; the scalar fallback did not, so Crafter.Math failed to compile on every target without an intrinsic backend: ``` Crafter.Math-MatrixRowMajor.cppm:81:53: error: no member named 'Dot' in 'Crafter::VectorF32<'\x04', '\x01'>' ``` Found cross-building Crafter.Graphics for `aarch64-alpine-linux-musl`. This adds the same `Dot` to the fallback, written like the RISC-V one (one lane per pair, only the first `Len` lanes of each input summed). ## Verification - With this change Crafter.Graphics cross-builds for aarch64 musl and its UI runs on a Fairphone 6. - No test in this repository covers the scalar fallback (the suite builds the x86 and RISC-V tiers), so the new function is compiled and run only through that cross-build. ## Note on overlap There is uncommitted work on a NEON backend in a local checkout that touches the same file. This PR is only the 22-line fallback fix on top of `master`; it stays valid for targets that still have no intrinsic backend. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

jorijnvdgraaf added 1 commit

2026-10-06 14:52:26 +00:00

fix(vector): batched Dot in the scalar VectorF32 fallback ed188f207b

MatrixRowMajor calls VectorF32<Len, 1>::Dot(a0, b0, a1, b1, ...) for
its matrix-vector products and for LookAt. The x86, wasm and RISC-V
backends each define it; the scalar fallback, which every other target
gets, did not. Anything that imports Crafter.Math on such a target
failed to compile with "no member named 'Dot' in VectorF32", aarch64
included: cross-building Crafter.Graphics for a phone stopped there.

The fallback gains the same batched Dot, written like the RISC-V one:
one lane per (a, b) pair, summing only the first Len lanes of each
input.

No test exercises it: the suite builds the x86 and RISC-V tiers only.
Checked by cross-building Crafter.Graphics for aarch64-alpine-linux-musl
and running its UI on the device.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

jorijnvdgraaf closed this pull request

2026-10-06 14:56:57 +00:00