Skip to content

Fix binary use of reduction NAND and NOR - #2590

Open
raspbeep wants to merge 2 commits into
chipsalliance:masterfrom
raspbeep:fix-2568-reduction-operators
Open

Fix binary use of reduction NAND and NOR#2590
raspbeep wants to merge 2 commits into
chipsalliance:masterfrom
raspbeep:fix-2568-reduction-operators

Conversation

@raspbeep

Copy link
Copy Markdown

Addresses #2568 by removing the binary operator grammar rules for ~& and ~|, which are valid only as unary reduction operators. Adds regression tests to verify that their invalid binary usage is rejected.

@linux-foundation-easycla

linux-foundation-easycla Bot commented Aug 31, 2026

Copy link
Copy Markdown

CLA Signed
The committers listed above are authorized under a signed CLA.

  • ✅ login: raspbeep / name: Pavel Kratochvil (58778b5)

@raspbeep
raspbeep force-pushed the fix-2568-reduction-operators branch from 58778b5 to b08e208 Compare September 1, 2026 07:34
@raspbeep

raspbeep commented Sep 1, 2026

Copy link
Copy Markdown
Author

Updated the ivtest smoke-test expectations to account for the 7 files that intentionally use Icarus Verilog’s non-standard binary ~& / ~| operators. These files were accepted before this fix and are now correctly rejected, so the parser-dependent failure counts increase by 7.

Comment thread .github/bin/smoke-test.sh
ExpectedFailCount[syntax:ivtest]=116
ExpectedFailCount[lint:ivtest]=116
ExpectedFailCount[project:ivtest]=145
ExpectedFailCount[syntax:ivtest]=123

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if the test that is now failing was using that as a negative example or if iverilog indeed supports this as binary operator, did you dig into the example ?

@hzeller

hzeller commented Sep 10, 2026

Copy link
Copy Markdown
Collaborator

I do like to support a super-set of Verilog if there is any verilog parser that supports this particular feature (but I don't remember what original was supporting it, maybe @fangism knows).

The problem with taking it out of the grammar is, that it then will be a hard failure and prevent the parser to recover after that. Ideally we would like to introduce some 'soft' failure where we parse this, but fail with an error but then continue parsing to find potentially other issues. I need to think about the details, so will leave this PR open for now while that is settled.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants