Faster temporal reasoning for infinite-state programs

In this paper, we describe a new symbolic model checking procedure for CTL verification of infinite-state programs. Our procedure exploits the natural decomposition of the state space given by the control-flow graph in combination with the nesting of temporal operators to optimize reasoning performed during symbolic model checking. An experimental evaluation against competing tools demonstrates that our approach not only gains orders-of-magnitude performance improvement, but also allows for scalability of temporal reasoning for larger programs.


I. INTRODUCTION
Branching-time temporal logics like CTL allow us to reason about safety, termination, and nontermination via the system's interaction with inputs and nondeterminism in a way that linear-time temporal logics like LTL do not.This style of reasoning can be useful in applications ranging from planning, games, security analysis, disproving, and environment synthesis [19], [29].CTL-based tools also have been used as the basis for higher-performance LTL tools [13].
In this paper we propose a new symbolic CTL model checker for infinite-state programs.We adapt the well-known bottom-up strategy for finite-state CTL model checking [9] to infinite-state programs using precondition synthesis as the enabling technology.We leverage recent techniques for proving safety, termination, and nontermination of programs to synthesize preconditions asserting the satisfaction of CTL sub-formulae of an input property.The key insight to our approach is the exploitation of the natural decomposition of the state space given by the control flow graph.That is, using a counterexample-guided precondition synthesis strategy, we compute program-location-specific preconditions.Our model checker drastically improves performance by reducing the amount of redundant and irrelevant reasoning performed through information sharing extracted from reachability analysis.That is, several preconditions for each program location can be computed simultaneously.
Take for example the fact that the set of states respecting a property such as EF y < z before a program command is very often the same or nearly the same as the set of states respecting EF y < z after the command.In comparison to existing tools (e.g.[10], [4]) we reduce the amount of reasoning performed as part of the procedure.We can infer whether a command is likely to affect the truth of EF y < z.So, sequential locality implies that the precondition of a location is easily computed if the preconditions of its successors are known.This approach gives way to compositional reasoning.For instance, given a program and a desired property, we can, in parallel, synthesize preconditions, desired environments, and plans of individual procedures of a program with the goal of composing the found preconditions into a proof of the whole program.The advantage to this approach is that the program verification tools never have to examine the program as a whole, but instead find a modular proof using compositional reasoning.Recent success in this style of reasoning can be found in areas such as proving correctness of non-blocking algorithms [20], and the analysis of biological models [11].
We also suggest a new method of treating existential path quantification in the infinite-state setting.Existential formulas are handled by considering their universal dual, allowing counterexamples of said duals to serve as a witness asserting the satisfaction of the existential CTL formula.
An experimental evaluation using examples from the benchmark suites of the competing tools (which are drawn from industrial benchmarks) demonstrates orders-of-magnitude performance improvements in many cases.This evaluation is discussed at the conclusion of the paper.
In this work we are aiming to prove CTL properties with nested combinations of existential and universal path quantifiers of integer programs.Song & Touili [32] perform a coarse one-time abstraction that takes programs and produces pushdown automata, however the abstraction produced is imprecise and leads to significant information loss.Gurfinkel et al. [22] do not reliably support mixtures of nested universal/existential path quantifiers, etc.The two tools closest in their feature set to our setting are from Cook & Koskinen [10] and Beyene et al. [4].Cook & Koskinen implement the Kesten and Pnueli [24] deductive proof system using an incremental reduction to program analysis tools.Beyene et al. these tools carryout unnecessary computation in their analysis.
In addition, our new approach to the treatment of existential path quantification based on dualization contrasts to that of Cook & Koskinen, which attempts to find a non-trivial restriction on the state-space such that AF can be used to reason about EF, or AG can be used to reason about EG.Our approach also contrasts to the tool of Beyene et al. [4], as their tool requires existential quantification over predicates to be supported by the underlying constraint solver, whereas our technique can make use of off-the-shelf verification tools.
Limitations.We do not support programs with heap, nor do we support recursion or concurrency.The heap-based programs we consider during our experimental evaluation have been abstracted using the over-approximation from the technique of Magill et al. [26].Note that this abstraction can lead to unsoundness when we use the existential subset of CTL.Our comparison to existing tools remains fair, as each of the previous tools uses the same abstraction.Effective techniques for proving temporal properties of programs with heap remains an open research question.
As our technique heavily relies on calculating pre-images, it is important that fragments of the underlying program logic are closed under pre-impages, e.g.integer linear arithmetic, a fragment of integer arithmetic.Our procedure is not complete as we use a series of incomplete subroutines.

II. PRELIMINARIES
Programs.As is standard [27], we treat programs as controlflow graphs, where edges are annotated by the updates they perform to variables.A program is a triple P = (L, E, Vars), where L is a set of locations, E is a set of edges/transitions, and Vars is a set of variables.Each edge τ = ( , ρ, ) in E, where , ∈ L and ρ is a condition, specifies possible transitions in the program.A valuation associates with the variables in Vars values in Vals.A trace or a path of a program is either a finite or an infinite sequence of edges allowed by the program.The condition ρ is an assertion in terms of Vars and Vars , a primed copy of Vars, where constants range over Vals.Intuitively, Vars refers to the values of variables before the update and Vars refers to the values of variables after the update.The set of locations includes the first location 0 that has no incoming transitions from other program locations.That is, for every τ = ( , ρ, ) ∈ E we have = 0 .Transitions exiting 0 have their conditions expressed in terms of Vars .Locations with incoming transitions from 0 are initial locations.This allows us to encode more complex initial conditions.In figures we usually omit 0 and add edges with no source to locations having an incoming transition from 0 .The program gives rise to a transition system T = (S, R), where S is the set of program states of the form S = (L − { 0 }) × (Vars → Vals) and R ⊆ S × S. That is, a program state is a pair ( , s) where = 0 and s is a valuation, i.e., a function from program variables to values.The program can transition from ( , s 1 ) to ( , s 2 ) if there is a transition ( , ρ, ) ∈ E such that (s 1 , s 2 ) |= ρ.Here the valuation (s 1 , s 2 ) is a function from Vars ∪ Vars to Vals such that for every v ∈ Vars we have where s −1 is some arbitrary state.Notice that in such a case ρ is expressed in terms of Vars and hence the state s −1 does not affect the evaluation of ρ.For example, Figure 1 includes the representation of the program while x ≤ 0 do if * then x := x + 1; fi; done; y := 1; with initial condition x = * ∧ y = 0 and where * indicates a non-deterministic value.
A finite set of program locations C ⊆ L is called a cutpoint set if 0 , n ∈ C, where n ∈ N and every cycle in the program's graph contains at least one cut-point.
CTL.We are interested in verifying state-based temporal properties in computational tree logic (CTL) [9].A CTL formula is of the form where α is an atomic proposition (e.g.x < y).
To give intuition behind the semantics of CTL, here P, s |= AFϕ asserts that in program P and in all possible executions starting from s the property ϕ will eventually hold in some future state reachable from s, whereas P, s |= EFϕ asserts that there is a state in which ϕ holds and that it can be reached from s.The formula AGϕ asserts that ϕ must hold throughout all possible executions, while EGϕ asserts that there exists an execution such that ϕ would be true throughout.Aϕ 1 Wϕ 2 asserts that for all executions, ϕ 1 has to hold until ϕ 2 holds, signifying that ϕ 2 does not necessarily have to hold as long as ϕ 1 holds.Contrarily, Eϕ 1 Uϕ 2 asserts that there exists an execution in which ϕ 1 has to hold at least until at some position ϕ 2 holds.AU and EW are represented as syntactic sugar as usual.
For a program P and a CTL property ϕ, we say that ϕ holds in P , denoted by P |= ϕ if for every initial state s we have P, s |= ϕ.
Ranking functions.For a state space S, a ranking function f is a total map from S to a well-ordered set with ordering relation ≺.A relation R ⊆ S × S is well-founded if and only if there exists a ranking function f such that ∀(s, s ) ∈ R. f (s ) ≺ f (s).We denote a finite set of ranking functions (or measures) as M. Note that the existence of a non-empty set of ranking functions for a relation R is equivalent to containment of R + within a finite union of wellfounded relations [30].That is, a set of ranking functions {f 1 , . . ., f n } denotes the disjunctively well-founded relation Counterexamples.In our setting new ranking functions can be automatically synthesized by examining counterexamples produced by an underlying safety prover (discussed in more detail in Section IV).Due to the recursive nature of our procedure it is only necessary to handle counterexamples to formulas of nesting depth 1.For example, Aϕ, where ϕ is a path formula that includes no nesting of additional operators, or α 1 ∨α 2 , where α 1 and α 2 are assertions.A counterexample for an atomic proposition α is a state in which α does not hold.A counterexample for a conjunction ϕ 1 ∧ ϕ 2 is a state ISBN: 978-0-9835678-4-4.Copyright owned jointly by the authors and FMCAD Inc.
where either ϕ 1 or ϕ 2 does not hold.A counter example for disjunction ϕ 1 ∨ ϕ 2 is a state where both sub-formulas do not hold.A counterexample to an AGϕ property is a path to a place where ϕ does not hold.A counterexample to an AFϕ property is a "lasso": a stem path to a particular program location, then a (not necessarily simple) cycle which returns to the same program location, and the property ϕ does not hold along the stem and the cycle.Finally, a counterexample to A[ϕ 1 Wϕ 2 ] is a path to a place where there is a subcounterexample to ϕ 1 as well as one to ϕ 2 .A counterexample to E[ϕ 1 Uϕ 2 ] can be of the same form as that of A[ϕ 1 Wϕ 2 ], as well as one where ϕ 1 holds while ϕ 2 does not hold anywhere along the path.

III. INTUITION AND EXAMPLE
We first informally explain our technique and demonstrate it with an example.
Intuition.The idea of the procedure is to find for each subformula ϕ a precondition ℘ ϕ that ensures its satisfaction.To utilize sequential locality of a counterexample's controlflow graph further on, a precondition ℘ ϕ is thus partitioned to ℘ i , ϕ for every location i in the program.Thus, ℘ ϕ takes the form i (pc = i ⇒ ℘ i , ϕ ).Here pc = i is used to assert that the state is at location i in the program's controlflow graph.We find preconditions by iteratively recursing over the structure of the given CTL formula.That is, we start by finding the precondition of the innermost sub-formula followed by search for the preconditions of the outer sub-formulas dependent on it.We note that the precondition of an atomic proposition is the proposition itself, hence from this point on, we shall treat the precondition of an atomic proposition and the atomic proposition itself synonymously.
Consider a universal CTL formula.Initially, we approximate its precondition as true.We then search for counterexamples from every possible reachable program location.Failures to the proof attempt will result in the strengthening of the precondition through adding the negation of the pre-image of the discovered counterexample.We use the control-flow graph of a counterexample to simultaneously synthesize preconditions of multiple locations.That is, a counterexample that consists of multiple program locations can be utilized to update the precondition of each contained program location.This is done by iterating along the counterexample path, and for each suffix computing a pre-image from a program location onwards.
Each counterexample found further strengthens a precondition, we thus eliminate said counterexample and search for Fig. 1: The control-flow graph of an example program for which we wish to prove the CTL property AGEF y = 1.
Fig. 2: The transformation of the program from Figure 1 for the property EF y = 1 using its dual AG y = 1.
other proof failures for the given CTL property.Eventually, the precondition will imply the correctness of the sub-formula when no further counterexamples are returned.Existential sub-formulas are handled by considering their universal dual.We thus seek a set of counterexamples generated from the property's universal dual to serve as an existential witness.Hence we begin with an initial precondition approximation false.More directly, pre-images of counterexamples to the negation of the sub-formula serve as a witnesses to the satisfaction of our existential formula.Counterexamples are similarly treated in the existential case, we iteratively calculate their pre-images followed by their elimination until no more counterexamples are generated.As before, we utilize a counterexample's control flow graph to simultaneously update preconditions of multiple locations.
Example.Consider the program in Figure 1 and the property ϕ ≡ AGEF y = 1, which states that for all states, it is always possible that eventually y = 1.The approach followed by nearly all tools supporting CTL would be to find, in this instance, a set of states ℘ such that AG℘ holds, and such that ℘ |= EF y = 1 holds.In this paper we suggest a strategy based on precondition synthesis.
Consider the sub-formula ψ ≡ EF y = 1.For the proposition y = 1, for every program location i we have ℘ i , y = 1 y = 1.We now attempt to prove that ℘ |= AG y = 1 given that AG is EF's universal dual.We start with ℘ ψ false as only failures to proving AG y = 1 can necessitate that there exists a witness such that EF y = 1.Failures to the proof attempt will result in refinements to ℘ through the iterative calculation of the pre-image of each discovered counterexample.Recall that we are interested in counterexamples starting from all program locations: ISBN: 978-0-9835678-4-4.Copyright owned jointly by the authors and FMCAD Inc.
Fig. 3: The transformation of the program from Figure 1 for the sub-property AGEF y = 1 to be utilized in the verification algorithm.The nested property EF y = 1 is substituted with its precondition resulting in a transformation for We begin with 1 .To check AG y = 1 we use a sourceto-source transformation that reduces checking of universal CTL properties to safety [10].The transformation returns the program in Figure 2 (new conditions outlined), on which we use a safety prover to check reachability of ERR.We get counterexample We then calculate the pre-image of CEX 1 for multiple locations along the counterexample.We do so by iterating along the counterexample path, and for every reachable location ∈ L in CEX 1 , we compute a pre-image utilizing the suffix of CEX 1 from onwards.Thus we can avoid redundant reasoning by utilizing sequential locality based upon the program's control-flow graph to compute a refinement for 2 from a counterexample generated for 1 .In this case, we compute ℘ (pc = 1 ⇒ y = 0) ∧ (pc = 2 ⇒ x > 0) One existential witness may not be sufficient to find all states that satisfy ψ in the respective locations, we thus rule out CEX 1 by adding ¬℘ i , ψ to each transition from i to the error state.We re-run our safety checker and find that we do not generate anymore counterexamples, thus completing our precondition synthesis for EF y = 1.
Note that the technique used by Cook & Koskinen [10] imposes that they spend time computing both ℘ 1 , ψ , ℘ 2 , ψ separately while the technique used by Beyene et al. [4] solves a constraint based on an entire path when it's only necessary to reason about a single state.
We now modify ϕ by using ℘ ψ and get ϕ = AG ((pc = The constructed transformation reducing the property ϕ to safety can be seen in Figure 3.Note that in this particular transformation, the outlined instrumented conditions correspond to each of the location preconditions generated for EF y = 1.As ϕ is universal, we begin with the initial precondition ℘ ϕ true.Failures to the proof attempt will result in strengthening the precondition by adding negated pre-images of discovered counterexamples.In this case no counterexamples are returned and we get ℘ ϕ true.This proves that AGEF y = 1 holds.
IV. PROCEDURE In this section we describe the details of our CTL model checking procedure.Figure 4 depicts VERIFY, which wraps  the main procedure TEMPORALWP in Figure 5.Other subroutines used in TEMPORALWP are in Figures 6-10.
We exploit the natural decomposition of the state space given by the control flow graph.That is, using a counterexample-guided precondition synthesis strategy, we compute program-location-specific preconditions.In our approach the table ℘ is the key data structure which maps pairs of program locations and sub-formulae to assertions which represent the current candidate precondition that would guarantee the sub-formulae at a respective location.That is, ℘ , ϕ should be a sufficient and most general precondition to prove that ϕ holds at location .If such is not the case, a counterexample is produced and the procedure attempts to refine ℘  given the counterexample path.Each precondition synthesized substitutes its temporal sub-property in the original formula, and we then continue with the next most outer formula.After a short description of TEMPORALWP and a brief description of each of its subroutines, we give an in depth explanation of TEMPORALWP.
TEMPORALWP: performs both a recursive and a refinementbased computation to construct ℘.It starts by initializing the map of preconditions using procedure INITIALIZEMAP (Figure 6) and then calling itself recursively for each subformula (lines 7-9 and 11-15).TRANSFORM and REFINE are part of the model checking procedure for the current sub-formula while PROPAGATE (Figure 8) updates the map by synthesizing the pre-images given a counterexample.We then reduce the amount of redundant and irrelevant reasoning performed through information sharing extracted from Fig. 9: If divergence is suspected due to infinitely many counterexamples, the sub-procedure strengthens the candidate precondition towards the limit.reachability information.That is, several preconditions for each program location can be computed simultaneously.When TEMPORALWP returns to VERIFY, it is only necessary to check if the precondition of the outermost temporal subproperty is satisfied by the initial states of the program.
TRANSFORM: implements the reduction of model checking to safety checking and well-foundedness, inspired by the procedure from [10].The TRANSFORM transformation utilizes the map ℘, which maps the preconditions synthesized previously for sub-properties and their negations (lines 6,9,13,22, and 31).The program is then transformed according to the CTL sub-property by modifying the program from a given program location k ∈ L. The reduction is only applied from a location k onwards (see loop invariants in lines 12, 21, and 30), that is, we only wish to verify the sub-property starting from transitions stemming from k. Whenever ϕ does not hold for a location , a new reachable transition to an error location ERR is added.
As mentioned, existential path quantifiers are handled by considering their universal dual.For both existential and universal properties, our mapping function is also updated with the precondition for the negation of the property on line 8 in TEMPORALWP and lines 11 and 14 in PROPAGATE.This allows us to conveniently access the negation of the property when encoding existential properties as their universal duals.REFINE: uses a safety prover (similar to IMPACT [28]) to obtain counterexamples from the transformed system, if a ISBN: 978-0-9835678-4-4.Copyright owned jointly by the authors and FMCAD Inc. counterexample exists.A produced counterexample to a liveness property (such as AF) contains a lasso fragment, we then attempt to find an accompanying set of ranking functions M that will show that the counterexample is not valid.We thus attempt to enlarge the set of ranking functions M using the well known method of [14].Otherwise, the absence of a set of ranking function indicates the existence of a recurrent set.Note that proving liveness is undecidable, thus techniques used in [14] are incomplete.

A. TEMPORALWP: computing ℘
In order to synthesize a precondition for a temporal property ψ, we first recursively accumulate the preconditions generated when considering the sub-properties of ψ at lines 8, 13, and 15.The base case, an atomic proposition α, is computed as is standard, e.g., in [15].For the sake of clarity, we omit the descriptions of both FINDCUTPOINTS and the use of sequential locality in PROPAGATE till later, as we solely wish to describe the fundamental procedure underlying our precondition synthesis for each temporal sub-property.We will then discuss how these sub-procedures provide the key to making use of the program's control-flow graph to construct multiple preconditions.
Given the omission of FINDCUTPOINTS, let C be the set of all locations in a program P , that is L. We wish to synthesize a precondition for each ∈ L such that the precondition asserts the satisfaction of ψ.Hence, we iterate over these locations (line 17) and generate a transformed program corresponding to each location using the subroutine TRANSFORM at line 18.
Recall that TRANSFORM allows us to reduce the checking of temporal properties to a program analysis task from a given program location.Each transformed program is then verified through the subroutine REFINE (line 19).A counterexampleguided precondition refinement loop then begins at line 20, where we iteratively refine a precondition for ∈ L until no more counterexamples are found.We now discuss the refinement process for each type of quantifier separately below.Universal precondition synthesis.For a universal CTL subproperty ψ, a precondition ℘ , ψ for a program location is initialized to true (Figure 6 line 12).If REFINE returns a counterexample, we refine ℘ , ψ by taking the negation of pre-image of the returned counterexample at location in PROPAGATE on line 21.Given our temporary omission of sequential locality in PROPAGATE, consider the loop in Figure 9 on line 3 to only iterate over one element, that is the current .As we are handling a universal sub-property its precondition is then strengthened to become ℘ , ψ = ℘ , ψ ∧ ¬pre( , CEX) (line 13 in PROPAGATE).
We then rule out the aforementioned counterexample by adding the assumption ¬pre( , CEX) to each ingoing transition to the error location on the counterexample path, as shown on lines 15 and 16 in PROPAGATE.We then continue to unfold the loop in TEMPORALWP whenever a new counterexample is discovered while iteratively refining ℘ , ϕ , resulting in: Existential precondition synthesis.For an existential CTL property, a precondition must entail an existential witness satisfying the sub-property ψ at program location .We thus verify the universal dual of the existential property (as instrumented by our encoding) and seek a set of counterexamples generated from the property's universal dual to serve as an existential witnesses.
A precondition ℘ , ϕ for a program state is initially false (line 7 in Figure 6).If a counterexample is returned, ℘ , ϕ is refined through the disjunction of the pre-image of the counterexample returned, that is ℘ , ψ = ℘ , ψ ∨ pre( , CEX) (line 10 in Figure 8).
We rule out the aforementioned counterexample by adding the assumption ¬pre( , CEX), and continue to unfold the loop with each newly discovered counterexample while iteratively refining ℘ , ψ .Note that finding one witness is not sufficient to satisfy an existential property, as ℘ , ψ must characterize all the states satisfying the sub-property ψ at a location.Thus, Upon the return of our precondition method to its caller, ℘ will contain the precondition for the most outer temporal property of the original CTL property ϕ.
In our procedure, divergence can occur due to the possibility of generating infinitely many counterexamples.In practice this is rare, but not unheard of.We thus implement the following heuristic introduced by [10]: • If we suspect we are looking at a sequence of repeated counterexamples that will result in divergence, we call the procedure STRENGTHEN ( Figure 9, line 5 in PROP-AGATE).The sub-procedure strengthens the candidate precondition towards the limit.• STRENGTHEN takes the calculated pre-image α, then proceeds to quantify out all variables that are updated proceeding the program location by applying quantifier elimination (QE).
• This heuristic can lead to unsoundness, as STRENGTHEN may over-approximate the set of states, causing ℘ to be potentially unsound for temporal properties involving existential path quantifiers.To check that the guessed candidate precondition is in fact a real precondition, e.g. that ℘ ⇒ EG ℘ , we can use the approach from Beyene et al. [4] to double check the small lemma.• If the check succeeds we continue, if the check fails we raise an exception.
Reducing redundant and irrelevant reasoning.Given that our approach synthesizes counterexample guided preconditions over program locations, we utilize sequential locality to simultaneously calculate preconditions for the set of locations that are arranged and can be accessed from a CEX starting from a given location .Our propagation sub-procedure PROP-AGATE (Figure 8) is called from TEMPORALWP at line 21.We iterate along the counterexample path, and for every reachable location ∈ L, we compute a pre-image utilizing a suffix of CEX from onwards.In more informal terms, every program location along the path can utilize the same counterexample to show that the property does or does not hold.Practically, the computation of a pre-image is performed by going backwards ISBN: 978-0-9835678-4-4.Copyright owned jointly by the authors and FMCAD Inc.
over the counter example.PROPAGATE alone does not eliminate redundant or irrelevant reasoning, as we would still iterate over locations whose preconditions have already been computed for.We thus calculate a cut-point set C such that C ⊆ L and every cycle in the program's graph contains at least one cut-point (line 16 in TEMPORALWP).That is, we only wish to synthesize a precondition over each program location ⊆ C. We choose to verify the set of cut-points [18] instead of all program locations, as cut-points provide locality across program locations given the nature of cycles.We will thus be able to propagate a cutpoint precondition to all locations reachable from a cycle of a generated counterexample.Other program analysis inspired techniques may be used for the selection of initial locations to be verified.A cycle independent analysis can be run for those locations unreachable from program cut-points.
Proof Sketch: We prove the proposition by induction on the structure of the formula.It is clear for an atomic proposition and for Boolean operators.Consider a universal path formula.As the counter examples obtained from the underlying program analysis tool are real counter examples, it follows that their pre-images do not satisfy the formula.We then get additional counter examples, which are all sound.The termination of the loop searching for counter examples implies that the disjunction of all pre-images is sound and complete.Existential path formulas are dual.

V. EVALUATION
In this section we discuss the results of our experiments with an implementation of the procedure from Figure 4. Our implementation is built as an extension to the open source project T2 [1], which uses a safety prover similar to IMPACT [28] alongside previously published techniques for discovering ranking functions, etc [31], [21] to prove both liveness and safety properties.The source code for our tool can be found at http://heidyk.com/T2source/.
We have compared our tool to that of Cook & Koskinen [10] and Beyene et al. [4].The benchmarks used are the same as those used in [10] and [4].These benchmarks were originally created by Cook & Koskinen using the examples drawn from the I/O subsystem of the Windows OS kernel, the backend infrastructure of the PostgreSQL database server, and the SoftUpdates patch system [23].The benchmarks can be found at http://www.cims.nyu.edu/˜ejk/ctl/.For each program and CTL property ϕ, we verify both ϕ and ¬ϕ.The various tools were executed on an Intel x64-based 2.8 GHz single-core processor.
Program commands.We now discuss the format in which we interpret a program's commands.A deterministic assignment statement of the form v = exp where v ∈ Vars and exp is an expression over program variables is translated to the In Figure 11 we display the comparison of our results.For each program and its set of CTL properties, we display the number of lines of code (LOC), and report the time it took to verify a CTL property (Time column) in seconds.A in the "Result" column indicates that the tool was able to verify the property.Likewise, an × indicates that the tool failed to prove the property.A timeout or memory exception is indicated by T/O.A timeout is triggered if verification of an experiment exceeds 3000 seconds.The symbol "-" in the Time and Result column indicates that the experiment was not run.
Overall, our tool demonstrates a significant increase in performance and scalability.Contrary to existing tools, our tool produces no timeouts and programs are often verified in under a second or less.The aforementioned tools often take minutes (the former more-so than the latter).Furthermore, the previous tools produce T/Os in cases where the temporal formula is complex, the size of the program is large, or both.Although a few of our results are on par with Beyene et al., one can speculate from our evaluations that said tool is not well equipped to handle larger programs.Contrarily, our tool demonstrates the potential for scalability.On average, we show orders-of-magnitude performance improvement over existing tools, particularly when dealing with larger programs.
In a few cases our tool produces results that differ with one of the previous tools, due to bugs in the previous tools.As an example, in the S/W Updates case we are unable to repeat the result of Cook & Koskinen on c > 5 ∧ AG(r ≤ 5) and c > 5 ∧ EG(r ≤ 5).Our result agrees with that of Beyene et al.. Finally, OS frag. 2 requires fairness, and it is unclear how [10] and [4] verified said program, as all these tools lack support for fairness.Cook & Koskinen acknowledge their bug.

VI. CONCLUDING REMARKS
In this paper we have described a procedure for CTL model checking that takes advantage of the structure of control-flow graphs available in programs.Our procedure works recursively on the structure of the property and computes (location-based) preconditions for the satisfaction of each sub-formula.The idea is to use a decomposition based on program-location (thus facilitating the use of program analysis techniques), but to maintain the current state of the intermediate lemmas in a way their results can be used to quickly facilitate the computation of results for nearby program locations.As is evident from the outcome of our experimental evaluation, our method leads to dramatic performance improvement over competing tools that support CTL verification for infinite-state programs.Additionally, we wish to further experiment with the scalability that our methodology can perhaps provide.ϕ ¬ϕ Fig. 4 Beyene [4] Cook [10] Fig. Fig. 11: The results of applying our CTL model checking procedure on benchmarks from [10], [4].For each program we verify a set of properties (ϕ) and their negations (¬ϕ) and compare our results with [10], [4].A timeout (T/O) is triggered if verification of a benchmark exceeds 3000 seconds.
[4] implement the same idea as Cook & Koskinen using a reduction to Hornclause reasoning.Neither Cook & Koskinen nor Beyene et al. make use of the locality in programs as we do.Effectively, ISBN: 978-0-9835678-4-4.Copyright owned jointly by the authors and FMCAD Inc.

16 C 17 foreach ∈ C do 18 P 25 done 26 ℘Fig. 5 :
Fig. 5: Procedure TEMPORALWP getting a temporal property and a program and returning the map from program locations and sub-formulas to assertions.

1 3 CEX 4 while P can reach ERR do 5 if 7 M 12 CEX 13 doneFig. 7 : 2 α = true 3 ( 8 α 13 ℘ 15 if = ERR then 16 ρFig. 8 :
Fig. 7: Procedure REFINE getting a program, a temporal property, the map from locations and temporal properties to assertions, and a set of ranking functions and returning a counter example reaching location ERR and a (possibly) larger set of ranking functions.1 let PR O P A G A T E(CEX, P, κ, ψ,n,℘): map = 2 α = true

Fig. 10 :
Fig. 10: Reduction of model checking of temporal properties to safety and ranking function synthesis.