To Run What No One Has Run Before: Executing an Intermediate Verification Language

Polikarpova, Nadia; Furia, Carlo A.; West, Scott

doi:10.1007/978-3-642-40787-1_15

Cited by 15 publications

(8 citation statements)

References 27 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…For instance, suppose we have arrays A and B and a candidate asserting that 10. Boogaloo [43] and Symbooglix [44] also support Boogie interpretation, but are generic and do not exploit knowledge specific to GPU kernels, as we do. all accesses into A and into B are distinct.…”

Section: Dynamic Analysis Dynmentioning

confidence: 90%

Implementing and Evaluating Candidate-Based Invariant Generation

Betts

Chong

Deligiannis

et al. 2018

IIEEE Trans. Software Eng.

View full text Add to dashboard Cite

The discovery of inductive invariants lies at the heart of static program verification. Presently, many automatic solutions to inductive invariant generation are inflexible, only applicable to certain classes of programs, or unpredictable. An automatic technique that circumvents these deficiencies to some extent is candidate-based invariant generation, whereby a large number of candidate invariants are guessed and then proven to be inductive or rejected using a sound program analyzer. This paper describes our efforts to apply candidate-based invariant generation in GPUVerify, a static checker for programs that run on GPUs. We study a set of 383 GPU programs that contain loops, drawn from a number of open source suites and vendor SDKs. Among this set, 253 benchmarks require provision of loop invariants for verification to succeed. We describe the methodology we used to incrementally improve the invariant generation capabilities of GPUVerify to handle these benchmarks, through candidate-based invariant generation, using cheap static analysis to speculate potential program invariants. We also describe a set of experiments that we used to examine the effectiveness of our rules for candidate generation, assessing rules based on their generality (the extent to which they generate candidate invariants), hit rate (the extent to which the generated candidates hold), worth (the extent to which provable candidates actually help in allowing verification to succeed), and influence (the extent to which the success of one generation rule depends on candidates generated by another rule). We believe that our methodology may serve as a useful framework for other researchers interested in candidate-based invariant generation. The candidates produced by GPUVerify help to verify 231 of the 253 programs. This increase in precision, however, makes GPUVerify sluggish: the more candidates that are generated, the more time is spent determining which are inductive invariants. To speed up this process, we have investigated four under-approximating program analyses that aim to reject false candidates quickly and a framework whereby these analyses can run in sequence or in parallel. Across two platforms, running Windows and Linux, our results show that the best combination of these techniques running sequentially speeds up invariant generation across our benchmarks by 1.17× (Windows) and 1.01× (Linux), with per-benchmark best speedups of 93.58× (Windows) and 48.34× (Linux), and worst slowdowns of 10.24× (Windows) and 43.31× (Linux). We find that parallelizing the strategies marginally improves overall invariant generation speedups to 1.27× (Windows) and 1.11× (Linux), maintains good best-case speedups of 91.18× (Windows) and 44.60× (Linux), and, importantly, dramatically reduces worst-case slowdowns to 3.15× (Windows) and 3.17× (Linux).

show abstract

Section: Dynamic Analysis Dynmentioning

confidence: 90%

Implementing and Evaluating Candidate-Based Invariant Generation

Betts

Chong

Deligiannis

et al. 2018

IIEEE Trans. Software Eng.

View full text Add to dashboard Cite

show abstract

“…The design of JML accommodates both deductive and runtime verification [16]. Combinations of deductive verification and testing for imperative languages were recently studied and implemented for C# programs specified with Boogie in [18], and combining Dafny and Pex in [7]. In [8], the specification-based random testing tool Quickcheck is used to find counter-examples to invariants that have not been formally verified by automated theorem provers.…”

Section: Discussionmentioning

confidence: 99%

“…Static analysis is performed on the source code without executing the program, whereas dynamic analysis is based on the program execution. Both are complementary and can be advantageously combined [10,3,14,6,7,5,18].…”

Section: Introductionmentioning

confidence: 99%

How Test Generation Helps Software Specification and Deductive Verification in Frama-C

et al. 2014

View full text Add to dashboard Cite

Abstract. This paper describes an incremental methodology of deductive verification assisted by test generation and illustrates its benefits by a set of frequent verification scenarios. We present STADY, a new integration of the concolic test generator PATHCRAWLER within the software analysis platform FRAMA-C. This new plugin treats a complete formal specification of a C program during test generation and provides the validation engineer with a helpful feedback at all stages of the specification and verification tasks.

show abstract

“…Each experiment targets one Boogie program b: it runs Boogie with command boogie b and a timeout of 180 seconds; it runs b2w to translate b to w in WhyML; for each SMT solver p among Alt-Ergo, CVC3, CVC4, and Z3, it runs Why3 with command why3 prove -P p w, also with a timeout of 180 seconds. 21 For each run we collected the wall-clock running time, the total number of verification goals, and how many of such goals the tool verified successfully. 22 20 https://github.com/boogie-org/boogie/tree/master/Test 21 The timeouts were enforced using the Unix command timeout.…”

Section: Methodsmentioning

confidence: 99%

“…Another element that differentiates Boogie and Why3 is the support for executing programs; this is quite useful for debugging verification attempts and for applying testing-like techniques to the realm of verification. Boogaloo [21] supports symbolic execution of Boogie programs; Symbooglix is a more recent project with the same goal [19]. Thanks to it being a member of the ML family, Why3 directly supports symbolic execution as well as compilation of WhyML programs to OCaml.…”

Section: Related Workmentioning

confidence: 99%

Why Just Boogie? Translating Between Intermediate Verification Languages

Ameri,

Furia

2016

Preprint

Self Cite

View full text Add to dashboard Cite

The verification systems Boogie and Why3 use their respective intermediate languages to generate verification conditions from high-level programs. Since the two systems support different back-end provers (such as Z3 and Alt-Ergo) and are used to encode different high-level languages (such as C# and Java), being able to translate between their intermediate languages would provide a way to reuse one system's features to verify programs meant for the other. This paper describes a translation of Boogie into WhyML (Why3's intermediate language) that preserves semantics, verifiability, and program structure to a large degree. We implemented the translation as a tool and applied it to 194 Boogieverified programs of various sources and sizes; Why3 verified 83% of the translated programs with the same outcome as Boogie. These results indicate that the translation is often effective and practically applicable.

show abstract

To Run What No One Has Run Before: Executing an Intermediate Verification Language

Cited by 15 publications

References 27 publications

Implementing and Evaluating Candidate-Based Invariant Generation

Implementing and Evaluating Candidate-Based Invariant Generation

How Test Generation Helps Software Specification and Deductive Verification in Frama-C

Why Just Boogie? Translating Between Intermediate Verification Languages

Contact Info

Product

Resources

About