You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The SMT2 input below exhibits brittle behavior in how quantifiers are instantiated or used. We frequently see this kind of brittleness through Dafny, but it's been difficult to construct a small repro. Here is one!
Description of the problem
The formula to be verified essentially has the form
A && ; marked (**0) in the input below
B && ; marked (**1) in the input below
...
==>
; C && ; (**2)
D ; (**3)
(but with the proof goal negated in the usual way).
As is, this formula is not verified (that is, Z3 returns unknown). However, there are two different ways to make Z3 verify it (that is, to return unsat).
One way to make Z3 prove the formula is to uncomment C. That may not seem so odd. But it is, because B is a universal quantifier whose matching pattern is matched by D. Hence, Z3 ought to instantiate B. And that instantiation would then give D <==> C. This should let Z3 meet the proof goal by proving C, just as if C had been given at (**2) in the input.
The other way to make Z3 prove the formula is to removeA. Removing an antecedent ought to make a proof be more difficult, but in this case, removing the antecedent lets Z3 find the proof. What's even more odd is that the property stated by A is, logically, not useful in the proof, so whether or not A is included ought not matter.
From the looks of it, there's something about this input that affects which quantifiers are triggered and used. It ought to be that the formula would be proved valid whether or not A and C are included in the input.
Versions and options
I have used Z3 version 4.12.1 to get the behaviors I described above. However, a colleague used Z3 version 4.13.0 (on a slightly larger version of this example) and got the same results.
Note that the example requires trigger-based quantifiers. That is, :auto_config and :smt.mbqi are set to false.
These are the options that Dafny uses (via Boogie). The example does not use arithmetic, so I doubt the :smt.arith.solver setting matters. I understand what :smt.qi.eager_threshold does, and removing it does not affect this example.
I do not understand what :smt.case_split 3 and :smt.delay_units true do. These are settings that Dafny and Boogie have used for over a decade. The :smt.case_split 3 setting does make a difference in this example. In particular, if this setting is omitted, then:
If A is included, then Z3 fails to verify the input, regardless of whether or not C is included.
If A is removed, then Z3 verifies the input, regardless of whether or not C is included.
So, while the buggy behavior is affected by :smt.case_split 3, this setting does not seem to be the one that causes the buggy behavior.
The SMT2 input below exhibits brittle behavior in how quantifiers are instantiated or used. We frequently see this kind of brittleness through Dafny, but it's been difficult to construct a small repro. Here is one!
Description of the problem
The formula to be verified essentially has the form
(but with the proof goal negated in the usual way).
As is, this formula is not verified (that is, Z3 returns
unknown
). However, there are two different ways to make Z3 verify it (that is, to returnunsat
).C
. That may not seem so odd. But it is, becauseB
is a universal quantifier whose matching pattern is matched byD
. Hence, Z3 ought to instantiateB
. And that instantiation would then giveD <==> C
. This should let Z3 meet the proof goal by provingC
, just as ifC
had been given at(**2)
in the input.A
. Removing an antecedent ought to make a proof be more difficult, but in this case, removing the antecedent lets Z3 find the proof. What's even more odd is that the property stated byA
is, logically, not useful in the proof, so whether or notA
is included ought not matter.From the looks of it, there's something about this input that affects which quantifiers are triggered and used. It ought to be that the formula would be proved valid whether or not
A
andC
are included in the input.Versions and options
I have used Z3 version 4.12.1 to get the behaviors I described above. However, a colleague used Z3 version 4.13.0 (on a slightly larger version of this example) and got the same results.
Note that the example requires trigger-based quantifiers. That is,
:auto_config
and:smt.mbqi
are set tofalse
.More unusually, the input sets
These are the options that Dafny uses (via Boogie). The example does not use arithmetic, so I doubt the
:smt.arith.solver
setting matters. I understand what:smt.qi.eager_threshold
does, and removing it does not affect this example.I do not understand what
:smt.case_split 3
and:smt.delay_units true
do. These are settings that Dafny and Boogie have used for over a decade. The:smt.case_split 3
setting does make a difference in this example. In particular, if this setting is omitted, then:A
is included, then Z3 fails to verify the input, regardless of whether or notC
is included.A
is removed, then Z3 verifies the input, regardless of whether or notC
is included.So, while the buggy behavior is affected by
:smt.case_split 3
, this setting does not seem to be the one that causes the buggy behavior.The input
The text was updated successfully, but these errors were encountered: