Hosted xtensa diverges from the x86-64 oracle on 21 of 142 cross programs

PREMISE CORRECTED, slug kept (frankA, 2026-08-31). Neither number in that heading survives measurement: the denominator is not 142 and never was, and the divergence count is 5, of which 2 are defects in this sweep rather than in the compiler. Read the 2026-08-31 section at the bottom, not this table — the table below is the 2026-08-30 state and is kept as history.

The first differential sweep xtensa has ever had. Of the 142 sources test-riscv32 uses, 55 match the x86-64 oracle exactly (now wired as make test-xtensa), 66 fail to compile for xtensa at all, and 21 compile, run, and produce the wrong answer. This ticket is the 21.

Sweep conditions: --target=xtensa --platform=posix --xtensa-soft-mulhigh, Call0, qemu-xtensa 10.2.1, compiler at e866cc16d4fe. Both flags are load-bearing: without --platform=posix syscalls lower to PAL_ERR_UNSUPPORTED, and without --xtensa-soft-mulhigh any numeric output SIGILLs.

e866cc16d4fe is NOT a commit (frankC, 2026-08-31): git cat-file -t calls it not a valid object name, and it is not an ancestor of origin/master. It is a binary sha256 prefix — the same twelve-hex shape a build line prints — which is the hazard CLAUDE.md's The name is not the thing names explicitly. So this sweep cannot be located in the tree by anyone, and a row cannot be re-checked against the state that produced it. Print the binary sha AND the commit, labelled, or the sweep is unrepeatable.

CORRECTION (frankC, 2026-08-31, within the hour of writing it). The paragraph above originally closed by reporting that pinned — "2026-08-29, older than this sweep" — already passed this program on xtensa, and offered that as an unexplained residual that nobody owned. It was wrong, and wrong in the way this very section is about. pinned is not from 2026-08-29 and is not older than the sweep: it is v398, 992065f21f33, written 2026-08-30 20:07, and a5f5bd42f (06:02 the same day) is an ancestor of its pin commit 4c4a5c125. The pinned compiler passes because it contains the fix. There is no residual: the row was recorded correctly and was then fixed, exactly as frankA and frank-coordinator said.

The mechanism is the one CLAUDE.md already names and I walked into anyway: pinned is a 13-byte symlink, so ls -l prints the SYMLINK's date (Aug 29 21:19), not the binary's. I read that as the binary's age and built a residual on it. ls -lL or sha256sum answers correctly and costs nothing — and the sha is the better answer, because it maps to a chore(stable): pin vNNN commit carrying the real date. A control is only a control once you know what it is a control FOR: I ran pinned twice, on two targets, as a deliberate check, and both runs were sound measurements of a binary I had misdated by a day.

Unchanged by this: e866cc16d4fe is still not a commit. If anything the correction argues the point harder — it was cheap only because a5f5bd42f is locatable.

The 21

Note (frankA, 2026-08-30): the test_cross_managed_aggregate_locals row originally held this program's raw output bytes, pasted literally. Four of them (\xac \xc6 \xcc \xbc) are not valid UTF-8, which made every progress.py run — board-md and check alike — die with a UnicodeDecodeError for all agents, since those tools read the whole ticket tree. The bytes are evidence, so none were dropped: each is now a backslash escape (\xNN, \t for the tabs), byte-for-byte identical to what was captured. Two agents hit this and repaired it independently within the same hour, which is itself the argument for the note: the failure surfaces far from its cause — every ticket tool dies, naming a byte offset in a file the agent running them never touched. Escape binary program output before pasting it into a ticket.

(First line of output only; several diverge further down.)

Three clusters, and the first one is a known signature

1. A heap handle leaking where an integer belongs. test_cross_var_string_param prints varlen=545267744 against the oracle's varlen=5 — and 545267744 is the same shape of value that ansistring = returned before [[bug-a-xtensa-has-no-ordered-string-compare-and-sorts-by-heap-handle]]: a live heap address rendered as a number. Length() of a var string parameter is handing back the handle instead of the length. Start here — it is the cluster with a known cause nearby, and firstchar being garbage in the same run says the parameter's indirection is what is wrong, not Length itself.

