<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">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.<div class="">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</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Best,</div><div class="">Min</div><div class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Nov 6, 2020, at 6:16 AM, Zhide Zhou via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="line-height: 1.7; font-size: 14px; font-family: Arial;" class=""><div style="margin:0;" class="">Hi, developers,</div><div style="margin:0;" class="">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.</div><div style="margin:0;" class="">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.</div><div style="margin:0;" class=""><br class=""></div><div style="margin:0;" class="">Thanks!</div><div style="margin:0;" class=""><br class=""></div><div class="">[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://doi.org/10.1145/3338906.3338957" _src="https://doi.org/10.1145/3338906.3338957" class="">https://doi.org/10.1145/3338906.3338957</a> </div><div class="">[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.</div></div><br class=""><br class=""><span title="neteasefooter" class=""><div class=""> <br class="webkit-block-placeholder"></div></span>_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a><br class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<br class=""></div></blockquote></div><br class=""></div></body></html>