Pith. sign in

REVIEW 5 major objections 6 minor 42 references

XAMT: Cross-Framework API Matching for Testing Deep Learning Libraries

T0 review · 5 major / 6 minor · reviewed 2026-08-05 · deepseek-v4-flash

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

Pith's one-line read This paper claims that cross-framework differential testing of equivalent deep learning APIs can detect bugs that manifest identically on CPU and GPU, which intra-framework backend comparisons miss.

desk verdict XAMT is a useful, well-evaluated extension of cross-framework differential testing, but its central CPU/GPU-invariance claim is asserted, not demonstrated. read the letter →

arxiv 2508.12546 v1 pith:4JEWKI42 submitted 2025-08-18 cs.SE

Bin Duan , Ruican Dong , Naipeng Dong , Dan Dongseong Kim , Guowei Yang This is my paper
classification cs.SE
keywords deeplearningtestingdifferentialfuzzingAPImatchingcross-frameworkvariance-guidedlibraries
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

XAMT matches functionally equivalent APIs across PyTorch, TensorFlow, Keras, Chainer, and JAX using similarity rules over names, documentation descriptions, and parameter structures. It then feeds aligned inputs to each matched API and uses variance-guided mutation to amplify output divergence, flagging crashes, NaNs, and inconsistencies. The paper's central claim is that this cross-framework oracle catches bugs that produce identical CPU and GPU outputs, so existing intra-framework testing methods cannot see them. In an evaluation of 839 matched APIs and 238 equivalence groups, XAMT found 17 bugs, 12 confirmed by developers. If this holds, cross-framework comparison becomes a necessary complement to backend-based fuzzing for deep learning library reliability.

What carries the argument

The central mechanism is the variance-guided differential fuzzing loop, built on the output variance $\sigma^2(x) = \frac{1}{n}\sum_i (A_i(x)-\mu(x))^2$ and the deviation vector $d(x) = [A_1(x)-\mu(x),\ldots,A_n(x)-\mu(x)]$ across $n$ matched APIs. This object is both the oracle signal (inconsistency is high variance under equivalent inputs) and the mutation guide (perturbations aligned with $d(x)$ push toward higher divergence), making it the single device that connects matching, fuzzing, and bug detection.

What would settle it

A concrete counterexample would be a matched API pair that passes the behavioral verification on 10 random inputs but later shows a high-variance output that is a legitimate framework-specific design choice, not a bug—for instance, different deterministic tie-breaking in sorting or different handling of signed zeros without any numerical error. If such cases are common, then the inconsistency oracle would produce false positives that cannot be distinguished from real bugs without manual inspection.

Watch

Extended reading notes

Core claim

The paper establishes that behavioral comparison across, rather than within, deep learning frameworks is a viable and effective bug-detection strategy. It introduces a matching pipeline that combines normalized Levenshtein name similarity, Sentence-BERT description similarity, and structural parameter similarity with control-related parameters filtered out, yielding groups of APIs that are functionally equivalent at the level of tensor inputs and outputs. On these groups, XAMT performs variance-guided differential fuzzing: it computes the element-wise output variance across the APIs, builds a deviation vector, and mutates inputs in the direction that increases divergence, using simulated ann

Load-bearing premise

The entire detection pipeline assumes that after filtering control-related parameters, the remaining parameter structures and the 10-sample behavioral check are enough to guarantee that two APIs are truly functionally equivalent, so that any later output divergence is a bug.

Editorial extensions

If this is right

  • If the approach generalizes, future deep learning library testers should treat cross-framework comparison as a standard oracle alongside CPU/GPU differential testing.
  • Bugs that are silent on both backends—numerical edge cases, sorting-tie inconsistencies, NaN propagation differences—become detectable through this method.
  • The matching pipeline, because it relies only on documentation and signatures, can be ported to additional frameworks such as PaddlePaddle or MXNet without retraining models.
  • Variance-guided mutation, shown to outperform random inputs in both coverage and bug count, offers a reusable strategy for other differential testing settings.
  • Confirmed bugs in TensorFlow and JAX indicate that widely deployed libraries still contain implementation-level inconsistencies that affect real workloads.

