Repository navigation
Conversation
The SMT2 back-end (smt2_convt::convert_expr) brings the shift distance of bvshl/bvlshr/bvashr to the width of the shifted operand, as required by SMT-LIB. When the distance was wider than the operand it truncated the distance with (_ extract (width_op0-1) 0). This is unsound: a distance with high bits set is >= the operand width and must shift the operand out entirely, but truncation drops exactly those bits (e.g. an 8-bit value shifted by a 16-bit distance of 256 was shifted by 0 instead of fully out). This disagreed with the boolbv (SAT) back-end. Instead, perform the shift at the wider distance width -- zero-extending the operand (sign-extending for arithmetic right shift) -- and extract the low width_op0 bits of the result. Adds unit tests pinning the generated SMT2 for equal-width, narrower, and wider shift distances.
kroening
requested review from
TGWDB,
martin-cs,
peterschrammel and
tautschnig
as code owners
October 7, 2026 15:25
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## develop #9178 +/- ##
========================================
Coverage 80.85% 80.86%
========================================
Files 1717 1717
Lines 190153 190193 +40
Branches 73 73
========================================
+ Hits 153754 153800 +46
+ Misses 36399 36393 -6 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
This branch has not been deployed
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
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.
The SMT2 back-end (
smt2_convt::convert_expr) brings the shift distance ofbvshl/bvlshr/bvashrto the width of the shifted operand, as required bySMT-LIB. When the distance was wider than the operand it truncated the
distance with
(_ extract (width_op0-1) 0).This is unsound: a distance with high bits set is
>=the operand width andmust shift the operand out entirely, but truncation drops exactly those bits.
For example, an 8-bit value shifted by a 16-bit distance of
256was shiftedby
0(since256 mod 256 == 0) instead of being fully shifted out. Thisdisagreed with the
boolbv(SAT) back-end, which computes the correct result.Fix
When the distance is wider than the operand, perform the shift at the wider
distance width — zero-extending the operand (sign-extending for an arithmetic
right shift) — and extract the low
width_op0bits of the result. Theequal-width and narrower-distance cases are unchanged.
Testing
Adds unit tests to
unit/solvers/smt2/smt2_conv.cpppinning the generatedSMT2 for equal-width, narrower, and wider shift distances (lshr/shl/ashr).
Found via EBMC (diffblue/hw-cbmc): a SystemVerilog compound assignment
a >>= bwithreg [7:0] a; reg [15:0] b = 256;was PROVED by the SAT backendbut REFUTED by z3/cvc5 because of this truncation.
Closes #9177