|
|
@@ -84,9 +84,19 @@ Implemented an open-addressing name index (`HashName`/`HashGetSym`/
|
|
|
|
|
|
Reverted to the green state (`a9a8ecd`). Suite 204/204.
|
|
|
|
|
|
-## Conclusion
|
|
|
-Three separate latent V3 bugs now block the whole-session re-emit:
|
|
|
-(a) the `ProcInfo` garbage-`np` loop (fixed), (b) a size/layout-sensitive
|
|
|
-miscompile at large tables, (c) a miscompile triggered by the hash code.
|
|
|
-Until (b)/(c) are isolated, the session re-emit is impractical, and the
|
|
|
-**grammar rewrite** remains the more predictable flip path.
|
|
|
+## Bisecting the hash miscompile
|
|
|
+Reproduced with a **proc-only** hash (`HashName`/`ProcEq`/`HashPutProc`/
|
|
|
+`HashGetProc`; `FindSym` left linear): the fixpoint still fails at stage 3.
|
|
|
+
|
|
|
+- `m2s2` (V3-built) **works on small programs** (`t_exit`, `t_arith`,
|
|
|
+ `t_lower5set`, `t_classmethod`) but **aborts (SIGABRT)** on
|
|
|
+ `Lower.def + Lower.mod`.
|
|
|
+- Backtrace: `HashPutProc` ← `NoteProc` ← `ProcHeading` ← `DefUnit` —
|
|
|
+ i.e. m2s2 crashes while parsing the definition module's proc headings.
|
|
|
+- The obvious cause — `(hashProc[s2] = 0) OR ProcEq(VAL(CARDINAL,
|
|
|
+ hashProc[s2]-1), name)` evaluating the RHS (so `0-1` → huge index) —
|
|
|
+ was restructured away, and a `ProcEq` bounds guard added; **neither
|
|
|
+ fixed it**. So it is a deeper V3 miscompile of `HashPutProc`.
|
|
|
+
|
|
|
+Narrowing further needs many ~10-minute fixpoint cycles; reverted to
|
|
|
+green (`a9a8ecd`). Suite 204/204.
|
