Phase 1 / Forge / Cross-platform determinism of forge_3d

.github/workflows/nightly-fuzz.yml

@@ -4,8 +4,16 @@ name: Nightly IPC fuzz
 # promoted to nightly CI at M0.7 / E4. Runs on Linux + Windows and
 # archives the stdout digest as an artifact (G3 gate). Scheduled runs
 # only fire from the default branch (GitHub rule), so this activates once
-# the M0.7 branch is squash-merged to `main`; `workflow_dispatch` lets it
-# be triggered manually from the Actions tab in the meantime.
+# the M0.7 branch is squash-merged to `main`.
+#
+# M1.1.14 correction, MEASURED: the sentence that stood here — that
+# `workflow_dispatch` lets it be triggered manually from the Actions tab in the
+# meantime — is FALSE, and had been dormant since M0.7 because nobody tried it
+# from a branch. `gh workflow run <file> --ref <feature-branch>` returns
+# `HTTP 404: workflow not found on the default branch`: a `workflow_dispatch`
+# workflow must ALSO exist on the default branch before it can be dispatched at
+# all, whatever `--ref` says. Dispatch is available for this file today only
+# because it is already on `main`.
 on:
   schedule:
     # 04:00 UTC daily — off-peak for the shared runner pool.

bench/forge_3d_mesh.zig

@@ -185,7 +185,7 @@ pub fn main() !void {
                 rand.float(Real) * 2 - 1,
                 rand.float(Real) * 2 - 1,
             });
