The ill fated commit I made yesterday was a partial attempt to address some of the problems: basically, it boils down to DEBUG blocks that induce extra debugging output that the test framework doesn't know about. I guess the correct thing to do is track all these places down individually and add checks for -dno-debug-output, though if some tests are checking for debug output, that might be tricky. Edward Excerpts from Simon Marlow's message of Tue Apr 05 15:35:45 -0400 2011:

On 05/04/11 17:50, Edward Z. Yang wrote:

...

Hello all,

If I run 'make fast' in the testsuite, with a stage2 compiler that has been built with -DDEBUG, should I be getting extra failures?

You shouldn't, but since we don't test that very often it's possible that some bugs have crept in. What failures are you seeing?

Cheers, Simon

On 06/04/2011 14:02, Max Bolingbroke wrote:

On 6 April 2011 12:04, Edward Z. Yang wrote:

...

The ill fated commit I made yesterday was a partial attempt to address some of the problems: basically, it boils down to DEBUG blocks that induce extra debugging output that the test framework doesn't know about.

You didn't used to get so many extra failures, but now GHC with -DDEBUG loves to say "constraint solver steps:<N>", so you basically can't test a compiler with -DDEBUG at all at the moment.

As Edward says, we should respect -dno-debug-output in these cases. There should probably be a variant of dumpTcRn that checks the flag. Cheers, Simon