Pith. sign in

REVIEW 2 major objections 5 minor 1 cited by

RVISmith: Fuzzing Compilers for RVV Intrinsics

T0 review · 2 major / 5 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 RVISmith, a fuzzer for RISC-V vector intrinsics, finds 13 previously unknown compiler bugs across GCC, LLVM, and XuanTie, of which 10 are confirmed and 3 fixed.

desk verdict Solid compiler-fuzzing paper with developer-confirmed bugs; the UB-avoidance assumption is the weak spot but external confirmations carry it. read the letter →

arxiv 2507.03773 v1 pith:7U3WMSN4 submitted 2025-07-04 cs.CR cs.DCcs.PLcs.SE

Yibo He , Cunjian Huang , Xianmiao Qu , Hongdeng Chen , Wei Yang , Tao Xie This is my paper
classification cs.CRcs.DCcs.PLcs.SE
keywords compilertestingfuzzingRISC-VvectorextensionSIMDintrinsicsdifferentialundefinedbehaviormiscompilationRVV
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

This paper claims that compiler bugs for SIMD intrinsics are common, discoverable, and driven by the complex way intrinsics combine inside strip-mining loops. It presents RVISmith, a randomized fuzzer that generates well-defined C programs with long, varied sequences of RISC-V Vector Extension (RVV) intrinsics, built from the ratified intrinsic specification. The paper reports that RVISmith covers 74.08% of RVV intrinsics versus 6.39% for the previous RVV-intrinsic fuzzer RIF, an 11.5-fold improvement, and that differential testing against GCC, LLVM, and XuanTie surfaced 13 previously unknown bugs, of which 10 are confirmed and 3 fixed. If correct, this establishes SIMD intrinsic miscompilation as a real and testable class of compiler defects, not a rarity.

What carries the argument

The load-bearing mechanism is the ratio-aligned intrinsic sequence: a sequence of RVV intrinsics in which all vector types share the same SEW/LMUL ratio, so that vsetvl and vsetvlmax yield the same vl and a vector-length-agnostic strip-mining loop processes every element exactly once. Around this, RVISmith builds a random vector-register allocation that creates data-dependency chains, three intrinsic-scheduling algorithms (all-in, unit, and random) that produce semantically equivalent programs, and an agnostic-state model that tracks which elements are active and well-defined so that only those are printed. Differential testing then compares execution results across compilers, across optimization levels of a single compiler, and across the equivalent scheduling variants.

What would settle it

Run a large batch of RVISmith-generated programs under an undefined-behavior sanitizer or a semantics-checked RVV simulator and find one case where the sanitizer reports an issue that the paper's classification labeled well-defined; alternatively, minimize a reported bug case until it reduces to an undefined behavior such as reading an uninitialized tail element.

Watch

Extended reading notes

Core claim

The central claim is that RVISmith detects compiler bugs in RVV intrinsic support by generating complex, semantically well-defined combinations of RVV intrinsics in strip-mining (vector-length-agnostic) loops, and that doing so is necessary because real use of intrinsics involves such combinations and the prior fuzzer RIF supports only a single operation per loop and under 7% of intrinsics. The paper's evidence is 11.5 times higher intrinsic coverage (74.08% vs 6.39% at 100,000 seeds) and 13 previously unknown bugs in GCC, LLVM, and XuanTie, with 10 confirmed and 3 fixed, affecting more than 20,000 intrinsics. The bugs are mostly miscompilations—data loss from incorrectly updated CSR vlenb, unintended rounding from un-restored frm and vxrm state, illegal instructions, and crashes—with no compiler warning.

Load-bearing premise

The argument depends on the assurance that every generated program is free of undefined behavior: if a latent undefined behavior slips through the Section 3.5 analysis, a differential mismatch could be a false positive rather than a compiler bug.

Editorial extensions

If this is right

  • If RVISmith's claim is right, a single fuzzer can cover the overwhelming majority of an intrinsic ISA's surface, making high-coverage compiler testing for SIMD intrinsics feasible.
  • The 13 bugs, most of which are silent miscompilations, imply that production software using affected RVV intrinsics on GCC, LLVM, or XuanTie can compute incorrect results without any warning.
  • The fact that ten bugs were confirmed and three fixed means the reports gave compiler developers actionable, minimized test cases; ongoing fuzzing of this kind should keep finding new instances as the specifications evolve.
  • Comparing a single compiler across optimization levels is as important as comparing across compilers, since most non-crash bugs live in optimization passes.

