Skip to content

Additional forward propagation to aid code contracts #7737

New issue

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

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

Already on GitHub? # 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 <delmasrd@amazon.com>
Needs some heuristics to constrain `record_may_leak`, which can produce
deeply nested expressions.

Co-authored-by: Remi Delmas <delmasrd@amazon.com>
# for free to join this conversation on GitHub. Already have an account? # to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant