Pith. sign in

REVIEW 1 major objections 6 minor 54 references

Improving Compiler Bug Isolation by Leveraging Large Language Models

T0 review · 1 major / 6 minor · reviewed 2026-08-06 · deepseek-v4-flash

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

Pith's one-line read An LLM reranking finds 42 of 120 compiler bugs at rank 1

desk verdict AutoCBI is a solid, well-ablated LLM re-ranking approach for compiler bug isolation, but the unaddressed training-data leakage risk makes the headline Top-1 gains provisional. read the letter →

arxiv 2506.17647 v1 pith:YPWQJNYW submitted 2025-06-21 cs.SE

Yixian Qi , Jiajun Jiang , Fengjie Li , Bowen Chen , Hongyu Zhang , Junjie Chen This is my paper · ORCID
classification cs.SE
keywords CompilerdebuggingBugisolationFaultlocalizationLargelanguagemodelsTestcoverageGCCLLVMPromptengineering
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

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

The reading

The paper proposes that compiler bug isolation can be made much more effective by letting a large language model re-rank the candidate files that coverage-based localization produces. The method, AutoCBI, feeds the LLM the failing test program, concise summaries of what each compiler source file does, two coverage-based suspicious-file lists, and the compiler's outputs under different optimization settings. On 120 real GCC and LLVM bugs, the faulty file is placed at position 1 in 42 cases and within the top 20 in 95 cases, outperforming the strongest baseline by 68% at Top-1. This matters because compiler bugs normally execute hundreds of files, so developers must otherwise inspect a long suspect list by hand; even moving real faults into the top five candidates would directly cut debugging effort.

What carries the argument

The load-bearing mechanism is the re-ranking prompt, which asks the LLM to score and sort candidate files using all four inputs at once. The two coverage rankings are computed with named formulas: Ochiai for coarse-grained test coverage and Wong2 for fine-grained execution coverage, where execution coverage means execution counts rather than binary file coverage. The summaries are produced once per source file by the same LLM and reused across bugs, so they give the model functional knowledge about hundreds of compiler files without exceeding input-length limits. The prompt is what converts separate signals into a single ranked list; without it, the coverage lists alone rank only a minority of faults highly.

What would settle it

Collect a set of GCC and LLVM bugs first reported after ChatGPT-4o's training cutoff, run AutoCBI unchanged, and compare the Top-1 rate; if it falls to the level of the coverage-only baselines, memorization rather than contextual reasoning would explain the paper's results.

Watch

Extended reading notes

Core claim

AutoCBI's central claim is that LLM-assisted re-ranking of coverage-based suspect lists is an effective and general strategy for isolating compiler faults. It combines four information sources in one prompt: the failing test program, LLM-generated natural-language summaries of the involved compiler source files, suspicious-file rankings from both ordinary test coverage and finer-grained execution coverage (how often each file runs, capturing recursion), and compilation outputs under different optimization options. The LLM assigns each file a score from 0 to 10 and sorts by that score. Across 60 GCC and 60 LLVM bugs, AutoCBI finds the true faulty file in the top 1/5/10/20 positions for 42/63/78/95 bugs, compared with 25/52/71/89 for the best baseline RecBi; per-compiler Top-1 gains over RecBi are 66.67% for GCC and 69.23% for LLVM. The ablation study shows every component helps on average: removing the source-file summaries or the failing test program cuts Top-1 success roughly in half.

Load-bearing premise

The load-bearing premise is that the LLM's measured advantage comes from reasoning over the provided context rather than from having memorized these specific 120 bugs and their fixes during training.

Editorial extensions