Reading between the lines

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

  • If the variance threshold $\sigma^2 \ge 0.1$ is taken as the bug criterion, then any framework pair that passes behavioral verification on 10 random inputs may still hide rare-input inconsistencies, so the matching validation is only as strong as the seed distribution.
  • The three acknowledged 'acceptable differences' suggest that the inconsistency oracle cannot by itself separate bugs from legitimate implementation choices; a human or reference oracle is still needed to adjudicate high-variance cases.
  • The paper's implicit bet is that documentation-derived equivalence is a faithful proxy for functional equivalence; a testable extension is to check whether APIs matched with high semantic similarity but low lexical overlap (e.g., `softmax_cross_entropy` vs. `crossentropy_loss`) also fail the same edge-case tests, which would strengthen or weaken the matching rules.
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

5 major / 6 minor

Summary. The paper introduces XAMT, a cross-framework fuzzing method for deep learning libraries. XAMT matches functionally equivalent APIs across PyTorch, TensorFlow, Keras, Chainer, and JAX using similarity rules over API names, descriptions, and parameter structures, aligns their inputs, and then applies variance-guided differential fuzzing with crash, NaN, and inconsistency oracles. The evaluation reports 238 matched API groups involving 839 APIs and 17 detected bugs, 12 of which were confirmed by developers. The paper's central claim is that XAMT detects bugs that manifest identically on CPU and GPU and are therefore invisible to existing intra-framework, backend-differential testing methods.

Significance. The cross-framework testing idea is timely and, if fully substantiated, would be a useful complement to backend-differential fuzzing. The paper provides a reproducible matching pipeline, concrete case studies with executable inputs (Listings 1–2), and an honest attempt to compare with FreeFuzz and DeepREL. The public code availability and the fact that 12 bugs were developer-confirmed are concrete strengths. However, the central novelty claim — that the detected bugs are CPU/GPU-invariant and hence undetectable by intra-framework methods — is currently supported mainly by a one-sentence assertion, and the inconsistency oracle is partly circular with the fuzzing objective. These gaps require additional experiments before the main contribution can be accepted.

major comments (5)
  1. [§IV-D, Table V] The paper's central novelty claim is that XAMT detects bugs that 'manifest identically on CPU vs GPU' and are 'undetectable by existing intra-framework testing methods.' The only support is the sentence in §IV-D: 'We verified that such NaN and Inconsistency bugs produce identical outputs across GPU and CPU.' No per-bug protocol, no output measurements, no tolerance, and no comparison with an actual CPU-vs-GPU differential oracle is reported. The baselines used in §IV-C (FreeFuzz, DeepREL) are not backend-differential testers, so their failure to find these bugs does not establish undetectability by backend-differential methods. Please add a systematic experiment that runs each reported bug on CPU and GPU for the same framework, reports the outputs and differences, and ideally compares against a CRADLE-style backend-differential oracle. If the invariance claim cannot be substantiated, the
  2. [§II-C2, §II-D3, §III-B] The inconsistency oracle and the fuzzing objective are the same quantity: Eq. (7) defines σ²(x) as the variance across APIs, and §II-C2 guides mutation to maximize it via the deviation vector d(x) in Eq. (8); §II-D3 then flags outputs with σ²(x) ≥ 0.1. Detected 'inconsistency' cases are therefore variance maxima by construction. The threshold 0.1 is selected from 'preliminary empirical analyses,' and the variance-improvement threshold (0.001) and reinitialization limit (20) are also manually set. Developer confirmation of 12 cases partially mitigates this, but the reported 7 inconsistency bugs do not form an independent sample. Please report all cases that exceeded the threshold, the distribution of variances, and a sensitivity analysis of the threshold; and separate developer-confirmed bugs from 'acceptable differences' and unconfirmed cases.
  3. [§IV-A2] Behavioral validation of matched API groups uses only 10 randomly generated input samples per group. This is too weak to establish functional equivalence for 238 groups, especially for the edge cases (signed zeros, denormals, NaN, complex inputs) that later trigger bugs in Listings 1–2. If some matched APIs are not truly equivalent under edge-case inputs, the inconsistency oracle will flag legitimate implementation differences as bugs. Please strengthen the validation protocol (more samples, edge cases, per-group statistical equivalence) or restrict bug claims to developer-confirmed cases, and discuss the impact on the three 'acceptable differences' reported in §IV-D.
  4. [§IV-C2, Table IV] The baseline bug-detection comparison is performed only on the 8 API cases in PyTorch/TensorFlow where XAMT already found bugs, not on a common random sample of APIs. Moreover, FreeFuzz and DeepREL are not intra-framework backend-differential testers; they use different oracles (e.g., relational APIs and documentation constraints). Therefore Table IV cannot support the claim that these bugs are 'undetectable by intra-framework testing that relies on backend-induced discrepancies.' Please compare on a fair common API set and, if possible, include a backend-differential baseline (e.g., CRADLE-style CPU-vs-GPU comparison) or explicitly restrict the claim to the compared methods.
  5. [§IV-D] The bug counts are ambiguous. The text says 17 detected, 12 confirmed, 3 considered acceptable differences, and 2 received no response, and then states 'Through manual validation, we confirmed that no false positives among these.' If three inconsistencies are acceptable differences, they cannot simultaneously be counted as true bugs; either they are false positives under the bug definition or they should be removed from the 17. Please report exact per-oracle counts after excluding acceptable differences and unconfirmed cases, and make the counting criterion explicit.
minor comments (6)
  1. [Table V] Header typo: 'Chanier' should be 'Chainer.'
  2. [§II-A3, Eq. (6)] SIM_Param is defined as SIM_Count + SIM_Type, which can range up to 2. Stage 3 then requires SIM_Param = 2. Please clarify this range explicitly and justify why an additive combination is appropriate.
  3. [§III-B] Minor text issue: 'we use X AMTto generate' should be 'XAMT to generate.' Several other spacing issues around 'X AMT' throughout.
  4. [§III-B] The hyperparameter paragraph lists several thresholds (relative margin 0.3, variance improvement 0.001, variance threshold 0.1, reinitialization limit 20) without a sensitivity analysis. Since the main oracle relies on these thresholds, at least a brief ablation would increase confidence.
  5. [§II-A3] The paper filters 'control-related parameters' (Table I) with the stated assumption that removing them preserves functional equivalence, but §V later acknowledges that control parameters such as dtype can affect numerical outcomes. This tension should be discussed in the paper.
  6. [Figure 3] Figure 3 is referenced in §IV-A1 but not included in the text. Please ensure the figure is present in the final version.

Circularity Check

1 steps flagged · score 5.0 of 10

Inconsistency oracle is the same variance objective the fuzzer is built to maximize, so 7 of 17 reported bugs are variance maxima by construction; the rest of the pipeline is not circular.

  1. self definitional [Section II-C2 (Eqs. 7-8) and Section II-D3 / Section IV-D]
    "Our goal is to identify valid inputs x that trigger maximal behavioral divergence across the APIs. ... we construct a deviation vector: d(x) = [A1(x) − µ(x), . . . , An(x) − µ(x)] ... Our goal is to generate a mutated input x′ that increases the output variance. ... For a given input, we collect the outputs from all matched APIs and compute their variance using the metric σ2(x) in Section II-C2. A high variance implies that the APIs produce noticeably different results under the same input. ... An output variance threshold of σ2(x) ≥ 0.1 is selected based on preliminary empirical analyses."

    The variance-guided mutator is rewarded for increasing σ²(x), and the deviation vector d(x) is exactly the list of residuals whose squared average defines σ²(x) in Eq. 7. The Inconsistency oracle then flags inputs by thresholding the same σ²(x). Consequently, the 7 reported 'Inconsistency' bugs are not independent discoveries; they are inputs that the search was explicitly engineered to find. The crash and NaN oracles are independent, and developer confirmation of some cases provides external evidence, so the circularity is partial rather than total.

full rationale

