Spurious or Genuine? Evaluating Large Language Models in Validating Counterexamples for Loop Invariant Inference

Abstract

Whether a counterexample is genuine or spurious fundamentally influences the effectiveness and completeness of loop invariant inference, which is a core component of automated program verification. However, reliably determining the validity of a counterexample remains a challenging task. In this paper, we present a systematic evaluation of large language models (LLMs) on this problem. We construct a benchmark of program states that serve as counterexamples, categorized into three representative types: (i) pre-states of inductive counterexamples derived from LLM-proposed invariants and (ii–iii) boundary states derived from correct inductive invariants, where the states themselves either violate (ii) or satisfy (iii) the program’s precondition. Ground-truth labels are established using a state-of-the-art program verifier. We evaluate multiple LLMs under diverse prompting strategies. Our results show that LLMs perform well on the first two types of counterexamples in the benchmark but poorly on the third. Moreover, LLMs are substantially more accurate in classifying spurious counterexamples than genuine ones. These findings offer valuable guidance for future research on LLM-assisted loop invariant inference.

1. Introduction

Program verification plays a pivotal role in ensuring software reliability and preventing runtime bugs. At its core is the inference of loop invariants, which are predicates that hold before and after each iteration of the loop. A wide range of techniques have been developed for this purpose, such as counterexample-guided abstraction refinement (CEGAR) [1,2], abstract interpretation [3,4], recurrence analysis [5,6,7], logical abduction [8], interpolation [9,10,11], template-based approaches [12,13], and ICE-based approaches [14,15,16,17,18,19,20,21]. Among these, ICE-based approaches assisted with large language models (LLMs) have recently demonstrated remarkable success [22,23].

ICE-based methods iteratively enumerate candidate invariants and verify them using an SMT solver. When verification fails, the solver returns a counterexample, which is then used to guide the filtering of candidates in subsequent iterations. However, these methods do not determine whether an inductive counterexample is genuine or spurious, that is, whether its pre-state is reachable during concrete program execution [2]. This limitation impairs their ability to effectively filter candidate invariants [24].

On the other hand, from the perspective of invariant precision, developers seek invariants that are not only sound but ideally complete, as completeness enables a full characterization of program behavior. A complete loop invariant must include all program states that are reachable during execution, which correspond to genuine counterexamples, and exclude all unreachable states, which manifest as spurious counterexamples [25]. Consequently, validating counterexamples to eliminate spurious instances is essential for refining inferred invariants and improving their precision [2].

Yet determining the genuineness of a counterexample remains highly challenging. Validating counterexamples, whether those generated by ICE-based synthesis or those used for completeness checking, reduces to a concrete state reachability problem, which is undecidable in general due to its equivalence to the halting problem—a classic undecidable problem established by Turing [2].

In this paper, motivated by the strong program-understanding capabilities of large language models (LLMs), we investigate their ability to distinguish whether a given program counterexample is genuine or spurious. To this end, based on a standard C program benchmark, we first constructed a counterexample benchmark, named CE-Bench, by leveraging execution logs from LaM4Inv [22], a state-of-the-art LLM-assisted ICE-based loop invariant inference tool. To cover both inductive verification and invariant completeness scenarios, CE-Bench comprises the following three types of counterexamples:

• Pre-states of inductive counterexamples obtained during inductiveness checks of candidate invariants generated by LLMs.
• Boundary states that satisfy the inferred loop invariant but violate the program precondition, representing boundary inputs of loop execution.
• Boundary states that satisfy both the inferred loop invariant and the program precondition, representing reachable edge cases of loop execution.

We then employ Ultimate Automizer, a state-of-the-art model-checking-based program verifier, to validate all counterexamples and assign ground-truth labels. This yields a labeled benchmark, which we call CE-Bench, covering 300 programs and containing 1936 counterexamples in total. Using CE-Bench, we evaluate six LLMs: GPT-5.2, GPT-4o-mini, DeepSeek-V3.2, and Qwen2.5 with 7B, 14B, and 32B parameters, under three prompting strategies: chain-of-thought (CoT) [26], zero-shot, and one-shot. Our experiments reveal the following key findings:

• Both cloud-scale models and larger local models achieve considerable accuracy, with zero-shot prompting consistently outperforming CoT and one-shot variants.
• LLMs exhibit high accuracy on inductive counterexamples and boundary states that violate the precondition, but struggle significantly on boundary states that satisfy the precondition.
• LLMs are notably more accurate in identifying spurious counterexamples than genuine ones, suggesting a systematic bias toward over-approximation in their reasoning about program reachability.

These findings not only reveal the current strengths and limitations of LLMs in counterexample validation but also provide actionable guidance for integrating LLMs into symbolic loop invariant inference workflows.

In summary, the main contributions of this paper include:

• The construction of CE-Bench, the first labeled benchmark for evaluating the genuineness of program counterexamples, which distinguishes between genuine and spurious instances.
• A comprehensive evaluation of six large language models under three popular prompting strategies across three distinct classes of counterexamples.
• Empirical findings that provide insights to inspire future research on LLM-assisted loop invariant inference.

2. Preliminary

This section introduces the foundational concepts and background necessary for understanding this paper, including loop invariant inference, the ICE-based method, and the state-of-the-art LLM-assisted loop inference tool LaM4Inv [22].

2.1. Loop Invariant Generation

Consider a while loop of the form while   B   do   S. The goal of loop invariant inference in Hoare logic [27]-based deductive verification is to find a predicate I over program variables such that the following three conditions hold:

$$\frac{P\Rightarrow I\{I\wedge B\}S\left\{I\right\}(I\wedge \neg B)\Rightarrow Q}{\left\{P\right\}\mathrm{while}B\mathrm{do}S\left\{Q\right\}}$$

