Section: New Results
Foundations and Spreading of Deductive Program Verification
 A Why3 Framework for Reflection Proofs and its Application to GMP's Algorithms

Earlier works using Why3 showed that automatically verifying the algorithms of the arbitraryprecision integer library GMP exceeds the current capabilities of automatic solvers. To complete this verification, numerous cut indications had to be supplied by the user, slowing the project to a crawl. G. Melquiond and R. RieuHelft extended Why3 with a framework for proofs by reflection, with minimal impact on the trusted computing base. This framework makes it easy to write dedicated decision procedures that make full use of Why3's imperative features and are formally verified. This approach opens the way to efficiently tackling the further verification of GMP's algorithms [33].
 GOSPEL  Providing OCaml with a Formal Specification Language

In the context of the ANR project “VOCaL” (see Sec. 9.2.2), which aims at building a formally verified OCaml library of data structures and algorithms, a specification language for OCaml is designed and implemented. It is called GOSPEL, for Generic Ocaml SPEcification Language. During his postdoc in the Toccata team, from September 2018 to August 2019, C. Lourenço implemented a parser and type checker for GOSPEL. The work on the GOSPEL language has been presented at FM'19 [23]. J.C. Filliâtre was keynote speaker at iFM 2019 and he gave a talk on the ongoing work in the VOCaL project, including GOSPEL [17].
 Program Verification Competition VerifyThis 2018

VerifyThis 2018 took place on April 14 and 15, 2018 in Thessaloniki, Greece, as a satellite event of ETAPS 2018. It was the sixth edition in the VerifyThis annual competition series. Typical challenges in the VerifyThis competitions are small but intricate algorithms given in pseudocode with an informal specification in natural language. Participants have to formalize the requirements, implement a solution, and formally verify the implementation for adherence to the specification. There are no restrictions on the programming language and verification technology used. The time frame to solve each challenge is limited to 90 minutes. Submissions are judged for correctness, completeness, and elegance. The focus includes the usability of the tools, their facilities for formalizing the properties and providing helpful output.
VerifyThis 2018 consisted of three increasingly difficult verification challenges, selected to showcase various aspects of software verification. Eleven teams (one or two participants) took part in the competition. A full report on the VerifyThis 2018 event [39] provides a presentation of the competing teams, a description of the challenges, a highlevel overview of the solutions, and the results of the competition.
 Proof automation with the Coq proof assistant

Proof assistants based on Type Theory, such as Coq, allow the implementation of effective automatic tactics based on computational reflection. These are usually limited to a particular mathematical domain (such as linear arithmetic or ring theory). In contrast, SMTCoq is a modular and extensible tool, using external provers, which generalizes these computational approaches to combine the reasoning from multiple domains. For this, it is based on a highlevel interface, which offers greater expressiveness, at the cost of more complex automation. Q. Garchery and his coauthors [22] focused on two improvements: the ability to use quantified lemmas, and the ability to use multiple representations of the same data structure. They realized a new automatic tactic, based on SMTCoq, that is expressive while keeping the modularity and the efficiency of the latter. Such a tactic thus enable scalable, lowcost automation of new domains supported by stateoftheart automatic provers.
 Certificates for Logic Transformations

In a context of formal program verification, using automatic provers, the trusted code base of verification environments is typically very broad. An environment such as Why3 implements many complex procedures: generation of verification conditions, logical transformations of proof tasks, and interactions with external provers. Considering only the logical transformations of Why3, their implementation already amounts to more than 17,000 lines of OCaml code. In order to increase our confidence in the correction of such a verification tool, Garchery, Keller, Marché and Paskevich present [32] proposed a mechanism of certifying transformations, producing certificates that can be validated by an external tool, according to the skeptical approach. They explored two methods to validate certificates: one based on a dedicated verifier developed in OCaml, the other based on the universal proof checker Dedukti. A specificity of their certificates is to be “small grains” and composable, which makes the approach incremental, allowing to gradually add new certifying transformations.
 Reasoning About Universal Cubes in MCMT

The Model Checking Modulo Theories (MCMT) framework is a powerful model checking technique for verifying safety properties of parameterized transition systems. In MCMT, logical formulas are used to represent both transitions and sets of states and safety properties are verified by an SMTbased backward reachability analysis. To be fully automated, the class of formulas handled in MCMT is restricted to cubes, i.e. existentially quantified conjunction of literals. While being very expressive, cubes cannot define properties with a global termination condition, usually described by a universally quantified formula. In this work, S. Conchon and M. Roux describe BRWP, an extension of the backward reachability of MCMT for reasoning about validity properties expressed as universal cubes, that is formulas of the form $\exists i\forall j.C(i,j)$, where $C(i,j)$ is a conjunction of literals. Their approach consists in a tight cooperation between the backward reachability loop and a deductive verification engine based on weakestprecondition calculus (WP). To provide evidence for the applicability of this new algorithm, they show how to make the model checker Cubicle cooperate with Why3 [25].
 A Generalized Program Verification Workflow Based on Loop Elimination and SA Form.

C. Lourenço, together with Maria Frade and Jorge Sousa Pinto from Universidade do Minho, developed a minimal model of the functioning of program verification and property checking tools based on (i) the encoding of loops as noniterating programs, either conservatively, making use of invariants and assume/assert commands, or in a bounded way; and (ii) the use of an intermediate singleassignment (SA) form. The model captures the basic workflow of tools like Boogie, Why3, or CBMC, building on a clear distinction between operational and axiomatic semantics. This allows one to consider separately the soundness of program annotation, loop encoding, translation into SA form, and verification condition (VC) generation, as well as appropriate notions of completeness for each of these processes. To the best of our knowledge, this is the first formalization of a bounded model checking of software technique, including soundness and completeness proofs using Hoare logic; they also give the first completeness proof of a deductive verification technique based on a conservative encoding of invariantannotated loops with assume/assert in SA form, as well as the first soundness proof based on a program logic. [21]