Conversation
`>>` was mapped to Verilog's `>>` unconditionally. Verilog's `>>` is a
LOGICAL shift -- it fills with zeros however the operand is declared --
and the arithmetic shift is `>>>`. The signedness repair this backend
already has (W565) fires only on ordered relations, so no shift was ever
fixed up.
`specs/igla/race/cordic_fixed.t27:42`
return x - (y >> shift);
emits, with `input signed [15:0] y;` two lines above,
cordic_x_next = (x - (y >> shift));
Simulated on the actual generated module with iverilog:
before x_next(100, -64, shift=2) = -16268
after x_next(100, -64, shift=2) = 116
The spec, the C backend and the Zig backend all say 116. y = -64 is
16'hFFC0 = 65472; 65472 >> 2 = 16368; 100 - 16368 = -16268. An
eight-iteration CORDIC whose rotations fill with zeros does not converge
at all: this is a wrong gate, not a wrong number.
This project's own hand-written golden CORDIC RTL writes `y0 >>> 1` for
the identical rotation. The right operator was known; the expression path
emitted it zero times across 559 generated modules.
`>>>` in generated Verilog 2 -> 369, across 48 specs
iverilog accepts 373 / 559 -> 373 / 559
suite 2455 / 0 -> 2455 / 0
Both of the old two were inside string literals. Acceptance is unchanged
because the wrong shift was always legal Verilog -- no gate could have
caught this, and none did.
Tempered, and the audit that found it said so first: 42 of the 45
affected specs shift values that happen to be non-negative today, so
they are latent rather than currently wrong. The three igla/race CORDIC
specs are value-corrupting now.
FROZEN_HASH resealed.
Refs #2860
Contributor
|
📓 NotebookLM Notebook linked to this PR
This notebook contains session context, decisions, and artifacts for this work. |
Contributor
gHashTag
enabled auto-merge (squash)
August 29, 2026 19:02
gHashTag
added a commit
that referenced
this pull request
Aug 29, 2026
…ot see it (#2870) 310: `gen-verilog` mapped `>>` to Verilog's logical `>>` on signed operands, and the decisive evidence was not in the compiler. All 559 generated modules held two `>>>`, both inside string literals -- and those literals are this project's own hand-written golden CORDIC RTL, which writes `y0 >>> 1` for the identical rotation. The project knew the right operator and the backend emitted it zero times. A hand-written reference in the repository is an oracle the generator can be measured against, and it costs one grep. 311: four defects fixed this pass and not one moved an acceptance number -- the step becoming the loop body, the dropped width suffix, the logical shift, the truncated test that reported OK. Every one produced output the target compiler was happy with, so a gate asking "does it compile" cannot see the whole interesting class. What saw them: a second backend to disagree with, a hand-written artefact to compare against, and simulating the emitted module instead of reading it. Refs #2868
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.
>>was mapped to Verilog's>>unconditionally. Verilog's>>is a logical shift — it fills with zeros however the operand is declared — and the arithmetic shift is>>>. The signedness repair this backend already has (W565) fires only on ordered relations< <= > >=, so no shift was ever fixed up.Simulated on the actual generated module
Not a reduced example —
t27c gen-verilogoutput with a$displayblock appended, compiled withiverilog -g2012:x_next(100, −64, shift=2)y = −64is16'hFFC0= 65472;65472 >> 2= 16368;100 − 16368= −16268.An eight-iteration CORDIC whose rotations fill with zeros does not converge at all. This is a wrong gate, not a wrong number — Verilog is the backend that reaches silicon.
The project already knew the right operator
Its own hand-written golden CORDIC RTL writes
y0 >>> 1for the identical rotation. The expression path emitted>>>zero times across 559 generated modules; the only two occurrences in the whole corpus were inside string literals.>>>in generated VerilogiverilogacceptsAcceptance is unchanged because the wrong shift was always legal Verilog. No gate could have caught this, and none did.
Tempered
The audit that found this said so first, and it holds: 42 of the 45 affected specs shift values that happen to be non-negative today, so they are latent rather than currently wrong. The three
igla/raceCORDIC specs are value-corrupting now.bootstrap/stage0/FROZEN_HASHresealed.Refs #2860