(1)

where P is the pre-condition before the loop, Q is the desired post-condition after the loop, and S the loop body guarded by condition B. Essentially, Equation (1) includes the following three requirements that a loop invariant I must satisfy:

• initialization: Every program state that can be reached at the loop entry, i.e., after executing the code preceding the loop under the pre-condition P, must satisfy the invariant I. This ensures that I holds when the loop starts.
• inductiveness: For any program state that satisfies both I and the loop guard B, the execution of the loop body S must result in a successor state that also satisfies I. This guarantees that I is preserved across all iterations of the loop.
• provability: Any program state satisfying I and the negation of the loop guard $\neg B$ must imply the desired post-condition Q. This ensures that the specification is fulfilled upon loop termination.

In this context, a program state is defined as a total valuation of all program variables, and an execution corresponds to a finite or infinite sequence of state transitions induced by the program semantics.

2.2. ICE-Based Method

The ICE framework [14] infers loop invariants through an iterative guess-and-check process. In each iteration, a candidate invariant I is proposed and validated against the three Hoare-style conditions in Equation (1) using an SMT solver such as Z3 [28]. The solver checks the following formula:

$$\neg (P\Rightarrow I)\vee \neg (I\wedge B\wedge S\Rightarrow I^{\prime })\vee \neg (I\wedge \neg B\Rightarrow Q),$$

(2)

where $I^{\prime }$ denotes the evaluation of the invariant after executing the loop body S. If verification fails, the solver returns a counterexample that violates one of the three required conditions. These counterexamples are used to refine the next candidate invariant as follows:

• If the counterexample violates the initialization condition (i.e., it is reachable from the pre-condition but does not satisfy the candidate), the new candidate must hold on this state.
• If the counterexample violates the provability condition (i.e., it satisfies the candidate invariant and the loop exit condition $\neg B$, but does not satisfy the post-condition Q), the new candidate must evaluate to false on this state.
• If the counterexample violates the inductiveness condition, it consists of a pair of states $(i_1,i_2)$ such that $i_1$ satisfies the candidate and the loop guard B, $i_2$ results from executing the loop body S from $i_1$, yet $i_2$ does not satisfy the candidate. In this case, the new candidate must either be false on $i_1$ or true on both $i_1$ and $i_2$. We refer to $i_1$ as the pre-state and $i_2$ as the post-state of the inductive counterexample.

Notably, counterexamples violating the initialization condition are necessarily genuine, as they satisfy the pre-condition P and are therefore reachable at loop entry. Conversely, counterexamples violating the provability condition are inherently spurious, because any state that satisfies $I\wedge \neg B$ but not the post-condition Q cannot arise in a correct program execution. In contrast, counterexamples violating the inductiveness condition may be either genuine or spurious, depending on whether their pre-state is concretely reachable during program execution. Critically, the ICE framework provides no mechanism to determine the genuineness of such inductive counterexamples.

2.3. LLM-Assisted Loop Invariant Inference via LaM4Inv

Building upon the ICE framework, LaM4Inv [22] leverages LLMs to generate candidate loop invariants. Each candidate is first decomposed into several components according to its logical structure. These components are then individually validated using bounded model checking [29]. LaM4Inv constructs a final candidate invariant in conjunctive normal form (CNF) by conjoining all verified components and checks whether it satisfies the three Hoare-style conditions for a valid loop invariant. If verification fails, the system extracts the violated condition and uses it as feedback to prompt the LLM to generate additional candidate invariants, repeating the process iteratively until a correct invariant is found or a timeout is reached.

3. Methodology

In this section, we describe the construction of CE-Bench, our benchmark for counterexample genuineness validation. We first detail the methodology for collecting representative counterexamples from LLM-assisted invariant inference. We then explain how ground-truth labels are assigned using rigorous model checking. Finally, we present key statistics and balance characteristics of the resulting benchmark.

3.1. Counterexample Collection

Our goal is to construct a diverse and representative set of counterexamples that reflect the core challenges in LLM-assisted loop invariant inference. To this end, we focus on two complementary aspects: (i) the effectiveness of invariant generation, which motivates our inclusion of inductive counterexamples, and (ii) the completeness of the inferred invariant, which leads us to collect boundary states that probe the limits of the candidate invariant.

3.1.1. Effectiveness Related Counterexamples

ICE-based methods have achieved remarkable success when enhanced with large language models (LLMs) [22,23]. In the LaM4Inv [22] benchmark—a newly introduced suite of 316 C programs—LaM4Inv successfully verifies 309 instances, substantially outperforming prior ICE-based approaches that rely on traditional machine learning techniques [18,20,21]. This progress underscores the potential of LLMs to improve the effectiveness of invariant generation within the ICE framework. However, as discussed in Section 2, the ICE framework cannot determine whether an inductive counterexample is genuine or spurious. This inherent ambiguity can mislead learning procedures and hinder convergence. To address this challenge, we explicitly include inductive counterexamples in our benchmark: they serve as critical test cases for evaluating whether an LLM-assisted method can correctly interpret and resolve the validity of such counterexamples. Consequently, the ability to handle inductive counterexamples becomes a key criterion for assessing the robustness and reasoning capability of LLM-enhanced invariant inference.

To obtain these counterexamples, we leverage the execution logs of LaM4Inv [22] on its standard benchmark. These logs contain not only the sequence of LLM-generated candidate invariants at each iteration but also the final verified invariant (if verification succeeds). We extract the raw LLM-generated invariants directly from the logs without applying LaM4Inv’s internal combination heuristics. This preserves the LLM’s original reasoning behavior. Crucially, each candidate is generated under feedback from prior verification failures, such as a reported failure of the inductiveness condition. As a result, the sequence of invariants is more authentic and representative than those obtained by repeatedly querying the LLM in isolation. Using these unprocessed candidates, we re-run the verification by SMT solver Z3 to collect all pre-states of inductive counterexamples produced during the inference process.

