------- Comment #7 from baldrick at gcc dot gnu dot org 2007-06-07 07:07 ------- > Valgrind is helful only if there is a crash (segmentation fault).
This is completely wrong. Valgrind detects problems that *may* cause a crash. The fact that crashes occur rarely doesn't mean there isn't something wrong. I already explained that you can't expect to get a segmentation fault on a small program. So for a testcase I either had to provide the large (300k/loc) original program which showed the segmentation fault systematically, or a small program which basically never shows a segmentation fault. i.e. testcases become less and less deterministic as you make them smaller. However there is a way to keep things deterministic: run under a tool such as valgrind. Valgrind detects the same problem every time no matter how big or small the testcase. This makes it feasible to submit a minimal testcase which captures the essential problem, even though when run normally (i.e. not under valgrind) it executes fine. In fact you will never get a segmentation fault with the testcase I submitted because it doesn't ever dereference the uninitialized pointer - but that doesn't matter because valgrind notices that it contains an uninitialized value when the "if" compares it with null. i.e. the testcase is good enough for debugging the compiler problem. Let me say it again: when run on the small testcase valgrind shows the presence of an uninitialized value that doesn't cause any problems when the small testcase is run - it causes problems on the large program from which this testcase was reduced. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32234