Friends
Have you done a full 32-bit Windows build recently? 'sh validate --fast' gives
these errors, and I wonder if we could squash them? I've appended the error
output for each below, except for the perf ones, and T5975a which has a huge
mass of Chinese characters.
Would anyone like to hel
Ian
I'm getting these failures on 64-bit Linux. Might you fix? I think these are
the tests you added recently
perf/haddock haddock.base [stat too good] (normal)
perf/haddock haddock.compiler [stat not good enough] (normal)
=> haddock.base(normal) 1583 of 3411 [0, 0, 0]
max_byte
I failed to push some patches; now done
S
| -Original Message-
| From: cvs-ghc-boun...@haskell.org [mailto:cvs-ghc-boun...@haskell.org]
| On Behalf Of Ian Lynagh
| Sent: 23 June 2012 14:19
| To: cvs-ghc@haskell.org
| Subject: Validate test failures
|
|
| Hi all,
|
| There are
Hi all,
There are currently 3 test failures when validating:
typecheck/should_compile T4361 [exit code non-0] (normal)
typecheck/should_fail tcfail181 [stderr mismatch] (normal)
typecheck/should_fail tcfail189 [stderr mismatch] (normal)
Does anyone know what's goi
l 2012 11:42
| To: Simon Peyton-Jones
| Cc: cvs-ghc@haskell.org
| Subject: Re: Test failures
|
| On 25/04/2012 15:32, Simon Peyton-Jones wrote:
| > A dozen tests on Linux are failing thus. Any ideas what 'openpty' is?
| >
| > Simon
| >
| > => hTell002(dyn) 3178 of 3291 [
On 25/04/2012 15:32, Simon Peyton-Jones wrote:
A dozen tests on Linux are failing thus. Any ideas what ‘openpty’ is?
Simon
=> hTell002(dyn) 3178 of 3291 [0, 49, 49]
cd ../../libraries/base/tests &&
'/5playpen/simonpj/HEAD/inplace/bin/ghc-stage2' -fforce-recomp
-dcore-lint -dcmm-lint -dno-d
A dozen tests on Linux are failing thus. Any ideas what 'openpty' is?
Simon
=> hTell002(dyn) 3178 of 3291 [0, 49, 49]
cd ../../libraries/base/tests &&
'/5playpen/simonpj/HEAD/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint
-dcmm-lint -dno-debug-output -no-user-package-conf -rtsopts -fn
Oops, I had a testsuite commit just sitting in my local tree I'd
forgotten about so I never was getting these warnings. Sorry for the
delay.
On 6 April 2012 04:37, Simon Peyton-Jones wrote:
> There are still a bunch of test failures on Windows/msys. There seem to be
> t
There are still a bunch of test failures on Windows/msys. There seem to be
these groups:
*Safe Haskell (6)
*GHCi/linking 'ar' not found (something in the build system?)
=> ghcilink001(normal) 788 of 3237 [0, 1, 0]
cd ./ghci/linking && $MAKE -s
Repository : ssh://darcs.haskell.org//srv/darcs/testsuite
Branch 'ghc-7.4' now includes:
d0a14b0... accept output ("Linking" message moved from stderr to stdout)
b0a8b2f... accept output
4d39beb... clean up test failures
___
mon Marlow
Date: Mon Nov 21 15:22:37 2011 +
clean up test failures
>---
tests/lib/libposix/all.T | 18 ++
tests/lib/libposix/posix006.hs |6 --
2 files changed, 18 insertions(+), 6 deletions(-)
On 10 August 2011 03:18, Manuel M T Chakravarty wrote:
> So, now we are down to two failures:
>
>> Unexpected failures:
>> cabal ghcpkg01 [bad stdout] (normal)
>> concurrent/should_run numsparks001 [bad exit code] (threaded1)
>
> For ghcpkg01, I get
>
Oops! Thanks, this is
Simon Peyton-Jones:
> This is Duncan. He's working on it; to quote:
>
> | Mm.
> |
> | I'll see what my extra tracing turns up. I may not have time to look at
> | this today. I've got a couple deadlines today.
>
> Maybe turn to expect_broken to avoid discombobulation?
It sounds as if he wil
| > Stderr:
| > numsparks001: internal error: ASSERTION FAILED: file rts/Schedule.c, line
1473
| >
| > (GHC version 7.3.20110809 for x86_64_apple_darwin)
| > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
| >
| > *** unexpected failure for numsparks001(threaded1)
|
So, now we are down to two failures:
> Unexpected failures:
>cabal ghcpkg01 [bad stdout] (normal)
>concurrent/should_run numsparks001 [bad exit code] (threaded1)
For ghcpkg01, I get
> Actual stdout output differs from expected:
> --- ./cabal/ghcpkg01.stdout 2011-07-27
David Terei:
> The Safe Haskell ones have been fixed a couple of hours back, if you
> pull the latest testsuite but are getting failure let me know.
One of my repos somehow forgot which remote it was tracking, which stopped
./sync-all prematurely — so, it didn't pull all repos.
Sorry,
Manuel
>
The Safe Haskell ones have been fixed a couple of hours back, if you
pull the latest testsuite but are getting failure let me know.
Cheers,
David
On 9 August 2011 22:03, Manuel M T Chakravarty wrote:
> A few days ago, I had zero failures on OS X, now I have
>
>> Unexpected passes:
>> th/TH_re
A few days ago, I had zero failures on OS X, now I have
> Unexpected passes:
>th/TH_recompile TH_recompile (normal)
>
> Unexpected failures:
>cabalghcpkg01 [bad stdout] (normal)
>ghci/scripts T4127 [bad stdout] (ghci)
>module mod9
On 06/08/2011 19:38, Ian Lynagh wrote:
On Fri, Aug 05, 2011 at 03:09:11PM +0100, Simon Marlow wrote:
I get almost identical results on my Linux box here. Ok, so to
summarise the T4801 results:
peak MB: Linux; 61
OS X : 72
allocations: Linux: 72GB
OS X:
On Sun, Aug 07, 2011 at 02:45:04PM +1000, Manuel M T Chakravarty wrote:
>
> Is that correct? 1s mutator versus 75s GC?
When running with -hT, yes.
> Seems the version is a bit faster, though. (Or is that on different
> hardware?)
Different hardware.
Thanks
Ian
__
Ian Lynagh:
> On Fri, Aug 05, 2011 at 03:09:11PM +0100, Simon Marlow wrote:
>>
>> I get almost identical results on my Linux box here. Ok, so to
>> summarise the T4801 results:
>>
>> peak MB: Linux; 61
>> OS X : 72
>>
>> allocations: Linux: 72GB
>> OS X: 81GB
>>
On Fri, Aug 05, 2011 at 03:09:11PM +0100, Simon Marlow wrote:
>
> I get almost identical results on my Linux box here. Ok, so to
> summarise the T4801 results:
>
> peak MB: Linux; 61
> OS X : 72
>
> allocations: Linux: 72GB
> OS X: 81GB
>
> those differences
On 05/08/2011 13:35, Daniel Fischer wrote:
On Friday 05 August 2011, 13:51:32, Manuel M T Chakravarty wrote:
Yes, I used standard validate settings. Judging by the timestamps, the
Linux numbers are from a while ago. They may be closer to the (old)
limit than they used to be when the limits we
On Friday 05 August 2011, 13:51:32, Manuel M T Chakravarty wrote:
>
> Yes, I used standard validate settings. Judging by the timestamps, the
> Linux numbers are from a while ago. They may be closer to the (old)
> limit than they used to be when the limits were set.
In particular the "bytes allo
888f3a558e1e135e4d8ad12698c2f7d90
>>
>>> ---
>>
>> commit bea1187888f3a558e1e135e4d8ad12698c2f7d90
>> Author: Manuel M T Chakravarty
>> Date: Fri Aug 5 13:01:05 2011 +1000
>>
>> Fix remaining test failures on OS X/x86_64
>>
bea1187888f3a558e1e135e4d8ad12698c2f7d90
Author: Manuel M T Chakravarty
Date: Fri Aug 5 13:01:05 2011 +1000
Fix remaining test failures on OS X/x86_64
* Adapted the limits of two performance tests for OS X/x86_64
Some of these limits had to be bumped by 10% or more. Can you think of
a
l M T Chakravarty
Date: Fri Aug 5 13:01:05 2011 +1000
Fix remaining test failures on OS X/x86_64
* Adapted the limits of two performance tests for OS X/x86_64
* ghci/linking tests need to use .dylib for shared libraries on OS X
Zero test failures on OS X/x86_64 (for
On 31/07/2011 21:46, Edward Z. Yang wrote:
indexed-types/should_compile T3017 [stderr mismatch] (normal)
indexed-types/should_fail NoMatchErr [stderr mismatch] (normal)
indexed-types/should_fail T2544 [stderr mismatch] (normal)
indexed-types/should_fail T2627b [stder
dynlibs T3807 [bad exit code] (normal)
indexed-types/should_compile T3017 [stderr mismatch] (normal)
indexed-types/should_fail NoMatchErr [stderr mismatch] (normal)
indexed-types/should_fail T2544 [stderr mismatch] (normal)
indexed-types/should_fail
I was trying to share some files between tests but this doesn't really
work when you use multiple threads to run the testsuite. It should be
fixed now.
Cheers,
David
On 7 July 2011 01:38, Simon Marlow wrote:
> I have a few test failures in a validate run related to Saf
I have a few test failures in a validate run related to SafeHaskell:
--- ./safeHaskell/check/Check01_fail.stderr.normalised 2011-07-07
09:31:53.7807
33921 +0100
+++ ./safeHaskell/check/Check01_fail.comp.stderr.normalised
2011-07-07 09:31
:53.780733921 +0100
@@ -1 +1 @@
-[3 of 3] Compiling
On 07/02/2011 15:16, Simon Peyton-Jones wrote:
Ian
I’m getting this. I think I’ve pulled all stuff. Maybe a missing update
to tests in stm/tests?
I'm fixing this. Note that stm is an "extra" package, so Ian probably
doesn't have it in his validate run.
Cheers,
Simon
Simon
=
Ian
I'm getting this. I think I've pulled all stuff. Maybe a missing update to
tests in stm/tests?
Simon
=> stm053(threaded1) 2690 of 2715 [0, 4, 0]
cd ../../../libraries/stm/tests &&
'/64playpen/simonpj/builds/HEAD/bindisttest/install dir/bin/ghc' -fforce-recomp
-dcore-lint -dcmm-lint
Tue Sep 29 02:04:10 PDT 2009 Simon Marlow
* wibbles to setting LC_ALL, trying to fix buildbot test failures
Ignore-this: ea290fa166ce8ff81bff95c928404453
M ./driver/runtests.py -2 +3
View patch online:
http://darcs.haskell.org/testsuite/_darcs/patches/20090929090410-12142
On 02/05/2009 01:14, Duncan Coutts wrote:
On Fri, 2009-05-01 at 12:05 +0100, Duncan Coutts wrote:
So the specific dyn way failures are:
[ ... ]
Turns out all but two are instances of the same problem which is fixed
by this patch:
Fri May 1 13:14:45 BST 2009 Duncan Coutts
* Make ghc -dyn
On Fri, 2009-05-01 at 09:33 +0100, Duncan Coutts wrote:
> Currently I'm getting some test failures for WAY=dyn. I'm not posting
> the full list at the moment as I'm not convinced it's quite accurate.
> I'll post an update later.
Unexpected failures:
1679(dyn)
Currently I'm getting some test failures for WAY=dyn. I'm not posting
the full list at the moment as I'm not convinced it's quite accurate.
I'll post an update later.
I've investigated ffi002. This test ffi exports a Haskell foo function
and calls it from a C main
I've noticed some odd test failures from the buildbots recently. e.g. last
night I saw the following, all on the 6.10 branch:
on x86_64-Linux:
conc023(threaded2)
signals004(threaded2)
on x86-Linux:
conc023(threaded2)
on x86-Windows:
list001(ghci)
There are several
Wed Jan 14 11:16:21 PST 2009 Ian Lynagh
* Move the Makefile changes around so they don't cause test failures
Our "make clean" detection was causing problems for tests which had
their own local clean target.
M ./Makefile +13
M ./mk/boilerplate.mk -8
M ./timeo
On Thu, Sep 11, 2008 at 09:25:46AM +0100, Simon Marlow wrote:
> Simon Peyton-Jones wrote:
>
> >=> bytestring001(optc)
> >Segmentation fault
>
> This is a segfault from GHC - perhaps you have old interface files in
> your bytestring package?
Nope, it's reproducible:
$ ls bytestring001.
Simon Peyton-Jones wrote:
I ran a full testsuite today. Several bytestring tests are seg-faulting
consistently, when -O is on. See below. Does anyone have a clue about why?
Simon
=> bytestring001(normal)
cd ./lib/Data.ByteString && '/64playpen/simonpj/builds/HEAD-1/ghc/stage2-inplace/gh
I ran a full testsuite today. Several bytestring tests are seg-faulting
consistently, when -O is on. See below. Does anyone have a clue about why?
Simon
=> bytestring001(normal)
cd ./lib/Data.ByteString &&
'/64playpen/simonpj/builds/HEAD-1/ghc/stage2-inplace/ghc' -fforce-recomp
-dcore-l
On Mon, Jun 09, 2008 at 08:08:08AM +0200, Thorkil Naur wrote:
>
> On Monday 09 June 2008 00:18, Ian Lynagh wrote:
> > ...
> > If you send us the your /usr/include/dlfcn.h (which should #define
> > RTLD_DEFAULT), /usr/include/time.h and /usr/include/sys/time.h (one of
> > which should give a protot
Hello,
On Monday 09 June 2008 00:18, Ian Lynagh wrote:
> ...
> If you send us the your /usr/include/dlfcn.h (which should #define
> RTLD_DEFAULT), /usr/include/time.h and /usr/include/sys/time.h (one of
> which should give a prototype for gettimeofday) then hopefully we can
> see a way around it.
On Sun, Jun 08, 2008 at 11:14:28PM +0200, Thorkil Naur wrote:
>
> > warning: passing argument 2 of 'gettimeofday' from incompatible
> >pointer type
> > error: 'RTLD_DEFAULT' undeclared (first use in this function)
I suspect that one of these is the problem:
> > > # de
Hello,
I have looked at this, not to the bottom, but perhaps to a level where you
will be able to proceed. Otherwise, I'll happily continue later.
The compile that fails (edited to reduce line lengths) is this:
/usr/libexec/gcc/powerpc-apple-darwin8/4.0.1/cc1 \
-quiet \
-v \
-I \
. \
It seems the PPC OSX buildbot is failing all its -fvia-C tests, with the
error below. We ought to look into this before the 6.8.3 release.
Thorkil, can you shed any light?
Cheers,
Simon
> arr001(optc)
cd ./array/should_run &&
'/Users/thorkilnaur/tn/buildbot/ghc/tnaur-ppc-osx/tnau
Simon Marlow wrote:
But not these:
Unexpected failures:
GADT11(normal)
Simple13(normal)
derefnull(normal)
divbyzero(normal)
equal(normal)
set(normal)
syn-perf(normal)
tc(normal)
tc095(normal)
termination(normal)
while(normal)
Linux i686 dual-core, happening wi
Isaac Dupree wrote:
these are the current set of validation failures for HEAD on my machine,
(the same just before and after committing my portability cleanup.)
They've all been around for quite a while, except list001(ghci) is a
little more recent, as listed in some previous e-mail I sent. Do
these are the current set of validation failures for HEAD on my machine,
(the same just before and after committing my portability cleanup.)
They've all been around for quite a while, except list001(ghci) is a
little more recent, as listed in some previous e-mail I sent. Do you
need any more in
Hi Claus,
On Sat, Sep 15, 2007 at 07:52:18PM +0100, Claus Reinke wrote:
> since you're still bypassing windows head buildbot, here are
> errors, warnings, and test failures in today's build (win/xp,
> cygwin shell, mingw gcc).
Thanks for the info!
> i hope you are rec
since you're still bypassing windows head buildbot, here are
errors, warnings, and test failures in today's build (win/xp,
cygwin shell, mingw gcc). i hope you are recording these
as todo items somewhere? or should there be a tracker
for head build issu
52 matches
Mail list logo