If this is right

  • If AutoCBI's results are correct, compiler bug isolation can be recast as a re-ranking problem on top of any existing coverage-based or generation-based method.
  • At roughly $0.075 in LLM cost and about 275 seconds per bug (excluding test generation), the added overhead is small relative to manual debugging and may make top-five localization practical in routine compiler maintenance.
  • Because document summaries are reusable until source files change, the per-bug cost of running AutoCBI should fall as more bugs are processed against the same compiler version.
  • The finding that finer-grained execution coverage helps 47 bugs but hurts 34 implies an ensemble of coverage types is better than either alone, supporting the use of multi-signal rankings for other large code bases.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The paper's acknowledgment that ChatGPT-4o may have seen the 120 benchmark bugs in training is the main unaddressed risk; a holdout evaluation on compiler bugs reported after the model's knowledge cutoff would separate genuine reasoning from memorization.
  • If summary quality drives most of the gain, as the ablation suggests, then automatically flagging low-confidence or ambiguous summaries and omitting them could improve accuracy further; the paper itself notes that extra information sometimes hurts.
  • Because the approach is a wrapper that re-ranks existing outputs, it could be combined with other future localizers, LLM-based or not, by treating their suspect lists as another input channel.
  • The observed cost gap between LLMs (roughly an order of magnitude) suggests that deployment could trade a small Top-1 drop for much lower per-bug expense, which a maintainer might prefer.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

1 major / 6 minor

Summary. The paper presents AutoCBI, a compiler bug isolation tool that combines three non-LLM components—source-file document summarization by ChatGPT-4o, RecBi-based test enhancement, and SBFL rankings computed with both coarse-grained test coverage and finer-grained execution coverage—with a prompt that asks an LLM to re-rank the suspicious file list using the failing test program, file summaries, compilation outputs, and the two coverage-based lists. The authors evaluate AutoCBI on the standard 120-bug GCC/LLVM benchmark (60 GCC, 60 LLVM) and report Top-1/5/10/20 localizations of 42/63/78/95 bugs, with large improvements over RecBi, DiWi, and FuseFL. Ablation studies remove each information source, replace SBFL formulas, and swap ChatGPT-4o for DeepSeek-V3/R1. The paper is clearly written and the implementation is open-sourced.

Significance. If the empirical results are trustworthy, AutoCBI would be a practically useful contribution: it is a general framework that combines an existing test-enhancement method with LLM-based contextual reasoning, and the ablation and configuration experiments give useful evidence about which information sources matter. The open-sourced implementation, the reproduction of baseline settings, and the prompt-level detail are strengths. The major unresolved issue is whether LLM memorization of the public benchmark, rather than multi-source reasoning, explains part of the improvement; because this directly affects the central comparison in Table 2, the significance claim is contingent on a contamination-controlled evaluation.

major comments (1)
  1. [§6.1, §4.3, Table 2] The data-leakage threat is acknowledged but not controlled. Section 6.1 states that “the potential for data leakage from LLM training involving similar compiler bugs could affect model performance and the fairness of our experiment,” but the only mitigation offered is that “the distinct focus of our work compared to the training process helps mitigate this threat,” followed by a plan to compile a new dataset. This is not a testable control. The benchmark described in §4.3 is the same 120-bug dataset used by DiWi/RecBi since 2019, and the example bugs cited in §2 and §3.3 (GCC 59221 from 2013, LLVM 25154 from 2015) have public bug reports, test cases, and fixes that predate ChatGPT-4o's training cutoff. Since the AutoCBI prompt includes the failing test program and LLM-generated file summaries, a model that has memorized these bugs can output the ground-truth file without performing the proposed multi-source integration, while the non-LLM baselines cannot benefit from such memorization. To support the central claim in Table 2, the authors must either evaluate on compiler bugs reported after the model's knowledge cutoff (or otherwise held out), or add a control that gives the LLM only the failing test program (and perhaps compilation outputs) and shows that full AutoCBI's gains are substantially larger than what the LLM can achieve from memory alone. The “new dataset” plan in §6.1 is future work, not evidence.
