Quantifiers on Demand

Abstract

Automated program verification is a difficult problem. It is undecidable even for transition systems over Linear Integer Arithmetic (LIA). Extending the transition system with theory of Arrays, further complicates the problem by requiring inference and reasoning with universally quantified formulas. In this paper, we present a new algorithm, QUIC3, that extends IC3 to infer universally quantified invariants over the combined theory of LIA and Arrays. Unlike other approaches that use either IC3 or an SMT solver as a black box, QUIC3 carefully manages quantified generalization (to construct quantified invariants) and quantifier instantiation (to detect convergence in the presence of quantifiers). While QUIC3 is not guaranteed to converge, it is guaranteed to make progress by exploring longer and longer executions. We have implemented QUIC3 within the Constrained Horn Clause solver engine of Z3 and experimented with it by applying QUIC3 to verifying a variety of public benchmarks of array manipulating C programs.

RustHorn: CHC-Based Verification for Rust Programs

“…For example, one can represent the memory state as a pair of an array h and an index sp indicating the maximum index that has been allocated so far. Finding quantified invariants is known to be difficult in general despite active studies on it [41,2,36,26,19] and most current array-supporting CHC solvers give up finding quantified invariants. In general, much more complex operations on pointers can naturally take place, which makes the universally quantified invariants highly involved and hard to automatically find.…”

Quantified Invariants via Syntax-Guided Synthesis

“…We have compared our tool with Spacer (Z3 v4.8.3) [26], that implements a recent QUIC3 [22] algorithm, Booster (v0.2) [2], VIAP (v1.0) [35], and Veri-Abs (v1.3.10) [11]. The last two tools performed well in the ReachSafety Array subcategory at SVCOMP 2019 4 .…”

Verifying Array Manipulating Programs with Full-Program Induction

“…Specifically, (i) we do not require explicit or implicit loop-specific invariants to be provided by the user or generated by a solver (viz. by constrained Horn clause solvers [20,14,9] or recurrence solvers [25,16]), (ii) we induct on the full program (possibly containing multiple loops) with parameter N and not on iterations of individual loops in the program, and (iii) we perform non-trivial correctby-construction code transformations, whenever feasible, to simplify the inductive step of reasoning. The combination of these factors often reduces reasoning about a program with multiple loops to reasoning about one with fewer (sometimes even none) and "simpler" loops, thereby simplifying proof goals.…”

“…Among techniques that do not require explicit inductive invariants or mid-conditions for each loop, there are some that require loop invariants to be implicitly generated by a constraint solver. These include techniques based on constrained Horn clause solving [20,14,9,23], acceleration and lazy interpolation for arrays [1] and those that use inductively defined predicates and recurrence solving [25,16], among others. Thanks to the impressive capabilities of modern constraint solvers and the effectiveness of carefully tuned heuristics for stringing together multiple solvers, this approach has shown a lot of promise in recent years.…”