Example 1.

For the original program from the benchmark of [22] in Figure 1, suppose an ICE-based loop invariant inference method proposes the candidate invariant $i\ge -1$. This candidate satisfies the initialization condition but violates the inductiveness condition, as the SMT solver returns an inductive counterexample $(i_1=-1,i_2=-2)$. In the subsequent guess-and-check iteration, a naive refinement strategy might require that if $-1$ is included in the new candidate invariant, then $-2$ must also be included to satisfy inductiveness. However, this approach fails to exploit the counterexample fully. Indeed, the reported counterexample is spurious: the value $i=-1$ is unreachable under the program’s pre-condition and control flow, and thus can never occur during actual execution. Leveraging this insight, we can safely exclude $i=-1$ from all future candidate invariants. Doing so not only eliminates a source of spurious feedback but also accelerates convergence by pruning infeasible regions of the hypothesis space.

Figure 1. Original program and instrumented versions for three counterexample cases.

3.1.2. Completeness Related Counterexamples

The completeness of a loop invariant refers to whether the inferred invariant precisely captures all and only those program states that are actually reachable during execution—without over-approximating by including states that can never occur in practice. For non-convex invariants, completeness can often be assessed by examining boundary states, i.e., extremal valuations of program variables that satisfy the invariant. Even for non-convex invariants, such boundary states provide valuable evidence regarding completeness: if a boundary state violates the program’s pre-condition or is otherwise unreachable, it indicates that the invariant is overly general and includes spurious regions of the state space.

To capture boundary cases related to invariant completeness, we further collect two types of concrete program states derived from the final verified invariant (when available): (i) States that violate the program’s pre-condition P, reflecting potential over-approximation in the invariant; (ii) States that satisfy P and the loop condition B, representing boundary inputs that can let the loop execute. These states help assess how well the invariant aligns with the actual reachable state space.

For boundary states, we take the final verified invariant I output by LaM4Inv and use an Optimization Modulo Theories (OMT) solver, e.g., Z3 [30], to generate concrete program states that push individual variables to their extremal values under given constraints. Specifically, for each program variable $v_i\in V=\{v_1,\dots ,v_n\}$, we solve two optimization problems:

$$\begin{array}{cc}\hfill & \mathrm{Maximize}{v}_i\mathrm{subject}\mathrm{to}I\wedge C\hfill \end{array}$$

(3)

$$\begin{array}{cc}\hfill & \mathrm{Minimize}{v}_i\mathrm{subject}\mathrm{to}I\wedge C\hfill \end{array}$$

(4)

where C denotes additional constraints based on the counterexample type: (i) for OMT_UNSAT_Pre_CEs is $C=\neg P$ and (ii) for OMT_SAT_Pre_CEs is $C=P\wedge B$.

Each OMT query returns a complete model, a full assignment to all variables in V, that satisfies $I\wedge C$ and achieves the optimal value for $v_i$. Crucially, the semantics of these two categories differ:

For OMT_SAT_Pre_CEs, the constraint $P\wedge B$ ensures that the generated state lies within the program’s initial state space (as defined by the concrete precondition P) and satisfies the loop guard. Since such states represent valid loop-entry configurations, they are genuine by construction, i.e., dynamically reachable without any loop iterations.

In contrast, OMT_UNSAT_Pre_CEs are constructed to violate P. Although they satisfy the inferred invariant I, they may fall outside the program’s concrete reachable states and are therefore spurious. Their purpose is to expose potential over-approximation in I: if the verifier accepts such a state as feasible, it would indicate a flaw in I; otherwise, they serve as negative probes for completeness.

This construction provides a computationally efficient way to generate boundary cases that directly test whether the inferred invariant aligns with the true reachable state space at the loop entry point.

Overall, we organize the counterexamples in CE-Bench into the following three categories, which we refer to as follows:

• Inductive_CEs: pre-states of inductive counterexamples from failed inductiveness checks.
• OMT_UNSAT_Pre_CEs: boundary states derived from the invariant and violating the pre-condition.
• OMT_SAT_Pre_CEs: boundary states derived from the invariant and satisfying the pre-condition and loop condition.

Example 2.

For the original program in Figure 1, LaM4Inv[22] successfully generates a correct candidate invariant, namely,$i\ge 0$. However, this invariant is overly weak: it permits i to take arbitrarily large values, up to the language-defined upper bound INT_MAX, even though the actual maximum value of i observed during loop execution is only 200. This illustrates that even a correct inductive invariant can still be highly imprecise. To characterize such imprecision, we consider two kinds of boundary states derived from the invariant: (i) The extremal state where i attains its maximal value allowed by the invariant (i.e., i = INT_MAX), which represents a worst-case over-approximation; (ii) A concrete boundary input such as $i=1$, which satisfies both the pre-condition and the loop guard, and thus corresponds to a feasible entry point into the loop.

3.2. Ground Truth Labeling

Determining whether a counterexample is genuine is equivalent to checking whether the corresponding program state is concretely reachable. This problem is theoretically undecidable and remains highly challenging in practice. Nevertheless, it can be cast as a standard program verification task. Specifically, we first construct an instrumented version of the program tailored to the counterexample type, then apply established verification tools to check the validity of the inserted assertion—thereby determining whether the counterexample is genuine or spurious.

3.2.1. Instrumentation Strategy by Counterexample Type

Given a counterexample for a program, we begin by removing the original post-condition. We then negate the concrete state described by the counterexample to form an assertion and insert it into the program at a location that reflects the semantic role of the counterexample. The placement varies by counterexample type, as each category corresponds to a distinct phase of loop execution:

