fix: Do not call [X.make] on non-subterms for bv2nat #954
Conversation
This file contains 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
It turns out that OCamlPro#881 revealed a latent issue with the implementation in OCamlPro#733 When we encounter a [bv2nat] term, we create a *term* that represents the [bv2nat] computation, then call [X.make] on the result. This has the unfortunate effect that the sub-terms of that new term are not added to the Union-Find (or at least not before the term itself). This is bad, but was harmless at the time. However, the resulting term from a call of [bv2nat] includes divisions. And since OCamlPro#881 divisions are represented by an uninterpreted term rather than an existential variable — and [IntervalCalculus.add] inspects that term, rightfully expecting that its sub-terms have been added to the Union-Find, which in this case they are not, and so we crash. This patch fixes the issue by introducing an uninterpreted term for the result of [bv2nat] and adding the equality between that uninterpreted term and the [bv2nat] computation. This equality is then processed as a term on its own, ensuring that subterms are added to the Union-Find before the terms that contain them. Note that long-term, we probably want to get rid of the construction of [bv2nat] terms directly in [X.make] in favor of propagators in a follow-up to OCamlPro#944 . This would avoid needing to go through terms for this.
This was referenced Nov 20, 2023
Halbaroth
approved these changes
Nov 22, 2023
bclement-ocp
added a commit
to bclement-ocp/alt-ergo
that referenced
this pull request
Nov 23, 2023
This is a follow-up to OCamlPro#954 Somehow convinced myself that the cases where we perform simplifications were fine because we would only be simplifying into a subterm, but that is obviously not the case due to negation. Let's just do the safe thing and always return the original term with the appropriate equalities. All of this code should be removed in favor of doing these computations in the relations instead anyways, which would make sure we always treat [bv2nat] in the same way for literals and after substitution (see also OCamlPro#824 )
bclement-ocp
added a commit
to bclement-ocp/alt-ergo
that referenced
this pull request
Nov 24, 2023
This is a follow-up to OCamlPro#954 Somehow convinced myself that the cases where we perform simplifications were fine because we would only be simplifying into a subterm, but that is obviously not the case due to negation. Let's just do the safe thing and always return the original term with the appropriate equalities. All of this code should be removed in favor of doing these computations in the relations instead anyways, which would make sure we always treat [bv2nat] in the same way for literals and after substitution (see also OCamlPro#824 )
bclement-ocp
added a commit
to bclement-ocp/alt-ergo
that referenced
this pull request
Nov 24, 2023
This is a follow-up to OCamlPro#954 Somehow convinced myself that the cases where we perform simplifications were fine because we would only be simplifying into a subterm, but that is obviously not the case due to negation. Let's just do the safe thing and always return the original term with the appropriate equalities. All of this code should be removed in favor of doing these computations in the relations instead anyways, which would make sure we always treat [bv2nat] in the same way for literals and after substitution (see also OCamlPro#824 )
bclement-ocp
added a commit
that referenced
this pull request
Nov 24, 2023
This is a follow-up to #954 Somehow convinced myself that the cases where we perform simplifications were fine because we would only be simplifying into a subterm, but that is obviously not the case due to negation. Let's just do the safe thing and always return the original term with the appropriate equalities. All of this code should be removed in favor of doing these computations in the relations instead anyways, which would make sure we always treat [bv2nat] in the same way for literals and after substitution (see also #824 )
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.
It turns out that #881 revealed a latent issue with the implementation in
#733
When we encounter a [bv2nat] term, we create a term that represents the [bv2nat] computation, then call [X.make] on the result. This has the unfortunate effect that the sub-terms of that new term are not added to the Union-Find (or at least not before the term itself). This is bad, but was harmless at the time.
However, the resulting term from a call of [bv2nat] includes divisions. And since #881 divisions are represented by an uninterpreted term rather than an existential variable — and [IntervalCalculus.add] inspects that term, rightfully expecting that its sub-terms have been added to the Union-Find, which in this case they are not, and so we crash.
This patch fixes the issue by introducing an uninterpreted term for the result of [bv2nat] and adding the equality between that uninterpreted term and the [bv2nat] computation. This equality is then processed as a term on its own, ensuring that subterms are added to the Union-Find before the terms that contain them.
Note that long-term, we probably want to get rid of the construction of [bv2nat] terms directly in [X.make] in favor of propagators in a follow-up to #944 . This would avoid needing to go through terms for this.