Skip to content

Additional forward propagation to aid code contracts #7737

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 4 commits into
base: develop
Choose a base branch
from

Conversation

tautschnig
Copy link
Collaborator

  • Each commit message has a non-empty body, explaining why the change was made.
  • Methods or procedures I have added are documented, following the guidelines provided in CODING_STANDARD.md.
  • 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).
  • My commit message includes data points confirming performance improvements (if claimed).
  • My PR is restricted to a single feature or bugfix.
  • White-space or formatting changes outside the feature-related changed lines are in commits of their own.

tautschnig and others added 4 commits May 25, 2023 15:28
Rather than adding more-and-more expressions to the enumeration just
call out those that are _not_ constant ((nondet) symbols and side-effect
expressions as well as any access that may be out of bounds).
We would only deem with_exprt constant when all their operands are
constant, which means that the array operand must be an array or
array_of expression, and both update indices as well as update values
must be constant. In most such cases the simplifier would rewrite the
with_exprt anyway. The exception to this is an index that cannot
immediately be evaluated to a numeric constant, as is the case with,
e.g., pointer_object expressions.

Fixes: diffblue#3095
We do not prescribe a fixed type for these expressions, so we can just
alter the type and have back-ends deal with producing a suitable value
of the new type.

Co-authored-by: Remi Delmas <[email protected]>
Needs some heuristics to constrain `record_may_leak`, which can produce
deeply nested expressions.

Co-authored-by: Remi Delmas <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant