<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">I skimmed the first paper. I’m assuming they picked mis-compile bugs (bad code generation). It looks like a technique to triangulate on the likely buggy module by mutating the example code provided with a bug report, and comparing coverage
traces for “good” and “bad” sources. It’s very black-box, assuming no diagnostic aids from the software under test, but that’s reasonable for an automated technique.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">In my experience, many bugs have fairly obvious origins (at least in terms of likely source modules) to someone experienced in a given area. But I could see this being a useful tool for bugs with less obvious origins, and certainly a lot
less tedious than wading through lots of diagnostic output. Also could be useful to people less familiar with LLVM, as one way to narrow down the search for a bug without needing to learn a lot about LLVM’s own diagnostic tools.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">FTR, the paper says the benchmark and code are available at the project webpage:
<a href="https://github.com/JunjieCheck/DiWi">https://github.com/JunjieCheck/DiWi</a> if anyone wants to try it out.<o:p></o:p></p>
<p class="MsoNormal">--paulr<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> llvm-dev <llvm-dev-bounces@lists.llvm.org> <b>On Behalf Of
</b>Min-Yih Hsu via llvm-dev<br>
<b>Sent:</b> Friday, November 6, 2020 12:29 PM<br>
<b>To:</b> Zhide Zhou <cszide@163.com><br>
<b>Cc:</b> llvm-dev@lists.llvm.org<br>
<b>Subject:</b> Re: [llvm-dev] How to find the root causes of compiler bugs in practice?<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">In general, finding the root cause in LLVM is not really a big difference than debugging a normal software: Depending on the scenario, if it’s a crash then putting it on a gdb is probably the first step you wanna do. And this usually can
tell you the answer pretty fast.<o:p></o:p></p>
<div>
<p class="MsoNormal">More tricky scenarios usually involving developers to leverage various of LLVM-specific diagnosing features, the `-print-after-all` CLI option in opt, to name a few, to provide more insights on the intermediate steps. To help you narrowing
down the problematic region. If the input is too big, more advanced tool like bugpoint (this is also LLVM-specific tool) can help you bisecting and trimming the input. After these (pre)processing, normal debugging tricks like gdb or even the good-old-printf
can be easily applied<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">IMHO the efficiency of finding root cause heavily depends on your experiences on engineering. And I 100% agree that it sometimes takes a lot of time. So it kinda makes sense that people want to automate it, but I’m not an expert on this
matter. All I know is there has been tons of research and efforts on finding bugs - there might be some overlap on these two topics, i’m not really sure. But you might want to checkout techniques like fuzzing, and sanitizer. LLVM has pretty mature implementations
on both of them.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Best,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Min<o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">On Nov 6, 2020, at 6:16 AM, Zhide Zhou via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Arial",sans-serif">Hi, developers,<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Arial",sans-serif">Recently, I read two papers [1], [2] about finding the root causes of compiler bugs. However, I do not find any information in these paper about how compiler developers find
the root causes of compiler bugs in practice. So I am curious whether these techniques are useful in practice. For my experience, the outputs of compilers are always used to isolate the causes of compiler bugs, such as the IR after each pass or the backtrace.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Arial",sans-serif">I am a newbie for LLVM. So I am curious how developers of LLVM or GCC find the root causes of compiler bugs in practice.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Arial",sans-serif"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Arial",sans-serif">Thanks!<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Arial",sans-serif"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Arial",sans-serif">[1] Junjie Chen, Jiaqi Han, Peiyi Sun, Lingming Zhang, Dan Hao, and Lu Zhang. 2019. 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 (ESEC/FSE 2019). Association for Computing Machinery, New York, NY, USA, 223–234. DOI:<a href="https://urldefense.com/v3/__https:/doi.org/10.1145/3338906.3338957__;!!JmoZiZGBv3RvKRSx!vPRrEiiBNs81YnmhqWD8vnz5PepmivNOy63gXrXkgTO2DODexM6QTO5QZkWF-IB1vg$">https://doi.org/10.1145/3338906.3338957</a>
<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Arial",sans-serif">[2] Junjie Chen, Haoyang Ma, Lingming Zhang, Enhanced Compiler Bug Isolation via Memoized Search, Proceedings of the 35th IEEE/ACM International Conference on Automated Software
Engineering.<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><br>
<br>
<br>
<o:p></o:p></p>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<p class="MsoNormal">_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="https://urldefense.com/v3/__https:/lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev__;!!JmoZiZGBv3RvKRSx!vPRrEiiBNs81YnmhqWD8vnz5PepmivNOy63gXrXkgTO2DODexM6QTO5QZkXXVwystQ$">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><o:p></o:p></p>
</div>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</body>
</html>