SMT-LIB2: shifts with wider shift distances

[kroening]

This fixes the case of converting shifts where the shift distance is wider than the shift operand to SMT-LIB2.

SMT-LIB2 requires that the width of the shift operand and the shift distance is the same. To not lose leading bits of the shift distance, use the wider one of the two as the width of the shift, and truncate the result when needed.

• Each commit message has a non-empty body, explaining why the change was made.
• n/a Methods or procedures I have added are documented, following the guidelines provided in CODING_STANDARD.md.
• n/a The feature or user visible behaviour I have added or modified has been documented in the User Guide in doc/cprover-manual/
• Regression or unit tests are included, or existing tests cover the modified code (in this case I have detailed which ones those are in the commit message).
• n/a My commit message includes data points confirming performance improvements (if claimed).
• My PR is restricted to a single feature or bugfix.
• n/a White-space or formatting changes outside the feature-related changed lines are in commits of their own.

[codecov]

Codecov Report

❌ Patch coverage is 98.68421% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 80.01%. Comparing base (15eb10a) to head (a136328).

Files with missing lines	Patch %	Lines
src/solvers/smt2/smt2_conv.cpp	97.61%	1 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff            @@
##           develop    #8834   +/-   ##
========================================
  Coverage    80.00%   80.01%           
========================================
  Files         1700     1700           
  Lines       188252   188312   +60     
  Branches        73       73           
========================================
+ Hits        150613   150675   +62     
+ Misses       37639    37637    -2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[tautschnig]

I believe sign-extending the operand is incorrect for lshr (logical right shift). Sign extension should only be used for ashr. For lshr and shl, zero extension is always correct:

Suggested change

	out << ')'; // bv*sh
	}
	else // width_op0<width_op1
	else // width_op<width_distance -- distance is wider
	{
	out << "((_ extract " << width_op0-1 << " 0) ";
	// enlarge the shift to match the distance operand,
	// then extract again
	out << "((_ extract " << width_op - 1 << " 0) ";
	emit_operator(shift_expr);
	// use sign extension when needed
	if(shift_expr.op().type().id() == ID_signedbv)
	{
	out << "((_ sign_extend " << width_distance - width_op << ") ";
	convert_expr(shift_expr.op());
	// use sign extension for arithmetic right shift
	if(
	shift_expr.id() == ID_ashr &&
	shift_expr.op().type().id() == ID_signedbv)
	{
	out << "((_ sign_extend " << width_distance - width_op << ") ";
	convert_expr(shift_expr.op());
	out << ')'; // sign_extend
	}
	else
	{
	out << "((_ zero_extend " << width_distance - width_op << ") ";
	convert_expr(shift_expr.op());
	out << ')'; // zero_extend
	}

[tautschnig]

This test covers ashr with a signed operand and wider distance, which exercises the sign-extension path. Please also add a test for lshr with a signed operand and wider distance to catch the bug described in my other comment. Expected output should use zero_extend, not sign_extend:

  GIVEN("A logical right shift with a signed operand and wider distance")
  {
    auto op = symbol_exprt{"op", signedbv_typet{8}};
    auto distance = symbol_exprt{"dist", unsignedbv_typet{10}};
    auto shift = lshr_exprt{op, distance};
    REQUIRE(
      smt2(shift) == "((_ extract 7 0) (bvlshr ((_ zero_extend 2) op) dist))");
  }

[tautschnig]

Suggested change

	GIVEN("A shift expression with equal-with operands")
	GIVEN("A shift expression with equal-width operands")