Re: testsuite results

2011-05-15 Thread Edward Z. Yang
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!
 

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


Re: Linking in Dead Code

2011-05-15 Thread B. Scott Michel
Cores don't necessarily help linking because it's I/O bound and very concrete 
sequential algo.
Sent from my Verizon Wireless BlackBerry

-Original Message-
From: Guy guytsalmave...@yahoo.com
Sender: glasgow-haskell-users-boun...@haskell.org
Date: Sat, 14 May 2011 22:08:16 
To: glasgow-haskell-users@haskell.org
Subject: Re: Linking in Dead Code

On 14/05/2011 21:10, Daniel Fischer wrote:
 Linking still tends to use a lot of memory with ld, on the appropriate
 platforms you could try using gold as the linker, that's reported to use
 less memory (and be faster).

No gold for windows :-( Another problem with ld is that it's only single core.


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users