-            if (@reduce(.Max, @abs(raw.data)) == 0) continue;
+            if (raw.maxAbsComponent() == 0) continue;
             const unit = raw.scale(1 / raw.length());
             const q = query.RayQuery{
                 .origin = unit.scale(60),

briefs/artifacts/m1.1.14-zig-reduce-order-issue.md

@@ -0,0 +1,79 @@
+# Upstream issue draft — `stage2_x86_64` reorders a floating-point `@reduce`
+
+> **Status: NOT FILED.** Filing is an outward-facing act and belongs to the repository
+> owner. This file is the prepared text and its evidence; the reproducer it refers to
+> is `briefs/artifacts/m1.1.14-zig-reduce-order-repro.zig`, self-verified.
+
+## Title
+
+`stage2_x86_64` does not honour the specified order of a floating-point `@reduce`
+
+## Toolchain, exactly
+
+`zig version` reports **0.16.0**. That is **not a public upstream release**: `ziglang/zig`
+carries no `0.16.0` tag (the ref lookup 404s), its newest release is `0.15.1` and its
+newest tag `0.15.2`, over 24 tags. So this is reported **against master**, not against a
+release, and the compiler under test is whatever `0.16.0` build the distribution shipped
+(Homebrew `zig 0.16.0_1`, labelled `stable` on its side). Host `aarch64-macos`,
+cross-compiling; the defect is in the `x86_64` self-hosted backend, not in the host.
+
+## What the language specifies
+
+From the langref on **master** (verbatim, and identical at tag `0.15.2`):
+
+> Transforms a vector into a scalar value (of type E) by performing a **sequential
+> horizontal reduction** of its elements using the specified operator
+
+> Note that `.Add` and `.Mul` reductions on integral types are wrapping; when applied on
+> floating point types **the operation associativity is preserved**, unless the float mode
+> is set to `Optimized`.
+
+The sequential fold of a 3-lane vector `p` is therefore `(p₀ + p₁) + p₂`.
+
+## What the two backends emit
+
+Both built at `-target x86_64-linux-gnu -mcpu=baseline`, from the same source file, on a
+3-lane `f32` reduction:
+
+| backend | instruction sequence | fold |
+|---|---|---|
+| `stage2_llvm` (`-fllvm`) | `movaps` seeds `p₀`; `shufps $0x55` → `p₁`; `addss`; `unpckhpd`/`movhlps` → `p₂`; `addss` | `(p₀ + p₁) + p₂` ✅ |
+| `stage2_x86_64` (`-fno-llvm`) | `movhlps` → `p₂`; `addss p₀`; `shufps $0x1` → `p₁`; `addss` | `p₁ + (p₂ + p₀)` ❌ |
+
+`p₁ + (p₂ + p₀)` is neither sequential in lane order nor an associativity-preserving
+rendering of the sequential fold, so it contradicts both halves of the specified sentence.
+
+## It is not the float mode
+
+The sequence is **identical, instruction for instruction**, under the default float mode
+and under an explicit `@setFloatMode(.strict)`, at `-O Debug`, `-O ReleaseSafe` and
+`-O ReleaseFast` — six listings. That rules out a mis-propagated float mode as the cause,
+and it rules out the specification's own `Optimized` escape.
+
+The reproducer places `probe()` and `expected()` in **one object, compiled by one backend
+in one float mode**: `expected()` — which writes the fold in source — emits the plain
+sequential `addss` chain that `probe()` does not. So the backend is able to produce the
+specified order and does when the source states it.
+
+## Why it is observable
+
+Floating-point addition is not associative. The two orders disagree on **313 816 of
+1 000 000** random `f32` triples drawn uniformly from `[-50, 50]` — **31.4 %** — by one
+ULP. First witness `(-12.127813, 21.12078, -40.04462)`: `(p₀+p₁)+p₂` = `0xC1F869C9`,
+`p₁+(p₂+p₀)` = `0xC1F869C8`.
+
+In the reporting project — a physics engine whose exit criterion is bit-exact replay — this
+surfaced as the simulation state diverging between a Debug build and a ReleaseSafe build of
+the same commit on the same machine, at the first stepped frame, amplifying to 2.53e-3 m
+after 38 frames. At `f64` both backends produce `(p₀ + p₁) + p₂` (LLVM by
+`mulpd`/`unpckhpd`, the self-hosted backend by a sequential `addsd` loop over memory), which
+is why only the `f32` leg diverged.
+
+## Reproducing
+
+```
+zig build-obj repro.zig -target x86_64-linux-gnu -mcpu=baseline -O Debug -fllvm
+zig build-obj repro.zig -target x86_64-linux-gnu -mcpu=baseline -O Debug -fno-llvm
+```
+
+then disassemble `probe` in each object and compare against `expected` in the same object.

briefs/artifacts/m1.1.14-zig-reduce-order-repro.zig

@@ -0,0 +1,46 @@
+//! Minimal reproducer — `stage2_x86_64` does not honour the specified order of
+//! a floating-point `@reduce`. Prepared at M1.1.14, NOT yet filed upstream.
+//!
+//! The langref states that `@reduce` performs "a sequential horizontal reduction
+//! of its elements", and that on floating point types "the operation
+//! associativity is preserved, unless the float mode is set to `Optimized`".
+//! The sequential fold of a 3-lane vector is `(v₀ + v₁) + v₂`.
+//!
+//! Build both ways and disassemble `probe`:
+//!
+//!   zig build-obj repro.zig -target x86_64-linux-gnu -mcpu=baseline -O Debug -fllvm
+//!   zig build-obj repro.zig -target x86_64-linux-gnu -mcpu=baseline -O Debug -fno-llvm
+//!
+//! LLVM emits `(v₀ + v₁) + v₂`:
+//!   movaps seeds v₀ ; shufps $0x55 → v₁ ; addss ; unpckhpd → v₂ ; addss
+//!
+//! `stage2_x86_64` emits `v₁ + (v₂ + v₀)`:
+//!   movhlps → v₂ ; addss v₀ ; shufps $0x1 → v₁ ; addss
+//!
+//! That is a permutation AND a reassociation, so it contradicts both halves of
+//! the specified sentence. Identical output under the default float mode and
+//! under the explicit `@setFloatMode(.strict)` below, at `-O Debug`,
+//! `ReleaseSafe` and `ReleaseFast` — six listings, instruction for instruction.
+//!
+//! Observable consequence, since float addition is not associative: the two
+//! orders disagree on 313816 of 1000000 random f32 triples drawn uniformly from
+//! `[-50, 50]`, by one ULP. First witness `(-12.127813, 21.12078, -40.04462)`:
+//! `(v₀+v₁)+v₂` = `0xC1F869C9`, `v₁+(v₂+v₀)` = `0xC1F869C8`.
+//!
+//! Measured with Zig 0.16.0 on an `aarch64-macos` host, cross-compiling.
+
+/// The reduction under test. `@setFloatMode(.strict)` is explicit so the
+/// specified "unless Optimized" escape cannot account for the difference.
+export fn probe(a: *const [3]f32, b: *const [3]f32) f32 {
+    @setFloatMode(.strict);
+    const va: @Vector(3, f32) = a.*;
+    const vb: @Vector(3, f32) = b.*;
+    return @reduce(.Add, va * vb);
+}
+
+/// The sequential fold the language specifies, for comparison in the same object.
+export fn expected(a: *const [3]f32, b: *const [3]f32) f32 {
+    @setFloatMode(.strict);
+    const p: @Vector(3, f32) = @as(@Vector(3, f32), a.*) * @as(@Vector(3, f32), b.*);
+    return (p[0] + p[1]) + p[2];
+}