• For Inductive_CEs, we place the assertion immediately before the first statement inside the loop body because these counterexamples represent concrete program states just prior to loop-body execution.
• For OMT_UNSAT_Pre_CEs, we insert the assertion right after the last statement of the loop body because they correspond to the final reachable states before the loop terminates.
• For OMT_SAT_Pre_CEs, we embed the assertion immediately before the first statement inside the loop body because these states satisfy both the pre-condition and the loop condition.

Example 3.

Consider the program in Figure 1. We illustrate our instrumentation strategy using three representative counterexamples: (i)  $i=-1$ from Inductive_CEs, (ii) i = INT_MAX from OMT_UNSAT_Pre_CEs , and (iii) $i=1$ from OMT_SAT_Pre_CEs. The corresponding instrumented programs are shown in the last three subfigures in Figure 1, respectively.

3.2.2. Validating Counterexample by Program Verification

Although numerous program verification techniques exist, careful consideration is required when selecting an appropriate method to validate the instrumented programs described above, since the soundness and precision of the chosen verifier directly affect the reliability of counterexample genuineness judgments.

• Abstract Interpretation [3,4] performs sound but over-approximate static analysis. It can prove that an assertion never fails (i.e., the state is unreachable), thereby confirming the counterexample as spurious. However, if the analysis reports a potential violation, it cannot distinguish between a true bug and an artifact of abstraction imprecision. Consequently, abstract interpretation alone cannot confirm genuine counterexamples.
• Bounded Model Checking (BMC) [29] and Symbolic Execution [31] explore executions up to a fixed depth using SMT solvers. They are precise: any reported assertion violation corresponds to a concrete, executable trace, thus certifying the counterexample as genuine. Yet, when no violation is found within the bounds, they provide no guarantee about deeper or unbounded behaviors—making them unable to conclusively classify a counterexample as spurious, especially in the presence of loops.
• Unbounded Software Model Checking [32], exemplified by tools like Ultimate Automizer [33], aims to decide reachability without artificial bounds. By integrating counterexample-guided abstraction refinement (CEGAR) [1,2], interpolation-based loop summarization [34,35], and automata-theoretic reasoning [36], such tools can often both discover genuine violations and prove assertions safe for unbounded programs.

Given the need for bidirectional classification of counterexamples into genuine or spurious instances and the prevalence of unbounded loops in our benchmark programs, we adopt Ultimate Automizer as our verification backend. It has consistently ranked among the top performers in the Reachability category of SV-COMP [37], demonstrating strong capability in handling real-world loop structures.

We assume that Ultimate Automizer is sound: a TRUE verdict means the safety property holds in all executions, and a FALSE verdict means there exists a concrete counterexample violating it. Under this assumption, we run the tool with a timeout of 100 s per instance, using its default configuration and heuristics without modification. Its output directly determines the ground-truth label of the original counterexample:

• If the tool reports FALSE (i.e., the assertion !(state) is violated along some feasible path), then the counterexample state holds on that path. This means the state is concretely reachable, and the counterexample is classified as genuine.
• If the tool reports TRUE (i.e., the assertion !(state) is proven to hold under all executions), then the counterexample state is unreachable in any concrete execution, and the counterexample is classified as spurious.
• In rare cases of timeout or inconclusive results (i.e., the verifier cannot decide the validity of the assertion !(state)), the reachability of the counterexample state remains undetermined. We conservatively treat such counterexamples as UNKNOWN and exclude them from ground-truth labeling.

For all spurious and genuine cases, we performed manual inspection of a random subset (20) to assess plausibility and found none revealed obvious misclassifications.

Example 4.

Consider the original program in Figure 1 and a counterexample state $i=1$from  OMT_SAT_Pre_CEs. When verified by  Ultimate Automizer, the tool reports  FALSE, producing a concrete trace where $i=1$ holds. This confirms that the state is reachable, and thus the counterexample is classified as genuine.

We note that OMT_SAT_Pre_CEs satisfy the loop precondition and loop guard, and are therefore theoretically genuine. Nevertheless, we apply model checking to validate them for two reasons. First, it ensures a consistent labeling pipeline across all three counterexample types, enabling a fair comparison of their behavior throughout the entire benchmarking workflow. Second, and more importantly, this validation allows us to evaluate how conventional symbolic verifiers handle such theoretically genuine counterexamples. The classification of these instances as genuine is not a trivial task: during evaluation, large language models are not provided with the counterexample’s origin or category, and must reason about its validity solely from the program and state. Moreover, these counterexamples correspond to feasible boundary inputs that are of significant value not only for inductive invariant inference but also for broader areas such as program testing.

Our counterexample validation procedure provides a robust, largely automated pipeline for grounding counterexamples in concrete program semantics, despite the theoretical undecidability of the underlying reachability problem.

3.3. Benchmark Statistics

Figure 2 summarizes the composition of our initial counterexample set, which contains 2488 instances generated as described in Section 3.1 and labeled via the validation procedure in Section 3.2. The counterexamples are grouped into three categories—Inductive_CEs, OMT_UNSAT_Pre_CEs, and OMT_SAT_Pre_CEs—and further classified by verification outcome as genuine, spurious, or UNKNOWN. Across all categories, a total of 552 cases (22.2%) remain undecided, labeled as unknown due to timeouts or inconclusive results from Ultimate Automizer.

Figure 2. Composition of the initial counterexample set by category and verification outcome.

A closer look at the breakdown by category reveals that the difficulty is not uniform across counterexample types. Among the 991 OMT_UNSAT_Pre_CEs, the verifier fails to reach a conclusion on 401 instances (40.5%). This high rate reflects the inherent challenge of synthesizing sufficiently strong inductive invariants for unreachability proofs.

