
Running the testsuite with today's HEAD (perf build, but without profiling to keep time bearable) resulted in: ==================== OVERALL SUMMARY for test run started at Do 12. Mai 13:34:13 CEST 2011 2765 total tests, which gave rise to 9300 test cases, of which 0 caused framework failures 1587 were skipped 7467 expected passes 229 expected failures 9 unexpected passes 8 unexpected failures ==================== Pretty cool, I can't remember having so few unexpected failures before. ==================== Unexpected failures: T5084(normal) That's the compiler not complaining about an INLINE-pragma on a class method without default implementation. Patch is in ghc-generics branch, not yet in master, according to #5084. Anyway it's nothing serious (was a feature request, not a bug). dph-diophantine-opt(normal,threaded1,threaded2) These are due to a missing Show instance for [:Int:], a library issue. dph-words-opt(normal) Fails with "dph-words-opt: libraries/vector/Data/Vector/Generic.hs:369 (slice): invalid slice (1,2,2)". No idea whether that's a library or a compiler issue. hpc_markup_multi_001(normal) hpc_markup_multi_002(normal) hpc_markup_multi_003(normal) Those are due to hpc looking in the wrong directory for the tix files, patch exists, but is not yet in the master branch, according to #5069. So, of the eight unexpected failures, six are due to trivia (they *might* fail for other causes when the trivia are fixed, but there's no reason to expect that), one is a feature request whose test reached testsuite/master before the implementation reached ghc/master and only one may (but need not) indicate a compiler bug at present, that's rather awesome. ==================== Unexpected passes: mc01(hpc,ghci) mc06(hpc,ghci) mc08(hpc,ghci) mc11(hpc) mc16(hpc) mc18(hpc) All these involve the new MonadComprehensions extension, they're expected to work and do so for the normal and optasm ways, maybe they should also be expected to work for hpc and ghci. Additionally, sometimes conc016(threaded2) passes unexpectedly; which thread first gets its exception to the other one is impossible to predict: -- NB. this test is delicate since 6.14, because throwTo is now always -- interruptible, so the main thread's killThread can be legitimately -- interrupted by the child thread's killThread, rather than the other -- way around. This happens because the child thread is running on -- another processor, so the main thread's throwTo is blocked waiting -- for a response, and while waiting it is interruptible. Summing up: Yay!

| hpc_markup_multi_001(normal) | hpc_markup_multi_002(normal) | hpc_markup_multi_003(normal) | Unexpected passes: | mc01(hpc,ghci) | mc06(hpc,ghci) | mc08(hpc,ghci) | mc11(hpc) | mc16(hpc) | mc18(hpc) I pushed patches for all of these today | Summing up: Yay! Indeed!

On Thursday 12 May 2011 17:49:16, Simon Peyton-Jones wrote:
| hpc_markup_multi_001(normal) | hpc_markup_multi_002(normal) | hpc_markup_multi_003(normal) | | Unexpected passes: | mc01(hpc,ghci) | mc06(hpc,ghci) | mc08(hpc,ghci) | mc11(hpc) | mc16(hpc) | mc18(hpc)
I pushed patches for all of these today
Great!
Now I've built HEAD (7b3a746294d3d034da0052644237e4d1ab1f08c8, minus the
patch removing the import Config from AsmCodeGen, cf #5194) with profiling,
leading to
====================
OVERALL SUMMARY for test run started at Do 12. Mai 20:47:35 CEST 2011
2766 total tests, which gave rise to
11839 test cases, of which
0 caused framework failures
2123 were skipped
9428 expected passes
280 expected failures
1 unexpected passes
7 unexpected failures
====================
Unexpected passes:
conc016(threaded2)
Well, that one occasionally happens.
====================
Unexpected failures:
T3016(profasm)
timeout-killed, too much other stuff running, rerunning T3016 on a less
busy machine made it pass, but I'm not too happy with the stats:
<
| Summing up: Yay!
Indeed!
Still very much yay, I can't find the new unexpected failure of T3064 disappointing in the least, only T3016(profasm) and dph-words-opt leave something to be desired.