Reading between the lines

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

  • Porting the ratio-aligned sequence technique to other SIMD intrinsic sets (x86 SSE/AVX, ARM NEON) is a natural next step; the ratio-alignment idea generalises to any intrinsic family whose vl is derived from a vsetvl-style operation.
  • The concentration of bugs around CSR state (frm, vxrm) suggests that fuzzers should deliberately stress rounding-mode transitions, pairing floating-point intrinsics with different rounding modes, to expose restore-missing optimizations.
  • Because the equivalence of the three scheduling variants relies on separating load and store memory, deeper equivalence relations such as reassociation or dead-code elimination would create stronger oracles and could find bugs that the current single-loop programs miss.
  • The finding that more than 20,000 intrinsics are affected implies that practical exposure is much wider than the minimized test cases; downstream libraries that use many intrinsics should be recompiled with updated compilers once fixes land.
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

2 major / 5 minor

Summary. The paper presents RVISmith, a randomized fuzzer that generates C programs containing sequences of RISC-V Vector (RVV) intrinsics with the goal of finding compiler bugs for SIMD intrinsics. The tool parses the ratified RVV intrinsic document, performs ratio-aligned intrinsic sequence selection, randomized vector-register allocation, and three intrinsic-scheduling algorithms that are claimed to produce equivalent load/store placements, then generates complete programs with memory initialization and element printing. An undefined-behavior avoidance layer is used to ensure that printed elements are well defined. Evaluation against GCC, LLVM, and XuanTie reports 11.5x higher intrinsic-name coverage than the previous RIF fuzzer, 13 previously unknown bugs (10 confirmed and 3 fixed) affecting more than 20,000 RVV intrinsics, plus quantitative comparisons across compiler versions, code coverage, and performance measurements.

Significance. If the reported results hold, RVISmith is the first fuzzer to generate complex combinations of RVV intrinsics in strip-mining loops, addressing a real gap: SIMD intrinsic compilation is often assumed to be a near one-to-one translation and is therefore under-tested. The paper ships an implementation and artifacts, reports externally confirmed bug reports with concrete issue numbers, and makes a first attempt at codifying RVV-intrinsic undefined behaviors. The empirical evidence is strong: developer confirmations, concrete case studies, a baseline comparison (RIF) that finds nothing, and a clearly described differential testing setup. The work should open a useful direction for fuzzing compiler built-ins for other SIMD ISA extensions and for further study of RVV intrinsic semantics.

major comments (2)
  1. [3.5] Section 3.5's assurance that generated programs are well defined is load-bearing for the differential oracle, but it is only asserted. The text states that 'RVISmith does not ensure that every element is valid during computation' and that printed elements are guaranteed by an agnostic-state model plus rule-based data generation for a hand-compiled list of conditionally undefined intrinsics. No formal invariant is given, and the paper does not say how many mismatches were discarded as suspected undefined behavior. A latent UB case, such as a vrgather selecting an agnostic source element or a reduction reading an agnostic tail, could create a spurious mismatch. Please add (i) a precise inductive definition of the non-agnostic element relation, (ii) the data-generation rules for each conditionally undefined intrinsic, and (iii) an empirical validation (e.g., a sample checked with a sanitizer or an independent RVV emulator) or at least a count of excluded mismatches. The developer-confirmed bug list mitigates the risk, but the well-definedness claim is central to the methodology and should be supported more directly.
  2. [4.3] The headline coverage result relies on a metric that counts intrinsic names rather than resolved overloads. The formula in Section 4.3 uses weight_i equal to the count of definitions sharing a name, and the text explicitly calls this an intentional approximation. Because the 11.5x claim is central, this approximation should be validated: for a sample of generated programs, resolve overloads and report both name-based and overload-based coverage, and state whether the 11.5x factor survives. If it does not survive, the claim should be qualified accordingly.