Surprisingly, even for the 882 OMT_SAT_Pre_CEs, which originate from satisfiable preconditions and thus admit concrete executions by construction, Ultimate Automizer still times out or returns inconclusive results on 34 cases (3.9%). The Inductive_CEs category shows a moderate unknown rate of 19.0% (117 out of 615). These statistics demonstrate that automated validation remains difficult across all counterexample types, highlighting a fundamental limitation in the practical completeness of current verification tools.

To enable a reliable evaluation of large language models’ capability in validating counterexamples, we construct our final benchmark by excluding all unknown instances. The resulting CE-Bench consists of 1936 conclusively validated counterexamples: 1025 genuine and 911 spurious. As shown in Figure 2, the majority of these validated cases originate from OMT_SAT_Pre_CEs (848 instances), followed by OMT_UNSAT_Pre_CEs (590) and Inductive_CEs (498).

To investigate whether discarding these UNKNOWN cases in OMT_UNSAT_Pre_CEs introduces selection bias, we analyze their boundary extremal value usage patterns in comparison with retained KNOWN (genuine or spurious) cases within the same category. As shown in Table 1, both sets exhibit substantial overlap in structural characteristics: 72.8% of UNKNOWN cases contain at least one boundary extremal value, compared to 87.5% for retained cases. The proportion of cases with no boundary extremal values is higher among UNKNOWN instances (27.2% vs. 12.5%), but both groups span the full range of boundary extremal usage, from fully extremal to entirely non-extremal assignments. This suggests that the exclusion of UNKNOWN cases does not introduce a severe or systematic bias toward simpler or more complex counterexamples. Nevertheless, we note that the difficulty for traditional symbolic methods (e.g., SMT solvers or model checkers) does not necessarily correlate with the difficulty for large language models; tasks deemed hard or easy by conventional verification tools may not accurately reflect LLM performance patterns.

Table 1. Extremal value usage in OMT_UNSAT_Pre_CEs: KNOWN (GENUINE or SPURIOUS) vs. UNKNOWN.

Extremal Value Usage	KNOWN	UNKNOWN
Total Cases	590	401
All variables are extremal values	14.6%	9.5%
Exactly one variable is a extremal value	43.1%	36.2%
Multiple but not all variables are extremal values	29.8%	27.2%
No variable is a extremal value	12.5%	27.2%

Genuine counterexamples in CE-Bench are especially prevalent in the OMT_SAT_Pre_CEs group, consistent with its derivation from satisfiable preconditions that often reflect real program behaviors. In contrast, spurious counterexamples dominate the other two categories. In Inductive_CEs, they account for 79.3% of the validated cases, and in OMT_UNSAT_Pre_CEs, the proportion rises even higher to 87.5%. This pattern reflects a well-known phenomenon in loop invariant synthesis: spurious counterexamples frequently arise, even when using a highly effective tool such as LaM4Inv. Moreover, almost all correct loop invariants are still not complete.

We further analyze the distribution of counterexamples per program in our final benchmark, as shown in Figure 3. The most common case occurs for 40 programs, each associated with exactly 5 counterexamples, followed by 33 programs with 2 counterexamples and another 33 programs with 4. Most programs have between 2 and 8 counterexamples, while a small number yield substantially more, ranging from 18 to 26. This pattern stems from two key factors. First, LaM4Inv is highly effective: for many programs, it synthesizes a correct loop invariant within only a few iterations, using just a small number of candidate invariants generated by the large language model, which limits the number of Inductive_CEs. Second, since the majority of programs involve only a few variables, the search space for OMT-based counterexamples remains small, resulting in relatively few OMT_SAT_Pre_CEs and OMT_UNSAT_Pre_CEs. Together, these factors lead to a sparse distribution of the counterexamples across programs. Finally, 16 programs have no counterexamples at all, either because LaM4Inv fails to generate a valid invariant or because the SMT solver encounters an error during inductive validation and cannot produce a counterexample.

Figure 3. Distribution of counterexamples per program in CE-Bench.

4. Evaluation

We evaluate the capability of large language models in validating counterexamples from CE-Bench through the following research questions:

• RQ1 (Model Impact): How does the choice of large language model affect counterexample validation performance?
• RQ2 (Prompting Strategy): How does the design of prompting strategies influence counterexample validation performance?
• RQ3 (Counterexample Type Sensitivity): How does validation performance vary across counterexample categories (Inductive_CEs, OMT_SAT_Pre_CEs, OMT_UNSAT_ Pre_CEs)?
• RQ4 (Genuineness Bias): Do large language models exhibit a performance bias toward genuine or spurious counterexamples?

• Models. To answer RQ1, we evaluate six large language models: GPT-5.2, GPT-4o-mini, DeepSeek-V3.2, and three INT4-quantized variants of Qwen2.5 with 7B, 14B, and 32B parameters. The Qwen models are deployed locally via Ollama [38], while the others are accessed through cloud APIs. All models use greedy decoding (temperature = 0) to ensure deterministic outputs. To isolate the effect of model choice, we fix the prompting strategy to zero-shot across all models.
• Prompts. To isolate the effect of prompting design to answer RQ2, we select the best-performing model from RQ1, which achieves the highest overall validation accuracy, and evaluate it under three prompting strategies: (i) zero-shot; (ii) dual-label one-shot, which augments the input with a fixed reference program accompanied by one genuine and one spurious counterexample (each explicitly labeled); and (iii) chain-of-thought (CoT) [26], which prompts step-by-step reasoning before the final judgment. The detailed prompt templates are provided in Appendix A.
• Environment. All the experiments were performed on a machine running Ubuntu 22.04 (64-bit), with 256 GB of RAM, 2 GeForce RTX 3090 GPUs, and a 3.7 GHz 32-core AMD 3970X CPU.

