Parallel numerical libraries such as PETSc are widely used in science and engineering applications where wrong results can have costly consequences. Despite this, numerical libraries are rarely formally verified. One of the challenges is the need for an expert to hand-write a specification and manually apply a verification tool, often requiring the development of a harness or driver, all of which can contain additional bugs that lead to false positives or false negatives during verification. With recent advancements in large language models (LLMs), it is tempting to generate such drivers and reference models automatically, but one-shot generation based on a simple prompt is brittle and leads to additional unverified code that needs to be audited. In this paper, we present an approach to use LLMs in a limited setting to generate a small, human-certifiable ACSL contract from the function's documentation, combined with a deterministic toolchain that supports a restricted ACSL profile and generates a driver that uses the CIVL verifier to check the implementation against the contract and, when available, an existing reference model. We demonstrate the pipeline end-to-end on three PETSc functions: MatAXPY (reference model already exists), MatAYPX (no reference model, so the certified contract is the sole oracle), and the non-compressing mode of MatFilter (no reference model, with more complex, conditional behavior). With this pipeline, we were able to discover a bug in PETSc's MatAYPX function that was previously undiscovered and had been present in the code since 1997.
Figures & tables
Fig. 1: The three-stage pipeline: LLM-generated contract, human certification, and deterministic CIVL driver generation.
Symbol
Stipulated meaning in the PETSc model
valid_mat ( M )
M is a matrix handle whose modeled dimensions, communicator, assembly state, and dense global image are consistent.
valid_vec ( v )
v is a vector handle whose modeled size, communicator, assembly state, and dense global image are consistent.
separated_mat ( A , B )
A and B are distinct matrix objects with disjoint modeled storage.
separated_vec ( x , y )
x and y are distinct vector objects with disjoint modeled storage.
same_comm ( x , y )
The modeled PETSc objects use the same MPI communicator.
assembled ( x )
The modeled object has no pending assembly updates.
TABLE I: Custom PETSc predicates for acsl2civl . These unescaped names extend the supported ACSL fragment.
Contract construct
Generated driver behavior
Supported requires equality
constrains symbolic dimensions or parameter values during driver construction.
Custom PETSc predicate
emits corresponding CIVL assumptions, construction constraints, or generated cases.
assigns over modeled data
records pre-call values outside the assignable set and checks that those values remain unchanged after the call.
Supported ensures
translated into elementwise CIVL assertions over the gathered global image; \ old terms refer to recorded pre-call values.
TABLE II: Translation from supported contract constructs to CIVL-C driver code.
Function
Case
str
Time (s)
Mem. (GiB)
States
Trans.
MatAXPY
aliased
D
27.01
2.27
79,599
162,530
MatAXPY
aliased
U
29.09
2.36
79,599
162,530
MatAXPY
distinct
D
36.73
2.27
102,082
206,215
MatAXPY
distinct
U
34.36
2.27
102,082
206,215
MatAYPX
aliased †
D
6.75
1.30
1,615
3,460
MatAYPX
aliased †
U
7.06
1.71
1,615
3,460
TABLE III: CIVL verification cost for the small experiments.
Function
PETSc body
Port
Drivers
Contract
MatAXPY
39
23
176
14
MatAYPX
4
4
152
13
MatFilter
72
24
38
8
TABLE IV: Artifact size by review strategy.
Fig. 2: Extending the PETSc-ACSL profile and acsl2civl to support MatFilter .
While LLMs have accelerated scientific code generation, comprehensively evaluating generated code remains challenging. Many benchmarks emphasize functional correctness or task completion, which is insufficient for code built on production HPC libraries, where solver selection, API conventions, memory management, parallel awareness, and performance also matter. We introduce PETSCAgent-Bench, a multidimensional benchmark and agent-based framework for assessing whether AI-generated scientific code uses a production HPC library as an expert would. A tool-augmented evaluator compiles, executes, and measures code and combines deterministic checks with LLM-based assessments in a 14-evaluator pipeline spanning five categories: correctness, performance, code quality, algorithmic appropriateness, and library-specific conventions. A2A and MCP enable black-box evaluation of compatible coding agents. Across realistic PETSc problems, frontier models generate readable, well-structured code but struggle with correctness on challenging problems and with library-specific conventions even when code compiles and runs---limitations that conventional pass/fail evaluation does not capture.
Verification is becoming central to both reinforcement-learning-based training and inference-time control of large language models (LLMs). Yet current verifiers face a fundamental trade-off: LLM-based verifiers are expressive but hard to control and prone to error, while deterministic executable verifiers are reliable and interpretable but often limited in capability. We study the following question: given a development set of LLM outputs and labels for a target objective, such as correctness, can we automatically induce a minimal set of Python verifiers whose joint satisfaction closely matches that objective? We propose AutoPyVerifier, a framework that uses an LLM to synthesize candidate verifier functions and then refines them through search over a directed acyclic graph (DAG). By navigating the DAG, AutoPyVerifier systematically explores the space of deterministic executable verifiers and selects a compact verifier set whose joint satisfaction best approximates the target objective. Across mathematical reasoning, coding, function calling, and instruction-following benchmarks for several state-of-the-art LLMs, AutoPyVerifier improves target-objective prediction by up to 55.0 F1 points over the initial LLM-generated verifier sets. Additional analyses show that the most useful verification targets vary by benchmark and model, and that the DAG-based search shifts the learned verifier sets toward more structural and semantically grounded checks. We further show that exposing the discovered verifier set to an LLM as an external tool improves downstream accuracy by up to 17.0 points. We release our code
Static verification tools can assure industrial scale software, but require significant human labor to write specifications. This is particularly true of static verifiers based on separation logic (SL verifiers), which excel at verifying heapmanipulating programs, but require many complex auxiliary specifications to reason about heap structure. Recent work applies large language models (LLMs) to generate code, tests, and proofs, including specifications for verifiers, but mostly targeting non-SL verifiers. To address this gap, this paper thoroughly evaluates how well LLMs perform when prompted to generate specifications for verifying 303 C functions with the SL verifier VeriFast. We explored eight prompting approaches, ten LLMs, and three input types in two stages. Quantitative and qualitative analyses are used to assess the LLM-generated code and specifications for functional behavior, verifiability and errors. The results show that LLMs preserve functional behavior in source code and specifications (both over 91%), but achieve modest verification success (31.4%). Using Gemini 2.5 Pro and providing formal contracts lead to higher success rates in our setting. Moreover, most errors (94%) come from LLMs' mistakes in the domainspecific knowledge of SL verifiers such as VeriFast. These findings provide guidance for optimizing LLM-generated specifications for SL verifiers.
Wen Fan, Minh Tran, Sanya Dod +5
Purdue University West Lafayette, Indiana, USA · University of Michigan Ann Arbor, Michigan, USA · Meta Menlo Park, California, USA