minor comments (5)
  1. [4.2] The sentence 'All the bugs are confirmed as real-world bugs' appears to conflict with Table 3, where the LLVM row reports 0 confirmed and 1 fixed. Please clarify whether 'fixed' is counted as a form of confirmation and align the table with the abstract's wording '10 are confirmed and another 3 are fixed'.
  2. [4.3] In Figure 7, the caption 'n = 105' should read 'n = 10^5'.
  3. [4.2] For the LLVM bug described as detected 'nearly simultaneously' by LLVM developers, please state how the claim 'previously unknown' is scoped and how attribution was determined, since simultaneous independent discovery may affect the wording.
  4. [3.4] In Section 3.4, the code generation description says memory is initialized with 'randomly generated values,' while Table 1 gives scalar ranges. Please state how vector element values are generated for each element type, especially for 8-bit and 16-bit types where a union-based conversion may not apply.
  5. [4.4] Table 7 reports CPU and real-time proportions, but not the total wall-clock time of the fuzzing campaigns. Reporting absolute times would aid reproducibility.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: central claims rest on external compiler differential testing, developer confirmations, and static coverage counts.

full rationale

RVISmith's central claims—higher intrinsic coverage and 13 previously unknown compiler bugs—are evaluated against external, independent evidence. The intrinsic coverage metric (Section 4.3) is a static count of intrinsic names appearing in generated code divided by the count in the RVV intrinsic definition list; it is computed from the generated programs and the specification, not fitted to the result. The 13-bug result comes from differential testing across GCC, LLVM, and XuanTie and across optimization levels, with 10 bugs confirmed and 3 fixed by compiler developers; the oracle does not reduce to RVISmith's own parameter choices. The 'equivalent programs' differential strategy is constructed to be equivalent by separating load and store memory (Section 3.3), so its equivalence is by construction rather than a predicted outcome. The only load-bearing assumption is the completeness of the Section 3.5 undefined-behavior avoidance; the paper explicitly admits it does not ensure every element is valid during computation and relies on a hand-built agnostic-state model. That is a soundness and correctness risk, not a circular derivation: no parameter is fitted to the target result, no self-citation carries the argument, and no equation reduces to its own input. Hence no significant circularity.

Assumptions & free parameters 0 free parameters · 4 assumptions · 0 invented entities

No new physical or mathematical entities are introduced. The only new artifacts are the fuzzer, the approximate intrinsic-coverage metric, and the undefined-behavior taxonomy, all of which are tools or measurements rather than postulated entities requiring independent falsifiable evidence.

assumptions (4)
  • domain assumption Generated programs are free of undefined behavior, based on the agnostic-state model and rules in Section 3.5.
    If any RVV intrinsic used in a generated program still invokes undefined behavior, differential mismatches could be false positives instead of compiler bugs. The paper itself labels some intrinsics as conditionally undefined and uses rule-based data generation to avoid them.
  • domain assumption The three scheduling algorithms produce semantically equivalent programs because memory for loads and stores is separated.
    Section 3.3 states that separating memory ensures stores do not affect later loads, so all-in, unit, and random scheduling preserve final values. This is an implementation argument, not a formal proof.
  • domain assumption QEMU v9.1.0 executes RISC-V ELF files correctly; divergences are attributed to the compiler under test.
    Section 5 says the authors assume there are no related bugs of QEMU; this assumption is load-bearing for flagging execution mismatches as compiler bugs.
  • domain assumption The ratified RVV intrinsic specification document correctly encodes intrinsic signatures and semantics used to generate programs.
    Section 3.1 parses the document to classify intrinsics and select sequences; errors in the source document would propagate into generated programs.

how reviews work

0 comments
Cite this review

Pith. "Pith review of RVISmith: Fuzzing Compilers for RVV Intrinsics." pith.science (2026). https://pith.science/paper/7U3WMSN4

@misc{pith2026250703773,
  author       = {Pith},
  title        = {Pith review of: RVISmith: Fuzzing Compilers for RVV Intrinsics},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/7U3WMSN4}},
  note         = {Machine review of arXiv:2507.03773}
}
read the original abstract