4.1. RQ1: Model Impact

Table 2 and Figure 4 summarize the zero-shot counterexample validation performance of six LLMs on CE-Bench. Overall, model choice has a substantial impact on both accuracy and inference efficiency. Among the quantized open-weight models, scaling from 7B to 32B parameters improves accuracy by over 12 percentage points (from 48.24% to 60.28%), demonstrating clear benefits of increased capacity even under INT4 quantization.

Table 2. Performance of LLMs under zero-shot prompting on CE-Bench.

Model	Correct	Accuracy (%)	Avg. Time (s)
Qwen2.5-7B	934	48.24	0.19
Qwen2.5-14B	963	49.74	0.35
Qwen2.5-32B	1167	60.28	0.71
GPT-4o-mini	1153	59.56	4.57
GPT-5.2	1165	60.18	6.16
DeepSeek-V3.2	1192	61.57	5.39

Figure 4. Comparison of zero-shot validation accuracy of six LLMs.

Surprisingly, the smaller GPT-4o-mini (59.56%) nearly matches the performance of the much larger Qwen2.5-32B (60.28%), highlighting the effectiveness of proprietary training data and optimization. The top-performing model is DeepSeek-V3.2, achieving 61.57% accuracy—slightly outperforming both GPT-5.2 (60.18%) and Qwen2.5-32B.

However, this comes at the cost of significantly higher latency: cloud-based models (GPT-4o-mini, GPT-5.2, DeepSeek-V3.2) take 4.5–6.2 s per query, whereas local Qwen models respond in under 0.71 s. This reveals a clear trade-off between accuracy and inference speed, with open-weight quantized models offering competitive performance at dramatically lower latency.

Despite these differences in scale and architecture, all models struggle to reliably validate counterexamples: even the best performer (DeepSeek-V3.2) correctly classifies only 61.57% of cases. Notably, smaller open-weight models such as Qwen2.5-7B (48.24%) and Qwen2.5-14B (49.74%) perform below random guessing on this binary task, suggesting they largely fail to capture the underlying program semantics. This indicates that current LLMs, while capable of surface-level pattern matching, still lack robust reasoning about program feasibility and execution traces required to consistently distinguish genuine counterexamples from spurious ones. The task remains highly challenging, and accuracy near or below 62% across even the strongest models suggests that LLMs alone are insufficient for high-assurance verification without additional safeguards, such as symbolic execution or integration with formal verification tools.

4.2. RQ2: Prompting Strategy

Table 3 presents the performance of DeepSeek-V3.2, the best model identified in RQ1, under three prompting strategies on CE-Bench. Surprisingly, the simplest strategy, zero-shot, achieves the highest accuracy at 61.57%, outperforming both dual-label one-shot at 53.87% and chain-of-thought (CoT) at 57.28%.

Table 3. Performance of DeepSeek-V3.2 under different prompting strategies on CE-Bench.

Prompting Strategy	Correct	Accuracy (%)	Avg. Time (s)
zero-shot	1192	61.57	5.39
one-shot	1043	53.87	5.65
CoT	1109	57.28	5.34

The substantial drop in accuracy with the dual-label one-shot approach, despite providing a concrete example with both genuine and spurious counterexamples, suggests that the model may be distracted or misled by the additional context. This could be due to overfitting to surface features of the reference program rather than learning general feasibility principles. Similarly, although CoT encourages step-by-step reasoning, it fails to improve validation accuracy and underperforms zero-shot by over 4 percentage points. This indicates that the model’s explicit reasoning process does not reliably align with formal program semantics.

Moreover, all strategies incur similar inference latency, ranging from 5.34 to 5.65 s, confirming that the observed performance differences are attributable solely to prompt design. Overall, these results challenge the common assumption that richer prompts always lead to better performance. For counterexample validation, minimal instructions yield the most reliable judgments.

4.3. RQ3: Counterexample Type Sensitivity

Table 4 and Figure 5 show the zero-shot performance of DeepSeek-V3.2 across three counterexample categories in CE-Bench. The model exhibits significant variation in accuracy depending on the category, indicating strong sensitivity to the underlying verification task structure.

Table 4. Performance of DeepSeek-V3.2 (zero-shot prompting) across counterexample categories.

Dataset Category	Correct/Total	Accuracy (%)	Avg. Time (s)
OMT_SAT_Pre_CEs	409/848	48.23	5.25
OMT_UNSAT_Pre_CEs	442/590	74.92	5.41
Inductive_CEs	341/498	68.47	5.60
Overall	1192/1936	61.57	5.39

Figure 5. Comparison of zero-shot validation accuracy across counterexample categories.

The poorest performance occurs on OMT_SAT_Pre_CEs, with an accuracy of only 48.23%. This category is the primary contributor to the modest overall accuracy of 61.57% observed in RQ1. Surprisingly, these counterexamples correspond to boundary states that satisfy both the precondition and loop guard, meaning they represent feasible initial loop entries that do not involve complex loop executions. Given that the state-of-the-art verifier Ultimate Automizer correctly validates 96.1% (848 out of 882) of these cases (see Figure 2), this class appears objectively easy for symbolic methods. Yet, large language models perform poorly, suggesting a fundamental mismatch between LLM reasoning capabilities and even the simplest forms of feasibility checking in program verification.

