[shinaoka]

Closes #156.

Problem

In 0.26.0 the values-only SVD allocates on the heap, although the caller passes a MemStack sized by svd_scratch. 0.25.0 did not allocate. tlinalg's alloc_counts test fails on it, which blocks the tlinalg 0.8.0 release.

There are two sources, both in dqds::singular_values:

• Work arrays: the four arrays (the squared factors a, b and the ping-pong buffers a2, b2) were built with vec!. That is two allocations at 1 × 1 and four above.
• Sort: the final descending sort was the stable sort_by. Its merge buffer moves from the stack to the heap for large slices: one allocation for f64 and c64 at 700 × 700 (f32 and c32 still fit on the stack).

Fix

• dqds::singular_values_scratch::<T>(n) describes the four arrays, and singular_values takes them from the MemStack with make_with.
• The values-only bidiagonal scratch (bidiag_real_svd_scratch with no U and no V) includes it, through any_of with the fallback paths, since dqds runs first and a failed dqds then runs the rotation path. So svd_scratch and the complex route include it too.
• The sort is sort_unstable_by. All equal keys are equal values, so the result does not change.
• No arithmetic change.

Tests

• New faer/tests/svd_values_no_alloc.rs: its own test binary with a process-wide counting allocator.
  • It runs values-only svd on Par::Seq for f64/f32/c64/c32 at 1×1, 2×2, 17×17, 40×33, 33×40, 128×128, 300×60 (the QR route) and 700×700.
  • It warms up first, then counts allocations during the call.
  • Without the change it counts [2, 2, 2, 2] at 1 × 1 (the issue's numbers).
  • With the arrays fixed but the stable sort kept, it counts [1, 0, 1, 0] at 700 × 700.
  • With this change it counts zero everywhere.
• dqds unit tests: updated to pass a scratch buffer.
• cargo test -p t4a-faer --lib linalg::svd: 74 passed.
• The LAPACK SVD tests (linalg::svd::tests --include-ignored): 88/88 passed (131 s).
  • In the full run-lapack-validation.py run, every other family passed.
  • The svd family alone hit the runner's 120 s limit inside parallel_paths, while primerose's load average was 60. Run directly without that limit, it passes, as above.
• cargo check --no-default-features and --features std: no warning or error from this change.

Review

The independent post-review (gpt-6.1-sol) found no BLOCKER or IMPORTANT issues. It checked:

• the scratch composition on the real, complex, square, QR-reduced and wide routes, and below the recursion threshold;
• that any_of is right because dqds releases its arrays before the fallback runs;
• alignment, and dropping the arrays for non-Copy scalars;
• the other callers, which all request vectors.

Its one MINOR (a redundant f64 copy in the test) is applied. The test checks steady-state calls after a warm-up; Par::Team and cold calls are outside its scope.

Records

• PATCHSET row added (KEEP).
• No upstream report: the dqds route is this fork's own code (perf(svd): blocked bidiagonalisation, dqds shift, padded work copy, caller-held worker group; values-only SVD at or below the vendor #52), not upstream's.
• The 0.26.1 release is the maintainer's decision.

🤖 Generated with Claude Code