atomics A.0c: harden guards (scalar-kind, ordering validity, align bail)

Adversarial review of A.0 found two silent-wrong defects reachable via the public
atomic_load/atomic_store intrinsics (raw LLVM verifier errors, not clean sx
diagnostics) + a latent alignment fallback. All fixed:

- scalar-kind allowlist (call.zig): the size-only T guard admitted same-sized
  aggregates ([8]u8, 8-byte structs) -> invalid 'load atomic [8 x i8]'. Now an
  allowlist switch (integer/float/bool/pointer/enum/vector) rejects loudly.
- per-op ordering validity (call.zig): load cannot release/acq_rel, store cannot
  acquire/acq_rel -> loud diagnostic instead of invalid LLVM.
- val_ty align fallback (ops.zig): the 'else .i64' (align 8) default would
  over-align a sub-8 store -> now bails loudly on a missing val_ty.

Locked by examples 1130 (non-scalar) + 1131 (bad ordering). Suite green (713/0).
This commit is contained in:
agra
2026-06-20 09:26:53 +03:00
parent 3c4305f78f
commit 8144a88a21
11 changed files with 88 additions and 5 deletions

View File

@@ -4,7 +4,27 @@ Companion to [PLAN-ATOMICS.md](PLAN-ATOMICS.md). Update after every step (one st
time, per the cadence rule). New corpus category: `17xx`.
## Last completed step
**A.0b (green) — DONE.** Real atomic load/store emission: `LLVMBuildLoad2`/`LLVMBuildStore`
**A.0c (guard hardening) — DONE.** Adversarial review of A.0 found two CRITICAL silent-wrong
defects (raw LLVM verifier errors leaking via the public intrinsics) + a latent align
fallback; all fixed:
- **Scalar-kind guard** (call.zig): the size-only check admitted same-sized aggregates
(`[8]u8`, 8-byte struct) → invalid `load atomic [8 x i8]`. Now an allowlist switch
(integer/float/bool/pointer/enum/vector) rejects non-scalars loudly.
- **Per-op ordering validity** (call.zig): a load can't `release`/`acq_rel`, a store can't
`acquire`/`acq_rel` (LLVM rejects). Now a loud diagnostic, not invalid IR.
- **`val_ty` align fallback** (ops.zig): the `else .i64` (align-8) default would over-align a
sub-8 store → now bails loudly if `val_ty` is missing (a compiler bug, not a guess).
- Locked by `examples/1130-diagnostics-atomic-nonscalar.sx` +
`1131-diagnostics-atomic-bad-ordering.sx`. Suite green (713, 0 failed).
**Capability landed (worker, commit 3c4305f):** comptime enum value params — `$o: Ordering`
now binds the variant tag and resolves in the body; during LOWERING the tag is readable via
`self.comptimeIntNamed("<param>")``?i64`. This unblocks A.0.5 (full ordering surface).
Worker limitation: `.tagged_union` constraints were skipped — user wants this lifted (any
value should be comptime-able); separate generalization worker spawned.
### Earlier — A.0b (green)
Real atomic load/store emission: `LLVMBuildLoad2`/`LLVMBuildStore`
+ `LLVMSetOrdering` + mandatory `LLVMSetAlignment`, ordering via an explicit
sx-tag→`LLVMAtomicOrdering` switch (`llvmOrdering`). `examples/1700` green (7/42/43); IR
shows `load atomic i64, ptr … seq_cst, align 8` + `store atomic …`. Added unit test
@@ -75,3 +95,6 @@ Full atomic load/store plumbing with LLVM emission deliberately bailing loudly;
- **A.0b** — real atomic load/store emission (LLVMBuildLoad2/Store + SetOrdering +
SetAlignment; explicit sx→LLVM ordering switch). 1700 green (7/42/43, `load atomic …
seq_cst, align 8`). Unit test added. Suite green (710 + units).
- **A.0c** — guard hardening from the adversarial review: scalar-kind allowlist + per-op
ordering validity (call.zig), val_ty align bail (ops.zig), + diagnostic examples
1130/1131. Suite green (713/0). (comptime enum value params landed via worker 3c4305f.)