CVC4 - User contributions [en]

User Manual

2018-07-12T18:19:48Z

Clark Barrett:

This manual includes information on installing and using CVC4. It is a work in progress.

=Getting CVC4=

Both pre-compiled binaries and the source code for CVC4 are available for download from [http://cvc4.cs.stanford.edu/downloads/builds/ http://cvc4.cs.stanford.edu/downloads/builds/].

==Getting CVC4 binaries==
The most recent binaries can be downloaded from our Nightly Builds pages:
* [http://cvc4.cs.stanford.edu/downloads/builds/x86_64-linux-opt/ Optimized] binaries (statically linked)
* [http://cvc4.cs.stanford.edu/downloads/builds/x86_64-linux-dbg/ Debug] binaries (statically linked)
* [http://cvc4.cs.stanford.edu/downloads/builds/debian/ Debian] packages

'''[Not ported to Stanford yet]''' To install CVC4 on an Ubuntu Machine follow the instructions below. First add the CVC4 repository to /etc/apt/sources.list by inserting the following two lines at the end of the file:
# CVC4 repository
deb http://cvc4.cs.nyu.edu/debian/ unstable/
deb-src http://cvc4.cs.nyu.edu/debian/ unstable/

To run CVC4 as a binary you only need the first line but to use the library API you will also need the source package.
Make sure to update the respository list by running:

sudo apt-get update

Now you can simply install CVC4 as you would any other piece of sofware using the command:
sudo apt-get install cvc4

If you want to use CVC4 as a library also install the following packages: libcvc4-dev, and libcvc4-parser-dev.

==Building CVC4 from source==
[http://cvc4.cs.stanford.edu/downloads/builds/src/ Sources are available] from the same site as the binaries. The source-code is also available in the [https://github.com/CVC4/CVC4 CVC4 source repository].

To build CVC4 from source the following steps are required. After downloading the source files first install antlr by running the following script in the CVC4 contrib directory:
cd contrib
./get-antlr-3.4

The next step is to configure CVC4:
cd ..
./configure --with-antlr-dir=`pwd`/antlr-3.4 ANTLR=`pwd`/antlr-3.4/bin/antlr3

And then finally compile it:
make
make check [recommended]
make install [optional]

For a comprehensive list of dependencies and more detailed build instructions see [[Building CVC4 from source]].

=Using the CVC4 binary=

Once installed, the CVC4 driver binary ("cvc4") can be executed to directly enter into interactive mode:

$ cvc4
cvc4 1.0 assertions:off
CVC4>

You can then enter commands into CVC4 interactively:

CVC4> OPTION "incremental";
CVC4> OPTION "produce-models";
CVC4> TRANSFORM 25*25;
625
CVC4> x, y : INT;
CVC4> QUERY x = y;
invalid
CVC4> COUNTERMODEL;
x : INT = -1;
y : INT = 0;
CVC4> ASSERT x >= 0;
CVC4> QUERY x = y;
invalid
CVC4> COUNTERMODEL;
x : INT = 0;
y : INT = 1;
CVC4>

The above example shows two useful options, ''incremental'' and ''produce-models.''

* The ''incremental'' option allows you to issue multiple QUERY (or CHECKSAT) commands, and allows the use of the PUSH and POP commands. Without this option, CVC4 optimizes itself for a single QUERY or CHECKSAT command (though you may issue any number of ASSERT commands). The ''incremental'' option may also be given by passing the ''-i'' command line option to CVC4.
* The ''produce-models'' option allows you to query the model (here, with the COUNTERMODEL command) after an "invalid" QUERY (or "satisfiable" CHECK-SAT). Without it, CVC4 doesn't do the bookkeeping necessary to support model generation. The ''produce-models'' option may also be given by passing the ''-m'' command line option to CVC4.

So, if you invoke CVC4 with ''-im'', you don't need to pass those options at all:

$ cvc4 -im
cvc4 1.0 assertions:off
CVC4> x, y : INT;
CVC4> QUERY x = y;
invalid
CVC4> COUNTERMODEL;
x : INT = -1;
y : INT = 0;
CVC4> ASSERT x >= 0;
CVC4> QUERY x = y;
invalid
CVC4> COUNTERMODEL;
x : INT = 0;
y : INT = 1;
CVC4>

By default, CVC4 operates in [[#CVC4's native input language|CVC-language mode]]. If you enter something that looks like SMT-LIB, it will suggest that you use the "''--lang smt''" command-line option for SMT-LIB mode:

CVC4> (declare-fun x () Int)
Parse Error: <shell>:1.7: In CVC4 presentation language mode, but SMT-LIB format detected. Use --lang smt for SMT-LIB support.
CVC4>

==Verbosity==

CVC4 has various levels of verbosity. By default, CVC4 is pretty quiet, only reporting serious warnings and notices. If you're curious about what it's doing, you can pass CVC4 the ''-v'' option:

$ cvc4 -v file.smt2
Invoking: (set-logic AUFLIRA)
Invoking: (set-info :smt-lib-version 2.000000)
Invoking: (set-info :category "crafted")
Invoking: (set-info :status unsat)
Invoking: (declare-fun x () Real)
''etc...''

For even more verbosity, you can pass CVC4 an ''additional'' ''-v'':

$ cvc4 -vv file.smt2
Invoking: (set-logic AUFLIRA)
Invoking: (set-info :smt-lib-version 2.000000)
Invoking: (set-info :category "crafted")
Invoking: (set-info :status unsat)
Invoking: (declare-fun x () Real)
''etc...''
expanding definitions...
constraining subtypes...
applying substitutions...
simplifying assertions...
doing static learning...
''etc...''

Internally, verbosity is just an integer value. It starts at 0, and with every ''-v'' on the command line it is incremented; with every ''-q'', decremented. It can also be set directly. From CVC language:

CVC4> OPTION "verbosity" 2;

Or from SMT-LIB language:

CVC4> (set-option :verbosity 2)

==Getting statistics==

Statistics can be dumped on exit (both normal and abnormal exits) with the ''--statistics'' command line option.

$ cvc4 --statistics foo.smt2
sat
sat::decisions, 0
sat::propagations, 3
sat::starts, 1
theory::uf::TheoryUF::functionTermsCount, 2
theory::uf::TheoryUF::mergesCount, 2
theory::uf::TheoryUF::termsCount, 6
theory<THEORY_UF>::propagations, 1
driver::filename, foo.smt2
driver::sat/unsat, sat
driver::totalTime, 0.02015373
''[many others]''

Many statistics name-value pairs follow, one comma-separated pair per line.

==Exit status==

Successful exit is marked by the exit code 0. Most "normal errors" return a 1 as the exit code, but out of memory conditions, terminating signals, and other conditions can produce different (nonzero) exit codes. In interactive mode, parse errors are ignored and the next line read; so in interactive mode, you may see an exit code of 0 even in the presence of such an error.

''Note on previous versions:'' Up to version 1.2 of CVC4, exit status depended on the result ("sat" results caused an exit code of 10, "unsat" of 20). This behavior was deemed nonstandard and is no longer the case; successful exits are always 0 in version 1.3 and later.

=CVC4's input languages=

When not used in interactive mode, CVC4 can read its input from an external file. It accepts the following input languages:

* [[CVC4's native language | CVC4's native language]]
* SMT-LIB 2.0 (see [http://www.grammatech.com/resources/smt/SMTLIBTutorial.pdf David Cok's SMT-LIB tutorial])
* SMT-LIB 1.0

CVC4 tries to automatically recognize the input language based on the file's extension: .cvc for CVC4's native language, .smt2 for SMT-LIB 2.0 and .smt for SMT-LIB 1.0. If the file extension does not match one of the previously mentioned ones you can specify the input language via the command line flag --lang. To see all language options type:
$ cvc4 --lang help

Every effort has been made to make CVC4 compliant with the SMT-LIB 2.0
standard (http://smtlib.org/). However, when parsing SMT-LIB input,
certain default settings don't match what is stated in the official
standard. To make CVC4 adhere more strictly to the standard, use the
"--smtlib" command-line option. Even with this setting, CVC4 is
somewhat lenient; some non-conforming input may still be parsed and
processed.

=Supported Theories=
The following theories are currently fully supported
* Booleans
* Uninterpreted functions
* Arrays [with extensionality]
* Inductive datatypes
* Tuples and record types
* Fixed width bitvectors
* Linear mixed real integer arithmetic
** Integer division and modulus by integer constants is supported by the "--rewrite-divk" flag
* [[sets|Finite sets]]
CVC4 supports first-order quantification and theory combinations of the above theories.

The following theories are currently partially supported and are undergoing development:
* Strings

Theories with '''highly limited''' support:
* CVC4's non-linear real and non-linear integer arithmetic support is currently unlikely to satisfy a user's needs. The current support is for parsing, rewrites, and a very limited class of proofs of unsatisifiability. The class of proofs is what is provable by linear arithmetic where each monomial (e.g. "xxy") is treated as a unique variable.

=The CVC4 library interface (API)=

There are a number of examples of using CVC4 as a library distributed with the source code of the project. There are given in the "/examples" directory.

==Using CVC4 in a C++ project==

A basic C++ example for using cvc4 is given in the file [https://github.com/CVC4/CVC4/blob/master/examples/simple_vc_cxx.cpp /examples/simple_vc_cxx.cpp].
The file goes through the examples for the basic interaction with CVC4:
# Constructing an ExprManager em
# Constructing an SmtEngine w.r.t. em.
# Getting a copy of the Type for mathematical integers from em, em.integerType().
# Constructing new Expressions
## Integer variables x and y: Expr x = em.mkVar("x", integer);
## The rational constant 0: em.mkConst(Rational(0));
## Constructing new expressions existing expressions: em.mkExpr(kind::GT, x, zero);
# Querying the SmtEngine whether or not a formula is valid.

More information on the interfaces for Expr, Type, ExprManager and SmtEngine can be found in their respective header files.

To compile simple_vc_cxx.cpp, there are different build instructions for whether or not you are compiling against a version of CVC4 in a local build directory or one installed via "make install" into a directory $PREFIX.

* Local Build Directory: If you have build cvc4 via the "make" command before, you can compile simple_vc_cxx.cpp via "make examples". The executable will then be "./builds/examples/simple_vc_cxx".

$ make examples
[...]
$ ./builds/examples/simple_vc_cxx
Checking validity of formula ((x > 0) AND (y > 0)) => (((2 * x) + y) >= 3) with CVC4.
CVC4 should report VALID.
Result from CVC4 is: valid
* Installed Copy: If you have installed CVC4 via "make install" into the directory $PREFIX (which you can configure via "./configure --prefix=$PREFIX" you will need to modify lines 21-22.
//#include <cvc4/cvc4.h> // use this after CVC4 is properly installed
#include "smt/smt_engine.h"
:First, uncomment line 21 and comment out line 22. You may now
You can now compile and run by executing
g++ -I$PREFIX/include -L$PREFIX/lib -lcvc4 examples/simple_vc_cxx.cpp -o simple_vc_cxx
./simple_vc_cxx
:You may need to add $PREFIX/lib is LD_LIBRARY_PATH or the equivalent.

==Using CVC4 from Java==
==The compatibility interface==

=Upgrading from CVC3 to CVC4=

==Features not supported by CVC4 (yet)==

===Type Correctness Conditions (TCCs)===

Type Correctness Conditions (TCCs), and the checking of such, are not
supported by CVC4 1.0. Thus, a function defined only on integers can be
applied to REAL (as INT is a subtype of REAL), and CVC4 will not complain,
but may produce strange results. For example:

f : INT -> INT;
ASSERT f(1/3) = 0;
ASSERT f(2/3) = 1;
CHECKSAT;
% sat
COUNTEREXAMPLE;
% f : (INT) -> INT = LAMBDA(x1:INT) : 0;

CVC3 can be used to produce TCCs for this input (with the +dump-tcc option).
The TCC can be checked by CVC3 or another solver. (CVC3 can also check
TCCs while solving with +tcc.)

==If you were using the text interfaces of CVC3==

The native language of all solvers in the CVC family, referred to as the
"presentation language," has undergone some revisions for CVC4. The
most notable is that CVC4 does _not_ add counterexample assertions to
the current assertion set after a SAT/INVALID result. For example:

x, y : INT;
ASSERT x = 1 OR x = 2;
ASSERT y = 1 OR y = 2;
ASSERT x /= y;
CHECKSAT;
% sat
QUERY x = 1;
% invalid
QUERY x = 2;
% invalid

Here, CVC4 responds "invalid" to the second and third queries, because
each has a counterexample (x=2 is a counterexample to the first, and
x=1 is a counterexample to the second). However, CVC3 will respond
with "valid" to one of these two, as the first query (the CHECKSAT)
had the side-effect of locking CVC3 into one of the two cases; the
later queries are effectively querying the counterexample that was
found by the first. CVC4 removes this side-effect of the CHECKSAT and
QUERY commands.

CVC4 supports rational literals (of type REAL) in decimal; CVC3 did not
support decimals.

CVC4 does not have support for the IS_INTEGER predicate.

==If you were using the library ("in-memory") interface of CVC3==
===If you were using CVC3 from C===
===If you were using CVC3 from Java===

=Advanced features=

This section describes some features of CVC4 of interest to developers and advanced users.

==Resource limits==

CVC4 can be made to self-timeout after a given number of milliseconds.
Use the --tlimit command line option to limit the entire run of
CVC4, or use --tlimit-per to limit each individual query separately.
Preprocessing time is not counted by the time limit, so for some large
inputs which require aggressive preprocessing, you may notice that
--tlimit does not work very well. If you suspect this might be the
case, you can use "-vv" (double verbosity) to see what CVC4 is doing.

Time-limited runs are not deterministic; two consecutive runs with the
same time limit might produce different results (i.e., one may time out
and responds with "unknown", while the other completes and provides an
answer). To ensure that results are reproducible, use --rlimit or
--rlimit-per. These options take a "resource count" (presently, based on
the number of SAT conflicts) that limits the search time. A word of
caution, though: there is no guarantee that runs of different versions of
CVC4 or of different builds of CVC4 (e.g., two CVC4 binaries with different
features enabled, or for different architectures) will interpret the resource
count in the same manner.

CVC4 does not presently have a way to limit its memory use; you may opt
to run it from a shell after using "ulimit" to limit the size of the
heap.

==Dumping API calls or preprocessed output==

[to do]

==Changing the output language==

[to do]

==Proof support==

CVC4 1.0 has limited support for proofs, and they are disabled by default.
(Run the configure script with --enable-proof to enable proofs). Proofs
are exported in LFSC format and are limited to the propositional backbone
of the discovered proof (theory lemmas are stated without proof in this
release).

==Parallel solving==

'''[Builds not ported to Stanford yet]''' The most recent binaries with support for parallel solving can be downloaded from our Nightly Builds pages:
* [http://cvc4.cs.nyu.edu/cvc4-builds/portfolio-x86_64-linux-opt/ Optimized] binaries (statically linked)
* [http://cvc4.cs.nyu.edu/cvc4-builds/portfolio-x86_64-linux-dbg/ Debug] binaries (statically linked)

If enabled at configure-time (./configure --with-portfolio), a second
CVC4 binary will be produced ("pcvc4"). This binary has support for
running multiple instances of CVC4 in different threads. Use --threads=N
to specify the number of threads, and use --thread0="options for thread 0"
--thread1="options for thread 1", etc., to specify a configuration for the
threads. Lemmas are *not* shared between the threads by default; to adjust
this, use the --filter-lemma-length=N option to share lemmas of N literals
(or smaller). (Some lemmas are ineligible for sharing because they include
literals that are "local" to one thread.)

Currently, the portfolio **does not work** with the theory of inductive
datatypes. This limitation will be addressed in a future release.

See more details and examples in the [[Tutorials#Parallel_Solving|tutorial]].

==Emacs support==

For a suggestion of editing CVC4 source code with emacs, see the file
contrib/editing-with-emacs. For a CVC language mode (the native input
language for CVC4), see contrib/cvc-mode.el.

About CVC4

2017-01-27T17:19:47Z

Clark Barrett:

CVC4 is an automatic theorem prover for [http://en.wikipedia.org/wiki/Satisfiability_Modulo_Theories Satisifiability Modulo Theories (SMT)] (for a more formal introduction to SMT see the following book chapter [https://cs.stanford.edu/~barrett/pubs/BSST09.pdf Satisfiability Modulo Theories] ). Technically, it is an automated validity checker for a many-sorted (i.e., typed) first-order logic with built-in theories.
It can be used to prove the validity (or, dually, the satisfiability) of a formula with respect to several built-in logical theories and their combination.

CVC4 currently has support for the following theories:
* equality over free (aka uninterpreted) function and predicate symbols
* real and integer linear arithmetic
* bit-vectors
* arrays
* tuples
* records
* user-defined inductive [[Datatypes|datatypes]]
* [[Strings|strings]]
* [[Sets|finite sets]]
* [[Separation Logic|separation logic]]

CVC4 has a wide variety of features including:

* support for quantifiers through heuristic instantiation;
* an interactive text-based interface;
* a rich [http://cvc4.cs.stanford.edu/cvc4-builds/documentation/public/latest/ C++ API] for embedding in other systems;
* model generation abilities;
* source compatibility with much of the CVC3 API via a "compatibility library";
* essentially no limit on its use for research or commercial purposes (see [https://github.com/CVC4/CVC4/blob/master/COPYING license]).

=Web site=

For more information and the latest news about CVC4, visit the [http://cvc4.cs.stanford.edu CVC4 web site].

=Decision Procedures=
* Architecture
** See the [http://dl.acm.org/citation.cfm?id=2032319 CVC4 tool paper].
* Arithmetic
** CVC4 solves linear real arithmetic using an implementation of [http://link.springer.com/chapter/10.1007%2F11817963_11? Simplex for DPLL(T)]. For a more complete introduction see the [http://yices.csl.sri.com/sri-csl-06-01.pdf tech report].
** The linear arithmetic module includes heuristics from [http://eprints-phd.biblio.unitn.it/166/2/thesis.pdf Section 2.5 of Alberto Griggio's thesis] and a few currently unpublished ones.
** Integers are currently handled by first solving the real relaxation of the constraints, and then using a combination of [http://www.cs.wm.edu/~idillig/cav2009.pdf Cuts from Proofs] and branching to ensure integer solutions. This approach and the equational solver used are described in [https://es.fbk.eu/people/griggio/papers/jsat12.pdf A Practical Approach to Satisfiability Modulo Linear Integer Arithmetic].
** A technical report is planned to explain a number of small details and extensions including analysis to improve simplex's conflicts, handling disequalities, supporting model generation in CVC4's combination framework, heuristically propagating equalities over sharing terms, tableau row based propagation, and terminating simplex with unknown.
** Non-linear arithmetic support is currently rudimentary to non-existent. In CVC4 v1.0, non-linearity is handled by abstracting monomials as unique new variables. We plan on implementing [http://cs.nyu.edu/~dejan/papers/jovanovic-ijcar2012.pdf Solving Non-Linear Arithmetic] this spring.
* Arrays
** Arrays are implemented in a manner inspired by the [http://research.microsoft.com/en-us/um/people/leonardo/files/fmcad09.pdf Generalized, efficient array decision procedures] paper with a few major modifications.
* Bitvectors
** Bitvectors is implemented primarily via a lazy schema for bitblasting. See [http://eprints-phd.biblio.unitn.it/345/ Anders Franzen's thesis chapter 3].
* Combination
** Theory combination is based on the care graph framework described in both [http://cs.nyu.edu/~dejan/papers/jovanovic-fmsd2012.pdf Being careful about theory combination] and [http://cs.nyu.edu/~dejan/papers/jovanovic-frocos2011.pdf Sharing is Caring: Combination of Theories].
* Datatypes
** CVC4 implements [http://homepage.cs.uiowa.edu/~tinelli/papers/BarST-JSAT-07.pdf An Abstract Decision Procedure for a Theory of Inductive Data Types].
** This procedure has been extended to incorporate coinductive datatypes [http://homepage.cs.uiowa.edu/~ajreynol/cade15.pdf].
* Quantifiers
** E-matching and conflict-based quantifier instantiation [http://homepage.cs.uiowa.edu/~ajreynol/fmcad14.pdf].
** Finite model finding [http://homepage.cs.uiowa.edu/~ajreynol/thesis.pdf].
** Techniques for finding counterexamples for conjectures in the presence of recursive functions [http://homepage.cs.uiowa.edu/~ajreynol/ijcar16a.pdf].
** Automated induction for datatypes [http://homepage.cs.uiowa.edu/~ajreynol/vmcai15.pdf].
** A decision procedure for quantified linear arithmetic with one alternation [http://homepage.cs.uiowa.edu/~ajreynol/report-inst-la15.pdf].
** Support for syntax-guided synthesis, as described in [http://homepage.cs.uiowa.edu/~ajreynol/cav15a.pdf].
* SAT Solver
** The main sat solver is based on [http://minisat.se/ minisat v2.2.0].
** Additionally, we (optionally, and enabled by default for certain theories) use non-clausal analysis to cut down search space of minisat. For more details see the article [http://cs.nyu.edu/~kshitij/articles/cvc4-branching-heuristic.pdf A branching heuristic in CVC4].
* Separation Logic
** A decision procedure for a fragment quantifier-free separation logic containing negation, separation star and magic wand is implemented and can be composed with other decision procedures supported by CVC4. For details see [http://homepage.divms.uiowa.edu/~ajreynol/atva16.pdf A Decision Procedure for Separation Logic in SMT].
* Sets
** Adaptation of tableau-based decision procedure described [http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.10.5176 here].
* Strings
** Original approach described in our [http://www.cs.stanford.edu/~barrett/pubs/LRT+14.pdf CAV 2014 paper: A DPLL(T) Theory Solver for a Theory of Strings and Regular Expressions].
** Decision procedure for regular memberships with length [http://homepage.cs.uiowa.edu/~ajreynol/frocos15.pdf].
* Uninterpreted functions
** UF (without cardinality) is handled in a manner inspired by [http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.70.1745 Simplify's tech report].
** UF + cardinality is described [http://www.divms.uiowa.edu/~ajreynol/pres-fmf12.pdf this presentation] and is used for finite model finding.

=History of CVC=

[[File:svc.gif|thumb|border|100px|The SVC logo.]]
[[File:cvc3_logo.jpg|thumb|border|100px|The CVC3 logo.]]
[[File:cvc3_night_logo.png|thumb|border|100px|The CVC3 "by night" logo, used for nightly builds and regressions.]]
[[File:cvc3cvc4.png|thumb|border|100px|An early CVC4 logo.]]

The Cooperating Validity Checker series has a long history. The
Stanford Validity Checker (SVC) came first in 1996, incorporating
theories and its own SAT solver. Its successor, the Cooperating
Validity Checker (CVC), had a more optimized internal design, produced
proofs, used the Chaff SAT solver, and featured a number of usability
enhancements. Its name comes from the cooperative nature of decision
procedures in Nelson-Oppen theory combination, which share amongst
each other equalities between shared terms. CVC Lite, first made
available in 2003, was a rewrite of CVC that attempted to make CVC
more flexible (hence the "lite") while extending the feature set: CVC
Lite supported quantifiers where its predecessors did not. CVC3 was a
major overhaul of portions of CVC Lite: it added better decision
procedure implementations, added support for using MiniSat in the
core, and had generally better performance.

[[File:cvc4-logo.png|thumb|border|100px|The CVC4 logo.]]
CVC4 is the new version, the fifth generation of this validity checker
line that is now celebrating sixteen years of heritage. It represents
a complete re-evaluation of the core architecture to be both
performant and to serve as a cutting-edge research vehicle for the
next several years. Rather than taking CVC3 and redesigning problem
parts, we've taken a clean-room approach, starting from scratch.
Before using any designs from CVC3, we have thoroughly scrutinized,
vetted, and updated them. Many parts of CVC4 bear only a superficial
resemblance, if any, to their correspondent in CVC3.

However, CVC4 is fundamentally similar to CVC3 and many other modern
SMT solvers: it is a DPLL(T) solver, with a SAT solver at its core and
a delegation path to different decision procedure implementations,
each in charge of solving formulas in some background theory.

The re-evaluation and ground-up rewrite was necessitated, we felt, by
the performance characteristics of CVC3. CVC3 has many useful
features, but some core aspects of the design led to high memory use,
and the use of heavyweight computation (where more nimble engineering
approaches could suffice) makes CVC3 a much slower prover than other
tools. As these designs are central to CVC3, a new version was
preferable to a selective re-engineering, which would have ballooned
in short order.

About CVC4

2017-01-27T00:16:56Z

Clark Barrett:

CVC4 is an automatic theorem prover for [http://en.wikipedia.org/wiki/Satisfiability_Modulo_Theories Satisifiability Modulo Theories (SMT)] (for a more formal introduction to SMT see the following book chapter [https://cs.stanford.edu/~barrett/pubs/BSST09.pdf Satisfiability Modulo Theories] ). Technically, it is an automated validity checker for a many-sorted (i.e., typed) first-order logic with built-in theories.
It can be used to prove the validity (or, dually, the satisfiability) of a formula with respect to several built-in logical theories and their combination.

CVC4 currently has support for the following theories:
* equality over free (aka uninterpreted) function and predicate symbols
* real and integer linear arithmetic
* bit-vectors
* arrays
* tuples
* records
* user-defined inductive [[Datatypes|datatypes]]
* [[Strings|strings]]
* [[Sets|finite sets]]
* [[Separation Logic|separation logic]]

CVC4 has a wide variety of features including:

* support for quantifiers through heuristic instantiation;
* an interactive text-based interface;
* a rich [http://cvc4.cs.stanford.edu/cvc4-builds/documentation/public/latest/ C++ API] for embedding in other systems;
* model generation abilities;
* source compatibility with much of the CVC3 API via a "compatibility library";
* essentially no limit on its use for research or commercial purposes (see [https://github.com/CVC4/CVC4/blob/master/COPYING license]).

=Web site=

For more information and the latest news about CVC4, visit the [http://cvc4.cs.stanford.edu CVC4 web site].

=Decision Procedures=
* Architecture
** See the [http://dl.acm.org/citation.cfm?id=2032319 CVC4 tool paper].
* Arithmetic
** CVC4 solves linear real arithmetic using an implementation of [http://link.springer.com/chapter/10.1007%2F11817963_11? Simplex for DPLL(T)]. For a more complete introduction see the [http://yices.csl.sri.com/sri-csl-06-01.pdf tech report].
** The linear arithmetic module includes heuristics from [http://eprints-phd.biblio.unitn.it/166/2/thesis.pdf Section 2.5 of Alberto Griggio's thesis] and a few currently unpublished ones.
** Integers are currently handled by first solving the real relaxation of the constraints, and then using a combination of [http://www.cs.wm.edu/~idillig/cav2009.pdf Cuts from Proofs] and branching to ensure integer solutions. This approach and the equational solver used are described in [https://es.fbk.eu/people/griggio/papers/jsat12.pdf A Practical Approach to Satisfiability Modulo Linear Integer Arithmetic].
** A technical report is planned to explain a number of small details and extensions including analysis to improve simplex's conflicts, handling disequalities, supporting model generation in CVC4's combination framework, heuristically propagating equalities over sharing terms, tableau row based propagation, and terminating simplex with unknown.
** Non-linear arithmetic support is currently rudimentary to non-existent. In CVC4 v1.0, non-linearity is handled by abstracting monomials as unique new variables. We plan on implementing [http://cs.nyu.edu/~dejan/papers/jovanovic-ijcar2012.pdf Solving Non-Linear Arithmetic] this spring.
* Arrays
** Arrays are implemented in a manner inspired by the [http://research.microsoft.com/en-us/um/people/leonardo/files/fmcad09.pdf Generalized, efficient array decision procedures] paper with a few major modifications.
* Bitvectors
** Bitvectors is implemented primarily via a lazy schema for bitblasting. See [http://eprints-phd.biblio.unitn.it/345/ Anders Franzen's thesis chapter 3].
* Combination
** Theory combination is based on the care graph framework described in both [http://cs.nyu.edu/~dejan/papers/jovanovic-fmsd2012.pdf Being careful about theory combination] and [http://cs.nyu.edu/~dejan/papers/jovanovic-frocos2011.pdf Sharing is Caring: Combination of Theories].
* Datatypes
** CVC4 implements [http://homepage.cs.uiowa.edu/~tinelli/papers/BarST-JSAT-07.pdf An Abstract Decision Procedure for a Theory of Inductive Data Types].
** This procedure has been extended to incorporate coinductive datatypes [http://homepage.cs.uiowa.edu/~ajreynol/cade15.pdf].
* Quantifiers
** E-matching and conflict-based quantifier instantiation [http://homepage.cs.uiowa.edu/~ajreynol/fmcad14.pdf].
** Finite model finding [http://homepage.cs.uiowa.edu/~ajreynol/thesis.pdf].
** Techniques for finding counterexamples for conjectures in the presence of recursive functions [http://homepage.cs.uiowa.edu/~ajreynol/ijcar16a.pdf].
** Automated induction for datatypes [http://homepage.cs.uiowa.edu/~ajreynol/vmcai15.pdf].
** A decision procedure for quantified linear arithmetic with one alternation [http://homepage.cs.uiowa.edu/~ajreynol/report-inst-la15.pdf].
** Support for syntax-guided synthesis, as described in [http://homepage.cs.uiowa.edu/~ajreynol/cav15a.pdf].
* SAT Solver
** The main sat solver is based on [http://minisat.se/ minisat v2.2.0].
** Additionally, we (optionally, and enabled by default for certain theories) use non-clausal analysis to cut down search space of minisat. For more details see the article [http://cs.nyu.edu/~kshitij/articles/cvc4-branching-heuristic.pdf A branching heuristic in CVC4].
* Separation Logic
** A decision procedure for a fragment quantifier-free separation logic containing negation, separation star and magic wand is implemented and can be composed with other decision procedures supported by CVC4. For details see [http://homepage.divms.uiowa.edu/~ajreynol/atva16.pdf A Decision Procedure for Separation Logic in SMT].
* Sets
** Adaptation of tableau-based decision procedure described [http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.10.5176 here].
* Strings
** Original approach described in our [http://www.cs.nyu.edu/~barrett/pubs/LRT+14.pdf CAV 2014 paper: A DPLL(T) Theory Solver for a Theory of Strings and Regular Expressions].
** Decision procedure for regular memberships with length [http://homepage.cs.uiowa.edu/~ajreynol/frocos15.pdf].
* Uninterpreted functions
** UF (without cardinality) is handled in a manner inspired by [http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.70.1745 Simplify's tech report].
** UF + cardinality is described [http://www.divms.uiowa.edu/~ajreynol/pres-fmf12.pdf this presentation] and is used for finite model finding.

=History of CVC=

[[File:svc.gif|thumb|border|100px|The SVC logo.]]
[[File:cvc3_logo.jpg|thumb|border|100px|The CVC3 logo.]]
[[File:cvc3_night_logo.png|thumb|border|100px|The CVC3 "by night" logo, used for nightly builds and regressions.]]
[[File:cvc3cvc4.png|thumb|border|100px|An early CVC4 logo.]]

The Cooperating Validity Checker series has a long history. The
Stanford Validity Checker (SVC) came first in 1996, incorporating
theories and its own SAT solver. Its successor, the Cooperating
Validity Checker (CVC), had a more optimized internal design, produced
proofs, used the Chaff SAT solver, and featured a number of usability
enhancements. Its name comes from the cooperative nature of decision
procedures in Nelson-Oppen theory combination, which share amongst
each other equalities between shared terms. CVC Lite, first made
available in 2003, was a rewrite of CVC that attempted to make CVC
more flexible (hence the "lite") while extending the feature set: CVC
Lite supported quantifiers where its predecessors did not. CVC3 was a
major overhaul of portions of CVC Lite: it added better decision
procedure implementations, added support for using MiniSat in the
core, and had generally better performance.

[[File:cvc4-logo.png|thumb|border|100px|The CVC4 logo.]]
CVC4 is the new version, the fifth generation of this validity checker
line that is now celebrating sixteen years of heritage. It represents
a complete re-evaluation of the core architecture to be both
performant and to serve as a cutting-edge research vehicle for the
next several years. Rather than taking CVC3 and redesigning problem
parts, we've taken a clean-room approach, starting from scratch.
Before using any designs from CVC3, we have thoroughly scrutinized,
vetted, and updated them. Many parts of CVC4 bear only a superficial
resemblance, if any, to their correspondent in CVC3.

However, CVC4 is fundamentally similar to CVC3 and many other modern
SMT solvers: it is a DPLL(T) solver, with a SAT solver at its core and
a delegation path to different decision procedure implementations,
each in charge of solving formulas in some background theory.

The re-evaluation and ground-up rewrite was necessitated, we felt, by
the performance characteristics of CVC3. CVC3 has many useful
features, but some core aspects of the design led to high memory use,
and the use of heavyweight computation (where more nimble engineering
approaches could suffice) makes CVC3 a much slower prover than other
tools. As these designs are central to CVC3, a new version was
preferable to a selective re-engineering, which would have ballooned
in short order.

About CVC4

2017-01-27T00:14:56Z

Clark Barrett: /* Web site */

CVC4 is an automatic theorem prover for [http://en.wikipedia.org/wiki/Satisfiability_Modulo_Theories Satisifiability Modulo Theories (SMT)] (for a more formal introduction to SMT see the following book chapter [https://cs.nyu.edu/~barrett/pubs/BSST09.pdf Satisfiability Modulo Theories] ). Technically, it is an automated validity checker for a many-sorted (i.e., typed) first-order logic with built-in theories.
It can be used to prove the validity (or, dually, the satisfiability) of a formula with respect to several built-in logical theories and their combination.

CVC4 currently has support for the following theories:
* equality over free (aka uninterpreted) function and predicate symbols
* real and integer linear arithmetic
* bit-vectors
* arrays
* tuples
* records
* user-defined inductive [[Datatypes|datatypes]]
* [[Strings|strings]]
* [[Sets|finite sets]]
* [[Separation Logic|separation logic]]

CVC4 has a wide variety of features including:

* support for quantifiers through heuristic instantiation;
* an interactive text-based interface;
* a rich [http://church.cims.nyu.edu/cvc4-builds/documentation/public/latest/ C++ API] for embedding in other systems;
* model generation abilities;
* source compatibility with much of the CVC3 API via a "compatibility library";
* essentially no limit on its use for research or commercial purposes (see [http://church.cims.nyu.edu/cvc4-builds/documentation/public/latest-unstable/copying.html license]).

=Web site=

For more information and the latest news about CVC4, visit the [http://cvc4.cs.stanford.edu CVC4 web site].

=Decision Procedures=
* Architecture
** See the [http://dl.acm.org/citation.cfm?id=2032319 CVC4 tool paper].
* Arithmetic
** CVC4 solves linear real arithmetic using an implementation of [http://link.springer.com/chapter/10.1007%2F11817963_11? Simplex for DPLL(T)]. For a more complete introduction see the [http://yices.csl.sri.com/sri-csl-06-01.pdf tech report].
** The linear arithmetic module includes heuristics from [http://eprints-phd.biblio.unitn.it/166/2/thesis.pdf Section 2.5 of Alberto Griggio's thesis] and a few currently unpublished ones.
** Integers are currently handled by first solving the real relaxation of the constraints, and then using a combination of [http://www.cs.wm.edu/~idillig/cav2009.pdf Cuts from Proofs] and branching to ensure integer solutions. This approach and the equational solver used are described in [https://es.fbk.eu/people/griggio/papers/jsat12.pdf A Practical Approach to Satisfiability Modulo Linear Integer Arithmetic].
** A technical report is planned to explain a number of small details and extensions including analysis to improve simplex's conflicts, handling disequalities, supporting model generation in CVC4's combination framework, heuristically propagating equalities over sharing terms, tableau row based propagation, and terminating simplex with unknown.
** Non-linear arithmetic support is currently rudimentary to non-existent. In CVC4 v1.0, non-linearity is handled by abstracting monomials as unique new variables. We plan on implementing [http://cs.nyu.edu/~dejan/papers/jovanovic-ijcar2012.pdf Solving Non-Linear Arithmetic] this spring.
* Arrays
** Arrays are implemented in a manner inspired by the [http://research.microsoft.com/en-us/um/people/leonardo/files/fmcad09.pdf Generalized, efficient array decision procedures] paper with a few major modifications.
* Bitvectors
** Bitvectors is implemented primarily via a lazy schema for bitblasting. See [http://eprints-phd.biblio.unitn.it/345/ Anders Franzen's thesis chapter 3].
* Combination
** Theory combination is based on the care graph framework described in both [http://cs.nyu.edu/~dejan/papers/jovanovic-fmsd2012.pdf Being careful about theory combination] and [http://cs.nyu.edu/~dejan/papers/jovanovic-frocos2011.pdf Sharing is Caring: Combination of Theories].
* Datatypes
** CVC4 implements [http://homepage.cs.uiowa.edu/~tinelli/papers/BarST-JSAT-07.pdf An Abstract Decision Procedure for a Theory of Inductive Data Types].
** This procedure has been extended to incorporate coinductive datatypes [http://homepage.cs.uiowa.edu/~ajreynol/cade15.pdf].
* Quantifiers
** E-matching and conflict-based quantifier instantiation [http://homepage.cs.uiowa.edu/~ajreynol/fmcad14.pdf].
** Finite model finding [http://homepage.cs.uiowa.edu/~ajreynol/thesis.pdf].
** Techniques for finding counterexamples for conjectures in the presence of recursive functions [http://homepage.cs.uiowa.edu/~ajreynol/ijcar16a.pdf].
** Automated induction for datatypes [http://homepage.cs.uiowa.edu/~ajreynol/vmcai15.pdf].
** A decision procedure for quantified linear arithmetic with one alternation [http://homepage.cs.uiowa.edu/~ajreynol/report-inst-la15.pdf].
** Support for syntax-guided synthesis, as described in [http://homepage.cs.uiowa.edu/~ajreynol/cav15a.pdf].
* SAT Solver
** The main sat solver is based on [http://minisat.se/ minisat v2.2.0].
** Additionally, we (optionally, and enabled by default for certain theories) use non-clausal analysis to cut down search space of minisat. For more details see the article [http://cs.nyu.edu/~kshitij/articles/cvc4-branching-heuristic.pdf A branching heuristic in CVC4].
* Separation Logic
** A decision procedure for a fragment quantifier-free separation logic containing negation, separation star and magic wand is implemented and can be composed with other decision procedures supported by CVC4. For details see [http://homepage.divms.uiowa.edu/~ajreynol/atva16.pdf A Decision Procedure for Separation Logic in SMT].
* Sets
** Adaptation of tableau-based decision procedure described [http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.10.5176 here].
* Strings
** Original approach described in our [http://www.cs.nyu.edu/~barrett/pubs/LRT+14.pdf CAV 2014 paper: A DPLL(T) Theory Solver for a Theory of Strings and Regular Expressions].
** Decision procedure for regular memberships with length [http://homepage.cs.uiowa.edu/~ajreynol/frocos15.pdf].
* Uninterpreted functions
** UF (without cardinality) is handled in a manner inspired by [http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.70.1745 Simplify's tech report].
** UF + cardinality is described [http://www.divms.uiowa.edu/~ajreynol/pres-fmf12.pdf this presentation] and is used for finite model finding.

=History of CVC=

[[File:svc.gif|thumb|border|100px|The SVC logo.]]
[[File:cvc3_logo.jpg|thumb|border|100px|The CVC3 logo.]]
[[File:cvc3_night_logo.png|thumb|border|100px|The CVC3 "by night" logo, used for nightly builds and regressions.]]
[[File:cvc3cvc4.png|thumb|border|100px|An early CVC4 logo.]]

The Cooperating Validity Checker series has a long history. The
Stanford Validity Checker (SVC) came first in 1996, incorporating
theories and its own SAT solver. Its successor, the Cooperating
Validity Checker (CVC), had a more optimized internal design, produced
proofs, used the Chaff SAT solver, and featured a number of usability
enhancements. Its name comes from the cooperative nature of decision
procedures in Nelson-Oppen theory combination, which share amongst
each other equalities between shared terms. CVC Lite, first made
available in 2003, was a rewrite of CVC that attempted to make CVC
more flexible (hence the "lite") while extending the feature set: CVC
Lite supported quantifiers where its predecessors did not. CVC3 was a
major overhaul of portions of CVC Lite: it added better decision
procedure implementations, added support for using MiniSat in the
core, and had generally better performance.

[[File:cvc4-logo.png|thumb|border|100px|The CVC4 logo.]]
CVC4 is the new version, the fifth generation of this validity checker
line that is now celebrating sixteen years of heritage. It represents
a complete re-evaluation of the core architecture to be both
performant and to serve as a cutting-edge research vehicle for the
next several years. Rather than taking CVC3 and redesigning problem
parts, we've taken a clean-room approach, starting from scratch.
Before using any designs from CVC3, we have thoroughly scrutinized,
vetted, and updated them. Many parts of CVC4 bear only a superficial
resemblance, if any, to their correspondent in CVC3.

However, CVC4 is fundamentally similar to CVC3 and many other modern
SMT solvers: it is a DPLL(T) solver, with a SAT solver at its core and
a delegation path to different decision procedure implementations,
each in charge of solving formulas in some background theory.

The re-evaluation and ground-up rewrite was necessitated, we felt, by
the performance characteristics of CVC3. CVC3 has many useful
features, but some core aspects of the design led to high memory use,
and the use of heavyweight computation (where more nimble engineering
approaches could suffice) makes CVC3 a much slower prover than other
tools. As these designs are central to CVC3, a new version was
preferable to a selective re-engineering, which would have ballooned
in short order.

Building CVC4 from source

2016-04-22T18:07:34Z

Clark Barrett:

To compile CVC4 from a source package you must do the following:
# Install antlr
# Configure cvc4
# Compile cvc4
# Install cvc4 [optional]

To do so run the following commands in the CVC4 directory:

cd contrib
./get-antlr-3.4
cd ..
./configure --with-antlr-dir=`pwd`/antlr-3.4 ANTLR=`pwd`/antlr-3.4/bin/antlr3
make
make check [recommended]
make install [optional]

Below are more details instructions about the various dependencies and options.

=Common make Options=
* "''make install''" will install into the "--prefix" option you gave to
the configure script (''/usr/local'' by default).
./configure --prefix=~/install_targets/cvc4 ...
make install
* '''You should run "''make check''"''' before installation to ensure that CVC4 has been
built correctly. In particular, GCC version 4.5.1 seems to have a
bug in the optimizer that results in incorrect behavior (and wrong
results) in many builds. This is a known problem for Minisat, and
since Minisat is at the core of CVC4, a problem for CVC4. "''make check''"
easily detects this problem (by showing a number of FAILed test cases).
It is ok if the unit tests aren't run as part of "''make check''", but all
system tests and regression tests should pass without incident.
* To build API documentation, use "''make doc''". Documentation is produced
under ''builds/doc/'' but is not installed by "''make install''".

Examples and tutorials are not installed with "''make install''." See [[#Examples_and_tutorials_are_not_built_or_installed|below]].

For more information about the build system itself (probably not
necessary for casual users), see the [[#Appendix:_Build_architecture|Appendix]] at the bottom of this
file.

=Common configure Options=
*'''--prefix=PREFIX''' install architecture-independent files in PREFIX (by default /usr/local)
*'''--with-build={production,debug,default,competition}'''
*'''--with-antlr-dir=PATH'''
*'''--with-cln'''/'''--with-gmp''' selects the numbers package to use by default ([[#Optional requirements]])
*'''--enable-static-binary''' build a fully statically-linked binary. (This is recommended for Mac OS X users that want to be able to use gdb.)
*'''ANTLR=PATH''' location of the antlr3 script
*'''--with-boost=DIR''' installation location of the boost libraries (most users will not need this)

See '''./configure --help''' for more.

=Build dependencies=

The following tools and libraries are required to run CVC4. Versions
given are minimum versions; more recent versions should be compatible.

*'''GNU C and C++''' (gcc and g++), reasonably recent versions
*'''GNU Make'''
*'''GNU Bash'''
*'''GMP v4.2''' (GNU Multi-Precision arithmetic library)
*'''libantlr3c v3.2 or v3.4''' (ANTLR parser generator C support library)
*'''The Boost C++ base libraries'''
*'''MacPorts''' [highly recommended if on a Mac; see [[#MacPorts]]]

The hardest to obtain and install is the libantlr3c requirement, and
is explained [[#Installing libantlr3c: ANTLR parser generator C support library|next]].

If "make" is non-GNU on your system, make sure to invoke "gmake" (or
whatever GNU Make is installed as). If your usual shell is not Bash,
the configure script should auto-correct this. If it does not, you'll
see strange shell syntax errors, and you may need to explicitly set
SHELL or CONFIG_SHELL to the location of bash on your system.

==Installing libantlr3c: ANTLR parser generator C support library==

For libantlr3c, you can use the convenience script in
''contrib/get-antlr-3.4'' in the source distribution---this will download, patch, compile and install
libantlr3c into your cvc4 directory as ''cvc4/antlr-3.4/''.
cd contrib
./get-antlr-3.4

CVC4 must be configured with the antlr library installation directory, '''--with-antlr-dir''', and an antlr executable script file, '''ANTLR'''. If libantlr3c was installed via get-antlr-3.4, the following configure line should suffice for CVC44
./configure --with-antlr-dir=`pwd`/antlr-3.4 ANTLR=`pwd`/antlr-3.4/bin/antlr3

For 64 bit machines, libantlr3c needs to be configured with 64 bit explicitly
./configure --enable-64bit ...
The get-antlr-3.4 script makes a guess at whether the machine is 64 bit and adds the appropriate flag.
To force the script to compile 32 bit:
MACHINE_TYPE="x86" ./get-antlr-3.4
To force the script to compile 64 bit:
MACHINE_TYPE="x86_64" ./get-antlr-3.4

For a longer discussion, instructions for manual installation, and more in depth troubleshooting, see [[Developer's Guide#ANTLR3]].

==MacPorts==

On a Mac, it is '''highly''' recommended that you use MacPorts (see
http://www.macports.org/). Doing so is easy. Then, simply run the
script ''contrib/mac-build'', which installs a few ports from the MacPorts
repository, then compiles and installs antlr3c using the ''get-antlr-3.4''
script. The mac-build script should set you up
with all requirements, and will tell you how to configure CVC4 when it
completes successfully.

==Installing the Boost C++ base libraries==

A Boost package is available on most Linux distributions; check yours
for a package named something like libboost-dev or boost-devel. There
are a number of additional Boost packages in some distributions, but
this "basic" one should be sufficient for building CVC4.

Should you want to install Boost manually, or to learn more about the
Boost project, please visit http://www.boost.org/.

==Building on FreeBSD==
CVC4's build process currently makes extensive use of bash, sed, and other common *nix tools. It has recently come to our attention by Kostas Oikonomou that some of these are problematic outside of the GNU toolkit. Users of systems that do not assume GNU implementation like FreeBSD may experience issues building CVC4. Until we have a more permanent solution, here are Kostas Oikonomou's notes on how to modify CVC4's source to get it to compile on such systems:

0. export CONFIG_SHELL=/usr/local/bin/bash
Edit 'configure' to set # !/usr/local/bin/bash

1. configure --prefix=/opt/cvc4 --enable-gpl --with-readline CC=clang CXX=clang++ LDFLAGS=-L/usr/local/lib CPPFLAGS=-I/usr/local/include

2a. Edit src/mksubdirs, src/theory/{mkrewriter,mktheorytraits} to change
!#/bin/bash to !#/usr/local/bin/bash
Similarly for src/base/{mktags,mktagheaders}, src/expr/{mkexpr,mkkind,mkmetakind}.

2b. src/options/mkoptions: same as above, plus all occurrences of expr -> gexpr.

3. Edit src/main/util.cpp:

stack_t ss;
ss.ss_sp = (char *) malloc(SIGSTKSZ);

4. make -j2

5. Edit test/regress/run_regression to fix the bash business.

6. make check

7. sudo gmake install

=Optional requirements=

None of these is required, but can improve CVC4 as described below:

*'''Optional: SWIG 2.0.x''' (Simplified Wrapper and Interface Generator)
*'''Optional: CLN v1.3 or newer''' (Class Library for Numbers)
*'''Optional: CUDD v2.4.2 or newer''' (Colorado University Decision Diagram package)
*'''Optional: GNU Readline library''' (for an improved interactive experience)
*'''Optional: The Boost C++ threading library''' (libboost_thread)
*'''Optional: CxxTest unit testing framework'''

SWIG is necessary to build the Java API (and of course a JDK is
necessary, too). SWIG 1.x won't work; you'll need 2.0, and the more
recent the better. On Mac, we've seen SWIG segfault when generating
CVC4 language bindings; version 2.0.8 or higher is recommended to
avoid this. See [[#Language_bindings|Language bindings]] below for build instructions.

CLN is an alternative multiprecision arithmetic package that can offer
better performance and memory footprint than GMP. CLN is covered by
the GNU General Public License, version 3; so if you choose to use
CVC4 with CLN support, you are licensing CVC4 under that same license.
(Usually CVC4's license is more permissive than GPL is; see the file
COPYING in the CVC4 source distribution for details.) Please visit
http://www.ginac.de/CLN/ for more details about CLN.

CUDD is a decision diagram package that changes the behavior of the
CVC4 arithmetic solver in some cases; it may or may not improve the
arithmetic solver's performance. See [[#Building_with_CUDD_(optional)|below]] for instructions on
obtaining and building CUDD.

The GNU Readline library is optionally used to provide command
editing, tab completion, and history functionality at the CVC prompt
(when running in interactive mode). Check your distribution for a
package named "libreadline-dev" or "readline-devel" or similar.

The Boost C++ threading library (often packaged independently of the
Boost base library) is needed to run CVC4 in "portfolio"
(multithreaded) mode. Check your distribution for a package named
"libboost-thread-dev" or similar.

CxxTest is necessary to run CVC4's unit tests (included with the
distribution). Running these is not really required for users of
CVC4; "make check" will skip unit tests if CxxTest isn't available,
and go on to run the extensive system- and regression-tests in the
source tree. However, if you're interested, you can download CxxTest
at http://cxxtest.com/ .

==Building with custom CLN installations (optional)==

One option for compiling against a custom CLN installation is to provide the CLN_LIBS and CLN_CFLAGS arguments at configuration. Supposing you installed cln into CLN_DIR the following provides the necessary locations of the header and linking information.
./configure <other arguments> --with-cln CLN_LIBS="-L<CLN_DIR>/lib -lcln" \
CLN_CFLAGS="-I<CLN_DIR>/include"

==Building with CUDD (optional)==

CUDD, if desired, must be installed delicately. The CVC4 configure
script attempts to auto-detect the locations and names of CUDD headers
and libraries the way that the Fedora RPMs install them, the way that
our NYU-provided Debian packages install them, and the way they exist
when you download and build the CUDD sources directly. If you install
from Fedora RPMs or our Debian packages, the process should be
completely automatic, since the libraries and headers are installed in
a standard location. If you download the sources yourself, you need
to build them in a special way. Fortunately, the
"contrib/build-cudd-2.4.2-with-libtool.sh" script in the CVC4 source
tree does exactly what you need: it patches the CUDD makefiles to use
libtool, builds the libtool libraries, then reverses the patch to
leave the makefiles as they were. Once you run this script on an
unpacked CUDD 2.4.2 source distribution, then CVC4's configure script
should pick up the libraries if you provide
--with-cudd-dir=/PATH/TO/CUDD/SOURCES.

If you want to force linking to CUDD, provide --with-cudd to the
configure script; this makes it a hard requirement rather than an
optional add-on.

The NYU-provided Debian packaging of CUDD 2.4.2 and CUDD 2.5.0 are
here (along with the CVC4 Debian packages):

deb http://cvc4.cs.nyu.edu/debian/ unstable/

On Debian (and Debian-derived distributions like Ubuntu), you only
need to drop that one line in your /etc/apt/sources.list file, then install with your favorite package manager.

The Debian source package "cudd", available from the same repository,
includes a diff of all changes made to cudd makefiles.

=Language bindings=

There are several options available for using CVC4 from the API.

First, CVC4 offers a complete and flexible API for manipulating
expressions, maintaining a stack of assertions, and checking
satisfiability, and related things. The C++ libraries (libcvc4.so and
libcvc4parser.so) and required headers are installed normally via a
"make install". This API is also available from Java (via CVC4.jar
and libcvc4jni.so) by configuring with --enable-language-bindings=java.
You'll also need SWIG 2.0 installed (and you might need to help
configure find it if you installed it in a nonstandard place with
--with-swig-dir=/path/to/swig/installation). You may also need to
give the configure script the path to your Java headers (in
particular, jni.h). You might do so with (for example):

./configure --enable-language-bindings=java \
JAVA_CPPFLAGS=-I/usr/lib/jvm/java-6-openjdk-amd64/include

There is also a "C++ compatibility API" (''#include <cvc4/cvc3_compat.h>''
and link against libcvc4compat.so) that attempts to maintain
source-level backwards-compatibility with the CVC3 C++ API. The
compatibility library is built by default, and
''--enable-language-bindings=java'' enables the Java compatibility library
(CVC4compat.jar and libcvc4compatjni.so).
''--enable-language-bindings=c'' enables the C compatibility library
(''#include <cvc4/bindings/compat/c/c_interface.h>'' and link against
libcvc4bindings_c_compat.so), and if you want both C and Java
bindings, use ''--enable-language-bindings=c,java''. These compatibility
language bindings do NOT require SWIG.

The ''examples/'' directory in the source distribution includes some basic examples (the "simple vc"
and "simple vc compat" family of examples) of all these interfaces.

In principle, since we use SWIG to generate the native Java API, we
could support other languages as well. However, using CVC4 from other
languages is not supported, nor expected to work, at this time. If
you're interested in helping to develop, maintain, and test a language
binding, please contact us via the users' mailing list at
cvc-users@cs.nyu.edu.

=Building CVC4 from a repository checkout=

The following tools and libraries are additionally required to build
CVC4 from from a repository checkout rather than from a prepared
source tarball.

*'''Automake v1.11'''
*'''Autoconf v2.61'''
*'''Libtool v2.2'''
*'''ANTLR3 v3.2 or v3.4'''
*'''Java Development Kit''' ([http://www.antlr.org/wiki/pages/viewpage.action?pageId=728 required for ANTLR3])

First, use "''./autogen.sh''" to create the configure script. Then
proceed as normal for any distribution tarball. The parsers are
pre-generated for the tarballs, but don't exist in the repository; hence the extra ANTLR3 and JDK requirements to
generate the source code for the parsers, when building from the
repository.

=Examples and tutorials are not built or installed=

Examples are not built by "''make''" or "''make install''". See
''examples/README'' in the source distribution for information on what to find in the ''examples/''
directory, as well as information about building and installing them.

=Appendix: Build architecture=

The build system is generated by automake, libtool, and autoconf. It
is somewhat nonstandard, though, which (for one thing) requires that
GNU Make be used. If you ./configure in the top-level source
directory, the objects will actually all appear in
builds/${arch}/${build_id}. This is to allow multiple, separate
builds in the same place (e.g., an assertions-enabled debugging build
alongside a production build), without changing directories at the
shell. The "current" build is maintained, and you can still use
(e.g.) "make -C src/main" to rebuild objects in just one subdirectory.

You can also create your own build directory inside or outside of the
source tree and configure from there. All objects will then be built
in that directory, and you'll ultimately find the "cvc4" binary in
src/main/, and the libraries under src/ and src/parser/.

Tutorials

2015-12-23T16:25:29Z

Clark Barrett:

=CVC language=

<coming soon...>

==Finding these examples==

Except where noted below, tutorial code appearing in this section is kept in the <code>examples/cvc</code> directory of the CVC4 source distribution. However, tutorial material on this page might be more recent than your CVC4 download. Please refer to the [http://cvc4.cs.nyu.edu/builds/src/ most recent nightly build] for the most recent tutorial code.

=SMT-LIB=

We recommend [http://smtlib.github.io/jSMTLIB/SMTLIBTutorial.pdf David Cok's excellent tutorial on SMT-LIB]. When running examples from this tutorial, we recommend using CVC4's ''--smtlib-strict'' command line option, which enters a stricter compliance mode.

CVC4 should be compliant with [http://www.smtlib.org/ the standard], and thus also with David Cok's tutorial, except for some unsupported functionality as noted in the [[SMT-LIB_Compliance|SMT-LIB compliance section of this wiki]]. If you find something that you believe to be nonconformant, please [http://cvc4.cs.nyu.edu/bugs/ report it as a bug].

=C++ API=
* helloworld : a simple example to start off with
* linear_arith : real and integer linear arithmetic
* combination : integer and uninterpreted function example
* bitvectors : bit-vectors example
* bitvectors_and_arrays : integer and uninterpreted function example
* quantifiers
* strings : strings example

==Finding and compiling these examples==

Except where noted below, tutorial code appearing in this section is kept in the <code>examples/api</code> directory of the CVC4 source distribution. However, tutorial material on this page might be more recent than your CVC4 download. Please refer to the [http://cvc4.cs.nyu.edu/builds/src/ most recent nightly build] for the most recent tutorial code.

To compile everything in the <code>examples/</code> directory, you can issue the command <code>make examples</code> from the top-level of the source distribution. This will first build CVC4 (if it isn't already built) and then the examples. Some examples from the directory may not be compiled, if (for instance) you haven't built with support for Java, or if you haven't built with support for the compatibility interface; however, all native C++ API examples should be, and those are the only ones appearing in this section.

Note that the example API code in the <code>examples/</code> directory is intended to be compiled and linked against a CVC4 library built from the source tree. If you try to compile them yourself, against a CVC4 library installed (for example) in <code>/usr</code>, you may find that certain headers cannot be found. There is an easy fix. CVC4 #includes like the following:
#include "expr/expr.h"
should be rewritten to this form:
#include <cvc4/expr/expr.h>
or, most likely, you can remove all such #includes and replace with this single one:
#include <cvc4/cvc4.h>

The example code is not installed by <code>make install</code>.

==helloworld==
To get used to CVC4, let us go through the following example line-by-line:
#include <iostream>
#include <cvc4/cvc4.h>
using namespace CVC4;
int main() {
ExprManager em;
Expr helloworld = em.mkVar("Hello World!", em.booleanType());
SmtEngine smt(&em);
std::cout << helloworld << " is " << smt.query(helloworld) << std::endl;
return 0;
}
(The example can be found in examples/api/helloworld.cpp.)

First we include the standard <iostream> library, and next we include the public interface for CVC4:
#include <cvc4/cvc4.h>
<code>cvc4/cvc4.h</code> includes definitions for all of the classes we'll need including ExprManager, Expr and SmtEngine. All of CVC4 lives in the namespace CVC4 and to save a bit of typing let's use the namespace. Now construct a new ExprManager named em.
ExprManager em;
ExprManagers are in charge of constructing and managing symbolic expressions in CVC4. We then construct the expression Expr helloworld.
Expr helloworld = em.mkVar("Hello World!", em.booleanType());
helloworld is a symbolic variable with the name "Hello World!" and the type boolean. Note that we ask em to both make the variable and to get em.booleanType(). We now make the main driver for CVC4 reasoning the SmtEngine smt using em as its ExprManager.
SmtEngine smt(&em);
Finally we print helloworld and query the SmtEngine if the boolean variable helloworld is valid.
std::cout << helloworld << " is " << smt.query(helloworld) << std::endl;

We can compile the program helloworld from helloworld.cpp by linking against <code>-lcvc4</code>
$ g++ helloworld.cpp -o helloworld -lcvc4
$ ./helloworld
Hello World! is invalid
This should all work if libcvc4 was installed using <code>make install</code>. If you used <code>make install</code> to a non-standard location, look at instructions for [[Build Problems#make_install_to_a_non-standard_prefix|using non-standard prefix]]. If you insist on not-using make, look at instructions for [[Build_Problems#libcvc4_without_make_install]].

==linear_arith==
With helloworld under our belt, let's try to work through the more advanced examples/api/linear_arith.cpp . In this example, we'll try to show that for <math> x \in \mathbb{Z}, y \in \mathbb{R}</math> if <math>x \geq 3 y, x \leq y, -2 < x </math> then <math> \max y - x = \frac{2}{3}</math>.
We can do this by first showing that these assumptions entail <math> y - x \leq \frac{2}{3}</math>, and then showing that <math> y - x = \frac{2}{3}</math> is consistent with the assumptions.

We use the same basic skeleton of includes/namespaces/main as before. We make an ExprManager and SmtEngine as before.
ExprManager em;
SmtEngine smt(&em);
We now set on option on the SmtEngine to enable incremental or multiple query solving, which we will take advantage of.
smt.setOption("incremental", SExpr("true")); // Enable incremental solving
We get the Types real and integer from em, and we make x and y variables of the respective types.
Type real = em.realType();
Type integer = em.integerType();
Expr x = em.mkVar("x", integer);
Expr y = em.mkVar("y", real);
We now make Exprs for the 3 Rational constants in the formulas using [[Expr#Constants|em.mkConst()]]:
Expr three = em.mkConst(Rational(3));
Expr neg2 = em.mkConst(Rational(-2));
Expr two_thirds = em.mkConst(Rational(2,3));
We will now make the intermediate terms using mkExpr.
Expr three_y = em.mkExpr(kind::MULT, three, y);
Expr diff = em.mkExpr(kind::MINUS, y, x);
The first argument to mkExpr is a Kind. Kind is an enum covering all of the various expressions that CVC4 can make. Common operators have fairly standard ALL_CAPS names, such as LEQ, MINUS, AND, BITVECTOR_NAND, and so on. Kind's are in the namespace CVC4::kind. For more information see [[Expr#Constants]].

Using these intermediate terms, we make the following formulas in the same way we made terms.
Expr x_geq_3y = em.mkExpr(kind::GEQ, x, three_y);
Expr x_leq_y = em.mkExpr(kind::LEQ, x, y);
Expr neg2_lt_x = em.mkExpr(kind::LT, neg2, x);

We now assert the assumptions in the SmtEngine:
Expr assumptions =
em.mkExpr(kind::AND, x_geq_3y, x_leq_y, neg2_lt_x);
smt.assertFormula(assumptions);
Alternatively, we could have asserted x_geq_3y, x_leq_y, and neg2_lt_x individually. It is worth pointing out that these are asserted at decision level 0. Modern DPLL(T) solvers are stack based. We can push the stack(), add assertions and then pop() assertions off of the stack.

We can now prove that <math> y - x \leq \frac{2}{3}</math>. We first make an Expr for this literal. We now push() the SmtEngine, query the SmtEngine for the validity of the literal given the assumptions, and pop() the SmtEngine.
smt.push();
Expr diff_leq_two_thirds = em.mkExpr(kind::LEQ, diff, two_thirds);
cout << "Prove that " << diff_leq_two_thirds << " with CVC4." << endl;
cout << "CVC4 should report VALID." << endl;
cout << "Result from CVC4 is: " << smt.query(diff_leq_two_thirds) << endl;
smt.pop();

It is worth noting that the push() and pop() are not strictly needed in order to not effect context level 0. This is because SmtEngine guards query(phi), checkSat(phi) with internal pushes and pops so phi does not effect the current context. It is needed below; however, as the second lemma is proved in the following fashion:
smt.push();
Expr diff_is_two_thirds = em.mkExpr(kind::EQUAL, diff, two_thirds);
smt.assertFormula(diff_is_two_thirds);
cout << "Show that the asserts are consistent with " << endl;
cout << diff_is_two_thirds << " with CVC4." << endl;
cout << "CVC4 should report SAT." << endl;
cout << "Result from CVC4 is: " << smt.checkSat(em.mkConst(true)) << endl;
smt.pop();

== bitvectors ==

In this example we will prove the equivalence of three different pieces of code. The example is adapted from the book [http://www.hackersdelight.org/ A Hacker's Delight] by Henry S. Warren. The code can be found in /examples/api/bitvectors.cpp.
Given a variable x, that can only have one of two values: a or b, we want to assign to x a value different than the current one. For example if x was equal to a we want to assign to it b. The most straightforward implementation of this is the following:

if (x == a) x = b;
else x = a;

or more concise:

x = x == a ? b : a; // (0)

However, the following two pieces of code provide a more efficient implementation:

x = a + b - x; // (1)

or

x = a ^ b ^ x; // (2)

We will encode the problem using the theory of bit-vectors and check that the three implementations are indeed equivalent.
Let's analyze the code in bitvector.cpp line by line. Because we are interested in checking two different problems we will turn on incremental mode and specify the logic, to increase efficiency of solving:

smt.setOption("incremental", true); // Enable incremental solving
smt.setLogic("QF_BV"); // Set the logic

To make a bit-vector variable we must first make a bit-vector type. The factory method that constructs a bit-vector type requires the width of the bit-vector as an argument. In our example we will assume we are modeling a 32-bit machine:

// Creating a bit-vector type of width 32
Type bitvector32 = em.mkBitVectorType(32);

Creating variables and expressions follows the same pattern as in previous examples. We will first create the input variables x, a and b:

// Variables
Expr x = em.mkVar("x", bitvector32);
Expr a = em.mkVar("a", bitvector32);
Expr b = em.mkVar("b", bitvector32);

The first assumption constraints x to be equal to either a or b:

// First encode the assumption that x must be equal to a or b
Expr x_eq_a = em.mkExpr(kind::EQUAL, x, a);
Expr x_eq_b = em.mkExpr(kind::EQUAL, x, b);
Expr assumption = em.mkExpr(kind::OR, x_eq_a, x_eq_b);

Because we will need this assumption to prove all following properties we can just assert it to the solver in the current context.
// Assert the assumption
smt.assertFormula(assumption);

To model the semantics of the instructions we need to introduce a new variable for x for each program state. Here new_x will represent the value of x after executing code (0). We will use new_x_ to represent the value of x after executing code (1) first, and then after executing code (2).

// Introduce a new variable for the new value of x after assignment.
Expr new_x = em.mkVar("new_x", bitvector32); // x after executing code (0)
Expr new_x_ = em.mkVar("new_x_", bitvector32); // x after executing code (1) or (2)

We can encode the assignment in code (0) in a straightforward manner by using a term-ITE (if-then-else) expression which captures the semantics of the C++ (cond ? val1 : val2).

// new_x = x == a ? b : a;
Expr ite = em.mkExpr(kind::ITE, x_eq_a, b, a);
Expr assignment0 = em.mkExpr(kind::EQUAL, new_x, ite);

// Assert the encoding of code (0)
cout << "Asserting " << assignment0 << " to CVC4 " << endl;
smt.assertFormula(assignment0);

Because the assertions we have so far are the only ones that will be used in both queries we can now push a new context:

cout << "Pushing a new context." << endl;
smt.push();

Next, we move to encoding the semantics of code (1) in a similar manner as before:

// Encoding code (1)
// new_x_ = a xor b xor x
Expr a_xor_b_xor_x = em.mkExpr(kind::BITVECTOR_XOR, a, b, x);
Expr assignment1 = em.mkExpr(kind::EQUAL, new_x_, a_xor_b_xor_x);

// Assert encoding to CVC4 in current context;
cout << "Asserting " << assignment1 << " to CVC4 " << endl;
smt.assertFormula(assignment1);

And we check that the value of x after executing code (0) is the same as that after executing code (1):

Expr new_x_eq_new_x_ = em.mkExpr(kind::EQUAL, new_x, new_x_);
cout << " Querying: " << new_x_eq_new_x_ << endl;
cout << " Expect valid. " << endl;
cout << " CVC4: " << smt.query(new_x_eq_new_x_) << endl;

Note that we are using smt.query(f) which checks for the validity of the formula f under the current assumptions i.e. that checking whether the current assertions imply (not f) is unsat.
Now that we are done with checking the first equivalence, we can pop the context:

cout << " Popping context. " << endl;
smt.pop();

Note that poping the context will remove the assertion saying new_x_ = a xor b xor x.

We follow a similar pattern to check the second equivalence:

// Encoding code (2)
// new_x_ = a + b - x
Expr a_plus_b = em.mkExpr(kind::BITVECTOR_PLUS, a, b);
Expr a_plus_b_minus_x = em.mkExpr(kind::BITVECTOR_SUB, a_plus_b, x);
Expr assignment2 = em.mkExpr(kind::EQUAL, new_x_, a_plus_b_minus_x);

// Assert encoding to CVC4 in current context;
cout << "Asserting " << assignment2 << " to CVC4 " << endl;
smt.assertFormula(assignment2);

cout << " Querying: " << new_x_eq_new_x_ << endl;
cout << " Expect valid. " << endl;
cout << " CVC4: " << smt.query(new_x_eq_new_x_) << endl;

Here is another example (extract.cpp) that demonstrates how to use the extract operator:

ExprManager em;
SmtEngine smt(&em);
smt.setLogic("QF_BV"); // Set the logic

Type bitvector32 = em.mkBitVectorType(32);

Expr x = em.mkVar("a", bitvector32);

Expr ext_31_1 = em.mkConst(CVC4::BitVectorExtract(31,1));
Expr x_31_1 = em.mkExpr(ext_31_1, x);

Expr ext_30_0 = em.mkConst(CVC4::BitVectorExtract(30,0));
Expr x_30_0 = em.mkExpr(ext_30_0, x);

Expr ext_31_31 = em.mkConst(CVC4::BitVectorExtract(31,31));
Expr x_31_31 = em.mkExpr(ext_31_31, x);

Expr ext_0_0 = em.mkConst(CVC4::BitVectorExtract(0,0));
Expr x_0_0 = em.mkExpr(ext_0_0, x);

Expr eq = em.mkExpr(kind::EQUAL, x_31_1, x_30_0);
cout << " Asserting: " << eq << endl;
smt.assertFormula(eq);

Expr eq2 = em.mkExpr(kind::EQUAL, x_31_31, x_0_0);
cout << " Querying: " << eq2 << endl;
cout << " Expect valid. " << endl;
cout << " CVC4: " << smt.query(eq2) << endl;

==Sets==

If setting the logic, use "FS" to enable theory of sets.
smt.setLogic("QF_UFLIAFS");

To create a set type, call <code>mkSetType</code> in the <code>ExprManager</code>. It takes as argument the element type.
Type integer = em.integerType();
Type set = em.mkSetType(integer);

===Union and Intersection===

Verify union distributions over intersection. Checks the validity of (A union B) intersection C = (A intersection C) union (B intersection C) for all sets A, B, C of integers.
<pre>
Expr A = em.mkVar("A", set);
Expr B = em.mkVar("B", set);
Expr C = em.mkVar("C", set);

Expr unionAB = em.mkExpr(kind::UNION, A, B);
Expr lhs = em.mkExpr(kind::INTERSECTION, unionAB, C);

Expr intersectionAC = em.mkExpr(kind::INTERSECTION, A, C);
Expr intersectionBC = em.mkExpr(kind::INTERSECTION, B, C);
Expr rhs = em.mkExpr(kind::UNION, intersectionAC, intersectionBC);

Expr theorem = em.mkExpr(kind::EQUAL, lhs, rhs);

cout << "CVC4 reports: " << theorem << " is " << smt.query(theorem) << "." << endl;
</pre>

===EmptySet constant and Subset predicate===
An object of CVC4::EmptySet carries its type, which should be given at construction time. Note that this is the type of the set itself (so, pass the type set of integers, not integers).

Then, the empty set constant can be define using mkConst passing this CVC4::EmptySet object.
<pre>
Expr A = em.mkVar("A", set);
Expr emptyset = em.mkConst(EmptySet(set));

Expr theorem = em.mkExpr(kind::SUBSET, emptyset, A);

cout << "CVC4 reports: " << theorem << " is " << smt.query(theorem) << "." << endl;
</pre>
===Membership, singleton and producing models===

Remember to enable models (this should be done at the start, just after creating the smt engine).
smt.setOption("produce-models", true);

Find an element in {1, 2} intersection {2, 3}, if there is one.

<pre>
// Integer constants
Expr one = em.mkConst(Rational(1));
Expr two = em.mkConst(Rational(2));
Expr three = em.mkConst(Rational(3));

// Singleton sets for each of these constants
Expr singleton_one = em.mkExpr(kind::SINGLETON, one);
Expr singleton_two = em.mkExpr(kind::SINGLETON, two);
Expr singleton_three = em.mkExpr(kind::SINGLETON, three);

// Build bigger sets using union
Expr one_two = em.mkExpr(kind::UNION, singleton_one, singleton_two);
Expr two_three = em.mkExpr(kind::UNION, singleton_two, singleton_three);

Expr intersection = em.mkExpr(kind::INTERSECTION, one_two, two_three);
Expr x = em.mkVar("x", integer);
Expr e = em.mkExpr(kind::MEMBER, x, intersection);

Result result = smt.checkSat(e);
cout << "CVC4 reports: " << e << " is " << result << "." << endl;

// If the formula was satisfiable (which it should be here), get the value of x.
if(result == Result::SAT) {
cout << "For instance, " << smt.getValue(x) << " is a member." << endl;
}
</pre>

==Strings==

The example can be found in examples/api/strings.cpp

If setting the logic, use "S" to enable theory of strings.
smt.setLogic("S");

To create a string type, call <code>mkSetType</code> in the <code>ExprManager</code>.
Type string = em.stringType();

Make some string literals:
// std::string
std::string std_str_ab("ab");
// CVC4::String
CVC4::String cvc4_str_ab(std_str_ab);
CVC4::String cvc4_str_abc("abc");
// String constants
Expr ab = em.mkConst(cvc4_str_ab);
Expr abc = em.mkConst(CVC4::String("abc"));

Make some string variables:
Expr x = em.mkVar("x", string);
Expr y = em.mkVar("y", string);
Expr z = em.mkVar("z", string);

Make some string constraints:
// String concatenation: x.ab.y
Expr lhs = em.mkExpr(kind::STRING_CONCAT, x, ab, y);
// String concatenation: abc.z
Expr rhs = em.mkExpr(kind::STRING_CONCAT, abc, z);
// x.ab.y = abc.z
Expr formula1 = em.mkExpr(kind::EQUAL, lhs, rhs);
// Length of y: |y|
Expr leny = em.mkExpr(kind::STRING_LENGTH, y);
// |y| >= 0
Expr formula2 = em.mkExpr(kind::GEQ, leny, em.mkConst(Rational(0)));
// Regular expression: (ab[c-e]*f)|g|h
Expr r = em.mkExpr(kind::REGEXP_UNION,
em.mkExpr(kind::REGEXP_CONCAT,
em.mkExpr(kind::STRING_TO_REGEXP, em.mkConst(String("ab"))),
em.mkExpr(kind::REGEXP_STAR,
em.mkExpr(kind::REGEXP_RANGE, em.mkConst(String("c")), em.mkConst(String("e")))),
em.mkExpr(kind::STRING_TO_REGEXP, em.mkConst(String("f")))),
em.mkExpr(kind::STRING_TO_REGEXP, em.mkConst(String("g"))),
em.mkExpr(kind::STRING_TO_REGEXP, em.mkConst(String("h"))));
// String variables
Expr s1 = em.mkVar("s1", string);
Expr s2 = em.mkVar("s2", string);
// String concatenation: s1.s2
Expr s = em.mkExpr(kind::STRING_CONCAT, s1, s2);
// s1.s2 in (ab[c-e]*f)|g|h
Expr formula3 = em.mkExpr(kind::STRING_IN_REGEXP, s, r);

Make a query:
Expr q = em.mkExpr(kind::AND,
formula1,
formula2,
formula3);

Check the result:
Result result = smt.checkSat(q);
std::cout << "CVC4 reports: " << q << " is " << result << "." << std::endl;
if(result == Result::SAT) {
std::cout << " x = " << smt.getValue(x) << std::endl;
std::cout << " s1.s2 = " << smt.getValue(s) << std::endl;
}

=Java API=
=Parallel Solving=
===Obtaining===
* Download a statically built binary supporting parallel solving: [http://cvc4.cs.nyu.edu/cvc4-builds/portfolio-x86_64-linux-opt Optimized build]
* If compiling from source, specify by '''--with-portfolio''' option to the configure script. This will create an additional binary '''pcvc4''' which supports parallel solving.
./configure --with-portfolio [...]

===Running===
*The '''pcvc4''' binary allows the user to run multiple instances of the solver simultaneously on the input problem. Each thread can be configured differently by prefixing each thread-specific options by '''--thread''N''='''<thread-specific-option> where ''N'' is the thread number (counting from 0). For example,
pcvc4 --thread0=--decision=internal --thread0=--no-simplification --thread1=--decision=justification input.smt2
will run two solver threads with different decision heuristics and simplification switched off for thread0. The solver will stop as soon as one of threads has an answer.

* The default number of threads is 2. The number of threads can be specified using '''--threads''' option. Note that any of the options specified outside all of the --thread''i''=... will be applied to all threads. For instance, in
pcvc4 --threads=3 \
--thread0=--random-seed=10 \
--thread1=--random-seed=20 \
--thread2=--random-seed=30 \
--simplification=none \
input.smt2
three threads will be run, all with simplification disabled, and different random seeds for the SAT solver.

* We also allow sharing of ''conflict clauses'' across different threads. By default, this is disabled but may he enabled by using the '''--filter-lemma-length''' option. For example,
pcvc4 --filter-lemma-length=5 ...
will share all lemmas having 5 or fewer literals.

Tutorials

2015-12-23T16:24:12Z

Clark Barrett:

Tutorials

2015-12-23T15:40:02Z

Clark Barrett:

=CVC language=

<coming soon...>

==Finding these examples==

Except where noted below, tutorial code appearing in this section is kept in the <code>examples/cvc</code> directory of the CVC4 source distribution. However, tutorial material on this page might be more recent than your CVC4 download. Please refer to the [http://cvc4.cs.nyu.edu/builds/src/ most recent nightly build] for the most recent tutorial code.

=SMT-LIB=

We recommend [http://smtlib.github.io/jSMTLIB/SMTLIBTutorial.pdf David Cok's excellent tutorial on SMT-LIB]. When running examples from this tutorial, we recommend using CVC4's ''--smtlib-strict'' command line option, which enters a stricter compliance mode.

CVC4 should be compliant with [http://www.smtlib.org/ the standard], and thus also with David Cok's tutorial, except for some unsupported functionality as noted in the [[SMT-LIB_Compliance|SMT-LIB compliance section of this wiki]]. If you find something that you believe to be nonconformant, please [http://cvc4.cs.nyu.edu/bugs/ report it as a bug].

=C++ API=
* helloworld : a simple example to start off with
* linear_arith : real and integer linear arithmetic
* combination : integer and uninterpreted function example
* bitvectors : bit-vectors example
* bitvectors_and_arrays : integer and uninterpreted function example
* quantifiers
* strings : strings example

==Finding and compiling these examples==

Except where noted below, tutorial code appearing in this section is kept in the <code>examples/api</code> directory of the CVC4 source distribution. However, tutorial material on this page might be more recent than your CVC4 download. Please refer to the [http://cvc4.cs.nyu.edu/builds/src/ most recent nightly build] for the most recent tutorial code.

To compile everything in the <code>examples/</code> directory, you can issue the command <code>make examples</code> from the top-level of the source distribution. This will first build CVC4 (if it isn't already built) and then the examples. Some examples from the directory may not be compiled, if (for instance) you haven't built with support for Java, or if you haven't built with support for the compatibility interface; however, all native C++ API examples should be, and those are the only ones appearing in this section.

Note that the example API code in the <code>examples/</code> directory is intended to be compiled and linked against a CVC4 library built from the source tree. If you try to compile them yourself, against a CVC4 library installed (for example) in <code>/usr</code>, you may find that certain headers cannot be found. There is an easy fix. CVC4 #includes like the following:
#include "expr/expr.h"
should be rewritten to this form:
#include <cvc4/expr/expr.h>
or, most likely, you can remove all such #includes and replace with this single one:
#include <cvc4/cvc4.h>

The example code is not installed by <code>make install</code>.

==helloworld==
To get used to CVC4, let us go through the following example line-by-line:
#include <iostream>
#include <cvc4/cvc4.h>
using namespace CVC4;
int main() {
ExprManager em;
Expr helloworld = em.mkVar("Hello World!", em.booleanType());
SmtEngine smt(&em);
std::cout << helloworld << " is " << smt.query(helloworld) << std::endl;
return 0;
}
(The example can be found in examples/api/helloworld.cpp.)

First we include the standard <iostream> library, and next we include the public interface for CVC4:
#include <cvc4/cvc4.h>
<code>cvc4/cvc4.h</code> includes definitions for all of the classes we'll need including ExprManager, Expr and SmtEngine. All of CVC4 lives in the namespace CVC4 and to save a bit of typing let's use the namespace. Now construct a new ExprManager named em.
ExprManager em;
ExprManagers are in charge of constructing and managing symbolic expressions in CVC4. We then construct the expression Expr helloworld.
Expr helloworld = em.mkVar("Hello World!", em.booleanType());
helloworld is a symbolic variable with the name "Hello World!" and the type boolean. Note that we ask em to both make the variable and to get em.booleanType(). We now make the main driver for CVC4 reasoning the SmtEngine smt using em as its ExprManager.
SmtEngine smt(&em);
Finally we print helloworld and query the SmtEngine if the boolean variable helloworld is valid.
std::cout << helloworld << " is " << smt.query(helloworld) << std::endl;

We can compile the program helloworld from helloworld.cpp by linking against <code>-lcvc4</code>
$ g++ helloworld.cpp -o helloworld -lcvc4
$ ./helloworld
Hello World! is invalid
This should all work if libcvc4 was installed using <code>make install</code>. If you used <code>make install</code> to a non-standard location, look at instructions for [[Build Problems#make_install_to_a_non-standard_prefix|using non-standard prefix]]. If you insist on not-using make, look at instructions for [[Build_Problems#libcvc4_without_make_install]].

==linear_arith==
With helloworld under our belt, let's try to work through the more advanced examples/api/linear_arith.cpp . In this example, we'll try to show that for <math> x \in \mathbb{Z}, y \in \mathbb{R}</math> if <math>x \geq 3 y, x \leq y, -2 < x </math> then <math> \max y - x = \frac{2}{3}</math>.
We can do this by first showing that these assumptions entail <math> y - x \leq \frac{2}{3}</math>, and then showing that <math> y - x = \frac{2}{3}</math> is consistent with the assumptions.

We use the same basic skeleton of includes/namespaces/main as before. We make an ExprManager and SmtEngine as before.
ExprManager em;
SmtEngine smt(&em);
We now set on option on the SmtEngine to enable incremental or multiple query solving, which we will take advantage of.
smt.setOption("incremental", SExpr("true")); // Enable incremental solving
We get the Types real and integer from em, and we make x and y variables of the respective types.
Type real = em.realType();
Type integer = em.integerType();
Expr x = em.mkVar("x", integer);
Expr y = em.mkVar("y", real);
We now make Exprs for the 3 Rational constants in the formulas using [[Expr#Constants|em.mkConst()]]:
Expr three = em.mkConst(Rational(3));
Expr neg2 = em.mkConst(Rational(-2));
Expr two_thirds = em.mkConst(Rational(2,3));
We will now make the intermediate terms using mkExpr.
Expr three_y = em.mkExpr(kind::MULT, three, y);
Expr diff = em.mkExpr(kind::MINUS, y, x);
The first argument to mkExpr is a Kind. Kind is an enum covering all of the various expressions that CVC4 can make. Common operators have fairly standard ALL_CAPS names, such as LEQ, MINUS, AND, BITVECTOR_NAND, and so on. Kind's are in the namespace CVC4::kind. For more information see [[Expr#Constants]].

Using these intermediate terms, we make the following formulas in the same way we made terms.
Expr x_geq_3y = em.mkExpr(kind::GEQ, x, three_y);
Expr x_leq_y = em.mkExpr(kind::LEQ, x, y);
Expr neg2_lt_x = em.mkExpr(kind::LT, neg2, x);

We now assert the assumptions in the SmtEngine:
Expr assumptions =
em.mkExpr(kind::AND, x_geq_3y, x_leq_y, neg2_lt_x);
smt.assertFormula(assumptions);
Alternatively, we could have asserted x_geq_3y, x_leq_y, and neg2_lt_x individually. It is worth pointing out that these are asserted at decision level 0. Modern DPLL(T) solvers are stack based. We can push the stack(), add assertions and then pop() assertions off of the stack.

We can now prove that <math> y - x \leq \frac{2}{3}</math>. We first make an Expr for this literal. We now push() the SmtEngine, query the SmtEngine for the validity of the literal given the assumptions, and pop() the SmtEngine.
smt.push();
Expr diff_leq_two_thirds = em.mkExpr(kind::LEQ, diff, two_thirds);
cout << "Prove that " << diff_leq_two_thirds << " with CVC4." << endl;
cout << "CVC4 should report VALID." << endl;
cout << "Result from CVC4 is: " << smt.query(diff_leq_two_thirds) << endl;
smt.pop();

It is worth noting that the push() and pop() are not strictly needed in order to not effect context level 0. This is because SmtEngine guards query(phi), checkSat(phi) with internal pushes and pops so phi does not effect the current context. It is needed below; however, as the second lemma is proved in the following fashion:
smt.push();
Expr diff_is_two_thirds = em.mkExpr(kind::EQUAL, diff, two_thirds);
smt.assertFormula(diff_is_two_thirds);
cout << "Show that the asserts are consistent with " << endl;
cout << diff_is_two_thirds << " with CVC4." << endl;
cout << "CVC4 should report SAT." << endl;
cout << "Result from CVC4 is: " << smt.checkSat(em.mkConst(true)) << endl;
smt.pop();

== bitvectors ==

In this example we will prove the equivalence of three different pieces of code. The example is adapted from the book [http://www.hackersdelight.org/ A Hacker's Delight] by Henry S. Warren. The code can be found in /examples/api/bitvectors.cpp.
Given a variable x, that can only have one of two values: a or b, we want to assign to x a value different than the current one. For example if x was equal to a we want to assign to it b. The most straightforward implementation of this is the following:

if (x == a) x = b;
else x = a;

or more concise:

x = x == a ? b : a; // (0)

However, the following two pieces of code provide a more efficient implementation:

x = a + b - x; // (1)

or

x = a ^ b ^ x; // (2)

We will encode the problem using the theory of bit-vectors and check that the three implementations are indeed equivalent.
Let's analyze the code in bitvector.cpp line by line. Because we are interested in checking two different problems we will turn on incremental mode and specify the logic, to increase efficiency of solving:

smt.setOption("incremental", true); // Enable incremental solving
smt.setLogic("QF_BV"); // Set the logic

To make a bit-vector variable we must first make a bit-vector type. The factory method that constructs a bit-vector type requires the width of the bit-vector as an argument. In our example we will assume we are modeling a 32-bit machine:

// Creating a bit-vector type of width 32
Type bitvector32 = em.mkBitVectorType(32);

Creating variables and expressions follows the same pattern as in previous examples. We will first create the input variables x, a and b:

// Variables
Expr x = em.mkVar("x", bitvector32);
Expr a = em.mkVar("a", bitvector32);
Expr b = em.mkVar("b", bitvector32);

The first assumption constraints x to be equal to either a or b:

// First encode the assumption that x must be equal to a or b
Expr x_eq_a = em.mkExpr(kind::EQUAL, x, a);
Expr x_eq_b = em.mkExpr(kind::EQUAL, x, b);
Expr assumption = em.mkExpr(kind::OR, x_eq_a, x_eq_b);

Because we will need this assumption to prove all following properties we can just assert it to the solver in the current context.
// Assert the assumption
smt.assertFormula(assumption);

To model the semantics of the instructions we need to introduce a new variable for x for each program state. Here new_x will represent the value of x after executing code (0). We will use new_x_ to represent the value of x after executing code (1) first, and then after executing code (2).

// Introduce a new variable for the new value of x after assignment.
Expr new_x = em.mkVar("new_x", bitvector32); // x after executing code (0)
Expr new_x_ = em.mkVar("new_x_", bitvector32); // x after executing code (1) or (2)

We can encode the assignment in code (0) in a straightforward manner by using a term-ITE (if-then-else) expression which captures the semantics of the C++ (cond ? val1 : val2).

// new_x = x == a ? b : a;
Expr ite = em.mkExpr(kind::ITE, x_eq_a, b, a);
Expr assignment0 = em.mkExpr(kind::EQUAL, new_x, ite);

// Assert the encoding of code (0)
cout << "Asserting " << assignment0 << " to CVC4 " << endl;
smt.assertFormula(assignment0);

Because the assertions we have so far are the only ones that will be used in both queries we can now push a new context:

cout << "Pushing a new context." << endl;
smt.push();

Next, we move to encoding the semantics of code (1) in a similar manner as before:

// Encoding code (1)
// new_x_ = a xor b xor x
Expr a_xor_b_xor_x = em.mkExpr(kind::BITVECTOR_XOR, a, b, x);
Expr assignment1 = em.mkExpr(kind::EQUAL, new_x_, a_xor_b_xor_x);

// Assert encoding to CVC4 in current context;
cout << "Asserting " << assignment1 << " to CVC4 " << endl;
smt.assertFormula(assignment1);

And we check that the value of x after executing code (0) is the same as that after executing code (1):

Expr new_x_eq_new_x_ = em.mkExpr(kind::EQUAL, new_x, new_x_);
cout << " Querying: " << new_x_eq_new_x_ << endl;
cout << " Expect valid. " << endl;
cout << " CVC4: " << smt.query(new_x_eq_new_x_) << endl;

Note that we are using smt.query(f) which checks for the validity of the formula f under the current assumptions i.e. that checking whether the current assertions imply (not f) is unsat.
Now that we are done with checking the first equivalence, we can pop the context:

cout << " Popping context. " << endl;
smt.pop();

Note that poping the context will remove the assertion saying new_x_ = a xor b xor x.

We follow a similar pattern to check the second equivalence:

// Encoding code (2)
// new_x_ = a + b - x
Expr a_plus_b = em.mkExpr(kind::BITVECTOR_PLUS, a, b);
Expr a_plus_b_minus_x = em.mkExpr(kind::BITVECTOR_SUB, a_plus_b, x);
Expr assignment2 = em.mkExpr(kind::EQUAL, new_x_, a_plus_b_minus_x);

// Assert encoding to CVC4 in current context;
cout << "Asserting " << assignment2 << " to CVC4 " << endl;
smt.assertFormula(assignment2);

cout << " Querying: " << new_x_eq_new_x_ << endl;
cout << " Expect valid. " << endl;
cout << " CVC4: " << smt.query(new_x_eq_new_x_) << endl;

==Sets==

If setting the logic, use "FS" to enable theory of sets.
smt.setLogic("QF_UFLIAFS");

To create a set type, call <code>mkSetType</code> in the <code>ExprManager</code>. It takes as argument the element type.
Type integer = em.integerType();
Type set = em.mkSetType(integer);

===Union and Intersection===

Verify union distributions over intersection. Checks the validity of (A union B) intersection C = (A intersection C) union (B intersection C) for all sets A, B, C of integers.
<pre>
Expr A = em.mkVar("A", set);
Expr B = em.mkVar("B", set);
Expr C = em.mkVar("C", set);

Expr unionAB = em.mkExpr(kind::UNION, A, B);
Expr lhs = em.mkExpr(kind::INTERSECTION, unionAB, C);

Expr intersectionAC = em.mkExpr(kind::INTERSECTION, A, C);
Expr intersectionBC = em.mkExpr(kind::INTERSECTION, B, C);
Expr rhs = em.mkExpr(kind::UNION, intersectionAC, intersectionBC);

Expr theorem = em.mkExpr(kind::EQUAL, lhs, rhs);

cout << "CVC4 reports: " << theorem << " is " << smt.query(theorem) << "." << endl;
</pre>

===EmptySet constant and Subset predicate===
An object of CVC4::EmptySet carries its type, which should be given at construction time. Note that this is the type of the set itself (so, pass the type set of integers, not integers).

Then, the empty set constant can be define using mkConst passing this CVC4::EmptySet object.
<pre>
Expr A = em.mkVar("A", set);
Expr emptyset = em.mkConst(EmptySet(set));

Expr theorem = em.mkExpr(kind::SUBSET, emptyset, A);

cout << "CVC4 reports: " << theorem << " is " << smt.query(theorem) << "." << endl;
</pre>
===Membership, singleton and producing models===

Remember to enable models (this should be done at the start, just after creating the smt engine).
smt.setOption("produce-models", true);

Find an element in {1, 2} intersection {2, 3}, if there is one.

<pre>
// Integer constants
Expr one = em.mkConst(Rational(1));
Expr two = em.mkConst(Rational(2));
Expr three = em.mkConst(Rational(3));

// Singleton sets for each of these constants
Expr singleton_one = em.mkExpr(kind::SINGLETON, one);
Expr singleton_two = em.mkExpr(kind::SINGLETON, two);
Expr singleton_three = em.mkExpr(kind::SINGLETON, three);

// Build bigger sets using union
Expr one_two = em.mkExpr(kind::UNION, singleton_one, singleton_two);
Expr two_three = em.mkExpr(kind::UNION, singleton_two, singleton_three);

Expr intersection = em.mkExpr(kind::INTERSECTION, one_two, two_three);
Expr x = em.mkVar("x", integer);
Expr e = em.mkExpr(kind::MEMBER, x, intersection);

Result result = smt.checkSat(e);
cout << "CVC4 reports: " << e << " is " << result << "." << endl;

// If the formula was satisfiable (which it should be here), get the value of x.
if(result == Result::SAT) {
cout << "For instance, " << smt.getValue(x) << " is a member." << endl;
}
</pre>

==Strings==

The example can be found in examples/api/strings.cpp

If setting the logic, use "S" to enable theory of strings.
smt.setLogic("S");

To create a string type, call <code>mkSetType</code> in the <code>ExprManager</code>.
Type string = em.stringType();

Make some string literals:
// std::string
std::string std_str_ab("ab");
// CVC4::String
CVC4::String cvc4_str_ab(std_str_ab);
CVC4::String cvc4_str_abc("abc");
// String constants
Expr ab = em.mkConst(cvc4_str_ab);
Expr abc = em.mkConst(CVC4::String("abc"));

Make some string variables:
Expr x = em.mkVar("x", string);
Expr y = em.mkVar("y", string);
Expr z = em.mkVar("z", string);

Make some string constraints:
// String concatenation: x.ab.y
Expr lhs = em.mkExpr(kind::STRING_CONCAT, x, ab, y);
// String concatenation: abc.z
Expr rhs = em.mkExpr(kind::STRING_CONCAT, abc, z);
// x.ab.y = abc.z
Expr formula1 = em.mkExpr(kind::EQUAL, lhs, rhs);
// Length of y: |y|
Expr leny = em.mkExpr(kind::STRING_LENGTH, y);
// |y| >= 0
Expr formula2 = em.mkExpr(kind::GEQ, leny, em.mkConst(Rational(0)));
// Regular expression: (ab[c-e]*f)|g|h
Expr r = em.mkExpr(kind::REGEXP_UNION,
em.mkExpr(kind::REGEXP_CONCAT,
em.mkExpr(kind::STRING_TO_REGEXP, em.mkConst(String("ab"))),
em.mkExpr(kind::REGEXP_STAR,
em.mkExpr(kind::REGEXP_RANGE, em.mkConst(String("c")), em.mkConst(String("e")))),
em.mkExpr(kind::STRING_TO_REGEXP, em.mkConst(String("f")))),
em.mkExpr(kind::STRING_TO_REGEXP, em.mkConst(String("g"))),
em.mkExpr(kind::STRING_TO_REGEXP, em.mkConst(String("h"))));
// String variables
Expr s1 = em.mkVar("s1", string);
Expr s2 = em.mkVar("s2", string);
// String concatenation: s1.s2
Expr s = em.mkExpr(kind::STRING_CONCAT, s1, s2);
// s1.s2 in (ab[c-e]*f)|g|h
Expr formula3 = em.mkExpr(kind::STRING_IN_REGEXP, s, r);

Make a query:
Expr q = em.mkExpr(kind::AND,
formula1,
formula2,
formula3);

Check the result:
Result result = smt.checkSat(q);
std::cout << "CVC4 reports: " << q << " is " << result << "." << std::endl;
if(result == Result::SAT) {
std::cout << " x = " << smt.getValue(x) << std::endl;
std::cout << " s1.s2 = " << smt.getValue(s) << std::endl;
}

=Java API=
=Parallel Solving=
===Obtaining===
* Download a statically built binary supporting parallel solving: [http://cvc4.cs.nyu.edu/cvc4-builds/portfolio-x86_64-linux-opt Optimized build]
* If compiling from source, specify by '''--with-portfolio''' option to the configure script. This will create an additional binary '''pcvc4''' which supports parallel solving.
./configure --with-portfolio [...]

===Running===
*The '''pcvc4''' binary allows the user to run multiple instances of the solver simultaneously on the input problem. Each thread can be configured differently by prefixing each thread-specific options by '''--thread''N''='''<thread-specific-option> where ''N'' is the thread number (counting from 0). For example,
pcvc4 --thread0=--decision=internal --thread0=--no-simplification --thread1=--decision=justification input.smt2
will run two solver threads with different decision heuristics and simplification switched off for thread0. The solver will stop as soon as one of threads has an answer.

* The default number of threads is 2. The number of threads can be specified using '''--threads''' option. Note that any of the options specified outside all of the --thread''i''=... will be applied to all threads. For instance, in
pcvc4 --threads=3 \
--thread0=--random-seed=10 \
--thread1=--random-seed=20 \
--thread2=--random-seed=30 \
--simplification=none \
input.smt2
three threads will be run, all with simplification disabled, and different random seeds for the SAT solver.

* We also allow sharing of ''conflict clauses'' across different threads. By default, this is disabled but may he enabled by using the '''--filter-lemma-length''' option. For example,
pcvc4 --filter-lemma-length=5 ...
will share all lemmas having 5 or fewer literals.

Building CVC4 from source

2013-10-09T05:35:36Z

Clark Barrett:

To compile CVC4 from a source package you must do the following:
# Install antlr
# Configure cvc4
# Compile cvc4
# Install cvc4 [optional]

To do so run the following commands in the CVC4 directory:

cd contrib
./get-antlr-3.4
cd ..
./configure --with-antlr-dir=`pwd`/antlr-3.4 ANTLR=`pwd`/antlr-3.4/bin/antlr3
make
make check [recommended]
make install [optional]

Below are more details instructions about the various dependencies and options.

=Common make Options=
* "''make install''" will install into the "--prefix" option you gave to
the configure script (''/usr/local'' by default).
./configure --prefix=~/install_targets/cvc4 ...
make install
* '''You should run "''make check''"''' before installation to ensure that CVC4 has been
built correctly. In particular, GCC version 4.5.1 seems to have a
bug in the optimizer that results in incorrect behavior (and wrong
results) in many builds. This is a known problem for Minisat, and
since Minisat is at the core of CVC4, a problem for CVC4. "''make check''"
easily detects this problem (by showing a number of FAILed test cases).
It is ok if the unit tests aren't run as part of "''make check''", but all
system tests and regression tests should pass without incident.
* To build API documentation, use "''make doc''". Documentation is produced
under ''builds/doc/'' but is not installed by "''make install''".

Examples and tutorials are not installed with "''make install''." See [[#Examples_and_tutorials_are_not_built_or_installed|below]].

For more information about the build system itself (probably not
necessary for casual users), see the [[#Appendix:_Build_architecture|Appendix]] at the bottom of this
file.

=Common configure Options=
*'''--prefix=PREFIX''' install architecture-independent files in PREFIX (by default /usr/local)
*'''--with-build={production,debug,default,competition}'''
*'''--with-antlr-dir=PATH'''
*'''--with-cln'''/'''--with-gmp''' selects the numbers package to use by default ([[#Optional requirements]])
*'''--enable-static-binary''' build a fully statically-linked binary. (This is recommended for Mac OS X users that want to be able to use gdb.)
*'''ANTLR=PATH''' location of the antlr3 script
*'''--with-boost=DIR''' installation location of the boost libraries (most users will not need this)

See '''./configure --help''' for more.

=Build dependencies=

The following tools and libraries are required to run CVC4. Versions
given are minimum versions; more recent versions should be compatible.

*'''GNU C and C++''' (gcc and g++), reasonably recent versions
*'''GNU Make'''
*'''GNU Bash'''
*'''GMP v4.2''' (GNU Multi-Precision arithmetic library)
*'''libantlr3c v3.2 or v3.4''' (ANTLR parser generator C support library)
*'''The Boost C++ base libraries'''
*'''MacPorts''' [highly recommended if on a Mac; see [[#MacPorts]]]

The hardest to obtain and install is the libantlr3c requirement, and
is explained [[#Installing libantlr3c: ANTLR parser generator C support library|next]].

If "make" is non-GNU on your system, make sure to invoke "gmake" (or
whatever GNU Make is installed as). If your usual shell is not Bash,
the configure script should auto-correct this. If it does not, you'll
see strange shell syntax errors, and you may need to explicitly set
SHELL or CONFIG_SHELL to the location of bash on your system.

==Installing libantlr3c: ANTLR parser generator C support library==

For libantlr3c, you can use the convenience script in
''contrib/get-antlr-3.4'' in the source distribution---this will download, patch, compile and install
libantlr3c into your cvc4 directory as ''cvc4/antlr-3.4/''.
cd contrib
./get-antlr-3.4

CVC4 must be configured with the antlr library installation directory, '''--with-antlr-dir''', and an antlr executable script file, '''ANTLR'''. If libantlr3c was installed via get-antlr-3.4, the following configure line should suffice for CVC44
./configure --with-antlr-dir=`pwd`/antlr-3.4 ANTLR=`pwd`/antlr-3.4/bin/antlr3

For 64 bit machines, libantlr3c needs to be configured with 64 bit explicitly
./configure --enable-64bit ...
The get-antlr-3.4 script makes a guess at whether the machine is 64 bit and adds the appropriate flag.
To force the script to compile 32 bit:
MACHINE_TYPE="x86" ./get-antlr-3.4
To force the script to compile 64 bit:
MACHINE_TYPE="x86_64" ./get-antlr-3.4

For a longer discussion, instructions for manual installation, and more in depth troubleshooting, see [[Developer's Guide#ANTLR3]].

==MacPorts==

On a Mac, it is '''highly''' recommended that you use MacPorts (see
http://www.macports.org/). Doing so is easy. Then, simply run the
script ''contrib/mac-build'', which installs a few ports from the MacPorts
repository, then compiles and installs antlr3c using the ''get-antlr-3.4''
script. The mac-build script should set you up
with all requirements, and will tell you how to configure CVC4 when it
completes successfully.

==Installing the Boost C++ base libraries==

A Boost package is available on most Linux distributions; check yours
for a package named something like libboost-dev or boost-devel. There
are a number of additional Boost packages in some distributions, but
this "basic" one should be sufficient for building CVC4.

Should you want to install Boost manually, or to learn more about the
Boost project, please visit http://www.boost.org/.

=Optional requirements=

None of these is required, but can improve CVC4 as described below:

*'''Optional: SWIG 2.0.x''' (Simplified Wrapper and Interface Generator)
*'''Optional: CLN v1.3 or newer''' (Class Library for Numbers)
*'''Optional: CUDD v2.4.2 or newer''' (Colorado University Decision Diagram package)
*'''Optional: GNU Readline library''' (for an improved interactive experience)
*'''Optional: The Boost C++ threading library''' (libboost_thread)
*'''Optional: CxxTest unit testing framework'''

SWIG is necessary to build the Java API (and of course a JDK is
necessary, too). SWIG 1.x won't work; you'll need 2.0, and the more
recent the better. On Mac, we've seen SWIG segfault when generating
CVC4 language bindings; version 2.0.8 or higher is recommended to
avoid this. See [[#Language_bindings|Language bindings]] below for build instructions.

CLN is an alternative multiprecision arithmetic package that can offer
better performance and memory footprint than GMP. CLN is covered by
the GNU General Public License, version 3; so if you choose to use
CVC4 with CLN support, you are licensing CVC4 under that same license.
(Usually CVC4's license is more permissive than GPL is; see the file
COPYING in the CVC4 source distribution for details.) Please visit
http://www.ginac.de/CLN/ for more details about CLN.

CUDD is a decision diagram package that changes the behavior of the
CVC4 arithmetic solver in some cases; it may or may not improve the
arithmetic solver's performance. See [[#Building_with_CUDD_(optional)|below]] for instructions on
obtaining and building CUDD.

The GNU Readline library is optionally used to provide command
editing, tab completion, and history functionality at the CVC prompt
(when running in interactive mode). Check your distribution for a
package named "libreadline-dev" or "readline-devel" or similar.

The Boost C++ threading library (often packaged independently of the
Boost base library) is needed to run CVC4 in "portfolio"
(multithreaded) mode. Check your distribution for a package named
"libboost-thread-dev" or similar.

CxxTest is necessary to run CVC4's unit tests (included with the
distribution). Running these is not really required for users of
CVC4; "make check" will skip unit tests if CxxTest isn't available,
and go on to run the extensive system- and regression-tests in the
source tree. However, if you're interested, you can download CxxTest
at http://cxxtest.com/ .

==Building with CUDD (optional)==

CUDD, if desired, must be installed delicately. The CVC4 configure
script attempts to auto-detect the locations and names of CUDD headers
and libraries the way that the Fedora RPMs install them, the way that
our NYU-provided Debian packages install them, and the way they exist
when you download and build the CUDD sources directly. If you install
from Fedora RPMs or our Debian packages, the process should be
completely automatic, since the libraries and headers are installed in
a standard location. If you download the sources yourself, you need
to build them in a special way. Fortunately, the
"contrib/build-cudd-2.4.2-with-libtool.sh" script in the CVC4 source
tree does exactly what you need: it patches the CUDD makefiles to use
libtool, builds the libtool libraries, then reverses the patch to
leave the makefiles as they were. Once you run this script on an
unpacked CUDD 2.4.2 source distribution, then CVC4's configure script
should pick up the libraries if you provide
--with-cudd-dir=/PATH/TO/CUDD/SOURCES.

If you want to force linking to CUDD, provide --with-cudd to the
configure script; this makes it a hard requirement rather than an
optional add-on.

The NYU-provided Debian packaging of CUDD 2.4.2 and CUDD 2.5.0 are
here (along with the CVC4 Debian packages):

deb http://cvc4.cs.nyu.edu/debian/ unstable/

On Debian (and Debian-derived distributions like Ubuntu), you only
need to drop that one line in your /etc/apt/sources.list file, then install with your favorite package manager.

The Debian source package "cudd", available from the same repository,
includes a diff of all changes made to cudd makefiles.

=Language bindings=

There are several options available for using CVC4 from the API.

First, CVC4 offers a complete and flexible API for manipulating
expressions, maintaining a stack of assertions, and checking
satisfiability, and related things. The C++ libraries (libcvc4.so and
libcvc4parser.so) and required headers are installed normally via a
"make install". This API is also available from Java (via CVC4.jar
and libcvc4jni.so) by configuring with --enable-language-bindings=java.
You'll also need SWIG 2.0 installed (and you might need to help
configure find it if you installed it in a nonstandard place with
--with-swig-dir=/path/to/swig/installation). You may also need to
give the configure script the path to your Java headers (in
particular, jni.h). You might do so with (for example):

./configure --enable-language-bindings=java \
JAVA_CPPFLAGS=-I/usr/lib/jvm/java-6-openjdk-amd64/include

There is also a "C++ compatibility API" (''#include <cvc4/cvc3_compat.h>''
and link against libcvc4compat.so) that attempts to maintain
source-level backwards-compatibility with the CVC3 C++ API. The
compatibility library is built by default, and
''--enable-language-bindings=java'' enables the Java compatibility library
(CVC4compat.jar and libcvc4compatjni.so).
''--enable-language-bindings=c'' enables the C compatibility library
(''#include <cvc4/bindings/compat/c/c_interface.h>'' and link against
libcvc4bindings_c_compat.so), and if you want both C and Java
bindings, use ''--enable-language-bindings=c,java''. These compatibility
language bindings do NOT require SWIG.

The ''examples/'' directory in the source distribution includes some basic examples (the "simple vc"
and "simple vc compat" family of examples) of all these interfaces.

In principle, since we use SWIG to generate the native Java API, we
could support other languages as well. However, using CVC4 from other
languages is not supported, nor expected to work, at this time. If
you're interested in helping to develop, maintain, and test a language
binding, please contact us via the users' mailing list at
cvc-users@cs.nyu.edu.

=Building CVC4 from a repository checkout=

The following tools and libraries are additionally required to build
CVC4 from from a repository checkout rather than from a prepared
source tarball.

*'''Automake v1.11'''
*'''Autoconf v2.61'''
*'''Libtool v2.2'''
*'''ANTLR3 v3.2 or v3.4'''
*'''Java Development Kit''' ([http://www.antlr.org/wiki/pages/viewpage.action?pageId=728 required for ANTLR3])

First, use "''./autogen.sh''" to create the configure script. Then
proceed as normal for any distribution tarball. The parsers are
pre-generated for the tarballs, but don't exist in the repository; hence the extra ANTLR3 and JDK requirements to
generate the source code for the parsers, when building from the
repository.

=Examples and tutorials are not built or installed=

Examples are not built by "''make''" or "''make install''". See
''examples/README'' in the source distribution for information on what to find in the ''examples/''
directory, as well as information about building and installing them.

=Appendix: Build architecture=

The build system is generated by automake, libtool, and autoconf. It
is somewhat nonstandard, though, which (for one thing) requires that
GNU Make be used. If you ./configure in the top-level source
directory, the objects will actually all appear in
builds/${arch}/${build_id}. This is to allow multiple, separate
builds in the same place (e.g., an assertions-enabled debugging build
alongside a production build), without changing directories at the
shell. The "current" build is maintained, and you can still use
(e.g.) "make -C src/main" to rebuild objects in just one subdirectory.

You can also create your own build directory inside or outside of the
source tree and configure from there. All objects will then be built
in that directory, and you'll ultimately find the "cvc4" binary in
src/main/, and the libraries under src/ and src/parser/.

Tutorials

2012-12-03T19:33:28Z

Clark Barrett: /* Running */

=CVC language=

<coming soon...>

==Finding these examples==

Except where noted below, tutorial code appearing in this section is kept in the <code>examples/cvc</code> directory of the CVC4 source distribution. However, tutorial material on this page might be more recent than your CVC4 download. Please refer to the [http://cvc4.cs.nyu.edu/builds/src/ most recent nightly build] for the most recent tutorial code.

=SMT-LIB=

We recommend [http://www.grammatech.com/resources/smt/SMTLIBTutorial.pdf David Cok's excellent tutorial on SMT-LIB]. When running examples from this tutorial, we recommend using CVC4's ''--smtlib-strict'' command line option, which enters a stricter compliance mode.

CVC4 should be compliant with [http://www.smtlib.org/ the standard], and thus also with David Cok's tutorial, except for some unsupported functionality as noted in the [[SMT-LIB_Compliance|SMT-LIB compliance section of this wiki]]. If you find something that you believe to be nonconformant, please [http://cvc4.cs.nyu.edu/bugs/ report it as a bug].

=C++ API=
* helloworld : a simple example to start off with
* linear_arith : real and integer linear arithmetic
* combination : integer and uninterpreted function example
* bitvectors : bit-vectors example
* bitvectors_and_arrays : integer and uninterpreted function example
* quantifiers

==Finding and compiling these examples==

Except where noted below, tutorial code appearing in this section is kept in the <code>examples/api</code> directory of the CVC4 source distribution. However, tutorial material on this page might be more recent than your CVC4 download. Please refer to the [http://cvc4.cs.nyu.edu/builds/src/ most recent nightly build] for the most recent tutorial code.

To compile everything in the <code>examples/</code> directory, you can issue the command <code>make examples</code> from the top-level of the source distribution. This will first build CVC4 (if it isn't already built) and then the examples. Some examples from the directory may not be compiled, if (for instance) you haven't built with support for Java, or if you haven't built with support for the compatibility interface; however, all native C++ API examples should be, and those are the only ones appearing in this section.

Note that the example API code in the <code>examples/</code> directory is intended to be compiled and linked against a CVC4 library built from the source tree. If you try to compile them yourself, against a CVC4 library installed (for example) in <code>/usr</code>, you may find that certain headers cannot be found. There is an easy fix. CVC4 #includes like the following:
#include "expr/expr.h"
should be rewritten to this form:
#include <cvc4/expr/expr.h>
or, most likely, you can remove all such #includes and replace with this single one:
#include <cvc4/cvc4.h>

The example code is not installed by <code>make install</code>.

==helloworld==
To get used to CVC4, let us go through the following example line-by-line:
#include <iostream>
#include <cvc4/cvc4.h>
using namespace CVC4;
int main() {
ExprManager em;
Expr helloworld = em.mkVar("Hello World!", em.booleanType());
SmtEngine smt(&em);
std::cout << helloworld << " is " << smt.query(helloworld) << std::endl;
return 0;
}
(The example can be found in examples/api/helloworld.cpp.)

First we include the standard <iostream> library, and next we include the public interface for CVC4:
#include <cvc4/cvc4.h>
<code>cvc4/cvc4.h</code> includes definitions for all of the classes we'll need including ExprManager, Expr and SmtEngine. All of CVC4 lives in the namespace CVC4 and to save a bit of typing let's use the namespace. Now construct a new ExprManager named em.
ExprManager em;
ExprManagers are in charge of constructing and managing symbolic expressions in CVC4. We then construct the expression Expr helloworld.
Expr helloworld = em.mkVar("Hello World!", em.booleanType());
helloworld is a symbolic variable with the name "Hello World!" and the type boolean. Note that we ask em to both make the variable and to get em.booleanType(). We now make the main driver for CVC4 reasoning the SmtEngine smt using em as its ExprManager.
SmtEngine smt(&em);
Finally we print helloworld and query the SmtEngine if the boolean variable helloworld is valid.
std::cout << helloworld << " is " << smt.query(helloworld) << std::endl;

We can compile the program helloworld from helloworld.cpp by linking against <code>-lcvc4</code>
$ g++ helloworld.cpp -o helloworld -lcvc4
$ ./helloworld
Hello World! is invalid
This should all work if libcvc4 was installed using <code>make install</code>. If you used <code>make install</code> to a non-standard location, look at instructions for [[Build Problems#make_install_to_a_non-standard_prefix|using non-standard prefix]]. If you insist on not-using make, look at instructions for [[Build_Problems#libcvc4_without_make_install]].

==linear_arith==
With helloworld under our belt, let's try to work through the more advanced examples/api/linear_arith.cpp . In this example, we'll try to show that for <math> x \in \mathbb{Z}, y \in \mathbb{R}</math> if <math>x \geq 3 y, x \leq y, -2 < x </math> then <math> \max y - x = \frac{2}{3}</math>.
We can do this by first showing that these assumptions entail <math> y - x \leq \frac{2}{3}</math>, and then showing that <math> y - x = \frac{2}{3}</math> is consistent with the assumptions.

We use the same basic skeleton of includes/namespaces/main as before. We make an ExprManager and SmtEngine as before.
ExprManager em;
SmtEngine smt(&em);
We now set on option on the SmtEngine to enable incremental or multiple query solving, which we will take advantage of.
smt.setOption("incremental", SExpr("true")); // Enable incremental solving
We get the Types real and integer from em, and we make x and y variables of the respective types.
Type real = em.realType();
Type integer = em.integerType();
Expr x = em.mkVar("x", integer);
Expr y = em.mkVar("y", real);
We now make Exprs for the 3 Rational constants in the formulas using [[Expr#Constants|em.mkConst()]]:
Expr three = em.mkConst(Rational(3));
Expr neg2 = em.mkConst(Rational(-2));
Expr two_thirds = em.mkConst(Rational(2,3));
We will now make the intermediate terms using mkExpr.
Expr three_y = em.mkExpr(kind::MULT, three, y);
Expr diff = em.mkExpr(kind::MINUS, y, x);
The first argument to mkExpr is a Kind. Kind is an enum covering all of the various expressions that CVC4 can make. Common operators have fairly standard ALL_CAPS names, such as LEQ, MINUS, AND, BITVECTOR_NAND, and so on. Kind's are in the namespace CVC4::kind. For more information see [[Expr#Constants]].

Using these intermediate terms, we make the following formulas in the same way we made terms.
Expr x_geq_3y = em.mkExpr(kind::GEQ, x, three_y);
Expr x_leq_y = em.mkExpr(kind::LEQ, x, y);
Expr neg2_lt_x = em.mkExpr(kind::LT, neg2, x);

We now assert the assumptions in the SmtEngine:
Expr assumptions =
em.mkExpr(kind::AND, x_geq_3y, x_leq_y, neg2_lt_x);
smt.assertFormula(assumptions);
Alternatively, we could have asserted x_geq_3y, x_leq_y, and neg2_lt_x individually. It is worth pointing out that these are asserted at decision level 0. Modern DPLL(T) solvers are stack based. We can push the stack(), add assertions and then pop() assertions off of the stack.

We can now prove that <math> y - x \leq \frac{2}{3}</math>. We first make an Expr for this literal. We now push() the SmtEngine, query the SmtEngine for the validity of the literal given the assumptions, and pop() the SmtEngine.
smt.push();
Expr diff_leq_two_thirds = em.mkExpr(kind::LEQ, diff, two_thirds);
cout << "Prove that " << diff_leq_two_thirds << " with CVC4." << endl;
cout << "CVC4 should report VALID." << endl;
cout << "Result from CVC4 is: " << smt.query(diff_leq_two_thirds) << endl;
smt.pop();

It is worth noting that the push() and pop() are not strictly needed in order to not effect context level 0. This is because SmtEngine guards query(phi), checkSat(phi) with internal pushes and pops so phi does not effect the current context. It is needed below; however, as the second lemma is proved in the following fashion:
smt.push();
Expr diff_is_two_thirds = em.mkExpr(kind::EQUAL, diff, two_thirds);
smt.assertFormula(diff_is_two_thirds);
cout << "Show that the asserts are consistent with " << endl;
cout << diff_is_two_thirds << " with CVC4." << endl;
cout << "CVC4 should report SAT." << endl;
cout << "Result from CVC4 is: " << smt.checkSat(em.mkConst(true)) << endl;
smt.pop();

== bitvectors ==

In this example we will prove the equivalence of three different pieces of code. The example is adapted from the book [http://www.hackersdelight.org/ A Hacker's Delight] by Henry S. Warren. The code can be found in /examples/api/bitvectors.cpp.
Given a variable x, that can only have one of two values: a or b, we want to assign to x a value different than the current one. For example if x was equal to a we want to assign to it b. The most straightforward implementation of this is the following:

if (x == a) x = b;
else x = a;

or more concise:

x = x == a ? b : a; // (0)

However, the following two pieces of code provide a more efficient implementation:

x = a + b - x; // (1)

or

x = a ^ b ^ x; // (2)

We will encode the problem using the theory of bit-vectors and check that the three implementations are indeed equivalent.
Let's analyze the code in bitvector.cpp line by line. Because we are interested in checking two different problems we will turn on incremental mode and specify the logic, to increase efficiency of solving:

smt.setOption("incremental", true); // Enable incremental solving
smt.setLogic("QF_BV"); // Set the logic

To make a bit-vector variable we must first make a bit-vector type. The factory method that constructs a bit-vector type requires the width of the bit-vector as an argument. In our example we will assume we are modeling a 32-bit machine:

// Creating a bit-vector type of width 32
Type bitvector32 = em.mkBitVectorType(32);

Creating variables and expressions follows the same pattern as in previous examples. We will first create the input variables x, a and b:

// Variables
Expr x = em.mkVar("x", bitvector32);
Expr a = em.mkVar("a", bitvector32);
Expr b = em.mkVar("b", bitvector32);

The first assumption constraints x to be equal to either a or b:

// First encode the assumption that x must be equal to a or b
Expr x_eq_a = em.mkExpr(kind::EQUAL, x, a);
Expr x_eq_b = em.mkExpr(kind::EQUAL, x, b);
Expr assumption = em.mkExpr(kind::OR, x_eq_a, x_eq_b);

Because we will need this assumption to prove all following properties we can just assert it to the solver in the current context.
// Assert the assumption
smt.assertFormula(assumption);

To model the semantics of the instructions we need to introduce a new variable for x for each program state. Here new_x will represent the value of x after executing code (0). We will use new_x_ to represent the value of x after executing code (1) first, and then after executing code (2).

// Introduce a new variable for the new value of x after assignment.
Expr new_x = em.mkVar("new_x", bitvector32); // x after executing code (0)
Expr new_x_ = em.mkVar("new_x_", bitvector32); // x after executing code (1) or (2)

We can encode the assignment in code (0) in a straightforward manner by using a term-ITE (if-then-else) expression which captures the semantics of the C++ (cond ? val1 : val2).

// new_x = x == a ? b : a;
Expr ite = em.mkExpr(kind::ITE, x_eq_a, b, a);
Expr assignment0 = em.mkExpr(kind::EQUAL, new_x, ite);

// Assert the encoding of code (0)
cout << "Asserting " << assignment0 << " to CVC4 " << endl;
smt.assertFormula(assignment0);

Because the assertions we have so far are the only ones that will be used in both queries we can now push a new context:

cout << "Pushing a new context." << endl;
smt.push();

Next, we move to encoding the semantics of code (1) in a similar manner as before:

// Encoding code (1)
// new_x_ = a xor b xor x
Expr a_xor_b_xor_x = em.mkExpr(kind::BITVECTOR_XOR, a, b, x);
Expr assignment1 = em.mkExpr(kind::EQUAL, new_x_, a_xor_b_xor_x);

// Assert encoding to CVC4 in current context;
cout << "Asserting " << assignment1 << " to CVC4 " << endl;
smt.assertFormula(assignment1);

And we check that the value of x after executing code (0) is the same as that after executing code (1):

Expr new_x_eq_new_x_ = em.mkExpr(kind::EQUAL, new_x, new_x_);
cout << " Querying: " << new_x_eq_new_x_ << endl;
cout << " Expect valid. " << endl;
cout << " CVC4: " << smt.query(new_x_eq_new_x_) << endl;

Note that we are using smt.query(f) which checks for the validity of the formula f under the current assumptions i.e. that checking whether the current assertions imply (not f) is unsat.
Now that we are done with checking the first equivalence, we can pop the context:

cout << " Popping context. " << endl;
smt.pop();

Note that poping the context will remove the assertion saying new_x_ = a xor b xor x.

We follow a similar pattern to check the second equivalence:

// Encoding code (2)
// new_x_ = a + b - x
Expr a_plus_b = em.mkExpr(kind::BITVECTOR_PLUS, a, b);
Expr a_plus_b_minus_x = em.mkExpr(kind::BITVECTOR_SUB, a_plus_b, x);
Expr assignment2 = em.mkExpr(kind::EQUAL, new_x_, a_plus_b_minus_x);

// Assert encoding to CVC4 in current context;
cout << "Asserting " << assignment2 << " to CVC4 " << endl;
smt.assertFormula(assignment1);

cout << " Querying: " << new_x_eq_new_x_ << endl;
cout << " Expect valid. " << endl;
cout << " CVC4: " << smt.query(new_x_eq_new_x_) << endl;

=Java API=
=Parallel Solving=
===Obtaining===
* Download a statically built binary supporting parallel solving: [http://cvc4.cs.nyu.edu/cvc4-builds/portfolio-x86_64-linux-opt Optimized build]
* If compiling from source, specify by '''--with-portfolio''' option to the configure script. This will create an additional binary '''pcvc4''' which supports parallel solving.
./configure --with-portfolio [...]

===Running===
*The '''pcvc4''' binary allows the user to run multiple instances of the solver simultaneously on the input problem. Each thread can be configured differently by specifying thread-specific options using '''--thread''N''=" <thread-specific-options> "'''. For example,
pcvc4 --thread0="--decision=internal" --thread1="--decision=justification" input.smt2
will run two solver threads with different decision heuristics. The solver will stop as soon as one of threads has an answer.

* The default number of threads is 2. The number of threads can be specified using '''--threads''' option. Note that any of the options specified outside all of the --thread''i''="..." will be applied to all threads. For instance, in
pcvc4 --threads=3 \
--thread0="--random-seed=10" \
--thread1="--random-seed=20" \
--thread2="--random-seed=30" \
--simplification=none \
input.smt2
three threads will be run, all with simplification disabled, and different random seeds for the SAT solver.

* We also allow sharing of ''conflict clauses'' across different threads. By default, this is disabled but may he enabled by using the '''--filter-lemma-length''' option. For example,
pcvc4 --filter-lemma-length=5 ...
will share all lemmas having 5 or fewer literals.

Tutorials

2012-12-03T19:30:25Z

Clark Barrett: /* SMT-LIB */

=CVC language=

<coming soon...>

==Finding these examples==

Except where noted below, tutorial code appearing in this section is kept in the <code>examples/cvc</code> directory of the CVC4 source distribution. However, tutorial material on this page might be more recent than your CVC4 download. Please refer to the [http://cvc4.cs.nyu.edu/builds/src/ most recent nightly build] for the most recent tutorial code.

=SMT-LIB=

We recommend [http://www.grammatech.com/resources/smt/SMTLIBTutorial.pdf David Cok's excellent tutorial on SMT-LIB]. When running examples from this tutorial, we recommend using CVC4's ''--smtlib-strict'' command line option, which enters a stricter compliance mode.

CVC4 should be compliant with [http://www.smtlib.org/ the standard], and thus also with David Cok's tutorial, except for some unsupported functionality as noted in the [[SMT-LIB_Compliance|SMT-LIB compliance section of this wiki]]. If you find something that you believe to be nonconformant, please [http://cvc4.cs.nyu.edu/bugs/ report it as a bug].

=C++ API=
* helloworld : a simple example to start off with
* linear_arith : real and integer linear arithmetic
* combination : integer and uninterpreted function example
* bitvectors : bit-vectors example
* bitvectors_and_arrays : integer and uninterpreted function example
* quantifiers

==Finding and compiling these examples==

Except where noted below, tutorial code appearing in this section is kept in the <code>examples/api</code> directory of the CVC4 source distribution. However, tutorial material on this page might be more recent than your CVC4 download. Please refer to the [http://cvc4.cs.nyu.edu/builds/src/ most recent nightly build] for the most recent tutorial code.

To compile everything in the <code>examples/</code> directory, you can issue the command <code>make examples</code> from the top-level of the source distribution. This will first build CVC4 (if it isn't already built) and then the examples. Some examples from the directory may not be compiled, if (for instance) you haven't built with support for Java, or if you haven't built with support for the compatibility interface; however, all native C++ API examples should be, and those are the only ones appearing in this section.

Note that the example API code in the <code>examples/</code> directory is intended to be compiled and linked against a CVC4 library built from the source tree. If you try to compile them yourself, against a CVC4 library installed (for example) in <code>/usr</code>, you may find that certain headers cannot be found. There is an easy fix. CVC4 #includes like the following:
#include "expr/expr.h"
should be rewritten to this form:
#include <cvc4/expr/expr.h>
or, most likely, you can remove all such #includes and replace with this single one:
#include <cvc4/cvc4.h>

The example code is not installed by <code>make install</code>.

==helloworld==
To get used to CVC4, let us go through the following example line-by-line:
#include <iostream>
#include <cvc4/cvc4.h>
using namespace CVC4;
int main() {
ExprManager em;
Expr helloworld = em.mkVar("Hello World!", em.booleanType());
SmtEngine smt(&em);
std::cout << helloworld << " is " << smt.query(helloworld) << std::endl;
return 0;
}
(The example can be found in examples/api/helloworld.cpp.)

First we include the standard <iostream> library, and next we include the public interface for CVC4:
#include <cvc4/cvc4.h>
<code>cvc4/cvc4.h</code> includes definitions for all of the classes we'll need including ExprManager, Expr and SmtEngine. All of CVC4 lives in the namespace CVC4 and to save a bit of typing let's use the namespace. Now construct a new ExprManager named em.
ExprManager em;
ExprManagers are in charge of constructing and managing symbolic expressions in CVC4. We then construct the expression Expr helloworld.
Expr helloworld = em.mkVar("Hello World!", em.booleanType());
helloworld is a symbolic variable with the name "Hello World!" and the type boolean. Note that we ask em to both make the variable and to get em.booleanType(). We now make the main driver for CVC4 reasoning the SmtEngine smt using em as its ExprManager.
SmtEngine smt(&em);
Finally we print helloworld and query the SmtEngine if the boolean variable helloworld is valid.
std::cout << helloworld << " is " << smt.query(helloworld) << std::endl;

We can compile the program helloworld from helloworld.cpp by linking against <code>-lcvc4</code>
$ g++ helloworld.cpp -o helloworld -lcvc4
$ ./helloworld
Hello World! is invalid
This should all work if libcvc4 was installed using <code>make install</code>. If you used <code>make install</code> to a non-standard location, look at instructions for [[Build Problems#make_install_to_a_non-standard_prefix|using non-standard prefix]]. If you insist on not-using make, look at instructions for [[Build_Problems#libcvc4_without_make_install]].

==linear_arith==
With helloworld under our belt, let's try to work through the more advanced examples/api/linear_arith.cpp . In this example, we'll try to show that for <math> x \in \mathbb{Z}, y \in \mathbb{R}</math> if <math>x \geq 3 y, x \leq y, -2 < x </math> then <math> \max y - x = \frac{2}{3}</math>.
We can do this by first showing that these assumptions entail <math> y - x \leq \frac{2}{3}</math>, and then showing that <math> y - x = \frac{2}{3}</math> is consistent with the assumptions.

We use the same basic skeleton of includes/namespaces/main as before. We make an ExprManager and SmtEngine as before.
ExprManager em;
SmtEngine smt(&em);
We now set on option on the SmtEngine to enable incremental or multiple query solving, which we will take advantage of.
smt.setOption("incremental", SExpr("true")); // Enable incremental solving
We get the Types real and integer from em, and we make x and y variables of the respective types.
Type real = em.realType();
Type integer = em.integerType();
Expr x = em.mkVar("x", integer);
Expr y = em.mkVar("y", real);
We now make Exprs for the 3 Rational constants in the formulas using [[Expr#Constants|em.mkConst()]]:
Expr three = em.mkConst(Rational(3));
Expr neg2 = em.mkConst(Rational(-2));
Expr two_thirds = em.mkConst(Rational(2,3));
We will now make the intermediate terms using mkExpr.
Expr three_y = em.mkExpr(kind::MULT, three, y);
Expr diff = em.mkExpr(kind::MINUS, y, x);
The first argument to mkExpr is a Kind. Kind is an enum covering all of the various expressions that CVC4 can make. Common operators have fairly standard ALL_CAPS names, such as LEQ, MINUS, AND, BITVECTOR_NAND, and so on. Kind's are in the namespace CVC4::kind. For more information see [[Expr#Constants]].

Using these intermediate terms, we make the following formulas in the same way we made terms.
Expr x_geq_3y = em.mkExpr(kind::GEQ, x, three_y);
Expr x_leq_y = em.mkExpr(kind::LEQ, x, y);
Expr neg2_lt_x = em.mkExpr(kind::LT, neg2, x);

We now assert the assumptions in the SmtEngine:
Expr assumptions =
em.mkExpr(kind::AND, x_geq_3y, x_leq_y, neg2_lt_x);
smt.assertFormula(assumptions);
Alternatively, we could have asserted x_geq_3y, x_leq_y, and neg2_lt_x individually. It is worth pointing out that these are asserted at decision level 0. Modern DPLL(T) solvers are stack based. We can push the stack(), add assertions and then pop() assertions off of the stack.

We can now prove that <math> y - x \leq \frac{2}{3}</math>. We first make an Expr for this literal. We now push() the SmtEngine, query the SmtEngine for the validity of the literal given the assumptions, and pop() the SmtEngine.
smt.push();
Expr diff_leq_two_thirds = em.mkExpr(kind::LEQ, diff, two_thirds);
cout << "Prove that " << diff_leq_two_thirds << " with CVC4." << endl;
cout << "CVC4 should report VALID." << endl;
cout << "Result from CVC4 is: " << smt.query(diff_leq_two_thirds) << endl;
smt.pop();

It is worth noting that the push() and pop() are not strictly needed in order to not effect context level 0. This is because SmtEngine guards query(phi), checkSat(phi) with internal pushes and pops so phi does not effect the current context. It is needed below; however, as the second lemma is proved in the following fashion:
smt.push();
Expr diff_is_two_thirds = em.mkExpr(kind::EQUAL, diff, two_thirds);
smt.assertFormula(diff_is_two_thirds);
cout << "Show that the asserts are consistent with " << endl;
cout << diff_is_two_thirds << " with CVC4." << endl;
cout << "CVC4 should report SAT." << endl;
cout << "Result from CVC4 is: " << smt.checkSat(em.mkConst(true)) << endl;
smt.pop();

== bitvectors ==

In this example we will prove the equivalence of three different pieces of code. The example is adapted from the book [http://www.hackersdelight.org/ A Hacker's Delight] by Henry S. Warren. The code can be found in /examples/api/bitvectors.cpp.
Given a variable x, that can only have one of two values: a or b, we want to assign to x a value different than the current one. For example if x was equal to a we want to assign to it b. The most straightforward implementation of this is the following:

if (x == a) x = b;
else x = a;

or more concise:

x = x == a ? b : a; // (0)

However, the following two pieces of code provide a more efficient implementation:

x = a + b - x; // (1)

or

x = a ^ b ^ x; // (2)

We will encode the problem using the theory of bit-vectors and check that the three implementations are indeed equivalent.
Let's analyze the code in bitvector.cpp line by line. Because we are interested in checking two different problems we will turn on incremental mode and specify the logic, to increase efficiency of solving:

smt.setOption("incremental", true); // Enable incremental solving
smt.setLogic("QF_BV"); // Set the logic

To make a bit-vector variable we must first make a bit-vector type. The factory method that constructs a bit-vector type requires the width of the bit-vector as an argument. In our example we will assume we are modeling a 32-bit machine:

// Creating a bit-vector type of width 32
Type bitvector32 = em.mkBitVectorType(32);

Creating variables and expressions follows the same pattern as in previous examples. We will first create the input variables x, a and b:

// Variables
Expr x = em.mkVar("x", bitvector32);
Expr a = em.mkVar("a", bitvector32);
Expr b = em.mkVar("b", bitvector32);

The first assumption constraints x to be equal to either a or b:

// First encode the assumption that x must be equal to a or b
Expr x_eq_a = em.mkExpr(kind::EQUAL, x, a);
Expr x_eq_b = em.mkExpr(kind::EQUAL, x, b);
Expr assumption = em.mkExpr(kind::OR, x_eq_a, x_eq_b);

Because we will need this assumption to prove all following properties we can just assert it to the solver in the current context.
// Assert the assumption
smt.assertFormula(assumption);

To model the semantics of the instructions we need to introduce a new variable for x for each program state. Here new_x will represent the value of x after executing code (0). We will use new_x_ to represent the value of x after executing code (1) first, and then after executing code (2).

// Introduce a new variable for the new value of x after assignment.
Expr new_x = em.mkVar("new_x", bitvector32); // x after executing code (0)
Expr new_x_ = em.mkVar("new_x_", bitvector32); // x after executing code (1) or (2)

We can encode the assignment in code (0) in a straightforward manner by using a term-ITE (if-then-else) expression which captures the semantics of the C++ (cond ? val1 : val2).

// new_x = x == a ? b : a;
Expr ite = em.mkExpr(kind::ITE, x_eq_a, b, a);
Expr assignment0 = em.mkExpr(kind::EQUAL, new_x, ite);

// Assert the encoding of code (0)
cout << "Asserting " << assignment0 << " to CVC4 " << endl;
smt.assertFormula(assignment0);

Because the assertions we have so far are the only ones that will be used in both queries we can now push a new context:

cout << "Pushing a new context." << endl;
smt.push();

Next, we move to encoding the semantics of code (1) in a similar manner as before:

// Encoding code (1)
// new_x_ = a xor b xor x
Expr a_xor_b_xor_x = em.mkExpr(kind::BITVECTOR_XOR, a, b, x);
Expr assignment1 = em.mkExpr(kind::EQUAL, new_x_, a_xor_b_xor_x);

// Assert encoding to CVC4 in current context;
cout << "Asserting " << assignment1 << " to CVC4 " << endl;
smt.assertFormula(assignment1);

And we check that the value of x after executing code (0) is the same as that after executing code (1):

Expr new_x_eq_new_x_ = em.mkExpr(kind::EQUAL, new_x, new_x_);
cout << " Querying: " << new_x_eq_new_x_ << endl;
cout << " Expect valid. " << endl;
cout << " CVC4: " << smt.query(new_x_eq_new_x_) << endl;

Note that we are using smt.query(f) which checks for the validity of the formula f under the current assumptions i.e. that checking whether the current assertions imply (not f) is unsat.
Now that we are done with checking the first equivalence, we can pop the context:

cout << " Popping context. " << endl;
smt.pop();

Note that poping the context will remove the assertion saying new_x_ = a xor b xor x.

We follow a similar pattern to check the second equivalence:

// Encoding code (2)
// new_x_ = a + b - x
Expr a_plus_b = em.mkExpr(kind::BITVECTOR_PLUS, a, b);
Expr a_plus_b_minus_x = em.mkExpr(kind::BITVECTOR_SUB, a_plus_b, x);
Expr assignment2 = em.mkExpr(kind::EQUAL, new_x_, a_plus_b_minus_x);

// Assert encoding to CVC4 in current context;
cout << "Asserting " << assignment2 << " to CVC4 " << endl;
smt.assertFormula(assignment1);

cout << " Querying: " << new_x_eq_new_x_ << endl;
cout << " Expect valid. " << endl;
cout << " CVC4: " << smt.query(new_x_eq_new_x_) << endl;

=Java API=
=Parallel Solving=
===Obtaining===
* Download a statically built binary supporting parallel solving: [http://cvc4.cs.nyu.edu/cvc4-builds/portfolio-x86_64-linux-opt Optimized build]
* If compiling from source, specify by '''--with-portfolio''' option to the configure script. This will create an additional binary '''pcvc4''' which supports parallel solving.
./configure --with-portfolio [...]

===Running===
*The '''pcvc4''' binary allows the user to run multiple instances of the solver simultaneously on the input problem. Each thread can be configured differently by specifying thread-specific options using '''--thread''N''=" <thread-specific-options> "'''. For example,
pcvc4 --thread0="--decision=internal" --thread1="--decision=justification" input.smt2
will run two solver threads with different decision heuristics. The solver will stop as soon as one of threads has an answer.

* The default number of threads is 2. The number of threads can be specified using '''--threads''' option. Note that any of the options specified outside all of the --thread''i''="..." will be applied to all threads. For instance, in
pcvc4 --threads=3 \
--thread0="--random-seed=10" \
--thread1="--random-seed=20" \
--thread2="--random-seed=30" \
--simplification=none \
input.smt2
three threads will be run, all with simplification disabled, and different random seeds for the SAT solver.

* We also allow sharing of ''conflict clauses'' across different threads. By default, this is disabled but may he enabled by using the '''--filter-lemma-length''' option. For example,
pcvc4 --filter-lemma-length=5 ...
will share all lemmas having 5 or less literals.

Tutorials

2012-12-03T19:28:45Z

Clark Barrett: /* CVC language */

=CVC language=

<coming soon...>

==Finding these examples==

Except where noted below, tutorial code appearing in this section is kept in the <code>examples/cvc</code> directory of the CVC4 source distribution. However, tutorial material on this page might be more recent than your CVC4 download. Please refer to the [http://cvc4.cs.nyu.edu/builds/src/ most recent nightly build] for the most recent tutorial code.

=SMT-LIB=

We recommend [http://www.grammatech.com/resources/smt/SMTLIBTutorial.pdf David Cok's excellent tutorial on SMT-LIB]. When running examples from this tutorial, we recommend using CVC4's ''--smtlib-strict'' command line option, which enters a stricter compliance mode.

CVC4 should be compliant with [http://www.smtlib.org/ the standard], and thus also with David Cok's tutorial, except for some unsupported functionality as outlined in the [[User's Manual#CVC4's support for the SMT-LIB language|SMT-LIB compliance section of the User's Manual]]. If you find something that you believe to be nonconformant, please [http://cvc4.cs.nyu.edu/bugs/ report it as a bug].

=C++ API=
* helloworld : a simple example to start off with
* linear_arith : real and integer linear arithmetic
* combination : integer and uninterpreted function example
* bitvectors : bit-vectors example
* bitvectors_and_arrays : integer and uninterpreted function example
* quantifiers

==Finding and compiling these examples==

Except where noted below, tutorial code appearing in this section is kept in the <code>examples/api</code> directory of the CVC4 source distribution. However, tutorial material on this page might be more recent than your CVC4 download. Please refer to the [http://cvc4.cs.nyu.edu/builds/src/ most recent nightly build] for the most recent tutorial code.

To compile everything in the <code>examples/</code> directory, you can issue the command <code>make examples</code> from the top-level of the source distribution. This will first build CVC4 (if it isn't already built) and then the examples. Some examples from the directory may not be compiled, if (for instance) you haven't built with support for Java, or if you haven't built with support for the compatibility interface; however, all native C++ API examples should be, and those are the only ones appearing in this section.

Note that the example API code in the <code>examples/</code> directory is intended to be compiled and linked against a CVC4 library built from the source tree. If you try to compile them yourself, against a CVC4 library installed (for example) in <code>/usr</code>, you may find that certain headers cannot be found. There is an easy fix. CVC4 #includes like the following:
#include "expr/expr.h"
should be rewritten to this form:
#include <cvc4/expr/expr.h>
or, most likely, you can remove all such #includes and replace with this single one:
#include <cvc4/cvc4.h>

The example code is not installed by <code>make install</code>.

==helloworld==
To get used to CVC4, let us go through the following example line-by-line:
#include <iostream>
#include <cvc4/cvc4.h>
using namespace CVC4;
int main() {
ExprManager em;
Expr helloworld = em.mkVar("Hello World!", em.booleanType());
SmtEngine smt(&em);
std::cout << helloworld << " is " << smt.query(helloworld) << std::endl;
return 0;
}
(The example can be found in examples/api/helloworld.cpp.)

First we include the standard <iostream> library, and next we include the public interface for CVC4:
#include <cvc4/cvc4.h>
<code>cvc4/cvc4.h</code> includes definitions for all of the classes we'll need including ExprManager, Expr and SmtEngine. All of CVC4 lives in the namespace CVC4 and to save a bit of typing let's use the namespace. Now construct a new ExprManager named em.
ExprManager em;
ExprManagers are in charge of constructing and managing symbolic expressions in CVC4. We then construct the expression Expr helloworld.
Expr helloworld = em.mkVar("Hello World!", em.booleanType());
helloworld is a symbolic variable with the name "Hello World!" and the type boolean. Note that we ask em to both make the variable and to get em.booleanType(). We now make the main driver for CVC4 reasoning the SmtEngine smt using em as its ExprManager.
SmtEngine smt(&em);
Finally we print helloworld and query the SmtEngine if the boolean variable helloworld is valid.
std::cout << helloworld << " is " << smt.query(helloworld) << std::endl;

We can compile the program helloworld from helloworld.cpp by linking against <code>-lcvc4</code>
$ g++ helloworld.cpp -o helloworld -lcvc4
$ ./helloworld
Hello World! is invalid
This should all work if libcvc4 was installed using <code>make install</code>. If you used <code>make install</code> to a non-standard location, look at instructions for [[Build Problems#make_install_to_a_non-standard_prefix|using non-standard prefix]]. If you insist on not-using make, look at instructions for [[Build_Problems#libcvc4_without_make_install]].

==linear_arith==
With helloworld under our belt, let's try to work through the more advanced examples/api/linear_arith.cpp . In this example, we'll try to show that for <math> x \in \mathbb{Z}, y \in \mathbb{R}</math> if <math>x \geq 3 y, x \leq y, -2 < x </math> then <math> \max y - x = \frac{2}{3}</math>.
We can do this by first showing that these assumptions entail <math> y - x \leq \frac{2}{3}</math>, and then showing that <math> y - x = \frac{2}{3}</math> is consistent with the assumptions.

We use the same basic skeleton of includes/namespaces/main as before. We make an ExprManager and SmtEngine as before.
ExprManager em;
SmtEngine smt(&em);
We now set on option on the SmtEngine to enable incremental or multiple query solving, which we will take advantage of.
smt.setOption("incremental", SExpr("true")); // Enable incremental solving
We get the Types real and integer from em, and we make x and y variables of the respective types.
Type real = em.realType();
Type integer = em.integerType();
Expr x = em.mkVar("x", integer);
Expr y = em.mkVar("y", real);
We now make Exprs for the 3 Rational constants in the formulas using [[Expr#Constants|em.mkConst()]]:
Expr three = em.mkConst(Rational(3));
Expr neg2 = em.mkConst(Rational(-2));
Expr two_thirds = em.mkConst(Rational(2,3));
We will now make the intermediate terms using mkExpr.
Expr three_y = em.mkExpr(kind::MULT, three, y);
Expr diff = em.mkExpr(kind::MINUS, y, x);
The first argument to mkExpr is a Kind. Kind is an enum covering all of the various expressions that CVC4 can make. Common operators have fairly standard ALL_CAPS names, such as LEQ, MINUS, AND, BITVECTOR_NAND, and so on. Kind's are in the namespace CVC4::kind. For more information see [[Expr#Constants]].

Using these intermediate terms, we make the following formulas in the same way we made terms.
Expr x_geq_3y = em.mkExpr(kind::GEQ, x, three_y);
Expr x_leq_y = em.mkExpr(kind::LEQ, x, y);
Expr neg2_lt_x = em.mkExpr(kind::LT, neg2, x);

We now assert the assumptions in the SmtEngine:
Expr assumptions =
em.mkExpr(kind::AND, x_geq_3y, x_leq_y, neg2_lt_x);
smt.assertFormula(assumptions);
Alternatively, we could have asserted x_geq_3y, x_leq_y, and neg2_lt_x individually. It is worth pointing out that these are asserted at decision level 0. Modern DPLL(T) solvers are stack based. We can push the stack(), add assertions and then pop() assertions off of the stack.

We can now prove that <math> y - x \leq \frac{2}{3}</math>. We first make an Expr for this literal. We now push() the SmtEngine, query the SmtEngine for the validity of the literal given the assumptions, and pop() the SmtEngine.
smt.push();
Expr diff_leq_two_thirds = em.mkExpr(kind::LEQ, diff, two_thirds);
cout << "Prove that " << diff_leq_two_thirds << " with CVC4." << endl;
cout << "CVC4 should report VALID." << endl;
cout << "Result from CVC4 is: " << smt.query(diff_leq_two_thirds) << endl;
smt.pop();

It is worth noting that the push() and pop() are not strictly needed in order to not effect context level 0. This is because SmtEngine guards query(phi), checkSat(phi) with internal pushes and pops so phi does not effect the current context. It is needed below; however, as the second lemma is proved in the following fashion:
smt.push();
Expr diff_is_two_thirds = em.mkExpr(kind::EQUAL, diff, two_thirds);
smt.assertFormula(diff_is_two_thirds);
cout << "Show that the asserts are consistent with " << endl;
cout << diff_is_two_thirds << " with CVC4." << endl;
cout << "CVC4 should report SAT." << endl;
cout << "Result from CVC4 is: " << smt.checkSat(em.mkConst(true)) << endl;
smt.pop();

== bitvectors ==

In this example we will prove the equivalence of three different pieces of code. The example is adapted from the book [http://www.hackersdelight.org/ A Hacker's Delight] by Henry S. Warren. The code can be found in /examples/api/bitvectors.cpp.
Given a variable x, that can only have one of two values: a or b, we want to assign to x a value different than the current one. For example if x was equal to a we want to assign to it b. The most straightforward implementation of this is the following:

if (x == a) x = b;
else x = a;

or more concise:

x = x == a ? b : a; // (0)

However, the following two pieces of code provide a more efficient implementation:

x = a + b - x; // (1)

or

x = a ^ b ^ x; // (2)

We will encode the problem using the theory of bit-vectors and check that the three implementations are indeed equivalent.
Let's analyze the code in bitvector.cpp line by line. Because we are interested in checking two different problems we will turn on incremental mode and specify the logic, to increase efficiency of solving:

smt.setOption("incremental", true); // Enable incremental solving
smt.setLogic("QF_BV"); // Set the logic

To make a bit-vector variable we must first make a bit-vector type. The factory method that constructs a bit-vector type requires the width of the bit-vector as an argument. In our example we will assume we are modeling a 32-bit machine:

// Creating a bit-vector type of width 32
Type bitvector32 = em.mkBitVectorType(32);

Creating variables and expressions follows the same pattern as in previous examples. We will first create the input variables x, a and b:

// Variables
Expr x = em.mkVar("x", bitvector32);
Expr a = em.mkVar("a", bitvector32);
Expr b = em.mkVar("b", bitvector32);

The first assumption constraints x to be equal to either a or b:

// First encode the assumption that x must be equal to a or b
Expr x_eq_a = em.mkExpr(kind::EQUAL, x, a);
Expr x_eq_b = em.mkExpr(kind::EQUAL, x, b);
Expr assumption = em.mkExpr(kind::OR, x_eq_a, x_eq_b);

Because we will need this assumption to prove all following properties we can just assert it to the solver in the current context.
// Assert the assumption
smt.assertFormula(assumption);

To model the semantics of the instructions we need to introduce a new variable for x for each program state. Here new_x will represent the value of x after executing code (0). We will use new_x_ to represent the value of x after executing code (1) first, and then after executing code (2).

// Introduce a new variable for the new value of x after assignment.
Expr new_x = em.mkVar("new_x", bitvector32); // x after executing code (0)
Expr new_x_ = em.mkVar("new_x_", bitvector32); // x after executing code (1) or (2)

We can encode the assignment in code (0) in a straightforward manner by using a term-ITE (if-then-else) expression which captures the semantics of the C++ (cond ? val1 : val2).

// new_x = x == a ? b : a;
Expr ite = em.mkExpr(kind::ITE, x_eq_a, b, a);
Expr assignment0 = em.mkExpr(kind::EQUAL, new_x, ite);

// Assert the encoding of code (0)
cout << "Asserting " << assignment0 << " to CVC4 " << endl;
smt.assertFormula(assignment0);

Because the assertions we have so far are the only ones that will be used in both queries we can now push a new context:

cout << "Pushing a new context." << endl;
smt.push();

Next, we move to encoding the semantics of code (1) in a similar manner as before:

// Encoding code (1)
// new_x_ = a xor b xor x
Expr a_xor_b_xor_x = em.mkExpr(kind::BITVECTOR_XOR, a, b, x);
Expr assignment1 = em.mkExpr(kind::EQUAL, new_x_, a_xor_b_xor_x);

// Assert encoding to CVC4 in current context;
cout << "Asserting " << assignment1 << " to CVC4 " << endl;
smt.assertFormula(assignment1);

And we check that the value of x after executing code (0) is the same as that after executing code (1):

Expr new_x_eq_new_x_ = em.mkExpr(kind::EQUAL, new_x, new_x_);
cout << " Querying: " << new_x_eq_new_x_ << endl;
cout << " Expect valid. " << endl;
cout << " CVC4: " << smt.query(new_x_eq_new_x_) << endl;

Note that we are using smt.query(f) which checks for the validity of the formula f under the current assumptions i.e. that checking whether the current assertions imply (not f) is unsat.
Now that we are done with checking the first equivalence, we can pop the context:

cout << " Popping context. " << endl;
smt.pop();

Note that poping the context will remove the assertion saying new_x_ = a xor b xor x.

We follow a similar pattern to check the second equivalence:

// Encoding code (2)
// new_x_ = a + b - x
Expr a_plus_b = em.mkExpr(kind::BITVECTOR_PLUS, a, b);
Expr a_plus_b_minus_x = em.mkExpr(kind::BITVECTOR_SUB, a_plus_b, x);
Expr assignment2 = em.mkExpr(kind::EQUAL, new_x_, a_plus_b_minus_x);

// Assert encoding to CVC4 in current context;
cout << "Asserting " << assignment2 << " to CVC4 " << endl;
smt.assertFormula(assignment1);

cout << " Querying: " << new_x_eq_new_x_ << endl;
cout << " Expect valid. " << endl;
cout << " CVC4: " << smt.query(new_x_eq_new_x_) << endl;

=Java API=
=Parallel Solving=
===Obtaining===
* Download a statically built binary supporting parallel solving: [http://cvc4.cs.nyu.edu/cvc4-builds/portfolio-x86_64-linux-opt Optimized build]
* If compiling from source, specify by '''--with-portfolio''' option to the configure script. This will create an additional binary '''pcvc4''' which supports parallel solving.
./configure --with-portfolio [...]

===Running===
*The '''pcvc4''' binary allows the user to run multiple instances of the solver simultaneously on the input problem. Each thread can be configured differently by specifying thread-specific options using '''--thread''N''=" <thread-specific-options> "'''. For example,
pcvc4 --thread0="--decision=internal" --thread1="--decision=justification" input.smt2
will run two solver threads with different decision heuristics. The solver will stop as soon as one of threads has an answer.

* The default number of threads is 2. The number of threads can be specified using '''--threads''' option. Note that any of the options specified outside all of the --thread''i''="..." will be applied to all threads. For instance, in
pcvc4 --threads=3 \
--thread0="--random-seed=10" \
--thread1="--random-seed=20" \
--thread2="--random-seed=30" \
--simplification=none \
input.smt2
three threads will be run, all with simplification disabled, and different random seeds for the SAT solver.

* We also allow sharing of ''conflict clauses'' across different threads. By default, this is disabled but may he enabled by using the '''--filter-lemma-length''' option. For example,
pcvc4 --filter-lemma-length=5 ...
will share all lemmas having 5 or less literals.

CVC4's native language

2012-12-01T18:12:09Z

Clark Barrett: /* Structured Types */

= CVC4 native input language =

The native input language consists of a sequence of symbol declarations and commands, each followed by a semicolon (<code>;</code>).

Any text after the first occurrence of a percent character and to the end of the current line is a comment:

%%% This is a native language comment

== Type System ==

CVC4's type system includes a set of built-in types which can be expanded with additional user-defined types.

The type system consists of ''first-order'' types, ''subtypes'' of first-order types, and ''higher-order'' types, all of which are interpreted as sets.
For convenience, we will sometimes identify below the interpretation of a type with the type itself.

First-order types consist of basic types and structured types. The basic types are <math>\mathrm{BOOLEAN}</math>, <math>\mathrm{REAL}</math>, <math>\mathrm{BITVECTOR}(n)</math> for all <math>n > 0</math>, as well as user-defined basic types (also called uninterpreted types).
The structured types are array, tuple, record types, and ML-style user-defined (inductive) datatypes.

'''Note:''' Currently, subtypes consist only of the built-in subtype <math>\mathrm{INT}</math> of <math>\mathrm{REAL}</math>.

Support for CVC3-style user-defined subtypes will be added in a later release.

Function types are the only higher-order types.
More precisely, they are just second-order types
since function symbols in CVC4, both built-in and user-defined, can take as argument or return only values of
a first-order type.

=== Basic Types ===

==== The BOOLEAN Type ====

The <math>\mathrm{BOOLEAN}</math> type is interpreted as the two-element set of Boolean values
<math>\{\mathrm{TRUE},\; \mathrm{FALSE}\}</math>.

'''Note:''' CVC4's treatment of this type differs from CVC3's where <math>\mathrm{BOOLEAN}</math> is used only as the type of formulas, but not as value type. CVC3 follows the two-tiered structure of classical first-order logic
which distinguishes between formulas and terms, and allows terms to occur in formulas but not vice versa (with the exception of the IF-THEN-ELSE construct).
CVC4 drops the distinction between terms and formulas and defines the latter just as terms of type <math>\mathrm{BOOLEAN}</math>. As such, formulas can occur as subterms of possibly non-Boolean terms.

Example:

[To do]

==== The REAL Type ====

The <math>\mathrm{REAL}</math> type is interpreted as the set of real numbers.

Note that these are the (infinite precision) mathematical reals,
not the floating point numbers.
Support for floating point types is planned for future versions.

x, y : REAL;
QUERY (( x <= y ) AND ( y <= x )) => ( x = y );

==== The INT Type ====

The <math>\mathrm{INT}</math> type is interpreted as the set of integer numbers
and is considered a subtype of <math>\mathrm{REAL}</math>.
The latter means in particular that it is possible to mix integer and real terms
in expressions without the need of an explicit ''upcasting'' operator.

Note that these are the (infinite precision) mathematical integers,
not the finite precision machine integers used in most programming languages.
The latter are modeled by [[ #Bitvectors | bit vector ]] types.

x, y : INT;
QUERY ((2 * x + 4 * y <= 1) AND ( y >= x)) => (x <= 0);
z : REAL;
QUERY (2 * x + z <= 3.5) AND (z >= 1);

==== Bit Vector Types ====

For every positive integer <math>n</math>, the type <math>\mathrm{BITVECTOR}(n)</math> is interpreted as the set of all bit vectors of size <math>n</math>.
A rich set of bit vector operators is supported.

==== User-defined Basic Types ====

Users can define new basic types
(often referred to as ''uninterpreted'' types in the SMT literature).
Each such type is interpreted as a set of unspecified cardinality
but disjoint from any other type.

User-defined basic types are created by declarations like the following:

% User declarations of basic types:

MyBrandNewType: TYPE;

Apples, Oranges: TYPE;

=== Structured Types ===

CVC4's structured types are divided into the following families.

==== Array Types ====

Array types are created by the mixfix type constructors <math>\mathrm{ARRAY}\ \_\ \mathrm{OF}\ \_</math>
whose arguments can be instantiated by any value type.

I : TYPE;

%% Array types:

% Arrays with indices from I and values from REAL
Array1: TYPE = ARRAY I OF REAL;

% Arrays with integer indices and array values
Array2: TYPE = ARRAY INT OF (ARRAY INT OF REAL);

% Arrays with integer pair indices and integer values
IntMatrix: TYPE = ARRAY [INT, INT] OF INT;

An array type of the form <math>\mathrm{ARRAY}\ T_1\ \mathrm{OF}\ T_2</math> is interpreted
as the set of all total maps from <math>T_1</math> to <math>T_2</math>.
The main difference with the function type <math>T_1 \to T_2</math> is that arrays,
contrary to functions, are first-class objects of the language, that is, values of an array
type can be arguments or results of functions.
Furthermore, array types come equipped with an update operation.

==== Tuple Types ====

Tuple types are created by the mixfix type constructors

<center>
<math>
\begin{array}{l} [\ \_\ ] \\[1ex] [\ \_\ ,\ \_\ ] \\[1ex] [\ \_\ ,\ \_\ \ ,\ \_\ ] \\[1ex] \ldots \end{array}
</math>
</center>

whose arguments can be instantiated by any value type.

IntArray: TYPE = ARRAY INT OF INT;

% Tuple type declarations

RealPair: TYPE = [REAL, REAL]

MyTuple: TYPE = [ REAL, IntArray, [INT, INT] ];

A tuple type of the form <math>[T_1, \ldots, T_n]</math> is interpreted
as the Cartesian product <math>T_1 \times \cdots \times T_n</math>.

Note that while the types <math>(T_1, \ldots, T_n) \to T</math> and
<math>[T_1 \times \cdots \times T_n] \to T</math> are semantically equivalent,
they are operationally different in CVC4.
The first is the type of functions that take <math>n</math> arguments
of respective type <math>T_1</math>, <math>\ldots</math>, <math>T_n</math>,
while the second is the type of functions that take one argument of an <math>n</math>-tuple type.

==== Record Types ====

Similar to, but more general than tuple types, record types are created by type constructors of the form

<center>
<math>
[\#\ l_1: \_\ ,\ \ldots\ ,\ l_n: \_\ \#]
</math>
</center>

where <math>n > 0</math>, <math>l_1,\ldots, l_n</math> are field labels,
and the arguments can be instantiated with any first-order types.

MyType: TYPE;

% Record declaration

RecordType: TYPE = [# id: REAL, age: INT, info: MyType #];

The order of the fields in a record type is meaningful:
permuting the field names gives a different type.

Note that record types are non-recursive.
For instance, it is not possible to declare a record type called <code>Person</code> containing
a field of type <code>Person</code>.
Recursive types are provided in CVC4 by the more general inductive data types.
(As a matter of fact, both record and tuple types are implemented internally as inductive data types.)

==== Inductive Data Types ====

Inductive data types in CVC4 are similar to inductive data types of functional languages.
They can be parametric or not.

===== Non-Parametric Data Types =====

Non-parametric data types are created by declarations of the form
<center>
<math>
\begin{array}{l}
\mathrm{DATATYPE} \\
\begin{array}{ccc}
\ \ A_1 & = & C_{1,1} \mid C_{1,2} \mid \cdots \mid C_{1,m_1}, \\
\ \ A_2 & = & C_{2,1} \mid C_{2,2} \mid \cdots \mid C_{2,m_2}, \\
\ \ \vdots & = & \vdots \\
\ \ A_n & = & C_{n,1} \mid C_{n,2} \mid \cdots \mid C_{n,m_n} \\
\end{array}
\\
\mathrm{END};
\end{array}
</math>
</center>
where
each <math>A_i</math> is a type name and
each <math>C_{ij}</math> is either a constant symbol or an expression of the form
<center>
<math>\mathit{cons}(\ \mathit{sel}_1: T_1,\ \ldots,\ \mathit{sel}_k: T_k\ )
</math>
</center>
where <math>T_1, \ldots, T_k</math> are any first-order types, including any <math>A_i</math>.
Such declarations define the data types <math>A_1, \ldots, A_n</math>.
For each data type <math>A_i</math> they introduce:

* constructor symbols <math>cons</math> of type <math>(T_1, \ldots, T_k) \to \mathit{type\_name}_i</math>,
* selector symbols <math>\mathit{sel}_j</math> of type <math>\mathit{type\_name}_i \to T_j</math>, and
* tester symbols <math>\mathit{is\_cons}</math> of type <math>\mathit{type\_name}_i \to \mathrm{BOOLEAN}</math>.

Note that permitting more than one data type to be defined in the same declarations allows
the definition of mutually recursive types.

% simple enumeration type

% implicitly defined are the testers: is_red, is_yellow and is_blue
% (similarly for the other data types)

DATATYPE
PrimaryColor = red | yellow | blue
END;

% infinite set of pairwise distinct values ..., v(-1), v(0), v(1), ...

DATATYPE
Id = v (id: INT)
END;

% ML-style integer lists

DATATYPE
IntList = nil | ins (head: INT, tail: IntList)
END;

% AST for lamba calculus

DATATYPE
Term = var (index: INT)
| apply (arg_1: Term, arg_2: Term)
| lambda (arg: INT, body: Term)
END;

% Trees

DATATYPE
Tree = tree (value: REAL, children: TreeList),
TreeList = nil_tl
| ins_tl (first_t1: Tree, rest_t1: TreeList)
END;

Constructor, selector and tester symbols defined for a data type have global scope.
So, for example, it is not possible for two different data types to use
the same name for a constructor.

An inductive data type is interpreted as a term algebra constructed by the constructor symbols
over some sets of generators.
For example, the type <code>IntList</code> defined above is interpreted as the set
of all terms constructed with <code>nil</code> and <code>ins</code> over the integers.

===== Parametric Data Types =====

Parametric data types are infinite families of (non-parametric) data types
with each family parametrized by one or more type variables.
They are created by declarations of the form
<center>
<math>
\begin{array}{l}
\mathrm{DATATYPE} \\
\begin{array}{ccc}
\ \ A_1[X_{1,1}, \ldots, X_{1,p_1}] & = & C_{1,1} \mid C_{1,2} \mid \cdots \mid C_{1,m_1}, \\
\ \ A_2[X_{2,1}, \ldots, X_{2,p_2}] & = & C_{2,1} \mid C_{2,2} \mid \cdots \mid C_{2,m_2}, \\
\ \ \vdots & = & \vdots \\
\ \ A_n[X_{n,1}, \ldots, X_{n,p_n}] & = & C_{n,1} \mid C_{n,2} \mid \cdots \mid C_{n,m_n} \\
\end{array}
\\
\mathrm{END};
\end{array}
</math>
</center>
where
each <math>A_i</math> is a type name parametrized by the type variables <math>X_{i,1}, \ldots, X_{i,p_i}</math>
and
each <math>C_{ij}</math> is either a constant symbol or an expression of the form
<center>
<math>\mathit{cons}(\ \mathit{sel}_1: T_1,\ \ldots,\ \mathit{sel}_k: T_k\ )
</math>
</center>
where <math>T_1, \ldots, T_k</math> are any first-order types,
possibly parametrized by <math>X_1, \ldots, X_p</math>, including any <math>A_i</math>.

% Parametric pairs
DATATYPE
Pair[X, Y] = pair (first: X, second: Y)
END;

% Parametric lists

DATATYPE
List[X] = nil | cons (head: X, tail: List[X])
END;

% Parametric trees using the list type above

DATATYPE
Tree[X] = node (value: X, children: List[Tree[X]]),
END;

The declarations above define infinitely many types of the form
Pair[S,T], List[T] and Tree[T] where S and T are first-order types.
Note that the identifier <code>List</code> above, for example, by itself does not denote a type.
In contrast, the terms <code>List[Real]</code>, <code>List[List[Real]]</code>, <code>List[Tree[INT]]</code>,
and so on do.

===== Restriction to Inductive Types =====

By adopting a term algebra semantics, CVC4 allows only ''inductive'' data types,
that is, data types whose values are essentially (labeled, ordered) finite trees.
Infinite structures such as streams or even finite but cyclic ones
such as circular lists are then excluded.
For instance, none of the following declarations define inductive data types,
and are rejected by CVC4:

DATATYPE
IntStream = s (first:INT, rest: IntStream)
END;

DATATYPE
RationalTree = node1 (child: RationalTree)
| node2 (left_child: RationalTree, right_child:RationalTree)
END;

DATATYPE
T1 = c1 (s1: T2),
T2 = c2 (s2: T1)
END;

In concrete, a declaration of <math>n \geq 1</math> datatypes <math>T_1, \ldots, T_n</math> will be rejected if for any one of the types <math>T_1, \ldots, T_n</math>, it is impossible to build a finite term of that type using only the constructors of <math>T_1, \ldots, T_n</math> and free constants of type other than <math>T_1, \ldots, T_n</math>.

Inductive data types are the only types where the user also chooses names for the built-in operations to:

* construct a value of the type (with the constructors),
* extract components from a value (with the selectors), or
* check if a value was constructed with a certain constructor or not (with the testers).

For all the other types, CVC4 provides predefined names for the built-in operations on the type.

=== Function Types ===

Function (<math>\to</math>) types are created by the mixfix type constructors
<center>
<math>
\begin{array}{l}
\_ \to \_ \\[1ex] (\ \_\ ,\ \_\ ) \to \_
\\[1ex] (\ \_\ ,\ \_\ ,\ \_\ ) \to \_
\\[1ex] \ldots
\end{array}
</math>
</center>
whose arguments can be instantiated by any first-order type.

% Function type declarations

UnaryFunType: TYPE = INT -> REAL;

BinaryFunType: TYPE = (REAL, REAL) -> ARRAY REAL OF REAL;

TernaryFunType: TYPE = (REAL, BITVECTOR(4), INT) -> BOOLEAN;

A function type of the form <math>(T_1, \ldots, T_n) \to T</math> with <math>n > 0</math> is interpreted as the set of all ''total'' functions from the Cartesian product <math>T_1 \times \cdots \times T_n</math> to <math>T</math>.

The example above also shows how to introduce type names.
A name like <code>UnaryFunType</code> above is just an abbreviation for the type <math>\mathrm{INT} \to \mathrm{REAL}</math> and can be used interchangeably with it.

In general, any type defined by a type expression <code>E</code> can be given a name with the declaration:

name : TYPE = E;

=== Type Checking ===

In CVC4, formulas and terms are statically typed at the level of types
(as opposed to subtypes) according to the usual rules of first-order many-sorted logic,
with the main difference that formulas are just terms of type <math>BOOLEAN</math>:

* each variable has one associated first-order type,
* each constant symbol has one or more associated first-order types,
* each function symbol has one or more associated function types,
* the type of a term consisting just of a variable is the type associated to that variable,
* the type of a term consisting just of a constant symbol is the type associated to that constant symbol,
* the term obtained by applying a function symbol <math>f</math> to the terms <math>t_1, \ldots, t_n</math> is <math>T</math> if <math>f</math> has type <math>(T_1, \ldots, T_n) \to T</math> and each <math>t_i</math> has type <math>T_i</math>.

Attempting to enter an ill-typed term will result in an error.

Another significant difference with standard many-sorted logic is that
some built-in symbols are parametrically polymorphic.
For instance, the function symbol for extracting the element of any array has
type <math>(\mathit{ARRAY}\ T_1\ \mathit{OF}\ T_2,\; T_1) \to T_2</math>
for all first-order types <math>T_1, T_2</math>.

==== Type Ascription ====

By the type inference rules above some terms might have more than one type.
This can happen with terms built with polymorphic data type constructors
that have more than one return type for the same input type.
In that case, a type ascription operator (<code>::</code>) must be applied
to the constructor to specify the intended return type.

DATATYPE [X]
List[X] = nil | cons (head: X, tail: List[X])
END;

ASSERT y = cons(1, nil::List[REAL]);

DATATYPE [X, Y]
Union[X, Y] = left(val_l: X) | right(val_r: Y)
END;

ASSERT y = left::Union[BOOLEAN, REAL](TRUE);

The constant symbol <math>\mathrm{nil}</math> declared above has infinitely many types
(<math>\mathrm{List}[\mathrm{REAL}]</math>, <math>\mathrm{List}[\mathrm{BOOLEAN}]</math>,
<math>\mathrm{List}[[\mathrm{REAL}, \mathrm{REAL}]]</math>,
<math>\mathrm{List}[\mathrm{List}[\mathrm{REAL}]]</math>, ...)
CVC4's type checker requires the user to indicate explicitly the type
of each occurrence of <code>nil</code> in a term.
Similarly,
the injection operator <code>left</code> has infinitely many return types
for the same input type, for instance:
<math>\mathrm{BOOLEAN} \to \mathrm{Union}[\mathrm{BOOLEAN}, \mathrm{REAL}]</math>,
<math>\mathrm{BOOLEAN} \to \mathrm{Union}[\mathrm{BOOLEAN}, [\mathrm{REAL}, \mathrm{REAL}]]</math>,
<math>\mathrm{BOOLEAN} \to \mathrm{Union}[\mathrm{BOOLEAN}, \mathrm{List}[\mathrm{REAL}]]</math>,
and so on.
Applications of <code>left</code> need to specify the intended returned typed, as shown above.

== Terms and Formulas ==

In addition to type expressions, CVC4 has expressions for terms and for formulas
(i.e., terms of type <math>\mathrm{BOOLEAN}</math>).
By and large, these are standard first-order terms built out of typed variables,
predefined theory-specific operators, free (i.e., user-defined) function symbols,
and quantifiers.
Extensions include an if-then-else operator, lambda abstractions, and local symbol
declarations, as illustrated below.
Note that these extensions still keep CVC4's language first-order.
In particular, lambda abstractions are restricted to take and return only terms of
a first-order type.
Similarly, variables can only be of a first-order type.

A number of built-in function symbols (for instance, the arithmetic ones) are used
as infix operators. All user-defined symbols are used as prefix ones.

User-defined, i.e., free, function symbols include ''constant symbols'' and
''predicate symbols'', respectively nullary function symbols and function symbols
with a <math>\mathrm{BOOLEAN}</math> return type.
These symbols are introduced with global declarations of the form
<math> f_1, \ldots, f_m: T;</math>
where <math>m > 0</math>, <math>f_i</math> are the names of the symbols and
<math>T</math> is their type:

% integer constants

a, b, c: INT;

% real constants

x, y, z: REAL;

% unary function

f1: REAL -> REAL;

% binary function

f2: (REAL, INT) -> REAL;

% unary function with a tuple argument

f3: [INT, REAL] -> BOOLEAN;

% binary predicate

p: (INT, REAL) -> BOOLEAN;

% Propositional "variables"

P, Q; BOOLEAN;

Like type declarations, function symbol declarations like the above have global scope
and must be unique.
In other words, it is not possible to declare a function symbol globally more than once
in the same lexical scope.
This entails among other things that globally-defined free symbols cannot be overloaded
with different types and that theory symbols cannot be redeclared globally as free symbols.

=== Global symbol definitions ===

As with types, a function symbol can be defined as the name of another term
of the corresponding type.
With constant symbols, this is done with a declaration of the form <math>f:T = t;</math> :

c: INT;

i: INT = 5 + 3*c; % i is effectively a shorthand for 5 + 3*c

j: REAL = 3/4;

t: [REAL, INT] = (2/3, -4);

r: [# key: INT, value: REAL #] = (# key := 4, value := (c + 1)/2 #);

f: BOOLEAN = FORALL (x:INT): x <= 0 OR x > c ;

A restriction on constants of type <math>\mathit{BOOLEAN}</math> is that their value
can only be a closed formula, that is, a formula with no free variables.

A term and its name can be used interchangeably in later expressions.
Named terms are often useful for shared subterms (terms used several times in different places)
since their use can make the input exponentially more concise.
Named terms are processed very efficiently by CVC4.
It is much more efficient to associate a complex term with a name directly rather than
to declare a constant and later assert that it is equal to the same term.
This point is explained in more detail later in section [[Commands | Commands]].

More generally, in CVC4 one can associate a term to function symbols of any arity.
For non-constant function symbols this is done with a declaration of the form

<center>
<math>f:(T_1, \ldots, T_n) \to T = \mathrm{LAMBDA}(x_1:T_1, \ldots, x:T_n): t\;;</math>
</center>

where <math>t</math> is any term of type <math>T</math> with free variables
in <math>\{x_1, \ldots, x_n\}</math>.
The lambda binder has the usual semantics and conforms to the usual lexical scoping rules:
within the term <math>t</math> the declaration of the symbols <math>x_1, \ldots, x_n</math>
as local variables of respective type <math>T_1, \ldots, T_n</math> hides any previous
declarations of those symbols that are in scope.

As a general shorthand, when <math>k</math> consecutive types
<math>T_i, \ldots, T_{i+k-1}</math> in the lambda expression
<math>\mathrm{LAMBDA}(x_1:T_1, \ldots, x:T_n): t</math> are identical, the syntax
<math>\mathrm{LAMBDA}(x_1:T_1, \ldots, x_i,\ldots, x_{i+k-1}:T_i,\ldots, x:T_n): t</math>
can also be used.

% Global declaration of x as a unary function symbol

x: REAL -> REAL;

% Local declarations of x as variable (hiding the global one)

f: REAL -> REAL = LAMBDA (x: REAL): 2*x + 3;

p: (INT, INT) -> BOOLEAN = LAMBDA (x,i: INT): i*x - 1 > 0;

g: (REAL, INT) -> [REAL, INT] = LAMBDA (x: REAL, i:INT): (x + 1, i - 3);

Note that lambda definitions are not recursive:
the symbol being defined cannot occur in the body of the lambda term.
They should be understood as macros.
For instance, any occurrence of the term <math>f(t)</math>
where <math>f</math> is as defined above will be treated
as if it was the term <math>(2*t + 3)</math>.

=== Local symbol definitions ===

Constant and function symbols can also be declared locally anywhere within a term
by means of a let binder.
This is done with a declaration of the form

<center>
<math>
\mathrm{LET}\ f = s \ \mathrm{IN}\ t ;
</math>
</center>

where <math>t</math> is a term with no free variables, possibly a lambda term.
Let binders can be nested arbitrarily and follow the usual lexical scoping rules.
The following general form
<center>
<math>
\mathrm{LET}\ f_1 = t_1, f_2 = t_2, \ldots, f_n = t_m \ \mathrm{IN}\ t ;
</math>
</center>
can used as a shorthand for
<center>
<math>
\mathrm{LET}\ f_1 = t_1\ \mathrm{IN}\
\mathrm{LET}\ f_2 = t_2\ \mathrm{IN}\
\ldots \
\mathrm{LET}\ f_n = t_m \ \mathrm{IN}\ t ;
</math>
</center>

t: REAL =
LET x1 = 42,
g = LAMBDA(x:INT): x + 1,
x2 = 2*x1 + 7/2
IN
(LET x3 = g(x1) IN x3 + x2) / x1;

Note that the same symbol = is used, unambiguously, in the syntax of global declarations,
let declarations, and as a predicate symbol.

'''Note:'''
A <math>\mathrm{LET}</math> term with a multiple symbols defines them sequentially.
A parallel version of the <math>\mathrm{LET}</math> construct will be introduced in a later version.

== Built-in theories and their symbols ==

In addition to user-defined symbols, CVC4 terms can use a number of predefined symbols:
the logical symbols, such as <math>\mathrm{AND}</math>, <math>\mathrm{OR}</math>, etc.,
as well as theory symbols, function symbols belonging to one of the built-in theories.
They are described next, with the theory symbols grouped by theory.

=== Logical Symbols ===

The logical symbols in CVC4's language include
the equality and disequality predicate symbols, respectively written as = and /=,
the multiarity disequality symbol <math>\mathrm{DISTINCT}</math>,
together with the logical constants <math>\mathrm{TRUE}</math>, <math>\mathrm{FALSE}</math>,
the connectives <math>\mathrm{NOT}</math>, <math>\mathrm{AND}</math>, <math>\mathrm{OR}</math>, <math>\mathrm{XOR}</math>, <math>\Rightarrow</math>, <math>\Leftrightarrow</math>, and
the first-order quantifiers <math>\mathrm{EXISTS}</math> and <math>\mathrm{FORALL}</math>,
all with the standard many-sorted logic semantics.

The binary connectives have infix syntax and type
<math>(\mathrm{BOOLEAN},\mathrm{BOOLEAN}) \to \mathrm{BOOLEAN}</math>.
The symbols = and /=, which are also infix, are instead parametrically polymorphic,
having type <math>(T,T) \to \mathrm{BOOLEAN}</math>
for every first-order type <math>T</math>.
They are interpreted respectively as the identity relation and its complement.

The DISTINCT symbol is both overloaded and polymorphic.
It has type <math>(T,...,T) \to \mathrm{BOOLEAN}</math>
for every sequence <math>(T,...,T)</math> of length <math>n > 0</math>
and first-order type <math>T</math>.
For each <math>n > 0</math>, it is interpreted as the relation
that holds exactly for tuples of pairwise distinct elements.

The syntax for quantifiers is similar to that of the lambda binder.

Here is an example of a formula built just of these logical symbols and variables:

A, B: TYPE;

q: BOOLEAN = FORALL (x,y: A, i,j,k: B):
i = j AND i /= k => EXISTS (z: A): x /= z OR z /= y;

Binding and scoping of quantified variables follows the same rules as
in let expressions.
In particular, a quantifier will shadow in its scope any constant and function symbols
with the same name as one of the variables it quantifies:

A: TYPE;
i, j: INT;

% The first occurrence of i and of j in f are constant symbols,
% the others are variables.

f: BOOLEAN = i = j AND FORALL (i,j: A): i = j OR i /= j;

Optionally, it is also possible to specify instantiation patterns
for quantified variables.
The general syntax for a quantified formula <math>\psi</math> with patterns is

<center>
<math>
Q\;(x_1:T_1, \ldots, x_k:T_k):\; p_1: \ldots\; p_n:\; \varphi
</math>
</center>

where <math>n \geq 0</math>, <math>Q</math> is
either <math>\mathrm{FORALL}</math> or <math>\mathrm{EXISTS}</math>,
<math>\varphi</math> is a term of type <math>\mathrm{BOOLEAN}</math>,
and each of the <math>p_i</math>'s,
a pattern for the quantifier <math>Q\;(x_1:T_1, \ldots, x_k:T_k)</math>, has the form

<center>
<math>
\mathrm{PATTERN}\; (t_1, \ldots, t_m)
</math>
</center>

where <math>m > 0</math> and <math>t_1, \ldots, t_m</math> are
arbitrary binder-free terms (no lets, no quantifiers).
Those terms can contain (free) variables, typically, but not exclusively,
drawn from <math>x_1, \ldots, x_k</math>.
(Additional variables can occur if <math>\psi</math> occurs in a bigger formula
binding those variables.)

A: TYPE;
b, c: A;
p, q: A -> BOOLEAN;
r: (A, A) -> BOOLEAN;

ASSERT FORALL (x0, x1, x2: A):
PATTERN (r(x0, x1), r(x1, x2)):
(r(x0, x1) AND r(x1, x2)) => r(x0, x2) ;

ASSERT FORALL (x: A):
PATTERN (r(x, b)):
PATTERN (r(x, c)):
p(x) => q(x) ;

ASSERT EXISTS (y: A):
FORALL (x: A):
PATTERN (r(x, y), p(y)):
r(x, y) => q(x) ;

Patterns have no logical meaning:
adding them to a formula does not change its semantics.
Their purpose is purely operational, as explained in
the [[#Instantiation Patterns | Instantiation Patterns]] section.

In addition to these constructs, CVC4 also has a general mixfix conditional operator
of the form

<center>
<math>
\mathrm{IF}\ b\ \mathrm{THEN}\ t\ \mathrm{ELSIF}\ b_1\ \mathrm{THEN}\ t_1\ \ldots\ \mathrm{ELSIF}\ b_n\ \mathrm{THEN}\ t_n\ \mathrm{ELSE}\ t_{n+1}\ \mathrm{ENDIF}
</math>
</center>

with <math>n \geq 0</math> where
<math>b, b_1, \ldots, b_n</math> are terms of type <math>\mathrm{BOOLEAN}</math> and
<math>t, t_1, \ldots, t_n, t_{n+1}</math> are terms of the same first-order type <math>T</math>:

% Conditional term
x, y, z, w: REAL;

t: REAL =
IF x > 0 THEN y
ELSIF x >= 1 THEN z
ELSIF x > 2 THEN w
ELSE 2/3 ENDIF;

=== User-defined Functions and Types ===

The theory of user-defined functions,also know in the SMT literature as
the theory ''Equality over Uninterpreted Functions'', or ''EUF'', is in effect
a family of theories of equality parametrized by the basic types and the free symbols
a user can define during a run of CVC4.

This theory has no built-in symbols (other than the logical ones).
Its types consist of ''all and only'' the user-defined types.
Its function symbols consist of ''all and only'' the user-defined free symbols.

=== Arithmetic ===

The real arithmetic theory has two types:
<math>\mathrm{REAL}</math> and <math>\mathrm{INTEGER}</math>
with the latter a subtype of the first.
Its built-in symbols for the usual arithmetic constants
and operators over the type <math>\mathrm{REAL}</math>, each with the expected type:
all numerals 0, 1, ..., as well as - (both unary and binary), +, *, /, <, >, <=, >=.
Application of the binary symbols are in infix form.
Note that + is only binary, and so an expression such as +4 is ill-formed.

Rational values can be expressed in decimal or fractional format,
e.g., 0.1, 23.243241, 1/2, 3/4, and so on.
A leading 0 is mandatory for decimal numbers smaller than one
(e.g., the syntax .3 cannot be used as a shorthand for 0.3).
However, a trailing 0 is ''not'' required for decimals that are whole numbers
(e.g., 3. is allowed as a shorthand for 3.0).
The size of the numerals used in the representation of natural and rational numbers
is unbounded; more accurately, bounded only by the amount of available memory.

=== Bit vectors ===

=== Arrays ===

The theory of arrays is a parametric theory of (total) unary maps.
It comes equipped with mixfix polymorphic selection and update operators, respectively
<center>
<math>\_[\_]</math> and <math>\_\ \mathrm{WITH}\ [\_]\ := \_</math> .
</center>
The semantics of these operators is the expected one:
for all first-order types <math>T_1</math> and <math>T_2</math>,
if <math>a</math> is of type <math>\mathrm{ARRAY}\ T_1 \mathrm{OF}\ T_2</math>,
<math>i</math> is of type <math>T_1</math>, and
<math>v</math> is of type <math>T_2</math>,
* <math>a[i]</math> denotes the value that <math>a</math> associates to index <math>i</math>,
* <math>a\ \mathrm{WITH}\ [i]\ := v</math> denotes a map that associates <math>v</math> to index <math>i</math> and is otherwise identical to <math>a</math>.
Sequential updates can be chained with the shorthand syntax
<math>\_\ \mathrm{WITH}\ [\_]\ := \_, \ldots, [\_]\ := \_</math>.

A: TYPE = ARRAY INT OF REAL;
a: A;
i: INT = 4;

% selection:

elem: REAL = a[i];

% update

a1: A = a WITH [10] := 1/2;

% sequential update
% (syntactic sugar for (a WITH [10] := 2/3) WITH [42] := 3/2)

a2: A = a WITH [10] := 2/3, [42] := 3/2;

Since arrays are just maps, equality between them is extensional, that is,
for two arrays of the same type to be different they have to map at least one
index to differ values.

=== Data types ===

The theory of inductive data types is in fact a family of theories parametrized
by a data type declaration specifying constructors and selectors
for one or more user-defined data types.

No built-in operators other than equality and disequality are provided
for this family in the native language.
Each user-provided data type declaration, however, generates constructor, selector and tester operators
as described in the [[#Inductive Data Types | Inductive Data Types]] section.

=== Tuples and Records ===

Semantically both records and tuples can be seen as special instances
of inductive data types.
CVC4 implements them internally indeed as data types.
In essence, a record type <math>[\#\ l_0:T_0, \ldots, l_n:T_n\ \#]</math>
is encoded as a data type of the form

<center>
<math>
\begin{array}{l}
\mathrm{DATATYPE} \\
\ \ \mathrm{Record} = \mathit{rec}(l_0:T_0, \ldots, l_n:T_n) \\
\mathrm{END};
\end{array}
</math>
</center>

Tuples of length <math>n</math> are in turn special cases of records whose field names are
the numerals from <math>0</math> to <math>n-1</math>.

Externally, tuples and records have their own syntax for constructor and selector operators.
* Records of type <math>[\#\ l_0:T_0, \ldots, l_n:T_n\ \#]</math> have the associated record constructor <math>(\#\ l_0 := \_,\; \ldots,\; l_n := \_\ \#)</math> whose arguments must be terms of type <math>T_0, \ldots, T_n</math>, respectively.
* Tuples of type <math>[\ T_0, \ldots, T_n\ ]</math> have the associated tuple constructor <math>(\ \_,\; \ldots,\; \_\ )</math> whose arguments must be terms of type <math>T_0, \ldots, T_n</math>, respectively.

The selector operators on records and tuples follows a dot notation syntax.

% Record construction and field selection
Item: TYPE = [# key: INT, weight: REAL #];

x: Item = (# key := 23, weight := 43/10 #);
k: INT = x.key;
v: REAL = x.weight;

% Tuple construction and projection
y: [REAL, INT, REAL] = ( 4/5, 9, 11/9 );
first_elem: REAL = y.0;
third_elem: REAL = y.2;

Differently from data types, records and tuples are also provided with built-in update operators similar in syntax and semantics to the update operator for arrays.
More precisely, for each record type <math>[\#\ l_0:T_0, \ldots, l_n:T_n\ \#]</math> and
each <math>i=0, \ldots, n</math>, CVC4 provides the operator

<center>
<math>
\_\ \mathrm{WITH}\ .l_i\ := \_
</math>
</center>

The operator maps a record <math>r</math> of that type and a value <math>v</math>
of type <math>T_i</math> to the record that stores <math>v</math> in field <math>l_i</math>
and is otherwise identical to <math>r</math>.
Analogously, for each tuple type <math>[T_0, \ldots, T_n]</math> and
each <math>i=0, \ldots, n</math>, CVC4 provides the operator

<center>
<math>
\_\ \mathrm{WITH}\ .i\ := \_
</math>
</center>

with similar semantics.

% Record updates

Item: TYPE = [# key: INT, weight: REAL #];

x: Item = (# key := 23, weight := 43/10 #);

x1: Item = x WITH .weight := 48;

% Tuple updates

Tup: TYPE = [REAL,INT,REAL];
y: Tup = ( 4/5, 9, 11/9 );
y1: Tup = y WITH .1 := 3;

Updates to a nested component can be combined in a single WITH operator:

Cache: TYPE = ARRAY [0..100] OF [# addr: INT, data: REAL #];
State: TYPE = [# pc: INT, cache: Cache #];

s0: State;
s1: State = s0 WITH .cache[10].data := 2/3;

Note that, differently from updates on arrays, tuple and record updates are
just additional syntactic sugar.
For instance, the record <code>x1</code> and tuple <code>y1</code> defined above
could have been equivalently defined as follows:

% Record updates

Item: TYPE = [# key: INT, weight: REAL #];

x: Item = (# key := 23, weight := 43/10 #);

x1: Item = (# key := x.key, weight := 48 #);

% Tuple updates

Tup: TYPE = [REAL,INT,REAL];
y: Tup = ( 4/5, 9, 11/9 );
y1: Tup = ( y.0, 3, y.1 );

== Commands ==

In addition to declarations of types and function symbols,
the CVC4 native language contains the following commands:

* <math>\mathrm{ASSERT}\ F</math> -- Add the formula <math>F</math> to the current logical context <math>\Gamma</math>.
* [[#CHECKSAT|<math>\mathrm{CHECKSAT}\ F</math>]] -- Check if the formula <math>F</math> is satisfiable in the current logical context (<math>\Gamma \not\models_T \mathrm{NOT}\ F</math>).
* <math>\mathrm{CONTINUE}</math> -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, search for a counter-example different from the current one.
* [[#COUNTEREXAMPLE|<math>\mathrm{COUNTEREXAMPLE}</math>]] -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, print the context that is a witness for invalidity/satisfiability.
* [[#COUNTERMODEL|<math>\mathrm{COUNTERMODEL}</math>]] -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, print a model that makes the formula invalid/satisfiable. The model is provided in terms of concrete values for each free symbol.
* <math>\mathrm{OPTION}\ o\ v</math> -- Set the command-line option flag <math>o</math> to value <math>v</math>. The argument <math>o</math> is provide as a string literal enclosed in double-quotes and <math>v</math> as an integer value.
* <math>\mathrm{POP}</math> -- Equivalent to <math>\mathrm{POPTO}\ 1</math>
* [[#POPTO|<math>\mathrm{POPTO}\ n</math>]] -- Restore the system to the state it was in right before the most recent call to <math>\mathrm{PUSH}</math> made from stack level <math>n</math>. Note that the current stack level is printed as part of the output of the <math>\mathrm{WHERE}</math> command.
* <math>\mathrm{PUSH}</math> -- Save (checkpoint) the current state of the system.
* [[#QUERY|<math>\mathrm{QUERY}\ F</math>]] -- Check if the formula <math>F</math> is valid in the current logical context (<math>\Gamma\models_T F</math>).
* [[#RESTART|<math>\mathrm{RESTART}\ F</math>]] -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, repeat the check but with the additional assumption <math>F</math> in the context.
* <math>\mathrm{PRINT}\ t</math> -- Parse and print back the term <math>t</math>.
* <math>\mathrm{TRANSFORM}\ t</math> -- Simplify the term <math>t</math> and print the result.
* <math>\mathrm{WHERE}</math> -- Print all the formulas in the current logical context <math>\Gamma</math>.

The remaining commands take a single argument, given as a string literal enclosed in double-quotes.

* <math>\mathrm{ECHO}\ s</math> -- Print string <math>s</math>
* <math>\mathrm{INCLUDE}\ f</math> -- Read commands from file <math>f</math>.
* <math>\mathrm{TRACE}\ f</math> -- Turn on tracing for the debug flag <math>f</math>.
* <math>\mathrm{UNTRACE}\ f</math> -- Turn off tracing for the debug flag <math>f</math>.

Here, we explain some of the above commands in more detail.

=== QUERY ===

The command <math>\mathrm{QUERY}\ F</math> invokes the core functionality of CVC4 to check
the validity of the formula <math>F</math> with respect to the assertions made thus far,
which constitute the context <math>\Gamma</math>.
The argument <math>F</math> must be well typed term of type <math>\mathrm{BOOLEAN}</math>,
as described in [[#Terms and Formulas | Terms and Formulas]].

The execution of this command always terminates and produces one of three possible answers:
<code>valid</code>, <code>invalid</code>, and <code>unknown</code>.

* A <code>valid</code> answer indicates that <math>\Gamma \models_T F</math>. After a query returning such an answer, the logical context <math>\Gamma</math> is exactly as it was before the query.
* An <code>invalid</code> answer indicates that <math>\Gamma \not\models_T F</math>, that is, there is a model of the background theory <math>T</math> that satisfies <math>\Gamma \cup \{\mathrm{NOT}\ F\}</math>. When <math>\mathrm{QUERY}\ F</math> returns <code>invalid</code>, the logical context <math>\Gamma</math> is augmented with a set <math>\Delta</math> of ground (i.e., variable-free) literals such that <math>\Gamma\cup\Delta</math> is satisfiable in <math>T</math>, but <math>\Gamma\cup\Delta\models_T \mathrm{NOT}\ F</math>. In fact, in this case <math>\Delta</math> ''propositionally entails'' <math>\mathrm{NOT}\ F</math>, in the sense that, every truth assignment to the literals of <math>\Delta</math> that satisfies <math>\Delta</math> falsifies <math>F</math>. We call the new context <math>\Gamma\cup\Delta</math> a ''counterexample'' for <math>F</math>.
* An <code>unknown</code> answer is similar to an <code>invalid</code> answer in that additional literals are added to the context which propositionally entail <math>\mathrm{NOT}\ F</math>. The difference in this case is that CVC4 cannot guarantee that <math>\Gamma\cup\Delta</math> is actually satisfiable in <math>T</math>.

CVC4 may report <code>unknown</code> when the context or the query contains
non-linear arithmetic terms or quantifiers.
In all other cases, it is expected to be sound and complete,
i.e., to report <code>Valid</code> if <math>\Gamma \models_T F</math>
and <code>Invalid</code> otherwise.

After an <code>invalid</code> (resp. <code>unknown</code>) answer,
counterexamples (resp. possible counterexamples) can be obtained with
a <math>\mathrm{WHERE}</math>, <math>\mathrm{COUNTEREXAMPLE}</math>,
or <math>\mathrm{COUNTERMODEL}</math> command.


Since the <math>\mathrm{QUERY}</math> command may modify
the current context, if one needs to check several formulas in a row
in the same context, it is a good idea to surround every
query by a <math>\mathrm{PUSH}</math> and <math>\mathrm{POP}</math> invocation
in order to preserve the context:

PUSH;
QUERY <formula>;
POP;

=== CHECKSAT ===

The command <math>\mathrm{CHECKSAT}\ F</math> behaves identically
to <math>\mathrm{QUERY}\ \mathrm{NOT}\ F</math>.

=== RESTART ===

The command <math>\mathrm{RESTART}\ F</math> can only be invoked after an invalid query.
For example, in an interactive setting:

QUERY <formula>;

CVC4> invalid

RESTART <formula2>;

Functionally, the behavior of the above command sequence is identical to the following:

PUSH;
QUERY <formula>;
POP;
ASSERT <formula2>;
QUERY <formula>;

The advantage of using the <math>\mathrm{RESTART}</math> command is that
the first command sequence may be executed much more efficiently that the second.
The reason is that with <math>\mathrm{RESTART}</math> CVC4 will re-use
what it has learned while answering the previous query rather than starting
over from scratch.

=== COUNTERMODEL ===

[More]

=== COUNTEREXAMPLE ===

[More]

=== POPTO ===

[More]

== Instantiation Patterns ==

CVC4 processes each universally quantified formula in the current context
by adding instances of the formula obtained by replacing its universal variables
with ground terms.
Patterns restrict the choice of ground terms for the quantified variables,
with the goal of controlling the potential explosion of ground instances.
In essence, adding patterns to a formula is a way for the user to tell CVC4
to focus only on certain instances which, in the user's opinion, will be
most helpful during a proof.

In more detail, patterns have the following effect on formulas that are found
in the logical context or get added to it later while CVC4 is trying to prove
the validity of some formula <math>F</math>.

If a formula in the current context starts with an existential quantifier,
CVC4 ''Skolemizes'' it, that is, replaces it in the context with the formula
obtained by substituting the existentially quantified variables
by fresh constants and dropping the quantifier.
Any patterns for the existential quantifier are simply ignored.

If a formula starts with a universal quantifier
<math>\mathrm{FORALL}\; (x_1:T_1, \ldots, x_n:T_n)</math>,
CVC4 adds to the context a number of instances of the formula,
with the goal of using them to prove the query <math>F</math> valid.
An instance is obtained by replacing each <math>x_i</math> with a ground term
of the same type occurring in one of the formulas in the context,
and dropping the universal quantifier.
If <math>x_i</math> occurs in a pattern
<math>\mathrm{PATTERN}\; (t_1, \ldots, t_m)</math> for the quantifier,
it will be instantiated only with terms obtained by simultaneously matching
all the terms in the pattern against ground terms in the current context
<math>\Gamma</math>.

Specifically, the matching process produces one or more substitutions
<math>\sigma</math> for the variables in <math>(t_1, \ldots, t_m)</math>
which satisfy the following invariant:
for each <math>i = 1, \ldots, m</math>, <math>\sigma(t_i)</math> is
a ground term and there is a ground term <math>s_i</math> in <math>\Gamma</math>
such that <math>\Gamma \models_T \sigma(t_i) = s_i</math>.
The variables of <math>(x_1:T_1, \ldots, x_n:T_n)</math> that occur
in the pattern are instantiated only with those substitutions
(while any remaining variables are instantiated arbitrarily).

The Skolemized version or the added instances of a context formula may themselves
start with a quantifier.
The same instantiation process is applied to them too, recursively.

Note that the matching mechanism is not limited to syntactic matching
but is modulo the equations asserted in the context.
Because of decidability and/or efficiency limitations, the matching process
is not exhaustive.
CVC4 will typically miss some substitutions that satisfy the invariant above.
As a consequence, it might fail to prove the validity of the query formula
<math>F</math>, which makes CVC4 incomplete for contexts containing
quantified formulas.
It should be noted though that exhaustive matching, which can be achieved
simply by not specifying any patterns, does not yield completeness anyway
since the instantiation of universal variables is still restricted
to just the ground terms in the context,
whereas in general additional ground terms might be needed.

CVC4's native language

2012-12-01T18:11:26Z

Clark Barrett: /* The INT Type */

= CVC4 native input language =

The native input language consists of a sequence of symbol declarations and commands, each followed by a semicolon (<code>;</code>).

Any text after the first occurrence of a percent character and to the end of the current line is a comment:

%%% This is a native language comment

== Type System ==

CVC4's type system includes a set of built-in types which can be expanded with additional user-defined types.

The type system consists of ''first-order'' types, ''subtypes'' of first-order types, and ''higher-order'' types, all of which are interpreted as sets.
For convenience, we will sometimes identify below the interpretation of a type with the type itself.

First-order types consist of basic types and structured types. The basic types are <math>\mathrm{BOOLEAN}</math>, <math>\mathrm{REAL}</math>, <math>\mathrm{BITVECTOR}(n)</math> for all <math>n > 0</math>, as well as user-defined basic types (also called uninterpreted types).
The structured types are array, tuple, record types, and ML-style user-defined (inductive) datatypes.

'''Note:''' Currently, subtypes consist only of the built-in subtype <math>\mathrm{INT}</math> of <math>\mathrm{REAL}</math>.

Support for CVC3-style user-defined subtypes will be added in a later release.

Function types are the only higher-order types.
More precisely, they are just second-order types
since function symbols in CVC4, both built-in and user-defined, can take as argument or return only values of
a first-order type.

=== Basic Types ===

==== The BOOLEAN Type ====

The <math>\mathrm{BOOLEAN}</math> type is interpreted as the two-element set of Boolean values
<math>\{\mathrm{TRUE},\; \mathrm{FALSE}\}</math>.

'''Note:''' CVC4's treatment of this type differs from CVC3's where <math>\mathrm{BOOLEAN}</math> is used only as the type of formulas, but not as value type. CVC3 follows the two-tiered structure of classical first-order logic
which distinguishes between formulas and terms, and allows terms to occur in formulas but not vice versa (with the exception of the IF-THEN-ELSE construct).
CVC4 drops the distinction between terms and formulas and defines the latter just as terms of type <math>\mathrm{BOOLEAN}</math>. As such, formulas can occur as subterms of possibly non-Boolean terms.

Example:

[To do]

==== The REAL Type ====

The <math>\mathrm{REAL}</math> type is interpreted as the set of real numbers.

Note that these are the (infinite precision) mathematical reals,
not the floating point numbers.
Support for floating point types is planned for future versions.

x, y : REAL;
QUERY (( x <= y ) AND ( y <= x )) => ( x = y );

==== The INT Type ====

The <math>\mathrm{INT}</math> type is interpreted as the set of integer numbers
and is considered a subtype of <math>\mathrm{REAL}</math>.
The latter means in particular that it is possible to mix integer and real terms
in expressions without the need of an explicit ''upcasting'' operator.

Note that these are the (infinite precision) mathematical integers,
not the finite precision machine integers used in most programming languages.
The latter are modeled by [[ #Bitvectors | bit vector ]] types.

x, y : INT;
QUERY ((2 * x + 4 * y <= 1) AND ( y >= x)) => (x <= 0);
z : REAL;
QUERY (2 * x + z <= 3.5) AND (z >= 1);

==== Bit Vector Types ====

For every positive integer <math>n</math>, the type <math>\mathrm{BITVECTOR}(n)</math> is interpreted as the set of all bit vectors of size <math>n</math>.
A rich set of bit vector operators is supported.

==== User-defined Basic Types ====

Users can define new basic types
(often referred to as ''uninterpreted'' types in the SMT literature).
Each such type is interpreted as a set of unspecified cardinality
but disjoint from any other type.

User-defined basic types are created by declarations like the following:

% User declarations of basic types:

MyBrandNewType: TYPE;

Apples, Oranges: TYPE;

=== Structured Types ===

CVC4's structured types are divided in the following families.

==== Array Types ====

Array types are created by the mixfix type constructors <math>\mathrm{ARRAY}\ \_\ \mathrm{OF}\ \_</math>
whose arguments can be instantiated by any value type.

I : TYPE;

%% Array types:

% Arrays with indices from I and values from REAL
Array1: TYPE = ARRAY I OF REAL;

% Arrays with integer indices and array values
Array2: TYPE = ARRAY INT OF (ARRAY INT OF REAL);

% Arrays with integer pair indices and integer values
IntMatrix: TYPE = ARRAY [INT, INT] OF INT;

An array type of the form <math>\mathrm{ARRAY}\ T_1\ \mathrm{OF}\ T_2</math> is interpreted
as the set of all total maps from <math>T_1</math> to <math>T_2</math>.
The main difference with the function type <math>T_1 \to T_2</math> is that arrays,
contrary to functions, are first-class objects of the language, that is, values of an array
type can be arguments or results of functions.
Furthermore, array types come equipped with an update operation.

==== Tuple Types ====

Tuple types are created by the mixfix type constructors

<center>
<math>
\begin{array}{l} [\ \_\ ] \\[1ex] [\ \_\ ,\ \_\ ] \\[1ex] [\ \_\ ,\ \_\ \ ,\ \_\ ] \\[1ex] \ldots \end{array}
</math>
</center>

whose arguments can be instantiated by any value type.

IntArray: TYPE = ARRAY INT OF INT;

% Tuple type declarations

RealPair: TYPE = [REAL, REAL]

MyTuple: TYPE = [ REAL, IntArray, [INT, INT] ];

A tuple type of the form <math>[T_1, \ldots, T_n]</math> is interpreted
as the Cartesian product <math>T_1 \times \cdots \times T_n</math>.

Note that while the types <math>(T_1, \ldots, T_n) \to T</math> and
<math>[T_1 \times \cdots \times T_n] \to T</math> are semantically equivalent,
they are operationally different in CVC4.
The first is the type of functions that take <math>n</math> arguments
of respective type <math>T_1</math>, <math>\ldots</math>, <math>T_n</math>,
while the second is the type of functions that take one argument of an <math>n</math>-tuple type.

==== Record Types ====

Similar to, but more general than tuple types, record types are created by type constructors of the form

<center>
<math>
[\#\ l_1: \_\ ,\ \ldots\ ,\ l_n: \_\ \#]
</math>
</center>

where <math>n > 0</math>, <math>l_1,\ldots, l_n</math> are field labels,
and the arguments can be instantiated with any first-order types.

MyType: TYPE;

% Record declaration

RecordType: TYPE = [# id: REAL, age: INT, info: MyType #];

The order of the fields in a record type is meaningful:
permuting the field names gives a different type.

Note that record types are non-recursive.
For instance, it is not possible to declare a record type called <code>Person</code> containing
a field of type <code>Person</code>.
Recursive types are provided in CVC4 by the more general inductive data types.
(As a matter of fact, both record and tuple types are implemented internally as inductive data types.)

==== Inductive Data Types ====

Inductive data types in CVC4 are similar to inductive data types of functional languages.
They can be parametric or not.

===== Non-Parametric Data Types =====

Non-parametric data types are created by declarations of the form
<center>
<math>
\begin{array}{l}
\mathrm{DATATYPE} \\
\begin{array}{ccc}
\ \ A_1 & = & C_{1,1} \mid C_{1,2} \mid \cdots \mid C_{1,m_1}, \\
\ \ A_2 & = & C_{2,1} \mid C_{2,2} \mid \cdots \mid C_{2,m_2}, \\
\ \ \vdots & = & \vdots \\
\ \ A_n & = & C_{n,1} \mid C_{n,2} \mid \cdots \mid C_{n,m_n} \\
\end{array}
\\
\mathrm{END};
\end{array}
</math>
</center>
where
each <math>A_i</math> is a type name and
each <math>C_{ij}</math> is either a constant symbol or an expression of the form
<center>
<math>\mathit{cons}(\ \mathit{sel}_1: T_1,\ \ldots,\ \mathit{sel}_k: T_k\ )
</math>
</center>
where <math>T_1, \ldots, T_k</math> are any first-order types, including any <math>A_i</math>.
Such declarations define the data types <math>A_1, \ldots, A_n</math>.
For each data type <math>A_i</math> they introduce:

* constructor symbols <math>cons</math> of type <math>(T_1, \ldots, T_k) \to \mathit{type\_name}_i</math>,
* selector symbols <math>\mathit{sel}_j</math> of type <math>\mathit{type\_name}_i \to T_j</math>, and
* tester symbols <math>\mathit{is\_cons}</math> of type <math>\mathit{type\_name}_i \to \mathrm{BOOLEAN}</math>.

Note that permitting more than one data type to be defined in the same declarations allows
the definition of mutually recursive types.

% simple enumeration type

% implicitly defined are the testers: is_red, is_yellow and is_blue
% (similarly for the other data types)

DATATYPE
PrimaryColor = red | yellow | blue
END;

% infinite set of pairwise distinct values ..., v(-1), v(0), v(1), ...

DATATYPE
Id = v (id: INT)
END;

% ML-style integer lists

DATATYPE
IntList = nil | ins (head: INT, tail: IntList)
END;

% AST for lamba calculus

DATATYPE
Term = var (index: INT)
| apply (arg_1: Term, arg_2: Term)
| lambda (arg: INT, body: Term)
END;

% Trees

DATATYPE
Tree = tree (value: REAL, children: TreeList),
TreeList = nil_tl
| ins_tl (first_t1: Tree, rest_t1: TreeList)
END;

Constructor, selector and tester symbols defined for a data type have global scope.
So, for example, it is not possible for two different data types to use
the same name for a constructor.

An inductive data type is interpreted as a term algebra constructed by the constructor symbols
over some sets of generators.
For example, the type <code>IntList</code> defined above is interpreted as the set
of all terms constructed with <code>nil</code> and <code>ins</code> over the integers.

===== Parametric Data Types =====

Parametric data types are infinite families of (non-parametric) data types
with each family parametrized by one or more type variables.
They are created by declarations of the form
<center>
<math>
\begin{array}{l}
\mathrm{DATATYPE} \\
\begin{array}{ccc}
\ \ A_1[X_{1,1}, \ldots, X_{1,p_1}] & = & C_{1,1} \mid C_{1,2} \mid \cdots \mid C_{1,m_1}, \\
\ \ A_2[X_{2,1}, \ldots, X_{2,p_2}] & = & C_{2,1} \mid C_{2,2} \mid \cdots \mid C_{2,m_2}, \\
\ \ \vdots & = & \vdots \\
\ \ A_n[X_{n,1}, \ldots, X_{n,p_n}] & = & C_{n,1} \mid C_{n,2} \mid \cdots \mid C_{n,m_n} \\
\end{array}
\\
\mathrm{END};
\end{array}
</math>
</center>
where
each <math>A_i</math> is a type name parametrized by the type variables <math>X_{i,1}, \ldots, X_{i,p_i}</math>
and
each <math>C_{ij}</math> is either a constant symbol or an expression of the form
<center>
<math>\mathit{cons}(\ \mathit{sel}_1: T_1,\ \ldots,\ \mathit{sel}_k: T_k\ )
</math>
</center>
where <math>T_1, \ldots, T_k</math> are any first-order types,
possibly parametrized by <math>X_1, \ldots, X_p</math>, including any <math>A_i</math>.

% Parametric pairs
DATATYPE
Pair[X, Y] = pair (first: X, second: Y)
END;

% Parametric lists

DATATYPE
List[X] = nil | cons (head: X, tail: List[X])
END;

% Parametric trees using the list type above

DATATYPE
Tree[X] = node (value: X, children: List[Tree[X]]),
END;

The declarations above define infinitely many types of the form
Pair[S,T], List[T] and Tree[T] where S and T are first-order types.
Note that the identifier <code>List</code> above, for example, by itself does not denote a type.
In contrast, the terms <code>List[Real]</code>, <code>List[List[Real]]</code>, <code>List[Tree[INT]]</code>,
and so on do.

===== Restriction to Inductive Types =====

By adopting a term algebra semantics, CVC4 allows only ''inductive'' data types,
that is, data types whose values are essentially (labeled, ordered) finite trees.
Infinite structures such as streams or even finite but cyclic ones
such as circular lists are then excluded.
For instance, none of the following declarations define inductive data types,
and are rejected by CVC4:

DATATYPE
IntStream = s (first:INT, rest: IntStream)
END;

DATATYPE
RationalTree = node1 (child: RationalTree)
| node2 (left_child: RationalTree, right_child:RationalTree)
END;

DATATYPE
T1 = c1 (s1: T2),
T2 = c2 (s2: T1)
END;

In concrete, a declaration of <math>n \geq 1</math> datatypes <math>T_1, \ldots, T_n</math> will be rejected if for any one of the types <math>T_1, \ldots, T_n</math>, it is impossible to build a finite term of that type using only the constructors of <math>T_1, \ldots, T_n</math> and free constants of type other than <math>T_1, \ldots, T_n</math>.

Inductive data types are the only types where the user also chooses names for the built-in operations to:

* construct a value of the type (with the constructors),
* extract components from a value (with the selectors), or
* check if a value was constructed with a certain constructor or not (with the testers).

For all the other types, CVC4 provides predefined names for the built-in operations on the type.

=== Function Types ===

Function (<math>\to</math>) types are created by the mixfix type constructors
<center>
<math>
\begin{array}{l}
\_ \to \_ \\[1ex] (\ \_\ ,\ \_\ ) \to \_
\\[1ex] (\ \_\ ,\ \_\ ,\ \_\ ) \to \_
\\[1ex] \ldots
\end{array}
</math>
</center>
whose arguments can be instantiated by any first-order type.

% Function type declarations

UnaryFunType: TYPE = INT -> REAL;

BinaryFunType: TYPE = (REAL, REAL) -> ARRAY REAL OF REAL;

TernaryFunType: TYPE = (REAL, BITVECTOR(4), INT) -> BOOLEAN;

A function type of the form <math>(T_1, \ldots, T_n) \to T</math> with <math>n > 0</math> is interpreted as the set of all ''total'' functions from the Cartesian product <math>T_1 \times \cdots \times T_n</math> to <math>T</math>.

The example above also shows how to introduce type names.
A name like <code>UnaryFunType</code> above is just an abbreviation for the type <math>\mathrm{INT} \to \mathrm{REAL}</math> and can be used interchangeably with it.

In general, any type defined by a type expression <code>E</code> can be given a name with the declaration:

name : TYPE = E;

=== Type Checking ===

In CVC4, formulas and terms are statically typed at the level of types
(as opposed to subtypes) according to the usual rules of first-order many-sorted logic,
with the main difference that formulas are just terms of type <math>BOOLEAN</math>:

* each variable has one associated first-order type,
* each constant symbol has one or more associated first-order types,
* each function symbol has one or more associated function types,
* the type of a term consisting just of a variable is the type associated to that variable,
* the type of a term consisting just of a constant symbol is the type associated to that constant symbol,
* the term obtained by applying a function symbol <math>f</math> to the terms <math>t_1, \ldots, t_n</math> is <math>T</math> if <math>f</math> has type <math>(T_1, \ldots, T_n) \to T</math> and each <math>t_i</math> has type <math>T_i</math>.

Attempting to enter an ill-typed term will result in an error.

Another significant difference with standard many-sorted logic is that
some built-in symbols are parametrically polymorphic.
For instance, the function symbol for extracting the element of any array has
type <math>(\mathit{ARRAY}\ T_1\ \mathit{OF}\ T_2,\; T_1) \to T_2</math>
for all first-order types <math>T_1, T_2</math>.

==== Type Ascription ====

By the type inference rules above some terms might have more than one type.
This can happen with terms built with polymorphic data type constructors
that have more than one return type for the same input type.
In that case, a type ascription operator (<code>::</code>) must be applied
to the constructor to specify the intended return type.

DATATYPE [X]
List[X] = nil | cons (head: X, tail: List[X])
END;

ASSERT y = cons(1, nil::List[REAL]);

DATATYPE [X, Y]
Union[X, Y] = left(val_l: X) | right(val_r: Y)
END;

ASSERT y = left::Union[BOOLEAN, REAL](TRUE);

The constant symbol <math>\mathrm{nil}</math> declared above has infinitely many types
(<math>\mathrm{List}[\mathrm{REAL}]</math>, <math>\mathrm{List}[\mathrm{BOOLEAN}]</math>,
<math>\mathrm{List}[[\mathrm{REAL}, \mathrm{REAL}]]</math>,
<math>\mathrm{List}[\mathrm{List}[\mathrm{REAL}]]</math>, ...)
CVC4's type checker requires the user to indicate explicitly the type
of each occurrence of <code>nil</code> in a term.
Similarly,
the injection operator <code>left</code> has infinitely many return types
for the same input type, for instance:
<math>\mathrm{BOOLEAN} \to \mathrm{Union}[\mathrm{BOOLEAN}, \mathrm{REAL}]</math>,
<math>\mathrm{BOOLEAN} \to \mathrm{Union}[\mathrm{BOOLEAN}, [\mathrm{REAL}, \mathrm{REAL}]]</math>,
<math>\mathrm{BOOLEAN} \to \mathrm{Union}[\mathrm{BOOLEAN}, \mathrm{List}[\mathrm{REAL}]]</math>,
and so on.
Applications of <code>left</code> need to specify the intended returned typed, as shown above.

== Terms and Formulas ==

In addition to type expressions, CVC4 has expressions for terms and for formulas
(i.e., terms of type <math>\mathrm{BOOLEAN}</math>).
By and large, these are standard first-order terms built out of typed variables,
predefined theory-specific operators, free (i.e., user-defined) function symbols,
and quantifiers.
Extensions include an if-then-else operator, lambda abstractions, and local symbol
declarations, as illustrated below.
Note that these extensions still keep CVC4's language first-order.
In particular, lambda abstractions are restricted to take and return only terms of
a first-order type.
Similarly, variables can only be of a first-order type.

A number of built-in function symbols (for instance, the arithmetic ones) are used
as infix operators. All user-defined symbols are used as prefix ones.

User-defined, i.e., free, function symbols include ''constant symbols'' and
''predicate symbols'', respectively nullary function symbols and function symbols
with a <math>\mathrm{BOOLEAN}</math> return type.
These symbols are introduced with global declarations of the form
<math> f_1, \ldots, f_m: T;</math>
where <math>m > 0</math>, <math>f_i</math> are the names of the symbols and
<math>T</math> is their type:

% integer constants

a, b, c: INT;

% real constants

x, y, z: REAL;

% unary function

f1: REAL -> REAL;

% binary function

f2: (REAL, INT) -> REAL;

% unary function with a tuple argument

f3: [INT, REAL] -> BOOLEAN;

% binary predicate

p: (INT, REAL) -> BOOLEAN;

% Propositional "variables"

P, Q; BOOLEAN;

Like type declarations, function symbol declarations like the above have global scope
and must be unique.
In other words, it is not possible to declare a function symbol globally more than once
in the same lexical scope.
This entails among other things that globally-defined free symbols cannot be overloaded
with different types and that theory symbols cannot be redeclared globally as free symbols.

=== Global symbol definitions ===

As with types, a function symbol can be defined as the name of another term
of the corresponding type.
With constant symbols, this is done with a declaration of the form <math>f:T = t;</math> :

c: INT;

i: INT = 5 + 3*c; % i is effectively a shorthand for 5 + 3*c

j: REAL = 3/4;

t: [REAL, INT] = (2/3, -4);

r: [# key: INT, value: REAL #] = (# key := 4, value := (c + 1)/2 #);

f: BOOLEAN = FORALL (x:INT): x <= 0 OR x > c ;

A restriction on constants of type <math>\mathit{BOOLEAN}</math> is that their value
can only be a closed formula, that is, a formula with no free variables.

A term and its name can be used interchangeably in later expressions.
Named terms are often useful for shared subterms (terms used several times in different places)
since their use can make the input exponentially more concise.
Named terms are processed very efficiently by CVC4.
It is much more efficient to associate a complex term with a name directly rather than
to declare a constant and later assert that it is equal to the same term.
This point is explained in more detail later in section [[Commands | Commands]].

More generally, in CVC4 one can associate a term to function symbols of any arity.
For non-constant function symbols this is done with a declaration of the form

<center>
<math>f:(T_1, \ldots, T_n) \to T = \mathrm{LAMBDA}(x_1:T_1, \ldots, x:T_n): t\;;</math>
</center>

where <math>t</math> is any term of type <math>T</math> with free variables
in <math>\{x_1, \ldots, x_n\}</math>.
The lambda binder has the usual semantics and conforms to the usual lexical scoping rules:
within the term <math>t</math> the declaration of the symbols <math>x_1, \ldots, x_n</math>
as local variables of respective type <math>T_1, \ldots, T_n</math> hides any previous
declarations of those symbols that are in scope.

As a general shorthand, when <math>k</math> consecutive types
<math>T_i, \ldots, T_{i+k-1}</math> in the lambda expression
<math>\mathrm{LAMBDA}(x_1:T_1, \ldots, x:T_n): t</math> are identical, the syntax
<math>\mathrm{LAMBDA}(x_1:T_1, \ldots, x_i,\ldots, x_{i+k-1}:T_i,\ldots, x:T_n): t</math>
can also be used.

% Global declaration of x as a unary function symbol

x: REAL -> REAL;

% Local declarations of x as variable (hiding the global one)

f: REAL -> REAL = LAMBDA (x: REAL): 2*x + 3;

p: (INT, INT) -> BOOLEAN = LAMBDA (x,i: INT): i*x - 1 > 0;

g: (REAL, INT) -> [REAL, INT] = LAMBDA (x: REAL, i:INT): (x + 1, i - 3);

Note that lambda definitions are not recursive:
the symbol being defined cannot occur in the body of the lambda term.
They should be understood as macros.
For instance, any occurrence of the term <math>f(t)</math>
where <math>f</math> is as defined above will be treated
as if it was the term <math>(2*t + 3)</math>.

=== Local symbol definitions ===

Constant and function symbols can also be declared locally anywhere within a term
by means of a let binder.
This is done with a declaration of the form

<center>
<math>
\mathrm{LET}\ f = s \ \mathrm{IN}\ t ;
</math>
</center>

where <math>t</math> is a term with no free variables, possibly a lambda term.
Let binders can be nested arbitrarily and follow the usual lexical scoping rules.
The following general form
<center>
<math>
\mathrm{LET}\ f_1 = t_1, f_2 = t_2, \ldots, f_n = t_m \ \mathrm{IN}\ t ;
</math>
</center>
can used as a shorthand for
<center>
<math>
\mathrm{LET}\ f_1 = t_1\ \mathrm{IN}\
\mathrm{LET}\ f_2 = t_2\ \mathrm{IN}\
\ldots \
\mathrm{LET}\ f_n = t_m \ \mathrm{IN}\ t ;
</math>
</center>

t: REAL =
LET x1 = 42,
g = LAMBDA(x:INT): x + 1,
x2 = 2*x1 + 7/2
IN
(LET x3 = g(x1) IN x3 + x2) / x1;

Note that the same symbol = is used, unambiguously, in the syntax of global declarations,
let declarations, and as a predicate symbol.

'''Note:'''
A <math>\mathrm{LET}</math> term with a multiple symbols defines them sequentially.
A parallel version of the <math>\mathrm{LET}</math> construct will be introduced in a later version.

== Built-in theories and their symbols ==

In addition to user-defined symbols, CVC4 terms can use a number of predefined symbols:
the logical symbols, such as <math>\mathrm{AND}</math>, <math>\mathrm{OR}</math>, etc.,
as well as theory symbols, function symbols belonging to one of the built-in theories.
They are described next, with the theory symbols grouped by theory.

=== Logical Symbols ===

The logical symbols in CVC4's language include
the equality and disequality predicate symbols, respectively written as = and /=,
the multiarity disequality symbol <math>\mathrm{DISTINCT}</math>,
together with the logical constants <math>\mathrm{TRUE}</math>, <math>\mathrm{FALSE}</math>,
the connectives <math>\mathrm{NOT}</math>, <math>\mathrm{AND}</math>, <math>\mathrm{OR}</math>, <math>\mathrm{XOR}</math>, <math>\Rightarrow</math>, <math>\Leftrightarrow</math>, and
the first-order quantifiers <math>\mathrm{EXISTS}</math> and <math>\mathrm{FORALL}</math>,
all with the standard many-sorted logic semantics.

The binary connectives have infix syntax and type
<math>(\mathrm{BOOLEAN},\mathrm{BOOLEAN}) \to \mathrm{BOOLEAN}</math>.
The symbols = and /=, which are also infix, are instead parametrically polymorphic,
having type <math>(T,T) \to \mathrm{BOOLEAN}</math>
for every first-order type <math>T</math>.
They are interpreted respectively as the identity relation and its complement.

The DISTINCT symbol is both overloaded and polymorphic.
It has type <math>(T,...,T) \to \mathrm{BOOLEAN}</math>
for every sequence <math>(T,...,T)</math> of length <math>n > 0</math>
and first-order type <math>T</math>.
For each <math>n > 0</math>, it is interpreted as the relation
that holds exactly for tuples of pairwise distinct elements.

The syntax for quantifiers is similar to that of the lambda binder.

Here is an example of a formula built just of these logical symbols and variables:

A, B: TYPE;

q: BOOLEAN = FORALL (x,y: A, i,j,k: B):
i = j AND i /= k => EXISTS (z: A): x /= z OR z /= y;

Binding and scoping of quantified variables follows the same rules as
in let expressions.
In particular, a quantifier will shadow in its scope any constant and function symbols
with the same name as one of the variables it quantifies:

A: TYPE;
i, j: INT;

% The first occurrence of i and of j in f are constant symbols,
% the others are variables.

f: BOOLEAN = i = j AND FORALL (i,j: A): i = j OR i /= j;

Optionally, it is also possible to specify instantiation patterns
for quantified variables.
The general syntax for a quantified formula <math>\psi</math> with patterns is

<center>
<math>
Q\;(x_1:T_1, \ldots, x_k:T_k):\; p_1: \ldots\; p_n:\; \varphi
</math>
</center>

where <math>n \geq 0</math>, <math>Q</math> is
either <math>\mathrm{FORALL}</math> or <math>\mathrm{EXISTS}</math>,
<math>\varphi</math> is a term of type <math>\mathrm{BOOLEAN}</math>,
and each of the <math>p_i</math>'s,
a pattern for the quantifier <math>Q\;(x_1:T_1, \ldots, x_k:T_k)</math>, has the form

<center>
<math>
\mathrm{PATTERN}\; (t_1, \ldots, t_m)
</math>
</center>

where <math>m > 0</math> and <math>t_1, \ldots, t_m</math> are
arbitrary binder-free terms (no lets, no quantifiers).
Those terms can contain (free) variables, typically, but not exclusively,
drawn from <math>x_1, \ldots, x_k</math>.
(Additional variables can occur if <math>\psi</math> occurs in a bigger formula
binding those variables.)

A: TYPE;
b, c: A;
p, q: A -> BOOLEAN;
r: (A, A) -> BOOLEAN;

ASSERT FORALL (x0, x1, x2: A):
PATTERN (r(x0, x1), r(x1, x2)):
(r(x0, x1) AND r(x1, x2)) => r(x0, x2) ;

ASSERT FORALL (x: A):
PATTERN (r(x, b)):
PATTERN (r(x, c)):
p(x) => q(x) ;

ASSERT EXISTS (y: A):
FORALL (x: A):
PATTERN (r(x, y), p(y)):
r(x, y) => q(x) ;

Patterns have no logical meaning:
adding them to a formula does not change its semantics.
Their purpose is purely operational, as explained in
the [[#Instantiation Patterns | Instantiation Patterns]] section.

In addition to these constructs, CVC4 also has a general mixfix conditional operator
of the form

<center>
<math>
\mathrm{IF}\ b\ \mathrm{THEN}\ t\ \mathrm{ELSIF}\ b_1\ \mathrm{THEN}\ t_1\ \ldots\ \mathrm{ELSIF}\ b_n\ \mathrm{THEN}\ t_n\ \mathrm{ELSE}\ t_{n+1}\ \mathrm{ENDIF}
</math>
</center>

with <math>n \geq 0</math> where
<math>b, b_1, \ldots, b_n</math> are terms of type <math>\mathrm{BOOLEAN}</math> and
<math>t, t_1, \ldots, t_n, t_{n+1}</math> are terms of the same first-order type <math>T</math>:

% Conditional term
x, y, z, w: REAL;

t: REAL =
IF x > 0 THEN y
ELSIF x >= 1 THEN z
ELSIF x > 2 THEN w
ELSE 2/3 ENDIF;

=== User-defined Functions and Types ===

The theory of user-defined functions,also know in the SMT literature as
the theory ''Equality over Uninterpreted Functions'', or ''EUF'', is in effect
a family of theories of equality parametrized by the basic types and the free symbols
a user can define during a run of CVC4.

This theory has no built-in symbols (other than the logical ones).
Its types consist of ''all and only'' the user-defined types.
Its function symbols consist of ''all and only'' the user-defined free symbols.

=== Arithmetic ===

The real arithmetic theory has two types:
<math>\mathrm{REAL}</math> and <math>\mathrm{INTEGER}</math>
with the latter a subtype of the first.
Its built-in symbols for the usual arithmetic constants
and operators over the type <math>\mathrm{REAL}</math>, each with the expected type:
all numerals 0, 1, ..., as well as - (both unary and binary), +, *, /, <, >, <=, >=.
Application of the binary symbols are in infix form.
Note that + is only binary, and so an expression such as +4 is ill-formed.

Rational values can be expressed in decimal or fractional format,
e.g., 0.1, 23.243241, 1/2, 3/4, and so on.
A leading 0 is mandatory for decimal numbers smaller than one
(e.g., the syntax .3 cannot be used as a shorthand for 0.3).
However, a trailing 0 is ''not'' required for decimals that are whole numbers
(e.g., 3. is allowed as a shorthand for 3.0).
The size of the numerals used in the representation of natural and rational numbers
is unbounded; more accurately, bounded only by the amount of available memory.

=== Bit vectors ===

=== Arrays ===

The theory of arrays is a parametric theory of (total) unary maps.
It comes equipped with mixfix polymorphic selection and update operators, respectively
<center>
<math>\_[\_]</math> and <math>\_\ \mathrm{WITH}\ [\_]\ := \_</math> .
</center>
The semantics of these operators is the expected one:
for all first-order types <math>T_1</math> and <math>T_2</math>,
if <math>a</math> is of type <math>\mathrm{ARRAY}\ T_1 \mathrm{OF}\ T_2</math>,
<math>i</math> is of type <math>T_1</math>, and
<math>v</math> is of type <math>T_2</math>,
* <math>a[i]</math> denotes the value that <math>a</math> associates to index <math>i</math>,
* <math>a\ \mathrm{WITH}\ [i]\ := v</math> denotes a map that associates <math>v</math> to index <math>i</math> and is otherwise identical to <math>a</math>.
Sequential updates can be chained with the shorthand syntax
<math>\_\ \mathrm{WITH}\ [\_]\ := \_, \ldots, [\_]\ := \_</math>.

A: TYPE = ARRAY INT OF REAL;
a: A;
i: INT = 4;

% selection:

elem: REAL = a[i];

% update

a1: A = a WITH [10] := 1/2;

% sequential update
% (syntactic sugar for (a WITH [10] := 2/3) WITH [42] := 3/2)

a2: A = a WITH [10] := 2/3, [42] := 3/2;

Since arrays are just maps, equality between them is extensional, that is,
for two arrays of the same type to be different they have to map at least one
index to differ values.

=== Data types ===

The theory of inductive data types is in fact a family of theories parametrized
by a data type declaration specifying constructors and selectors
for one or more user-defined data types.

No built-in operators other than equality and disequality are provided
for this family in the native language.
Each user-provided data type declaration, however, generates constructor, selector and tester operators
as described in the [[#Inductive Data Types | Inductive Data Types]] section.

=== Tuples and Records ===

Semantically both records and tuples can be seen as special instances
of inductive data types.
CVC4 implements them internally indeed as data types.
In essence, a record type <math>[\#\ l_0:T_0, \ldots, l_n:T_n\ \#]</math>
is encoded as a data type of the form

<center>
<math>
\begin{array}{l}
\mathrm{DATATYPE} \\
\ \ \mathrm{Record} = \mathit{rec}(l_0:T_0, \ldots, l_n:T_n) \\
\mathrm{END};
\end{array}
</math>
</center>

Tuples of length <math>n</math> are in turn special cases of records whose field names are
the numerals from <math>0</math> to <math>n-1</math>.

Externally, tuples and records have their own syntax for constructor and selector operators.
* Records of type <math>[\#\ l_0:T_0, \ldots, l_n:T_n\ \#]</math> have the associated record constructor <math>(\#\ l_0 := \_,\; \ldots,\; l_n := \_\ \#)</math> whose arguments must be terms of type <math>T_0, \ldots, T_n</math>, respectively.
* Tuples of type <math>[\ T_0, \ldots, T_n\ ]</math> have the associated tuple constructor <math>(\ \_,\; \ldots,\; \_\ )</math> whose arguments must be terms of type <math>T_0, \ldots, T_n</math>, respectively.

The selector operators on records and tuples follows a dot notation syntax.

% Record construction and field selection
Item: TYPE = [# key: INT, weight: REAL #];

x: Item = (# key := 23, weight := 43/10 #);
k: INT = x.key;
v: REAL = x.weight;

% Tuple construction and projection
y: [REAL, INT, REAL] = ( 4/5, 9, 11/9 );
first_elem: REAL = y.0;
third_elem: REAL = y.2;

Differently from data types, records and tuples are also provided with built-in update operators similar in syntax and semantics to the update operator for arrays.
More precisely, for each record type <math>[\#\ l_0:T_0, \ldots, l_n:T_n\ \#]</math> and
each <math>i=0, \ldots, n</math>, CVC4 provides the operator

<center>
<math>
\_\ \mathrm{WITH}\ .l_i\ := \_
</math>
</center>

The operator maps a record <math>r</math> of that type and a value <math>v</math>
of type <math>T_i</math> to the record that stores <math>v</math> in field <math>l_i</math>
and is otherwise identical to <math>r</math>.
Analogously, for each tuple type <math>[T_0, \ldots, T_n]</math> and
each <math>i=0, \ldots, n</math>, CVC4 provides the operator

<center>
<math>
\_\ \mathrm{WITH}\ .i\ := \_
</math>
</center>

with similar semantics.

% Record updates

Item: TYPE = [# key: INT, weight: REAL #];

x: Item = (# key := 23, weight := 43/10 #);

x1: Item = x WITH .weight := 48;

% Tuple updates

Tup: TYPE = [REAL,INT,REAL];
y: Tup = ( 4/5, 9, 11/9 );
y1: Tup = y WITH .1 := 3;

Updates to a nested component can be combined in a single WITH operator:

Cache: TYPE = ARRAY [0..100] OF [# addr: INT, data: REAL #];
State: TYPE = [# pc: INT, cache: Cache #];

s0: State;
s1: State = s0 WITH .cache[10].data := 2/3;

Note that, differently from updates on arrays, tuple and record updates are
just additional syntactic sugar.
For instance, the record <code>x1</code> and tuple <code>y1</code> defined above
could have been equivalently defined as follows:

% Record updates

Item: TYPE = [# key: INT, weight: REAL #];

x: Item = (# key := 23, weight := 43/10 #);

x1: Item = (# key := x.key, weight := 48 #);

% Tuple updates

Tup: TYPE = [REAL,INT,REAL];
y: Tup = ( 4/5, 9, 11/9 );
y1: Tup = ( y.0, 3, y.1 );

== Commands ==

In addition to declarations of types and function symbols,
the CVC4 native language contains the following commands:

* <math>\mathrm{ASSERT}\ F</math> -- Add the formula <math>F</math> to the current logical context <math>\Gamma</math>.
* [[#CHECKSAT|<math>\mathrm{CHECKSAT}\ F</math>]] -- Check if the formula <math>F</math> is satisfiable in the current logical context (<math>\Gamma \not\models_T \mathrm{NOT}\ F</math>).
* <math>\mathrm{CONTINUE}</math> -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, search for a counter-example different from the current one.
* [[#COUNTEREXAMPLE|<math>\mathrm{COUNTEREXAMPLE}</math>]] -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, print the context that is a witness for invalidity/satisfiability.
* [[#COUNTERMODEL|<math>\mathrm{COUNTERMODEL}</math>]] -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, print a model that makes the formula invalid/satisfiable. The model is provided in terms of concrete values for each free symbol.
* <math>\mathrm{OPTION}\ o\ v</math> -- Set the command-line option flag <math>o</math> to value <math>v</math>. The argument <math>o</math> is provide as a string literal enclosed in double-quotes and <math>v</math> as an integer value.
* <math>\mathrm{POP}</math> -- Equivalent to <math>\mathrm{POPTO}\ 1</math>
* [[#POPTO|<math>\mathrm{POPTO}\ n</math>]] -- Restore the system to the state it was in right before the most recent call to <math>\mathrm{PUSH}</math> made from stack level <math>n</math>. Note that the current stack level is printed as part of the output of the <math>\mathrm{WHERE}</math> command.
* <math>\mathrm{PUSH}</math> -- Save (checkpoint) the current state of the system.
* [[#QUERY|<math>\mathrm{QUERY}\ F</math>]] -- Check if the formula <math>F</math> is valid in the current logical context (<math>\Gamma\models_T F</math>).
* [[#RESTART|<math>\mathrm{RESTART}\ F</math>]] -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, repeat the check but with the additional assumption <math>F</math> in the context.
* <math>\mathrm{PRINT}\ t</math> -- Parse and print back the term <math>t</math>.
* <math>\mathrm{TRANSFORM}\ t</math> -- Simplify the term <math>t</math> and print the result.
* <math>\mathrm{WHERE}</math> -- Print all the formulas in the current logical context <math>\Gamma</math>.

The remaining commands take a single argument, given as a string literal enclosed in double-quotes.

* <math>\mathrm{ECHO}\ s</math> -- Print string <math>s</math>
* <math>\mathrm{INCLUDE}\ f</math> -- Read commands from file <math>f</math>.
* <math>\mathrm{TRACE}\ f</math> -- Turn on tracing for the debug flag <math>f</math>.
* <math>\mathrm{UNTRACE}\ f</math> -- Turn off tracing for the debug flag <math>f</math>.

Here, we explain some of the above commands in more detail.

=== QUERY ===

The command <math>\mathrm{QUERY}\ F</math> invokes the core functionality of CVC4 to check
the validity of the formula <math>F</math> with respect to the assertions made thus far,
which constitute the context <math>\Gamma</math>.
The argument <math>F</math> must be well typed term of type <math>\mathrm{BOOLEAN}</math>,
as described in [[#Terms and Formulas | Terms and Formulas]].

The execution of this command always terminates and produces one of three possible answers:
<code>valid</code>, <code>invalid</code>, and <code>unknown</code>.

* A <code>valid</code> answer indicates that <math>\Gamma \models_T F</math>. After a query returning such an answer, the logical context <math>\Gamma</math> is exactly as it was before the query.
* An <code>invalid</code> answer indicates that <math>\Gamma \not\models_T F</math>, that is, there is a model of the background theory <math>T</math> that satisfies <math>\Gamma \cup \{\mathrm{NOT}\ F\}</math>. When <math>\mathrm{QUERY}\ F</math> returns <code>invalid</code>, the logical context <math>\Gamma</math> is augmented with a set <math>\Delta</math> of ground (i.e., variable-free) literals such that <math>\Gamma\cup\Delta</math> is satisfiable in <math>T</math>, but <math>\Gamma\cup\Delta\models_T \mathrm{NOT}\ F</math>. In fact, in this case <math>\Delta</math> ''propositionally entails'' <math>\mathrm{NOT}\ F</math>, in the sense that, every truth assignment to the literals of <math>\Delta</math> that satisfies <math>\Delta</math> falsifies <math>F</math>. We call the new context <math>\Gamma\cup\Delta</math> a ''counterexample'' for <math>F</math>.
* An <code>unknown</code> answer is similar to an <code>invalid</code> answer in that additional literals are added to the context which propositionally entail <math>\mathrm{NOT}\ F</math>. The difference in this case is that CVC4 cannot guarantee that <math>\Gamma\cup\Delta</math> is actually satisfiable in <math>T</math>.

CVC4 may report <code>unknown</code> when the context or the query contains
non-linear arithmetic terms or quantifiers.
In all other cases, it is expected to be sound and complete,
i.e., to report <code>Valid</code> if <math>\Gamma \models_T F</math>
and <code>Invalid</code> otherwise.

After an <code>invalid</code> (resp. <code>unknown</code>) answer,
counterexamples (resp. possible counterexamples) can be obtained with
a <math>\mathrm{WHERE}</math>, <math>\mathrm{COUNTEREXAMPLE}</math>,
or <math>\mathrm{COUNTERMODEL}</math> command.


Since the <math>\mathrm{QUERY}</math> command may modify
the current context, if one needs to check several formulas in a row
in the same context, it is a good idea to surround every
query by a <math>\mathrm{PUSH}</math> and <math>\mathrm{POP}</math> invocation
in order to preserve the context:

PUSH;
QUERY <formula>;
POP;

=== CHECKSAT ===

The command <math>\mathrm{CHECKSAT}\ F</math> behaves identically
to <math>\mathrm{QUERY}\ \mathrm{NOT}\ F</math>.

=== RESTART ===

The command <math>\mathrm{RESTART}\ F</math> can only be invoked after an invalid query.
For example, in an interactive setting:

QUERY <formula>;

CVC4> invalid

RESTART <formula2>;

Functionally, the behavior of the above command sequence is identical to the following:

PUSH;
QUERY <formula>;
POP;
ASSERT <formula2>;
QUERY <formula>;

The advantage of using the <math>\mathrm{RESTART}</math> command is that
the first command sequence may be executed much more efficiently that the second.
The reason is that with <math>\mathrm{RESTART}</math> CVC4 will re-use
what it has learned while answering the previous query rather than starting
over from scratch.

=== COUNTERMODEL ===

[More]

=== COUNTEREXAMPLE ===

[More]

=== POPTO ===

[More]

== Instantiation Patterns ==

CVC4 processes each universally quantified formula in the current context
by adding instances of the formula obtained by replacing its universal variables
with ground terms.
Patterns restrict the choice of ground terms for the quantified variables,
with the goal of controlling the potential explosion of ground instances.
In essence, adding patterns to a formula is a way for the user to tell CVC4
to focus only on certain instances which, in the user's opinion, will be
most helpful during a proof.

In more detail, patterns have the following effect on formulas that are found
in the logical context or get added to it later while CVC4 is trying to prove
the validity of some formula <math>F</math>.

If a formula in the current context starts with an existential quantifier,
CVC4 ''Skolemizes'' it, that is, replaces it in the context with the formula
obtained by substituting the existentially quantified variables
by fresh constants and dropping the quantifier.
Any patterns for the existential quantifier are simply ignored.

If a formula starts with a universal quantifier
<math>\mathrm{FORALL}\; (x_1:T_1, \ldots, x_n:T_n)</math>,
CVC4 adds to the context a number of instances of the formula,
with the goal of using them to prove the query <math>F</math> valid.
An instance is obtained by replacing each <math>x_i</math> with a ground term
of the same type occurring in one of the formulas in the context,
and dropping the universal quantifier.
If <math>x_i</math> occurs in a pattern
<math>\mathrm{PATTERN}\; (t_1, \ldots, t_m)</math> for the quantifier,
it will be instantiated only with terms obtained by simultaneously matching
all the terms in the pattern against ground terms in the current context
<math>\Gamma</math>.

Specifically, the matching process produces one or more substitutions
<math>\sigma</math> for the variables in <math>(t_1, \ldots, t_m)</math>
which satisfy the following invariant:
for each <math>i = 1, \ldots, m</math>, <math>\sigma(t_i)</math> is
a ground term and there is a ground term <math>s_i</math> in <math>\Gamma</math>
such that <math>\Gamma \models_T \sigma(t_i) = s_i</math>.
The variables of <math>(x_1:T_1, \ldots, x_n:T_n)</math> that occur
in the pattern are instantiated only with those substitutions
(while any remaining variables are instantiated arbitrarily).

The Skolemized version or the added instances of a context formula may themselves
start with a quantifier.
The same instantiation process is applied to them too, recursively.

Note that the matching mechanism is not limited to syntactic matching
but is modulo the equations asserted in the context.
Because of decidability and/or efficiency limitations, the matching process
is not exhaustive.
CVC4 will typically miss some substitutions that satisfy the invariant above.
As a consequence, it might fail to prove the validity of the query formula
<math>F</math>, which makes CVC4 incomplete for contexts containing
quantified formulas.
It should be noted though that exhaustive matching, which can be achieved
simply by not specifying any patterns, does not yield completeness anyway
since the instantiation of universal variables is still restricted
to just the ground terms in the context,
whereas in general additional ground terms might be needed.

CVC4's native language

2012-12-01T18:08:22Z

Clark Barrett: /* The INT Type */

= CVC4 native input language =

The native input language consists of a sequence of symbol declarations and commands, each followed by a semicolon (<code>;</code>).

Any text after the first occurrence of a percent character and to the end of the current line is a comment:

%%% This is a native language comment

== Type System ==

CVC4's type system includes a set of built-in types which can be expanded with additional user-defined types.

The type system consists of ''first-order'' types, ''subtypes'' of first-order types, and ''higher-order'' types, all of which are interpreted as sets.
For convenience, we will sometimes identify below the interpretation of a type with the type itself.

First-order types consist of basic types and structured types. The basic types are <math>\mathrm{BOOLEAN}</math>, <math>\mathrm{REAL}</math>, <math>\mathrm{BITVECTOR}(n)</math> for all <math>n > 0</math>, as well as user-defined basic types (also called uninterpreted types).
The structured types are array, tuple, record types, and ML-style user-defined (inductive) datatypes.

'''Note:''' Currently, subtypes consist only of the built-in subtype <math>\mathrm{INT}</math> of <math>\mathrm{REAL}</math>.

Support for CVC3-style user-defined subtypes will be added in a later release.

Function types are the only higher-order types.
More precisely, they are just second-order types
since function symbols in CVC4, both built-in and user-defined, can take as argument or return only values of
a first-order type.

=== Basic Types ===

==== The BOOLEAN Type ====

The <math>\mathrm{BOOLEAN}</math> type is interpreted as the two-element set of Boolean values
<math>\{\mathrm{TRUE},\; \mathrm{FALSE}\}</math>.

'''Note:''' CVC4's treatment of this type differs from CVC3's where <math>\mathrm{BOOLEAN}</math> is used only as the type of formulas, but not as value type. CVC3 follows the two-tiered structure of classical first-order logic
which distinguishes between formulas and terms, and allows terms to occur in formulas but not vice versa (with the exception of the IF-THEN-ELSE construct).
CVC4 drops the distinction between terms and formulas and defines the latter just as terms of type <math>\mathrm{BOOLEAN}</math>. As such, formulas can occur as subterms of possibly non-Boolean terms.

Example:

[To do]

==== The REAL Type ====

The <math>\mathrm{REAL}</math> type is interpreted as the set of real numbers.

Note that these are the (infinite precision) mathematical reals,
not the floating point numbers.
Support for floating point types is planned for future versions.

x, y : REAL;
QUERY (( x <= y ) AND ( y <= x )) => ( x = y );

==== The INT Type ====

The <math>\mathrm{INT}</math> type is interpreted as the set of integer numbers
and is considered a subtype of <math>\mathrm{REAL}</math>.
The latter means in particular that it is possible to mix integer and real terms
in expressions without the need of an explicit ''upcasting'' operator.

Note that these are the (infinite precision) mathematical integers,
not the finite precision machine integers used in most programming languages.
The latter are models by [[ #Bitvectors | bit vector ]] types.

x, y : INT;
QUERY ((2 * x + 4 * y <= 1) AND ( y >= x)) => (x <= 0);
z : REAL;
QUERY (2 * x + z <= 3.5) AND (z >= 1);

==== Bit Vector Types ====

For every positive integer <math>n</math>, the type <math>\mathrm{BITVECTOR}(n)</math> is interpreted as the set of all bit vectors of size <math>n</math>.
A rich set of bit vector operators is supported.

==== User-defined Basic Types ====

Users can define new basic types
(often referred to as ''uninterpreted'' types in the SMT literature).
Each such type is interpreted as a set of unspecified cardinality
but disjoint from any other type.

User-defined basic types are created by declarations like the following:

% User declarations of basic types:

MyBrandNewType: TYPE;

Apples, Oranges: TYPE;

=== Structured Types ===

CVC4's structured types are divided in the following families.

==== Array Types ====

Array types are created by the mixfix type constructors <math>\mathrm{ARRAY}\ \_\ \mathrm{OF}\ \_</math>
whose arguments can be instantiated by any value type.

I : TYPE;

%% Array types:

% Arrays with indices from I and values from REAL
Array1: TYPE = ARRAY I OF REAL;

% Arrays with integer indices and array values
Array2: TYPE = ARRAY INT OF (ARRAY INT OF REAL);

% Arrays with integer pair indices and integer values
IntMatrix: TYPE = ARRAY [INT, INT] OF INT;

An array type of the form <math>\mathrm{ARRAY}\ T_1\ \mathrm{OF}\ T_2</math> is interpreted
as the set of all total maps from <math>T_1</math> to <math>T_2</math>.
The main difference with the function type <math>T_1 \to T_2</math> is that arrays,
contrary to functions, are first-class objects of the language, that is, values of an array
type can be arguments or results of functions.
Furthermore, array types come equipped with an update operation.

==== Tuple Types ====

Tuple types are created by the mixfix type constructors

<center>
<math>
\begin{array}{l} [\ \_\ ] \\[1ex] [\ \_\ ,\ \_\ ] \\[1ex] [\ \_\ ,\ \_\ \ ,\ \_\ ] \\[1ex] \ldots \end{array}
</math>
</center>

whose arguments can be instantiated by any value type.

IntArray: TYPE = ARRAY INT OF INT;

% Tuple type declarations

RealPair: TYPE = [REAL, REAL]

MyTuple: TYPE = [ REAL, IntArray, [INT, INT] ];

A tuple type of the form <math>[T_1, \ldots, T_n]</math> is interpreted
as the Cartesian product <math>T_1 \times \cdots \times T_n</math>.

Note that while the types <math>(T_1, \ldots, T_n) \to T</math> and
<math>[T_1 \times \cdots \times T_n] \to T</math> are semantically equivalent,
they are operationally different in CVC4.
The first is the type of functions that take <math>n</math> arguments
of respective type <math>T_1</math>, <math>\ldots</math>, <math>T_n</math>,
while the second is the type of functions that take one argument of an <math>n</math>-tuple type.

==== Record Types ====

Similar to, but more general than tuple types, record types are created by type constructors of the form

<center>
<math>
[\#\ l_1: \_\ ,\ \ldots\ ,\ l_n: \_\ \#]
</math>
</center>

where <math>n > 0</math>, <math>l_1,\ldots, l_n</math> are field labels,
and the arguments can be instantiated with any first-order types.

MyType: TYPE;

% Record declaration

RecordType: TYPE = [# id: REAL, age: INT, info: MyType #];

The order of the fields in a record type is meaningful:
permuting the field names gives a different type.

Note that record types are non-recursive.
For instance, it is not possible to declare a record type called <code>Person</code> containing
a field of type <code>Person</code>.
Recursive types are provided in CVC4 by the more general inductive data types.
(As a matter of fact, both record and tuple types are implemented internally as inductive data types.)

==== Inductive Data Types ====

Inductive data types in CVC4 are similar to inductive data types of functional languages.
They can be parametric or not.

===== Non-Parametric Data Types =====

Non-parametric data types are created by declarations of the form
<center>
<math>
\begin{array}{l}
\mathrm{DATATYPE} \\
\begin{array}{ccc}
\ \ A_1 & = & C_{1,1} \mid C_{1,2} \mid \cdots \mid C_{1,m_1}, \\
\ \ A_2 & = & C_{2,1} \mid C_{2,2} \mid \cdots \mid C_{2,m_2}, \\
\ \ \vdots & = & \vdots \\
\ \ A_n & = & C_{n,1} \mid C_{n,2} \mid \cdots \mid C_{n,m_n} \\
\end{array}
\\
\mathrm{END};
\end{array}
</math>
</center>
where
each <math>A_i</math> is a type name and
each <math>C_{ij}</math> is either a constant symbol or an expression of the form
<center>
<math>\mathit{cons}(\ \mathit{sel}_1: T_1,\ \ldots,\ \mathit{sel}_k: T_k\ )
</math>
</center>
where <math>T_1, \ldots, T_k</math> are any first-order types, including any <math>A_i</math>.
Such declarations define the data types <math>A_1, \ldots, A_n</math>.
For each data type <math>A_i</math> they introduce:

* constructor symbols <math>cons</math> of type <math>(T_1, \ldots, T_k) \to \mathit{type\_name}_i</math>,
* selector symbols <math>\mathit{sel}_j</math> of type <math>\mathit{type\_name}_i \to T_j</math>, and
* tester symbols <math>\mathit{is\_cons}</math> of type <math>\mathit{type\_name}_i \to \mathrm{BOOLEAN}</math>.

Note that permitting more than one data type to be defined in the same declarations allows
the definition of mutually recursive types.

% simple enumeration type

% implicitly defined are the testers: is_red, is_yellow and is_blue
% (similarly for the other data types)

DATATYPE
PrimaryColor = red | yellow | blue
END;

% infinite set of pairwise distinct values ..., v(-1), v(0), v(1), ...

DATATYPE
Id = v (id: INT)
END;

% ML-style integer lists

DATATYPE
IntList = nil | ins (head: INT, tail: IntList)
END;

% AST for lamba calculus

DATATYPE
Term = var (index: INT)
| apply (arg_1: Term, arg_2: Term)
| lambda (arg: INT, body: Term)
END;

% Trees

DATATYPE
Tree = tree (value: REAL, children: TreeList),
TreeList = nil_tl
| ins_tl (first_t1: Tree, rest_t1: TreeList)
END;

Constructor, selector and tester symbols defined for a data type have global scope.
So, for example, it is not possible for two different data types to use
the same name for a constructor.

An inductive data type is interpreted as a term algebra constructed by the constructor symbols
over some sets of generators.
For example, the type <code>IntList</code> defined above is interpreted as the set
of all terms constructed with <code>nil</code> and <code>ins</code> over the integers.

===== Parametric Data Types =====

Parametric data types are infinite families of (non-parametric) data types
with each family parametrized by one or more type variables.
They are created by declarations of the form
<center>
<math>
\begin{array}{l}
\mathrm{DATATYPE} \\
\begin{array}{ccc}
\ \ A_1[X_{1,1}, \ldots, X_{1,p_1}] & = & C_{1,1} \mid C_{1,2} \mid \cdots \mid C_{1,m_1}, \\
\ \ A_2[X_{2,1}, \ldots, X_{2,p_2}] & = & C_{2,1} \mid C_{2,2} \mid \cdots \mid C_{2,m_2}, \\
\ \ \vdots & = & \vdots \\
\ \ A_n[X_{n,1}, \ldots, X_{n,p_n}] & = & C_{n,1} \mid C_{n,2} \mid \cdots \mid C_{n,m_n} \\
\end{array}
\\
\mathrm{END};
\end{array}
</math>
</center>
where
each <math>A_i</math> is a type name parametrized by the type variables <math>X_{i,1}, \ldots, X_{i,p_i}</math>
and
each <math>C_{ij}</math> is either a constant symbol or an expression of the form
<center>
<math>\mathit{cons}(\ \mathit{sel}_1: T_1,\ \ldots,\ \mathit{sel}_k: T_k\ )
</math>
</center>
where <math>T_1, \ldots, T_k</math> are any first-order types,
possibly parametrized by <math>X_1, \ldots, X_p</math>, including any <math>A_i</math>.

% Parametric pairs
DATATYPE
Pair[X, Y] = pair (first: X, second: Y)
END;

% Parametric lists

DATATYPE
List[X] = nil | cons (head: X, tail: List[X])
END;

% Parametric trees using the list type above

DATATYPE
Tree[X] = node (value: X, children: List[Tree[X]]),
END;

The declarations above define infinitely many types of the form
Pair[S,T], List[T] and Tree[T] where S and T are first-order types.
Note that the identifier <code>List</code> above, for example, by itself does not denote a type.
In contrast, the terms <code>List[Real]</code>, <code>List[List[Real]]</code>, <code>List[Tree[INT]]</code>,
and so on do.

===== Restriction to Inductive Types =====

By adopting a term algebra semantics, CVC4 allows only ''inductive'' data types,
that is, data types whose values are essentially (labeled, ordered) finite trees.
Infinite structures such as streams or even finite but cyclic ones
such as circular lists are then excluded.
For instance, none of the following declarations define inductive data types,
and are rejected by CVC4:

DATATYPE
IntStream = s (first:INT, rest: IntStream)
END;

DATATYPE
RationalTree = node1 (child: RationalTree)
| node2 (left_child: RationalTree, right_child:RationalTree)
END;

DATATYPE
T1 = c1 (s1: T2),
T2 = c2 (s2: T1)
END;

In concrete, a declaration of <math>n \geq 1</math> datatypes <math>T_1, \ldots, T_n</math> will be rejected if for any one of the types <math>T_1, \ldots, T_n</math>, it is impossible to build a finite term of that type using only the constructors of <math>T_1, \ldots, T_n</math> and free constants of type other than <math>T_1, \ldots, T_n</math>.

Inductive data types are the only types where the user also chooses names for the built-in operations to:

* construct a value of the type (with the constructors),
* extract components from a value (with the selectors), or
* check if a value was constructed with a certain constructor or not (with the testers).

For all the other types, CVC4 provides predefined names for the built-in operations on the type.

=== Function Types ===

Function (<math>\to</math>) types are created by the mixfix type constructors
<center>
<math>
\begin{array}{l}
\_ \to \_ \\[1ex] (\ \_\ ,\ \_\ ) \to \_
\\[1ex] (\ \_\ ,\ \_\ ,\ \_\ ) \to \_
\\[1ex] \ldots
\end{array}
</math>
</center>
whose arguments can be instantiated by any first-order type.

% Function type declarations

UnaryFunType: TYPE = INT -> REAL;

BinaryFunType: TYPE = (REAL, REAL) -> ARRAY REAL OF REAL;

TernaryFunType: TYPE = (REAL, BITVECTOR(4), INT) -> BOOLEAN;

A function type of the form <math>(T_1, \ldots, T_n) \to T</math> with <math>n > 0</math> is interpreted as the set of all ''total'' functions from the Cartesian product <math>T_1 \times \cdots \times T_n</math> to <math>T</math>.

The example above also shows how to introduce type names.
A name like <code>UnaryFunType</code> above is just an abbreviation for the type <math>\mathrm{INT} \to \mathrm{REAL}</math> and can be used interchangeably with it.

In general, any type defined by a type expression <code>E</code> can be given a name with the declaration:

name : TYPE = E;

=== Type Checking ===

In CVC4, formulas and terms are statically typed at the level of types
(as opposed to subtypes) according to the usual rules of first-order many-sorted logic,
with the main difference that formulas are just terms of type <math>BOOLEAN</math>:

* each variable has one associated first-order type,
* each constant symbol has one or more associated first-order types,
* each function symbol has one or more associated function types,
* the type of a term consisting just of a variable is the type associated to that variable,
* the type of a term consisting just of a constant symbol is the type associated to that constant symbol,
* the term obtained by applying a function symbol <math>f</math> to the terms <math>t_1, \ldots, t_n</math> is <math>T</math> if <math>f</math> has type <math>(T_1, \ldots, T_n) \to T</math> and each <math>t_i</math> has type <math>T_i</math>.

Attempting to enter an ill-typed term will result in an error.

Another significant difference with standard many-sorted logic is that
some built-in symbols are parametrically polymorphic.
For instance, the function symbol for extracting the element of any array has
type <math>(\mathit{ARRAY}\ T_1\ \mathit{OF}\ T_2,\; T_1) \to T_2</math>
for all first-order types <math>T_1, T_2</math>.

==== Type Ascription ====

By the type inference rules above some terms might have more than one type.
This can happen with terms built with polymorphic data type constructors
that have more than one return type for the same input type.
In that case, a type ascription operator (<code>::</code>) must be applied
to the constructor to specify the intended return type.

DATATYPE [X]
List[X] = nil | cons (head: X, tail: List[X])
END;

ASSERT y = cons(1, nil::List[REAL]);

DATATYPE [X, Y]
Union[X, Y] = left(val_l: X) | right(val_r: Y)
END;

ASSERT y = left::Union[BOOLEAN, REAL](TRUE);

The constant symbol <math>\mathrm{nil}</math> declared above has infinitely many types
(<math>\mathrm{List}[\mathrm{REAL}]</math>, <math>\mathrm{List}[\mathrm{BOOLEAN}]</math>,
<math>\mathrm{List}[[\mathrm{REAL}, \mathrm{REAL}]]</math>,
<math>\mathrm{List}[\mathrm{List}[\mathrm{REAL}]]</math>, ...)
CVC4's type checker requires the user to indicate explicitly the type
of each occurrence of <code>nil</code> in a term.
Similarly,
the injection operator <code>left</code> has infinitely many return types
for the same input type, for instance:
<math>\mathrm{BOOLEAN} \to \mathrm{Union}[\mathrm{BOOLEAN}, \mathrm{REAL}]</math>,
<math>\mathrm{BOOLEAN} \to \mathrm{Union}[\mathrm{BOOLEAN}, [\mathrm{REAL}, \mathrm{REAL}]]</math>,
<math>\mathrm{BOOLEAN} \to \mathrm{Union}[\mathrm{BOOLEAN}, \mathrm{List}[\mathrm{REAL}]]</math>,
and so on.
Applications of <code>left</code> need to specify the intended returned typed, as shown above.

== Terms and Formulas ==

In addition to type expressions, CVC4 has expressions for terms and for formulas
(i.e., terms of type <math>\mathrm{BOOLEAN}</math>).
By and large, these are standard first-order terms built out of typed variables,
predefined theory-specific operators, free (i.e., user-defined) function symbols,
and quantifiers.
Extensions include an if-then-else operator, lambda abstractions, and local symbol
declarations, as illustrated below.
Note that these extensions still keep CVC4's language first-order.
In particular, lambda abstractions are restricted to take and return only terms of
a first-order type.
Similarly, variables can only be of a first-order type.

A number of built-in function symbols (for instance, the arithmetic ones) are used
as infix operators. All user-defined symbols are used as prefix ones.

User-defined, i.e., free, function symbols include ''constant symbols'' and
''predicate symbols'', respectively nullary function symbols and function symbols
with a <math>\mathrm{BOOLEAN}</math> return type.
These symbols are introduced with global declarations of the form
<math> f_1, \ldots, f_m: T;</math>
where <math>m > 0</math>, <math>f_i</math> are the names of the symbols and
<math>T</math> is their type:

% integer constants

a, b, c: INT;

% real constants

x, y, z: REAL;

% unary function

f1: REAL -> REAL;

% binary function

f2: (REAL, INT) -> REAL;

% unary function with a tuple argument

f3: [INT, REAL] -> BOOLEAN;

% binary predicate

p: (INT, REAL) -> BOOLEAN;

% Propositional "variables"

P, Q; BOOLEAN;

Like type declarations, function symbol declarations like the above have global scope
and must be unique.
In other words, it is not possible to declare a function symbol globally more than once
in the same lexical scope.
This entails among other things that globally-defined free symbols cannot be overloaded
with different types and that theory symbols cannot be redeclared globally as free symbols.

=== Global symbol definitions ===

As with types, a function symbol can be defined as the name of another term
of the corresponding type.
With constant symbols, this is done with a declaration of the form <math>f:T = t;</math> :

c: INT;

i: INT = 5 + 3*c; % i is effectively a shorthand for 5 + 3*c

j: REAL = 3/4;

t: [REAL, INT] = (2/3, -4);

r: [# key: INT, value: REAL #] = (# key := 4, value := (c + 1)/2 #);

f: BOOLEAN = FORALL (x:INT): x <= 0 OR x > c ;

A restriction on constants of type <math>\mathit{BOOLEAN}</math> is that their value
can only be a closed formula, that is, a formula with no free variables.

A term and its name can be used interchangeably in later expressions.
Named terms are often useful for shared subterms (terms used several times in different places)
since their use can make the input exponentially more concise.
Named terms are processed very efficiently by CVC4.
It is much more efficient to associate a complex term with a name directly rather than
to declare a constant and later assert that it is equal to the same term.
This point is explained in more detail later in section [[Commands | Commands]].

More generally, in CVC4 one can associate a term to function symbols of any arity.
For non-constant function symbols this is done with a declaration of the form

<center>
<math>f:(T_1, \ldots, T_n) \to T = \mathrm{LAMBDA}(x_1:T_1, \ldots, x:T_n): t\;;</math>
</center>

where <math>t</math> is any term of type <math>T</math> with free variables
in <math>\{x_1, \ldots, x_n\}</math>.
The lambda binder has the usual semantics and conforms to the usual lexical scoping rules:
within the term <math>t</math> the declaration of the symbols <math>x_1, \ldots, x_n</math>
as local variables of respective type <math>T_1, \ldots, T_n</math> hides any previous
declarations of those symbols that are in scope.

As a general shorthand, when <math>k</math> consecutive types
<math>T_i, \ldots, T_{i+k-1}</math> in the lambda expression
<math>\mathrm{LAMBDA}(x_1:T_1, \ldots, x:T_n): t</math> are identical, the syntax
<math>\mathrm{LAMBDA}(x_1:T_1, \ldots, x_i,\ldots, x_{i+k-1}:T_i,\ldots, x:T_n): t</math>
can also be used.

% Global declaration of x as a unary function symbol

x: REAL -> REAL;

% Local declarations of x as variable (hiding the global one)

f: REAL -> REAL = LAMBDA (x: REAL): 2*x + 3;

p: (INT, INT) -> BOOLEAN = LAMBDA (x,i: INT): i*x - 1 > 0;

g: (REAL, INT) -> [REAL, INT] = LAMBDA (x: REAL, i:INT): (x + 1, i - 3);

Note that lambda definitions are not recursive:
the symbol being defined cannot occur in the body of the lambda term.
They should be understood as macros.
For instance, any occurrence of the term <math>f(t)</math>
where <math>f</math> is as defined above will be treated
as if it was the term <math>(2*t + 3)</math>.

=== Local symbol definitions ===

Constant and function symbols can also be declared locally anywhere within a term
by means of a let binder.
This is done with a declaration of the form

<center>
<math>
\mathrm{LET}\ f = s \ \mathrm{IN}\ t ;
</math>
</center>

where <math>t</math> is a term with no free variables, possibly a lambda term.
Let binders can be nested arbitrarily and follow the usual lexical scoping rules.
The following general form
<center>
<math>
\mathrm{LET}\ f_1 = t_1, f_2 = t_2, \ldots, f_n = t_m \ \mathrm{IN}\ t ;
</math>
</center>
can used as a shorthand for
<center>
<math>
\mathrm{LET}\ f_1 = t_1\ \mathrm{IN}\
\mathrm{LET}\ f_2 = t_2\ \mathrm{IN}\
\ldots \
\mathrm{LET}\ f_n = t_m \ \mathrm{IN}\ t ;
</math>
</center>

t: REAL =
LET x1 = 42,
g = LAMBDA(x:INT): x + 1,
x2 = 2*x1 + 7/2
IN
(LET x3 = g(x1) IN x3 + x2) / x1;

Note that the same symbol = is used, unambiguously, in the syntax of global declarations,
let declarations, and as a predicate symbol.

'''Note:'''
A <math>\mathrm{LET}</math> term with a multiple symbols defines them sequentially.
A parallel version of the <math>\mathrm{LET}</math> construct will be introduced in a later version.

== Built-in theories and their symbols ==

In addition to user-defined symbols, CVC4 terms can use a number of predefined symbols:
the logical symbols, such as <math>\mathrm{AND}</math>, <math>\mathrm{OR}</math>, etc.,
as well as theory symbols, function symbols belonging to one of the built-in theories.
They are described next, with the theory symbols grouped by theory.

=== Logical Symbols ===

The logical symbols in CVC4's language include
the equality and disequality predicate symbols, respectively written as = and /=,
the multiarity disequality symbol <math>\mathrm{DISTINCT}</math>,
together with the logical constants <math>\mathrm{TRUE}</math>, <math>\mathrm{FALSE}</math>,
the connectives <math>\mathrm{NOT}</math>, <math>\mathrm{AND}</math>, <math>\mathrm{OR}</math>, <math>\mathrm{XOR}</math>, <math>\Rightarrow</math>, <math>\Leftrightarrow</math>, and
the first-order quantifiers <math>\mathrm{EXISTS}</math> and <math>\mathrm{FORALL}</math>,
all with the standard many-sorted logic semantics.

The binary connectives have infix syntax and type
<math>(\mathrm{BOOLEAN},\mathrm{BOOLEAN}) \to \mathrm{BOOLEAN}</math>.
The symbols = and /=, which are also infix, are instead parametrically polymorphic,
having type <math>(T,T) \to \mathrm{BOOLEAN}</math>
for every first-order type <math>T</math>.
They are interpreted respectively as the identity relation and its complement.

The DISTINCT symbol is both overloaded and polymorphic.
It has type <math>(T,...,T) \to \mathrm{BOOLEAN}</math>
for every sequence <math>(T,...,T)</math> of length <math>n > 0</math>
and first-order type <math>T</math>.
For each <math>n > 0</math>, it is interpreted as the relation
that holds exactly for tuples of pairwise distinct elements.

The syntax for quantifiers is similar to that of the lambda binder.

Here is an example of a formula built just of these logical symbols and variables:

A, B: TYPE;

q: BOOLEAN = FORALL (x,y: A, i,j,k: B):
i = j AND i /= k => EXISTS (z: A): x /= z OR z /= y;

Binding and scoping of quantified variables follows the same rules as
in let expressions.
In particular, a quantifier will shadow in its scope any constant and function symbols
with the same name as one of the variables it quantifies:

A: TYPE;
i, j: INT;

% The first occurrence of i and of j in f are constant symbols,
% the others are variables.

f: BOOLEAN = i = j AND FORALL (i,j: A): i = j OR i /= j;

Optionally, it is also possible to specify instantiation patterns
for quantified variables.
The general syntax for a quantified formula <math>\psi</math> with patterns is

<center>
<math>
Q\;(x_1:T_1, \ldots, x_k:T_k):\; p_1: \ldots\; p_n:\; \varphi
</math>
</center>

where <math>n \geq 0</math>, <math>Q</math> is
either <math>\mathrm{FORALL}</math> or <math>\mathrm{EXISTS}</math>,
<math>\varphi</math> is a term of type <math>\mathrm{BOOLEAN}</math>,
and each of the <math>p_i</math>'s,
a pattern for the quantifier <math>Q\;(x_1:T_1, \ldots, x_k:T_k)</math>, has the form

<center>
<math>
\mathrm{PATTERN}\; (t_1, \ldots, t_m)
</math>
</center>

where <math>m > 0</math> and <math>t_1, \ldots, t_m</math> are
arbitrary binder-free terms (no lets, no quantifiers).
Those terms can contain (free) variables, typically, but not exclusively,
drawn from <math>x_1, \ldots, x_k</math>.
(Additional variables can occur if <math>\psi</math> occurs in a bigger formula
binding those variables.)

A: TYPE;
b, c: A;
p, q: A -> BOOLEAN;
r: (A, A) -> BOOLEAN;

ASSERT FORALL (x0, x1, x2: A):
PATTERN (r(x0, x1), r(x1, x2)):
(r(x0, x1) AND r(x1, x2)) => r(x0, x2) ;

ASSERT FORALL (x: A):
PATTERN (r(x, b)):
PATTERN (r(x, c)):
p(x) => q(x) ;

ASSERT EXISTS (y: A):
FORALL (x: A):
PATTERN (r(x, y), p(y)):
r(x, y) => q(x) ;

Patterns have no logical meaning:
adding them to a formula does not change its semantics.
Their purpose is purely operational, as explained in
the [[#Instantiation Patterns | Instantiation Patterns]] section.

In addition to these constructs, CVC4 also has a general mixfix conditional operator
of the form

<center>
<math>
\mathrm{IF}\ b\ \mathrm{THEN}\ t\ \mathrm{ELSIF}\ b_1\ \mathrm{THEN}\ t_1\ \ldots\ \mathrm{ELSIF}\ b_n\ \mathrm{THEN}\ t_n\ \mathrm{ELSE}\ t_{n+1}\ \mathrm{ENDIF}
</math>
</center>

with <math>n \geq 0</math> where
<math>b, b_1, \ldots, b_n</math> are terms of type <math>\mathrm{BOOLEAN}</math> and
<math>t, t_1, \ldots, t_n, t_{n+1}</math> are terms of the same first-order type <math>T</math>:

% Conditional term
x, y, z, w: REAL;

t: REAL =
IF x > 0 THEN y
ELSIF x >= 1 THEN z
ELSIF x > 2 THEN w
ELSE 2/3 ENDIF;

=== User-defined Functions and Types ===

The theory of user-defined functions,also know in the SMT literature as
the theory ''Equality over Uninterpreted Functions'', or ''EUF'', is in effect
a family of theories of equality parametrized by the basic types and the free symbols
a user can define during a run of CVC4.

This theory has no built-in symbols (other than the logical ones).
Its types consist of ''all and only'' the user-defined types.
Its function symbols consist of ''all and only'' the user-defined free symbols.

=== Arithmetic ===

The real arithmetic theory has two types:
<math>\mathrm{REAL}</math> and <math>\mathrm{INTEGER}</math>
with the latter a subtype of the first.
Its built-in symbols for the usual arithmetic constants
and operators over the type <math>\mathrm{REAL}</math>, each with the expected type:
all numerals 0, 1, ..., as well as - (both unary and binary), +, *, /, <, >, <=, >=.
Application of the binary symbols are in infix form.
Note that + is only binary, and so an expression such as +4 is ill-formed.

Rational values can be expressed in decimal or fractional format,
e.g., 0.1, 23.243241, 1/2, 3/4, and so on.
A leading 0 is mandatory for decimal numbers smaller than one
(e.g., the syntax .3 cannot be used as a shorthand for 0.3).
However, a trailing 0 is ''not'' required for decimals that are whole numbers
(e.g., 3. is allowed as a shorthand for 3.0).
The size of the numerals used in the representation of natural and rational numbers
is unbounded; more accurately, bounded only by the amount of available memory.

=== Bit vectors ===

=== Arrays ===

The theory of arrays is a parametric theory of (total) unary maps.
It comes equipped with mixfix polymorphic selection and update operators, respectively
<center>
<math>\_[\_]</math> and <math>\_\ \mathrm{WITH}\ [\_]\ := \_</math> .
</center>
The semantics of these operators is the expected one:
for all first-order types <math>T_1</math> and <math>T_2</math>,
if <math>a</math> is of type <math>\mathrm{ARRAY}\ T_1 \mathrm{OF}\ T_2</math>,
<math>i</math> is of type <math>T_1</math>, and
<math>v</math> is of type <math>T_2</math>,
* <math>a[i]</math> denotes the value that <math>a</math> associates to index <math>i</math>,
* <math>a\ \mathrm{WITH}\ [i]\ := v</math> denotes a map that associates <math>v</math> to index <math>i</math> and is otherwise identical to <math>a</math>.
Sequential updates can be chained with the shorthand syntax
<math>\_\ \mathrm{WITH}\ [\_]\ := \_, \ldots, [\_]\ := \_</math>.

A: TYPE = ARRAY INT OF REAL;
a: A;
i: INT = 4;

% selection:

elem: REAL = a[i];

% update

a1: A = a WITH [10] := 1/2;

% sequential update
% (syntactic sugar for (a WITH [10] := 2/3) WITH [42] := 3/2)

a2: A = a WITH [10] := 2/3, [42] := 3/2;

Since arrays are just maps, equality between them is extensional, that is,
for two arrays of the same type to be different they have to map at least one
index to differ values.

=== Data types ===

The theory of inductive data types is in fact a family of theories parametrized
by a data type declaration specifying constructors and selectors
for one or more user-defined data types.

No built-in operators other than equality and disequality are provided
for this family in the native language.
Each user-provided data type declaration, however, generates constructor, selector and tester operators
as described in the [[#Inductive Data Types | Inductive Data Types]] section.

=== Tuples and Records ===

Semantically both records and tuples can be seen as special instances
of inductive data types.
CVC4 implements them internally indeed as data types.
In essence, a record type <math>[\#\ l_0:T_0, \ldots, l_n:T_n\ \#]</math>
is encoded as a data type of the form

<center>
<math>
\begin{array}{l}
\mathrm{DATATYPE} \\
\ \ \mathrm{Record} = \mathit{rec}(l_0:T_0, \ldots, l_n:T_n) \\
\mathrm{END};
\end{array}
</math>
</center>

Tuples of length <math>n</math> are in turn special cases of records whose field names are
the numerals from <math>0</math> to <math>n-1</math>.

Externally, tuples and records have their own syntax for constructor and selector operators.
* Records of type <math>[\#\ l_0:T_0, \ldots, l_n:T_n\ \#]</math> have the associated record constructor <math>(\#\ l_0 := \_,\; \ldots,\; l_n := \_\ \#)</math> whose arguments must be terms of type <math>T_0, \ldots, T_n</math>, respectively.
* Tuples of type <math>[\ T_0, \ldots, T_n\ ]</math> have the associated tuple constructor <math>(\ \_,\; \ldots,\; \_\ )</math> whose arguments must be terms of type <math>T_0, \ldots, T_n</math>, respectively.

The selector operators on records and tuples follows a dot notation syntax.

% Record construction and field selection
Item: TYPE = [# key: INT, weight: REAL #];

x: Item = (# key := 23, weight := 43/10 #);
k: INT = x.key;
v: REAL = x.weight;

% Tuple construction and projection
y: [REAL, INT, REAL] = ( 4/5, 9, 11/9 );
first_elem: REAL = y.0;
third_elem: REAL = y.2;

Differently from data types, records and tuples are also provided with built-in update operators similar in syntax and semantics to the update operator for arrays.
More precisely, for each record type <math>[\#\ l_0:T_0, \ldots, l_n:T_n\ \#]</math> and
each <math>i=0, \ldots, n</math>, CVC4 provides the operator

<center>
<math>
\_\ \mathrm{WITH}\ .l_i\ := \_
</math>
</center>

The operator maps a record <math>r</math> of that type and a value <math>v</math>
of type <math>T_i</math> to the record that stores <math>v</math> in field <math>l_i</math>
and is otherwise identical to <math>r</math>.
Analogously, for each tuple type <math>[T_0, \ldots, T_n]</math> and
each <math>i=0, \ldots, n</math>, CVC4 provides the operator

<center>
<math>
\_\ \mathrm{WITH}\ .i\ := \_
</math>
</center>

with similar semantics.

% Record updates

Item: TYPE = [# key: INT, weight: REAL #];

x: Item = (# key := 23, weight := 43/10 #);

x1: Item = x WITH .weight := 48;

% Tuple updates

Tup: TYPE = [REAL,INT,REAL];
y: Tup = ( 4/5, 9, 11/9 );
y1: Tup = y WITH .1 := 3;

Updates to a nested component can be combined in a single WITH operator:

Cache: TYPE = ARRAY [0..100] OF [# addr: INT, data: REAL #];
State: TYPE = [# pc: INT, cache: Cache #];

s0: State;
s1: State = s0 WITH .cache[10].data := 2/3;

Note that, differently from updates on arrays, tuple and record updates are
just additional syntactic sugar.
For instance, the record <code>x1</code> and tuple <code>y1</code> defined above
could have been equivalently defined as follows:

% Record updates

Item: TYPE = [# key: INT, weight: REAL #];

x: Item = (# key := 23, weight := 43/10 #);

x1: Item = (# key := x.key, weight := 48 #);

% Tuple updates

Tup: TYPE = [REAL,INT,REAL];
y: Tup = ( 4/5, 9, 11/9 );
y1: Tup = ( y.0, 3, y.1 );

== Commands ==

In addition to declarations of types and function symbols,
the CVC4 native language contains the following commands:

* <math>\mathrm{ASSERT}\ F</math> -- Add the formula <math>F</math> to the current logical context <math>\Gamma</math>.
* [[#CHECKSAT|<math>\mathrm{CHECKSAT}\ F</math>]] -- Check if the formula <math>F</math> is satisfiable in the current logical context (<math>\Gamma \not\models_T \mathrm{NOT}\ F</math>).
* <math>\mathrm{CONTINUE}</math> -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, search for a counter-example different from the current one.
* [[#COUNTEREXAMPLE|<math>\mathrm{COUNTEREXAMPLE}</math>]] -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, print the context that is a witness for invalidity/satisfiability.
* [[#COUNTERMODEL|<math>\mathrm{COUNTERMODEL}</math>]] -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, print a model that makes the formula invalid/satisfiable. The model is provided in terms of concrete values for each free symbol.
* <math>\mathrm{OPTION}\ o\ v</math> -- Set the command-line option flag <math>o</math> to value <math>v</math>. The argument <math>o</math> is provide as a string literal enclosed in double-quotes and <math>v</math> as an integer value.
* <math>\mathrm{POP}</math> -- Equivalent to <math>\mathrm{POPTO}\ 1</math>
* [[#POPTO|<math>\mathrm{POPTO}\ n</math>]] -- Restore the system to the state it was in right before the most recent call to <math>\mathrm{PUSH}</math> made from stack level <math>n</math>. Note that the current stack level is printed as part of the output of the <math>\mathrm{WHERE}</math> command.
* <math>\mathrm{PUSH}</math> -- Save (checkpoint) the current state of the system.
* [[#QUERY|<math>\mathrm{QUERY}\ F</math>]] -- Check if the formula <math>F</math> is valid in the current logical context (<math>\Gamma\models_T F</math>).
* [[#RESTART|<math>\mathrm{RESTART}\ F</math>]] -- After an invalid <math>\mathrm{QUERY}</math> or satisfiable <math>\mathrm{CHECKSAT}</math>, repeat the check but with the additional assumption <math>F</math> in the context.
* <math>\mathrm{PRINT}\ t</math> -- Parse and print back the term <math>t</math>.
* <math>\mathrm{TRANSFORM}\ t</math> -- Simplify the term <math>t</math> and print the result.
* <math>\mathrm{WHERE}</math> -- Print all the formulas in the current logical context <math>\Gamma</math>.

The remaining commands take a single argument, given as a string literal enclosed in double-quotes.

* <math>\mathrm{ECHO}\ s</math> -- Print string <math>s</math>
* <math>\mathrm{INCLUDE}\ f</math> -- Read commands from file <math>f</math>.
* <math>\mathrm{TRACE}\ f</math> -- Turn on tracing for the debug flag <math>f</math>.
* <math>\mathrm{UNTRACE}\ f</math> -- Turn off tracing for the debug flag <math>f</math>.

Here, we explain some of the above commands in more detail.

=== QUERY ===

The command <math>\mathrm{QUERY}\ F</math> invokes the core functionality of CVC4 to check
the validity of the formula <math>F</math> with respect to the assertions made thus far,
which constitute the context <math>\Gamma</math>.
The argument <math>F</math> must be well typed term of type <math>\mathrm{BOOLEAN}</math>,
as described in [[#Terms and Formulas | Terms and Formulas]].

The execution of this command always terminates and produces one of three possible answers:
<code>valid</code>, <code>invalid</code>, and <code>unknown</code>.

* A <code>valid</code> answer indicates that <math>\Gamma \models_T F</math>. After a query returning such an answer, the logical context <math>\Gamma</math> is exactly as it was before the query.
* An <code>invalid</code> answer indicates that <math>\Gamma \not\models_T F</math>, that is, there is a model of the background theory <math>T</math> that satisfies <math>\Gamma \cup \{\mathrm{NOT}\ F\}</math>. When <math>\mathrm{QUERY}\ F</math> returns <code>invalid</code>, the logical context <math>\Gamma</math> is augmented with a set <math>\Delta</math> of ground (i.e., variable-free) literals such that <math>\Gamma\cup\Delta</math> is satisfiable in <math>T</math>, but <math>\Gamma\cup\Delta\models_T \mathrm{NOT}\ F</math>. In fact, in this case <math>\Delta</math> ''propositionally entails'' <math>\mathrm{NOT}\ F</math>, in the sense that, every truth assignment to the literals of <math>\Delta</math> that satisfies <math>\Delta</math> falsifies <math>F</math>. We call the new context <math>\Gamma\cup\Delta</math> a ''counterexample'' for <math>F</math>.
* An <code>unknown</code> answer is similar to an <code>invalid</code> answer in that additional literals are added to the context which propositionally entail <math>\mathrm{NOT}\ F</math>. The difference in this case is that CVC4 cannot guarantee that <math>\Gamma\cup\Delta</math> is actually satisfiable in <math>T</math>.

CVC4 may report <code>unknown</code> when the context or the query contains
non-linear arithmetic terms or quantifiers.
In all other cases, it is expected to be sound and complete,
i.e., to report <code>Valid</code> if <math>\Gamma \models_T F</math>
and <code>Invalid</code> otherwise.

After an <code>invalid</code> (resp. <code>unknown</code>) answer,
counterexamples (resp. possible counterexamples) can be obtained with
a <math>\mathrm{WHERE}</math>, <math>\mathrm{COUNTEREXAMPLE}</math>,
or <math>\mathrm{COUNTERMODEL}</math> command.


Since the <math>\mathrm{QUERY}</math> command may modify
the current context, if one needs to check several formulas in a row
in the same context, it is a good idea to surround every
query by a <math>\mathrm{PUSH}</math> and <math>\mathrm{POP}</math> invocation
in order to preserve the context:

PUSH;
QUERY <formula>;
POP;

=== CHECKSAT ===

The command <math>\mathrm{CHECKSAT}\ F</math> behaves identically
to <math>\mathrm{QUERY}\ \mathrm{NOT}\ F</math>.

=== RESTART ===

The command <math>\mathrm{RESTART}\ F</math> can only be invoked after an invalid query.
For example, in an interactive setting:

QUERY <formula>;

CVC4> invalid

RESTART <formula2>;

Functionally, the behavior of the above command sequence is identical to the following:

PUSH;
QUERY <formula>;
POP;
ASSERT <formula2>;
QUERY <formula>;

The advantage of using the <math>\mathrm{RESTART}</math> command is that
the first command sequence may be executed much more efficiently that the second.
The reason is that with <math>\mathrm{RESTART}</math> CVC4 will re-use
what it has learned while answering the previous query rather than starting
over from scratch.

=== COUNTERMODEL ===

[More]

=== COUNTEREXAMPLE ===

[More]

=== POPTO ===

[More]

== Instantiation Patterns ==

CVC4 processes each universally quantified formula in the current context
by adding instances of the formula obtained by replacing its universal variables
with ground terms.
Patterns restrict the choice of ground terms for the quantified variables,
with the goal of controlling the potential explosion of ground instances.
In essence, adding patterns to a formula is a way for the user to tell CVC4
to focus only on certain instances which, in the user's opinion, will be
most helpful during a proof.

In more detail, patterns have the following effect on formulas that are found
in the logical context or get added to it later while CVC4 is trying to prove
the validity of some formula <math>F</math>.

If a formula in the current context starts with an existential quantifier,
CVC4 ''Skolemizes'' it, that is, replaces it in the context with the formula
obtained by substituting the existentially quantified variables
by fresh constants and dropping the quantifier.
Any patterns for the existential quantifier are simply ignored.

If a formula starts with a universal quantifier
<math>\mathrm{FORALL}\; (x_1:T_1, \ldots, x_n:T_n)</math>,
CVC4 adds to the context a number of instances of the formula,
with the goal of using them to prove the query <math>F</math> valid.
An instance is obtained by replacing each <math>x_i</math> with a ground term
of the same type occurring in one of the formulas in the context,
and dropping the universal quantifier.
If <math>x_i</math> occurs in a pattern
<math>\mathrm{PATTERN}\; (t_1, \ldots, t_m)</math> for the quantifier,
it will be instantiated only with terms obtained by simultaneously matching
all the terms in the pattern against ground terms in the current context
<math>\Gamma</math>.

Specifically, the matching process produces one or more substitutions
<math>\sigma</math> for the variables in <math>(t_1, \ldots, t_m)</math>
which satisfy the following invariant:
for each <math>i = 1, \ldots, m</math>, <math>\sigma(t_i)</math> is
a ground term and there is a ground term <math>s_i</math> in <math>\Gamma</math>
such that <math>\Gamma \models_T \sigma(t_i) = s_i</math>.
The variables of <math>(x_1:T_1, \ldots, x_n:T_n)</math> that occur
in the pattern are instantiated only with those substitutions
(while any remaining variables are instantiated arbitrarily).

The Skolemized version or the added instances of a context formula may themselves
start with a quantifier.
The same instantiation process is applied to them too, recursively.

Note that the matching mechanism is not limited to syntactic matching
but is modulo the equations asserted in the context.
Because of decidability and/or efficiency limitations, the matching process
is not exhaustive.
CVC4 will typically miss some substitutions that satisfy the invariant above.
As a consequence, it might fail to prove the validity of the query formula
<math>F</math>, which makes CVC4 incomplete for contexts containing
quantified formulas.
It should be noted though that exhaustive matching, which can be achieved
simply by not specifying any patterns, does not yield completeness anyway
since the instantiation of universal variables is still restricted
to just the ground terms in the context,
whereas in general additional ground terms might be needed.

About CVC4

2012-12-01T02:09:17Z

Clark Barrett:

About CVC4

2012-12-01T02:08:40Z

Clark Barrett:

About CVC4

2012-12-01T02:07:06Z

Clark Barrett:

About CVC4

2012-12-01T02:06:49Z

Clark Barrett:

About CVC4

2012-12-01T02:06:06Z

Clark Barrett:

Publications

2012-12-01T02:01:22Z

Clark Barrett:

Papers about the tool
* Clark Barrett, Christopher L. Conway, Morgan Deters, Liana Hadarean, Dejan Jovanović, Tim King, Andrew Reynolds, and Cesare Tinelli. [http://cs.nyu.edu/~barrett/pubs/BCD+11.pdf CVC4]. Lecture Notes in Computer Science, 2011, Volume 6806, Computer Aided Verification, Pages 171-177.

Papers describing original research that was incorporated into CVC4
* Theory Combination
** Dejan Jovanović and Clark Barrett. [http://cs.nyu.edu/~barrett/pubs/JB10-SMT.pdf Sharing is Caring]. In Proceedings of the 8th International Workshop on Satisfiability Modulo Theories (SMT '10), July 2010.
** Dejan Jovanović and Clark Barrett. [http://cs.nyu.edu/~barrett/pubs/JB10-TR.pdf Polite Theories Revisited]. In Proceedings of the Seventeenth International Conference on Logic for Programming, Artificial Intelligence, and Reasoning (LPAR '10), volume 6397 of Lecture Notes in Computer Science, pages 402-416. Springer, October 2010. Yogyakarta, Indonesia.

Applications of CVC4
* Tim King and Clark Barrett. [http://cs.nyu.edu/~barrett/pubs/KB11.pdf Exploring and Categorizing Error Spaces using BMC and SMT]. In Proceedings of the 9th International Workshop on Satisfiability Modulo Theories (SMT '11), July 2011.

About CVC4

2012-12-01T01:34:52Z

Clark Barrett:

About CVC4

2012-12-01T01:29:20Z

Clark Barrett:

CVC4 is a solver for [http://en.wikipedia.org/wiki/Satisfiability_Modulo_Theories Satisifiability Modulo Theories (SMT) ] (for a more formal introduction to SMT see the following book chapter [https://cs.nyu.edu/~barrett/pubs/BSST09.pdf Satisfiability Modulo Theories] ). Technically, it is an automated validity checker for a many-sorted (i.e., typed) first-order logic with built-in theories.

CVC4 currently has support for the following theories:
* equality over free (aka uninterpreted) function and predicate symbols
* real and integer linear arithmetic
* bit-vectors,
* arrays
* tuples
* records
* user-defined inductive data types.

It also supports the use of quantifiers through heuristic instantiation and can produce models for quantifier-free satisfiable queries.

=History of CVC=

[[File:svc.gif|thumb|border|100px|The SVC logo.]]
[[File:cvc3_logo.jpg|thumb|border|100px|The CVC3 logo.]]
[[File:cvc3_night_logo.png|thumb|border|100px|The CVC3 "by night" logo, used for nightly builds and regressions.]]
[[File:cvc3cvc4.png|thumb|border|100px|An early CVC4 logo.]]

The Cooperating Validity Checker series has a long history. The
Stanford Validity Checker (SVC) came first in 1996, incorporating
theories and its own SAT solver. Its successor, the Cooperating
Validity Checker (CVC), had a more optimized internal design, produced
proofs, used the Chaff SAT solver, and featured a number of usability
enhancements. Its name comes from the cooperative nature of decision
procedures in Nelson-Oppen theory combination, which share amongst
each other equalities between shared terms. CVC Lite, first made
available in 2003, was a rewrite of CVC that attempted to make CVC
more flexible (hence the "lite") while extending the feature set: CVC
Lite supported quantifiers where its predecessors did not. CVC3 was a
major overhaul of portions of CVC Lite: it added better decision
procedure implementations, added support for using MiniSat in the
core, and had generally better performance.

[[File:cvc4-logo.png|thumb|border|100px|The CVC4 logo.]]
CVC4 is the new version, the fifth generation of this validity checker
line that is now celebrating sixteen years of heritage. It represents
a complete re-evaluation of the core architecture to be both
performant and to serve as a cutting-edge research vehicle for the
next several years. Rather than taking CVC3 and redesigning problem
parts, we've taken a clean-room approach, starting from scratch.
Before using any designs from CVC3, we have thoroughly scrutinized,
vetted, and updated them. Many parts of CVC4 bear only a superficial
resemblance, if any, to their correspondent in CVC3.

However, CVC4 is fundamentally similar to CVC3 and many other modern
SMT solvers: it is a DPLL(T) solver, with a SAT solver at its core and
a delegation path to different decision procedure implementations,
each in charge of solving formulas in some background theory.

The re-evaluation and ground-up rewrite was necessitated, we felt, by
the performance characteristics of CVC3. CVC3 has many useful
features, but some core aspects of the design led to high memory use,
and the use of heavyweight computation (where more nimble engineering
approaches could suffice) makes CVC3 a much slower prover than other
tools. As these designs are central to CVC3, a new version was
preferable to a selective re-engineering, which would have ballooned
in short order. Some specific deficiencies of CVC3 are mentioned in
this article.

CVC4

2012-12-01T01:27:39Z

Clark Barrett:

CVC4 is an automatic theorem prover for Satisfiability Modulo Theories (SMT) problems. It can be used to prove the validity (or, dually, the satisfiability) of first-order formulas in a large number of built-in logical theories and their combination.

CVC4 is the most recent of a series of popular SMT provers, which originated at Stanford University with the SVC system. CVC4 is a from-scratch redesign and reimplementation of earlier solvers; it is designed for flexibility as a research tool and performance as an industrial SMT solver.

CVC4 works with a version of first-order logic and has a wide variety of features including:

* several built-in base theories: rational and integer linear arithmetic, arrays, tuples, records, inductive data types, bit vectors, and equality over uninterpreted function symbols;
* support for quantifiers;
* an interactive text-based interface;
* a rich [http://church.cims.nyu.edu/cvc4-builds/documentation/public/latest/ C++ API] for embedding in other systems;
* model generation abilities;
* source compatibility with much of the CVC3 API via a "compatibility library";
* essentially no limit on its use for research or commercial purposes (see [http://church.cims.nyu.edu/cvc4-builds/documentation/public/latest/COPYING_source.html license]).

Acknowledgments

2012-10-10T21:36:30Z

Clark Barrett:

CVC4 is supported in part by the following organizations:

* [http://www.wpafb.af.mil/AFRL/afosr/ The Air Force Office of Scientific Research]
* [http://www.intel.com/ Intel Corporation]
* [http://www.nsf.gov/ The National Science Foundation]
* [http://www.nyu.edu/ New York University]
* [http://www.src.org/ The Semiconductor Research Corporation] (contract 2008-TJ-1850)

Any opinions, findings and conclusions or recommendations expressed in this site are those of the authors and do not necessarily reflect the views of the organizations listed above.

Acknowledgments

2012-10-10T21:36:14Z

Clark Barrett:

CVC4 is supported in part by the following organizations:

* [http://www.wpafb.af.mil/AFRL/afosr/ The Air Force Office of Scientific Research]
* [http://www.intel.com/ Intel Corporation]
* [http://www.nsf.gov/ The National Science Foundation]
* [http://www.nyu.edu/ New York University]
* [http://www.src.org/ The Semiconductor Research Corporation (contract 2008-TJ-1850)

Any opinions, findings and conclusions or recommendations expressed in this site are those of the authors and do not necessarily reflect the views of the organizations listed above.

CVC4

2012-05-16T17:49:02Z

Clark Barrett:

Welcome to the CVC portal and CVC4 developers' wiki. This service is only intended for the developers of CVC4 at [http://www.nyu.edu/ NYU] and [http://www.uiowa.edu/ UIowa].

A valid login is required for many of these links.

'''Relevant to CVC4 development:'''
* [[Developer Meeting Minutes]]<ul>{{#ifexist: Meeting Minutes - {{#timel:F j, Y}}|<li>[[Meeting Minutes - {{#timel:F j, Y}}|'''Today's meeting''' - {{#timel:D M j}}]]</li>}}{{#if: {{mtglinks_recent}}|<li>'''Recent meetings:''' {{mtglinks_recent}}</li>}}{{#if: {{mtglinks_upcoming}}|<li>'''Upcoming meetings:''' {{mtglinks_upcoming}}</li>}}</ul>
* [http://church.cims.nyu.edu/~mdeters/cvc4-devel.logs/ cvc4-devel IRC logs]
* [[CVC4 Contest|CVC4 Contest]]
* [[CVC4 Wishlist|CVC4 wishlist]]
* [[Developer's Guide]]
* [[User's Manual]]
* [[How do I... ?]]
* [[Library|Our library: bibliographical references of interest]]
* [[To Discuss|Items "yet to discuss"]]
* [[CVC4 Parsing]]
* [[How to write a theory in CVC4]]

'''Some CVC3 resources:'''
* [http://www.cs.nyu.edu/acsys/bugs/ CVC3 Bugzilla]
* [http://www.cs.nyu.edu/acsys/cvc3/wiki CVC3 Wiki]
* [http://cs.nyu.edu/mailman/listinfo/cvc-devel Mailing list]
* [http://cs.nyu.edu/acsys/cvc3/ CVC3 public page]
* [[Fuzz-testing, October 2009|Results of Fuzz-testing CVC3 prior to release]]

'''Some CVC4 resources:'''
* [http://church.cims.nyu.edu/bugzilla/ CVC4 Bugzilla]
* [http://cs.nyu.edu/mailman/listinfo/cvc4-devel Mailing list]


'''Relevant to this wiki:'''
* [[User Registration|User registration]]
* [[Developer Resources|Developer resources]]
* [[Using SSL with Church]]

To register as a new user, or recommend someone for an account, contact [http://cs.nyu.edu/~dejan/ Dejan] or [http://cs.nyu.edu/~mdeters/ Morgan].

Developer's Guide

2010-06-14T15:16:38Z

Clark Barrett: /* ANTLR3 */

In addition to this wiki, we also have a [http://cs.nyu.edu/mailman/listinfo/cvc4-devel developer mailing list] and [http://goedel.cims.nyu.edu/bugzilla3/ Bugzilla database] for this version of CVC. CVC3 resources have been kept separate, at this time, because of the different needs of CVC4 during active development.

=Source tree layout=

* <code>config</code> - this directory holds m4 macro processor files (autoconf code) as well as bits of the autotools build system that go out as part of the distribution to ''smooth over'' platform differences.
* <code>contrib</code> - this directory includes maintainer scripts and other things that aren't '''directly''' part of CVC4
* <code>doc</code> - documentation
* <code>src/context</code> - context manager, context-dependent object/collection sources
* <code>src/expr</code> - the expression package
* <code>src/include</code> - public includes (installed in /usr/local or whatever on a users' machines)
* <code>src/main</code> - source for the main cvc4 binary
* <code>src/parser</code> - parsers for supported CVC4 input formats
* <code>src/prop</code> - propositional parts of CVC4; these include imported minisat sources and the PropEngine
* <code>src/smt</code> - SmtEngine
* <code>src/theory</code> - the TheoryEngine and all theory solvers
* <code>src/util</code> - utility classes, debugging macros, the Exception class, etc.
* <code>test</code> - CxxTest unit tests (invoked by <code>make check</code>)

=Using CVC4's Subversion source control repository=

CVC4 keeps a source control repository using [http://subversion.tigris.org/ Subversion], allowing us to track changes, effectively branch and merge, etc.

==Accessing CVC4's repository==

Access to CVC4's Subversion repository is restricted; you must have an AcSys-group CIMS account, or apply to us for outside collaborator access to the repository. Once you have access, you can:

<nowiki>svn --username $USERNAME checkout https://subversive.cims.nyu.edu/cvc4/cvc4/trunk cvc4</nowiki>

...where <code>$USERNAME</code> is your CIMS username (or the username you were given as an outside collaborator). If your username on the Windows/UNIX machine you're coming from is the same, you can leave out the <code>--username $USERNAME</code> part.

The above checks out <code>/cvc4/cvc4/trunk</code> to your local directory <code>cvc4</code>. This second argument (your local working directory for CVC4 development), you can of course call whatever you like. The first is the path in the repository. The initial <code>/cvc4</code> is the base of our repository (other groups' repositories are hosted on the same server). The second <code>/cvc4</code> in the path is the ''product'' (since we might decide to keep other, CVC4-related projects in the CVC4 repository even if they aren't directly part of CVC4. This includes things like useful benchmark suites (that aren't part of the source tree proper), benchmark-processing utilities, the nightly build system scripts, the webpage, etc. These things may not belong directly in the source tree, but are still worth keeping in the CVC4 repository. The third component of the path, <code>/trunk</code>, is the ''branch'' of CVC4 you're requesting. In Subversion terminology, ''trunk'' is the head of development: the most recent version of CVC4 that's been committed. The ''trunk'' is where most of our CVC4 mainline development will take place, for now. We may occasionally branch (see below) to develop and test new or experimental features, but generally these branches will be merged back into the trunk.

Once you've checked out a working directory, some helpful commands are:

* <code>svn update</code> - updates your working directory to the most recent version, merging updates into your edits)
* <code>svn status</code> - tells you what you've changed
* <code>svn diff</code> - gives you a diff of what you've changed

===Repository access from Eclipse===

From [http://www.eclipse.org/ Eclipse], you can go to <code>File -> New -> Project...</code> and then choose ''Project from SVN'' under the SVN category. Use the repository location <code>https://subversive.cims.nyu.edu/cvc4/cvc4/trunk</code> and click ''Finish.'' Your Eclipse CVC4 project is then associated to the repository and you can use the Subversion facilities of Eclipse to perform the operations in this section instead of the command line.

===Browsing the repository===

You can also browse CVC4 sources without checking them out from Subversion. Simply point your browser to:

https://subversive.cims.nyu.edu/cvc4/cvc4/trunk

Your browser may complain about the security certificate. Use your CIMS login and password, or the outside collaborator credentials we've given you.

==Branching and merging==

Branches live in the repository under <code>/cvc4/cvc4/branches</code>. You can see a list of all branches available (that haven't been deleted) by using <code>svn ls</code>:

<nowiki>svn --username $USERNAME ls https://subversive.cims.nyu.edu/cvc4/cvc4/branches</nowiki>

To check out a branch, you check out the branch path instead of the trunk:

<nowiki>svn --username $USERNAME checkout https://subversive.cims.nyu.edu/cvc4/cvc4/branches/experimental-quantifier-instantiation cvc4.quant</nowiki>

To get information about where a working directory came from, use <code>svn info</code>

<nowiki>
[mdeters@adric ~]$ cd cvc4
[mdeters@adric cvc4]$ svn info
Path: .
URL: https://subversive.cims.nyu.edu/cvc4/cvc4/trunk
Repository Root: https://subversive.cims.nyu.edu/cvc4
Repository UUID: 615e1583-3794-4256-8e52-04c157d34929
Revision: 59
Node Kind: directory
Schedule: normal
Last Changed Author: barrett
Last Changed Rev: 59
Last Changed Date: 2009-12-15 13:20:31 -0500 (Tue, 15 Dec 2009)

[mdeters@adric cvc4]$
</nowiki>

===Creating a branch===

To create a branch, you ''copy'' the source tree to another place:

<nowiki>svn --username $USERNAME cp https://subversive.cims.nyu.edu/cvc4/cvc4/trunk https://subversive.cims.nyu.edu/cvc4/cvc4/branches/my-branch</nowiki>

...though '''please use a more descriptive name for your branch than this!''' Then proceed by checking out the branch:

<nowiki>svn --username $USERNAME checkout https://subversive.cims.nyu.edu/cvc4/cvc4/branches/my-branch cvc4.mybranch</nowiki>

Before doing lots of development on it, please document why your branch exists in a file named <code>README.<branchname></code> in the top-level directory:

<nowiki>
[mdeters@adric ~]$ cd cvc4
[mdeters@adric cvc4]$ vi README.my-branch
[mdeters@adric cvc4]$ cat README.my-branch
This branch is to test the ideas of Splitting On Demand in SMT:

ftp://ftp.cs.uiowa.edu/pub/tinelli/papers/BarNOT-LPAR-06.pdf

-- Morgan Deters <mdeters@cs.nyu.edu> Tue, 15 Dec 2009 17:31:01 -0500
[mdeters@adric cvc4]$ svn add README.my-branch
[mdeters@adric cvc4]$ svn commit
</nowiki>

This makes it easy to see what each branch exists for (without even checking it out):

<nowiki>svn --username $USERNAME cat https://subversive.cims.nyu.edu/cvc4/cvc4/branches/my-branch/README.my-branch
This branch is to test the ideas of Splitting On Demand in SMT:

ftp://ftp.cs.uiowa.edu/pub/tinelli/papers/BarNOT-LPAR-06.pdf

-- Morgan Deters <mdeters@cs.nyu.edu> Tue, 15 Dec 2009 17:31:01 -0500
</nowiki>

Of course, the above example created a branch from the trunk. That need not be the case; you might create a branch from another branch (simply copy that branch instead of the trunk).

===Merging a branch back to the trunk===

Recent versions of Subversion make merging incredibly easy, because for versions of CVC4 with a common ancestral line (which you get from branching) have ''merge metadata'' stored regarding their merges. This makes it '''much, MUCH''' easier to merge than it used to be under CVS. Let's say you've created a branch <code>my-branch</code> from the CVC4 trunk, like above. First, commit all your changes to my-branch that you want. Then, get a clean copy of the CVC4 trunk:

<nowiki>
[mdeters@adric ~]$ svn co https://subversive.cims.nyu.edu/cvc4/cvc4/trunk cvc4.clean
[mdeters@adric ~]$ cd cvc4.clean
[mdeters@adric cvc4.clean]$ svn merge https://subversive.cims.nyu.edu/cvc4/cvc4/branches/my-branch
</nowiki>

That's all there is to it. Subversion will merge all of the differences between ''trunk'' and ''my-branch'' '''since the last merge''' into the working directory. That's the key part: '''since the last merge.''' It keeps track of this information for you. You can inspect the changes, do a test build, and when you're happy with the changes, commit them.

You might occasionally merge the other way, too. If you've been developing along a branch for a long time, you might want to get the newest bugfixes from other parts of CVC4 that have been committed to the trunk. You can merge changes in the trunk to my-branch as well:

<nowiki>
[mdeters@adric ~]$ cd cvc4.my-branch
[mdeters@adric cvc4.my-branch]$ svn merge https://subversive.cims.nyu.edu/cvc4/cvc4/trunk
</nowiki>

Naturally, if you don't want to incorporate changes into/from the trunk, but rather another version, then specify that URL instead.

==Symbolically tagging a version==

Symbolically tagging a branch (for example, a release version) is very similar to [[#Creating a branch|branching]], but put under <code>/tags</code> instead of <code>/branches</code>. For example:

<nowiki>svn --username $USERNAME cp https://subversive.cims.nyu.edu/cvc4/cvc4/trunk https://subversive.cims.nyu.edu/cvc4/cvc4/tags/cade2010</nowiki>

Just as with branching, please provide a README file:

<nowiki>
[mdeters@adric ~]$ svn --username $USERNAME checkout https://subversive.cims.nyu.edu/cvc4/cvc4/tags/cade2010 cvc4.cade2010
[mdeters@adric ~]$ cd cvc4.cade2010
[mdeters@adric cvc4.cade2010]$ vi README.cade2010
[mdeters@adric cvc4.cade2010]$ cat README.cade2010
cade2010 version of CVC4
------------------------
This version generated the results published in the CADE 2010 paper.

-- Morgan Deters <mdeters@cs.nyu.edu> Tue, 15 Dec 2009 17:39:05 -0500
[mdeters@adric cvc4.cade2010]$ svn add README.cade2010
[mdeters@adric cvc4.cade2010]$ svn commit
</nowiki>

==Branches versus tags==

Use a [[#Creating a branch|''branch'']] when you plan to do major (and perhaps experimental) editing on the source tree and don't want to screw up the nightly builds, tests, or other developers with a work in progress. Use a [[#Symbolically tagging a version|''tag'']] when no development will occur on the source tree; it's merely a "bookmark" on a historical version of CVC4 in case we need to refer to it later in the repository.

==Working with files and directories==

Occasionally a class name might change (and its source file will therefore need renaming), or you want to move around files and directories in other ways. In the old days under the CVS version control system, you had to remove the files under the old name/location and add them anew under the new name/location, losing all of the history information. Not so under Subversion. You can <code>mv</code> files and directories just like under UNIX:

svn mv foo.cpp bar.cpp

You can <code>mkdir</code>:

svn mkdir newdir

If you already have the directory (and sources in it), you can <code>svn add</code> it:

svn add newdir

The same goes with new source files:

svn add new_source_file.cpp

And, also, if you want to remove a file from the repository, you can do so:

svn rm obsolete_test.h

Note that these commands operate on the working directory. This has two consequences:

# You don't need to use <code>--username $USERNAME</code>, because the working directory is already linked to your login credentials (it was stored in the working directory meta-information when you checked out the working copy).
# The changes aren't immediate. You still need to use <code>svn commit</code> to commit your changes (and leave a log in the commit history).

==Reverting a file in a working directory==

Sometimes you make a local edit to a file and decide you want to undo the edit (restoring the last version you retrieved from the repository via a ''checkout'' or ''update''). To do that, use <code>svn revert</code>:

svn revert file.cpp

==Reverting a commit==

Sometimes you want to revert a commit previously done by you or someone else. Perhaps a bugfix actually caused more problems than it solved, or you want to back out of a refactoring decision that turned out to be a bad idea. Let's say that revision 120 was perfect but a bugfix committed as revision 121 broke something and you want to undo that change. Now the repository is at revision 130. No problem:

[mdeters@adric ~]$ svn co https://subversive.cims.nyu.edu/cvc4/cvc4/trunk cvc4.clean
[mdeters@adric ~]$ cd cvc4.clean
[mdeters@adric cvc4.clean]$ svn merge . -r 121:120

''Merge'' here means to ''merge the differences between two revisions;'' it's similar in some respects to the notion of ''merge'' between branches, but here there is no branch. Subversion computes a diff between revisions 121 and 120 (here, order is important---we're doing a rollback so the revision number goes down) and merges it into the working directory. The "." is the directory to be merged. Perhaps revision 121 committed a lot of things, and you only want to rollback the changes made to the context manager. No problem:

[mdeters@adric cvc4.clean]$ svn merge src/context -r 121:120

==Ignoring files==

If you're familiar with CVS, you're probably familiar with <code>.cvsignore</code> files---these are committed to the repository but are ''special'' in that they instruct CVS to ignore certain files in the working directory (and not report them as <code>?</code> when you update). In Subversion, an <code>svn status</code> is similar; it will complain about files that exist but aren't in the repository. You can tell Subversion to ignore some files if they shouldn't ever be committed to the repository by using the property system (specifically the <code>svn:ignore</code> property on directories). "<code>svn proplist</code>" lists the properties on a file/directory, "<code>svn propget</code>" and "<code>svn propset</code>" get and set a specific property value on a file or directory, "<code>svn propdel</code>" deletes a property, and "<code>svn propedit</code>" edits a property (using the current <code>$EDITOR</code> from your environment). For example:

[mdeters@adric ~]$ cd cvc4
[mdeters@adric cvc4]$ EDITOR=vi svn propedit svn:ignore .

...edits the <code>svn:ignore</code> property on the top-level cvc4 source directory with the <code>vi</code> editor.

Changes to properties are versioned and tracked as well; changes must be committed just like a file.

==Marking a file as executable in Subversion==

Another property is used for the eXecute bit. If you want to make a file executable, you can set the ''svn:executable'' property:

svn propset svn:executable yes ''filename''

==Resolving conflicts in a working directory==

Sometimes you do an <code>svn update</code> and the update procedure causes a ''conflict'' (because you made changes in the same place as someone else did). In such cases, Subversion punts: it doesn't know which change should override the other, or if they need to be combined in some (non-naïve) way.

Open the file with the conflict and edit it to remove the conflicts. If Subversion still thinks it's in conflict (it has a <code>C</code> mark when you run <code>svn status</code>), then you should inform it that the conflict has been resolved:

svn resolved conflicting_file.cpp

==For more information==

Refer to the [http://svnbook.red-bean.com/ Subversion book] for more information on Subversion and how to work with repositories.

=The CVC4 build system=

The build system behind CVC4 is pretty complex. It attempts to:

# be cross platform (automake, libtool, autoconf are used)
# support a set of standard ''build profiles'' (default, production, debug, competition) with standard settings for assertions, debugging symbols, etc.
# allow deviating from the standard build profile by overriding its settings
# keep separate object/library files and sources (doing ./configure from the source directory creates a build directory and configures it instead)
# support multiple builds at once in same source tree (build directory names are based on build profile, ''e.g.,'' debug or production, and architecture)
# support changing Makefile.am automake specifications without re-running a bootstrap script
# support partial tree rebuilding from the source directories (Makefile in source directory delegates to "current" build directory)
# support partial tree rebuilding from the build directories (recursive make)

Due to these constraints, the build system of CVC4 resembles a recursive-make implementation using automake/autoconf/libtool, ''except'' that it's very nonstandard.

==Build profiles==

The build profiles supported are:

* '''production''' - highly optimized, no assertions, no tracing
* '''debug''' - unoptimized, debug symbols, assertions, tracing
* '''default''' - moderately optimized, assertions, tracing
* '''competition''' - maximally optimized, no assertions, no tracing, muzzled

The default build profile is, not surprisingly, ''default''. That's what you'll get if you just run "<code>./configure</code>". To build a ''debug'' build, use:

$ ./configure debug

and then "<code>make</code>" as usual.

===Working with multiple, concurrent build profiles===

You can configure multiple types of builds. They are built in separate directories. "<code>make</code>" will always build the last-''configured'' one. If you want to build another (already configured) build, you can use "<code>make CURRENT_BUILD=debug</code>", but this is not "sticky"---the build profile built by default remains the last-''configured'' one. For example:

$ ./configure debug
[a debug build is configured under builds/[ARCH]/debug/]
$ make
[builds the debug build, puts the binaries under builds/bin/]
$ ./configure production
[a production build is configured under builds/[ARCH]/production/]
$ make
[builds the production build, puts the binaries under builds/bin]
$ make CURRENT_BUILD=[ARCH]/debug
[builds the debug build, puts the binaries under builds/bin]
$ make
[builds the '''production build'''---it was the last-''configured'' one]

Build profiles can be customized. For example, to make a debug build with support for profiling but without assertions, use:

$ ./configure debug --enable-profiling --disable-assertions

Note that when you override build profile options in this way, the build is considered distinct. Here, "debug-with-profiling-but-without-assertions" is distinct from a "debug" build:

$ ./configure debug --enable-profiling --disable-assertions
[a debug build with profiling and without assertions is configured under builds/[ARCH]/debug-profiling-noassertions/]
$ make
[builds the debug-noassertions-profiling build, puts the binaries under builds/bin/]
$ ./configure debug
[a debug build (with assertions, no profiling code) is configured under builds/[ARCH]/debug/]
$ make
[builds the debug build, puts the binaries under builds/bin]
$ make CURRENT_BUILD=[ARCH]/debug-noassertions-profiling
[builds the debug-noassertions-profiling build, puts the binaries under builds/bin]

===Determining the type of build from a binary===

Sometimes you're left with a ''cvc4'' binary and have no idea what produced it. Use the "<code>--show-config</code>" command-line option to inspect it:

$ builds/bin/cvc4 --show-config
This is a pre-release of CVC4.
Copyright (C) 2009, 2010
The ACSys Group
Courant Institute of Mathematical Sciences,
New York University
New York, NY 10012 USA

version : prerelease

debug code: yes
tracing : yes
muzzled : no
assertions: yes
coverage : no
profiling : no

To see if the binary is statically linked, or not, use the '''ldd''' command:

$ ldd builds/bin/cvc4
linux-gate.so.1 => (0x006b0000)
libcvc4parser.so.0 => /home/mdeters/cvc4-cleancheckout/builds/usr/local/lib/libcvc4parser.so.0 (0x00e6d000)
libcvc4.so.0 => /home/mdeters/cvc4-cleancheckout/builds/usr/local/lib/libcvc4.so.0 (0x00a75000)
libgmp.so.3 => /usr/lib/libgmp.so.3 (0x00110000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x008d8000)
libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0x00a11000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00298000)
libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0x002b6000)
/lib/ld-linux.so.2 (0x00d91000)

This was a dynamically-linked binary, and is dynamically-linked against the cvc4 libraries. If the cvc4 libraries are missing from the list, the binary was statically-linked against the cvc4 libraries (and dynamically-linked against the others). If ldd's output looks like this:

$ ldd /bin/bash-static
not a dynamic executable

then the cvc4 binary was configured with <code>--enable-static-binary</code>.

==Adding source and header files==

To add a ''source'' file to CVC4, all you need to do is create the file, add the content, then:

$ svn add source_file.cpp

to add it to the repository, and edit the appropriate <code>Makefile.am</code> (usually in that directory, or if not then in the immediate parent directory) to list the file under <code>*_SOURCES</code> for the correct convenience library. When you next build the project, the <code>Makefile.am</code>'s new timestamp should trigger ''make'' to regenerate the <code>Makefile.in</code> (in the source directory) and the Makefile (in the build directory), remake dependencies for the source, and rebuild what's necessary.

To add a ''header'' file to CVC4, create the file, add the content, then:

$ svn add header_file.h

to add it to the repository, and edit the appropriate <code>Makefile.am</code> to list the file under <code>*_SOURCES</code> for the correct convenience library. All the above should still apply.

If you have problems getting the Makefile.in/Makefile/dependencies rebuilt, or get a warning from the <code>missing</code> script, re-run <code>autogen.sh</code> in the top-level source directory, re-run <code>configure</code>, and then proceed.

==Adding source directories==

If you add a source ''directory'' to CVC4 (under <code>src/</code> or <code>test/</code>), make sure it's pristine (that is, just as you want it in the repository), and then:

# Add it to SVN: <pre>$ svn add newdir</pre>
# Make sure that the <code>Makefile.am</code> in the parent directory lists it in <code>SUBDIRS</code> in the correct order (''e.g.,'' if it depends on the build artifacts of another subdirectory, it should be listed after).
# Run <code>contrib/addsourcedir ''path''</code> to auto-generate a basic <code>Makefile</code> and <code>Makefile.am</code>. You'll need to edit the <code>Makefile.am</code>, but this gives you a template to start with. Existing files are not overwritten. Alternatively, you can generate these two Makefiles yourself:
## Create <code>Makefile.am</code> in the new directory (using as a template another <code>Makefile.am</code>).
## Set up <code>Makefile.am</code> to build a convenience libtool library (<code>noinst_LTLIBRARIES</code>) with an appropriate <code>lib*_la_SOURCES</code> listing the headers and sources in the directory.
## Add the new convenience library to the <code>*_LIBADD</code> in the parent directory.
## Create a <code>Makefile</code> in the new directory (using other source <code>Makefile</code>s as a template).
# Add the new <code>Makefile</code>s to SVN.
# You may need to re-run <code>autogen.sh</code> in the top-level source directory.

The <code>Makefile</code>'s sole purpose is to support typing "''make''" inside a source subdirectory. It needs to set up a few variables correctly and then include <code>Makefile.subdirs</code> from the top level. It looks like this: (but use a template from another source directory, it might be more up-to-date than this version)

topdir = ../..
srcdir = src/expr

include $(topdir)/Makefile.subdir

First, <code>topdir</code> is the relative path to the root of the source tree. <code>srcdir</code> is the relative path ''from'' the root to this directory. <code>builddir</code> should have the same definition for every subdirectory; it gives the full relative path to the associated build directory. The <code>include</code> line gets the standard rules for running ''make'' from a source subdirectory.

'''Note also''' that when you add a convenience library you need to add it also to the unit testing makefile in <code>test/unit/Makefile.am</code>. This is because the testing framework links directly against the convenience libraries to avoid the symbols that are ''hidden'' by the linker.

==Adding copyrighted sources==

The procedure for adding sources from other projects is a bit trickier. CVC4 incorporates source from others in a few different places:

* ''autogen.sh'', our auto-build-system-generation script
* doxygen macros for autoconf (under ''contrib/'')
* MiniSat (under ''src/prop/minisat'')
* ANTLR3 (some parts under ''src/parser'')

Naturally, we have other ''dependencies'' too, like on ''CxxTest'' and on ''libgmp'', but for these we don't need to copy source under our tree; we are simply a client of those tools.

Generally, the steps you should perform when you choose to copy copyrighted sources into CVC4's source tree are:

<ol>
<li>
'''Does this make sense?''' Incorporating source from others can be a headache. We have to exclude these sources from our copyright, and include their copyright notice in ours.
</li>

<li>
'''Identify legal implications.''' Is the license used by this software compatible with CVC4? Are we permitted to copy their sources? Are we permitted to modify them in any way? Are we permitted to re-distribute them?</li>
</li>

<li>
'''Create a vendor branch in the Subversion repository.''' Before copying into the CVC4 tree, create a vendor version of the software you're about to import:
<ul>
<li> Import a pristine version into the repository under ''<nowiki>https://subversive.cims.nyu.edu/cvc4/vendor/$PACKAGE/$VERSION_NUMBER</nowiki>''. </li>
<li> Copy to "current":<pre>svn copy https://subversive.cims.nyu.edu/cvc4/vendor/$PACKAGE/$VERSION_NUMBER https://subversive.cims.nyu.edu/cvc4/vendor/$PACKAGE/current</pre> </li>
<li> Now copy into the cvc4 source tree. You can "copy" into your current working directory with svn checkout, for example:<pre>svn checkout https://subversive.cims.nyu.edu/cvc4/vendor/$PACKAGE/current src/util/bar</pre> will copy your package under CVC4's src/util directory as "bar." '''It is important that you use svn to do this, so there's a record of the link between the vendor branch and the "bar" directory.'''</li>
</ul>
</li>

<li>
'''Importing another build system.''' If you're importing sources, you have to decide how to cleanly incorporate the imported project with CVC4. In most cases, for small imported projects, it's easiest to create a Makefile.am in their top-level that is just like our Makefile.am files, and compiles their entire project. But you may need to rely on their ''configure''/''make'' build system if the imported project is more complex, which means that in the future we may need to create [http://www.gnu.org/software/autoconf/manual/autoconf.html#Subdirectories configurable subprojects] (though it'd be nice to avoid that, if possible). Use your best judgment.
</li>

<li>
'''Adding a copyright exemption.''' You '''MUST''' edit the ''COPYING'' file at the top-level source directory for CVC4. I am not a lawyer, however, I would say that '''this is crucial'''. In ''COPYING'', indicate:
<ul>
<li> Where the copied sources are in the CVC4 tree. </li>
<li> What its copyright and (lack of) warranty is. Include all its legal information. </li>
</ul>
There are a lot of examples in ''COPYING'' already of this; use them as a template.
</li>

<li>
'''Exclude from auto-copyright.''' If you have imported headers or source files into the CVC4 tree, '''you must edit''' the ''contrib/update-copyright.pl'' script to make sure it doesn't automatically add CVC4's copyright to the top of the file the next time it's run. Add the full (relative) path to it under ''$excluded_paths'' (''$excluded_directories'' are names excluded at any level of the directory tree). If you don't know Perl-compatible regular expressions, ask someone.
</li>
</ol>

=Coding guidelines=

The following sections attempt to standardize C++ coding and organizational style for the CVC4 project.

Note that many of these standards apply to unit tests under <code>test/</code> as well, but many do not.

The guiding philosophy in the coding guidelines for CVC4 is to make the code readable and consistent throughout without getting in the way by being overly restrictive. Flexibility is afforded in edge cases where the developer should make his or her best effort to satisfy the guidelines, but not at the expense of making the code less readable or formatted poorly or insensibly.

==File and directory names==

* File names are all lowercase. Class ''FooSolver'' has its definition in <code>foo_solver.h</code> and its implementation in <code>foo_solver.cpp</code>.

* File extensions <code>.cpp</code> and <code>.h</code> are generally preferred, with <code>.ypp</code> and <code>.lpp</code> for yacc and lex inputs---an exception is made for headers when other tools have clashing preferences for generated sources; ''e.g.'', autotools wants to output parser definitions for the presentation language as <code>pl.hpp</code>.

==Preprocessor macros==

Preprocessor macros should be avoided when possible.

Preprocessor macro names are <code>ALWAYS_UPPERCASE</code>.

=== Binary macros ===

A binary macro is a symbol that has two states. There are two kinds of binary macros:

* A macro that is either "defined" or "undefined." These macros should have names that are nouns or noun phrases. The should not be defined to have a value—their definition should be empty. For example:
#define DEBUG
These macros can be tested using the <code>#ifdef</code> directive:
#ifdef DEBUG
/* ... */
#endif /* DEBUG */

* A macro that has one of the values 0 or 1. These macros should have names that are verbs or verb phrases. For example:
#define USE_MINISAT 1
These macros should be tested using <code>if</code> statements rather than preprocessor directives:
if(USE_MINISAT) {
/* do something with minisat */
} else {
/* some non-minisat default behavior */
}

=== Block macros ===

Macros that expand to multiple statements should use the <code>do { ... } while(0)</code>. For example, a macro <code>FOO</code> that generates the statements <code>S1; S2;</code> should be defined using
#define FOO do { S1; S2; } while(0)
(Note that there is ''no semicolon'' after <code>while(0)</code>.)

=== Miscellaneous ===

* Since macro parameters may be expressions with side effects, they should not be used multiple times in a definition.

* Remember these aren't hygienic macros! You can capture names:
#define ADD(c, a, b) { int x = a, y = b; c = x + y; }
int main() {
int x = 5;
// print out the value x + x ^ 2 (should be 30)
int z;
ADD(z, x, x * x);
printf("%d\n", z); // does NOT print 30 :-(
}
The usual way to combat this problem is to prefix the names in the macro with underscores:
#define ADD(c, a, b) { int __x = a, __y = b; c = x + y; }
Though it's best to use longer names and perhaps to mix in the name of the macro as well, to avoid any possible clash.

* Except when you're playing clever/stupid tricks with macro expansion, you should guard against unwitting order-of-operations surprises by parenthesizing arguments when expanded in macro bodies:
#define ADD(c, a, b) { int __add_x = (a), __add_y = (b); (c) = x + y; }
This approximates (in this case) macro-call-by-value.

* There is an exception to the <code>ALWAYS_UPPERCASE</code> rule for ''CVC4::Assert()'' and friends.

==Class names==

* Classes, and type names in general, are in CamelCase. There are exceptions to this rule, however, where lower case names with embedded underscores are acceptable:
** STL type names are not CamelCase, and when implementing traits and STL-like typedefs (''iterators'' for instance), you should match the STL style as closely as possible:
class Foo {
class Item;
typedef Item* iterator;
typedef const Item* const_iterator;
};
** for low-level ''exception'' types (similar to STL's <code>bad_alloc</code>). However, for derived classes of ''CVC4::Exception'', the names should be CamelCase.
** Low-level unions and structs may be in a similar lower case form, ''e.g.'', <code>low_level_struct</code>.
* Note that acronyms (SMT, CVC4) inside ''type'' names should generally be lowercase after the first letter, such as in ''CVC4::SmtEngine''. This is preferred to ''SMTEngine'' or ''SMT_Engine'', but use judgment on a case-by-case basis.

==Namespaces==

* Everything is in the ''CVC4'' namespace or a sub-namespace. Generally, the sub-namespace follows the module (and thus the source directory) structure. The name remains uncapitalized, and acronyms are all in lowercase letters (''e.g.'' ''CVC4::smt'', ''CVC4::main'', ''CVC4::parser''). However, certain base types go in ''CVC4'' directly ''instead'' of a sub-namespace despite belonging to a module. These are user-visible (such as ''CVC4::Exception''), core functionality classes, and utility classes from <code>src/util/</code>.

==Member names==

* Data members are prefixed with <code>d_</code>, and are generally in lowerCamelCase after that. For example:
class Foo {
int d_thisIsAnInt;
};
* Static members are prefixed with <code>s_</code>:
class Foo {
static int s_thisIsAStaticInt;
};
* Union elements are prefixed with <code>u_</code>.

* There is an exception to these rules for low-level ''struct'' types that have no member functions and no destructors (and only simple, initializing constructors). For an example see the definition of ''CVC4::Options'' in <code>src/util/options.h</code>.

==Class Organization==

Declarations of class members should be organized as follows.

* Members are declared in the following order:
:# Typedefs and friend declarations
:# Static members
:# Data members
:# Constructors and destructors
:# Methods

* <code>public</code>, <code>private</code>, and <code>protected</code> sections may come in any order. Alternation between sections should be minimized as much as possible.

==Communicating with the user: the output classes==

ALL OUTPUT through ''Debug'' and ''Trace'' and ''Notice'' and ''Warning'' functionality please! Very easy:
#include "util/output.h"
CVC4::Debug("arith", "foo!"); // prints "foo!" if arith debugging is on
CVC4::Warning("Equivalence classes didn't get merged."); // prints unless user gave -q or in SMT-COMP mode
CVC4::Notice("Hi, so you don't get bored, here are some statistics: " + stats); // if user gives -v
CVC4::Chat("I feel like doing some theory propagation.");// if user gives -vv
CVC4::Trace("arith", "<ralph>I'm now calling a function!</ralph>");// if user gives -vvv
''Chatting'' in particular should be useful for tuning/strategy things. Parts of the code that aren't conditional on particular settings in CVC4 should avoid ''Chat'' and use ''Trace'' or ''Debug''. Tracing is tagged with the module to which it's relevant. The above add a <code>\n</code> for you. If you don't want that, you can use a <code>printf()</code> interface:
CVC4::Debug::printf("arith", "foo!"); // no line termination
or the stream interface:
CVC4::Debug("arith") << "foo!"; // also no line termination
For non-debug builds, ''CVC4::Debug'' is a no-op and everything will be inlined away.

==Assertions==

CVC4 Assertions:
#include "util/assert.h"
CVC4::Assert(condition); // asserts condition is true
CVC4::Assert(condition, "error message on fail"); // asserts condition is true, custom error message
Note that Assert is a macro (in order to collect source line and file and expression-string information from the C preprocessor). A ''CVC4::AssertionException'' is thrown if it fails. When assertions are turned off, this is a no-op and everything is inlined away.

The above assertions can be turned off (with <code>--disable-assertions</code> at ''configure''-time). You might want to have an assertion be checked even if assertions are off. For example:
# ''Unreachable code.'' If you have a section of code that is intended to be unreachable (you have, perhaps, proved on paper that the code should never enter this state), it costs nothing to check the assertion (it's essentially an <code>assert(false)</code>---''always'' fail).
# ''Highly-compromised state.'' In cases where a wrong answer is unlikely and the assertion check is cheap and infrequently-run, you may consider leaving an assertion in. This is the case also with the above unreachable-code assertion.

For ''unreachable code'', use the <code>Unreachable()</code> macro. It will throw a ''CVC4::UnreachableCodeException'' (a subclass of ''CVC4::AssertionException''):
#include "util/assert.h"
CVC4::Unreachable(); // flags (supposedly) unreachable code; fails even under --disable-assertions
CVC4::Unreachable("error message"); // custom error message

Another special case is an ''unhandled case'' (for example, a ''default'' block in a switch that was designed to handle all cases). It will throw a ''CVC4::UnhandledCaseException'' (a subclass of ''CVC4::UnreachableCodeException''):
#include "util/assert.h"
CVC4::Unhandled(); // flags an unhandled case; fails even under --disable-assertions
CVC4::Unhandled(the_case); // same but prints out the_case that's unhandled as well (which should be whatever is in the switch)
CVC4::Unhandled("error message"); // custom error message
CVC4::Unhandled(the_case, "error message"); // custom error message with the_case that is unhandled

For a ''strong'' assertion that's checked even with <code>--disable-assertions</code>, use an <code>AlwaysAssert()</code>. It throws a ''CVC4::AssertionException'' just as <code>Assert()</code> does.
#include "util/assert.h"
CVC4::AlwaysAssert(condition);
CVC4::AlwaysAssert(condition, "error message");

==Doxygen comments==

==Exporting library symbols==

When built with a GNU toolchain, libcvc4 hides all symbols by default (with <code>-fvisibility-hidden</code>). This is a good way to ensure that the public interface is complete, that no undocumented interface is used by anyone, and it also permits more aggressive optimization of the library. Those symbols intended to be the public interface to CVC4, however, must be ''explicitly'' exported.

Fortunately, this isn't difficult. To use a symbol, a user should have a header file anyway. Only a subset of CVC4 headers are installed with <code>make install</code>, and these all live in <code>src/include/</code> and comprise the complete public interface. Public symbols are marked with <code>CVC4_PUBLIC</code>:

class CVC4_PUBLIC Expr {
/* ... */
public:
Expr();
};

Note here that ''types'' and ''private members'' need not be marked <code>CVC4_EXPORT</code>.

Now. What do you care? Well, if you ever forward-declare something that's public, you have to mark it PUBLIC in the forward-declaration too. (Is this true??)

Exception classes should all be marked CVC4_PUBLIC, because they might end up in user code (external to ''libcvc4'') and their ''type_info'' information must be available to the catch block in user code. If you don't think your exception can (nor should by design) exit the library and end up in user code, then first double-check this, then triple-check it, then document that fact clearly at call site, the catch site (inside the library), and at the exception class definition.

See http://gcc.gnu.org/wiki/Visibility for more information on visibility.

==Source file layout==

===Class header files===

* A class named <code>AdjectiveNoun</code> has its definition in <code>adjective_noun.h</code>. Each header file is guarded by a preprocessor macro to prevent duplicate declarations. For example, in <code>adjective_noun.h</code>:

#ifndef __CVC4__ADJECTIVE_NOUN_H
#define __CVC4__ADJECTIVE_NOUN_H

... declarations go here ...

#endif /* __CVC4__ADJECTIVE_NOUN_H */

Generally all <code>#include</code>s of other headers should go inside the <code>#ifndef</code> guard. There is an exception though (with an <code>#include</code> going above the guard) for circular dependencies and other special circumstances. Such things should be documented in the code. All <code>#include</code>s should generally go at the top of the file, however, for inlined and template implementations following a class definition, sometimes additional files should be included after the class definition but before these member function definitions (again, when breaking circular dependencies).

If the class <code>AdjectiveNoun</code> is in the <code>CVC4</code> namespace, the macro guard is named <code>__CVC4__ADJECTIVE_NOUN_H</code>. If it is in a sub-namespace <code>Foo</code>, then the macro guard is <code>__CVC4__FOO__ADJECTIVE_NOUN_H</code>. Note the ''two'' underscores for each <code>::</code> and the two prefix underscores. One underscore is used between words in a type or namespace name.
* Prefer forward-declaration of classes instead of <code>#include</code>'ing their header from another header, wherever this is possible.
* Public headers (in <code>src/include/</code>), use preprocessor macro guard <code>__CVC4_</code>''headername''<code>_H</code>, for example, <code>__CVC4_EXPR_H</code> for <code>cvc4_expr.h</code>. Note here the ''one'' underscore between ''CVC4'' and the name.
* Other (non-class) header files should use a similar preprocessor macro guard, based on relevant module and header file name, as class header files do. In all cases, prefix the name of the guard with <code>__CVC4_</code> and design it to be unlikely that it will ever conflict with any other (future) CVC4 header, whether it might be for internal use only or externally provided to a library user.
* Everything should be in the ''CVC4'' namespace, or a sub-namespace of ''CVC4'' (based on module).
* '''For test classes.''' [[#Unit testing|Unit test classes (under <code>test/unit/</code>)]] are implemented as header files and do not need to be in a namespace, nor guarded by a preprocessor macro. The idea is to keep them as simple and ''clean'' as possible, so the tests can be easily read. They are special-purpose and compiled and linked individually, so they don't need these protections.

===Class implementation files===

* A class named ''ThisIsAClass'' should have its implementation under <code>src/</code> in <code>this_is_a_class.cpp</code> in the relevant module directory.

===Imported sources===

* '''For imported sources.''' Make sure to add an exclusion to the <code>contrib/update-copyright.pl</code> script so that a CVC4 copyright isn't added when the script is run.

==Source file headers==

* A common comment blurb heads all sources in CVC4 (including lex and yacc inputs and unit tests, but excluding imported sources).
* A script, <code>update-copyright.pl</code> is used to maintain/update this comment blurb.

===update-copyright.pl===

* You can run <code>contrib/update-copyright.pl</code> to update ''all'' sources with a new copyright template. (Some) efforts are made to throw away old boilerplate comment blurbs while keeping file-specific comments.
* '''PLEASE BE CAREFUL.''' This updates files in place without keeping a backup. ''The script is probably buggy. You have been warned.'' It's best to do this on a copy of your source tree, or on a fresh repository checkout. (The program will warn you too.)
* Please consult <code>svn diff</code> before committing changes made by the script.
* You can run the update script on specific files/directories by providing arguments to the script. By default it processes all sources in the <code>src/</code> and <code>test/</code> directories.

==Using emacs==

* There's an emacs-lisp snippet available that you can drop in your <code>~/.emacs</code> to conform to spacing, indentation, etc., in the CVC4 source tree.
* See <code>contrib/editing-with-emacs</code>.

==Textual source layout==

===Whitespace/tabs===

* No tabs, please.
* No whitespace between '''if''', '''for''', '''while''', ''''catch'''', etc., and their opening parenthesis.
* One space between closing paren and open curly brace (except if aligning to other nearby source lines).
** The matching right curly brace goes on a line by itself (possibly with an end-comment tagging the construct it's part of) in the same column as the first letter of the construct keyword. (That is, the right-brace lines up with the '''if''', '''for''', etc.)
* One space around binary operators to avoid crowding, ''e.g.'':
x = y;
z = y + 1;
* In complicated arithmetic expressions, even when parentheses aren't required by operator order of evaluation, sometimes parentheses and extra spacing and alignment should be used for ''visual'' clarity, or to match more closely what is being implemented, what is described in associated source code comments, or both. For example:
if( ( ( x1 + y1 ) - ( z * 2 ) ) <= 4 ||
( ( x2 + y2 ) - ( zp * 2 ) ) >= -4 ) { ... }
* Occasionally to emphasize a !, so it doesn't get visually lost, it's best followed or even surrounded by space. For example, this is bad:
if(!(x + y > 4 && z < x)) ...
* while this is much preferred, since it emphasizes the negation of the entire condition:
if( !( x + y > 4 && z < x ) ) { ... }
* (assuming that it's preferable '''not''' to rewrite this as x + y <= 4 for some other reason of course).
* Between type names and <code>*/&</code> when declaring members and variables, to emphasize the ''introduced name'' is a pointer:
Foo *a, *b;
* ''NOT'' between type names and <code>*/&</code> when in an argument list or return type, to emphasize that the ''type'' is a pointer:
Bar* fooToBar(Foo* f);
* There is an exception for array types. Since <code>char *argv[]</code> is actually an array of pointers, it doesn't make sense to attach <code>*</code> to the type in this case (in C/C++, the <code>[]</code> must come after the formal name and can't be attached to the type name, as it can be in Java). In particular:
int main(int argc, char *argv[]);
is how the signature for the ''main'' function is written.
* No trailing spaces please. ''M-x delete-trailing-whitespace'' in emacs might help.

===Increment/Decrement===

* Preincrement/decrement preferred over postincrement/-decrement, ''e.g.'':
for(int x = 0; x < 10; ++x) { ... }

===Bracing===

* Braces are not required around one-line blocks, but preferred in complicated cases, especially with if (to avoid visually-ambiguous '''else'''s).
** ''E.g.'' this is fine:
if(extra_output)
do_something();
** But this is debatable (preferring braces on the <code>if()</code> but not the <code>for():</code>
if(extra_output)
for(int i = 0; i < 10; ++i)
do_something();
** And this is horrible:
if(extra_output)
do_something_simple();
else
while(!done)
for(int i = 0; i < 10; ++i)
if(a[i] < 5)
a[i + 10] += a[i];

* Generally, if the ''then'' part of an '''if''' is complicated and braced, but the ''else'' part is simple, the else need not be braced but may be. But if the '''else''' part is complicated and braced then the '''then''' part should be (even if it's simple).
* If in doubt, brace.
* If anything is visually ambiguous, brace for clarity.

===Indentation===

* Indentation level is 2.
* No indentation under ''switch() {}'' or ''namespace {}''
** An exception is forward-declarations inside namespaces, where you ''do'' indent. For instance, from <code>src/include/cvc4_expr.h</code>:
namespace CVC4 {

namespace expr {
class ExprValue;
}/* CVC4::expr namespace */

class Expr {
/* ... */
}/* class Expr */

}/* CVC4 namespace */
* Goto labels, case labels, and "private/public/protected" are recessed 2.
* <code>template <class T></code> generally belongs on its own line before a function declaration or definition. An exception is inside a class file where there's a long string of simple functions that are best not separated by vertical space.
* If something is templated in this way, the entire construct must be vertically separated from its surroundings with blank lines, and the <code>template <></code> specification is on its own line.
* Attempt to keep lines under 80 columns wide. Though if this makes things excessively ugly or confusing, it's probably ok to go over 80.
* Indentation level is 2 for preprocessor directives as well, but the leading # is ''always'' in the first column. For example:
#if A
# if B
# warning A B case
# else /* ! B */
# warning A -B case
# endif /* B */
#else /* ! B */
# if B
# warning -A B case
# else /* ! B */
# warning -A -B case
# endif /* B */
#endif /* A */

==Misc C++==

* int foo(void) -- (void) unnecessary
* An array reference <code>a[i]</code> in C++ may also be reversed as <code>i[a]</code>, due to a symmetric definition of <code>operator[]</code> when applied to array and integral types in C. In CVC4, array indexing should be done in the standard way.
* never use "using" in header files
* enums require operator<<

==Intentionally not covered==

* 0 vs NULL

=Use of autotools: automake, autoconf, autoheader, libtool=

* Please don't check into the repository things generated by automake, autoconf, or autoheader, for example: <code>config.h.in</code>, <code>Makefile.in</code>s, <code>Makefile</code>s, <code>ylwrap</code>/<code>libtool</code>/<code>aclocal.m4</code>/<code>missing</code>/<code>config.guess</code>, <code>configure</code>, etc.

=Commit policy=

* Before you commit, everything should be documented and your code should conform to the coding guidelines.
* An automated bot will review code commits and complain loudly to you if it doesn't like your documentation or coding style.
* Clark will review all code commits for content.
* Others in the group will review Clark's commits for content.
* Unit tests should be included to test any new functionality included in your commit. These tests should pass the ''gcov'' coverage assessment for CVC4.

=Unit tests with CxxTest=

There are two unit tests for modules:
* those written by the main author of the module/piece of functionality (white-box)
* those written by another group member to test the exported interface of the module (black-box)

==Coverage testing with gcov==

Every ''non-exceptional'' line of code should be tickled by a unit test. To generate code coverage information, configure CVC4 with <code>--enable-coverage</code>, recompile the project, then run <code>make check</code>.

The code coverage information for a single file <code>SRC_PATH/foo.cpp</code> (and its <code>#include</code>'d dependencies) can be obtained by executing:
gcov -o builds/ARCH/BUILD_ID/SRC_PATH SRC_PATH/foo.cpp
''If you have multiple builds configured simultaneously, remember to use the correct BUILD_ID! It will have '''coverage''' in its name, something like '''debug-coverage''' or '''production-coverage'''.''
This will print out the percentage coverage of each processed file and create a set of <code>.gcov</code> files in the current directory. The <code>.gcov</code> files reproduce the source code with execution counts. More information about <code>gcov</code> usage is available from [http://gcc.gnu.org/onlinedocs/gcc/Gcov.html the online manual].

You can use the [http://ltp.sourceforge.net/coverage/lcov.php <code>lcov</code>] tool to produce a more global, browseable coverage report. (<code>lcov</code> is installable via ''APT'' and the package includes both ''lcov'' and ''genhtml'', used below). Simply run <code>make lcov</code>.

If that doesn't work for some reason, you can try running <code>lcov</code> manually. After running <code>make check</code> with a coverage-enabled build, execute:
mkdir -p HTML_DIR
lcov --directory builds/ARCH/BUILD_ID/ --capture --output-file HTML_DIR/cvc4-gcov.info
cd HTML_DIR
genhtml cvc4-gcov.info
Open <code>HTML_DIR/index.html</code> to start browsing.

=Other coding guidelines (as yet uncategorized)=

* No <code>using</code> or <code>using namespace</code> in header files, please!
* All exceptions thrown by CVC4 should be types publicly derived from ''CVC4::Exception'', unless the exception is very low-level (similar to <code>std::bad_alloc</code>) and there's a compelling reason to avoid the CVC4 infrastructure (this is true, for instance, for non-exceptional signals that are thrown internally by CVC4 and never escape the library; it's preferable to avoid memory allocation in this case).
* Traditionally long declaration blocks (classes, namespaces, #endifs) should have an associated comment, ''even when they are short:''
namespace CVC4 {
class Foo {
/* pages
* and
* pages
* go
* by
*/
};/* class Foo */
}/* CVC4 namespace */
Others ('''if''', '''while''', '''switch''', function definitions, etc.) should be close-commented for clarity where necessary. No space exists between the last token of the declaration or definition and the start of the close-comment.

Always end with a comment that matches the declaration ("struct Foo", "class Foo", "enum Foo"), except for namespaces, where it's the "Foo namespace." Comment preprocessor macros similarly:
#ifdef SOMETHING
# ifdef OTHERTHING
# error You can't do that.
# else /* !OTHERTHING */
# warning This is experimental code.
# define FOO(x) x
# endif /* OTHERTHING */
#else /* SOMETHING */
# define FOO(x)
#endif /* SOMETHING */
Note that the indentation level for preprocessor macros is 2, but that the leading # is always in the first column, and that the #else takes the '''negation''' of the condition as a comment (but #endif takes the non-negated one). Here, note that the else-comment and close-comment is preceded by a single space. In cases where these blocks are long and you want to include additional context information about what macros are true, please do:
#ifdef SOMETHING
/* lots of
* code here
*/
#else /* !SOMETHING */
/* lots of
* code here
*/
# ifdef OTHERTHING /* && !SOMETHING */
/* code... */
# endif
#endif
* Code and preprocessor indentation levels need not match unless it makes sense for them to.
* ALWAYS COMMENT FALL-THROUGH CASES IN ''switch() {}'':
switch(foo) {
case THIS_ONE:
printf("this!\n");
/* fall through */
case THAT_ONE:
printf("that!\n");
}

==Vertical spacing==

Vertical spacing depends on context. Logically group statements. Debugging bits should generally be offset from the rest of the code by blank lines. ''switch() {}'' blocks should generally leave a space between a case label and the preceding break.

=Code reviews=

[[Image:Code_review_lifecycle.png|400px|thumb|The typical code review lifecycle.]]

A code review ticket is opened in Bugzilla with importance "review". The scope of the review is indicated in the comments.

If you are assigned a code review, here is a guide to the life cycle for your review ticket:

<ol><li> '''Familiarize yourself with the code in the assigned module (and possibly other, related modules).'''
<ol><li> If something simple is unclear, ask the developer in person or via email. </li>
<li> If something less-than-simple is unclear, please ask the developer publicly on the ticket, so the discussion is tracked and better documentation can be produced as part of the code review.</li>
<li> If something less-than-simple is unclear and has larger, team-level consequences, ask the developer publicly on the developers' mailing list and/or raise it at a developers' meeting.</li></ol></li>

<li> '''Review the code of the assigned module.'''
<ol><li> Simple code formatting, typos, etc., should be directly fixed and committed by the reviewer.</li>
<li> Slightly larger issues (refactoring, renaming of critical variables, methods, etc.), even when it's to bring the code in line with coding guidelines, can be directly committed but should be communicated to the developer of the code and noted on the Subversion revision log and the code review bug ticket.</li>
<li> Larger, architectural changes to the module should be worked on WITH the developer, not solely by the code reviewer.</li>
<li> If, during the course of review, additional changes are indicated to modules ''other'' than the one formally under review, those should be opened as an additional review/bug ticket, or mentioned to the developer of those modules for correction.</li>
<li> In general, ''please avoid having "discussions" with the developer in comments in the source code.''</ol></li>

<li> '''Bugs, requests for documentation, etc., should be filed as ''separate'' bug tickets in bugzilla, with the module's original developer as the assignee.'''
<ol><li> Simple things (questions, or requests to "document this please," etc.) can be included as part of the review ticket. As the reviewer, post your questions and requests, and re-assign the ticket to the developer. When the developer answers and addresses the issue, the developer should re-assign the ticket to the reviewer.</li>
<li> More complex things (separate these two modules, provide documentation of invariants to this class, re-architect this to be in line with this other thing, etc.) should be opened as tickets, one per request, separate from the review ticket. These new tickets are assigned the developer. The review ticket itself does not get re-assigned to the developer unless there are (simpler-to-address) questions and requests on the review ticket.</li></ol></li>

<li> ''' ''Black-box'' and ''Public'' tests should be written by the reviewer for the general contract of the class.'''
<ul><li> If the reviewer chooses, the reviewer may write some white-box tests also, to assert internal state of the class is what the reviewer expects.</li></ul></li>

<li> '''Ensure the code in the module is ''sufficiently'' covered by tests.'''
<ul><li> For guidance on what is ''sufficient,'' please review the output of ''gcov'' and apply common sense, as informed by experience. All methods should be called and at least partly covered. If important methods aren't covered, certainly they should be. It's probably okay if some branches of exceptional paths are not covered. Some paths are difficult to cover in a black-box or regression test and may need to be triggered in a white-box test.</li></ul></li>

<li> '''In the documentation at the top of all relevant file(s), mark yourself as the reviewer.'''
<ul><li>If there are other reviews listed, put yours at the end of the list (so they remain in chronological order).</li>
<li>List your name, the date, and the code review ticket number.</li>
<li>For example:
<div style="white-space:pre;font-size:larger;">
/********************* */
/** ecdata.cpp
** Original author: taking
** Major contributors: mdeters
** Minor contributors (to current version): none
** This file is part of the CVC4 prototype.
** Copyright (c) 2009, 2010 The Analysis of Computer Systems Group (ACSys)
** Courant Institute of Mathematical Sciences
** New York University
** See the file COPYING in the top-level source directory for licensing
** information.
**
** Implementation of equivalence class data for UF theory. This is a
** context-dependent object.
**
** <span style="color:#a00;">Reviewed by dejan, Feb 24 2010 (bug #10).</span>
** <span style="color:#a00;">Reviewed by mdeters, Apr 4 2010 (bug #64).</span>
**/
</div>
</li></ul></li>

<li> '''The ticket can be closed when:'''
<ul><li> tests cover the code sufficiently, '''and''' </li>
<li> the simple requests in the review ticket itself have been addressed, '''and''' </li>
<li> bugs have been opened to address more complex requests. </li></ul>
The more complex requests need not be addressed to close the review ticket; it is enough that they have been identified and entered into Bugzilla.</li>
</ol>

=Binary compatibility: what is it and why do we care?=

*http://sources.redhat.com/autobook/autobook/autobook_91.html
*http://www.linux.org/docs/ldp/howto/Program-Library-HOWTO/shared-libraries.html
*http://ispras.linux-foundation.org/index.php/ABI_compliance_checker_Downloads
*http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html

=Unit testing=

First, get CxxTest from here:

http://cxxtest.tigris.org/files/documents/6421/43281/cxxtest-3.10.1.tar.gz

Unpack it in, say, your home directory. Then, just point CVC4's configure to it:

./configure --with-cxxtest-dir=~/cxxtest

Now, <code>make check</code> will run the CxxTest unit tests under <code>test/</code>.

==Running unit tests==

The simplest way to run all unit tests (and regressions and system tests) is to run <code>make check</code> in the top-level source directory. If you specifically want to run units and not other kinds of tests, <code>make check</code> in just the unit tests directory:

$ make -C test/unit check

There is also experimental support for running unit tests related to a specific package. If you specifically want to run units for the expr package, for example, <code>make check</code> ''in the source directory for expr'' (not in the test directory):

$ make -C src/expr check

==Types of unit tests==

There are three kinds of unit tests:

* '''white tests''' test the system from a '''white-box''' point of view: they have access to the private functionality of classes (that is, usual C++ access restrictions '''do not''' apply), and they are written (typically by the author of the tested class) to test the internal functions and invariants of a class implementation. If the implementation details of a class change, one or more tests will likely change too.
**By convention, white tests are named <code>*_white.h</code>. For example, for the '''Node''' class, which is in the '''CVC4::expr''' namespace, the test is under the <code>expr/</code> directory in <code>node_white.h</code>.
* '''black tests''' test the system from a '''black-box''' point of view: they have access only to the public functionality of classes (that is, usual C++ access restrictions '''do''' apply), and they are written (typically ''not'' by the author of the tested class) to test the external interface and invariants of a class. If the implementation details of a class change, the tests do not change; if the external interface of a class change, the test should be updated.
**By convention, black tests are named <code>*_black.h</code>. For example, for the '''Node''' class, which is in the '''CVC4::expr''' namespace, the test is under the <code>expr/</code> directory in <code>node_black.h</code>.
**a subcategory of black tests are '''public''' tests; these test the system from a '''public''' point of view: they have access only to the public, functionality of '''libraries'''---the exported symbols of various libraries. Usual C++ access restrictions apply, as do the usual linking procedures against the library. Essentially, these '''public''' tests are black tests that test the public functionality of a public class. It is useful to separate them from the black tests in order to test that the exported symbols of a library are adequate. Public tests are named <code>*_public.h</code>.

==Adding unit tests==

To add a new test, create a test header file under <code>test/unit</code> (possibly in a subdirectory based on the relevant CVC4 module). If your test is a ''white-box test'' (it calls private functionality of the tested class directly and was written knowing the implementation details), its name should include ''White'', ''e.g.,'' ''NodeWhite'', and it should be in a file like <code>test/unit/expr/node_white.h</code>, and you should add it to <code>TESTS_WHITE</code> in <code>test/unit/Makefile.am</code>. If your test is a ''black-box test'' (it calls only the public functionality of the tested class and was written knowing the interface only), its name should include ''Black'', ''e.g.,'' ''NodeBlack'', and it should be in a file like <code>test/unit/expr/node_black.h</code>, and you should add it to <code>TESTS_BLACK</code> in <code>test/unit/Makefile.am</code>. If your test is a ''public test'' (it calls only the public functionality of the tested class, which is exported in the public-facing interface of the library), its name should include ''Public'', ''e.g.,'' ''ExprPublic'', and it should be in a file like <code>test/unit/expr/expr_public.h</code>, and you should add it to <code>TESTS_PUBLIC</code> in <code>test/unit/Makefile.am</code>.

If you add your test to the correct <code>TESTS_*</code> block in <code>test/unit/Makefile.am</code>, and you're using the GNU C++ compiler, it will be compiled and linked correctly: that is, if it's a '''white-box test,''' the compiler will ignore access restrictions; if it's a '''black-box test,''' it can still access hidden symbols; and if it's a '''public test,''' it must only access the public-facing, exported symbols of the appropriate library.

==Test implementations==

Your test methods are named <code>test*</code>, ''e.g.,'' <code>testNull()</code>. They return <code>void</code> and take no arguments.

There are numerous testing assertions you can make inside your testing code. For example:

TS_ASSERT( 1 + 1 > 1 );
TS_ASSERT_EQUALS( 1 + 1, 2 );

There's also a <code>TS_FAIL()</code> that fails unconditionally:

void testSomething() {
TS_FAIL( "I don't know how to test this!" );
}

...and a <code>TS_WARN()</code>:

void testSomething() {
TS_WARN( "TODO: This test still needs to be written!" );
}

[http://cxxtest.sourceforge.net/guide.html The users' guide is here for your reference.]

==Debugging unit tests==

In order to run, CxxTest takes a header file, generates from that a new cpp file, and then then compiles the cpp file into a binary.
The binaries for the unit tests live in the builds directory.
If a unit test had the path
cvc4/test/unit/foo/bar.h
then the binary will have the path <code>cvc4/builds/test/unit/foo/bar</code>. (The CxxTest cpp file will have the path <code>cvc4/builds/test/unit/foo/bar.cpp</code>.)

If you have compiled cvc4 in debug mode, then the unit tests binaries can be run in gdb.

Tests are executed in the order that they appear in the header file.
Moving a broken test to the top of the class definition (temporarily) makes it execute before the other tests. This is a useful trick for making debugging with gdb easier.

To recompile all of the tests, you can run <code>make check</code> in <code>cvc4/</code>. If you just run <code>make</code> after changing the source of cvc4 or a unit test, the test will not be recompiled.

===Compile-time errors in unit tests===

The most common errors with unit tests are duplicating method names, improper copy-'n'-paste between tests, etc.

If you get strange errors, make sure you called your test class something unique (''e.g.,'' "ExprBlack" for black-box tests on ''Expr''). If you get an error that looks like this:

expr/expr_black.cpp:20: error: expected initializer before ‘suite_ExprBlack’
expr/expr_black.cpp:23: error: ‘suite_ExprBlack’ was not declared in this scope
expr/expr_black.cpp: In member function ‘virtual void TestDescription_ExprBlack_testDefaultCtor::runTest()’:
expr/expr_black.cpp:28: error: ‘suite_ExprBlack’ was not declared in this scope
expr/expr_black.cpp: In member function ‘virtual void TestDescription_ExprBlack_testCtors::runTest()’:
expr/expr_black.cpp:34: error: ‘suite_ExprBlack’ was not declared in this scope
...etc...

...then you're missing a closing semicolon at the end of your test class definition. (They're easy to forget.)

==Test rebuilding==

{{BUG|44}} states:

<blockquote>
As our unit-test database is growing the time to compile all the tests is
getting increasingly unbearable, specially as every change in the source spawns
recompilation of all tests. I know it might be impossible, but I would be
wonderful if we could get around this somehow.
</blockquote>

Previously, in response to {{bug|13}}, entitied ''Test not rebuilding on code
changes,'' the behavior was fixed precisely to force test rebuilding

Fortunately, the answer is yes, this rebuilding can be avoided.

But it must be stressed that before any commit, '''you should always let the
build tree rebuild, relink, and rerun all tests!'''

===Partial testing===

First, the preferred method involves ''partial rebuilding:'' you
can run subsets of unit tests (rebuilding only those necessary for the
subset). Say you have an up-to-date build tree (including all
unit tests). You make a small change to <code>src/theory/theory.h</code> and
want to rerun ''just'' the theory tests. Run ''make'' to rebuild the
libraries, then:

$ make -C src/theory check

By the way, -C isn't anything magical, it just chdir's into <code>src/theory</code>
first. So the same results from:

$ (cd src/theory && make check)

With the current build tree (that is, March 4, 2010), this will rebuild ''only'' the <code>theory_black</code>
and <code>theory_uf_white</code> tests and then run them. When we have more
theory-related unit tests, it will include those too.

===Marking the test tree up-to-date (not preferred)===

''If'' you are using dynamic linking (<code>--enable-shared</code>, which is the default), and
you make a change to <code>libcvc4</code> or <code>libcvc4parser</code> that shouldn't require
a rebuild of test binaries---a small change to a non-inlined function,
for example---you can use:

$ make
[ libraries are rebuilt ]
$ make -t check
[the tests are marked up-to-date even though they aren't]
$ make check
[the tests are run]

You cannot combine these three steps. Providing "-t" to ''make'' won't do any rebuilding, which you need in the first and third invocations.

If you change interface, data layout, or inline-able function
implementations, you'll run into problems and the tests should be
rebuilt, so use good judgment and '''always rebuild, relink, and rerun
all unit tests before a commit!'''

Also, if you use this "<code>make -t check</code>" method, your build tree may
become out-of-sync with itself. If you see strange behavior
(unexpected segfaults, weird debugger behavior, etc.), rebuild and
relink all tests.

=Regression testing=

''Regression tests'' in CVC4 are tests of the CVC4 binary.

To add a regression test, drop the file (which should have extension ''.smt'' or ''.cvc'' in <code>test/regress/regress''N''/</code> (for ''N'' the regression level it should be in) and add it under <code>TESTS</code> to <code>test/regress/regress''N''/Makefile.am</code>. Then add it to subversion:

$ svn add test/regress/my_test.cvc

In the case of a <code>.cvc</code> benchmark, add one or more <code>% EXPECT: ''output''</code> lines in the file (either at the top or scattered throughout). This is the expected output of CVC4 (running without -q or -v or debugging or anything). '''Any''' differences in output from the expected are flagged as test errors. See other <code>.cvc</code> regression tests for examples. If there are no ''EXPECT'' lines, the ''run_regression'' script flags an error. An ''EXIT'' line indicates the expected exit code of CVC4, but is optional; if omitted, CVC4 may have any exit status.

In the case of an <code>.smt</code> benchmark, make sure it has '':status sat'' or '':status unsat''. This is used to determine if the output is correct and if CVC4 exits with the correct exit code.

This should be all that's necessary. Before committing to the repository, you should re-run ''autogen.sh'' in the root directory so that your commit includes the newest <code>Makefile.in</code>.

==Multi-level regression testing==

The directories
* <code>test/regress/regress0</code>
* <code>test/regress/regress1</code>
* <code>test/regress/regress2</code>
* <code>test/regress/regress3</code>
contain benchmarks at different regression levels. More difficult or longer-running benchmarks are typically placed in higher regression levels.

A simple ''make check'' at the top-level source directory (or top-level build or test source or build directories) does regression testing at level 0. For a specific level, use ''make regressN:'' this runs all tests at levels less than or equal to ''N''. (At the top-level, the ''regressN'' target implies the ''check'' target, so you can ''make regress3'' to run all unit tests, system tests, '''and also''' regressions at all levels.)

To run a specific level of regressions, ''e.g.,'' regressions at level 2, without running regressions at lower levels, run a ''make check'' inside that specific directory. For example:

$ make -C test/regress/regress2 check

==Running the full regression suite on the cluster==

Experimental CVC4 binarys can be submitted to the cluster for a full run of the regression suite [http://goedel.cims.nyu.edu/regress-results/submit_cvc4.html here]. The test daemon will send you an email with a link to the results when the jobs is finished running.

=System testing=

''System,'' or ''API,'' testing is a form of regression testing on CVC4 libraries rather than the driver. Rather than .cvc and .smt instances as input, a system test is a source file that is built and linked against the cvc4 libraries and uses its API, bypassing the usual CVC4 driver. These tests are located under <code>test/system/</code>.

'''FIXME expand this section.'''

=Command-line options=

To add a new command-line option to CVC4, open up <code>src/main/getopt.cpp</code>. Add an entry to the <code>cmdlineOptions</code> array:

* the first item is the ''long'' name of the command-line option. For example, ''verbose'' for <code>--verbose</code>.
* the second item is <code>required_argument</code>, <code>optional_argument</code>, or <code>no_argument</code>, depending on whether the option takes an argument, an optional argument, or does not take an argument.
* the third item should be NULL.
* the last item should be the equivalent short option (a <code>char</code>), or a member of the <code>OptionValue</code> enumeration if there isn't an equivalent short option.

Next, if you don't have an equivalent short option, add the appropriate item to the <code>OptionValue</code> enumeration. If you '''do''' have an equivalent short option, append the short option to the string passed to <code>getopt_long()</code> in <code>parseOptions()</code>. Your option character should be followed by a single colon if an argument is required, or two colons if an argument is optional.

Next, modify the ''switch()'' construct in <code>parseOptions()</code> to handle your short option character (or the value from the <code>OptionValue</code> enumeration). If you need a new field in the <code>CVC4::Options</code> structure, add it in <code>src/util/options.h</code>.

Finally, change the usage string in <code>src/main/usage.h</code>.

=NodeBuilders=

'''FIXME'''. ADD CONTENT.

=Attributes=

What does this mean?

<pre>
/home/mdeters/cvc4/builds/x86_64-unknown-linux-gnu/debug/../../../src/expr/attribute.h: In member function �$-1òøvoid CVC4::expr::AttributeManager::setAttribute(const CVC4::Node&, const AttrKind&, const typename AttrKind::value_type&) [with AttrKind = TestFlag6]òù:
/home/mdeters/cvc4/builds/x86_64-unknown-linux-gnu/debug/../../../src/expr/node_manager.h:128: instantiated from �$-1òøvoid CVC4::NodeManager::setAttribute(const CVC4::Node&, const AttrKind&, const typename AttrKind::value_type&) [with AttrKind = TestFlag6]òù
/home/mdeters/cvc4/builds/x86_64-unknown-linux-gnu/debug/../../../src/expr/node.h:291: instantiated from �$-1òøvoid CVC4::Node::setAttribute(const AttrKind&, const typename AttrKind::value_type&) [with AttrKind = TestFlag6]òù
/home/mdeters/cvc4/builds/x86_64-unknown-linux-gnu/debug/../../../test/unit/expr/node_white.h:113: instantiated from here
/home/mdeters/cvc4/builds/x86_64-unknown-linux-gnu/debug/../../../src/expr/attribute.h:753: error: invalid use of undefined type �$-1òøstruct CVC4::expr::getTable<FooBar>òù
/home/mdeters/cvc4/builds/x86_64-unknown-linux-gnu/debug/../../../src/expr/attribute.h:508: error: declaration of �$-1òøstruct CVC4::expr::getTable<FooBar>òù
/home/mdeters/cvc4/builds/x86_64-unknown-linux-gnu/debug/../../../src/expr/attribute.h:755: error: invalid use of undefined type �$-1òøstruct CVC4::expr::getTable<FooBar>òù
/home/mdeters/cvc4/builds/x86_64-unknown-linux-gnu/debug/../../../src/expr/attribute.h:508: error: declaration of �$-1òøstruct CVC4::expr::getTable<FooBar>òù
/home/mdeters/cvc4/builds/x86_64-unknown-linux-gnu/debug/../../../src/expr/node_manager.h:128: instantiated from �$-1òøvoid CVC4::NodeManager::setAttribute(const CVC4::Node&, const AttrKind&, const typename AttrKind::value_type&) [with AttrKind = TestFlag6]òù
/home/mdeters/cvc4/builds/x86_64-unknown-linux-gnu/debug/../../../src/expr/node.h:291: instantiated from �$-1òøvoid CVC4::Node::setAttribute(const AttrKind&, const typename AttrKind::value_type&) [with AttrKind = TestFlag6]òù
/home/mdeters/cvc4/builds/x86_64-unknown-linux-gnu/debug/../../../test/unit/expr/node_white.h:113: instantiated from here
/home/mdeters/cvc4/builds/x86_64-unknown-linux-gnu/debug/../../../src/expr/attribute.h:755: error: invalid use of undefined type �$-1òøstruct CVC4::expr::getTable<FooBar>òù
/home/mdeters/cvc4/builds/x86_64-unknown-linux-gnu/debug/../../../src/expr/attribute.h:508: error: declaration of �$-1òøstruct CVC4::expr::getTable<FooBar>òù
make[5]: *** [expr/node_white] Error 1
</pre>

It means that the Attribute value-type (in this case ''FooBar''), is invalid; there's no hashtable of appropriate kind to put it in. You probably want FooBar*.

=ANTLR3=

To get ANTLR3, which isn't yet distributed as a Debian/Ubuntu package:

<ol>
<li>Go to the ANTLR3 page and download Complete ANTLR 3.2 jar; all tools, runtime, etc... <http://antlr.org/download/antlr-3.2.jar> to <code>$ANTLR3_JAR</code>.</li>
<li>Save the following as <code>$ANTLR3_DIR/antlr3</code> (and make sure the file is executable), substituting the correct fully-qualified path for "<code>$ANTLR3_JAR</code>":
<pre>
#!/bin/sh

export CLASSPATH=/usr/share/java/stringtemplate.jar:$ANTLR3_JAR
exec java org.antlr.Tool "$@"
</pre></li>
<li>Download "libantlr3c-3.2.tar.gz" from http://antlr.org/download/C and extract the archive to <code>LIBANTLR3C_SRC_DIR</code>.</li>
<li>Enter <code>$LIBANTLR3C_SRC_DIR</code>.</li>
<li>If you are on a 32-bit machine, run
<pre>
./configure --prefix=$LIBANTLR3C_INSTALL_DIR
</pre>
If you are on a 64 bit machine, run
<pre>
./configure --prefix=$LIBANTLR3C_INSTALL_DIR --enable-64bit
</pre>
<code>--prefix=PREFIX</code> specifies the library installation directory. This defaults to <code>/usr/local</code>.</li>
<li> Open up the Makefile that's generated at the top-level source directory and add <code>-fexceptions</code> to the CFLAGS setting. </li>
<li> Run
<pre>
make
make install
</pre>
or
<pre>
sudo make install
</pre></li>
<li> Note the following installation information for <code>libantlr3c</code> (where <code>LIBDIR</code> is <code>$LIBANTLR3C_INSTALL_DIR</code>):
<pre>
If you ever happen to want to link against installed libraries
in a given directory, LIBDIR, you must either use libtool, and
specify the full pathname of the library, or use the `-LLIBDIR'
flag during linking and do at least one of the following:
- add LIBDIR to the `LD_LIBRARY_PATH' environment variable
during execution
- add LIBDIR to the `LD_RUN_PATH' environment variable
during linking
- use the `-Wl,--rpath -Wl,LIBDIR' linker flag
- have your system administrator add LIBDIR to `/etc/ld.so.conf'
</pre>
</li>
<li> <code>cd</code> to the CVC4 source tree. </li>
<li>Now run
<pre>
./configure --with-antlr-dir=$LIBANTLR3_INSTALL_DIR ANTLR=$ANTLR3_DIR/antlr3"
</pre>
</li>
</ol>

== Profiling the code ==

To profile CVC4, configure with <code>--enable-profiling</code>. Unfortunately, GProf can't instrument system calls, so it will give misleading results for allocation-heavy programs like CVC4. Instead, you can use the Callgrind tool (a component of Valgrind):
valgrind --tool=callgrind --dump-every-bb=100000000 ''<executable> <arguments...>''
(The <code>--dump-every-bb</code> argument causes Callgrind to produce incremental data periodically throughout the execution. A value of 100,000,000 or higher is recommended to keep the number of data files emitted manageable.) Callgrind will create a master file <code>callgrind.out.''<pid>''</code> and a number of incremental data files (<code>callgrind.out.''<pid>''.1</code>, <code>callgrind.out.''<pid>''.2</code>, etc). Open <code>callgrind.out.''<pid>''</code> using the KCachegrind GUI tool to visualize the profiling information. (You can do this before the program has terminated. Pressing F5 will cause KCachegrind to load any new incremental data.)

== Adding theory support to the parser ==

To add support for a new theory to the SMT parser, you will need to edit <code>src/parser/smt/Smt.g</code>:

<ol>
<li> Add any new operators to the list of operator tokens near the end of file (look for <code>AND_TOK</code>, etc).
<li> Add the new operator as an alternative in the rule <code>builtinOp</code>, mapping it to its corresponding CVC4 <code>Kind</code>.
<li> Add the rules to match new constant tokens near the end of the file (look for <code>NUMERAL_TOK</code>, etc).
<li>Add the new constants as alternatives in the rule <code>annotatedFormula</code>, decoding the token text and calling <code>MK_CONST</code> (which is just a macro that calls <code>ExprManager::mkConst</code>). NOTE: if you have a constant token type <code>MY_CONST_TOK</code>, you can get a <code>std::string</code> representing the matched input using the static method <code>AntlrInput::tokenText</code>, e.g.,
<pre> // annotatedFormula alternatives ...
| MY_CONST_TOK
{ std::string myConstText = AntlrInput::tokenText($MY_CONST_TOK);
MyConstType c = ...;
expr = MK_CONST(c); }
</pre>
</li>
</ol>

== Building a 32-bit binary on a 64-bit machine ==

(These instructions are for Debian/Ubuntu)

First, make sure you have the 32-bit library dependencies installed

sudo apt-get install libc6-dev-i386 g++-multilib lib32gmpxx4 lib32gmp3 lib32gmp3-dev

You will also need to build a 32-bit version of the ANTLR library. Just configure the library with <code>--disable-64bit</code>. [I found that I had to first configure and build with <code>--enable-64bit</code>, then reconfigure and build with <code>--disable-64bit</code> to get it to work. -Chris]

Configure CVC4 with <code>CFLAGS=-m32 CXXFLAGS=-m32</code> and build as usual.

CVC4 - User contributions [en]

User Manual

About CVC4

About CVC4

About CVC4

Building CVC4 from source

Tutorials

Tutorials

Tutorials

Building CVC4 from source

Tutorials

Tutorials

Tutorials

CVC4's native language

CVC4's native language

CVC4's native language

About CVC4

About CVC4

About CVC4

About CVC4

About CVC4

Publications

About CVC4

About CVC4

CVC4

Acknowledgments

Acknowledgments

Related Links

CVC4

Developer's Guide