:

. To (dis)prove termination of C programs, AProVE uses symbolic execution to transform the program’s LLVM code into an integer transition system, which is then analyzed by several backends. The transformation steps in AProVE and the tools in the backend only produce sub-proofs in their domains. Hence, we now developed new techniques to automatically combine the essence of these proofs. If non-termination is proved, then they yield an overall witness, which identi(cid:28)es a non-terminating path in the original C program.


Verication Approach and Software Architecture
To prove (non-)termination of a C program, AProVE uses the Clang compiler [7] to translate it to the intermediate representation of the LLVM framework [15]. Then AProVE symbolically executes the LLVM program and uses abstraction to obtain a nite symbolic execution graph (SEG) containing all possible program runs. We refer to [14,17] for further details on our approach to prove termination.
To prove non-termination, AProVE runs three approaches in parallel, see Fig. 1. The rst two approaches transform the lassos of the SEG to integer transition systems (ITSs), which are then passed to the tools T2 [6] and LoAT [11]. If one of the tools returns a proof of non-termination, AProVE uses it to construct a non-terminating path through the C program. The path of the rst succeeding approach is returned to the user while all other computations are stopped.
T2's proof consists of a recurrent set characterizing those variable assignments that lead to a non-terminating ITS run. Here, AProVE uses an SMT solver to identify a corresponding concrete assignment of the variables in the ITS (which correspond to the variables in the (abstract) program states of the SEG). The third approach transforms the lassos of the SEG directly to SMT formulas which are only satisable if there is a non-terminating path, and in this case, we can deduce a variable assignment from the model of the formulas returned by the solver. While the rst and the third approach were already available in AProVE before [13], we now extended them by the generation of non-termination witnesses. To this end, the variable assignment obtained from these approaches To handle such programs as well, we now developed a novel second approach for proving non-termination which uses our tool LoAT in the backend. To understand how LoAT nds non-termination proofs, consider the function f in Fig. 2. The rst loop decrements x as long as x is positive and increments y by the same amount. Afterwards, the second loop does not terminate if y is greater than 1.
Hence, the function f does not terminate if the initial value of the parameter x is greater than 1. LoAT can detect such coherences in the corresponding ITS (Fig. 3a) generated by AProVE. To this end, LoAT uses dierent forms of loop acceleration: Consequently, the corresponding concrete execution path includes two iterations of the rst loop before reaching the non-terminating second loop.
Once the path is constructed, AProVE extracts the LLVM program positions from the states, obtaining a non-terminating path through the LLVM program in form of a lasso. Using the Clang debug information output, AProVE then matches the LLVM lines to the lines in the C program. The resulting C witness can be validated by the tools CPAchecker [5] and Ultimate Automizer [12].

Discussion of Strengths and Weaknesses
In general, AProVE is especially powerful on programs where a precise modeling of the values of program variables and memory contents is needed to (dis)prove termination. However, on large programs containing many variables which are not relevant for termination, tools with CEGAR-based approaches are often faster. The reason is that AProVE does not implement any techniques to decide which variables are relevant for (non-)termination.
Furthermore, one of AProVE's most crucial weaknesses when proving nontermination in past editions of SV-COMP was to produce a meaningful witness. Therefore, in the two approaches for proving non-termination in AProVE that are based on T2 or on the direct analysis of lassos of the SEG, we added the novel techniques presented in the current paper to generate non-termination witnesses from the obtained variable assignments. Here, the problem is that when computing a concrete execution path, we cannot be sure when to stop the computation: Whenever we visit a program position repeatedly, we do not know if this position is part of the non-terminating loop of the lasso, or if it is still part of the nite path to the non-terminating loop.
In contrast, in our new approach based on LoAT, the simplication tree allows us to infer the order in which the loops of the program are traversed and this tree also contains the information which loop is the non-terminating one.
Thus, this approach extends AProVE's power substantially, since it can nd non-termination witnesses for programs where all non-terminating paths lead through several iterations of more than one loop. On the other hand, there are also examples where the other two approaches outperform the approach based on LoAT, e.g., if T2 nds a non-termination proof and LoAT does not. Our observation is that especially for small programs containing only a single loop, the other approaches are often faster. This is also conrmed by our results in the Termination category of SV-COMP 2022 : While in the sub-categories MainControlFlow and MainHeap, 83% of the non-termination proofs are found using T2 or the direct SMT approach, in Termination-Other, 95% of the non-termination proofs result from the LoAT approach. This set consists of especially large programs, which often contain more than one loop.
More information about SV-COMP 2022 including the competition results can be found in the competition report [3].

Setup and Conguration
AProVE is developed in the Programming Languages and Verication group headed by J. Giesl at RWTH Aachen University. On the web site [2], AProVE can be downloaded or accessed via a web interface. Moreover, [2] also contains a list of external tools used by AProVE and a list of present and past contributors.
In SV-COMP 2022, AProVE only participates in the category Termination.
All les from the submitted archive must be extracted into one folder. AProVE is implemented in Java and needs a Java 11 Runtime Environment. Moreover, AProVE requires the Clang compiler [7] to translate C to LLVM. To analyze the resulting ITSs in the backend, AProVE uses LoAT [11] and T2 [6]. Furthermore, it applies the satisability checkers Z3 [8], Yices [9], and MiniSAT [10] in parallel (our archive contains all these tools). As a dependency of T2, Mono [16] (version ≥ 4.0) needs to be installed. Extending the path environment is necessary so that AProVE can nd these programs. Using the wrapper script aprove.py in the BenchExec repository, AProVE can be invoked, e.g., on the benchmarks dened in aprove.xml in the SV-COMP repository. The most recent version of AProVE with the improved witness generation can be downloaded at [1]. Data Availability Statement. All data of SV-COMP 2022 are archived as described in the competition report [3] and available on the competition web site. This includes the verication tasks, results, witnesses, scripts, and instructions for reproduction. The version of our verier as used in the competition is archived together with other participating tools [4].