On May 26, 2008, at 11:55 PM, Chandler Carruth wrote:> This would make the summary of > <http://chandlerc.net/llvm-coverage/lib/Target/PowerPC/ > PPCHazardRecognizers.cpp.gcov.html> > much more favorable. > > I'm not seeing the bad aspect of this particular file? It has pretty > good coverage, is code calling into this "bad"? If so, then > assertions, or logging or something might be more appropriate. > Coverage just says that it got used, not that its use was > "correct". ;]I think he means the lines like: switch (Opcode) { default: assert(0 && "Unknown load!"); where the default case is never executed. -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080527/96d6be36/attachment.html>
On Tue, May 27, 2008 at 8:50 PM, Chris Lattner <sabre at nondot.org> wrote:> I think he means the lines like: > > switch (Opcode) { > > default: assert(0 && "Unknown load!"); > > > where the default case is never executed. > > I would personally appreciate expected to fail tests that ensure theassertions actually catch the bad inputs that they were designed to catch, there by executing those lines. I realize that many couldn't be tested in this manner (they assert on malformed data in the middle, which should be caught much earlier). Anyways, I'm gonna go prod the generated files, and see if I can capture at least some of that code. -Chandler> -Chris > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080527/ff584ef1/attachment.html>
Hi,> > I think he means the lines like: > > > > switch (Opcode) { > > > > default: assert(0 && "Unknown load!"); > > > > > > where the default case is never executed. > > > I would personally appreciate expected to fail tests that ensure the > assertions actually catch the bad inputs that they were designed to catch, > there by executing those lines. I realize that many couldn't be tested in > this manner (they assert on malformed data in the middle, which should be > caught much earlier). Anyways, I'm gonna go prod the generated files, and > see if I can capture at least some of that code.I don't think assertions should be used to catch malformed input. Assertions should be used to check that impossible things aren't happening, not possible things. The right way to handle malformed input IMHO is to output a message and explicitly abort, whether assertions are enabled or not. In short it should be impossible to get test coverage for assertions because by definition they should be impossible to reach. Ciao, Duncan.