Pith. sign in

REVIEW 3 major objections 4 minor 40 references

GapForge argues that treating compiler coverage gaps as explicit region-level targets—inferring the program structures and compilation flags needed to reach each uncovered span—lets LLM-guided fuzzing cover 68.13% of core GCC and 69.11% of

Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

T0 review · deepseek-v4-flash

2026-08-01 22:23 UTC pith:J3TRBBVT

load-bearing objection Genuine novelty in targeting coverage gaps, but the single-run stochastic evaluation makes the headline margins provisional. the 3 major comments →

arxiv 2607.15762 v1 pith:J3TRBBVT submitted 2026-07-17 cs.SE

GapForge: Directed Compiler Fuzzing via Coverage-Gap Analysis

Mingxuan Zhu , Qingyuan Liang , Junjie Chen , Zhihong Xue , Dan Hao This is my paper
classification cs.SE
keywords compiler fuzzingcoverage-guided testingLLM-based test generationcoverage gapspath-difference analysistriggering requirementscompiler failuresGCC and LLVM
verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper sets out to close the long-tail coverage gaps that persist in large compilers because existing test generators keep re-exercising the same hotspot paths. Its proposal, GapForge, turns each uncovered line span into an explicit target: it scores files by size and under-coverage, has an LLM compare the uncovered span with its immediately surrounding covered code to infer the triggering requirements (program structures and compiler flags), then synthesizes prompts that incorporate previously failed attempts. The paper reports that within 72 hours this reaches 68.13% coverage of core GCC and 69.11% of core LLVM, adds thousands of lines beyond the compilers' own test suites, and surfaces 12 real-world failures, 8 crashes and 4 miscompilations. A sympathetic reader would care because it suggests coverage feedback can be converted into precise, actionable guidance for LLM test generation rather than coarse file-level summaries.

Core claim

On the paper's own terms, GapForge's central discovery is that coverage gaps, not programs, should be the unit of targeting in compiler fuzzing. Each iteration selects a file with a score S_f = L_f × (1 − C_f)^2, converted into a selection probability P_f = 1 − (1 − W_f)^k to avoid over-concentrating on the hottest undercovered file. For the chosen file, the uncovered line span is paired with its enclosing covered context and the LLM performs path-difference analysis to emit Target Requirements: a coverage goal, per-basic-block program-structure constraints, and required compilation options. A prompt is then assembled from these requirements plus a randomly retrieved previously failed prompt

What carries the argument

The load-bearing mechanism is the 'triggering requirement' inference via path-difference analysis. Given an uncovered line span and the covered lines immediately enclosing it, the LLM is asked to reason about what input characteristics would steer control flow into the uncovered region and which compilation options activate that path; the output is a structured spec of per-basic-block program structures and flags. This spec is the interface between coverage data and test generation: it converts a static gap into a prompt constraint. A secondary mechanism is the selection-probability transform P_f = 1 − (1 − W_f)^k, which tempers the dominance of high-scoring files and keeps the campaign expl

Load-bearing premise

The load-bearing premise is that a single LLM pass over an uncovered line span plus its immediately enclosing covered lines yields correct triggering requirements (program structures and compilation options); if those inferred requirements are wrong or incomplete, the generated tests miss the target and the whole gain collapses.

What would settle it

Measure the per-region hit rate: for each uncovered basic block targeted by GapForge, compute the fraction of generated programs that actually execute that block. If the hit rate is close to that of a control that uses the same covered context but with shuffled or random requirement prompts, or if removing the covered-context step leaves coverage unchanged, then the claimed path-difference analysis is not the cause of the gains. A second check: run GapForge with the recommended compilation options stripped but a note telling the LLM to guess options; if coverage drops far less than the reporte

Watch this falsifier. Get emailed when new claim-graph text bears on it.

