1 Introduction
The goal of program synthesis is to find a program in some search space that meets a specification—e.g., satisfies a set of examples or a logical formula. Recently, a large family of synthesis problems has been unified into a framework called syntaxguided synthesis (SyGuS). A SyGuS problem is specified by a regulartree grammar that describes the search space of programs, and a logical formula that constitutes the behavioral specification. Many synthesizers now support a specific format for SyGuS problems [1], and compete in annual synthesis competitions [2]. Thanks to these competitions, these solvers are now quite mature and are finding a wealth of applications [9].
Consider the SyGuS problem to synthesize a function that computes the maximum of two variables and , denoted by . The goal is to create —an expressiontree for —where is in the language of the following regulartree grammar :
and is valid, where denotes the meaning of , and
SyGuS solvers can easily find a solution, such as
Although many solvers can now find solutions efficiently to many SyGuS problems, there has been effectively no work on the much harder task of proving that a given SyGuS problem is unrealizable—i.e., it does not admit a solution. For example, consider the SyGuS problem , where is the more restricted grammar with ifthenelse operators and conditions stripped out:
This SyGuS problem does not have a solution, because no expression generated by meets the specification.^{1}^{1}1Grammar only generates terms that are equivalent to some linear function of and ; however, the maximum function cannot be described by a linear function. However, to the best of our knowledge, current SyGuS solvers cannot prove that such a SyGuS problem is unrealizable.^{2}^{2}2The synthesis problem presented above is one that is generated by a recent tool called QSyGuS, which extends SyGuS with quantitative syntactic objectives [10]. The advantage of using quantitative objectives in synthesis is that they can be used to produce higherquality solutions—e.g., smaller, more readable, more efficient, etc. The synthesis problem arises from a QSyGuS problem in which the goal is to produce an expression that (i) satisfies the specification , and (ii) uses the smallest possible number of ifthenelse operators. Existing SyGuS solvers can easily produce a solution that uses one ifthenelse operator, but cannot prove that no better solution exists—i.e., is unrealizable.
A key property of the previous example is that the grammar is infinite. When such a SyGuS problem is realizable, any search technique that systematically explores the infinite search space of possible programs will eventually identify a solution to the synthesis problem. In contrast, proving that a problem is unrealizable requires showing that every program in the infinite search space fails to satisfy the specification. This problem is in general undecidable [6]. Although we cannot hope to have an algorithm for establishing unrealizability, the challenge is to find a technique that succeeds for the kinds of problems encountered in practice. Existing synthesizers can detect the absence of a solution in certain cases (e.g., because the grammar is finite, or is infinite but only generate a finite number of functionally distinct programs). However, in practice, as our experiments show, this ability is limited—no existing solver was able to show unrealizability for any of the examples considered in this paper.
In this paper, we present a technique for proving that a possibly infinite SyGuS problem is unrealizable. Our technique builds on two ideas.

We observe that unrealizability can often be proven using finitely many input examples. In IllustrativeExample, we show how the example discussed above can be proven to be unrealizable using four input examples—, , , and .

We devise a way to encode a SyGuS problem over a finite set of examples as a reachability problem in a recursive program . In particular, the program that we construct has an assertion that holds if and only the given SyGuS problem is unrealizable. Consequently, unrealizability can be proven by establishing that the assertion always holds. This property can often be established by a conventional programanalysis tool.
The encoding mentioned in EncodingOfGrammarAndExamples is nontrivial for three reasons. The following list explains each issue, and sketches how they are addressed
1) Infinitely many terms. We need to model the infinitely many terms generated by the grammar of a given synthesis problem .
To address this issue, we use nondeterminism and recursion, and give an encoding such that (i) each nondeterministic path in the program corresponds to a possible expression that can generate, and (ii) for each expression that can generate, there is a path in . (There is an isomorphism between paths and the expressiontrees of )
2) Nondeterminism. We need the computation performed along each path in to mimic the execution of expression . Because the program uses nondeterminism, we need to make sure that, for a given path in the program , computational steps are carried out that mimic the evaluation of for each of the finitely many example inputs in .
We address this issue by threading the expressionevaluation computations associated with each example in through the same nondeterministic choices.
3) Complex Specifications. We need to handle specifications that allow for nested calls of the programs being synthesized.
For instance, consider the specification . To handle this specification, we introduce a new variable and rewrite the specification as . Because is now also used as an input to , we will thread both the computations of and through the nondeterministic recursive program.
Our work makes the following contributions:

We reduce the SyGuS unrealizability problem to a reachability problem to which standard programanalysis tools can be applied (IllustrativeExample and verification).

We observe that, for many SyGuS problems, unrealizability can be proven using finitely many input examples, and use this idea to apply the CounterExampleGuided Inductive Synthesis (CEGIS) algorithm to the problem of proving unrealizability (cegis).

We give an encoding of a SyGuS problem over a finite set of examples as a reachability problem in a nondeterministic recursive program , which has the following property: if a certain assertion in always holds, then the synthesis problem is unrealizable (verification).

We implement our technique in a tool nope using the ESolver synthesizer [2] as the SyGuS solver and the SeaHorn tool [8] for checking reachability. nope is able to establish unrealizability for 59 out of 132 variants of benchmarks taken from the SyGuS competition. In particular, nope solves all benchmarks with no more than 15 productions in the grammar and requiring no more than 9 input examples for proving unrealizability. Existing SyGuS solvers lack the ability to prove that these benchmarks are unrealizable, and time out on them.
RelatedWork discusses related work. Some additional technical material, proofs, and full experimental results are given in AdditionalMaterialproofssuppeval, respectively.
2 Illustrative Example
In this section, we illustrate the main components of our framework for establishing the unrealizability of a SyGuS problem.
Consider the SyGuS problem to synthesize a function that computes the maximum of two variables and , denoted by . The goal is to create —an expressiontree for —where is in the language of the following regulartree grammar :
and is valid, where denotes the meaning of , and
SyGuS solvers can easily find a solution, such as
Although many solvers can now find solutions efficiently to many SyGuS problems, there has been effectively no work on the much harder task of proving that a given SyGuS problem is unrealizable—i.e., it does not admit a solution. For example, consider the SyGuS problem , where is the more restricted grammar with ifthenelse operators and conditions stripped out:
This SyGuS problem does not have a solution, because no expression generated by meets the specification.^{3}^{3}3Grammar generates all linear functions of and , and hence generates an infinite number of functionally distinct programs; however, the maximum function cannot be described by a linear function. However, to the best of our knowledge, current SyGuS solvers cannot prove that such a SyGuS problem is unrealizable. As an example, we use the problem discussed in Introduction, and show how unrealizability can be proven using four input examples: , , , and .
width=.75center
3 SyGuS, Realizability, and Cegis
3.1 Background
Trees and Tree Grammars.
A ranked alphabet is a tuple where is a finite set of symbols and associates a rank to each symbol. For every , the set of all symbols in with rank is denoted by . In our examples, a ranked alphabet is specified by showing the set and attaching the respective rank to every symbol as a superscript—e.g., . (For brevity, the superscript is sometimes omitted.) We use to denote the set of all (ranked) trees over —i.e., is the smallest set such that (i) , (ii) if and , then . In what follows, we assume a fixed ranked alphabet .
In this paper, we focus on typed regular tree grammars, in which each nonterminal and each symbol is associated with a type. There is a finite set of types . Associated with each symbol , there is a type assignment , where is called the lefthandside type and are called the righthandside types. Tree grammars are similar to word grammars, but generate trees over a ranked alphabet instead of words.
Definition 1 (Regular Tree Grammar)
A typed regular tree grammar (RTG) is a tuple , where is a finite set of nonterminal symbols of arity 0; is a ranked alphabet; is an initial nonterminal; is a type assignment that gives types for members of ; and is a finite set of productions of the form , where for , each is a nonterminal such that if then .
In a SyGuS problem, each variable, such as and in the example RTGs in Introduction, is treated as an arity symbol—i.e., and .
Given a tree , applying a production to produces the tree resulting from replacing the leftmost occurrence of in with the righthand side . A tree is generated by the grammar —denoted by —iff it can be obtained by applying a sequence of productions to the tree whose root is the initial nonterminal .
SyntaxGuided Synthesis.
A SyGuS problem is specified with respect to a background theory —e.g., linear arithmetic—and the goal is to synthesize a function that satisfies two constraints provided by the user. The first constraint, , describes a semantic property that should satisfy. The second constraint limits the search space of , and is given as a set of expressions specified by an RTG that defines a subset of all terms in .
Definition 2 (SyGuS)
A SyGuS problem over a background theory is a pair where is a regular tree grammar that only contains terms in —i.e., —and is a Boolean formula constraining the semantic behavior of the synthesized program .
A SyGuS problem is realizable if there exists a expression such that is true. Otherwise we say that the problem is unrealizable.
Theorem 3.1 (Undecidability [6])
Given a SyGuS problem , it is undecidable to check whether is realizable.
CounterexampleGuided Inductive Synthesis
The CounterexampleGuided Inductive Synthesis (CEGIS) algorithm is a popular approach to solving synthesis problems. Instead of directly looking for an expression that satisfies the specification on all possible inputs, the CEGIS algorithm uses a synthesizer that can find expressions that are correct on a finite set of examples . If finds a solution that is correct on all elements of , CEGIS uses a verifier to check whether the discovered solution is also correct for all possible inputs to the problem. If not, a counterexample obtained from is added to the set of examples, and the process repeats. More formally, CEGIS starts with an empty set of examples and repeats the following steps:

Call the synthesizer to find an expression such that holds and go to step 2; return unrealizable if no expression exists.

Call the verifier to find a model for the formula , and add to the counterexample set ; return as a valid solution if no model is found.
Because SyGuS problems are only defined over firstorder decidable theories, any SMT solver can be used as the verifier to check whether the formula is satisfiable. On the other hand, providing a synthesizer to find solutions such that holds is a much harder problem because is a secondorder term drawn from an infinite search space. In fact, checking whether such an exists is an undecidable problem [6].
The main contribution of our paper is a reduction of the unrealizability problem—i.e., the problem of proving that there is no expression such that holds—to an unreachability problem (verification). This reduction allows us to use existing (un)reachability verifiers to check whether a SyGuS instance is unrealizable.
3.2 Cegis and Unrealizability
The CEGIS algorithm is sound but incomplete for proving unrealizability. Given a SyGuS problem and a finite set of inputs , we denote with the corresponding SyGuS problem that only requires the function to be correct on the examples in .
Lemma 1 (Soundness)
If is unrealizable then is unrealizable.
Even when given a perfect synthesizer —i.e., one that can solve a problem for every possible set —there are SyGuS problems for which the CEGIS algorithm is not powerful enough to prove unrealizability.
Lemma 2 (Incompleteness)
There exists an unrealizable SyGuS problem such that for every finite set of examples the problem is realizable.
Despite this negative result, we will show that a CEGIS algorithm can prove unrealizability for many SyGuS instances (evaluation).
4 From Unrealizability to Unreachability
In this section, we show how a SyGuS problem for finitely many examples can be reduced to a reachability problem in a nondeterministic, recursive program in an imperative programming language.
4.1 Reachability Problems
A program takes an initial state as input and outputs a final state , i.e., where denotes the semantic function of the programming language. As illustrated in IllustrativeExample, we allow a program to contain calls to an external function nd(), which returns a nondeterministically chosen Boolean value. When program contains calls to nd(), we use to denote the program that is the same as except that takes an additional integer input n, and each call nd() is replaced by a call to a local function nextbit() defined as follows:
In other words, the integer parameter n of formalizes all of the nondeterministic choices made by in calls to nd().
For the programs used in our unrealizability algorithm, the only calls to nd() are ones that control whether or not a production is selected from grammar during a topdown, lefttoright generation of an expressiontree. Given n, we can decode it to identify which expressiontree n represents.
Example 1
Consider again the SyGuS problem discussed in IllustrativeExample. In the discussion of the initial program (cexample0), we hypothesized that the program analyzer chose to report path (LABEL:Eq:PathPlusXOne0) in , for which the sequence of nondeterministic choices is . That sequence means that for , the value of n is (or ). The s, from loworder to highorder position, represent choices of production instances in a topdown, lefttoright generation of an expressiontree. (The s represent rejected possible choices.) The rightmost in n corresponds to the choice in PlusBegin0 of “Start ::= Plus(Start, Start)”; the in the thirdfromrightmost position corresponds to the choice in StartX0 of “Start ::= x” as the left child of the Plus node; and the in the leftmost position corresponds to the choice in StartOne0 of “Start ::= 1” as the right child. By this means, we learn that the behavioral specification holds for the example set for . ∎
Definition 3 (Reachability Problem)
Given a program , containing assertion statements and a nondeterministic integer input n, we use to denote the corresponding reachability problem. The reachability problem is satisfiable if there exists a value that, when bound to n, falsifies any of the assertions in . The problem is unsatisfiable otherwise.
4.2 Reduction to Reachability
The main component of our framework is an encoding enc that given a SyGuS problem over a set of examples , outputs a program such that is realizable if and only if is satisfiable. In this section, we define all the components of , and state the correctness properties of our reduction.
Remark: In this section, we assume that in the specification every occurrence of has as input parameter. We show how to overcome this restriction in complexinvocations. In the following, we assume that the input has type , where could be a complex type—e.g., a tuple type.
Program construction. Recall that the grammar is a tuple . First, for each nonterminal , the program contains global variables of type that are used to express the values resulting from evaluating expressions generated from nonterminal on the examples. Second, for each nonterminal , the program contains a function
We denote by the set of production rules of the form in . The body of funcA has the following structure:
The encoding of a production is defined as follows ( denotes the type of the term ):
Note that if is of arity —i.e., if —the construction yields assignments of the form .
The function interprets the semantics of on the input example. We take Linear Integer Arithmetic as an example to illustrate how works.
We now turn to the correctness of the construction. First, we formalize the relationship between expressiontrees in , the semantics of , and the number n. Given an expressiontree , we assume that each node in is annotated with the production that has produced that node. Recall that is the set of productions with head (where the subscripts are indexes in some arbitrary, but fixed order). Concretely, for every node , we assume there is a function , which associates with a pair that indicates that nonterminal produced using the production (i.e., is the production whose lefthandside nonterminal is ).
We now define how we can extract a number for which the program will exhibit the same semantics as that of the expressiontree . First, for every node in such that , we define the following number:
The number indicates what suffix of the value of n will cause funcA to trigger the code corresponding to production . Let be the sequence of nodes visited during a preorder traversal of expressiontree . The number corresponding to , denoted by
, is defined as the bitvector
.Finally, we add the entrypoint of the program, which calls the function funcS corresponding to the initial nonterminal , and contains the assertion that encodes our reachability problem on all the input examples .
Correctness. We first need to show that the function captures the correct language of expressiontrees. Given a nonterminal , a value , and input values , we use to denote the values of the variables at the end of the execution of with the initial value of and input values . Given a nonterminal , we write to denote the set of terms that can be derived starting with .
Lemma 3
Let be a nonterminal, an expression, and an input set. Then, .
Each procedure that we construct has an explicit dependence on variable n, where n controls the nondeterministic choices made by the funcA and procedures called by funcA. As a consequence, when relating numbers and expressiontrees, there are two additional issues to contend with:
 Nontermination.

