Finding and Understanding Bugs in C Compilers (2011) [pdf](users.cs.utah.edu)
users.cs.utah.edu
Finding and Understanding Bugs in C Compilers (2011) [pdf]
https://users.cs.utah.edu/~regehr/papers/pldi11-preprint.pdf
7 comments
The Csmith paper. The follow-on paper about Creduce is also worth reading. Creduce takes valid programs and reduces them to smaller valid programs, using some predicate (does this shell script finish with an error code?). This allows hits by Csmith to be greatly minimized automatically. Maintaining validity during shrinking is the central problem.
cvise and llvm-reduce are really good complements to c-reduce. Allows for mechanical reduction without any understanding of how compilers / backends are designed. I've found that it's much quicker to get a fix if I do the reduce before opening the bug.
As a compiler developer, if you give me a bug and the source is not reduced, I'm decently likely to tell you to reduce it first before I attempt to take a look at it.
A good strategy if you don't care about fixing bugs.
Still, I try to be polite and reduce the code some before making the bug report. I don't want to come across as lazy and load you (in particular) with work I could have done.
Having said that, reduction can be tricky, and I need to do more work on that with the Common Lisp random tester, so as to allow more language constructs to be in the random code.
Having said that, reduction can be tricky, and I need to do more work on that with the Common Lisp random tester, so as to allow more language constructs to be in the random code.
[deleted]
Really any tooling that parses things can be used with Creduce. It doesn't even have to be C.