If this is right

  • Coverage-driven file selection can be lifted out and applied to other white-box fuzzers: the paper shows that grafting its target selection onto a whole-file-summarization technique recovers hundreds of newly covered lines on both compilers, even though it still trails full GapForge.
  • Compilation-option inference is the single largest contributor among the components: ablations that remove option recommendations lose about 19,480 covered lines, the biggest drop of any variant, implying option-gated paths are a major untapped source of coverage.
  • Failure reflection becomes more valuable as the campaign lengthens: only 6 informative failure cases accumulate in 24 hours but 22 in 72 hours, so its contribution should grow on longer budgets.
  • Because GapForge covers 36.29%/39.75% of the hard-to-cover files (below 30% average coverage for other techniques) versus about 27%/30% for the strongest baseline, the paper claims explicit gap reasoning reaches regions that resist all eight compared techniques.
  • The same loop, with roughly half the token budget of the close white-box baseline, achieves higher coverage, suggesting targeted context is cheaper than whole-file summarization.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • The paper does not report per-region hit rates: how often a generated program actually executes the specific uncovered basic block it was aimed at. A direct measurement of that rate would isolate whether the LLM's requirement inference is genuinely steering generation or merely improving program diversity.
  • The mechanism should transfer beyond compilers to any coverage-instrumented tool with option-gated paths—static analyzers, linkers, JITs, or circuit tools—where LLM-generated inputs can be steered by the same covered-context/uncovered-span contrast.
  • Since failure reflection operates at file level, a future refinement could rank failures by how much partial coverage they incidentally produced and reuse the best partial successes, not just the failures, as few-shot seeds.
  • The paper's own threats section notes that line coverage is the only metric and that CPU-based random generators share hardware with GPU-accelerated LLM approaches, so per-program generation counts are not directly comparable; a branch/path-coverage replication would test whether the gains persist.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit.

Referee Report

3 major / 4 minor

Summary. The paper presents GapForge, an LLM-based compiler fuzzing technique that uses coverage gaps as explicit region-level targets. Given a compiler codebase and initial coverage, GapForge iteratively selects undercovered files using a coverage-driven score, infers per-region triggering requirements (program structure and compilation options) via an LLM that contrasts uncovered line spans with their covered context, and synthesizes prompts that incorporate previously failed prompts. The approach is evaluated on GCC 14.3.0 and LLVM 19.1.0 against eight baselines, reporting that within 72 hours GapForge reaches 68.13% and 69.11% coverage on core modules, exceeding WhiteFox by 24,736 and 19,798 lines, and discovers 12 real compiler failures (8 crashes, 4 miscompilations). Ablation studies and LLM-sensitivity experiments are also reported.

Significance. If the empirical claims hold, GapForge is a meaningful contribution: it is one of the few compiler fuzzing approaches that explicitly reasons about uncovered code regions rather than generating diverse inputs or summarizing whole files. The pipeline is clearly described, coverage is measured externally via gcov, and the paper reports token consumption and provides a public artifact. The ablation study is logically designed and shows that each component contributes. However, the central 'significantly outperforms' claim currently rests on single-run executions of a stochastic LLM pipeline, and the WhiteFox comparison is based on a re-implementation with an added target-selection step. These issues need to be addressed before the claims are fully supported.

