Do not simplify (T)bv-typed when T has smaller bit width

[tautschnig]

We must not modify the bit width of bv (and not signed/unsigned bv) typed expressions via type casts. Make sure simplification doesn't given rise to such expressions.

Fixes: #7426

• 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.

[kroening]

BTW, why is the simplification wrong?

[tautschnig]

BTW, why is the simplification wrong?

https://github.com/diffblue/cbmc/blob/develop/src/solvers/flattening/boolbv_typecast.cpp#L429..L433 claims it is. But then maybe the typecast flattening code is wrong?

[codecov]

Codecov Report

Base: 78.49% // Head: 78.49% // Decreases project coverage by -0.01% ⚠️

Coverage data is based on head (b4def86) compared to base (d6c318e).
Patch coverage: 49.26% of modified lines in pull request are covered.

Additional details and impacted files

@@             Coverage Diff             @@
##           develop    #7428      +/-   ##
===========================================
- Coverage    78.49%   78.49%   -0.01%     
===========================================
  Files         1663     1663              
  Lines       191331   191330       -1     
===========================================
- Hits        150180   150176       -4     
- Misses       41151    41154       +3     

Impacted Files	Coverage Δ
src/solvers/flattening/boolbv_typecast.cpp	48.66% <49.26%> (-1.17%)	⬇️

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

[kroening]

I don't think that the invariant is claiming that the cast would necessarily be unsound.

A question is what semantics to give it. I'd say it's straight forward when casting to something smaller. You drop the extra bits.

There is certainly ambiguity when casting to something bigger, since it's not obvious whether to zero extend or sign extend.