4 ms·

Finding and Understanding Bugs in C Compilers (2011) [pdf]

• pfdietz 1y ago
  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.
  • wyldfire 1y ago
    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.
    • jcranmer 1y ago
      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.
      • stassats 1y ago
        A good strategy if you don't care about fixing bugs.
        • pfdietz 1y ago
          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.
        • deleted 1y ago
          [deleted]
    • pfdietz 1y ago
      Really any tooling that parses things can be used with Creduce. It doesn't even have to be C.