Some numbers can cause to fail to terminate. For instance, if the case for “Start ::= Plus(Start, Start)” in program from cexample0 were moved from the first branch (PlusBegin0PlusEnd0) to the final else case (StartZero0), the number would cause Start to never terminate, due to repeated selections of Plus nodes. However, note that the only assert statement in the program is placed at the end of the main procedure. Now, consider a value of such that is satisfiable. reachability implies that the flow of control will reach and falsify the assertion, which implies that terminates. ^{4}^{4}4If the SyGuS problem deals with the synthesis of programs for a language that can express nonterminating programs, that would be an additional source of nontermination, different from that discussed in item Nontermination. That issue does not arise for LIA SyGuS problems. Dealing with the more general kind of nontermination is postponed for future work.
 Shared suffixes of sufficient length.

In TermDecoding, we showed how for program (cexample0) the number corresponds to the topdown, lefttoright generation of Plus(x,1). That derivation consumed exactly seven bits; thus, any number that, written in , shares the suffix —e.g., —will also generate Plus(x,1).
The issue of shared suffixes is addressed in the following lemma:
Lemma 4
For every nonterminal and number n such that (i.e., funcA terminates when the nondeterministic choices are controlled by n), there exists a minimal that is a () suffix of n for which (i) there is an such that , and (ii) for every input , we have .
We are now ready to state the correctness property of our construction.
Theorem 4.1
Given a SyGuS problem over a finite set of examples , the problem is realizable iff is satisfiable.
5 Implementation and Evaluation
nope is a tool that can return twosided answers to unrealizability problems of the form . When it returns unrealizable, no expressiontree in satisfies ; when it returns realizable, some satisfies ; nope can also time out. nope incorporates several existing pieces of software.