The core matching pipeline (name/description/parameter similarity, parameter alignment, input seed generation) is self-contained and does not reduce to a fitted prediction. The part of the novelty that rests on 'inconsistency bugs' does reduce to the optimization objective: Eq. 8 is the element-wise residual of Eq. 7, and the oracle is the same thresholded variance. However, the paper also reports crash and NaN bugs detected by separate oracles, and 12 of 17 bugs were confirmed by framework developers, which provides independent evidence for many detections. The claim that the bugs 'manifest identically on CPU vs GPU' is asserted rather than demonstrated (no per-bug CPU/GPU protocol is given), but that is a validity concern, not a circularity. The three 'acceptable differences' acknowledged in §IV-D further show that the variance oracle alone does not separate bugs from legitimate implementation differences, which is consistent with the partial self-definitional issue. Overall, the central derivation is not fully circular, but one of the three detection channels is the same quantity the fuzzer maximizes.

Assumptions & free parameters 7 free parameters · 6 assumptions · 0 invented entities

The paper introduces no new physical entities. Its free parameters are all thresholds and budgets set by hand or tuned on preliminary data. The core assumptions concern the validity of similarity-based matching, the reference status of PyTorch, and the reliability of output variance as a bug oracle.

free parameters (7)
  • Name similarity threshold = 0.5
    Stage 1 cutoff for candidate retrieval, justified by 'widely used in approximate string matching'.
  • Relative margin threshold = 0.3
    Stage 2 threshold for treating top candidate as best match, set as a hyperparameter.
  • Output variance threshold = 0.1
    Inconsistency oracle threshold 'selected based on preliminary empirical analyses'.
  • Variance improvement acceptance threshold = 0.001
    Minimum increase in variance to accept a mutation, 'empirically determined'.
  • Test cases per API = 500
    Adopted from coverage stabilization observed in Figure 4, a cost-effectiveness choice.
  • Maximum consecutive failed mutations = 20
    Reinitialization limit in the fuzzing loop.
  • Behavioral validation sample count = 10
    Number of random inputs used to validate each matched API group.
assumptions (6)
  • standard math Levenshtein distance and cosine similarity are valid measures of API name and description equivalence.
    Used in Eqs. 1-3 for matching.
  • domain assumption Sentence-BERT embeddings of API descriptions capture functional semantics across frameworks.
    Section II-A2; no calibration against human judgment.
  • ad hoc to paper Removing control-related parameters preserves functional equivalence.
    Table I filter list is manually curated; removal is necessary to align argsort signatures.
  • domain assumption The unified abstract type mapping (Tensor, int, bool, etc.) is sufficient for cross-framework type comparison.
    Table II; simplifications like TensorFlow Tensor vs JAX Array may obscure behavior.
  • ad hoc to paper PyTorch is a correct reference baseline; deviations from it indicate bugs in other frameworks.
    Section IV-A1 designates PyTorch as reference; bugs in PyTorch would be misattributed.
  • domain assumption High output variance among matched APIs indicates a bug, not acceptable implementation-defined behavior.
    Central oracle assumption, contradicted by three developer-accepted differences in Section IV-D.

how reviews work

0 comments
Cite this review

Pith. "Pith review of XAMT: Cross-Framework API Matching for Testing Deep Learning Libraries." pith.science (2026). https://pith.science/paper/4JEWKI42

@misc{pith2026250812546,
  author       = {Pith},
  title        = {Pith review of: XAMT: Cross-Framework API Matching for Testing Deep Learning Libraries},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/4JEWKI42}},
  note         = {Machine review of arXiv:2508.12546}
}
read the original abstract