major comments (3)
  1. [Section III-D, IV-A, Tables II-V] All coverage comparisons and ablations are based on a single execution of each technique. The generation and summarization components use GPT-4o and StarCoder (Section III-B), which are stochastic; Section III-D itself acknowledges that token consumption varies across runs. Without repeated runs, confidence intervals, or significance tests, statements such as 'significantly outperforms' (Abstract, Section IV-A) and conclusions about component contributions (Section IV-B) are not statistically supported. For example, in Table II the 72-hour GCC incremental improvement is 3,452 lines vs. LegoFuzz's 705; a single run cannot establish that this gap is reproducible. I request at least 5 independent runs per configuration with reported mean/standard deviation and a paired significance test, or a substantive revision of the claim to 'improvements observed in our runs'.
  2. [Section III-B, footnote 5; Section IV-A3] WhiteFox is re-implemented rather than run from the authors' public artifact, and the re-implementation adds a 'neutral target-provision step' that uniformly samples files. This is a modified WhiteFox variant, not the original WhiteFox as released. The paper later constructs WhiteFoxSelection with GapForge's selection, so the main comparison in Table II is effectively against a WhiteFox with altered file-provision. This undermines the specific claim 'surpassing WhiteFox by 24,736 and 19,798 lines' (Abstract), because the baseline may not represent the actual WhiteFox system. The per-target optimization comparison (Section IV-A3) is helpful but uses the same re-implementation. Please run the original WhiteFox artifact if possible, or provide a detailed justification of why the re-implementation faithfully preserves WhiteFox's behavior, and discuss the impact of the added 'neutral' step on
  3. [Eq. (1), Eq. (3), Section IV-B1] The selection score S_f in Eq. (1) uses an unstated quadratic exponent, and the selection probability in Eq. (3) uses k=10. The ablation in Section IV-B1 evaluates k=5,10,15 on GCC under a 24-hour budget, and k=10 is chosen as default and then applied to the main 72-hour and LLVM experiments. This is parameter fitting on the primary evaluation benchmark. Reporting results for multiple k on both GCC and LLVM (Table III only shows GCC 24-hour) is needed to show that the main conclusions are not an artifact of this tuning. The quadratic exponent in Eq. (1) is never varied or justified; a sensitivity analysis for this exponent would strengthen the paper.