minor comments (6)
  1. [§4.5, Table 2] Please clarify whether the “five iterations and select best” protocol applies only to the three baselines or also to AutoCBI; if it applies to AutoCBI, report the temperature/sampling configuration and the mean (not only the best) counts across runs, since the LLM output is stochastic.
  2. [Table 2] The column headers “MFR↑MFR” and “MAR↑MAR” are confusing because smaller MFR/MAR values are better; please state the formula for the reported improvement rates and use a direction indicator consistent with “lower is better.”
  3. [Table 1] The execution-coverage version of Tarantula omits the normalization by total failed/passed execution counts that appears in the test-coverage version; please justify this definition or correct the formula.
  4. [Figure 1b] Figure 1b contains garbled text (e.g., “2O”, “1<<f5”, “O<<B5”) and misaligned line numbers; please replace it with a clean rendering.
  5. [References] References [3] and [4] are the same paper and should be merged or numbered correctly.
  6. [§6.1] There is a typo: “becuase” should be “because.”

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: AutoCBI's multi-source LLM reranking is an empirical pipeline whose inputs are not the output of the same derivation; leakage is a validity risk, not a circularity.

full rationale

This paper does not present a formal derivation chain; the central activity is an empirical evaluation. AutoCBI feeds four independent information sources (the failing test program, LLM-generated file summaries, SBFL rankings from two coverage granularities, and compilation outputs under configurations) into a black-box LLM that outputs a reranked suspicious-file list. None of these inputs is defined in terms of the final ranking, and the final ranking is not fitted to the ground-truth faulty files. The default SBFL formulas (Ochiai and Wong2) are fixed configurations and are varied in Table 4 as a robustness check, not fit parameters. The ablation in Table 3 removes each component and reports degraded performance, which is evidence that the components contribute independently. Self-citations to DiWi/RecBi occur because those tools are used as test-enhancement inputs and as baselines; using RecBi's generated passing programs as one input inside AutoCBI and then comparing to RecBi as a baseline is a potential experimental design concern, but not circularity in the derivation sense, because AutoCBI's output is not RecBi's output by construction and the comparison is against an external baseline. The acknowledged LLM training-data leakage risk in Section 6.1 is a threat to external validity and comparison fairness, not a circularity of derivation, and it should be weighted as a correctness risk elsewhere. Under the stated rules, no claim in this paper reduces by definition or by self-citation to its own inputs.

Assumptions & free parameters 2 free parameters · 3 assumptions · 0 invented entities

The method introduces no new physical or mathematical entities. The only fitted choices are the SBFL formulas, which are configuration selections made using the same benchmark. The other assumptions are standard for this kind of empirical software engineering study.

free parameters (2)
  • Default SBFL formula for coarse-grained test coverage = Ochiai
    Chosen based on preliminary experiments on the same 120-bug benchmark; Table 4 shows the choice has marginal impact.
  • Default SBFL formula for finer-grained execution coverage = Wong2
    Chosen because it achieved 'slightly better fault localization results' in the preliminary study on the same 120-bug benchmark.
assumptions (3)
  • domain assumption The benchmark of 120 real-world GCC/LLVM bugs is representative and the labeled faulty file is correct for each bug.
    The evaluation relies on the accuracy of the ground truth labels provided by the dataset (Section 4.3).
  • domain assumption The passing test programs generated by RecBi are valid and their coverage information is useful for fault localization.
    AutoCBI uses RecBi's test generation as its test enhancement component (Section 4.2); if the generated tests are of low quality, the coverage-based rankings degrade.
  • domain assumption The LLM (ChatGPT-4o) performs the re-ranking based on the provided context rather than memorized bug solutions.
    Section 6.1 acknowledges data leakage as a threat but does not verify its absence; the central evaluation assumes this premise.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Improving Compiler Bug Isolation by Leveraging Large Language Models." pith.science (2026). https://pith.science/paper/YPWQJNYW

@misc{pith2026250617647,
  author       = {Pith},
  title        = {Pith review of: Improving Compiler Bug Isolation by Leveraging Large Language Models},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/YPWQJNYW}},
  note         = {Machine review of arXiv:2506.17647}
}
read the original abstract

