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