At the same time, we observe that performance on OMT_UNSAT_Pre_CEs is the highest among the three counterexample categories, with an accuracy of 74.92%. In contrast, Ultimate Automizer conclusively validates only 590 out of 991 such counterexamples, yielding a decision rate of 59.5% (see Figure 2). These metrics are not directly comparable: Automizer’s decision rate reflects its ability to reach a conclusive verdict on the full set of instances, whereas our LLM evaluation reports classification accuracy solely on the pre-labeled subset for which ground-truth labels are available—i.e., excluding cases that symbolic verification leaves undecided (e.g., due to timeouts or unknown outcomes).

Critically, these counterexamples of OMT_UNSAT_Pre_CEs correspond to boundary states that satisfy the true loop invariant. Whether they are classified as genuine or spurious directly reflects the completeness of the inferred candidate invariant. The low decision rate of the state-of-the-art symbolic verifier indicates a fundamental challenge in handling completeness during invariant inference—specifically, its difficulty in recognizing feasible executions that lie at the boundary of an incomplete invariant’s coverage. Despite the differing evaluation settings, the high accuracy of large language models on this labeled subset suggests they may offer complementary value in assessing the plausibility of such boundary states, potentially assisting symbolic verifiers when invariant incompleteness leads to inconclusive results.

For Inductive_CEs, the model attains a respectable 68.47% accuracy. While this is notably better than random guessing, such counterexamples remain challenging because they correspond to intermediate program states deep within loop executions, requiring the model to reason about how the program reaches those configurations. Nevertheless, given their critical role in ICE-based invariant synthesis—where high-quality counterexamples drive convergence, LLMs can serve as a viable fallback to validate these counterexamples to enhance the entire loop invariant inference process.

4.4. RQ4: Genuineness Bias

Table 5 reveals a pronounced asymmetry in the error patterns of DeepSeek-V3.2 under zero-shot prompting, indicating a pronounced bias toward labeling counterexamples as spurious. Across all categories, the model is far more likely to misclassify genuine counterexamples as spurious than vice versa. Overall, it incorrectly rejects 52.2% of genuine cases (535 out of 1025), yielding a genuine recall of only 47.8%, a precision of 70.1%, and an F1-score of 60.6%, while falsely accepting only 22.9% of spurious ones (209 out of 911). The overall balanced accuracy, defined as the average of genuine and spurious recalls, is 62.5%, highlighting the performance gap between classes that raw accuracy obscures.

Table 5. Error tendency of DeepSeek-V3.2 (zero-shot prompting).

CE Type	GENUINE → SPURIOUS (Errors/Total)	SPURIOUS → GENUINE (Errors/Total)
OMT_SAT_Pre_CEs	439/848 (51.8%)	—
OMT_UNSAT_Pre_CEs	35/74 (47.3%)	113/516 (21.9%)
Inductive_CEs	61/103 (59.2%)	96/395 (24.3%)
Overall	535/1025 (52.2%)	209/911 (22.9%)

This bias is especially severe in OMT_SAT_Pre_CEs, where every instance is genuine by construction, yet the model labels 51.8% of them as spurious (genuine recall = 48.2%). Similarly, for genuine Inductive_CEs, the false rejection rate rises to 59.2% (genuine recall = 40.8%). In contrast, the false acceptance rates for spurious counterexamples remain consistently low: 21.9% for OMT_UNSAT_Pre_CEs and 24.3% for Inductive_CEs, corresponding to spurious recalls of 78.1% and 75.7%, respectively.

These results suggest that the model adopts a conservative validation strategy, erring on the side of rejecting potentially valid counterexamples rather than risking the acceptance of an infeasible one. While this may reflect a learned heuristic from code corpora, where over-accepting invalid states could be more harmful, it also implies that LLMs are more useful for filtering out likely spurious candidates than for confirming genuine ones. This systematic bias must be accounted for when integrating LLMs into verification loops that rely on accurate counterexample classification. Understanding the origins of this conservative tendency, whether rooted in training priors, prompt sensitivity, or inherent reasoning limitations, represents a promising direction for future work with broader implications for LLMs in formal tasks.

5. Discussion

5.1. Threats to Validity

We discuss threats to validity along four dimensions:

Internal validity concerns factors that may confound our experimental results. First, we use deterministic runs (temperature = 0) with fixed prompts to ensure reproducibility, but this precludes measuring variance due to prompt rewording or minor formatting changes. Second, although fixing decoding parameters like temperature enables controlled comparison, alternative settings—especially for stochastic strategies such as CoT—could affect performance. Third, API-based models (GPT-4o-mini, DeepSeek-V3.2) are evaluated under real-world network conditions; latency measurements include network overhead, which may not reflect pure inference cost. Fourth, although we use zero-shot prompting for RQ1 to isolate model effects, subtle differences in tokenization or context handling across platforms could introduce noise. Fifth, the one-shot prompt in RQ2 uses a fixed example, which may bias results toward its structure; more broadly, any fixed prompt formulation may inadvertently favor certain reasoning patterns or surface features.

External validity relates to the generalizability of our findings. Our conclusions are based on six LLMs, including three quantized open-weight models and three proprietary APIs. While this covers a range of scales and architectures, results may not extend to future models with improved reasoning capabilities or specialized training for verification tasks. Moreover, CE-Bench focuses on loop-free preconditions and inductive counterexamples from single-loop C programs verified via OMT solvers; performance may differ on benchmarks involving concurrency, floating-point arithmetic, or other languages.

Construct validity questions whether our metrics truly capture counterexample validation capability. We use binary accuracy (genuine vs. spurious) as the primary metric, which treats all errors equally. However, in practice, misclassifying a genuine counterexample as spurious (false negative) may be more harmful than the reverse (false positive), as it hides real bugs. Although Table 5 reveals this asymmetry, our main evaluation does not weight errors by severity. Additionally, we do not measure calibration or confidence, which are important for deployment in human-in-the-loop verification.