Compilers play a foundational role in building reliable software systems, and bugs within them can lead to catastrophic consequences. The compilation process typically involves hundreds of files, making traditional automated bug isolation techniques inapplicable due to scalability or effectiveness issues. Current mainstream compiler bug localization techniques have limitations in test program mutation and resource consumption. Inspired by the recent advances of pre-trained Large Language Models (LLMs), we propose an innovative approach named AutoCBI, which (1) uses LLMs to summarize compiler file functions and (2) employs specialized prompts to guide LLM in reordering suspicious file rankings. This approach leverages four types of information: the failing test program, source file function summaries, lists of suspicious files identified through analyzing test coverage, as well as compilation configurations with related output messages, resulting in a refined ranking of suspicious files. Our evaluation of AutoCBI against state-of-the-art approaches (DiWi, RecBi and FuseFL) on 120 real-world bugs from the widely-used GCC and LLVM compilers demonstrates its effectiveness. Specifically, AutoCBI isolates 66.67%/69.23%, 300%/340%, and 100%/57.14% more bugs than RecBi, DiWi, and FuseFL, respectively, in the Top-1 ranked results for GCC/LLVM. Additionally, the ablation study underscores the significance of each component in our approach.

Figures

Figures reproduced from arXiv: 2506.17647 by the authors.

