by achew22 on 12/21/10, 12:47 PM with 8 comments
by bigmac on 12/21/10, 2:29 PM
Its not in the slides, but during the Q&A they revealed that far fewer bugs were found in gcc than in LLVM. With compilers, as with most software, battle-tested dinosaurs win the day when it comes to code quality.
Its also interesting to note that the greatest number of bugs were found in the InstCombine pass, which has been completely refactored. In LLVM2.6 it was one monolithic source code file (13000 lines) with a zillion different peephole optimizations. Now its broken up into 15 files.
by smcl on 12/21/10, 5:46 PM
I was astonished, these few tests yielded something like 5 serious bugs (crashes, bad optimisations) in the development branch. That was only when built -O (full optimisation, rarely reveals bugs) on a single architecture, if I'd spent a bit more time I reckon I could've uncovered a few more just be adding or changing the build switches alone for the same tests.
Unfortunately I wasn't able to do this, as I was let go shortly afterwards and wasn't able to convince anyone that we should include this in regular testing before I left. I wasn't even able to submit bug reports to John Regehr and his team at Utah University - who were curious about what kinds of bugs their tool was uncovering - even though I promised I would.
by pohl on 12/21/10, 2:07 PM
Very cool.
The slides don't make it clear whether the various bugs discovered ended up being covered by unit tests in the regular LLVM suite.
Does anybody remember in the mid 90s there was a 'crashme' program that could be used to fuzz test the Linux kernel? I recall looking for it again about 5 years ago and couldn't find references to it. Did that technique fall out of use?
by tdj on 12/21/10, 2:18 PM
I also wish that this testing methodology would be adopted by other projects, makes QA much easier.
by barrkel on 12/21/10, 2:30 PM
http://docs.google.com/viewer?url=http%3A%2F%2Fwww.llvm.org%...