Conversation
const EXP_OFFSET: u32 = 1792...173 // 185 digits
Typecheck OK (0 errors, 0 warnings)
Rust emitted `pub const EXP_OFFSET: u32 = 1792...173;`, Verilog emitted
`localparam [31:0] OFFSET_MAX = 3584...346;`, C emitted the `#define`. Only cc
said anything -- "integer literal is too large to be represented in any integer
type" -- and it is the fourth backend, so three of four carried a ~590-bit value
in a 32-bit box without a word.
Ten constants across five specs, the whole `gft` ladder. The digit count roughly
doubles per rung, so they look computed; the file header says the quantity is
`E_t = round((N-1)/phi^2) = 391`.
Signed types hold one bit fewer, so `const X: i32 = 3000000000` is caught too --
the same defect at a size cc never complains about, because it fits uint64_t.
HOW THIS WAS FOUND, and the reading that was wrong first. The C backlog ranked by
FIRST error put the scaffold helpers on top: `default_input` 47, `valid_input`
27. Measured before building anything: of the 166 files carrying that error,
ZERO would compile if it were the only fix. Ranking by first error ranks by
position in the file, not by blocking power. Only 20 of 404 files are blocked by
exactly one family; the median carries four or five. This defect came from four
of those twenty.
TWO BRANCHES OF THE FIRST DRAFT WERE DEAD, each with a comment explaining why it
was necessary. A `len() > 20` guard "because parsing 185 digits into u128 would
overflow" -- `parse::<u128>` returns `Err`, and the `Err` arm already answers.
A filter stripping `_` "because separators are not digits" -- the lexer strips
them before the check sees the literal. Both mutations changed no test, so both
are gone and the comments now say what is actually load-bearing.
The five specs go in the expectations ledger rather than being edited: which
number is meant is a question about the GF-T ladder's definition, not about the
compiler. 150 -> 155 with the reason in the file. Nothing regressed -- this is
newly detected, not newly broken.
Closes #2925
This was referenced Aug 30, 2026
gHashTag
enabled auto-merge (squash)
August 30, 2026 00:24
This was referenced Aug 30, 2026
# Conflicts: # bootstrap/stage0/FROZEN_HASH # docs/reports/suite_expectations.json
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
Contributor
PR DashboardGenerated at: 2026-08-30 00:37:35 UTC
Summary
Seal Status
|
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
Contributor
PR DashboardGenerated at: 2026-08-30 00:38:36 UTC
Summary
Seal Status
|
This was referenced Aug 30, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
pub const EXP_OFFSET: u32 = 1792…173;localparam [31:0] OFFSET_MAX = 3584…346;#define EXP_OFFSET 1792…173error: integer literal is too large to be represented in any integer typeThree of four backends carried a ~590-bit value in a 32-bit box without a word.
The fourth is the only reason anyone noticed. Ten constants, five specs, the
whole
gftladder (#2925).Signed types hold one bit fewer, so
const X: i32 = 3000000000is caught too —the same defect at a size
ccnever complains about, because it fitsuint64_t.The reading that was wrong first
The C backlog is 404 specs that generate C
ccrefuses. Ranked by firsterror, the top family was the scaffold helpers:
default_input47,valid_input27. That looked like the lever.Measured before building anything:
Zero. Every one of the 166 has other independent errors. Ranking by first
error ranks by position in the file, not by blocking power.
This defect came from four of those twenty.
Two dead branches in my own first draft
Each had a comment explaining why it was necessary. Each mutation changed no
test, so both are gone:
if d.len() > 20 { return false }u128would overflowparse::<u128>returnsErr; theErrarm already answers.filter(|c| *c != '_')The comments now say what is load-bearing.
Err(_) => falseis the arm thatdoes the work, and flipping it to
truefailsa_literal_too_wide_for_u128_is_still_rejected.Mutation-checked
i32given 32 value bitsa_signed_type_holds_one_bit_fewerErr(_) => truea_literal_too_wide_for_u128_is_still_rejectedTests drive the shipped binary, not a library call — this crate has no lib
target, and a test that reimplemented the check would pass against a compiler
that never shipped it.
Ledger
The five specs are recorded, not edited: which number is meant is a question
about the GF-T ladder's definition (the header says
E_t = 391), not about thecompiler.
150 → 155, reason written into the file. Newly detected, not newlybroken.
Closes #2925