2. Bus errors and segfaults, all involving aggregates or floats: test_cross_aggregate_stackargs, test_cross_float, test_cross_float_return, test_single_in_aggregate, and test_cross_multidim3d (which prints its first line correctly, then segfaults on a 3-D array parameter). A crash is the cheap case and these have locations; take them before the quiet ones.

These are NOT Track F. They are crashes and wrong control flow that happen to live in float code — rank the mechanism, never the datatype. Float accuracy would be F; a bus error is an ordinary bug.

3. Quiet wrong values: test_cross_syscall answers 0 where the oracle says 1, test_cross_stack_params loses arguments past the register set, test_shortstring_trunc, test_u64_to_double, the two interface tests. These are the expensive class — no crash, a plausible number, far from the cause.

Deliberately not skipped

The 21 are excluded from make test-xtensa by NAME, not by a silent filter, and this ticket is cited in that target's header. A differential that quietly drops its own failures is precisely how xtensa reached 2026 with a backend nobody had ever executed.

Bound

Object-level plus observable output, hosted profile, Call0 only, at e866cc16d4fe. Windowed is a separate and worse story — [[bug-a-xtensa-windowed-abi-faults-on-frozen-strings-copy-and-dynarray-setlength]]. The 66 compile failures are not covered here; they are missing features rather than wrong answers, and want their own scoping pass.

UPDATE — 19 of 142, and the handle-leak cluster is closed. frankS, 2026-08-30

Housekeeping first: the table above was generated by pasting each program's raw first line into Markdown, and two of those lines contained non-UTF-8 bytes — unsurprising for programs that emit garbage, but it made the file undecodable. Someone else fixed it concurrently with \xNN escapes while I was replacing the bytes with ?; theirs is kept, because an escape preserves the evidence and a ? destroys it. Worth stating for the next person generating a table from raw output: escape, do not substitute.

test_cross_var_string_param's varlen=545267744 was the shared ABI predicate ABIParamSlotHoldsValueAddr (abi.inc) being used by x86-64, i386, aarch64, arm32 and riscv32 — five of six backends — while xtensa open-coded only its by-value-Variant row. Fixed by adopting the predicate; same shape as [[bug-a-xtensa-has-no-ordered-string-compare-and-sorts-by-heap-handle]] one file over, and as PXXStrCmp3's "four cross backends" and HeapMmap's seven arms.

Re-swept, same 142 sources: 55 -> 57 matching, 21 -> 19 diverging, zero regressions. Newly green: test_cross_multidim3d and test_cross_param_2darray — both by-ref ARRAY params, which the predicate also covers and which nothing in this ticket had connected to the string case. That is the argument for adopting a shared predicate rather than adding the one row that was failing.

Two of the 19 now have their own ticket, because they share a crisp repro this ticket's framing hid: [[bug-a-xtensa-cannot-read-a-managed-string-out-of-a-record-field-or-array-element]]. WriteLn(r.f) prints nothing and Length(r.f) prints 1936482630 — but so does x := r.f; Length(x), so the value is wrong before any consumer touches it. Also a candidate cause for the two interface tests here.

test_cross_var_string_param still diverges, on firstchar alone: indexing a managed string through a by-ref parameter (d[1]) is still one deref short, while Length(d), the tail loop and taillen are now correct.

WHY XTENSA WAS THE HOLDOUT — and it was not forgetfulness. frankS, 2026-08-30

The coordinator asked for the line that stops a sixth instance, so: traced, not guessed.

ABIParamSlotHoldsValueAddr was created on 2026-08-09 in d68ff8d16 ("the ABI oracle, slice 1 — the parameter-slot rules"), which converted five backends to it in a single commit: ir_codegen.inc, ir_codegen386.inc, ir_codegen_aarch64.inc, ir_codegen_arm32.inc, ir_codegen_riscv32.inc. ir_codegen_xtensa.inc is not in that commit's file list at all — and it was not too new to be: xtensa codegen has existed since bd49a5953, 2026-06-12, two months earlier.