Conclusion validity involves statistical reliability. All experiments are deterministic (temperature = 0), so we report single-run results. While this ensures reproducibility, it precludes estimation of variance due to sampling.

5.2. Future Work

Our results suggest several promising directions for integrating large language models into loop invariant synthesis:

First, since LLMs demonstrate pronounced capability in validating boundary counterexamples that expose incompleteness of candidate invariants (e.g., on OMT_UNSAT_Pre_CEs), they could be incorporated into the counterexample selection or filtering stage of ICE-based invariant inference to prioritize genuine counterexamples that drive effective refinement.

Second, the observed bias toward labeling counterexamples as spurious indicates a need for calibration techniques that adjust the model’s decision threshold based on the current invariant hypothesis or program context, thereby reducing false negatives that stall convergence.

Third, instead of using generic prompts, future work could explore invariant-aware prompting strategies that explicitly reference the current candidate invariant, loop guard, and precondition, guiding the model to reason about feasibility relative to the invariant’s coverage.

Finally, a tighter integration with symbolic engines could yield a cooperative synthesis loop: the LLM proposes or refines invariant candidates based on linguistic patterns, while the verifier generates counterexamples and validates final correctness, combining data-driven intuition with formal guarantees.

6. Related Work

6.1. Loop Invariant Inference

Automated loop invariant inference has long been a cornerstone of program verification, with approaches broadly falling into two paradigms: symbolic and learning-based.

Symbolic methods rely on formal reasoning engines to derive invariants that are guaranteed correct. These include constraint solving over templates [13], abstract interpretation [4], interpolation-based techniques [9,10,11], syntax-guided synthesis (SyGuS) using SMT solvers [39], and Horn clause solving via model checking [1,2]. While sound and often complete for restricted domains, these methods can struggle with scalability and require careful engineering of heuristics or templates.

To address these limitations, learning-based approaches have emerged under the ICE framework [14], which iteratively refines candidate invariants using labeled counterexamples. Early work employed decision trees [14,15], support vector machines [40,41], or PAC learning [42] to learn predicates from data. More recently, neural and reinforcement learning models have been explored: Code2Inv [18] and LIPuS [19] use reinforcement learning to grow invariant expressions; CLN2INV [20] and G-CLN [21] map logical formulas to continuous logic networks for gradient-based optimization.

Very recently, large language models (LLMs) have been investigated for invariant inference. Kamath et al. [43] prompt LLMs to directly generate candidate invariants; Liu et al. [44] fine-tune LLMs via self-supervision on synthetic invariants; Wu et al. [22] combine LLMs with bounded model checking to guide search. Cao et al. [23] employ LLMs to directly answer clauses of the loop and then combine them to form candidate invariants.

In contrast to these works, which focus on generating invariants, our work investigates a complementary role for LLMs: validating counterexamples within an ICE-style loop. Accurate classification of counterexamples as genuine or spurious is critical for invariant refinement, yet remains challenging for pure symbolic engines, especially when assessing boundary states that expose incompleteness. We thus position LLMs not as invariant generators but as lightweight pre-filters or plausibility scorers that help triage counterexamples by flagging likely spurious ones for early discard and surfacing potentially genuine cases for rigorous symbolic verification, thereby improving the efficiency and focus of the counterexample-driven synthesis process.

6.2. Benchmarks for Evaluating LLMs

The rapid advancement of large language models has spurred their adoption across diverse technical domains, from real-time visual tracking in agriculture [45] to educational assessment and support [46]. In software engineering, this trend has motivated the construction of specialized benchmarks to evaluate LLM reasoning capabilities on programming tasks.

Early efforts such as HumanEval [47] and MBPP [48] assess code generation from natural language descriptions, while APPS [49] and CodeContests [50] target competitive programming challenges. For program repair, datasets like QuixBugs [51] and ManyBugs [52] have been repurposed to evaluate LLM-based patch generation. More realistic settings are explored by SWE-bench [53], which evaluates models on real-world GitHub issues from popular Python repositories, requiring end-to-end debugging, patching, and test validation—making it one of the first benchmarks to measure LLMs’ ability to perform full software maintenance tasks.

More recently, benchmarks have emerged that probe deeper into semantic and formal reasoning. Cruxeval [54] evaluates models on questions requiring precise program trace understanding. DS-1000 [55] focuses on data science code with complex library usage. In the domain of formal methods, VeriBench [56] introduces a suite for evaluating LLMs on end-to-end code verification, while FOLIO [57] tests first-order logic reasoning. However, none of these benchmarks explicitly target the validation of counterexamples in the context of loop invariant synthesis, a critical yet subtle step in automated verification where judgments hinge on feasibility, execution semantics, and invariant completeness.

To address this gap, we introduce CE-Bench, a benchmark specifically designed to evaluate LLMs’ ability to distinguish genuine from spurious counterexamples across three categories that reflect real challenges in ICE-based invariant inference. Unlike prior datasets that focus on input-output correctness or syntactic repair, CE-Bench requires models to reason about program states relative to logical preconditions and loop structures, thereby providing a more nuanced assessment of semantic validation capability.

7. Conclusions

In this paper, we introduce CE-Bench, a new benchmark constructed from real verification runs to systematically evaluate large language models on counterexample validation in the context of loop invariant inference. Our study demonstrates that large language models are effective at identifying boundary cases that expose incompleteness in candidate invariants and at evaluating inductive counterexamples, showing clear potential to enhance ICE-based invariant synthesis. However, they also exhibit a pronounced bias toward rejecting valid counterexamples. This highlights their promise as heuristic plausibility estimators that can prioritize or pre-filter counterexamples for downstream symbolic validation, while underscoring the need for careful integration into loop invariant inference pipelines.