search for: zhide

Hi, developers, 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

Hi there, I am working with opt-6.0 and try to generate a call graph of libsndfile, but it seems the call graph doesn't cover all call relationship. Actually, I am doing static analysis on *CVE-2014-8130*, which is a zero division on libtiff/tif_write.c TIFFWriteScanline. (see https://security-tracker.debian.org/tracker/CVE-2014-8130) Theoretically, the main function in

...e 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. Best, Min > On Nov 6, 2020, at 6:16 AM, Zhide Zhou via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi, developers, > 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...

Hi everyone, I want to test the passes in llvm, and I got some passes sequences that caused the crash of opt. Although I can use bugpoint to narrow down the source of problems, I can only get some reduced and simplified IR and passes to reproduce the problem. My question is how to get the reduced IR of the original IR file to reproduce the problem. For example, "opt a.bc -a -b -c -d (where