The sweep's own safety check is what hid it

From d68ff8d16's message:

The enforceable invariant is greppable: an IsRef or chain inside ir_codegen*.inc now means someone grew a ninth copy. grep finds none.

That check is sound and it was honestly run. Measured against the parent commit:

Xtensa had zero not because it was correct, but because it had never implemented the rule at all. It open-coded a single row — the by-value Variant case — spelled (Syms[si].Kind = skParam) and (Syms[si].TypeKind = tyVariant), which contains no IsRef and no or chain. So the search found every backend holding a wrong duplicate and could not see the one backend holding no copy, and the file that most needed converting is precisely the one that satisfied the invariant.

A search for duplicated logic cannot find the place where the logic is missing. That is the exact inverse of this repo's "if you fix a bug on one arm of a double case, grep for the sibling" rule ([[devdocs/dev/normalise-dont-special-case]]) — grep-for-the-sibling finds divergent copies, and is blind to absent ones. The generalisation for a sweep that converts N call sites onto a shared helper: enumerate the backends that should call the helper and check each one calls it, rather than searching for the pattern being replaced. The first list is closed and countable; the second is defined by what already exists.

The second half: the verification list had the same hole

The same commit records: "verified against FPC on x86-64, aarch64 and arm32 (qemu) plus riscv32." Four targets, xtensa absent — because xtensa could not be executed, and would not be until the hosted profile landed 2026-08-29/30.

So both of the sweep's safety nets — the static grep and the differential — excluded xtensa for two unrelated reasons that happened to point the same way. This is the same sentence as PXXStrCmp3's "four cross backends" and HeapMmap's seven arms, arriving from a third direction: the target with no working oracle is the target that keeps the bug, and it also keeps the bug that a conscientious sweep was specifically designed not to leave behind.

Xtensa now runs, and the differential ([[bug-a-hosted-xtensa-diverges-from-the-oracle-on-21-cross-programs]]) is what found this one.

HANDBACK — the state of hosted xtensa, 2026-08-30 (frankS)

Measured at HEAD fa01f7111, compiler a6b4e6e1816c (a verified self-host fixedpoint, sha confirmed different from pinned). 129 sources — the union of what test-riscv32 and test-xtensa compile. The 142 in this ticket's title is wrong and cannot be reproduced from the Makefile at any target combination; treat the partition as N/matching, never as a fixed denominator.