Modern processors are equipped with single instruction multiple data (SIMD) instructions for fine-grained data parallelism. Compiler auto-vectorization techniques that target SIMD instructions face performance limitations due to insufficient information available at compile time, requiring programmers to manually manipulate SIMD instructions. SIMD intrinsics, a type of built-in function provided by modern compilers, enable programmers to manipulate SIMD instructions within high-level programming languages. Bugs in compilers for SIMD intrinsics can introduce potential threats to software security, producing unintended calculation results, data loss, program crashes, etc. To detect bugs in compilers for SIMD intrinsics, we propose RVISmith, a randomized fuzzer that generates well-defined C programs that include various invocation sequences of RVV (RISC-V Vector Extension) intrinsics. We design RVISmith to achieve the following objectives: (i) achieving high intrinsic coverage, (ii) improving sequence variety, and (iii) without known undefined behaviors. We implement RVISmith based on the ratified RVV intrinsic specification and evaluate our approach with three modern compilers: GCC, LLVM, and XuanTie. Experimental results show that RVISmith achieves 11.5 times higher intrinsic coverage than the state-of-the-art fuzzer for RVV intrinsics. By differential testing that compares results across different compilers, optimizations, and equivalent programs, we detect and report 13 previously unknown bugs of the three compilers under test to date. Of these bugs, 10 are confirmed and another 3 are fixed by the compiler developers.

Figures

Figures reproduced from arXiv: 2507.03773 by the authors.