Figure 1
Figure 1. The failing test program triggering GCC bug ( [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. The framework of AutoCBI Compiler Bug Isolation), encompassing four core components. 1 Document summarization – converts rich-text documents of source code into concise summaries, preserving key insights about code function to minimize noise. 2 Test enhancement – generates a set of passing test programs to improve the distinguishing ability of test coverage; 3 Coverage analysis – effectively utilizes test cover￾age … view at source ↗
Figure 3
Figure 3. The simplified document for the source file [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗
Figures from the paper (4 more)
Figure 4
Figure 4. Figure 4: Fault localization results by Ochiai when using [PITH_FULL_IMAGE:figures/full_fig_p005_4.png]
Figure 5
Figure 5. Figure 5: The prompt used by AutoCBI for integrating mul￾tiple data sources. Specifically, we first input the compiler source file summaries into the LLM to ensure the model can understand the specific role of each file in the compiler. This step is crucial because a compiler is…
Figure 6
Figure 6. Figure 6: Overlaps of compiler bugs localized at Top-1. [PITH_FULL_IMAGE:figures/full_fig_p008_6.png]
Figure 7
Figure 7. Figure 7: Overlaps of compiler bugs localized at Top-1 when [PITH_FULL_IMAGE:figures/full_fig_p009_7.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

54 extracted references · 40 canonical work pages

  1. [1]

    GCC BUG ID 59221

    2013. GCC BUG ID 59221. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59221. Accessed: 2025

    work page 2013

  2. [2]

    LLVM BUG ID 25154

    2015. LLVM BUG ID 25154. https://bugs.llvm.org/show_bug.cgi?id=25154. Ac- cessed: 2025

    work page 2015

  3. [4]

    Rui Abreu, Peter Zoeteweij, and Arjan JC Van Gemund. 2007. On the accuracy of spectrum-based fault localization. InTesting: Academic and industrial conference practice and research techniques-MUTATION (TAICPART-MUTATION 2007). IEEE, 89–98

    2007

  4. [5]

    Rui Abreu, Peter Zoeteweij, and Arjan JC Van Gemund. 2009. Spectrum-based multiple fault localization. In2009 IEEE/ACM International Conference on Auto- mated Software Engineering. IEEE, 88–99

    work page 2009

  5. [6]

    Samuel Benton, Xia Li, Yiling Lou, and Lingming Zhang. 2020. On the effective- ness of unified debugging: An extensive study on 16 program repair systems. In Proceedings of the 35th IEEE/ACM International Conference on Automated Software Engineering. 907–918

    work page 2020

  6. [7]

    Bor-Yuh Evan Chang, Adam Chlipala, George C Necula, and Robert R Schneck

    work page

  7. [8]

    Junjie Chen, Jiaqi Han, Peiyi Sun, Lingming Zhang, Dan Hao, and Lu Zhang

  8. [9]

    Junjie Chen, Haoyang Ma, and Lingming Zhang. 2020. Enhanced compiler bug isolation via memoized search. InProceedings of the 35th IEEE/ACM International Conference on Automated Software Engineering. 78–89

    work page 2020

Show all 54 references
  1. [10]

    Junjie Chen, Jibesh Patra, Michael Pradel, Yingfei Xiong, Hongyu Zhang, Dan Hao, and Lu Zhang. 2020. A survey of compiler testing.ACM Computing Surveys (CSUR)53, 1 (2020), 1–36

    2020

  2. [11]

    DeepSeek. 2024. DeepSeek-V3-671B. https://api-docs.deepseek.com/zh-cn/news/ news1226. Accessed: 2025

    2024

  3. [12]

    DeepSeek. 2025. DeepSeek-R1-671B. https://api-docs.deepseek.com/zh-cn/news/ news250120. Accessed: 2025

    2025

  4. [13]

    Nicholas DiGiuseppe and James A Jones. 2011. On the influence of multiple faults on coverage-based fault localization. InProceedings of the 2011 international symposium on software testing and analysis. 210–220

    2011

  5. [14]

    Vijay D’Silva, Mathias Payer, and Dawn Song. 2015. The correctness-security gap in compiler optimization. In2015 IEEE Security and Privacy Workshops. IEEE, 73–87

    2015

  6. [15]

    Joe W Duran and Simeon C Ntafos. 1984. An evaluation of random testing.IEEE transactions on Software Engineering4 (1984), 438–444

    1984

  7. [16]

    GCC. [n. d.]. GCC. https://gcc.gnu.org. Accessed: 2024

    2024

  8. [17]

    Patrice Godefroid, Michael Y Levin, David A Molnar, et al . 2008. Automated whitebox fuzz testing.. InNDSS, Vol. 8. 151–166

    2008

  9. [18]

    Josie Holmes and Alex Groce. 2018. Causal distance-metric-based assistance for debugging after compiler fuzzing. In2018 IEEE 29th International Symposium on Software Reliability Engineering (ISSRE). IEEE, 166–177

    2018

  10. [19]

    Josie Holmes and Alex Groce. 2020. Using mutants to help developers distinguish and debug (compiler) faults.Software Testing, Verification and Reliability30, 2 (2020), e1727

    2020

  11. [20]

    Xinyi Hou, Yanjie Zhao, Yue Liu, Zhou Yang, Kailong Wang, Li Li, Xiapu Luo, David Lo, John Grundy, and Haoyu Wang. 2023. Large language models for software engineering: A systematic literature review.ACM Transactions on Software Engineering and Methodology(2023)

    2023

  12. [21]

    Jiajun Jiang, Yingfei Xiong, and Xin Xia. 2019. A manual inspection of Defects4J bugs and its implications for automatic program repair.Science china information sciences62 (2019), 1–16

    2019

  13. [22]

    Matthew Jin, Syed Shahriar, Michele Tufano, Xin Shi, Shuai Lu, Neel Sundaresan, and Alexey Svyatkovskiy. 2023. Inferfix: End-to-end program repair with llms. InProceedings of the 31st ACM Joint European Software Engineering Conference and Symposium on the Foundations of Softwa...

    2023

  14. [23]

    James A Jones and Mary Jean Harrold. 2005. Empirical evaluation of the tarantula automatic fault-localization technique. InProceedings of the 20th IEEE/ACM international Conference on Automated software engineering. 273–282

    2005

  15. [24]

    Pavneet Singh Kochhar, Xin Xia, David Lo, and Shanping Li. 2016. Practition- ers’ expectations on automated fault localization. InProceedings of the 25th International Symposium on Software Testing and Analysis(Saarbrücken, Ger- many)(ISSTA 2016). Association for Computing Mac...

    2016

  16. [25]

    Yann LeCun, Yoshua Bengio, and Geoffrey Hinton. 2015. Deep learning.nature 521, 7553 (2015), 436–444

    2015

  17. [26]

    Xia Li and Lingming Zhang. 2017. Transforming programs and tests in tandem for fault localization.Proceedings of the ACM on Programming Languages1, OOPSLA (2017), 1–30

    2017

  18. [27]

    HeuiChan Lim and Saumya Debray. 2021. Automated bug localization in JIT com- pilers. InProceedings of the 17th ACM SIGPLAN/SIGOPS International Conference on Virtual Execution Environments. 153–164

    2021

  19. [28]

    LLVM. [n. d.]. LLVM. https://llvm.org. Accessed: 2024

    2024

  20. [29]

    Yiling Lou, Ali Ghanbari, Xia Li, Lingming Zhang, Haotian Zhang, Dan Hao, and Lu Zhang. 2020. Can automated program repair refine fault localization? a unified debugging approach. InProceedings of the 29th ACM SIGSOFT International Symposium on Software Testing and Analysis. 75–87

    2020

  21. [30]

    Bonan Min, Hayley Ross, Elior Sulem, Amir Pouran Ben Veyseh, Thien Huu Nguyen, Oscar Sainz, Eneko Agirre, Ilana Heintz, and Dan Roth. 2023. Recent advances in natural language processing via large pre-trained language models: A survey.Comput. Surveys56, 2 (2023), 1–40

    2023

  22. [31]

    OpenAI. 2024. ChatGPT-4o-2024-08-06. https://platform.openai.com/docs/ models#gpt-4o. Accessed: 2025

    2024

  23. [32]

    Alan Romano, Xinyue Liu, Yonghwi Kwon, and Weihang Wang. 2021. An empiri- cal study of bugs in webassembly compilers. In2021 36th IEEE/ACM International Conference on Automated Software Engineering (ASE). IEEE, 42–54

    2021

  24. [33]

    Raul Santelices, James A Jones, Yanbing Yu, and Mary Jean Harrold. 2009. Light- weight fault-localization using multiple coverage types. In2009 IEEE 31st Inter- national Conference on Software Engineering. IEEE, 56–66

    2009

  25. [34]

    Huzaifa Sidhpurwala. 2019. Security flaws caused by compiler optimizations. Red Hat Blog(2019)

    2019

  26. [35]

    Chengnian Sun, Vu Le, and Zhendong Su. 2016. Finding and analyzing compiler warning defects. InProceedings of the 38th International Conference on Software Engineering. 203–213

    2016

  27. [36]

    Haoxin Tu, Zhide Zhou, He Jiang, Imam Nur Bani Yusuf, Yuxian Li, and Lingxiao Jiang. 2024. Isolating Compiler Bugs by Generating Effective Witness Programs with Large Language Models.IEEE Transactions on Software Engineering(2024)

    2024

  28. [37]

    Qianqian Wang, Chris Parnin, and Alessandro Orso. 2015. Evaluating the useful- ness of ir-based fault localization techniques. InProceedings of the 2015 interna- tional symposium on software testing and analysis. 1–11

    2015

  29. [38]

    Xi Wang, Nickolai Zeldovich, M Frans Kaashoek, and Armando Solar-Lezama

  30. [39]

    Ming Wen, Junjie Chen, Yongqiang Tian, Rongxin Wu, Dan Hao, Shi Han, and Shing-Chi Cheung. 2019. Historical spectrum based fault localization.IEEE Transactions on Software Engineering47, 11 (2019), 2348–2368

    2019

  31. [40]

    Ratnadira Widyasari, Jia Wei Ang, Truong Giang Nguyen, Neil Sharma, and David Lo. 2024. Demystifying faulty code: Step-by-step reasoning for explainable fault localization. In2024 IEEE International Conference on Software Analysis, Evolution and Reengineering (SANER). IEEE, 568–579

    2024

  32. [41]

    W Eric Wong, Vidroha Debroy, Ruizhi Gao, and Yihao Li. 2013. The DStar method for effective software fault localization.IEEE Transactions on Reliability63, 1 (2013), 290–308

    2013

  33. [42]

    W Eric Wong, Yu Qi, Lei Zhao, and Kai-Yuan Cai. 2007. Effective fault localiza- tion using code coverage. In31st Annual International Computer Software and Applications Conference (COMPSAC 2007), Vol. 1. IEEE, 449–456

    2007

  34. [43]

    Jifeng Xuan and Martin Monperrus. 2014. Test case purification for improv- ing fault localization. InProceedings of the 22nd ACM SIGSOFT international symposium on foundations of software engineering. 52–63

    2014

  35. [44]

    Aidan ZH Yang, Claire Le Goues, Ruben Martins, and Vincent Hellendoorn. 2024. Large language models for test-free fault localization. InProceedings of the 46th IEEE/ACM International Conference on Software Engineering. 1–12

    2024

  36. [45]

    Jing Yang, Yibiao Yang, Maolin Sun, Ming Wen, Yuming Zhou, and Hai Jin

  37. [46]

    Andreas Zeller. 2002. Isolating cause-effect chains from computer programs. ACM SIGSOFT Software Engineering Notes27, 6 (2002), 1–10

    2002

  38. [47]

    Lingming Zhang, Miryung Kim, and Sarfraz Khurshid. 2011. Localizing failure- inducing program edits based on spectrum information. In2011 27th IEEE Inter- national Conference on Software Maintenance (ICSM). IEEE, 23–32

    2011

  39. [48]

    Lingming Zhang, Lu Zhang, and Sarfraz Khurshid. 2013. Injecting mechanical faults to localize developer faults for evolving software.ACM SIGPLAN Notices 48, 10 (2013), 765–784

    2013

  40. [49]

    Yuntong Zhang, Haifeng Ruan, Zhiyu Fan, and Abhik Roychoudhury. 2024. Autocoderover: Autonomous program improvement. InProceedings of the 33rd ACM SIGSOFT International Symposium on Software Testing and Analysis. 1592– 1604

    2024

  41. [50]

    Jian Zhou, Hongyu Zhang, and David Lo. 2012. Where should the bugs be fixed? More accurate information retrieval-based bug localization based on bug reports. In2012 34th International Conference on Software Engineering (ICSE). 14–24. doi:10.1109/ICSE.2012.6227210

    2012

  42. [51]

    Zhide Zhou, He Jiang, Zhilei Ren, Yuting Chen, and Lei Qiao. 2022. Locseq: Automated localization for compiler optimization sequence bugs of LLVM.IEEE Transactions on Reliability71, 2 (2022), 896–910. 12

    2022

  43. [2005]

    InProceedings of the 2005 ACM SIGPLAN international workshop on Types in languages design and implementation

    Type-based verification of sssembly language for compiler debugging. InProceedings of the 2005 ACM SIGPLAN international workshop on Types in languages design and implementation. 91–102

    2005

  44. [2013]

    behavior

    Towards optimization-safe systems: Analyzing the impact of undefined 11 Qi et al. behavior. InProceedings of the Twenty-Fourth ACM Symposium on Operating Systems Principles. 260–275

  45. [2019]

    In Proceedings of the 2019 27th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering

    Compiler bug isolation via effective witness test program generation. In Proceedings of the 2019 27th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering. 223–234

    2019

  46. [2022]

    In2022 IEEE International Conference on Software Analysis, Evolution and Reengineering (SANER)

    Isolating compiler optimization faults via differentiating finer-grained options. In2022 IEEE International Conference on Software Analysis, Evolution and Reengineering (SANER). IEEE, 481–491

Pith tools

Reviewed August 6, 2026 · model on record in the stance chip above.