minor comments (4)
  1. [Figure 4] Legend labels 'GapSmith' while the technique is GapForge; also 'CSmith' capitalization is inconsistent.
  2. [Section III-D] Coverage is said to be collected for '*.cc and *.cpp' files, but Table I lists GCC targets such as gcc/*.c and gcc/c-family/*.c. Please clarify the file extension handling.
  3. [Section III-C, footnote 5] The phrasing 'So that, we add a neutral target-provision step' is awkward and should be rewritten for clarity.
  4. [Tables III and V] Variant names have inconsistent spacing/hyphenation (e.g., 'GapForge N F S' vs. 'GapForgeN S'). Please standardize.

Circularity Check

0 steps flagged

No circularity found; GapForge's coverage claims are empirical and externally measured.

full rationale

GapForge's pipeline is not a derivation that reduces to its own inputs. Each component—coverage-driven target selection, targeted summarization, and prompt synthesis with failure reflection—is an independent heuristic whose effect is evaluated by ablations against externally collected gcov coverage on GCC and LLVM. The reported coverage improvements are not implied by construction from the definition of the selection score, the prompt template, or any fitted constant. The paper tunes k=10 and the quadratic scoring exponent on the same benchmark, and the LLM evaluation appears to be single-run, but these are threats to validity (overfitting and statistical robustness), not circularity: no tuned parameter or self-citation is renamed as a prediction. References to the authors' prior work are peripheral to the central effectiveness claim and are not used to justify the method's success. The limitation and threat-to-validity statements similarly concern hardware, token-consumption, and measurement variability, not a reduction of the results to the method's assumptions. Therefore no load-bearing circular step can be exhibited.

Axiom & Free-Parameter Ledger

2 free parameters · 4 axioms · 0 invented entities

No invented physical or technical entities. The central empirical claim rests on two tuned constants (k=10 and the quadratic exponent), LLM inference capability, and measurement assumptions about gcov and differential testing.

free parameters (2)
  • selection aggregation exponent k = 10
    In Eq. 3, k controls how sharply selection favors high-weight files; k=10 is chosen as default after ablation comparing k=5 and k=15 on GCC (Section IV-B). It is tuned, not derived.
  • coverage-score exponent = 2
    Eq. 1 uses (1-C_f)^2; the quadratic amplification is a design choice validated against linear scoring in ablation, not derived from first principles.
axioms (4)
  • domain assumption A single LLM can infer triggering requirements from the uncovered region plus its immediately enclosing covered lines
    Central to Section II-B; if false, generated tests cannot reach target regions. Only aggregate coverage validates this, with no per-region success measurement.
  • domain assumption gcov line coverage on selected modules is a valid proxy for compiler testing effectiveness
    Used throughout to define coverage targets and evaluate results; inherited from prior work but not independently justified in this paper.
  • domain assumption Differential testing across -O0..-O3 detects miscompilations
    Used in Section III-D and Section IV-C to identify failures; miscompilations that agree across all tested optimization levels would be missed.
  • ad hoc to paper The re-implemented WhiteFox with a neutral file-provision step faithfully represents the original WhiteFox
    Section III-B and III-C compare against a re-implementation rather than the original artifact, and the inserted target-provision step may change behavior.

pith-pipeline@v1.3.0-alltime-deepseek · 17365 in / 12702 out tokens · 97144 ms · 2026-08-01T22:23:41.906465+00:00 · methodology

0 comments
read the original abstract

Modern compiler codebases (e.g., GCC and LLVM) are large and complex, making comprehensive coverage across diverse code regions highly challenging. Most existing test generation techniques ignore characteristics of the target code, producing test programs that exercise only a limited subset of it. Consequently, substantial compiler regions remain insufficiently tested, leaving persistent long-tail coverage gaps that survive across releases. Even existing white-box techniques achieve limited coverage on large-scale compilers. To improve compiler coverage, especially for hard-to-reach edge regions, we present GapForge, a targeted LLM-based test generation technique that reasons about coverage gaps. Unlike program-driven techniques that generate diverse inputs without modeling which regions they exercise, and unlike whole-file summarization that yields coarse guidance, GapForge treats coverage gaps as explicit region-level targets in three steps. First, it prioritizes files via coverage-driven scoring that favors large, undercovered files. Second, it pairs each uncovered line span with its enclosing covered context and performs path-difference analysis to infer fine-grained triggering requirements: the program structures and compilation options needed to reach the uncovered region. Third, it synthesizes prompts from these requirements and previously failed prompts, using coverage feedback to guide next-round selection. On GCC 14.3.0 and LLVM 19.1.0, GapForge significantly outperforms eight state-of-the-art techniques. Within 72 hours, it achieves 68.13% and 69.11% coverage on core compiler modules in GCC and LLVM, surpassing the white-box technique WhiteFox by 24,736 and 19,798 additional lines, respectively. Moreover, GapForge discovers 12 real-world compiler failures (5 in GCC, 7 in LLVM), including 8 crashes and 4 miscompilations, with each component contributing to its performance.

Figures

Figures reproduced from arXiv: 2607.15762 by Dan Hao, Junjie Chen, Mingxuan Zhu, Qingyuan Liang, Zhihong Xue.

Figure 1
Figure 1. Figure 1: Workflow of GapForge. and generate optimization-triggering tests. However, WhiteFox summarizes each source file as a whole and is primarily de￾signed for optimization-related code, rather than systematically improving coverage across the entire compiler. As a result, it provides limited guidance for the large number of under￾tested files and hard-to-reach code regions that lie outside optimization passes. … view at source ↗
Figure 2
Figure 2. Figure 2: Targeted summarization for c-ada-spec.cc. covered context, each given with its original line numbers (as illustrated in [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 3
Figure 3. Figure 3: Prompt synthesis and program generation for [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗
Figure 4
Figure 4. Figure 4: Coverage results on LLVM and GCC in 24 hours. [PITH_FULL_IMAGE:figures/full_fig_p008_4.png] view at source ↗

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

40 extracted references · 1 canonical work pages

  1. [1]

    A Survey of Compiler Testing,

    J. Chen, J. Patra, M. Pradel, Y . Xiong, H. Zhang, D. Hao, and L. Zhang, “A Survey of Compiler Testing,”ACM Computing Surveys, vol. 53, no. 1, pp. 4:1–4:36, 2021

    2021

  2. [2]

    Finding and understanding bugs in C compilers,

    X. Yang, Y . Chen, E. Eide, and J. Regehr, “Finding and understanding bugs in C compilers,” inProceedings of the 32nd ACM SIGPLAN Conference on Programming Language Design and Implementation (PLDI), 2011, pp. 283–294

    2011

  3. [3]

    CsmithEdge: more effective compiler testing by handling undefined behaviour less conservatively,

    K. Even-Mendoza, C. Cadar, and A. F. Donaldson, “CsmithEdge: more effective compiler testing by handling undefined behaviour less conservatively,”Empirical Software Engineering, vol. 27, no. 6, p. 129, 2022

    2022

  4. [4]

    Random testing for C and C++ compilers with Y ARPGen,

    V . Livinskii, D. Babokin, and J. Regehr, “Random testing for C and C++ compilers with Y ARPGen,”Proc. ACM Program. Lang., vol. 4, no. OOPSLA, pp. 196:1–196:25, 2020

    2020

  5. [5]

    Fuzzing with code fragments,

    C. Holler, K. Herzig, and A. Zeller, “Fuzzing with code fragments,” in21st USENIX Security Symposium (USENIX Security 12), 2012, pp. 445–458

    2012

  6. [6]

    Compiler validation via equivalence modulo inputs,

    V . Le, M. Afshari, and Z. Su, “Compiler validation via equivalence modulo inputs,” inProceedings of the 35th ACM SIGPLAN Conference on Programming Language Design and Implementation (PLDI), 2014, pp. 216–226

    2014

  7. [7]

    Finding deep compiler bugs via guided stochastic program mutation,

    V . Le, C. Sun, and Z. Su, “Finding deep compiler bugs via guided stochastic program mutation,” inProceedings of the 2015 ACM SIG- PLAN International Conference on Object-Oriented Programming, Sys- tems, Languages, and Applications (OOPSLA), 2015, pp. 386–399

    2015

  8. [8]

    Boosting Compiler Testing by Injecting Real-World Code,

    S. Li, T. Theodoridis, and Z. Su, “Boosting Compiler Testing by Injecting Real-World Code,”Proc. ACM Program. Lang., vol. 8, no. PLDI, pp. 223–245, 2024

    2024

  9. [9]

    GrayC: Greybox Fuzzing of Compilers and Analysers for C,

    K. Even-Mendoza, A. Sharma, A. F. Donaldson, and C. Cadar, “GrayC: Greybox Fuzzing of Compilers and Analysers for C,” inProceedings of the 32nd ACM SIGSOFT International Symposium on Software Testing and Analysis (ISSTA), 2023, pp. 1219–1231

    2023

  10. [10]

    Coverage-guided tensor compiler fuzzing with joint IR-pass mutation,

    J. Liu, Y . Wei, S. Yang, Y . Deng, and L. Zhang, “Coverage-guided tensor compiler fuzzing with joint IR-pass mutation,”Proc. ACM Program. Lang., vol. 6, no. OOPSLA1, pp. 1–26, 2022

    2022

  11. [11]

    Generating focused random tests using directed swarm testing,

    M. A. Alipour, A. Groce, R. Gopinath, and A. Christi, “Generating focused random tests using directed swarm testing,” inProceedings of the 25th International Symposium on Software Testing and Analysis (ISSTA), 2016, pp. 70–81

    2016

  12. [12]

    Fuzz4All: Universal Fuzzing with Large Language Models,

    C. S. Xia, M. Paltenghi, J. L. Tian, M. Pradel, and L. Zhang, “Fuzz4All: Universal Fuzzing with Large Language Models,” inProceedings of the 46th IEEE/ACM International Conference on Software Engineering (ICSE), 2024, pp. 126:1–126:13

    2024

  13. [13]

    WhiteFox: White-Box Compiler Fuzzing Empowered by Large Language Models,

    C. Yang, Y . Deng, R. Lu, J. Yao, J. Liu, R. Jabbarvand, and L. Zhang, “WhiteFox: White-Box Compiler Fuzzing Empowered by Large Language Models,”Proc. ACM Program. Lang., vol. 8, no. OOPSLA2, pp. 709–735, 2024

    2024

  14. [14]

    LegoFuzz: Interleaving Large Language Models for Compiler Testing,

    Y . Ni, “LegoFuzz: Interleaving Large Language Models for Compiler Testing,” inCompanion Proceedings of the 2025 ACM SIGPLAN International Conference on Systems, Programming, Languages, and Applications: Software for Humanity (SPLASH), 2025, pp. 37–39

    2025

  15. [15]

    Optimization-Directed Compiler Fuzzing for Continuous Translation Validation,

    J. Kwon, B. Jang, J. Lee, and K. Heo, “Optimization-Directed Compiler Fuzzing for Continuous Translation Validation,”Proc. ACM Program. Lang., vol. 9, no. PLDI, pp. 627–650, 2025

    2025

  16. [16]

    Alive: Provably Correct InstCombine Optimizations,

    D. Menendez and N. P. Lopes, “Alive: Provably Correct InstCombine Optimizations,” LLVM Developer Meeting, 2014

    2014

  17. [17]

    Symbolic execution and program testing,

    J. C. King, “Symbolic execution and program testing,”Communications of the ACM, vol. 19, no. 7, pp. 385–394, 1976

    1976

  18. [18]

    GNU Compiler Collection,

    GCC, “GNU Compiler Collection,” https://gcc.gnu.org, 2026

    2026

  19. [19]

    The LLVM Compiler Infrastructure,

    LLVM, “The LLVM Compiler Infrastructure,” https://llvm.org, 2026

    2026

  20. [20]

    gcov—a Test Coverage Program,

    GNU Project, “gcov—a Test Coverage Program,” https://gcc.gnu.org/onlinedocs/gcc/Gcov.html, accessed 2026

    2026

  21. [21]

    Learning Deep Semantics for Test Completion,

    P. Nie, R. Banerjee, J. J. Li, R. J. Mooney, and M. Gligoric, “Learning Deep Semantics for Test Completion,” in45th IEEE/ACM International Conference on Software Engineering (ICSE), 2023, pp. 2111–2123

    2023

  22. [22]

    CodeT5: Identifier- aware Unified Pre-trained Encoder-Decoder Models for Code Under- standing and Generation,

    Y . Wang, W. Wang, S. R. Joty, and S. C. H. Hoi, “CodeT5: Identifier- aware Unified Pre-trained Encoder-Decoder Models for Code Under- standing and Generation,” inProceedings of the 2021 Conference on Empirical Methods in Natural Language Processing (EMNLP), 2021, pp. 8696–8708

    2021

  23. [23]

    TestPilot,

    GitHub Next, “TestPilot,” https://github.com/githubnext/testpilot, ac- cessed 2026

    2026

  24. [24]

    Introducing Codex,

    OpenAI, “Introducing Codex,” https://openai.com/index/introducing- codex/, 2021

    2021

  25. [25]

    Effective test generation using pre-trained Large Language Models and mutation testing,

    A. M. Dakhel, A. Nikanjam, V . Majdinasab, F. Khomh, and M. C. Desmarais, “Effective test generation using pre-trained Large Language Models and mutation testing,”Information and Software Technology, vol. 171, p. 107468, 2024

    2024

  26. [26]

    ChatUniTest: A Framework for LLM-Based Test Generation,

    Y . Chen, Z. Hu, C. Zhi, J. Han, S. Deng, and J. Yin, “ChatUniTest: A Framework for LLM-Based Test Generation,” inCompanion Proceed- ings of the 32nd ACM International Conference on the Foundations of Software Engineering (FSE), 2024, pp. 572–576

    2024

  27. [27]

    ChatGPT,

    OpenAI, “ChatGPT,” https://openai.com/chatgpt, 2022

    2022

  28. [28]

    CodaMosa: Escaping Coverage Plateaus in Test Generation with Pre-trained Large Language Models,

    C. Lemieux, J. P. Inala, S. K. Lahiri, and S. Sen, “CodaMosa: Escaping Coverage Plateaus in Test Generation with Pre-trained Large Language Models,” in45th IEEE/ACM International Conference on Software Engineering (ICSE), 2023, pp. 919–931

    2023

  29. [29]

    ChatGPT vs SBST: A Compar- ative Assessment of Unit Test Suite Generation,

    Y . Tang, Z. Liu, Z. Zhou, and X. Luo, “ChatGPT vs SBST: A Compar- ative Assessment of Unit Test Suite Generation,”IEEE Transactions on Software Engineering, vol. 50, no. 6, pp. 1340–1359, 2024

    2024

  30. [30]

    CoverUp: Effective High Coverage Test Generation for Python,

    J. A. Pizzorno and E. D. Berger, “CoverUp: Effective High Coverage Test Generation for Python,”Proc. ACM Softw. Eng., vol. 2, no. FSE, pp. 2897–2919, 2025

    2025

  31. [31]

    Large Language Models Are Zero-Shot Fuzzers: Fuzzing Deep-Learning Libraries via Large Language Models,

    Y . Deng, C. S. Xia, H. Peng, C. Yang, and L. Zhang, “Large Language Models Are Zero-Shot Fuzzers: Fuzzing Deep-Learning Libraries via Large Language Models,” inProceedings of the 32nd ACM SIGSOFT International Symposium on Software Testing and Analysis (ISSTA), 2023, pp. 423–435

    2023

  32. [32]

    Large Language Models are Edge-Case Fuzzers: Testing Deep Learning Libraries via FuzzGPT,

    Y . Deng, C. S. Xia, C. Yang, S. D. Zhang, S. Yang, and L. Zhang, “Large Language Models are Edge-Case Fuzzers: Testing Deep Learning Libraries via FuzzGPT,”CoRR, abs/2304.02014, 2023

    Pith/arXiv arXiv 2023

  33. [33]

    SMT Solver Validation Empowered by Large Pre-Trained Language Models,

    M. Sun, Y . Yang, Y . Wang, M. Wen, H. Jia, and Y . Zhou, “SMT Solver Validation Empowered by Large Pre-Trained Language Models,” in38th IEEE/ACM International Conference on Automated Software Engineering (ASE), 2023, pp. 1288–1300

    2023

  34. [34]

    Towards understanding the effectiveness of large language models on directed test input generation,

    Z. Jiang, M. Wen, J. Cao, X. Shi, and H. Jin, “Towards understanding the effectiveness of large language models on directed test input generation,” inProceedings of the 39th IEEE/ACM International Conference on Automated Software Engineering (ASE), 2024, pp. 1408–1420

    2024

  35. [35]

    Compiler Auto-Tuning via Critical Flag Selec- tion,

    M. Zhu and D. Hao, “Compiler Auto-Tuning via Critical Flag Selec- tion,” in2023 38th IEEE/ACM International Conference on Automated Software Engineering (ASE), 2023, pp. 1000–1011

    2023

  36. [36]

    Compiler Autotuning through Multiple- phase Learning,

    M. Zhu, D. Hao, and J. Chen, “Compiler Autotuning through Multiple- phase Learning,”ACM Transactions on Software Engineering and Methodology, vol. 33, no. 4, pp. 1–38, 2024

    2024

  37. [37]

    PDCAT: Preference-Driven Compiler Auto-tuning,

    M. Zhu, Z. Sun, and D. Hao, “PDCAT: Preference-Driven Compiler Auto-tuning,”Proc. ACM Softw. Eng., vol. 2, no. FSE, pp. 847–867, 2025

    2025

  38. [38]

    The Saturation Effect in Fuzzing,

    J. Regehr, “The Saturation Effect in Fuzzing,” https://blog.regehr.org/archives/1796, 2016

    2016

  39. [39]

    Boosting Fuzzer Efficiency: An Information Theoretic Perspective,

    M. B ¨ohme, V . J. M. Man`es, and S. K. Cha, “Boosting Fuzzer Efficiency: An Information Theoretic Perspective,” inProceedings of the 28th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering (ESEC/FSE), 2020, pp. 678–689

    2020

  40. [40]

    GapSmith Repository,

    “GapSmith Repository,”https://doi.org/10.5281/zenodo.21103572, 2026

    work page doi:10.5281/zenodo.21103572 2026