Figure 1
Figure 1. Three implementations for adding two 32-bit floating-point arrays. (b) and (c) are for RISC-V V extension. [PITH_FULL_IMAGE:figures/full_fig_p004_1.png] view at source ↗
Figure 2
Figure 2. Diagram of vector type naming and intrinsic nam [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 3
Figure 3. Overview of RVISmith. vl = __riscv_vsetvl_e32m4(avl); /* some e32m4 (ratio=8) intrinsics */ vfloat32m2_t va = __riscv_vle32_v_f32m2(a, vl); vfloat32m2_t vb = __riscv_vle32_v_f32m2(b, vl); vfloat32m2_t vc = __riscv_vfadd_vv_f32m2(va, vb, vl); __riscv_vse32_v_f32m2(c, vc, vl); //ratio=16 a += vl; b += vl; c += vl; avl -= vl; [PITH_FULL_IMAGE:figures/full_fig_p006_3.png] view at source ↗
Figures from the paper (7 more)
Figure 4
Figure 4. Figure 4: An example of non-ratio-aligned RVI sequence. [PITH_FULL_IMAGE:figures/full_fig_p006_4.png]
Figure 5
Figure 5. Figure 5: An example of invocation sequences after intrinsic [PITH_FULL_IMAGE:figures/full_fig_p007_5.png]
Figure 6
Figure 6. Figure 6: Quantitative comparison results of GCC and LLVM versions. [PITH_FULL_IMAGE:figures/full_fig_p010_6.png]
Figure 7
Figure 7. Figure 7: Distribution of covered RVV intrinsics by RIF and [PITH_FULL_IMAGE:figures/full_fig_p011_7.png]
Figure 9
Figure 9. Figure 9: [#118103] GCC at -O3 miscompiles this code. The status of CSR frm is not restored between the first and second floating-point intrinsics, leading to an unintended rounding. for (size_t vl; avl > 0; avl -= vl){ vl = __riscv_vsetvl_e16m1(avl); vfloat16mf2_t va = __riscv_…
Figure 10
Figure 10. Figure 10: [#117286] GCC at -O1/2/3/s crashes on this code. The LMUL extension intrinsic causes a segment fault in GCC. for (size_t vl; avl > 0; avl -= vl){ vl = __riscv_vsetvl_e32m1(avl); vfloat32m1_t va = __riscv_vlse32_v_f32m1(ptr_a, 4, vl); va = __riscv_vfsqrt_v_f32m1_rm( va…
Figure 8
Figure 8. Figure 8: [#117947] GCC at -O2/3 miscompiles this code. Pointers are updated by the CSR vlenb that is incorrectly configured by a vsetvli instruction. This bug results in half of the data being lost after computation. The reason for this crash is that GCC tries to use a NULL poi…

Discussion (0). Sign in to comment.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. SimdBench: Benchmarking Large Language Models for SIMD-Intrinsic Code Generation

    cs.SE 2025-07 conditional novelty 6.0 of 10

    All 18 evaluated LLMs pass fewer SIMD-intrinsic code-generation tests than scalar-code tests on the new SimdBench benchmark, with the largest drops on SVE and RVV.

Reference graph

Works this paper leans on

46 extracted references · 22 canonical work pages · cited by 1 Pith paper

  1. [1]

    Alibaba DAMO Academy. 2024. XuanTie. https://www.xrvm.com

    work page 2024

  2. [2]

    ARM. 2024. Neon. https://developer.arm.com/Architectures/Neon

    work page 2024

  3. [3]

    Baghsorkhi, Nalini Vasudevan, and Youfeng Wu

    Sara S. Baghsorkhi, Nalini Vasudevan, and Youfeng Wu. 2016. FlexVec: Auto- Vectorization for Irregular Loops. In Proceedings of the 37th ACM SIGPLAN Conference on Programming Language Design and Implementation (PLDI 2016) . Association for Computing Machinery, New York, NY, USA, 697–710. https: //doi.org/10.1145/2908080.2908111

    arXiv 2016

  4. [4]

    Lukas Bernhard, Tobias Scharnowski, Moritz Schloegel, Tim Blazytko, and Thorsten Holz. 2022. JIT-Picking: Differential Fuzzing of JavaScript Engines. In Proceedings of the 28th ACM SIGSAC Conference on Computer and Communica- tions Security (CCS 2022) . Association for Computing Machinery, New York, NY, USA, 351–364. https://doi.org/10.1145/3548606.3560624

    arXiv 2022

  5. [5]

    Yishen Chen, Charith Mendis, Michael Carbin, and Saman Amarasinghe. 2021. Ve- Gen: A Vectorizer Generator for SIMD and Beyond. InProceedings of the 26th ACM International Conference on Architectural Support for Programming Languages and Operating Systems (ASPLOS 2021) . Association for Computing Machinery, New York, NY, USA, 902–914. https://doi.org/10.11...

    arXiv 2021

  6. [6]

    Clang. 2024. Undefined Behavior Sanitizer. https://clang.llvm.org/docs/ UndefinedBehaviorSanitizer.html

    work page 2024

  7. [7]

    Vijay D’Silva, Mathias Payer, and Dawn Song. 2015. The Correctness-Security Gap in Compiler Optimization. In Proceedings of the 36th IEEE Security and Privacy Workshops (SPW 2015) . IEEE Computer Society, USA, 73–87. https: //doi.org/10.1109/SPW.2015.33

    doi:10.1109/spw.2015.33 2015

  8. [8]

    Donaldson, and Cristian Cadar

    Karine Even-Mendoza, Arindam Sharma, Alastair F. Donaldson, and Cristian Cadar. 2023. GrayC: Greybox Fuzzing of Compilers and Analysers for C. In Proceedings of the 32nd ACM SIGSOFT International Symposium on Software Testing and Analysis (ISSTA 2023). Association for Computing Machinery, New York, NY, USA, 1219–1231. https://doi.org/10.1145/3597926.3598130

    arXiv 2023

Show all 46 references
  1. [9]

    Jing Ge Feng, Ye Ping He, Qiu Ming Tao, and Fazli Wahid. 2021. Evaluation of Compilers’ Capability of Automatic Vectorization Based on Source Code Analysis. Scientific Programming 2021, 1 (2021), 3264624. https://doi.org/10.1155/2021/ 3264624

    2021 doi

  2. [10]

    GCC. 2024. The GNU Compiler Collection. https://gcc.gnu.org

    2024

  3. [11]

    Google. 2024. Berberis. https://android.googlesource.com/platform/frameworks/ libs/binary_translation/+/refs/heads/main/README.md

    2024

  4. [12]

    Samuel Groß, Simon Koch, Lukas Bernhard, Thorsten Holz, and Martin Johns

  5. [13]

    Yann Herklotz and John Wickerson. 2020. Finding and Understanding Bugs in FPGA Synthesis Tools. In Proceedings of the 28th ACM/SIGDA International Symposium on Field-Programmable Gate Arrays (FPGA 2020) . Association for Computing Machinery, New York, NY, USA, 277–287. https:/...

    2020

  6. [14]

    Intel. 2024. Intel ® Intrinsics Guide. https://www.intel.com/content/www/us/en/ docs/intrinsics-guide/index.html

    2024

  7. [15]

    RISC-V International. 2024. RISC-V Vector Intrinsic Document. https://github. com/riscv-non-isa/rvv-intrinsic-doc

    2024

  8. [16]

    RISC-V International. 2024. Spike. https://github.com/riscv-software-src/riscv- isa-sim

    2024

  9. [17]

    Vu Le, Mehrdad Afshari, and Zhendong Su. 2014. Compiler Validation via Equivalence Modulo Inputs. In Proceedings of the 35th ACM SIGPLAN Confer- ence on Programming Language Design and Implementation (PLDI 2014) . As- sociation for Computing Machinery, New York, NY, USA, 216–2...

    2014

  10. [18]

    Vu Le, Chengnian Sun, and Zhendong Su. 2015. Finding Deep Compiler Bugs via Guided Stochastic Program Mutation. In Proceedings of the 30th ACM SIGPLAN International Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA 2015) . Association for ...

    2015

  11. [19]

    Shaohua Li, Theodoros Theodoridis, and Zhendong Su. 2024. Boosting Compiler Testing by Injecting Real-World Code. InProceedings of the 45th ACM SIGPLAN Conference on Programming Language Design and Implementation (PLDI 2024) . Association for Computing Machinery, New York, NY,...

    2024 doi

  12. [20]

    Donaldson

    Christopher Lidbury, Andrei Lascu, Nathan Chong, and Alastair F. Donaldson

  13. [21]

    Vsevolod Livinskii, Dmitry Babokin, and John Regehr. 2020. Random Testing for C and C++ Compilers with YARPGen. In Proceedings of the 35th ACM SIGPLAN International Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA 2020) . Association for ...

    2020 doi

  14. [22]

    Vsevolod Livinskii, Dmitry Babokin, and John Regehr. 2023. Fuzzing Loop Op- timizations in Compilers for C++ and Data-Parallel Languages. In Proceedings of the 44th ACM SIGPLAN Conference on Programming Language Design and Implementation (PLDI 2023). Association for Computing ...

    2023 doi

  15. [23]

    LLVM. 2024. The LLVM Compiler Infrastructure. https://llvm.org

    2024

  16. [24]

    Charith Mendis, Cambridge Yang, Yewen Pu, Dr.Saman Amarasinghe, and Michael Carbin. 2019. Compiler Auto-Vectorization with Imitation Learning. In Proceedings of the 33rd International Conference on Neural Information Pro- cessing Systems (NeurIPS 2019) . Curran Associates Inc....

    2019

  17. [25]

    Robin Morisset, Pankaj Pawan, and Francesco Zappa Nardelli. 2013. Compiler Testing via a Theory of Sound Optimisations in the C11/C++11 Memory Model. In Proceedings of the 34th ACM SIGPLAN Conference on Programming Language Design and Implementation (PLDI 2013) . Association f...

    2013

  18. [26]

    Dorit Nuzman and Richard Henderson. 2006. Multi-Platform Auto-Vectorization. In Proceedings of the 4th International Symposium on Code Generation and Opti- mization (CGO 2006). IEEE Computer Society, USA, 281–294. https://doi.org/10. 1109/CGO.2006.25

    2006

  19. [27]

    Dorit Nuzman, Ira Rosen, and Ayal Zaks. 2006. Auto-Vectorization of In- terleaved Data for SIMD. In Proceedings of the 27th ACM SIGPLAN Confer- ence on Programming Language Design and Implementation (PLDI 2006) . As- sociation for Computing Machinery, New York, NY, USA, 132–14...

    2006

  20. [28]

    OpenCV.AI. 2024. OpenCV. https://opencv.org/

    2024

  21. [29]

    Xianfei Ou, Cong Li, Yanyan Jiang, and Chang Xu. 2024. The Mutators Reloaded: Fuzzing Compilers with Large Language Model Generated Mutation Operators. In Proceedings of 29th ACM International Conference on Architectural Support for Programming Languages and Operating Systems ...

    2024 doi

  22. [30]

    Angela Pohl, Biagio Cosenza, Mauricio Alvarez Mesa, Chi Ching Chi, and Ben Juurlink. 2016. An Evaluation of Current SIMD Programming Models for C++. In Proceedings of the 3rd Workshop on Programming Models for SIMD/Vector Processing (WPMVP 2016) . Association for Computing Mac...

    2016

  23. [31]

    Donaldson

    Mayank Sharma, Pingshi Yu, and Alastair F. Donaldson. 2023. RustSmith: Random Differential Compiler Testing for Rust. In Proceedings of the 32nd ACM SIGSOFT International Symposium on Software Testing and Analysis (ISSTA 2023). Association for Computing Machinery, New York, NY...

    2023

  24. [32]

    SiFive. 2024. RVV Intrinsic Fuzzing (RIF). https://github.com/sifive/riscv-vector- intrinsic-fuzzing

    2024

  25. [33]

    Sergi Siso, Wes Armour, and Jeyarajan Thiyagalingam. 2019. Evaluating Auto- Vectorizing Compilers through Objective Withdrawal of Useful Information. ACM Transactions on Architecture and Code Optimization (TACO) 16, 4 (2019), 1–23. https://doi.org/10.1145/3356842

    2019 doi

  26. [34]

    Alen Stojanov, Ivaylo Toskov, Tiark Rompf, and Markus Püschel. 2018. SIMD Intrinsics on Managed Language Runtimes. InProceedings of the 16th International Symposium on Code Generation and Optimization (CGO 2018) . Association for Computing Machinery, New York, NY, USA, 2–15. h...

    2018

  27. [35]

    Chengnian Sun, Vu Le, and Zhendong Su. 2016. Finding Compiler Bugs via Live Code Mutation. In Proceedings of the 31st ACM SIGPLAN International Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA 2016). Association for Computing Machinery, N...

    2016

  28. [36]

    Theodoros Theodoridis and Zhendong Su. 2024. Refined Input, Degraded Output: The Counterintuitive World of Compiler Behavior. In Proceedings of the 45th ACM SIGPLAN Conference on Programming Language Design and Implementation (PLDI 2024). Association for Computing Machinery, N...

    2024 doi

  29. [37]

    Jiming Wang, Yan Kang, Chenggang Wu, Yuhao Hu, Yue Sun, Jikai Ren, Yuanming Lai, Mengyao Xie, Charles Zhang, Tao Li, and Zhe Wang. 2024. OptFuzz: Opti- mization Path Guided Fuzzing for JavaScript JIT Compilers. In Proceedings of the 33rd USENIX Conference on Security Symposium...

    2024

  30. [38]

    Junjie Wang, Zhiyi Zhang, Shuang Liu, Xiaoning Du, and Junjie Chen. 2023. FuzzJIT: Oracle-Enhanced Fuzzing for JavaScript Engine JIT Compiler. In Pro- ceedings of the 32nd USENIX Conference on Security Symposium (USENIX Security 2023). USENIX Association, Anaheim, CA, 1865–188...

    2023

  31. [39]

    Qian Wang and Ralf Jung. 2024. Rustlantis: Randomized Differential Testing of the Rust Compiler. In Proceedings of the 39th ACM SIGPLAN International Conference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA 2024). Association for Computing Machin...

    2024 doi

  32. [40]

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

  33. [41]

    XiangShan. 2024. NEMU. https://github.com/OpenXiangShan/NEMU

    2024

  34. [42]

    Jianhao Xu, Kangjie Lu, Zhengjie Du, Zhu Ding, Linke Li, Qiushi Wu, Mathias Payer, and Bing Mao. 2023. Silent Bugs Matter: A Study of Compiler-Introduced Security Bugs. In Proceedings of the 32nd USENIX Conference on Security Sym- posium (USENIX Security 2023) . USENIX Associa...

    2023

  35. [43]

    ACM Trans- actions on Computer Systems (TOCS) 33, 1 (2015), 1–29

    A Differential Approach to Undefined Behavior Detection. ACM Trans- actions on Computer Systems (TOCS) 33, 1 (2015), 1–29. https://doi.org/10.1145/ 2699678

    2015

  36. [46]

    Xuejun Yang, Yang Chen, Eric Eide, and John Regehr. 2011. Finding and Understanding Bugs in C Compilers. In Proceedings of the 32nd ACM SIG- PLAN Conference on Programming Language Design and Implementation (PLDI 2011). Association for Computing Machinery, New York, NY, USA, 2...

    2011

  37. [2015]

    In Proceedings of the 36th ACM SIGPLAN Conference on Programming Language Design and Implementation (PLDI 2015)

    Many-Core Compiler Fuzzing. In Proceedings of the 36th ACM SIGPLAN Conference on Programming Language Design and Implementation (PLDI 2015) . Association for Computing Machinery, New York, NY, USA, 65–76. https://doi. org/10.1145/2737924.2737986

    2015

  38. [2023]

    In Proceed- ings of 30th edition of the Network and Distributed System Security Symposium (NDSS 2023)

    FUZZILLI: Fuzzing for JavaScript JIT Compiler Vulnerabilities. In Proceed- ings of 30th edition of the Network and Distributed System Security Symposium (NDSS 2023). Internet Society, USA. https://doi.org/10.14722/ndss.2023.24290

    2023

Pith tools

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