To chime in, latest validate for me on x86-32 had two fails: OVERALL SUMMARY for test run started at Sun May 15 16:16:28 BST 2011 2773 total tests, which gave rise to 10058 test cases, of which 0 caused framework failures 7598 were skipped 2377 expected passes 81 expected failures 0 unexpected passes 2 unexpected failures Unexpected failures: T3064(normal) (the improved GHC) T5084(normal) (the now typechecking expr) Edward Excerpts from Daniel Fischer's message of Thu May 12 10:59:01 -0400 2011:
Running the testsuite with today's HEAD (perf build, but without profiling to keep time bearable) resulted in:
==================== OVERALL SUMMARY for test run started at Do 12. Mai 13:34:13 CEST 2011 2765 total tests, which gave rise to 9300 test cases, of which 0 caused framework failures 1587 were skipped
7467 expected passes 229 expected failures 9 unexpected passes 8 unexpected failures ====================
Pretty cool, I can't remember having so few unexpected failures before.
==================== Unexpected failures: T5084(normal)
That's the compiler not complaining about an INLINE-pragma on a class method without default implementation. Patch is in ghc-generics branch, not yet in master, according to #5084. Anyway it's nothing serious (was a feature request, not a bug).
dph-diophantine-opt(normal,threaded1,threaded2)
These are due to a missing Show instance for [:Int:], a library issue.
dph-words-opt(normal)
Fails with "dph-words-opt: libraries/vector/Data/Vector/Generic.hs:369 (slice): invalid slice (1,2,2)". No idea whether that's a library or a compiler issue.
hpc_markup_multi_001(normal) hpc_markup_multi_002(normal) hpc_markup_multi_003(normal)
Those are due to hpc looking in the wrong directory for the tix files, patch exists, but is not yet in the master branch, according to #5069.
So, of the eight unexpected failures, six are due to trivia (they *might* fail for other causes when the trivia are fixed, but there's no reason to expect that), one is a feature request whose test reached testsuite/master before the implementation reached ghc/master and only one may (but need not) indicate a compiler bug at present, that's rather awesome.
====================
Unexpected passes: mc01(hpc,ghci) mc06(hpc,ghci) mc08(hpc,ghci) mc11(hpc) mc16(hpc) mc18(hpc)
All these involve the new MonadComprehensions extension, they're expected to work and do so for the normal and optasm ways, maybe they should also be expected to work for hpc and ghci.
Additionally, sometimes conc016(threaded2) passes unexpectedly; which thread first gets its exception to the other one is impossible to predict:
-- NB. this test is delicate since 6.14, because throwTo is now always -- interruptible, so the main thread's killThread can be legitimately -- interrupted by the child thread's killThread, rather than the other -- way around. This happens because the child thread is running on -- another processor, so the main thread's throwTo is blocked waiting -- for a response, and while waiting it is interruptible.
Summing up: Yay!

Continuing with today's HEAD's results: 7506 expected passes 235 expected failures 0 unexpected passes 9 unexpected failures More failures than Friday, with fewer tests run (no profiling). But what's the actual difference? We have our old acquaintances T3064(normal) T5084(normal) dph-diophantine-opt(normal,threaded1,threaded2) dph-words-opt(normal) T3016(profasm) obviously wasn't run, without profiling support. New are: ds022(normal) an overlapping pattern warning used to report the first overlapping patterns, now the last; the expected stderr output has been updated meanwhile, but my testsuite was started before that. 3307(normal) environment001(normal) These two failed with (mutatis mutandis) Actual stderr output differs from expected: --- /dev/null 2011-05-15 19:13:45.604004218 +0200 +++ ./lib/IO/environment001.run.stderr.normalised 2011-05-16 12:33:18.000000000 +0200 @@ -0,0 +1 @@ +/bin/sh: Zeile 0: echo: Schreibfehler: Datenübergabe unterbrochen (broken pipe). *** unexpected failure for environment001(normal) I think it's the testsuite driver interacting badly with my OS, because running `make TEST=XY' in the testsuite directory consistently fails with a broken pipe, but running the tests from the .../lib/IO directory, either by manually issuing the commands from the command line or by running `make XY-test', consistently succeeds (including the production of the correct output). Altogether, things still look good.
participants (3)
-
Daniel Fischer
-
Edward Z. Yang
-
Simon Peyton-Jones