Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Conversation

@TaoBi22
Copy link
Contributor

@TaoBi22 TaoBi22 commented Jan 8, 2025

Fixes an issue where SMT bitvector widths being parsed as unsigned meant that e.g. !smt.bv<-1> would wrap around and be interpreted as a 18446744073709551615-wide bitvector. The downside of this fix is that the error messages for bitvectors that are too wide become a little less clear (see the updated test) - does this still look like an ok fix to you @maerhart? Let me know if I should also drop the code that's emitting that error in the RepeatOp verifier, don't think it can be triggered after this but I may have missed a case.

@TaoBi22 TaoBi22 added bug Something isn't working SMT labels Jan 8, 2025
@TaoBi22 TaoBi22 requested a review from maerhart as a code owner January 8, 2025 16:42
Copy link
Member

@maerhart maerhart left a comment

Choose a reason for hiding this comment

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

It might be cleaner to write a custom parser that avoids the implicit conversion (basically parsing an APInt and doing the necessary checks before converting it to uint64_t).
When creating this type in C++ you probably give it an unsigned int, so the implicit conversion to a signed int could be a bit annoying there (but also only in corner cases).
But this approach is also fine for me.

I assume something like #8062 can still happen after this change (just the bitwidth to trigger it would be smaller)?

@TaoBi22
Copy link
Contributor Author

TaoBi22 commented Jan 10, 2025

It might be cleaner to write a custom parser that avoids the implicit conversion (basically parsing an APInt and doing the necessary checks before converting it to uint64_t).

Agreed that would be nicer - I'll merge this for now (once CI has passed) so we have a fix in but I'll try and come back and fix it up properly at a later date. I'll make a tracking issue to remind me once this is merged (edit: #8064).

I assume something like #8062 can still happen after this change (just the bitwidth to trigger it would be smaller)?

Yes, after this fix circt-opt spits out:

hw.module @ImplicitOverflow() {
  %0 = smt.bv.constant #smt.bv<1> : !smt.bv<9223372036854775803>
}

as:

module {
  hw.module @ImplicitOverflow() {
    %c1_bv4294967291 = smt.bv.constant #smt.bv<1> : !smt.bv<4294967291>
    hw.output
  }
}

@TaoBi22 TaoBi22 merged commit 00b68e6 into llvm:main Jan 10, 2025
4 checks passed
TaoBi22 added a commit to TaoBi22/circt that referenced this pull request Jul 17, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working SMT

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants