Fix SInt literals to reject too small of widths #4786
Merged
Conversation
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
seldridge
approved these changes
Mar 11, 2025
Comment on lines
+288
to
+300
| property("SInt literals with too small of a width should be rejected") { | ||
| // Sanity checks. | ||
| 0.S.getWidth should be(1) | ||
| 0.S(0.W).getWidth should be(0) | ||
| -1.S.getWidth should be(1) | ||
| 1.S.getWidth should be(2) | ||
| // The real check. | ||
| -2.S.getWidth should be(2) | ||
| an[IllegalArgumentException] shouldBe thrownBy(-2.S(1.W)) | ||
| 0xde.S.getWidth should be(9) | ||
| an[IllegalArgumentException] shouldBe thrownBy(0xde.S(8.W)) | ||
| an[IllegalArgumentException] shouldBe thrownBy(0xde.S(4.W)) | ||
| } |
Member
There was a problem hiding this comment.
These tests look right! I haven't thought through the other ramifications of this change, other than that the existing tests in the repo all pass.
Contributor
Author
There was a problem hiding this comment.
Yeah I'm confident it's correct. Note that even before this change 0xde.S.getWidth == 9, it's just that we were accepting 1-bit less than the correct answer if the user specified it which would then coincidentally do the right thing in most circumstances due to the FIRRTL we emitted actually having the correct width semantics. Thus things would work as long as you didn't introspect on the width and do things with it.
Co-authored-by: Schuyler Eldridge <[email protected]>
chiselbot
pushed a commit
that referenced
this pull request
Mar 12, 2025
Co-authored-by: Schuyler Eldridge <[email protected]> (cherry picked from commit db93161) # Conflicts: # src/test/scala/chiselTests/SIntOps.scala
14 tasks
Contributor
✅ Backports have been created
|
Contributor
|
Awesome, thanks for the super-fast fix @jackkoenig! |
tymcauley
added a commit
to tymcauley/fixedpoint
that referenced
this pull request
Mar 12, 2025
An 8-bit signed integer with a binary point at 2 effectively has a 6-bit signed number for the value to the left of the decimal point. That means it can represent values in the range [-2^5, 2^5-1], or [-32, 31]. After chipsalliance/chisel#4786 was merged, the `55` and `56` literals are now correctly flagged as being out-of-range for this type. I've subtracted 32 from these out-of-range values (changing the MSB from 1 to 0), and the tests now pass.
tymcauley
added a commit
to tymcauley/fixedpoint
that referenced
this pull request
Mar 13, 2025
An 8-bit signed integer with a binary point at 2 effectively has a 6-bit signed number for the value to the left of the decimal point. That means it can represent values in the range [-2^5, 2^5-1], or [-32, 31]. After chipsalliance/chisel#4786 was merged, the `55` and `56` literals are now correctly flagged as being out-of-range for this type. I've subtracted 32 from these out-of-range values (changing the MSB from 1 to 0), and the tests now pass.
tymcauley
added a commit
to tymcauley/fixedpoint
that referenced
this pull request
Mar 24, 2025
An 8-bit signed integer with a binary point at 2 effectively has a 6-bit signed number for the value to the left of the decimal point. That means it can represent values in the range [-2^5, 2^5-1], or [-32, 31]. After chipsalliance/chisel#4786 was merged, the `55` and `56` literals are now correctly flagged as being out-of-range for this type. I've subtracted 32 from these out-of-range values (changing the MSB from 1 to 0), and the tests now pass.
tymcauley
added a commit
to tymcauley/fixedpoint
that referenced
this pull request
Mar 24, 2025
An 8-bit signed integer with a binary point at 2 effectively has a 6-bit signed number for the value to the left of the decimal point. That means it can represent values in the range [-2^5, 2^5-1], or [-32, 31]. After chipsalliance/chisel#4786 was merged, the `55` and `56` literals are now correctly flagged as being out-of-range for this type. I've subtracted 32 from these out-of-range values (changing the MSB from 1 to 0), and the tests now pass.
tymcauley
added a commit
to tymcauley/fixedpoint
that referenced
this pull request
Apr 2, 2025
An 8-bit signed integer with a binary point at 2 effectively has a 6-bit signed number for the value to the left of the decimal point. That means it can represent values in the range [-2^5, 2^5-1], or [-32, 31]. After chipsalliance/chisel#4786 was merged, the `55` and `56` literals are now correctly flagged as being out-of-range for this type. I've subtracted 32 from these out-of-range values (changing the MSB from 1 to 0), and the tests now pass.
tymcauley
added a commit
to tymcauley/fixedpoint
that referenced
this pull request
Apr 2, 2025
An 8-bit signed integer with a binary point at 2 effectively has a 6-bit signed number for the value to the left of the decimal point. That means it can represent values in the range [-2^5, 2^5-1], or [-32, 31]. After chipsalliance/chisel#4786 was merged, the `55` and `56` literals are now correctly flagged as being out-of-range for this type. I've subtracted 32 from these out-of-range values (changing the MSB from 1 to 0), and the tests now pass.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Found by @tymcauley ucb-bar/fixedpoint#11 (comment)
This bug was introduced 2 years ago when we added support for zero-width literals: #2932
The problem is that
BigInt.bitlengthexcludes the sign bit, so we need to add 1 to it for SInts (which is what we originally did), BUT we need special case support for zero-width SInts (only when specified).Contributor Checklist
docs/src?Type of Improvement
Desired Merge Strategy
Release Notes
For users attempting to reinterpret raw 2s complement values as SInts, use
.U.asSInt.Reviewer Checklist (only modified by reviewer)
3.6.x,5.x, or6.xdepending on impact, API modification or big change:7.0)?Enable auto-merge (squash)and clean up the commit message.Create a merge commit.