The (un)reachability verifier SeaHorn is applied to the reachability problems of the form created during successive CEGIS rounds.

The SMT solver Z3 is used to check whether a generated expressiontree satisfies . If it does, nope returns realizable (along with ); if it does not, nope creates a new input example to add to .
It is important to observe that SeaHorn, like most reachability verifiers, is only sound for unsatisfiability—i.e., if SeaHorn returns unsatisfiable, the reachability problem is indeed unsatisfiable. Fortunately, SeaHorn’s onesided answers are in the correct direction for our application: to prove unrealizability, nope only requires the reachability verifier to be sound for unsatisfiability.
There is one aspect of nope that differs from the technique that has been presented earlier in the paper. While SeaHorn is sound for unreachability, it is not sound for reachability—i.e., it cannot soundly prove whether a synthesis problem is realizable. To address this problem, to check whether a given SyGuS problem is realizable on the finite set of examples , nope also calls the SyGuS solver ESolver [2] to synthesize an expressiontree that satisfies .^{5}^{5}5We chose ESolver because on the benchmarks we considered, ESolver outperformed other SyGuS solvers (e.g., CVC4 [3]).
In practice, for every intermediate problem generated by the CEGIS algorithm, nope runs the ESolver on and SeaHorn on in parallel. If ESolver returns a solution , SeaHorn is interrupted, and Z3 is used to check whether satisfies . Depending on the outcome, nope either returns realizable or obtains an additional input example to add to . If SeaHorn returns unsatisfiable, nope returns unrealizable.
Modulo bugs in its constituent components, nope is sound for both realizability and unrealizability, but because of Lemma 2 and the incompleteness of SeaHorn, nope is not complete for unrealizability.
Benchmarks. We perform our evaluation on 132 variants of the 60 LIA benchmarks from the LIA SyGuS competition track [2]. We do not consider the other SyGuS benchmark track, BitVectors, because the SeaHorn verifier is unsound for most bitvector operations–e.g., bitshifting. We used three suites of benchmarks. LimitedIf (resp. LimitedPlus) contains 57 (resp. 30) benchmarks in which the grammar bounds the number of times an IfThenElse (resp. Plus) operator can appear in an expressiontree to be less than the number required to solve the original synthesis problem. We used the tool Quasi to automatically generate the restricted grammars. LimitedConst
contains 45 benchmarks in which the grammar allows the program to contain only constants that are coprime to any constants that may appear in a valid solution—e.g., the solution requires using odd numbers, but the grammar only contains the constant
. The numbers of benchmarks in the three suites differ because for certain benchmarks it did not make sense to create a limited variant—e.g., if the smallest program consistent with the specification contains no IfThenElse operators, no variant is created for the LimitedIf benchmark. In all our benchmarks, the grammars describing the search space contain infinitely many terms.Our experiments were performed on an Intel Core i7 4.00GHz CPU, with 32GB of RAM, running Lubuntu 18.10 via VirtualBox. We used version 4.8 of Z3, commit 97f2334 of SeaHorn, and commit d37c50e of ESolver. The timeout for each individual SeaHorn/ESolver call is set at 10 minutes.
Experimental Questions. Our experiments were designed to answer the questions posed below.
[ breakable, left=0pt, right=0pt, top=0pt, bottom=1pt, colback=gray!20, colframe=gray!20, width=boxsep=4pt, arc=0pt,outer arc=0pt, ] EQ 1. Can nope prove unrealizability for variants of real SyGuS benchmarks, and how long does it take to do so?
Finding: nope can prove unrealizability for benchmarks. For the benchmarks solved by nope, the average time taken is s. The time taken to perform the last iteration of the algorithm—i.e., the time taken by SeaHorn to return unsatisfiable—accounts for of the total running time.
nope can solve all of the LimitedIf benchmarks for which the grammar allows at most one IfThenElse operator. Allowing more IfThenElse operators in the grammar leads to larger programs and larger sets of examples, and consequently the resulting reachability problems are harder to solve for SeaHorn.
For a similar reason, nope can solve only one of the LimitedPlus benchmarks. All other LimitedPlus benchmarks allow or more Plus statements, resulting in grammars that have at least productions.
nope can solve all LimitedConst benchmarks because these require few examples and result in small encoded programs.
[ breakable, left=0pt, right=0pt, top=0pt, bottom=1pt, colback=gray!20, colframe=gray!20, width=boxsep=4pt, arc=0pt,outer arc=0pt, ] EQ 2. How many examples does nope use to prove unrealizability and how does the number of examples affect the performance of nope? Note that Z3 can produce different models for the same query, and thus different runs of NOPE can produce different sequences of example. Hence, there is no guarantee that NOPE finds a good sequence of examples that prove unrealizability. One measure of success is whether nope is generally able to find a small number of examples, when it succeeds in proving unrealizability.
Finding: Nope used 1 to 9 examples to prove unrealizability for the benchmarks on which it terminated. Problems requiring large numbers of examples could not be solved because either ESolver or SeaHorn timeouts—e.g., on the problem max4, nope gets to the point where the CEGIS loop has generated 17 examples, at which point ESolver exceeds the timeout threshold.
Finding: The number of examples required to prove unrealizability depends mainly on the arity of the synthesized function and the complexity of the grammar. The number of examples seems to grow quadratically with the number of bounded operators allowed in the grammar. In particular, problems in which the grammar allows zero IfThenElse operators require 2–4 examples, while problems in which the grammar allows one IfThenElse operator require 7–9 examples.
Figure 1 plots the running time of nope against the number of examples generated by the CEGIS algorithm. Finding: The solving time appears to grow exponentially with the number of examples required to prove unrealizability.
6 Related Work
The SyGuS formalism was introduced as a unifying framework to express several synthesis problems [1]. Caulfield et al. [6] proved that it is undecidable to determine whether a given SyGuS problem is realizable. Despite this negative result, there are several SyGuS solvers that compete in yearly SyGuS competitions [2] and can efficiently produce solutions to SyGuS problems when a solution exists. Existing SyGuS synthesizers fall into three categories: (i) Enumeration solvers enumerate programs with respect to a given total order [7]. If the given problem is unrealizable, these solvers typically only terminate if the language of the grammar is finite or contains finitely many functionally distinct programs. While in principle certain enumeration solvers can prune infinite portions of the search space, none of these solvers could prove unrealizability for any of the benchmarks considered in this paper. (ii) Symbolic solvers reduce the synthesis problem to a constraintsolving problem [3]. These solvers cannot reason about grammars that restrict allowed terms, and resort to enumeration whenever the candidate solution produced by the constraint solver is not in the restricted search space. Hence, they also cannot prove unrealizability. (iii) Probabilistic synthesizers randomly search the search space, and are typically unpredictable [14], providing no guarantees in terms of unrealizability.
Synthesis as Reachability. CETI [12] introduces a technique for encoding templatebased synthesis problems as reachability problems. The CETI encoding only applies to the specific setting in which (i) the search space is described by an imperative program with a finite number of holes—i.e., the values that the synthesizer has to discover—and (ii) the specification is given as a finite number of inputoutput test cases with which the target program should agree. Because the number of holes is finite, and all holes correspond to values (and not terms), the reduction to a reachability problem only involves making the holes global variables in the program (and no more elaborate transformations).
In contrast, our reduction technique handles search spaces that are described by a grammar, which in general consist of an infinite set of terms (not just values). Due to this added complexity, our encoding has to account for (i) the semantics of the productions in the grammar, and (ii) the use of nondeterminism to encode the choice of grammar productions. Our encoding creates one expressionevaluation computation for each of the example inputs, and threads these computations through the program so that each expressionevaluation computation makes use of the same set of nondeterministic choices.
Using the inputthreading, our technique can handle specifications that contain nested calls of the synthesized program (e.g., ). ( complexinvocations.)
The inputthreading technique builds a product program that perform multiple executions of the same function as done in relational program verification [4]. Alternatively, a different encoding could use multiple function invocations on individual inputs and require the verifier to thread the same bitstream for all input evaluations. In general, verifiers perform much better on product programs [4], which motivates our choice of encoding.
Unrealizability in Program Synthesis. For certain synthesis problems—e.g., reactive synthesis [5]—the realizability problem is decidable. The framework tackled in this paper, SyGuS, is orthogonal to such problems, and it is undecidable to check whether a given SyGuS problem is realizable [6].
Mechtaev et al. [11] propose to use a variant of SyGuS to efficiently prune irrelevant paths in a symbolicexecution engine. In their approach, for each path in the program, a synthesis problem is generated so that if is unrealizable, the path is infeasible. The synthesis problems generated by Mechtaev et al. (which are not directly expressible in SyGuS) are decidable because the search space is defined by a finite set of templates, and the synthesis problem can be encoded by an SMT formula. To the best of our knowledge, our technique is the first one that can check unrealizability of general SyGuS problems in which the search space is an infinite set of functionally distinct terms.
Acknowledgment This work was supported, in part, by a gift from Rajiv and Ritu Batra; by AFRL under DARPA MUSE award FA87501420270 and DARPA STAC award FA875015C0082; by ONR under grant N000141712889; by NSF under grants CNS1763871 and CCF1704117; and by the UWMadison OVRGE with funding from WARF.
References
 [1] R. Alur, R. Bodik, G. Juniwal, M. M. Martin, M. Raghothaman, S. A. Seshia, R. Singh, A. SolarLezama, E. Torlak, and A. Udupa. Syntaxguided synthesis. In Formal Methods in ComputerAided Design (FMCAD), pages 1–8. IEEE, 2013.
 [2] R. Alur, D. Fisman, R. Singh, and A. SolarLezama. Syguscomp 2016: results and analysis. arXiv preprint arXiv:1611.07627, 2016.
 [3] C. Barrett, C. L. Conway, M. Deters, L. Hadarean, D. Jovanović, T. King, A. Reynolds, and C. Tinelli. Cvc4. In International Conference on Computer Aided Verification, (CAV), pages 171–177. SpringerVerlag, 2011.
 [4] G. Barthe, J. M. Crespo, and C. Kunz. Relational verification using product programs. In International Symposium on Formal Methods (FM), pages 200–214. Springer, 2011.
 [5] R. Bloem. Reactive synthesis. In Formal Methods in ComputerAided Design (FMCAD), pages 3–3, 2015.
 [6] B. Caulfield, M. N. Rabe, S. A. Seshia, and S. Tripakis. What’s decidable about syntaxguided synthesis? arXiv preprint arXiv:1510.08393, 2015.
 [7] ESolver. https://github.com/abhishekudupa/syguscomp14.
 [8] A. Gurfinkel, T. Kahsai, and J. A. Navas. SeaHorn: A framework for verifying C programs (competition contribution). In Tools and Algorithms for the Construction and Analysis of Systems (TACAS), pages 447–450, 2015.
 [9] Q. Hu and L. D’Antoni. Automatic program inversion using symbolic transducers. In Proceedings of the 38th ACM SIGPLAN Conference on Programming Language Design and Implementation, (PLDI), pages 376–389, 2017.
 [10] Q. Hu and L. D’Antoni. Syntaxguided synthesis with quantitative syntactic objectives. In Computer Aided Verification  30th International Conference, (CAV), pages 386–403, 2018.
 [11] S. Mechtaev, A. Griggio, A. Cimatti, and A. Roychoudhury. Symbolic execution with existential secondorder constraints. In Proceedings of the 2018 26th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering (ESEC/FSE), pages 389–399, 2018.
 [12] T. Nguyen, W. Weimer, D. Kapur, and S. Forrest. Connecting program synthesis and reachability: Automatic program repair using testinput generation. In A. Legay and T. Margaria, editors, Tools and Algorithms for the Construction and Analysis of Systems (TACAS), pages 301–318, 2017.
 [13] H. Qinheping, B. Jason, C. John, D. Loris, and T. Reps. Proving unrealizability for syntaxguided synthesis. arXiv preprint arXiv:1905.05800, 2019.
 [14] E. Schkufza, R. Sharma, and A. Aiken. Stochastic program optimization. Commun. ACM, 59(2):114–122, 2016.
Appendix 0.A Additional Material
0.a.1 Encoding in the Presence of Nested FunctionInvocations
In EncodingAlgorithm, we presented a simplified encoding that relied on the specification to only involve function invocations of the form , where represents the input parameter of the function to be synthesized. In this section, we show with a simple example how such a restriction can be overcome.
Consider the following semantic specification that involves multiple invocations of the function on different arguments, as well as nested function calls:
By introducing new input variables and performing the proper refactoring, we can rewrite as the following specification, where is always called on a single input variable:
It is now easy to adapt our encoding to operate over this new specification. First, the program will now operate over input examples of the form , where each example is a tuple corresponding to the values of variables . Second, the program will need to compute the values of all possible calls of on the various input parameters. Hence, for every expression in
Comments
There are no comments yet.