<?xml version='1.0' encoding='UTF-8'?>
<feed xmlns:opensearch="http://a9.com/-/spec/opensearch/1.1/" xmlns:arxiv="http://arxiv.org/schemas/atom" xmlns="http://www.w3.org/2005/Atom">
  <id>https://arxiv.org/api//yNb+/oosPQsLCBH21X15zIK/JY</id>
  <title>arXiv Query: search_query=all:"compiler testing"&amp;id_list=&amp;start=0&amp;max_results=40</title>
  <updated>2026-09-28T14:39:18Z</updated>
  <link href="https://arxiv.org/api/query?search_query=all:%22compiler+testing%22&amp;start=0&amp;max_results=40&amp;id_list=" type="application/atom+xml"/>
  <opensearch:itemsPerPage>40</opensearch:itemsPerPage>
  <opensearch:totalResults>49</opensearch:totalResults>
  <opensearch:startIndex>0</opensearch:startIndex>
  <entry>
    <id>http://arxiv.org/abs/2608.23611v1</id>
    <title>REFINE: A Multi-Agent LLM Approach for Evidence-Guided Code Refactoring</title>
    <updated>2026-08-21T17:44:40Z</updated>
    <link href="https://arxiv.org/abs/2608.23611v1" rel="alternate" type="text/html"/>
    <link href="https://arxiv.org/pdf/2608.23611v1" rel="related" type="application/pdf" title="pdf"/>
    <summary>Large Language Models (LLMs) offer new opportunities for automated code refactoring. However, generated changes must reduce targeted quality problems without introducing new issues or altering behaviour-relevant code structures. We introduce REFINE (Refactoring with Evidence-aware Flow for Integrated ageNtic Execution), a tool-agnostic, evidence-aware multi-agent approach for generating Java file-level refactoring candidates. REFINE combines static-analysis-guided smell identification, smell-informed planning, LLM-based transformation, automated re-analysis, preservation checks, and structured reporting.
  We evaluate REFINE on 450 Java files from 15 open-source systems, producing 1,350 model-pass outputs using OpenAI GPT-5.5, Google Gemini 3.1 Pro Preview, and Anthropic Claude Opus 4.8. REFINE reduces detected code smells by 68.26%, 72.79%, and 68.49% across the three configurations, respectively, with the strongest reductions observed for major smells. A matched 150-file direct-prompt baseline shows that REFINE achieves a higher median code-smell reduction with smaller edits and fewer public-method removals. However, broader quality improvements are inconsistent, and preservation checks reveal residual risks, including assert/fail-call changes and public-method removal. Therefore, REFINE outputs should be treated as refactoring candidates requiring compilation, testing, dependency analysis, and human review before adoption in repository- or system-level settings.</summary>
    <category term="cs.SE" scheme="http://arxiv.org/schemas/atom"/>
    <category term="cs.AI" scheme="http://arxiv.org/schemas/atom"/>
    <published>2026-08-21T17:44:40Z</published>
    <arxiv:comment>Preprint. 450 Java files from 15 open-source systems; 1,350 model-pass outputs across three LLM configurations. The accompanying replication package will be made publicly available</arxiv:comment>
    <arxiv:primary_category term="cs.SE"/>
    <author>
      <name>Muhammad Waseem</name>
    </author>
    <author>
      <name>Aakash Ahmad</name>
    </author>
    <author>
      <name>Pekka Abrahamsson</name>
    </author>
  </entry>
  <entry>
    <id>http://arxiv.org/abs/2608.16638v1</id>
    <title>ModBench: A Pipeline for Building Modelica Benchmark Datasets Mined from Library Repositories</title>
    <updated>2026-08-17T14:35:20Z</updated>
    <link href="https://arxiv.org/abs/2608.16638v1" rel="alternate" type="text/html"/>
    <link href="https://arxiv.org/pdf/2608.16638v1" rel="related" type="application/pdf" title="pdf"/>
    <summary>Research on equation-based cyber-physical systems modeling languages, such as Modelica, is constrained by the lack of curated benchmark datasets. This limits empirical insight into the evolution and development of models. We address this gap with ModBench, a pipeline that mines Git repositories of Modelica libraries to produce benchmark datasets of model snapshots. The pipeline (1) filters repository commits to retain human-authored, Modelica-relevant revisions; (2) extracts simulation-eligible classes; and (3) builds canonical representations of Modelica classes. For empirical validation, we applied ModBench to the Modelica Standard Library (MSL) and report the resulting dataset, spanning the full commit history (since Modelica language v3), with 85,562 distinct class snapshots, and links enabling traceability to original models and Git metadata. The dataset, its API, and the data generation pipeline are publicly available to support future research on model evolution analysis, compiler testing, and automated model repair or generation.</summary>
    <category term="cs.SE" scheme="http://arxiv.org/schemas/atom"/>
    <published>2026-08-17T14:35:20Z</published>
    <arxiv:comment>Extended abstract accepted at SAM 2026, co-located with MODELS 2026. To appear in the ACM/IEEE MODELS 2026 Companion Proceedings</arxiv:comment>
    <arxiv:primary_category term="cs.SE"/>
    <author>
      <name>Masoud Sadrnezhaad</name>
    </author>
    <author>
      <name>Martin Sjölund</name>
    </author>
    <author>
      <name>Adrian Pop</name>
    </author>
    <author>
      <name>José Antonio Hernández López</name>
    </author>
    <author>
      <name>Torvald Mårtensson</name>
    </author>
    <author>
      <name>Dániel Varró</name>
    </author>
    <arxiv:doi>10.1145/3837062.3838901</arxiv:doi>
    <link rel="related" href="https://doi.org/10.1145/3837062.3838901" title="doi"/>
  </entry>
  <entry>
    <id>http://arxiv.org/abs/2608.12440v2</id>
    <title>Specification-first convergence with an AI coding agent: a case study of dismantling a core architectural invariant across 189 files in a 717k-line codebase with no test oracle and no human code review</title>
    <updated>2026-08-15T11:27:55Z</updated>
    <link href="https://arxiv.org/abs/2608.12440v2" rel="alternate" type="text/html"/>
    <link href="https://arxiv.org/pdf/2608.12440v2" rel="related" type="application/pdf" title="pdf"/>
    <summary>This paper reports a single, fully instrumented case study of a large-scale architectural refactoring by an AI coding agent under a specification-first protocol, with no human review of the generated code and no pre-existing oracle to validate the target behaviour. The task, dismantling a central invariant across a large interdependent codebase, was assessed by the author as effectively infeasible through incremental refactoring, the kind of change that conventionally calls for a rewrite instead. Under the protocol described here, the agent completed it successfully.
  The system is a 717,725-line production TypeScript application across 3,648 files. The task required dismantling a core lifetime invariant: the guarantee that a UI panel remains open for the duration of an AI request. The target behaviour was that a streaming generation survives the closing of its panel and can be reattached, on reopening, to the same live stream with no loss or duplication.
  The protocol: formal specification by the agent, 14 refinement cycles auditing that specification against the source code, atomic implementation, a compile/test feedback loop, then 17 verification cycles auditing the code against the frozen specification. Across 31 audit passes, 201 defects were corrected before any human executed the program. The convergence criterion was empirical: two consecutive verification passes returning zero findings.
  The change touched 189 files (31 new); with the extraction phase, the two commits total 288 files, 34,770 insertions, 16,422 deletions. Across the first and roughly thirty later sessions, the software behaved as specified, no bug observed. Elapsed: three days; cost: USD 2,430.
  The full specification and raw session logs, 1,500+ pages in French, are published as evidence, allowing inspection of the process and submission to a language model for consistency checking.</summary>
    <category term="cs.SE" scheme="http://arxiv.org/schemas/atom"/>
    <category term="cs.AI" scheme="http://arxiv.org/schemas/atom"/>
    <published>2026-08-12T15:35:48Z</published>
    <arxiv:comment>14 pages, 4 figures, 3 tables. v2: added plain-text log URLs in Section 10 for LLM readability</arxiv:comment>
    <arxiv:primary_category term="cs.SE"/>
    <author>
      <name>Joel Abenhaim</name>
    </author>
  </entry>
  <entry>
    <id>http://arxiv.org/abs/2608.11772v1</id>
    <title>Diagnosis Before Recovery: Turning Agent Failures into Selective Self-Correction</title>
    <updated>2026-08-12T08:14:45Z</updated>
    <link href="https://arxiv.org/abs/2608.11772v1" rel="alternate" type="text/html"/>
    <link href="https://arxiv.org/pdf/2608.11772v1" rel="related" type="application/pdf" title="pdf"/>
    <summary>Self-correction is particularly useful when a failure constrains the next repair. Coding agents benefit from this property because compilers, tests, and execution traces turn many failures into typed recovery signals, but broad language-agent tasks often expose only a coarse task failure. This creates a tension for generic recovery playbooks: they broaden the agent's context precisely when the system needs a narrower repair interface, mixing incompatible signals for invalid actions, missing procedures, and strict-format errors. Our insight is that development-set failures can recover part of the missing diagnostic substrate by deciding which recovery interventions are admissible before test-time correction. We propose DARC, a diagnosis-guided recovery harness that profiles task-family failure modes, prunes mismatched interventions from a shared recovery library, and freezes a verifier-selected success-cost policy for deployment. This causal order makes correction selective: the harness first determines what kind of failure can be repaired, then decides how much recovery evidence to spend. In ALFWorld, AppWorld, and XBRL Finance, the same protocol yields an action-validity harness, a procedural-recovery fallback, and a format-precision retrieval policy; in each evaluated setting it improves average task performance over base agents and broad playbooks while reducing environment steps or retrieval budget. Our experiments show that failures need not trigger uniformly more context: DARC turns self-correction from prompt expansion into recovery-interface design. DARC provides a practical route toward more reliable agents in domains where compiler-like feedback is absent: making failures actionable before making contexts larger.</summary>
    <category term="cs.CL" scheme="http://arxiv.org/schemas/atom"/>
    <published>2026-08-12T08:14:45Z</published>
    <arxiv:primary_category term="cs.CL"/>
    <author>
      <name>Pan Wang</name>
    </author>
    <author>
      <name>Yihao Hu</name>
    </author>
    <author>
      <name>Hang Wang</name>
    </author>
    <author>
      <name>Zirui Lv</name>
    </author>
    <author>
      <name>Xin Zhang</name>
    </author>
    <author>
      <name>Jianshe Li</name>
    </author>
    <author>
      <name>Jiang-Ming Yang</name>
    </author>
    <author>
      <name>Wei Wu</name>
    </author>
    <author>
      <name>Yongqi Tong</name>
    </author>
  </entry>
  <entry>
    <id>http://arxiv.org/abs/2608.11066v1</id>
    <title>Quantum Coordination Advantages in AI State-Tracking Tasks: Semantic Compilation and Latent Memory</title>
    <updated>2026-08-11T15:32:15Z</updated>
    <link href="https://arxiv.org/abs/2608.11066v1" rel="alternate" type="text/html"/>
    <link href="https://arxiv.org/pdf/2608.11066v1" rel="related" type="application/pdf" title="pdf"/>
    <summary>We prove inference-time quantum coordination advantages for specified AI state-tracking tasks. A solver compresses semantic history into a future-accessible boundary state and later answers a query. We count communication $B$, persistent instance-dependent memory $M$, and local work $D$; classical recurrence, caches, tools, and recomputation are allowed and charged. The central result is a boundary-preserving semantic-compilation theorem. It maps a finite one-way, streaming, or adaptive causal task into a semantic AI interface while preserving event order and access to past input. Classical boundary-state lower bounds and quantum-memory upper bounds transfer up to explicit compiler overhead, independently of the finite-precision recurrent architecture. Two applications have classical semantics. Matched-entity synopsis QA inherits the hidden-matching separation between $O(\log N)$ qubits and $Ω(\sqrt{N})$ classical boundary bits. Continual requirements auditing inherits a Max-$k$SAT streaming separation: a recurrent solver uses $O(\log^5 n\log(1/δ))$ qubits and polylogarithmic classical workspace to obtain a $0.7172$-approximation, whereas every classical one-pass finite-information solver attaining that ratio requires $Ω(\sqrt{n})$ coordination width. As a quantum-native compiler test, a stabilizer latent-state dialogue uses $n$ qubits, while every exact finite-state classical causal online realization satisfies $B+M \ge \frac{1}{2}n^2+(\frac{3}{2}-\log_2 3)n+O(1)$. The source protocols, streaming algorithms, and stabilizer witness are imported; the new result is their architecture-independent semantic transfer. These are memory and coordination separations, not runtime or empirical advantages for present-day language models. The stabilizer result assumes exact simulation and ideal noiseless quantum memory.</summary>
    <category term="quant-ph" scheme="http://arxiv.org/schemas/atom"/>
    <category term="cs.AI" scheme="http://arxiv.org/schemas/atom"/>
    <category term="cs.CC" scheme="http://arxiv.org/schemas/atom"/>
    <published>2026-08-11T15:32:15Z</published>
    <arxiv:comment>Comments and suggestions are welcome on alphaXiv</arxiv:comment>
    <arxiv:primary_category term="quant-ph"/>
    <author>
      <name>Ming Yang</name>
    </author>
  </entry>
  <entry>
    <id>http://arxiv.org/abs/2607.29247v1</id>
    <title>Metamorphic Testing of Transpilers via Mutation Consistency of Programs</title>
    <updated>2026-07-31T10:20:08Z</updated>
    <link href="https://arxiv.org/abs/2607.29247v1" rel="alternate" type="text/html"/>
    <link href="https://arxiv.org/pdf/2607.29247v1" rel="related" type="application/pdf" title="pdf"/>
    <summary>Transpilers are increasingly used for software development, especially in industrial domains that rely on domain-specific languages (DSLs), to allow engineers to work with familiar concepts and appropriate abstractions. Ensuring the correctness of these instruments is therefore critical in many industrial settings. This paper observes that existing approaches for compiler testing hardly generalize to transpilers. Differential testing approaches are hindered as multiple equivalent implementations of the transpiler under test are seldom available in practice. The approaches based on metamorphic testing assume the ability to execute the compiled binaries, an assumption that cannot be always made for transpilers, which oftentimes produce results expressed as source code, requiring complex toolchains, hardware-in-the-loop setups, and depending on non trivial inputs. This paper introduces a novel metamorphic testing technique tailored to transpilers. Instead of reasoning about the runtime behavior of compiled programs, our approach defines metamorphic relations directly over the source code produced by the transpiler. These relations capture a property that we call mutation consistency of the (transpiled) programs: mutation-style changes in the input DSL program must induce predictable and structurally consistent changes in the generated output. We implemented this idea in a tool, MCP-Tester, and evaluated it through a case study conducted in the context of a technology-transfer project. Our current empirical results indicate that the proposed approach can effectively reveal faults that would remain undetected with pure fuzzing.</summary>
    <category term="cs.SE" scheme="http://arxiv.org/schemas/atom"/>
    <published>2026-07-31T10:20:08Z</published>
    <arxiv:comment>11 pages, 4 figures</arxiv:comment>
    <arxiv:primary_category term="cs.SE"/>
    <author>
      <name>Enea Raffaele Ilario Papaleo</name>
    </author>
    <author>
      <name>Luca Guglielmo</name>
    </author>
    <author>
      <name>Giovanni Denaro</name>
    </author>
  </entry>
  <entry>
    <id>http://arxiv.org/abs/2607.11811v1</id>
    <title>Complexity Theory of Randomised Testing</title>
    <updated>2026-07-13T17:08:03Z</updated>
    <link href="https://arxiv.org/abs/2607.11811v1" rel="alternate" type="text/html"/>
    <link href="https://arxiv.org/pdf/2607.11811v1" rel="related" type="application/pdf" title="pdf"/>
    <summary>Randomised testing is a widely-used approach to software validation, yet its theoretical foundations remain thin. In particular, the fundamental question of what it means for a set of inputs to be \emph{generable} has gone unanswered in both the literature and folklore. We present the first complexity-theoretic foundations for random generators in software testing. We model generators as Turing transducers that consume random bits and produce string-encoded outputs, and show that the theoretically generable languages coincide exactly with the recursively enumerable languages. This has direct implications for testing at the boundaries of decidability, such as compiler testing. For \emph{efficient} generation, we show that the polynomial-time generable languages lie within \textit{NP}, that certain \textit{NP}-complete languages admit efficient generators, and that -- under standard cryptographic assumptions -- there are languages in \textit{P} for which no efficient generator exists: the complexity of efficienct generation and of efficient decision are not the same. We show space-bounded complexity is the natural framework for generators producing \emph{correlated} samples, capturing methodologies such as coverage-guided fuzzing and symbolic execution. Beyond classification, we characterise efficient generability: a language has a polynomial-time generator iff it admits a \emph{certificate scheme} over a verifier -- so witness planting, the folklore technique behind generators to test SAT solvers, is in a sense the only route to efficient generation. On the design of property-based testing libraries, we prove no library can compositionally derive efficient generators from logical predicates involving conjunction or negation, under standard assumptions. However, restricted classes like \textit{NL} (equivalently, linear Datalog predicates) would admit such a compilation.</summary>
    <category term="cs.PL" scheme="http://arxiv.org/schemas/atom"/>
    <category term="cs.CC" scheme="http://arxiv.org/schemas/atom"/>
    <category term="cs.SE" scheme="http://arxiv.org/schemas/atom"/>
    <published>2026-07-13T17:08:03Z</published>
    <arxiv:comment>44 pages, 2 figures</arxiv:comment>
    <arxiv:primary_category term="cs.PL"/>
    <author>
      <name>Pingshi Yu</name>
    </author>
    <author>
      <name>Chengsong Tan</name>
    </author>
    <author>
      <name>Nicolas Wu</name>
    </author>
    <author>
      <name>Alastair Donaldson</name>
    </author>
  </entry>
  <entry>
    <id>http://arxiv.org/abs/2607.07217v1</id>
    <title>Finding and Understanding Miscompilation Bugs in the Solidity Compiler</title>
    <updated>2026-07-08T09:59:46Z</updated>
    <link href="https://arxiv.org/abs/2607.07217v1" rel="alternate" type="text/html"/>
    <link href="https://arxiv.org/pdf/2607.07217v1" rel="related" type="application/pdf" title="pdf"/>
    <summary>Smart contract compilers are critical to ensuring the correctness of public blockchains whose defining characteristics are open-source and immutable code. We created SolSmith, a semantics-aware differential fuzz testing tool, to improve the quality of the Solidity compiler -- the most popular compiler for the Ethereum blockchain -- and spent over three years finding compiler defects that produce incorrect code. We call these defects miscompilation bugs. During this time period, we have discovered 25 miscompilation bugs that went unnoticed, some for multiple years. Our first contribution is to make compiler testing more rigorous. SolSmith achieves this goal by generating valid test programs that are likely to stress test code generation and optimization components. This helps SolSmith find bugs missed during routine testing that could potentially have serious implications for smart contracts and their users. Our second contribution is a qualitative and quantitative analysis of miscompilation bugs that we found in the Solidity compiler. We classify miscompilation bugs found by SolSmith based on their nature, root-causes, and impact on end-users. This sheds light on some pitfalls of optimizing compilers.</summary>
    <category term="cs.SE" scheme="http://arxiv.org/schemas/atom"/>
    <category term="cs.CR" scheme="http://arxiv.org/schemas/atom"/>
    <category term="cs.PL" scheme="http://arxiv.org/schemas/atom"/>
    <published>2026-07-08T09:59:46Z</published>
    <arxiv:comment>16 pages, 7 figures, 4 tables</arxiv:comment>
    <arxiv:primary_category term="cs.SE"/>
    <author>
      <name>Bhargava Shastry</name>
    </author>
  </entry>
  <entry>
    <id>http://arxiv.org/abs/2606.29999v1</id>
    <title>AlgoSkill: Learning to Design Algorithms by Scheduling Human-Like Skills</title>
    <updated>2026-06-29T09:09:16Z</updated>
    <link href="https://arxiv.org/abs/2606.29999v1" rel="alternate" type="text/html"/>
    <link href="https://arxiv.org/pdf/2606.29999v1" rel="related" type="application/pdf" title="pdf"/>
    <summary>Designing an algorithm from a natural-language problem statement requires identifying the problem structure, reading constraints, choosing a suitable paradigm, checking correctness, and refining complexity. Existing large language model (LLM) methods often rely on direct generation or generic self-refinement, leaving these steps implicit. We propose AlgoSkill, which models algorithm design as sequential decision-making over a typed library of algorithmic skills, including abstraction, constraint analysis, state design, data-structure selection, proof checking, counterexample construction, and complexity refinement. A learned scheduler proposes skills from the current design state, while a Monte Carlo Tree Search (MCTS) controller explores skill sequences using verification feedback from compilation, testing, stress testing, and complexity analysis. Experiments on competitive programming and combinatorial optimization benchmarks show that AlgoSkill improves over direct LLM generation, chain-of-thought prompting, self-refinement, and MCTS without typed skills. Ablations show that typed skills, verification-based repair, and search-based scheduling each contribute to performance. These results support treating automatic algorithm design as verification-guided skill scheduling rather than one-shot code generation.</summary>
    <category term="cs.AI" scheme="http://arxiv.org/schemas/atom"/>
    <published>2026-06-29T09:09:16Z</published>
    <arxiv:comment>Under Review</arxiv:comment>
    <arxiv:primary_category term="cs.AI"/>
    <author>
      <name>Xinyuan Song</name>
    </author>
    <author>
      <name>Zekun Cai</name>
    </author>
    <author>
      <name>Liang Zhao</name>
    </author>
  </entry>
  <entry>
    <id>http://arxiv.org/abs/2606.28132v1</id>
    <title>CrossLangFuzzer: Differential Testing of Cross-Language JVM Compilers</title>
    <updated>2026-06-26T14:33:52Z</updated>
    <link href="https://arxiv.org/abs/2606.28132v1" rel="alternate" type="text/html"/>
    <link href="https://arxiv.org/pdf/2606.28132v1" rel="related" type="application/pdf" title="pdf"/>
    <summary>Modern JVM software increasingly integrates multiple programming languages, such as Java, Kotlin, Groovy, and Scala, within a single application. Supporting such interoperability requires JVM compilers to perform cross-language compilation while reconciling subtle semantic differences across language boundaries. Errors in this process can lead to critical miscompilations, yet existing compiler testing techniques focus exclusively on isolated, singlelanguage compilation. To address this gap, we present CrossLangFuzzer, the first differential testing framework for cross-language JVM compilation. CrossLangFuzzer leverages the Kotlin compiler's unified intermediate representation (IR) to synthesize cross-language test programs. It further applies seven mutation operators to diversify generated test programs and improve bug-finding capability. Evaluated on the latest versions of five major JVM compilers, CrossLangFuzzer uncovered 32 confirmed bugs, including 15 in Kotlin, 4 in Groovy, 7 in Scala 3, 2 in Scala 2, and 4 in Java. CrossLangFuzzer is open-source at https://github.com/XYZboom/CrossLangFuzzer</summary>
    <category term="cs.SE" scheme="http://arxiv.org/schemas/atom"/>
    <published>2026-06-26T14:33:52Z</published>
    <arxiv:primary_category term="cs.SE"/>
    <author>
      <name>Xiaotian Ma</name>
    </author>
    <author>
      <name>Qiong Feng</name>
    </author>
    <author>
      <name>Yongqiang Tian</name>
    </author>
    <author>
      <name>Wei Song</name>
    </author>
    <author>
      <name>Peng Liang</name>
    </author>
  </entry>
  <entry>
    <id>http://arxiv.org/abs/2606.26977v1</id>
    <title>CLIR: Liveness-Driven and Structure-Aware Fuzzing for the Cranelift Compiler</title>
    <updated>2026-06-25T12:48:54Z</updated>
    <link href="https://arxiv.org/abs/2606.26977v1" rel="alternate" type="text/html"/>
    <link href="https://arxiv.org/pdf/2606.26977v1" rel="related" type="application/pdf" title="pdf"/>
    <summary>Modern compilers are complex software systems that must correctly translate high-level programming languages into machine code across multiple architectures. Cranelift, a fast and modern compiler backend originally developed for WebAssembly and recently adopted as an experimental backend for Rust, has gained increasing importance due to its superior compilation speed compared to LLVM and comprehensive multi-architecture support, including x86-64, AArch64, s390x, and RISCV64. However, despite decades of development in compiler testing, testing Cranelift still presents unique challenges, including (1) constructing valid IR under the strict enforcement of SSA form, (2) generating sequences with sufficient computational density to stress backend components, and (3) balancing broad backend coverage with efficient root cause analysis across heterogeneous architectures.
  To address these challenges, we propose CLIR, a differential testing framework that integrates a syntax-preserving hierarchical generation strategy to guarantee SSA validity, a liveness-guided instruction refinement mechanism to maximize computational density, and a diagnosis-guided cross-architecture adaptation scheme to facilitate efficient root cause analysis across heterogeneous backends. Our comprehensive evaluation demonstrates that CLIR significantly outperforms existing state-of-the-art baselines, detecting 8x, 24x, and 8x more unique bugs than cranelift-fuzzgen, wasm-smith, and WASMaker, respectively, while RustSmith uncovered no bugs. Consequently, within 72 hours of testing, CLIR discovered 24 bugs spanning all target architectures, with 21 confirmed and 9 fixed.</summary>
    <category term="cs.SE" scheme="http://arxiv.org/schemas/atom"/>
    <published>2026-06-25T12:48:54Z</published>
    <arxiv:primary_category term="cs.SE"/>
    <author>
      <name>Shangtong Cao</name>
    </author>
    <author>
      <name>Tianlei Song</name>
    </author>
    <author>
      <name>Qiuping Yi</name>
    </author>
    <author>
      <name>Tianyu Chen</name>
    </author>
    <author>
      <name>Guoai Xu</name>
    </author>
    <author>
      <name>Ningyu He</name>
    </author>
    <author>
      <name>Haoyu Wang</name>
    </author>
  </entry>
  <entry>
    <id>http://arxiv.org/abs/2606.18421v1</id>
    <title>Finding Compiler-Platform Interaction Bugs in Deep Learning Pipelines via Cross-Layer Constraints</title>
    <updated>2026-06-16T19:15:17Z</updated>
    <link href="https://arxiv.org/abs/2606.18421v1" rel="alternate" type="text/html"/>
    <link href="https://arxiv.org/pdf/2606.18421v1" rel="related" type="application/pdf" title="pdf"/>
    <summary>The growing deployment of artificial intelligence (AI) necessitates robust deep learning (DL) compilers, such as TVM and ONNX-MLIR. These compilers take as input high-level AI models, lower them through multi-layer transformations, and specialize them to diverse hardware. Testing such compilers is uniquely challenging as correctness depends on implicit constraints embedded throughout the compilation stack. Existing testing approaches largely take type constraints to restrict input model generation and therefore emphasize type validation and monitor compilation crashes or coverage gains. This focus overlooks compiler-platform interaction bugs that arise from interleaved effects across compilation and execution environments.
  In this work, we propose a scalable, automated DL compiler testing framework for, in tandem, (1) finding compiler-platform interaction bugs and (2) enabling behavior equivalence partitioning. Our key insight is that these bugs are caused by violated assumptions arising from interactions across compilation passes and hardware platforms. Therefore, we move beyond constraining input generation and derive full-stack constraints. Our approach is three-fold. First, we design an automated approach to extract full-stack constraints that jointly guide model generation and characterize compilation behaviors. Second, we prioritize constraints that expose interaction-sensitive behaviors, so our generated models are capable of exercising deep compilation logic. Third, we enable behavior equivalence partitioning by automatically inserting assertions to monitor distinct compilation symptoms that coverage or pass/fail signals miss.
  We evaluated our tool, XCheck, on three widely-used DL compilers and found 2,034 bug-revealing cases, including memory overflows, integer overflows, and silent unexpected compilations that were rooted in compiler-platform interactions.</summary>
    <category term="cs.SE" scheme="http://arxiv.org/schemas/atom"/>
    <published>2026-06-16T19:15:17Z</published>
    <arxiv:primary_category term="cs.SE"/>
    <author>
      <name>Yuxin Qiu</name>
    </author>
    <author>
      <name>Jiyuan Wang</name>
    </author>
    <author>
      <name>Ronak Badhe</name>
    </author>
    <author>
      <name>Ben Limpanukorn</name>
    </author>
    <author>
      <name>Miryung Kim</name>
    </author>
    <author>
      <name>Qian Zhang</name>
    </author>
  </entry>
  <entry>
    <id>http://arxiv.org/abs/2606.00530v3</id>
    <title>Sakura: An Approach for Generating Complex Tests from Natural Language Test Descriptions</title>
    <updated>2026-08-13T19:42:37Z</updated>
    <link href="https://arxiv.org/abs/2606.00530v3" rel="alternate" type="text/html"/>
    <link href="https://arxiv.org/pdf/2606.00530v3" rel="related" type="application/pdf" title="pdf"/>
    <summary>Research on automating software testing has spanned several decades. Most existing approaches generate unit tests for individual methods, validate isolated API endpoints, or target user interface (UI) layers, with non-API and non-UI generators typically exercising only a single focal method. Recent empirical evidence shows a substantial gap between such generated tests and developer-written ones, which often span several focal classes and methods, involve multi-step call sequences, and contain chained assertions, all characteristics that current approaches fail to capture. To address this gap, we propose generating tests from natural language (NL) descriptions of developer intent, an expressive and accessible medium for specifying complex test scenarios. We present Sakura, the first agent-based framework for generating structurally complex tests from NL descriptions. Sakura decomposes NL descriptions into structured blocks and processes them with a multi-agent system: a localization agent grounds test steps in concrete application code via static analysis, a composition agent synthesizes compilable test code and iteratively refines it using execution feedback, and a supervisor agent coordinates their interactions. To evaluate Sakura, we curate a novel dataset of NL test descriptions at three levels of abstraction, reflecting different end-user personas, systematically derived from developer-written tests in Apache Commons projects. Across 20 applications and 1,464 test scenarios, Sakura substantially outperforms off-the-shelf agentic tools such as Gemini CLI instantiated with multiple LLMs, achieving 50-78% higher test compilability and 38-66% higher coverage overlap with ground-truth tests using the same models. Moreover, Sakura paired with small open-source models such as Devstral Small 2 and Qwen3-Coder outperforms Gemini CLI using large proprietary models, at lower cost.</summary>
    <category term="cs.SE" scheme="http://arxiv.org/schemas/atom"/>
    <published>2026-05-30T04:49:10Z</published>
    <arxiv:comment>25 pages, 11 figures. Accepted to ISSTA 2026</arxiv:comment>
    <arxiv:primary_category term="cs.SE"/>
    <author>
      <name>Tyler Stennett</name>
    </author>
    <author>
      <name>Rangeet Pan</name>
    </author>
    <author>
      <name>Bridget McGinn</name>
    </author>
    <author>
      <name>Alessandro Orso</name>
    </author>
    <author>
      <name>Saurabh Sinha</name>
    </author>
    <arxiv:doi>10.1145/3832112</arxiv:doi>
    <link rel="related" href="https://doi.org/10.1145/3832112" title="doi"/>
  </entry>
  <entry>
    <id>http://arxiv.org/abs/2605.19652v2</id>
    <title>Characterizing Real-World Bugs in Tile Programs for Automated Bug Detection</title>
    <updated>2026-07-29T03:55:18Z</updated>
    <link href="https://arxiv.org/abs/2605.19652v2" rel="alternate" type="text/html"/>
    <link href="https://arxiv.org/pdf/2605.19652v2" rel="related" type="application/pdf" title="pdf"/>
    <summary>Tile-based programming frameworks are increasingly adopted to write high-performance GPU kernels in domains such as deep learning and scientific computing. While these frameworks enhance productivity and hardware utilization, their multi-stage compilation pipelines introduce distinct code generation bugs that are tightly coupled to input shapes, data types, and backend targets. These bugs often manifest as silent wrong results or performance issues, making them difficult to detect using existing compiler testing tools. Additionally, the unique programming conventions of tile domain-specific languages complicate root cause identification, while fixing such bugs demands specialized knowledge of tile abstractions and compilation pipelines. Despite the growing adoption of tile-based systems, their code generation bugs remain largely unexplored. This paper presents the first systematic study of tile-program code generation bugs. We curate 401 bug reports from GitHub and identify 301 tile-program codegen bugs for analysis, characterizing their root causes and symptoms, the input patterns that trigger them, the test oracles that detect them, and the strategies for fixing these bugs. Our study provides foundational insights for building debugging, testing, and repair tools tailored to tile-based compiler infrastructures.</summary>
    <category term="cs.SE" scheme="http://arxiv.org/schemas/atom"/>
    <published>2026-05-19T10:42:29Z</published>
    <arxiv:comment>In Proceedings of the 35th ACM SIGSOFT International Symposium on Software Testing and Analysis (ISSTA 2026)</arxiv:comment>
    <arxiv:primary_category term="cs.SE"/>
    <author>
      <name>Ravishka Rathnasuriya</name>
    </author>
    <author>
      <name>Zihe Song</name>
    </author>
    <author>
      <name>Nidhi Majoju</name>
    </author>
    <author>
      <name>Aaryaa Moharir</name>
    </author>
    <author>
      <name>Tingxi Li</name>
    </author>
    <author>
      <name>Wei Yang</name>
    </author>
    <author>
      <name>Tao Xie</name>
    </author>
  </entry>
  <entry>
    <id>http://arxiv.org/abs/2605.05282v1</id>
    <title>Beyond BLEU: A Semantic Evaluation Method for Code Translation</title>
    <updated>2026-05-06T17:14:33Z</updated>
    <link href="https://arxiv.org/abs/2605.05282v1" rel="alternate" type="text/html"/>
    <link href="https://arxiv.org/pdf/2605.05282v1" rel="related" type="application/pdf" title="pdf"/>
    <summary>Code translation is one of the core capabilities of LLMs. However, evaluating the correctness of translations remains difficult, as commonly used metrics such as BLEU measure only syntactic similarity, disregarding program semantics. We propose a novel evaluation methodology for code translation tasks, emphasizing semantic equivalence over surface-level string similarity. Our approach applies established compiler testing methodology to a new domain, allowing the assessment of an LLM fine-tuned for binary lifting tasks (i.e. decompiling binaries to higher-level representations). We introduce a semantic correctness score, defined as the proportion of translations that produce correct execution outcomes, and demonstrate its application by evaluating LLM-based and heuristic decompilers. Our findings show that LLM-based approaches significantly outperform heuristic ones, while BLEU scores show negligible correlation with semantic correctness (r = -0.127 to 0.354), demonstrating that syntactic metrics fail to predict functional accuracy.</summary>
    <category term="cs.PL" scheme="http://arxiv.org/schemas/atom"/>
    <category term="cs.CL" scheme="http://arxiv.org/schemas/atom"/>
    <published>2026-05-06T17:14:33Z</published>
    <arxiv:primary_category term="cs.PL"/>
    <author>
      <name>Julius Näumann</name>
    </author>
    <author>
      <name>Sven Keidel</name>
    </author>
    <author>
      <name>Amir Molzam Sharifloo</name>
    </author>
    <author>
      <name>Mira Mezini</name>
    </author>
  </entry>
  <entry>
    <id>http://arxiv.org/abs/2602.16671v1</id>
    <title>SPARC: Scenario Planning and Reasoning for Automated C Unit Test Generation</title>
    <updated>2026-02-18T18:09:03Z</updated>
    <link href="https://arxiv.org/abs/2602.16671v1" rel="alternate" type="text/html"/>
    <link href="https://arxiv.org/pdf/2602.16671v1" rel="related" type="application/pdf" title="pdf"/>
    <summary>Automated unit test generation for C remains a formidable challenge due to the semantic gap between high-level program intent and the rigid syntactic constraints of pointer arithmetic and manual memory management. While Large Language Models (LLMs) exhibit strong generative capabilities, direct intent-to-code synthesis frequently suffers from the leap-to-code failure mode, where models prematurely emit code without grounding in program structure, constraints, and semantics. This will result in non-compilable tests, hallucinated function signatures, low branch coverage, and semantically irrelevant assertions that cannot properly capture bugs. We introduce SPARC, a neuro-symbolic, scenario-based framework that bridges this gap through four stages: (1) Control Flow Graph (CFG) analysis, (2) an Operation Map that grounds LLM reasoning in validated utility helpers, (3) Path-targeted test synthesis, and (4) an iterative, self-correction validation loop using compiler and runtime feedback. We evaluate SPARC on 59 real-world and algorithmic subjects, where it outperforms the vanilla prompt generation baseline by 31.36% in line coverage, 26.01% in branch coverage, and 20.78% in mutation score, matching or exceeding the symbolic execution tool KLEE on complex subjects. SPARC retains 94.3% of tests through iterative repair and produces code with significantly higher developer-rated readability and maintainability. By aligning LLM reasoning with program structure, SPARC provides a scalable path for industrial-grade testing of legacy C codebases.</summary>
    <category term="cs.SE" scheme="http://arxiv.org/schemas/atom"/>
    <category term="cs.AI" scheme="http://arxiv.org/schemas/atom"/>
    <published>2026-02-18T18:09:03Z</published>
    <arxiv:comment>9 pages, 6 figures, 4 tables</arxiv:comment>
    <arxiv:primary_category term="cs.SE"/>
    <author>
      <name>Jaid Monwar Chowdhury</name>
    </author>
    <author>
      <name>Chi-An Fu</name>
    </author>
    <author>
      <name>Reyhaneh Jabbarvand</name>
    </author>
  </entry>
  <entry>
    <id>http://arxiv.org/abs/2602.09942v1</id>
    <title>QEMI: A Quantum Software Stacks Testing Framework via Equivalence Modulo Inputs</title>
    <updated>2026-02-10T16:26:34Z</updated>
    <link href="https://arxiv.org/abs/2602.09942v1" rel="alternate" type="text/html"/>
    <link href="https://arxiv.org/pdf/2602.09942v1" rel="related" type="application/pdf" title="pdf"/>
    <summary>As quantum algorithms and hardware continue to evolve, ensuring the correctness of the quantum software stack (QSS) has become increasingly important. However, testing QSSes remains challenging due to the oracle problem, i.e., the lack of a reliable ground truth for expected program behavior. Existing metamorphic testing approaches often rely on equivalent circuit transformations, backend modifications, or parameter tuning to address this issue. In this work, inspired by Equivalence Modulo Inputs (EMI), we propose Quantum EMI (QEMI), a new testing approach for QSSes. Our key contributions include: (1) a random quantum program generator that produces code with dead code based on quantum control-flow structures, and (2) an adaptation of the EMI technique from classical compiler testing to generate variants by removing dead code. By comparing the behavior of these variants, we can detect potential bugs in QSS implementations. We applied QEMI to Qiskit, Q#, and Cirq, and successfully identified 11 crash bugs and 1 behavioral inconsistency. QEMI expands the limited set of testing techniques available for quantum software stacks by going beyond structural transformations and incorporating semantics-preserving ones into quantum program analysis.</summary>
    <category term="cs.SE" scheme="http://arxiv.org/schemas/atom"/>
    <published>2026-02-10T16:26:34Z</published>
    <arxiv:primary_category term="cs.SE"/>
    <author>
      <name>Junjie Luo</name>
    </author>
    <author>
      <name>Shangzhou Xia</name>
    </author>
    <author>
      <name>Fuyuan Zhang</name>
    </author>
    <author>
      <name>Jianjun Zhao</name>
    </author>
  </entry>
  <entry>
    <id>http://arxiv.org/abs/2602.03712v1</id>
    <title>SWE-Refactor: A Repository-Level Benchmark for Real-World LLM-Based Code Refactoring</title>
    <updated>2026-02-03T16:36:29Z</updated>
    <link href="https://arxiv.org/abs/2602.03712v1" rel="alternate" type="text/html"/>
    <link href="https://arxiv.org/pdf/2602.03712v1" rel="related" type="application/pdf" title="pdf"/>
    <summary>Large Language Models (LLMs) have recently attracted wide interest for tackling software engineering tasks. In contrast to code generation, refactoring demands precise, semantics-preserving edits that improve program structure, which also makes automated evaluation challenging. However, existing refactoring benchmarks commonly suffer from three shortcomings: limited coverage of refactoring scenarios, the inclusion of instances that mix refactoring with unrelated changes, and insufficient repository-level context for realistic assessment. To mitigate these issues, we introduce SWE-Refactor, a new benchmark for LLM-based code refactoring. SWE-Refactor comprises 1,099 developer-written, behavior-preserving refactorings mined from 18 Java projects, including 922 atomic and 177 compound instances. Each instance is validated via compilation, test execution, and automated refactoring detection tools to ensure correctness. We evaluate nine widely used LLMs on SWE-Refactor, covering models such as GPT-4o-mini, DeepSeek-V3, and CodeLLaMa, to provide representative reference results. Our results show that complex and compound refactorings remain the primary source of failures; notably, an OpenAI Codex agent achieves only 39.4% success on compound instances. We release SWE-Refactor and all evaluation results to facilitate future research on LLM-based code refactoring.</summary>
    <category term="cs.SE" scheme="http://arxiv.org/schemas/atom"/>
    <published>2026-02-03T16:36:29Z</published>
    <arxiv:primary_category term="cs.SE"/>
    <author>
      <name>Yisen Xu</name>
      <arxiv:affiliation>Peter</arxiv:affiliation>
    </author>
    <author>
      <name>Jinqiu Yang</name>
      <arxiv:affiliation>Peter</arxiv:affiliation>
    </author>
    <author>
      <name> Tse-Hsun</name>
      <arxiv:affiliation>Peter</arxiv:affiliation>
    </author>
    <author>
      <name> Chen</name>
    </author>
  </entry>
  <entry>
    <id>http://arxiv.org/abs/2601.08995v1</id>
    <title>Build Code is Still Code: Finding the Antidote for Pipeline Poisoning</title>
    <updated>2026-01-13T21:35:18Z</updated>
    <link href="https://arxiv.org/abs/2601.08995v1" rel="alternate" type="text/html"/>
    <link href="https://arxiv.org/pdf/2601.08995v1" rel="related" type="application/pdf" title="pdf"/>
    <summary>Open source C code underpins society's computing infrastructure. Decades of work has helped harden C code against attackers, but C projects do not consist of only C code. C projects also contain build system code for automating development tasks like compilation, testing, and packaging. These build systems are critcal to software supply chain security and vulnerable to being poisoned, with the XZ Utils and SolarWinds attacks being recent examples. Existing techniques try to harden software supply chains by verifying software dependencies, but such methods ignore the build system itself. Similarly, classic software security checkers only analyze and monitor program code, not build system code. Moreover, poisoned build systems can easily circumvent tools for detecting program code vulnerabilities by disabling such checks. We present development phase isolation, a novel strategy for hardening build systems against poisoning by modeling the information and behavior permissions of build automation as if it were program code. We have prototyped this approach as a tool called Foreman, which successfully detects and warns about the poisoned test files involved in the XZ Utils attack. We outline our future plans to protect against pipeline poisoning by automatically checking development phase isolation. We envision a future where build system security checkers are as prevalent as program code checkers.</summary>
    <category term="cs.SE" scheme="http://arxiv.org/schemas/atom"/>
    <published>2026-01-13T21:35:18Z</published>
    <arxiv:comment>2026 IEEE/ACM 48th International Conference on Software Engineering. April 12--18, 2026. Rio de Janeiro, Brazil. 5 pages. 3 figures. 2 code listings. 1 table</arxiv:comment>
    <arxiv:primary_category term="cs.SE"/>
    <author>
      <name>Brent Pappas</name>
    </author>
    <author>
      <name>Paul Gazzillo</name>
    </author>
  </entry>
  <entry>
    <id>http://arxiv.org/abs/2601.04327v1</id>
    <title>ParaCodex: A Profiling-Guided Autonomous Coding Agent for Reliable Parallel Code Generation and Translation</title>
    <updated>2026-01-07T19:04:53Z</updated>
    <link href="https://arxiv.org/abs/2601.04327v1" rel="alternate" type="text/html"/>
    <link href="https://arxiv.org/pdf/2601.04327v1" rel="related" type="application/pdf" title="pdf"/>
    <summary>Parallel programming is central to HPC and AI, but producing code that is correct and fast remains challenging, especially for OpenMP GPU offload, where data movement and tuning dominate. Autonomous coding agents can compile, test, and profile on target hardware, but outputs are brittle without domain scaffolding.
  We present ParaCodex, an HPC-engineer workflow that turns a Codex-based agent into an autonomous OpenMP GPU offload system using staged hotspot analysis, explicit data planning, correctness gating, and profiling-guided refinement. We evaluate translation from serial CPU kernels to OpenMP GPU offload kernels on HeCBench, Rodinia, and NAS. After excluding five kernels, ParaCodex succeeded on all 31 valid kernels. The generated kernels improved GPU time over reference OpenMP implementations in 25/31 cases, achieving geometric-mean speedups of 3x on HeCBench and 5x on Rodinia, and outperforming a zero-shot Codex baseline on all suites. We also evaluate CUDA to OpenMP offload translation on ParEval, where ParaCodex maintains high compilation and validation rates in code-only and end-to-end settings.</summary>
    <category term="cs.DC" scheme="http://arxiv.org/schemas/atom"/>
    <category term="cs.AI" scheme="http://arxiv.org/schemas/atom"/>
    <published>2026-01-07T19:04:53Z</published>
    <arxiv:primary_category term="cs.DC"/>
    <author>
      <name>Erel Kaplan</name>
    </author>
    <author>
      <name>Tomer Bitan</name>
    </author>
    <author>
      <name>Lian Ghrayeb</name>
    </author>
    <author>
      <name>Le Chen</name>
    </author>
    <author>
      <name>Tom Yotam</name>
    </author>
    <author>
      <name>Niranjan Hasabnis</name>
    </author>
    <author>
      <name>Gal Oren</name>
    </author>
  </entry>
  <entry>
    <id>http://arxiv.org/abs/2601.02218v1</id>
    <title>MLIR-Smith: A Novel Random Program Generator for Evaluating Compiler Pipelines</title>
    <updated>2026-01-05T15:43:09Z</updated>
    <link href="https://arxiv.org/abs/2601.02218v1" rel="alternate" type="text/html"/>
    <link href="https://arxiv.org/pdf/2601.02218v1" rel="related" type="application/pdf" title="pdf"/>
    <summary>Compilers are essential for the performance and correct execution of software and hold universal relevance across various scientific disciplines. Despite this, there is a notable lack of tools for testing and evaluating them, especially within the adaptable Multi-Level Intermediate Representation (MLIR) context. This paper addresses the need for a tool that can accommodate MLIR's extensibility, a feature not provided by previous methods such as Csmith. Here we introduce MLIR-Smith, a novel random program generator specifically designed to test and evaluate MLIR-based compiler optimizations. We demonstrate the utility of MLIR-Smith by conducting differential testing on MLIR, LLVM, DaCe, and DCIR, which led to the discovery of multiple bugs in these compiler pipelines. The introduction of MLIR-Smith not only fills a void in the realm of compiler testing but also emphasizes the importance of comprehensive testing within these systems. By providing a tool that can generate random MLIR programs, this paper enhances our ability to evaluate and improve compilers and paves the way for future tools, potentially shaping the wider landscape of software testing and quality assurance.</summary>
    <category term="cs.PL" scheme="http://arxiv.org/schemas/atom"/>
    <category term="cs.SE" scheme="http://arxiv.org/schemas/atom"/>
    <published>2026-01-05T15:43:09Z</published>
    <arxiv:primary_category term="cs.PL"/>
    <author>
      <name>Berke Ates</name>
    </author>
    <author>
      <name>Filip Dobrosavljević</name>
    </author>
    <author>
      <name>Theodoros Theodoridis</name>
    </author>
    <author>
      <name>Zhendong Su</name>
    </author>
  </entry>
  <entry>
    <id>http://arxiv.org/abs/2512.15766v1</id>
    <title>LOOPRAG: Enhancing Loop Transformation Optimization with Retrieval-Augmented Large Language Models</title>
    <updated>2025-12-12T11:09:48Z</updated>
    <link href="https://arxiv.org/abs/2512.15766v1" rel="alternate" type="text/html"/>
    <link href="https://arxiv.org/pdf/2512.15766v1" rel="related" type="application/pdf" title="pdf"/>
    <summary>Loop transformations are semantics-preserving optimization techniques, widely used to maximize objectives such as parallelism. Despite decades of research, applying the optimal composition of loop transformations remains challenging due to inherent complexities, including cost modeling for optimization objectives. Recent studies have explored the potential of Large Language Models (LLMs) for code optimization. However, our key observation is that LLMs often struggle with effective loop transformation optimization, frequently leading to errors or suboptimal optimization, thereby missing opportunities for performance improvements. To bridge this gap, we propose LOOPRAG, a novel retrieval-augmented generation framework designed to guide LLMs in performing effective loop optimization on Static Control Part. We introduce a parameter-driven method to harness loop properties, which trigger various loop transformations, and generate diverse yet legal example codes serving as a demonstration source. To effectively obtain the most informative demonstrations, we propose a loop-aware algorithm based on loop features, which balances similarity and diversity for code retrieval. To enhance correct and efficient code generation, we introduce a feedback-based iterative mechanism that incorporates compilation, testing and performance results as feedback to guide LLMs. Each optimized code undergoes mutation, coverage and differential testing for equivalence checking. We evaluate LOOPRAG on PolyBench, TSVC and LORE benchmark suites, and compare it against compilers (GCC-Graphite, Clang-Polly, Perspective and ICX) and representative LLMs (DeepSeek and GPT-4). The results demonstrate average speedups over base compilers of up to 11.20$\times$, 14.34$\times$, and 9.29$\times$ for PolyBench, TSVC, and LORE, respectively, and speedups over base LLMs of up to 11.97$\times$, 5.61$\times$, and 11.59$\times$.</summary>
    <category term="cs.PL" scheme="http://arxiv.org/schemas/atom"/>
    <category term="cs.AI" scheme="http://arxiv.org/schemas/atom"/>
    <category term="cs.DC" scheme="http://arxiv.org/schemas/atom"/>
    <category term="cs.PF" scheme="http://arxiv.org/schemas/atom"/>
    <published>2025-12-12T11:09:48Z</published>
    <arxiv:comment>Accepted to ASPLOS 2026</arxiv:comment>
    <arxiv:primary_category term="cs.PL"/>
    <author>
      <name>Yijie Zhi</name>
    </author>
    <author>
      <name>Yayu Cao</name>
    </author>
    <author>
      <name>Jianhua Dai</name>
    </author>
    <author>
      <name>Xiaoyang Han</name>
    </author>
    <author>
      <name>Jingwen Pu</name>
    </author>
    <author>
      <name>Qingran Wu</name>
    </author>
    <author>
      <name>Sheng Cheng</name>
    </author>
    <author>
      <name>Ming Cai</name>
    </author>
  </entry>
  <entry>
    <id>http://arxiv.org/abs/2511.05987v3</id>
    <title>High-Performance Generation of Constrained Inputs</title>
    <updated>2026-07-23T23:39:46Z</updated>
    <link href="https://arxiv.org/abs/2511.05987v3" rel="alternate" type="text/html"/>
    <link href="https://arxiv.org/pdf/2511.05987v3" rel="related" type="application/pdf" title="pdf"/>
    <summary>Language-based testing combines context-free grammar definitions with semantic constraints over grammar elements to generate test inputs. By pairing context-free grammars with constraints, users have the expressiveness of unrestricted grammars while retaining simple structure. However, producing inputs in the presence of such constraints can be challenging. In past approaches, SMT solvers have been found to be very slow at finding string solutions; evolutionary algorithms are faster and more general, but current implementations still struggle with complex constraints that would be required for domains such as compiler testing. In this paper, we present a novel approach for evolutionary language-based testing that improves performance by 3-4 orders of magnitude over the current state of the art, reducing hours of generation and constraint solving time to seconds. We accomplish this by (1) carefully transforming grammar definitions into Rust types and trait implementations, ensuring that the compiler may near-maximally optimize arbitrary operations on arbitrary grammars; and (2) using better evolutionary algorithms that improve the ability of language-based testing to solve complex constraint systems. These performance and algorithmic improvements allow our prototype, FANDANGO-RS, to solve constraints that previous strategies simply cannot handle. We demonstrate this by a case study for a C subset, in which FANDANGO-RS is able to generate 401 diverse, complex, and valid test inputs for a C compiler per minute.</summary>
    <category term="cs.SE" scheme="http://arxiv.org/schemas/atom"/>
    <category term="cs.FL" scheme="http://arxiv.org/schemas/atom"/>
    <category term="cs.PL" scheme="http://arxiv.org/schemas/atom"/>
    <published>2025-11-08T12:26:55Z</published>
    <arxiv:primary_category term="cs.SE"/>
    <author>
      <name>Addison Crump</name>
    </author>
    <author>
      <name>Alexi Turcotte</name>
    </author>
    <author>
      <name>José Antonio Zamudio Amaya</name>
    </author>
    <author>
      <name>Andreas Zeller</name>
    </author>
  </entry>
  <entry>
    <id>http://arxiv.org/abs/2509.11173v3</id>
    <title>Your Compiler is Backdooring Your Model: Understanding and Exploiting Compilation Inconsistency Vulnerabilities in Deep Learning Compilers</title>
    <updated>2025-10-27T03:04:50Z</updated>
    <link href="https://arxiv.org/abs/2509.11173v3" rel="alternate" type="text/html"/>
    <link href="https://arxiv.org/pdf/2509.11173v3" rel="related" type="application/pdf" title="pdf"/>
    <summary>Deep learning (DL) compilers are core infrastructure in modern DL systems, offering flexibility and scalability beyond vendor-specific libraries. This work uncovers a fundamental vulnerability in their design: can an official, unmodified compiler alter a model's semantics during compilation and introduce hidden backdoors? We study both adversarial and natural settings. In the adversarial case, we craft benign models where triggers have no effect pre-compilation but become effective backdoors after compilation. Tested on six models, three commercial compilers, and two hardware platforms, our attack yields 100% success on triggered inputs while preserving normal accuracy and remaining undetected by state-of-the-art detectors. The attack generalizes across compilers, hardware, and floating-point settings. In the natural setting, we analyze the top 100 HuggingFace models (including one with 220M+ downloads) and find natural triggers in 31 models. This shows that compilers can introduce risks even without adversarial manipulation.
  Our results reveal an overlooked threat: unmodified DL compilers can silently alter model semantics. To our knowledge, this is the first work to expose inherent security risks in DL compiler design, opening a new direction for secure and trustworthy ML.</summary>
    <category term="cs.CR" scheme="http://arxiv.org/schemas/atom"/>
    <category term="cs.AI" scheme="http://arxiv.org/schemas/atom"/>
    <category term="cs.LG" scheme="http://arxiv.org/schemas/atom"/>
    <category term="cs.SE" scheme="http://arxiv.org/schemas/atom"/>
    <published>2025-09-14T09:11:49Z</published>
    <arxiv:comment>This paper is accepted to IEEE S&amp;P 2026, the code is available at https://github.com/SeekingDream/DLCompilerAttack</arxiv:comment>
    <arxiv:primary_category term="cs.CR"/>
    <author>
      <name>Simin Chen</name>
    </author>
    <author>
      <name>Jinjun Peng</name>
    </author>
    <author>
      <name>Yixin He</name>
    </author>
    <author>
      <name>Junfeng Yang</name>
    </author>
    <author>
      <name>Baishakhi Ray</name>
    </author>
  </entry>
  <entry>
    <id>http://arxiv.org/abs/2508.18955v1</id>
    <title>Interleaving Large Language Models for Compiler Testing</title>
    <updated>2025-08-26T11:49:58Z</updated>
    <link href="https://arxiv.org/abs/2508.18955v1" rel="alternate" type="text/html"/>
    <link href="https://arxiv.org/pdf/2508.18955v1" rel="related" type="application/pdf" title="pdf"/>
    <summary>Testing compilers with AI models, especially large language models (LLMs), has shown great promise. However, current approaches struggle with two key problems: The generated programs for testing compilers are often too simple, and extensive testing with the LLMs is computationally expensive. In this paper, we propose a novel compiler testing framework that decouples the testing process into two distinct phases: an offline phase and an online phase. In the offline phase, we use LLMs to generate a collection of small but feature-rich code pieces. In the online phase, we reuse these code pieces by strategically combining them to build high-quality and valid test programs, which are then used to test compilers.
  We implement this idea in a tool, LegoFuzz, for testing C compilers. The results are striking: we found 66 bugs in GCC and LLVM, the most widely used C compilers. Almost half of the bugs are miscompilation bugs, which are serious and hard-to-find bugs that none of the existing LLM-based tools could find. We believe this efficient design opens up new possibilities for using AI models in software testing beyond just C compilers.</summary>
    <category term="cs.SE" scheme="http://arxiv.org/schemas/atom"/>
    <published>2025-08-26T11:49:58Z</published>
    <arxiv:primary_category term="cs.SE"/>
    <author>
      <name>Yunbo Ni</name>
    </author>
    <author>
      <name>Shaohua Li</name>
    </author>
  </entry>
  <entry>
    <id>http://arxiv.org/abs/2507.21447v2</id>
    <title>LLM4VV: Evaluating Cutting-Edge LLMs for Generation and Evaluation of Directive-Based Parallel Programming Model Compiler Tests</title>
    <updated>2025-08-19T03:08:54Z</updated>
    <link href="https://arxiv.org/abs/2507.21447v2" rel="alternate" type="text/html"/>
    <link href="https://arxiv.org/pdf/2507.21447v2" rel="related" type="application/pdf" title="pdf"/>
    <summary>The usage of Large Language Models (LLMs) for software and test development has continued to increase since LLMs were first introduced, but only recently have the expectations of LLMs become more realistic. Verifying the correctness of code generated by LLMs is key to improving their usefulness, but there have been no comprehensive and fully autonomous solutions developed yet. Hallucinations are a major concern when LLMs are applied blindly to problems without taking the time and effort to verify their outputs, and an inability to explain the logical reasoning of LLMs leads to issues with trusting their results. To address these challenges while also aiming to effectively apply LLMs, this paper proposes a dual-LLM system (i.e. a generative LLM and a discriminative LLM) and experiments with the usage of LLMs for the generation of a large volume of compiler tests. We experimented with a number of LLMs possessing varying parameter counts and presented results using ten carefully-chosen metrics that we describe in detail in our narrative. Through our findings, it is evident that LLMs possess the promising potential to generate quality compiler tests and verify them automatically.</summary>
    <category term="cs.SE" scheme="http://arxiv.org/schemas/atom"/>
    <category term="cs.ET" scheme="http://arxiv.org/schemas/atom"/>
    <published>2025-07-29T02:34:28Z</published>
    <arxiv:primary_category term="cs.SE"/>
    <author>
      <name>Zachariah Sollenberger</name>
    </author>
    <author>
      <name>Rahul Patel</name>
    </author>
    <author>
      <name>Saieda Ali Zada</name>
    </author>
    <author>
      <name>Sunita Chandrasekaran</name>
    </author>
  </entry>
  <entry>
    <id>http://arxiv.org/abs/2506.03909v1</id>
    <title>Solsmith: Solidity Random Program Generator for Compiler Testing</title>
    <updated>2025-06-04T13:04:17Z</updated>
    <link href="https://arxiv.org/abs/2506.03909v1" rel="alternate" type="text/html"/>
    <link href="https://arxiv.org/pdf/2506.03909v1" rel="related" type="application/pdf" title="pdf"/>
    <summary>Smart contracts are computer programs that run on blockchain platforms, with Solidity being the most widely used language for their development. As blockchain technology advances, smart contracts have become increasingly important across various fields. In order for smart contracts to operate correctly, the correctness of the compiler is particularly crucial. Although some research efforts have been devoted to testing Solidity compilers, they primarily focus on testing methods and do not address the core issue of generating test programs. To fill this gap, this paper designs and implements Solsmith, a test program generator specifically aimed at uncovering defects in Solidity compilers. It tests the compiler correctness by generating valid and diverse Solidity programs. We have designed a series of unique program generation strategies tailored to Solidity, including enabling optimizations more frequently, avoiding undefined behaviour, and mitigating behavioural differences caused by intermediate representations. To validate the effectiveness of Solsmith, we assess the effectiveness of the test programs generated by Solsmith using the approach of differential testing. The preliminary results show that Solsmith can generate the expected test programs and uncover four confirmed defects in Solidity compilers, demonstrating the effectiveness and potential of Solsmith.</summary>
    <category term="cs.SE" scheme="http://arxiv.org/schemas/atom"/>
    <published>2025-06-04T13:04:17Z</published>
    <arxiv:comment>11 pages, 12 figures</arxiv:comment>
    <arxiv:primary_category term="cs.SE"/>
    <author>
      <name>Lantian Li</name>
    </author>
    <author>
      <name>Zhihao Liu</name>
    </author>
    <author>
      <name>Zhongxing Yu</name>
    </author>
  </entry>
  <entry>
    <id>http://arxiv.org/abs/2503.20332v7</id>
    <title>Bounded Exhaustive Random Program Generation for Testing Solidity Compilers</title>
    <updated>2025-12-02T10:06:47Z</updated>
    <link href="https://arxiv.org/abs/2503.20332v7" rel="alternate" type="text/html"/>
    <link href="https://arxiv.org/pdf/2503.20332v7" rel="related" type="application/pdf" title="pdf"/>
    <summary>By July 2025, smart contracts collectively manage roughly $120 billion in assets. With Solidity remaining the dominant language for smart contract development, the correctness of Solidity compilers has become critically important. However, Solidity compilers are bug-prone, with a recent study revealing that combinations of qualifiers in Solidity programs are the primary cause of compiler crashes, accounting for 40.5% of all historical crashes. While random program generators are widely used for compiler testing, they may be less effective at finding Solidity compiler bugs because they explore the unbounded space of possible programs rather than concentrating on the specific subspace related to bug-prone qualifiers. A promising idea for finding qualifier-related bugs is to bound the search space based on empirical evidence of where such bugs are likely to occur, specifically focusing test generation to target subspaces with rich combinations of qualifiers. To address this, we propose bounded exhaustive random program generation, a novel approach that dynamically bounds the search space, enhancing the likelihood of uncovering Solidity compiler bugs. Specifically, our method bounds the search space by generating valid program templates that abstract programs that use bug-prone qualifiers, and then uses these templates as a basis for compiler testing through exhaustive enumeration of suitable qualifiers. Mechanisms are devised to address technical challenges regarding validity and efficiency. We have implemented our novel generation approach in a new tool, Erwin. We have used Erwin to find and report 26 bugs across two Solidity compilers, solc and solang, and one Solidity static analyzer, slither. Among these, 23 were previously unknown, 18 have been confirmed, and 10 have been fixed. Evaluation results demonstrate that Erwin outperforms state-of-the-art Solidity fuzzers in bug detection.</summary>
    <category term="cs.PL" scheme="http://arxiv.org/schemas/atom"/>
    <published>2025-03-26T08:58:00Z</published>
    <arxiv:primary_category term="cs.PL"/>
    <author>
      <name>Haoyang Ma</name>
    </author>
    <author>
      <name>Alastair F. Donaldson</name>
    </author>
    <author>
      <name>Qingchao Shen</name>
    </author>
    <author>
      <name>Yongqiang Tian</name>
    </author>
    <author>
      <name>Junjie Chen</name>
    </author>
    <author>
      <name>Shing-Chi Cheung</name>
    </author>
    <arxiv:doi>10.1145/3744916.3773237</arxiv:doi>
    <link rel="related" href="https://doi.org/10.1145/3744916.3773237" title="doi"/>
  </entry>
  <entry>
    <id>http://arxiv.org/abs/2501.11940v1</id>
    <title>Build Optimization: A Systematic Literature Review</title>
    <updated>2025-01-21T07:32:06Z</updated>
    <link href="https://arxiv.org/abs/2501.11940v1" rel="alternate" type="text/html"/>
    <link href="https://arxiv.org/pdf/2501.11940v1" rel="related" type="application/pdf" title="pdf"/>
    <summary>Continuous Integration (CI) consists of an automated build process involving continuous compilation, testing, and packaging of the software system. While CI comes up with several advantages related to quality and time to delivery, CI also presents several challenges addressed by a large body of research. To better understand the literature so as to help practitioners find solutions for their problems and guide future research, we conduct a systematic review of 97 studies on build optimization published between 2006 and 2024, which we summarized according to their goals, methodologies, used datasets, and leveraged metrics. The identified build optimization studies focus on two main challenges: (1) long build durations, and (2) build failures. To meet the first challenge, existing studies have developed a range of techniques, including predicting build outcome and duration, selective build execution, and build acceleration using caching or repairing performance smells. The causes of build failures have been the subject of several studies, leading to the development of techniques for predicting build script maintenance and automating repair. Recent studies have also focused on predicting flaky build failures caused by environmental issues. The majority of these techniques use machine learning algorithms and leverage build metrics, which we classify into five categories. Additionally, we identify eight publicly available build datasets for build optimization research.</summary>
    <category term="cs.SE" scheme="http://arxiv.org/schemas/atom"/>
    <published>2025-01-21T07:32:06Z</published>
    <arxiv:comment>An earlier version of this work was submitted to ACM CSUR in November 2023</arxiv:comment>
    <arxiv:primary_category term="cs.SE"/>
    <author>
      <name>Henri Aïdasso</name>
    </author>
    <author>
      <name>Mohammed Sayagh</name>
    </author>
    <author>
      <name>Francis Bordeleau</name>
    </author>
    <arxiv:doi>10.1145/3757912</arxiv:doi>
    <link rel="related" href="https://doi.org/10.1145/3757912" title="doi"/>
  </entry>
  <entry>
    <id>http://arxiv.org/abs/2408.00433v1</id>
    <title>ShellFuzzer: Grammar-based Fuzzing of Shell Interpreters</title>
    <updated>2024-08-01T10:10:24Z</updated>
    <link href="https://arxiv.org/abs/2408.00433v1" rel="alternate" type="text/html"/>
    <link href="https://arxiv.org/pdf/2408.00433v1" rel="related" type="application/pdf" title="pdf"/>
    <summary>Despite its long-standing popularity and fundamental role in an operating system, the Unix shell has rarely been a subject of academic research. In particular, regardless of the significant progress in compiler testing, there has been hardly any work applying automated testing techniques to detect faults and vulnerabilities in shell interpreters.
  To address this important shortcoming, we present ShellFuzzer: a technique to test Unix shell interpreters by automatically generating a large number of shell scripts. ShellFuzzer combines grammar-based generation with selected random mutations, so as to produce a diverse range of shell programs with predictable characteristics (e.g., valid according to the language standard, and free from destructive behavior).
  In our experimental evaluation, ShellFuzzer generated shell programs that exposed 8 previously unknown issues that affected a recent version of the mksh POSIX-compliant shell; the shell maintainers confirmed 7 of these issues, and addressed them in the latest revisions of the shell's open-source implementation.</summary>
    <category term="cs.SE" scheme="http://arxiv.org/schemas/atom"/>
    <published>2024-08-01T10:10:24Z</published>
    <arxiv:primary_category term="cs.SE"/>
    <author>
      <name>Riccardo Felici</name>
    </author>
    <author>
      <name>Laura Pozzi</name>
    </author>
    <author>
      <name>Carlo A. Furia</name>
    </author>
  </entry>
  <entry>
    <id>http://arxiv.org/abs/2407.16626v2</id>
    <title>A Tale of Two DL Cities: When Library Tests Meet Compiler</title>
    <updated>2024-08-14T14:25:37Z</updated>
    <link href="https://arxiv.org/abs/2407.16626v2" rel="alternate" type="text/html"/>
    <link href="https://arxiv.org/pdf/2407.16626v2" rel="related" type="application/pdf" title="pdf"/>
    <summary>Deep Learning (DL) compilers typically load a DL model and optimize it with intermediate representation.Existing DL compiler testing techniques mainly focus on model optimization stages, but rarely explore bug detection at the model loading stage. Effectively testing the model loading stage requires covering diverse usages of each DL operator from various DL libraries, which shares a common objective with DL library testing, indicating that the embedded knowledge in DL library tests is beneficial for testing the model loading stage of DL compilers. In this work, we propose OPERA to extract such domain knowledge from the test inputs for DL libraries. OPERA constructs diverse tests from the various test inputs for DL libraries (including the test inputs documented in DL libraries and those generated by recent fuzzers). In addition, it incorporates a diversity-based test prioritization strategy to migrate and execute those test inputs that are more likely to detect diverse bugs earlier. We considered three sources of tests in DL libraries for migration and used eight frontends from three DL compilers (e.g., TVM, TensorRT, and OpenVINO) for evaluation. OPERA detected 170 previously unknown bugs in total, 90 of which have been confirmed/fixed by developers, demonstrating the effectiveness of such the migration-based idea. The test prioritization strategy in OPERA improves testing efficiency with migrated tests by 11.9%~47.4% on average compared to general test prioritization strategies.</summary>
    <category term="cs.SE" scheme="http://arxiv.org/schemas/atom"/>
    <published>2024-07-23T16:35:45Z</published>
    <arxiv:comment>This paper has been accepted by ICSE'2025</arxiv:comment>
    <arxiv:primary_category term="cs.SE"/>
    <author>
      <name>Qingchao Shen</name>
    </author>
    <author>
      <name>Yongqiang Tian</name>
    </author>
    <author>
      <name>Haoyang Ma</name>
    </author>
    <author>
      <name>Junjie Chen</name>
    </author>
    <author>
      <name>Lili Huang</name>
    </author>
    <author>
      <name>Ruifeng Fu</name>
    </author>
    <author>
      <name>Shing-Chi Cheung</name>
    </author>
    <author>
      <name>Zan Wang</name>
    </author>
  </entry>
  <entry>
    <id>http://arxiv.org/abs/2407.03274v1</id>
    <title>Using Photoplethysmography to Detect Real-time Blood Pressure Changes with a Calibration-free Deep Learning Model</title>
    <updated>2024-07-03T17:00:47Z</updated>
    <link href="https://arxiv.org/abs/2407.03274v1" rel="alternate" type="text/html"/>
    <link href="https://arxiv.org/pdf/2407.03274v1" rel="related" type="application/pdf" title="pdf"/>
    <summary>Blood pressure (BP) changes are linked to individual health status in both clinical and non-clinical settings. This study developed a deep learning model to classify systolic (SBP), diastolic (DBP), and mean (MBP) BP changes using photoplethysmography (PPG) waveforms. Data from the Vital Signs Database (VitalDB) comprising 1,005 ICU patients with synchronized PPG and BP recordings was used. BP changes were categorized into three labels: Spike (increase above a threshold), Stable (change within a plus or minus threshold), and Dip (decrease below a threshold). Four time-series classification models were studied: multi-layer perceptron, convolutional neural network, residual network, and Encoder. A subset of 500 patients was randomly selected for training and validation, ensuring a uniform distribution across BP change labels. Two test datasets were compiled: Test-I (n=500) with a uniform distribution selection process, and Test-II (n=5) without. The study also explored the impact of including second-deviation PPG (sdPPG) waveforms as additional input information. The Encoder model with a Softmax weighting process using both PPG and sdPPG waveforms achieved the highest detection accuracy--exceeding 71.3% and 85.4% in Test-I and Test-II, respectively, with thresholds of 30 mmHg for SBP, 15 mmHg for DBP, and 20 mmHg for MBP. Corresponding F1-scores were over 71.8% and 88.5%. These findings confirm that PPG waveforms are effective for real-time monitoring of BP changes in ICU settings and suggest potential for broader applications.</summary>
    <category term="eess.SP" scheme="http://arxiv.org/schemas/atom"/>
    <published>2024-07-03T17:00:47Z</published>
    <arxiv:comment>8 pages, 5 figures, 7 tables, 1 supplementary material</arxiv:comment>
    <arxiv:primary_category term="eess.SP"/>
    <author>
      <name>Jingyuan Hong</name>
    </author>
    <author>
      <name>Manasi Nandi</name>
    </author>
    <author>
      <name>Weiwei Jin</name>
    </author>
    <author>
      <name>Jordi Alastruey</name>
    </author>
  </entry>
  <entry>
    <id>http://arxiv.org/abs/2401.09474v1</id>
    <title>Weak Memory Demands Model-based Compiler Testing</title>
    <updated>2024-01-12T15:50:32Z</updated>
    <link href="https://arxiv.org/abs/2401.09474v1" rel="alternate" type="text/html"/>
    <link href="https://arxiv.org/pdf/2401.09474v1" rel="related" type="application/pdf" title="pdf"/>
    <summary>A compiler bug arises if the behaviour of a compiled concurrent program, as allowed by its architecture memory model, is not a behaviour permitted by the source program under its source model. One might reasonably think that most compiler bugs have been found in the decade since the introduction of the C/C++ memory model. We observe that processor implementations are increasingly exploiting the behaviour of relaxed architecture models. As such, compiled programs may exhibit bugs not seen on older hardware. To account for this we require model-based compiler testing.
  While this observation is not surprising, its implications are broad. Compilers and their testing tools will need to be updated to follow hardware relaxations, concurrent test generators will need to be improved, and assumptions of prior work will need revisiting. We explore these ideas using a compiler toolchain bug we reported in LLVM.</summary>
    <category term="cs.PL" scheme="http://arxiv.org/schemas/atom"/>
    <category term="cs.AR" scheme="http://arxiv.org/schemas/atom"/>
    <category term="cs.SE" scheme="http://arxiv.org/schemas/atom"/>
    <published>2024-01-12T15:50:32Z</published>
    <arxiv:comment>2 pages, Presented at The Future of Weak Memory Workshop, 2024 at the 51st ACM SIGPLAN Symposium on Principles of Programming Languages (POPL 2024)</arxiv:comment>
    <arxiv:primary_category term="cs.PL"/>
    <author>
      <name>Luke Geeson</name>
    </author>
  </entry>
  <entry>
    <id>http://arxiv.org/abs/2401.01036v1</id>
    <title>PTE: Axiomatic Semantics based Compiler Testing</title>
    <updated>2024-01-02T04:50:47Z</updated>
    <link href="https://arxiv.org/abs/2401.01036v1" rel="alternate" type="text/html"/>
    <link href="https://arxiv.org/pdf/2401.01036v1" rel="related" type="application/pdf" title="pdf"/>
    <summary>The correctness of a compiler affects the correctness of every program written in the language, and thus must be thoroughly evaluated. Existing automatic compiler testing methods however either rely on weak oracles (e.g., a program behaves the same if only dead code is modified), or require substantial initial effort (e.g., having a complete operational language semantics). While the former prevents a comprehensive correctness evaluation, the latter makes those methods irrelevant in practice. In this work, we propose an axiomatic semantics based approach for testing compilers, called PTE. The idea is to incrementally develop a set of ``axioms'' capturing anecdotes of the language semantics in the form of \emph{(\textbf{p}recondition, \textbf{t}ransformation, \textbf{e}xpectation) triples, which allows us to test the compiler automatically.} Such axioms are written in the same language whose compiler is under test, and can be developed either based on the language specification, or by generalizing the bug reports. PTE has been applied to a newly developed compiler (i.e., Cangjie) and a mature compiler (i.e., Java), and successfully identified 42 implementation bugs and 9 potential language design issues.</summary>
    <category term="cs.SE" scheme="http://arxiv.org/schemas/atom"/>
    <published>2024-01-02T04:50:47Z</published>
    <arxiv:primary_category term="cs.SE"/>
    <author>
      <name>Guoliang Dong</name>
    </author>
    <author>
      <name>Jun Sun</name>
    </author>
    <author>
      <name>Richard Schumi</name>
    </author>
    <author>
      <name>Bo Wang</name>
    </author>
    <author>
      <name>Xinyu Wang</name>
    </author>
  </entry>
  <entry>
    <id>http://arxiv.org/abs/2311.01515v1</id>
    <title>Implementation and Synthesis of Math Library Functions</title>
    <updated>2023-11-02T18:03:02Z</updated>
    <link href="https://arxiv.org/abs/2311.01515v1" rel="alternate" type="text/html"/>
    <link href="https://arxiv.org/pdf/2311.01515v1" rel="related" type="application/pdf" title="pdf"/>
    <summary>Achieving speed and accuracy for math library functions like exp, sin, and log is difficult. This is because low-level implementation languages like C do not help math library developers catch mathematical errors, build implementations incrementally, or separate high-level and low-level decision making. This ultimately puts development of such functions out of reach for all but the most experienced experts. To address this, we introduce MegaLibm, a domain-specific language for implementing, testing, and tuning math library implementations. MegaLibm is safe, modular, and tunable. Implementations in MegaLibm can automatically detect mathematical mistakes like sign flips via semantic wellformedness checks, and components like range reductions can be implemented in a modular, composable way, simplifying implementations. Once the high-level algorithm is done, tuning parameters like working precisions and evaluation schemes can be adjusted through orthogonal tuning parameters to achieve the desired speed and accuracy. MegaLibm also enables math library developers to work interactively, compiling, testing, and tuning their implementations and invoking tools like Sollya and type-directed synthesis to complete components and synthesize entire implementations. MegaLibm can express 8 state-of-the-art math library implementations with comparable speed and accuracy to the original C code, and can synthesize 5 variations and 3 from-scratch implementations with minimal guidance.</summary>
    <category term="cs.PL" scheme="http://arxiv.org/schemas/atom"/>
    <published>2023-11-02T18:03:02Z</published>
    <arxiv:comment>25 pages, 12 figures</arxiv:comment>
    <arxiv:primary_category term="cs.PL"/>
    <author>
      <name>Ian Briggs</name>
    </author>
    <author>
      <name>Yash Lad</name>
    </author>
    <author>
      <name>Pavel Panchekha</name>
    </author>
  </entry>
  <entry>
    <id>http://arxiv.org/abs/2310.15991v3</id>
    <title>WhiteFox: White-Box Compiler Fuzzing Empowered by Large Language Models</title>
    <updated>2024-09-04T18:25:09Z</updated>
    <link href="https://arxiv.org/abs/2310.15991v3" rel="alternate" type="text/html"/>
    <link href="https://arxiv.org/pdf/2310.15991v3" rel="related" type="application/pdf" title="pdf"/>
    <summary>Compiler correctness is crucial, as miscompilation can falsify program behaviors, leading to serious consequences. Fuzzing has been studied to uncover compiler defects. However, compiler fuzzing remains challenging: Existing arts focus on black- and grey-box fuzzing, which generates tests without sufficient understanding of internal compiler behaviors. Meanwhile, traditional white-box techniques, like symbolic execution, are computationally inapplicable to the giant codebase of compilers. Recent advances demonstrate that Large Language Models (LLMs) excel in code generation/understanding tasks. Nonetheless, guiding LLMs with compiler source-code information remains a missing piece of research in compiler testing.
  To this end, we propose WhiteFox, the first white-box compiler fuzzer using LLMs with source-code information to test compiler optimization, with a spotlight on detecting deep logic bugs in the deep learning (DL) compilers. WhiteFox adopts a multi-agent framework: an LLM-based analysis agent examines the low-level optimization source code and produces requirements on the high-level test programs that can trigger the optimization; an LLM-based generation agent produces test programs based on the summarized requirements. Additionally, optimization-triggering tests are used as feedback to enhance the generation on the fly. Our evaluation on the three most popular DL compilers (i.e., PyTorch Inductor, TensorFlow-XLA, and TensorFlow Lite) shows WhiteFox can generate high-quality test programs to exercise deep optimizations, practicing up to 8X more than state-of-the-art fuzzers. WhiteFox has found 101 bugs for the DL compilers, with 92 confirmed as previously unknown and 70 fixed. WhiteFox has been acknowledged by the PyTorch team and is being incorporated into its development workflow. Beyond DL compilers, WhiteFox can also be adapted for compilers in different domains.</summary>
    <category term="cs.SE" scheme="http://arxiv.org/schemas/atom"/>
    <category term="cs.LG" scheme="http://arxiv.org/schemas/atom"/>
    <category term="cs.PL" scheme="http://arxiv.org/schemas/atom"/>
    <published>2023-10-24T16:39:06Z</published>
    <arxiv:comment>Published in OOPSLA 2024</arxiv:comment>
    <arxiv:primary_category term="cs.SE"/>
    <arxiv:journal_ref>Proc. ACM Program. Lang., Vol. 8, No. OOPSLA2, Article 296. Publication date: October 2024</arxiv:journal_ref>
    <author>
      <name>Chenyuan Yang</name>
    </author>
    <author>
      <name>Yinlin Deng</name>
    </author>
    <author>
      <name>Runyu Lu</name>
    </author>
    <author>
      <name>Jiayi Yao</name>
    </author>
    <author>
      <name>Jiawei Liu</name>
    </author>
    <author>
      <name>Reyhaneh Jabbarvand</name>
    </author>
    <author>
      <name>Lingming Zhang</name>
    </author>
    <arxiv:doi>10.1145/3689736</arxiv:doi>
    <link rel="related" href="https://doi.org/10.1145/3689736" title="doi"/>
  </entry>
  <entry>
    <id>http://arxiv.org/abs/2310.12337v3</id>
    <title>Compiler Testing With Relaxed Memory Models</title>
    <updated>2024-01-29T20:38:43Z</updated>
    <link href="https://arxiv.org/abs/2310.12337v3" rel="alternate" type="text/html"/>
    <link href="https://arxiv.org/pdf/2310.12337v3" rel="related" type="application/pdf" title="pdf"/>
    <summary>Finding bugs is key to the correctness of compilers in wide use today. If the behaviour of a compiled program, as allowed by its architecture memory model, is not a behaviour of the source program under its source model, then there is a bug. This holds for all programs, but we focus on concurrency bugs that occur only with two or more threads of execution. We focus on testing techniques that detect such bugs in C/C++ compilers.
  We seek a testing technique that automatically covers concurrency bugs up to fixed bounds on program sizes and that scales to find bugs in compiled programs with many lines of code. Otherwise, a testing technique can miss bugs. Unfortunately, the state-of-the-art techniques are yet to satisfy all of these properties.
  We present the Téléchat compiler testing tool for concurrent programs. Téléchat compiles a concurrent C/C++ program and compares source and compiled program behaviours using source and architecture memory models. We make three claims: Téléchat improves the state-of-the-art at finding bugs in code generation for multi-threaded execution, it is the first public description of a compiler testing tool for concurrency that is deployed in industry, and it is the first tool that takes a significant step towards the desired properties. We provide experimental evidence suggesting Téléchat finds bugs missed by other state-of-the-art techniques, case studies indicating that Téléchat satisfies the properties, and reports of our experience deploying Téléchat in industry regression testing.</summary>
    <category term="cs.PL" scheme="http://arxiv.org/schemas/atom"/>
    <category term="cs.AR" scheme="http://arxiv.org/schemas/atom"/>
    <category term="cs.SE" scheme="http://arxiv.org/schemas/atom"/>
    <published>2023-10-18T21:24:26Z</published>
    <arxiv:comment>12 pages, Accepted to IEEE/ACM International Symposium on Code Generation and Optimization</arxiv:comment>
    <arxiv:primary_category term="cs.PL"/>
    <author>
      <name>Luke Geeson</name>
    </author>
    <author>
      <name>Lee Smith</name>
    </author>
  </entry>
  <entry>
    <id>http://arxiv.org/abs/2305.04207v3</id>
    <title>No More Manual Tests? Evaluating and Improving ChatGPT for Unit Test Generation</title>
    <updated>2024-05-19T08:51:14Z</updated>
    <link href="https://arxiv.org/abs/2305.04207v3" rel="alternate" type="text/html"/>
    <link href="https://arxiv.org/pdf/2305.04207v3" rel="related" type="application/pdf" title="pdf"/>
    <summary>Unit testing is essential in detecting bugs in functionally-discrete program units. Manually writing high-quality unit tests is time-consuming and laborious. Although traditional techniques can generate tests with reasonable coverage, they exhibit low readability and cannot be directly adopted by developers. Recent work has shown the large potential of large language models (LLMs) in unit test generation, which can generate more human-like and meaningful test code. ChatGPT, the latest LLM incorporating instruction tuning and reinforcement learning, has performed well in various domains. However, It remains unclear how effective ChatGPT is in unit test generation.
  In this work, we perform the first empirical study to evaluate ChatGPT's capability of unit test generation. Specifically, we conduct a quantitative analysis and a user study to systematically investigate the quality of its generated tests regarding the correctness, sufficiency, readability, and usability. The tests generated by ChatGPT still suffer from correctness issues, including diverse compilation errors and execution failures. Still, the passing tests generated by ChatGPT resemble manually-written tests by achieving comparable coverage, readability, and even sometimes developers' preference. Our findings indicate that generating unit tests with ChatGPT could be very promising if the correctness of its generated tests could be further improved.
  Inspired by our findings above, we propose ChatTESTER, a novel ChatGPT-based unit test generation approach, which leverages ChatGPT itself to improve the quality of its generated tests. ChatTESTER incorporates an initial test generator and an iterative test refiner. Our evaluation demonstrates the effectiveness of ChatTESTER by generating 34.3% more compilable tests and 18.7% more tests with correct assertions than the default ChatGPT.</summary>
    <category term="cs.SE" scheme="http://arxiv.org/schemas/atom"/>
    <published>2023-05-07T07:17:08Z</published>
    <arxiv:primary_category term="cs.SE"/>
    <author>
      <name>Zhiqiang Yuan</name>
    </author>
    <author>
      <name>Yiling Lou</name>
    </author>
    <author>
      <name>Mingwei Liu</name>
    </author>
    <author>
      <name>Shiji Ding</name>
    </author>
    <author>
      <name>Kaixin Wang</name>
    </author>
    <author>
      <name>Yixuan Chen</name>
    </author>
    <author>
      <name>Xin Peng</name>
    </author>
  </entry>
  <entry>
    <id>http://arxiv.org/abs/2302.00842v3</id>
    <title>Effective Random Test Generation for Deep Learning Compilers</title>
    <updated>2024-12-26T07:34:35Z</updated>
    <link href="https://arxiv.org/abs/2302.00842v3" rel="alternate" type="text/html"/>
    <link href="https://arxiv.org/pdf/2302.00842v3" rel="related" type="application/pdf" title="pdf"/>
    <summary>Deep learning compilers help address the difficulties of deploying deep learning models on diverse types of hardware. Testing deep learning compilers is highly crucial, because they are impacting countless AI applications that use them for model optimization and deployment. To test deep learning compilers, random testing, the testing method popularly used for compiler testing practices, faces the challenge of generating semantically valid test inputs, i.e., deep learning models that satisfy the semantic model specifications (in short as semantic specifications). To tackle this challenge, in this paper, we propose a novel approach named Isra, including a domain-specific constraint solver that resolves the constraints from the semantic specifications without backtracking. We implement and apply our approach to three popular real-world deep learning compilers including TVM, Glow, and a commercial compiler named SophGo. The evaluation results show that Isra is more effective than the state-of-the-art approaches and the baseline approaches on constructing valid test inputs for compiler-bug detection, and Isra successfully finds 24 previously unknown bugs in released versions of the three compilers. These results indicate Isra's effectiveness and practical value.</summary>
    <category term="cs.SE" scheme="http://arxiv.org/schemas/atom"/>
    <published>2023-02-02T03:00:36Z</published>
    <arxiv:primary_category term="cs.SE"/>
    <author>
      <name>Luyao Ren</name>
    </author>
    <author>
      <name>ZiHeng Wang</name>
    </author>
    <author>
      <name>Yingfei Xiong</name>
    </author>
    <author>
      <name>Li Zhang</name>
    </author>
    <author>
      <name>Guoyue Jiang</name>
    </author>
    <author>
      <name>Tao Xie</name>
    </author>
  </entry>
  <entry>
    <id>http://arxiv.org/abs/2209.04514v1</id>
    <title>Compiler Testing using Template Java Programs</title>
    <updated>2022-09-09T20:31:38Z</updated>
    <link href="https://arxiv.org/abs/2209.04514v1" rel="alternate" type="text/html"/>
    <link href="https://arxiv.org/pdf/2209.04514v1" rel="related" type="application/pdf" title="pdf"/>
    <summary>We present JAttack, a framework that enables template-based testing for compilers. Using JAttack, a developer writes a template program that describes a set of programs to be generated and given as test inputs to a compiler. Such a framework enables developers to incorporate their domain knowledge on testing compilers, giving a basic program structure that allows for exploring complex programs that can trigger sophisticated compiler optimizations. A developer writes a template program in the host language (Java) that contains holes to be filled by JAttack. Each hole, written using a domain-specific language, constructs a node within an extended abstract syntax tree (eAST). An eAST node defines the search space for the hole, i.e., a set of expressions and values. JAttack generates programs by executing templates and filling each hole by randomly choosing expressions and values (available within the search space defined by the hole). Additionally, we introduce several optimizations to reduce JAttack's generation cost. While JAttack could be used to test various compiler features, we demonstrate its capabilities in helping test just-in-time (JIT) Java compilers, whose optimizations occur at runtime after a sufficient number of executions. Using JAttack, we have found six critical bugs that were confirmed by Oracle developers. Four of them were previously unknown, including two unknown CVEs (Common Vulnerabilities and Exposures). JAttack shows the power of combining developers' domain knowledge (via templates) with random testing to detect bugs in JIT compilers.</summary>
    <category term="cs.PL" scheme="http://arxiv.org/schemas/atom"/>
    <category term="cs.SE" scheme="http://arxiv.org/schemas/atom"/>
    <published>2022-09-09T20:31:38Z</published>
    <arxiv:comment>13 pages, 6 figures, 2 tables, accepted in ASE 2022 (Research Papers track)</arxiv:comment>
    <arxiv:primary_category term="cs.PL"/>
    <author>
      <name>Zhiqiang Zang</name>
    </author>
    <author>
      <name>Nathan Wiatrek</name>
    </author>
    <author>
      <name>Milos Gligoric</name>
    </author>
    <author>
      <name>August Shi</name>
    </author>
    <arxiv:doi>10.1145/3551349.3556958</arxiv:doi>
    <link rel="related" href="https://doi.org/10.1145/3551349.3556958" title="doi"/>
  </entry>
</feed>
