Cvc4

Barrett, Clark; Conway, Christopher L.; Deters, Morgan; Hadarean, Liana; Jovanović, Dejan; King, Tim L.; Reynolds, Andrew; Tinelli, Cesare

doi:10.1007/978-3-642-22110-1_14

Cited by 581 publications

(268 citation statements)

References 15 publications

Supporting

Mentioning

266

Contrasting

Unclassified

Order By: Relevance

“…She starts by writing down the program code, xes one or two simple mistakes (readily spotted by static typing), and, before annotating the program with any pre-or postconditions, runs the interactive veri er to perform the safety checks against out-of-bounds array accesses, arithmetic over ows, division by zero, etc. Why3 presents the whole veri cation condition for a given function as a single goal, and thus the rst step is to split it down to a number of simple proof obligations and then to launch the provers, say, Alt-Ergo [3], CVC4 [1], or Z3 [7] on each of them. Let each safety condition be satis ed, except for one, which requires an integer parameter to be positive.…”

Section: Introductionmentioning

confidence: 99%

Preserving User Proofs across Specification Changes

Bobot

Filliâtre

Marché

et al. 2014

Verified Software: Theories, Tools, Experiments

View full text Add to dashboard Cite

Abstract. In the context of deductive program veri cation, both the speci cation and the code evolve as the veri cation process carries on. For instance, a loop invariant gets strengthened when additional properties are added to the speci cation. This causes all the related proof obligations to change; thus previous user veri cations become invalid. Yet it is often the case that most of previous proof attempts (goal transformations, calls to interactive or automated provers) are still directly applicable or are easy to adjust. In this paper, we describe a technique to maintain a proof session against modi cation of veri cation conditions. This technique is implemented in the Why3 platform. It was successfully used in developing more than a hundred veri ed programs and in keeping them up to date along the evolution of Why3 and its standard library. It also helps out with changes in the environment, e.g. prover upgrades.

show abstract

Section: Introductionmentioning

confidence: 99%

Preserving User Proofs across Specification Changes

Bobot

Filliâtre

Marché

et al. 2014

Verified Software: Theories, Tools, Experiments

View full text Add to dashboard Cite

show abstract

“…Our conversion scheme follows a declarative and non-recursive style. The produced quantified constraints are often beyond the capacity of modern SMT solvers such as Yices [19] and CVC [1]. To handle them, we propose an efficient quantifier elimination algorithm.…”

Section: Introductionmentioning

confidence: 99%

PASS: String Solving with Parameterized Array and Interval Automaton

Ghosh

2013

Hardware and Software: Verification and Testing

View full text Add to dashboard Cite

Abstract. The problem of solving string constraints together with numeric constraints has received increasing interest recently. Existing methods use either bit-vectors or automata (or their combination) to model strings, and reduce string constraints to bit-vector constraints or automaton operations, which are then solved in the respective domain. Unfortunately, they often fail to achieve a good balance between efficiency, accuracy, and comprehensiveness. In this paper we illustrate a new technique that uses parameterized arrays as the main data structure to model strings, and converts string constraints into quantified expressions that are solved through quantifier elimination. We present an efficient and sound quantifier elimination algorithm. In addition, we use an automaton model to handle regular expressions and reason about string values faster. Our method does not need to enumerate string lengths (as bit-vector based methods do), or concrete string values (as automaton based methods do). Hence, it can achieve much better accuracy and efficiency. In particular, it can identify unsatisfiable cases quickly. Our solver (named PASS) supports most of the popular string operations, including string comparisons, string-numeric conversions, and regular expressions. Experimental results demonstrate the advantages of our method.

show abstract

“…InstGen [33], Model Evolution [6], or Geometric Resolution [20]). 4 Ideally, however, we envision a format open to future extensions for recording of techniques yet to be developed.…”

Section: An Ideal Proof Formatmentioning

confidence: 99%

“…Here, LF stands for the Edinburgh Logical Framework [25] (also based on λΠ-calculus as its meta-language) and SC stands for Side Conditions, which are pieces of trusted code in a small custom programming language used to express more complicated rules. LFSC is the proof language currently employed by the SMT solver CVC4 [4]. 6 There have been other efforts by the SMT community to devising a common proof format.…”

Section: Some Previous Work and Related Approachesmentioning

confidence: 99%

Checkable Proofs for First-Order Theorem Proving

Reger¹,

Suda²

EPiC Series in Computing

View full text Add to dashboard Cite

Inspired by the success of the DRAT proof format for certification of boolean satisfiability (SAT), we argue that a similar goal of having unified automatically checkable proofs should be sought by the developers of automatic first-order theorem provers (ATPs). This would not only help to further increase assurance about the correctness of prover results, but would also be indispensable for tools which rely on ATPs, such as "hammers" employed within interactive theorem provers. The current situation, represented by the TSTP format, is unsatisfactory, because this format does not have a standardised semantics and thus cannot be checked automatically. Providing such semantics, however, is a challenging endeavour. One would ideally like to have a proof format which covers only-satisfiability-preserving operations such as Skolemisation and is versatile enough to encompass various proving methods (i.e. not just superposition) or is perhaps even open-ended towards yet to be conceived methods or at least easily extendable in principle. Going beyond pure first-order logic to theory reasoning in the style of SMT, or beyond proofs to certification of satisfiability are further interesting challenges. Although several projects have already provided partial solutions in this direction, we would like to use the opportunity of ARCADE to further promote the idea and gather critical mass needed for its satisfactory realisation. The challengeWe would like to propose to the first-order ATP community the challenge of designing, implementing and bringing into practice a unified mechanically checkable proof format along with an efficient proof checker. The format should support the whole reasoning pipeline including formula preprocessing, be sufficiently general to cover all the solving techniques currently employed by ATPs, and be open to future extensions for proof recording of techniques yet to be developed. In this paper, we summarise the current situation regarding proof output of ATPs, explain why we think striving for a mechanically checkable proof format is a worthy effort, list the main properties we believe an ideal format should satisfy, attempt to give an overview of work already done in the first-order ATP community and related areas, and, finally, suggest possible avenues and the next steps to be taken for meeting the challenge.At this point we add the disclaimer that other people have already examined this challenge in various ways. We attempt to present this previous work and do not claim that what we are suggesting is novel, but instead we are calling for further work in this area. Our main aim at ARCADE is to solicit opinions from experts on why the proposed idea has not yet made its way to practice and on how exactly should the community proceed to achieve the envisioned goal.

show abstract

Cvc4

Cited by 581 publications

References 15 publications

Preserving User Proofs across Specification Changes

Preserving User Proofs across Specification Changes

PASS: String Solving with Parameterized Array and Interval Automaton

Checkable Proofs for First-Order Theorem Proving

Contact Info

Product

Resources

About