Deep learning powers critical applications such as autonomous driving, healthcare, and finance, where the correctness of underlying libraries is essential. Bugs in widely used deep learning APIs can propagate to downstream systems, causing serious consequences. While existing fuzzing techniques detect bugs through intra-framework testing across hardware backends (CPU vs. GPU), they may miss bugs that manifest identically across backends and thus escape detection under these strategies. To address this problem, we propose XAMT, a cross-framework fuzzing method that tests deep learning libraries by matching and comparing functionally equivalent APIs across different frameworks. XAMT matches APIs using similarity-based rules based on names, descriptions, and parameter structures. It then aligns inputs and applies variance-guided differential testing to detect bugs. We evaluated XAMT on five popular frameworks, including PyTorch, TensorFlow, Keras, Chainer, and JAX. XAMT matched 839 APIs and identified 238 matched API groups, and detected 17 bugs, 12 of which have been confirmed. Our results show that XAMT uncovers bugs undetectable by intra-framework testing, especially those that manifest consistently across backends. XAMT offers a complementary approach to existing methods and offers a new perspective on the testing of deep learning libraries.

Figures

Figures reproduced from arXiv: 2508.12546 by the authors.

Figure 1
Figure 1. Overview of XAMT. generation, and differential fuzzing. XAMT extracts API names, descriptions, and signatures from official documen￾tation to form equivalence groups, generates valid inputs, and applies variance-guided mutation with crash, NaN, and inconsistency oracles. All code is publicly available. • Evaluation. We evaluate XAMT on five popular deep learn￾ing frameworks. XAMT matched 839 APIs and identified 238 … view at source ↗
Figure 2
Figure 2. Matching Rules. similarity score implies a closer semantic relationship, suggest￾ing that the APIs may provide similar or related functionalities. As illustrated in [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 3
Figure 3. Functionally Equivalent API Group Matched. [PITH_FULL_IMAGE:figures/full_fig_p007_3.png] view at source ↗
Figures from the paper (1 more)
Figure 5
Figure 5. Figure 5: Compare with Variance-Guided and Random Strategy. [PITH_FULL_IMAGE:figures/full_fig_p008_5.png]

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

42 extracted references · 40 canonical work pages

  1. [2]

    Murray, Benoit Steiner, Paul A

    Mart ´ın Abadi, Paul Barham, Jianmin Chen, Zhifeng Chen, Andy Davis, Jeffrey Dean, Matthieu Devin, Sanjay Ghemawat, Geoffrey Irving, Michael Isard, Manjunath Kudlur, Josh Levenberg, Rajat Monga, Sherry Moore, Derek G. Murray, Benoit Steiner, Paul A. Tucker, Vijay Va- sudevan, Pete Warden, Martin Wicke, Yuan Yu, and Xiaoqiang Zheng. Tensorflow: A system fo...

    work page 2016

  2. [3]

    Deep learning for smart healthcare—a survey on brain tumor detection from medical imaging

    Mahsa Arabahmadi, Reza Farahbakhsh, and Javad Rezazadeh. Deep learning for smart healthcare—a survey on brain tumor detection from medical imaging. Sensors, 22(5):1960, 2022

    work page 1960

  3. [4]

    Anomaly detection in autonomous driving: A survey

    Daniel Bogdoll, Maximilian Nitsche, and J Marius Z ¨ollner. Anomaly detection in autonomous driving: A survey. In Proceedings of the IEEE/CVF conference on computer vision and pattern recognition, pages 4488–4499, 2022

    work page 2022

  4. [5]

    Jax: Composable trans- formations of python+numpy programs

    James Bradbury, Roy Frostig, Peter Hawkins, Matthew Johnson, Chris Leary, Dougal Maclaurin, George Necula, Adam Paszke, Jake Vander- Plas, Skye Wanderman-Milne, and Qiao Zhang. Jax: Composable trans- formations of python+numpy programs. https://github.com/google/jax, 2018

    work page 2018

  5. [6]

    History-guided configuration diversification for compiler test-program generation

    Junjie Chen, Guancheng Wang, Dan Hao, Yingfei Xiong, Hongyu Zhang, and Lu Zhang. History-guided configuration diversification for compiler test-program generation. In 2019 34th IEEE/ACM International Conference on Automated Software Engineering (ASE) , pages 305–316. IEEE, 2019

    work page 2019

  6. [7]

    Keras, 2015

    Francois Chollet et al. Keras, 2015

    2015

  7. [8]

    {IvySyn}: Automated vulnerability discovery in deep learning frameworks

    Neophytos Christou, Di Jin, Vaggelis Atlidakis, Baishakhi Ray, and Vasileios P Kemerlis. {IvySyn}: Automated vulnerability discovery in deep learning frameworks. In 32nd USENIX Security Symposium (USENIX Security 23) , pages 2383–2400, 2023

    work page 2023

  8. [9]

    Cohen, Pradeep Ravikumar, and Stephen E

    William W. Cohen, Pradeep Ravikumar, and Stephen E. Fienberg. A comparison of string distance metrics for name-matching tasks. IJCAI- 2003 Workshop on Information Integration on the Web , 2003

    work page 2003

Show all 42 references
  1. [10]

    Large language models are zero-shot fuzzers: Fuzzing deep-learning libraries via large language models

    Yinlin Deng, Chunqiu Steven Xia, Haoran Peng, Chenyuan Yang, and Lingming Zhang. Large language models are zero-shot fuzzers: Fuzzing deep-learning libraries via large language models. In Proceedings of the 32nd ACM SIGSOFT international symposium on software testing and analy...

    2023

  2. [11]

    Large language models are edge-case fuzzers: Testing deep learning libraries via fuzzgpt

    Yinlin Deng, Chunqiu Steven Xia, Chenyuan Yang, Shizhuo Dylan Zhang, Shujing Yang, and Lingming Zhang. Large language models are edge-case fuzzers: Testing deep learning libraries via fuzzgpt. arXiv preprint arXiv:2304.02014, 2023

    2023 arXiv

  3. [12]

    Fuzzing deep-learning libraries via automated relational api inference

    Yinlin Deng, Chenyuan Yang, Anjiang Wei, and Lingming Zhang. Fuzzing deep-learning libraries via automated relational api inference. In Proceedings of the 30th ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering, pages 44...

    2022

  4. [13]

    Differential testing of cross deep learning framework {APIs}: Revealing inconsistencies and vulnerabilities

    Zizhuang Deng, Guozhu Meng, Kai Chen, Tong Liu, Lu Xiang, and Chunyang Chen. Differential testing of cross deep learning framework {APIs}: Revealing inconsistencies and vulnerabilities. In 32nd USENIX Security Symposium (USENIX Security 23) , pages 7393–7410, 2023

    2023

  5. [14]

    Harnessing llms for document- guided fuzzing of opencv library

    Bin Duan, Tarek Mahmud, Meiru Che, Yan Yan, Naipeng Dong, Dan Dongseong Kim, and Guowei Yang. Harnessing llms for document- guided fuzzing of opencv library. arXiv preprint arXiv:2507.14558 , 2025

    2025 arXiv

  6. [15]

    Ontology Matching

    J ´erˆome Euzenat and Pavel Shvaiko. Ontology Matching. Springer, 2013

    2013

  7. [16]

    Muffin: Testing deep learning libraries via neural architecture fuzzing

    Jiazhen Gu, Xuchuan Luo, Yangfan Zhou, and Xin Wang. Muffin: Testing deep learning libraries via neural architecture fuzzing. In Pro- ceedings of the 44th International Conference on Software Engineering , pages 1418–1430, 2022

    2022

  8. [17]

    Audee: Automated testing for deep learning frameworks

    Qianyu Guo, Xiaofei Xie, Yi Li, Xiaoyu Zhang, Yang Liu, Xiaohong Li, and Chao Shen. Audee: Automated testing for deep learning frameworks. In Proceedings of the 35th IEEE/ACM International Conference on Automated Software Engineering , pages 486–498, 2020

    2020

  9. [18]

    Deep learning for finance: deep portfolios

    James B Heaton, Nick G Polson, and Jan Hendrik Witte. Deep learning for finance: deep portfolios. Applied Stochastic Models in Business and Industry, 33(1):3–12, 2017

    2017

  10. [19]

    Fuzzing with code fragments

    Christian Holler, Kim Herzig, and Andreas Zeller. Fuzzing with code fragments. In 21st USENIX Security Symposium (USENIX Security 12) , pages 445–458, 2012

    2012

  11. [20]

    Binary codes capable of correcting deletions, insertions, and reversals

    Vladimir I Levenshtein. Binary codes capable of correcting deletions, insertions, and reversals. Soviet physics doklady , 10(8):707–710, 1966

    1966

  12. [21]

    Fuzzing: a survey

    Jun Li, Bodong Zhao, and Chao Zhang. Fuzzing: a survey. Cybersecu- rity, 1(1):1–13, 2018

    2018

  13. [22]

    Nnsmith: Generating diverse and valid test cases for deep learning compilers

    Jiawei Liu, Jinkun Lin, Fabian Ruffy, Cheng Tan, Jinyang Li, Aurojit Panda, and Lingming Zhang. Nnsmith: Generating diverse and valid test cases for deep learning compilers. In Proceedings of the 28th ACM International Conference on Architectural Support for Programming Langua...

    2023

  14. [23]

    Acid: an api compati- bility issue detector for android apps

    Tarek Mahmud, Meiru Che, and Guowei Yang. Acid: an api compati- bility issue detector for android apps. In Proceedings of the ACM/IEEE 44th International Conference on Software Engineering: Companion Proceedings, pages 1–5, 2022

    2022

  15. [24]

    Deep learning for healthcare: review, opportunities and chal- lenges

    Riccardo Miotto, Fei Wang, Shuang Wang, Xiaoqian Jiang, and Joel T Dudley. Deep learning for healthcare: review, opportunities and chal- lenges. Briefings in bioinformatics , 19(6):1236–1246, 2018

    2018

  16. [25]

    Pytorch: An imperative style, high-performance deep learning library

    Adam Paszke, Sam Gross, Francisco Massa, Adam Lerer, James Brad- bury, Gregory Chanan, Trevor Killeen, Zeming Lin, Natalia Gimelshein, Luca Antiga, Alban Desmaison, Andreas Kopf, Edward Yang, Zachary DeVito, Martin Raison, Alykhan Tejani, Sasank Chilamkurthy, Benoit Steiner, L...

    2019

  17. [26]

    Cradle: cross-backend validation to detect and localize bugs in deep learning libraries

    Hung Viet Pham, Thibaud Lutellier, Weizhen Qi, and Lin Tan. Cradle: cross-backend validation to detect and localize bugs in deep learning libraries. In 2019 IEEE/ACM 41st International Conference on Software Engineering (ICSE), pages 1027–1038. IEEE, 2019

    2019

  18. [27]

    Using gcov with GCC 12.1

    GNU Project. Using gcov with GCC 12.1 . Free Software Foundation, Boston, MA, USA, 2023

    2023

  19. [28]

    Deep learning for self-driving cars: Chances and challenges

    Qing Rao and Jelena Frtunikj. Deep learning for self-driving cars: Chances and challenges. In Proceedings of the 1st international workshop on software engineering for AI in autonomous systems , pages 35–38, 2018

    2018

  20. [29]

    Sentence-bert: Sentence embeddings using siamese bert-networks

    Nils Reimers and Iryna Gurevych. Sentence-bert: Sentence embeddings using siamese bert-networks. In Proceedings of the 2019 Conference on Empirical Methods in Natural Language Processing (EMNLP) , pages 3982–3992, 2019

    2019

  21. [30]

    Explainable deep learning models in medical image analysis

    Amitojdeep Singh, Sourya Sengupta, and Vasudevan Lakshminarayanan. Explainable deep learning models in medical image analysis. Journal of imaging, 6(6):52, 2020

    2020

  22. [31]

    Chainer: A next-generation open source framework for deep learning

    Seiya Tokui, Kenta Oono, Shohei Hido, and Justin Clayton. Chainer: A next-generation open source framework for deep learning. In Proceed- ings of Workshop on Machine Learning Systems (LearningSys) in NIPS , 2015

    2015

  23. [32]

    An efficient outlier detection with deep learning-based financial crisis prediction model in big data environment

    Yalla Venkateswarlu, K Baskar, Anupong Wongchai, Venkatesh Gauri Shankar, Christian Paolo Martel Carranza, Jos ´e Luis Arias Gonz´ales, and AR Murali Dharan. An efficient outlier detection with deep learning-based financial crisis prediction model in big data environment. Comp...

    2022

  24. [33]

    Eagle: creating equivalent graphs to test deep learning libraries

    Jiannan Wang, Thibaud Lutellier, Shangshu Qian, Hung Viet Pham, and Lin Tan. Eagle: creating equivalent graphs to test deep learning libraries. In Proceedings of the 44th International Conference on Software Engineering, pages 798–810, 2022

    2022

  25. [34]

    Deep learning library testing via effective model generation

    Zan Wang, Ming Yan, Junjie Chen, Shuang Liu, and Dongdi Zhang. Deep learning library testing via effective model generation. In Proceed- ings of the 28th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering, pag...

    2020

  26. [35]

    Free lunch for testing: Fuzzing deep-learning libraries from open source

    Anjiang Wei, Yinlin Deng, Chenyuan Yang, and Lingming Zhang. Free lunch for testing: Fuzzing deep-learning libraries from open source. In Proceedings of the 44th International Conference on Software Engineer- ing, pages 995–1007, 2022

    2022

  27. [36]

    Evaluating and improving neural program-smoothing-based fuzzing

    Mingyuan Wu, Ling Jiang, Jiahong Xiang, Yuqun Zhang, Guowei Yang, Huixin Ma, Sen Nie, Shi Wu, Heming Cui, and Lingming Zhang. Evaluating and improving neural program-smoothing-based fuzzing. In Proceedings of the 44th International Conference on Software Engineer- ing, pages 8...

    2022

  28. [37]

    Metamorphic testing of deep learning compilers

    Dongwei Xiao, Zhibo Liu, Yuanyuan Yuan, Qi Pang, and Shuai Wang. Metamorphic testing of deep learning compilers. Proceedings of the ACM on Measurement and Analysis of Computing Systems , 6(1):1–28, 2022

    2022

  29. [38]

    Docter: documentation-guided fuzzing for testing deep learning api functions

    Danning Xie, Yitong Li, Mijung Kim, Hung Viet Pham, Lin Tan, Xiangyu Zhang, and Michael W Godfrey. Docter: documentation-guided fuzzing for testing deep learning api functions. In Proceedings of the 31st ACM SIGSOFT International Symposium on Software Testing and Analysis, pag...

    2022

  30. [39]

    Advances in symbolic execution

    Guowei Yang, Antonio Filieri, Mateus Borges, Donato Clun, and Junye Wen. Advances in symbolic execution. Advances in Computers , 113:225–287, 2019

    2019

  31. [40]

    A synergistic approach to improving symbolic execution using test ranges

    Guowei Yang, Rui Qiu, Sarfraz Khurshid, Corina S P ˘as˘areanu, and Junye Wen. A synergistic approach to improving symbolic execution using test ranges. Innovations in Systems and Software Engineering , 15:325–342, 2019

    2019

  32. [41]

    An algebraic approach for managing inconsistencies in software processes

    Qiusong Yang, Mingshu Li, Qing Wang, Guowei Yang, Jian Zhai, Juan Li, Lishan Hou, and Yun Yang. An algebraic approach for managing inconsistencies in software processes. In International Conference on Software Process, pages 121–133. Springer, 2007

    2007

  33. [42]

    Summary-guided incremen- tal symbolic execution

    Qiuping Yi, Junye Wen, and Guowei Yang. Summary-guided incremen- tal symbolic execution. In Proceedings of the ACM/IEEE 42nd Interna- tional Conference on Software Engineering: Companion Proceedings , pages 310–311, 2020

    2020

  34. [43]

    Feedback-driven incremental symbolic execution

    Qiuping Yi and Guowei Yang. Feedback-driven incremental symbolic execution. In 2022 IEEE 33rd International Symposium on Software Reliability Engineering (ISSRE) , pages 505–516. IEEE, 2022

    2022

Pith tools

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