Call0      MATCH 100   DIFF  7   CFAIL 21   (oracle can't build 1)
windowed   MATCH  50   DIFF 55   CFAIL 23

(Updated after the handback: test_shortstring_trunc is fixed, and the reason it was in the DIFF column was not the reason this table originally gave.)

Call0 over the night: 69 → 99 matching, 21 → 8 diverging, across nine changes, no sweep regressed a program. Windowed is a different target in practice and is NOT the subject of any of this — see the windowed ticket.

The 8 that still diverge, each with an owner

Three of those eight had no ticket and two were wrong-VALUE bugs. I named them here rather than filing them, because a ticket I do not work is worth less than a row someone reads. One is now fixed — and the label I put on it was wrong: shortstring_trunc's b-CLOBBERED was not a clobber at all. I took the test's own failure message as a diagnosis and repeated it in three places before anyone had looked at the mechanism. A guard row that names a cause it does not verify propagates that cause into every summary that quotes it. The remaining untriaged one is record_byval_wide's address-as-number. That is no longer true — it was triaged and fixed the same day as [[bug-a-a-by-value-wide-record-on-xtensa-renders-a-live-address]] (a5f5bd42f), and both of this program's rows above are struck through. The sentence outlived its fix by a day and sent frankC to measure arm32, because the program's NAME says arm32 and the failing column was xtensa (caught by frank-coordinator). Nothing else in the 21 was re-measured — treat every other row as of the original sweep, not of today.

The 21 that do not compile — seven categories, all named

Nothing in the tail is unclassified. That was the point of partitioning it rather than sampling it: a bucket you have counted is a bucket whose members you have looked at, and it is what turned "23 assorted failures" into five distinct filed defects nobody could have named that morning.

What a green here does and does not mean

Unchanged and still load-bearing: --xtensa-soft-mulhigh labels the multiply divergence rather than removing it (no qemu-xtensa core implements MUL32HIGH), so any arithmetic verdict from this target must name the flag. This is Call0 only. And one row — test_signal_default_revert_b336 — sits in the signal family but installs no handler: it raises SIGTERM with the default disposition and dies 143, which needs kill, not the signal runtime. It is coverage-shaped and proves nothing about the family it sits in. I wired it, so I am flagging it.

The one methodological thing worth carrying forward

Every fix tonight was a missing row of a rule the other backends already carried — not a novel xtensa problem. ABIParamSlotHoldsValueAddr, IR_STORE_MEM's typed stores, IR_INDEX's managed-string bases, the dyn-array ops, the set family, SPECIAL_IN. The reason they survived is that a search for duplicated logic cannot find the place where the logic is missing: xtensa passed the "no IsRef or chain outside the helper" grep by having no copy at all. When a sweep converts N call sites onto a shared helper, enumerate the backends that should call it and check each one does — the first list is closed and countable, the second is defined by what already exists.

RE-MEASURED — 115/5/20 of 140, and only two of the five are compiler bugs. frankA, 2026-08-31

Compiler db19ff591808 (self-host fixedpoint, converged after 1 round(s), sha differs from pinned). Source list re-derived from the test-xtensa and test-riscv32 recipes at HEAD.

xtensa    MATCH 115   DIFF 5   CFAIL 20     of 140
riscv32   MATCH 127   DIFF 4   CFAIL  8     of 140   (same harness, for contrast)

State the denominator as derived, never as a constant. 140 is what the two recipes name today; it was 129 yesterday. The slug's 21 and the body's 142 are both stale, which is how three numbers in one ticket came to disagree.

RESOLVED — 117/3/20, zero unexplained compiler divergences

binary b91c0ceab90b, commit d702b0641, 140/140 rows, denominator asserted. Superseding the 116/4/20 below, which was one sweep earlier.

xtensa    MATCH 117   DIFF 3   CFAIL 20     of 140

The three: test_cross_float (Track F formatting, now filed), test_rtti and test_signal_altstack (both sweep artifacts, documented below — do not re-file). The 20 CFAIL are feature gaps, already partitioned into named tickets by the 2026-08-30 handback.

Fixed in this group: test_cross_trunc_round_saturate (9da47b2cc, which also fixed riscv32's Single arm — a defect with no ticket), test_cross_syscall (97e96fc1b, a missing test arm that exposed a live PalBackendMmapAnon bug), test_asm_ifdef_multiarch (d702b0641, a missing asm arm, now run under both ABIs). All three rows are wired into test-xtensa rather than excluded.

Two of the original "divergences" were never compiler bugs and two more were my own sweep — the reconciliation below is the durable part of this ticket, because a naive oracle comparison rediscovers those rows by construction.

Superseded: 116/4/20

binary f996aace9d75, commit 97e96fc1b — labelled, because the previous baseline e866cc16d4fe is a binary sha256 sitting in a slot the sentence reads as a commit, which is why no row of the original 21-row table can be re-checked by anyone. Both ids here are verifiable: the commit is an ancestor of origin/master, the binary is a self-host fixedpoint whose sha differs from pinned.

xtensa    MATCH 116   DIFF 4   CFAIL 20     of 140

Fixed this session: test_cross_trunc_round_saturate (and riscv32's Single arm with it) and test_cross_syscall — the latter was filed here as a divergence, was really a missing test arm, and adding that arm exposed a genuine PalBackendMmapAnon bug (xtensa's MAP_ANONYMOUS is $800, not $20; every anonymous mapping through the POSIX PAL returned EBADF). Both rows are now wired into test-xtensa. 97e96fc1b, 9da47b2cc.

The frankC ABI flip (fc9c8ade2, eb22cc325) moved nothing — identical partitions measured before and after it, on xtensa and riscv32 both.

The five, reconciled against how the Makefile actually asserts each row

Two of them were my sweep, not the compiler. A source path is not a test row: the real row also carries flags, an output filter and sometimes a fixed expected literal, and re-deriving a list from the recipes throws all of that away. The resulting figure is credible because most rows have no special handling — which is exactly why it needs reconciling rather than reporting.

Do not re-file the last two. Any sweep that compares them naively to the x86-64 oracle will rediscover them; that is a property of the comparison, not of xtensa.

A trap this ticket sets for its own readers: the filename names a target

Raised by the coordinator after it fired. test_arm32_record_byval_wide is a row in an xtensa vs x86-64 table — arm32 is only in the program's FILENAME. A peer disclaiming authorship of the fix measured it carefully on arm32, aarch64, riscv32 and x86-64, with a pinned-compiler control, all green, and concluded the row had never been red. None of those is the column the row is about, and their own output contains 1 7 8 2, which is the oracle value this ticket records.

It is fixed on the column it is about, and here is that measurement: --target=xtensa --platform=posix --xtensa-soft-mulhigh, run under qemu-xtensa, byte-identical to the x86-64 build; independently, its row in the xtensa-only sweep is MATCH. Nobody claimed it — something else in the ABI work of 2026-08-30 took it out.

So name the target in any row you add here, because every program in this table is named for something other than the target it is being run on.

Fixed: Trunc/Round to Int64 saturated at 2^31 — and it was two targets

xtensa's -203/-204 arm called the 32-bit __pxx_d2i/__pxx_s2i and sign-extended, so every Int64 result past 2^31 came back 2147483647. Trunc(1.0e15):

riscv32's Single arm is the half nobody had reported. Its double arm was already on the 64-bit kernel; the single arm beside it was not, and no ticket named it. Found by varying the operand width while reproducing the xtensa defect — the "grep for the sibling" rule paying out across targets rather than within one file.

There is no __pxx_s2i64, so the fix promotes to double and uses __pxx_d2i64/_rne for both widths — what arm32 already does, and why arm32 was the one correct target. Each backend's two float arms collapse into one.

One trap named at the site: EmitFloatUnaryCallXtensa's dstDouble argument means the result occupies the a2:a3 pair, not the result is a float. It is what moves a11 -> a3 under the windowed ABI, so False for a d2i64 would drop the Int64's high word — correct under Call0, wrong under windowed.

The signal cluster: the arms exist AND there is real work behind them

frankS verified the two "no arm" tickets are phantoms but could not say whether anything real sat behind them. Measured from the other side, there is:

• 3 x undefined variable (SYS_gettid) — a missing lib/rtl row, not a backend gap
• 1 x the __pxxSigPCPtr/__pxxSigSPPtr ucontext offsets — [[feature-a-xtensa-ucontext-pc-sp-offsets]], the live one
• test_signal_altstack passes its real assertion (above)

UContextPCOffset/UContextSPOffset in ir.inc claimed "xtensa never reaches here" and marked both fallthroughs unreachable. False: test_signal_pc_rewrite and test_signal_sp_rewrite reach them and stop at the -1 guard with the intended error. Corrected in the same session (comment-only, binary byte-identical). frankS's read that those comments are why the phantoms still scan as open looks right.

Harness note, so the next sweep does not repeat either mistake

1. Feed the source list on fd 3 and give every child </dev/null. Fed on stdin, the test programs inherit the fd and eat the list: my first run silently processed 74 of 140 and reported a clean partition, and the stdin-reading row "diverged" by printing my own source list back. Assert rows == wc -l < list; nothing else catches it, because the skipped rows produce no output.
2. Reconcile every non-matching row against its Makefile recipe before reporting it — flags, filters, expected literals. That is what turned 6 into 3, and it only happened because a peer disputed one row.

Log

• 2026-08-31 — resolved, commit 76dc6a4ad.