Demand-driven inference of loop invariants in a theorem prover K. Rustan M. Leino Microsoft Research, Redmond, WA, USA joint work with Francesco Logozzo

Demand-driven inference ofloop invariants in a theorem proverK. Rustan M. LeinoMicrosoft Research, Redmond, WA, USA

joint work with

Francesco LogozzoÉcole Polytechnique, Paris, France

3 April 2005Invited talk, AVIS 2005Edinburgh, Scotland, UK

Spec# joint work withMike Barnett,Robert DeLine,Manuel Fähndrich,Wolfram Schulte,

andHerman Venter

Software engineering problem

Building and maintaining large systems that are correct

Approach

• Specifications record design decisions– bridge intent and code

• Tools amplify human effort– manage details– find inconsistencies– ensure quality

Spec#• Experimental mix of contracts and tool

support• Aimed at experienced developers who know

the high cost of testing and maintenance• Superset of C#

– non-null types– pre- and postconditions– object invariants

• Tool support– more type checking– compiler-emitted run-time checks– static program verification

C#contracts

everywhere

type checking

static verification

into the future

run-time checks

degree of checking,effort

Spec# demo

Basic architecture of a static verifier

verification conditiongenerator

theorem prover

verification condition

program with specifications

“correct” or list of errors

Spec# static verifier architecture

V.C. generator

automatictheorem prover


Spec#

“correct” or list of errors

Spec# compiler

MSIL (“bytecode”)

translator

Boogie PL

inference engine

Spec# static program verifier

• high precision• needs invariants

• computes invariants• over-approximates

error message

Predicate abstraction and refinement

C program

predicates

boolean program

modelchecker

correct

concrete trace

feasible?

abstract trace

no yes

e.g.: Graf & Saïdi, SLAM, BLAST, …

predicateabstraction

predicaterefinement

unsatisfiable

satisfiable

Lemmas-by-demand theorem proving

input formula

lemmas

propositional formula

SAT solver

conjunction of input literalsconsistent with theories?

monome

no yes

e.g.: Verifun, de Moura & Rueß, CVC Lite, Zap, …

conflict-clause

generation

counterexample

valid

error message

Static program verification

program loop invariant

s


theoremprover

program trace


generation

counterexample

valid

error message

Loop invariants on demand

program loop invariant

s


theoremprover

program tracegive up?

no yesmore precise

(stronger or context sensitive)inference


generation

counterexample

valid

error message

Generating VC once

program

properties about loop invariants


(VC)

theoremprover

program trace

give up?

no yes

more precise inference

formula

sourcelanguage

intermediatelanguage

passive command


S,T ::= x := E| assert E| S ; T| if E then S else T

end| while E do S end

sourcelanguage


passive command


C,D ::= x := E| assert E| assume E| C ; D| C [] D| while * do S end

sourcelanguage


passive command


Tr[ x := E ] = x := ETr[ assert E ] = assert ETr[ S;T ] = Tr[ S ] ; Tr[ T ]Tr[ if E then S else T end ] =

( assume E ; Tr[ S ] [] assume ¬E ; Tr[ T ] )

Tr[ while E do S end ] =while * do assume E ; Tr[ S ] end ;assume ¬E

sourcelanguage


passive command


Tr[ x := E ] = x := ETr[ assert E ] = assert ETr[ S;T ] = Tr[ S ] ; Tr[ T ]Tr[ if E then S else T end ] =

( assume E ; Tr[ S ] [] assume ¬E ; Tr[ T ] )

Tr[ while E do S end ] =while * do assume E ; Tr[ S ] end ;( assume E ; Tr[ S ] ; assume false[] assume ¬E)

x := * ;assume J

sourcelanguage


passive command


• variation on Single Static Assignment (SSA) form

Examples:• if name of x before assert E is x0,

then translate assert E into:assert E[x0 / x]

• if name of x before x := E is x0, then make up a new name x1 and translate x := E into:

assume x1 = E[x0 / x]

sourcelanguage


passive command


• if name of x is x0 after S and x1 after T , then make up a new name x2 and translate S [] T into:

S’ ; assume x2 = x0[] T’ ; assume x2 = x1

• if name of x is x0 before while * do S end , then make up a new name x1 and translate the loop into:

assume J(x0, x1)where J is an uninterpreted predicate symbol

sourcelanguage


passive command


• wp( assert E, Q ) = E Q• wp( assume E, Q ) = E Q• wp( S;T, Q ) = wp( S, wp( T,

Q ))• wp( S [] T, Q ) = wp( S, Q )

wp( T, Q )

Examplefinding index of minimum element in an array

m := 0; x := 0;while x < N do

if * then m := x end;x := x + 1

end;if N > 0 then

assert 0 ≤ m < Nend

Example: passive command

assume m0 = 0; assume x0 = 0;assume J(m0, m1, x0, x1);( assume x1 < N ;

( assume m2 = m1 [] assume m2 = x1 );assume x2 = x1 + 1;assume false

[]assume ¬ (x1 < N)

);( assume N > 0 ; assert 0 ≤ m1 < N[] assume ¬ (N > 0))

Example: from monome to lemma

M : m0 = 0 x0 = 0 J(m0, m1, x0, x1) ¬ (x1 < N) N > 0 ¬(0 ≤ m1 < N)

On entry to the loop, the names m0, m1, N are in scope, about which M says:

m0 = 0 x0 = 0 N > 0

Thus, assuming the condition: m0 = 0 x0 = 0 N > 0 m0 = m x0 = x

on entry to the loop, an abstract interpreter may infer the following loop invariant:

0 = m0 ≤ m < N 0 = x0 ≤ x ≤ N

Thus, the abstract interpreter produces the following lemma about J:

m0 = 0 x0 = 0 N > 0 J(m0, m1, x0, x1) 0 = m0 ≤ m1 < N 0 = x0 ≤ x1 ≤ N

Watch forpreliminaryrelease of Spec#next week

Summary and conclusions• Spec# is a programming system that

includes a static program verifier• Trend: abstraction refinement on

demand• Inference of invariants can be done this

way, inside theorem prover!• Inference can be context sensitive• VCs can be generated once• Extensions to procedure summaries

http://research.microsoft.com/~leino

http://research.microsoft.com/projects/specsharp

Documents

Demand-driven inference of loop invariants in a theorem prover K. Rustan M. Leino Microsoft Research, Redmond, WA, USA joint work with Francesco Logozzo