On Wed, Oct 31, 2012 at 04:22:03PM +, Simon Peyton-Jones wrote:
> I think that's all mine. arrowfail001 fails with stage=1 (with an ASSERT
> error, and it *is* wrong)
I think it'll only fail with a DEBUG compiler. I've updated the test
accordingly.
Thanks
Ian
arlow; GHC CVS list
| Subject: RE: Validate failures of the day
|
| I fixed 5691, 7264, 5130
|
| Simon
|
| | -Original Message-
| | From: cvs-ghc-boun...@haskell.org [mailto:cvs-ghc-boun...@haskell.org]
| | On Behalf Of Simon Marlow
| | Sent: 31 October 2012 12:37
| | To: GHC CVS list
| | Su
I fixed 5691, 7264, 5130
Simon
| -Original Message-
| From: cvs-ghc-boun...@haskell.org [mailto:cvs-ghc-boun...@haskell.org]
| On Behalf Of Simon Marlow
| Sent: 31 October 2012 12:37
| To: GHC CVS list
| Subject: Validate failures of the day
|
| Here's a selection of today'
Here's a selection of today's validate failures on x86_64/Linux for your
enjoyment.
1 unexpected passes
13 unexpected failures
And that's on our best supported platform. Now, one of those is due to
local changes in my tree, and another 4 are due to a linking issue
On Montag, 22. Oktober 2012, 12:03:24, Ben Lippmeier wrote:
>
> I went to find out what got broken and I'm getting a validate failure
> somewhere else:
>
> compiler/stage1/build/Parser.hs:38:27:
> Module `StaticFlags' does not export `opt_Hpc'
> make[1]: *** [compiler/stage1/build/Parser.o]
On 19/10/2012, at 2:17 AM, Simon Peyton-Jones wrote:
> I’m getting these failures in DPH when validating on Windows (32-bit)
>
>dph/nbody dph-nbody-copy-fast [exit code non-0]
> (normal)
>dph/nbody dph-nbody-vseg-fast [exit code non-0]
> (normal
I'm getting these failures in DPH when validating on Windows (32-bit)
dph/nbody dph-nbody-copy-fast [exit code non-0] (normal)
dph/nbody dph-nbody-vseg-fast [exit code non-0] (normal)
It's a type error as below. Can anyone (Manuel, Ben?) say what's w
On Mon, Jun 04, 2012 at 12:34:38PM +0100, Simon Marlow wrote:
>
> => setByteArray(normal) 1494 of 3344 [0, 0, 0]
>
> : can't find file: setByteArray.hs
Sorry, fixed.
Thanks
Ian
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org
-boun...@haskell.org]
| On Behalf Of Simon Marlow
| Sent: 04 June 2012 12:35
| To: GHC CVS list
| Subject: validate failures
|
| Today's validate has 3 failures. One is a "stat too good", so I'll
| commit a fix. Could whoever is responsible please fix the other two:
|
| =&g
Today's validate has 3 failures. One is a "stat too good", so I'll
commit a fix. Could whoever is responsible please fix the other two:
=> setByteArray(normal) 1494 of 3344 [0, 0, 0]
cd ./codeGen/should_run &&
'/5playpen/simonmar/ghc-validate/bindisttest/install dir/bin/ghc'
-fforce-re
On 01/03/2012 02:26, Ian Lynagh wrote:
On Wed, Feb 29, 2012 at 10:31:31AM +, Simon Marlow wrote:
On 28/02/2012 13:07, Ian Lynagh wrote:
On Tue, Feb 28, 2012 at 10:44:35AM +, Simon Marlow wrote:
On 28/02/2012 09:03, Simon Marlow wrote:
The safeHaskell failures disappeared on my second
On Wed, Feb 29, 2012 at 10:31:31AM +, Simon Marlow wrote:
> On 28/02/2012 13:07, Ian Lynagh wrote:
> >On Tue, Feb 28, 2012 at 10:44:35AM +, Simon Marlow wrote:
> >>On 28/02/2012 09:03, Simon Marlow wrote:
> >>>The safeHaskell failures disappeared on my second validate run, so I'm
> >>>not s
On 28/02/2012 13:07, Ian Lynagh wrote:
On Tue, Feb 28, 2012 at 10:44:35AM +, Simon Marlow wrote:
On 28/02/2012 09:03, Simon Marlow wrote:
The safeHaskell failures disappeared on my second validate run, so I'm
not sure what happened (I had pulled into the tree first, and there were
no patche
On Tue, Feb 28, 2012 at 10:44:35AM +, Simon Marlow wrote:
> On 28/02/2012 09:03, Simon Marlow wrote:
> >The safeHaskell failures disappeared on my second validate run, so I'm
> >not sure what happened (I had pulled into the tree first, and there were
> >no patches between the two runs that shou
On 28/02/2012 09:03, Simon Marlow wrote:
The safeHaskell failures disappeared on my second validate run, so I'm
not sure what happened (I had pulled into the tree first, and there were
no patches between the two runs that should have affected this). Perhaps
there's some missing cleaning somewhere
..@haskell.org [mailto:cvs-ghc-boun...@haskell.org] On
| Behalf Of Simon Marlow
| Sent: 28 February 2012 09:04
| To: David Terei
| Cc: GHC CVS list
| Subject: Re: Validate failures
|
| The safeHaskell failures disappeared on my second validate run, so I'm
| not sure what happened (I had pulled
The safeHaskell failures disappeared on my second validate run, so I'm
not sure what happened (I had pulled into the tree first, and there were
no patches between the two runs that should have affected this).
Perhaps there's some missing cleaning somewhere? Anyway I wouldn't
worry about it unl
Is this still happening and on what platforms? I don't get the
safeHaskell failures on X64 Linux
Cheers,
David
On 27 February 2012 06:09, Simon Marlow wrote:
> Validate is slipping again folks. Can those responsible please clean up the
> failures? These make it hard for someone else to fig
Validate is slipping again folks. Can those responsible please clean up
the failures? These make it hard for someone else to figure out whether
they can commit or not.
Unexpected failures:
ghci/scripts Defer02 [bad stderr] (ghci)
indexed-types/should_fail T3330c [stderr m
There may be more, but now I'm not sure which are my failures and which
are breakage in the repo :-(
Trying another pull and validate.
=> T5625(optasm) 24 of 82 [0, 1, 0]
cd ./should_run && '/64playpen/simonmar/validate/inplace/bin/ghc-stage2'
-fforce-recomp -dcore-lint -dcmm-lint -dno-deb
On Friday 11 November 2011, 13:49:21, Simon Marlow wrote:
> I have the following validate failures on x86_64/Linux today:
>
> Unexpected failures:
> perf/compiler T3064 [stat not good enough] (normal)
> typecheck/should_compile tc167 [stderr mi
I have the following validate failures on x86_64/Linux today:
Unexpected failures:
perf/compiler T3064 [stat not good enough] (normal)
typecheck/should_compile tc167 [stderr mismatch] (normal)
bytes allocated 151026120 is more than maximum allowed 15000
*** unexpected
On Tue, Nov 08, 2011 at 04:31:29PM +, Simon Peyton-Jones wrote:
> NEW: Ian can you diagnose
>rts T5423 [bad exit code] (normal)
I forgot to add a file; now fixed.
Thanks
Ian
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
ht
On 8 November 2011 08:31, Simon Peyton-Jones wrote:
> NEW: Ian can you diagnose
>
> rts T5423 [bad exit code] (normal)
>
>
>
> Manuel
>
> dph/diophantine dph-diophantine-fast [exit code non-0] (normal)
>
>
>
> David (thanks for saying you’ll deal with these by W
NEW: Ian can you diagnose
rts T5423 [bad exit code] (normal)
Manuel
dph/diophantine dph-diophantine-fast [exit code non-0] (normal)
David (thanks for saying you'll deal with these by Wednesday)
ffi/should_fail ccfail001 [stderr mismatch] (normal)
ugust 2011 09:50
| To: GHC CVS list
| Subject: Validate failures
|
| A validate last night failed on:
|
| Unexpected failures:
| haddock/haddock_examples haddock.Test [stderr mismatch] (normal)
| thT1835 [exit code non-0] (normal)
|
| These also failed i
A validate last night failed on:
Unexpected failures:
haddock/haddock_examples haddock.Test [stderr mismatch] (normal)
thT1835 [exit code non-0] (normal)
These also failed in the nightly build.
Come on folks, we need to keep validate clean on at least one platform
The T* failures are all memory allocation failures on the part of
GHC, probably because Hoopl generates a lot more garbage than the
old code generator.
The space leak one is really interesting, because it doesn't show up
when I do normal tests with a devel2 built stage2. Maybe I fixed it
with my o
On 07/04/2011 17:07, Edward Z. Yang wrote:
Amazingly enough, a GHC fully built with the new code generator
and with it set to default only fails five tests on validate:
OVERALL SUMMARY for test run started at Thu Apr 7 11:53:31 EDT 2011
2712 total tests, which gave rise to
9094 test c
Well done!
| -Original Message-
| From: cvs-ghc-boun...@haskell.org [mailto:cvs-ghc-boun...@haskell.org] On
| Behalf Of Edward Z. Yang
| Sent: 07 April 2011 17:07
| To: cvs-ghc
| Subject: Validate failures on the new codegen
|
| Amazingly enough, a GHC fully built with the new code
Amazingly enough, a GHC fully built with the new code generator
and with it set to default only fails five tests on validate:
OVERALL SUMMARY for test run started at Thu Apr 7 11:53:31 EDT 2011
2712 total tests, which gave rise to
9094 test cases, of which
0 caused framework failur
On Wed, Apr 06, 2011 at 11:26:15AM +0100, Simon Marlow wrote:
>
> - why did we not get an email sent to cvs-ghc for this patch?
>(there have been lots of missing emails from various people)
I've now added him to /etc/email-addresses on abbot, so future commits
from him should get through.
W
I've reverted the patch.
Excerpts from Simon Marlow's message of Wed Apr 06 06:26:15 -0400 2011:
> Questions:
>
> - did you validate Edward?
No. I thought it would be a safe patch because it only affected debugging,
and had the validate running over the evening. My apologies.
> - why did we
I have multiple validate failures:
Unexpected failures:
T3017(normal)
T3319(normal)
T3600(normal)
T3899(normal)
T4436(normal)
TH_foreignInterruptible(normal)
TH_genEx(normal)
TH_pragma(normal)
tc168(normal)
tc231(normal)
They are all due to this patch:
commit
I did a validate on x86-64/Linux just now, and saw these failures:
Unexpected failures:
dph-diophantine-fast(normal)
dph-primespj-fast(normal)
dph-quickhull-fast(normal)
dph-words-fast(normal)
=> dph-quickhull-fast(normal) 1096 of 2731 [0, 0, 0]
cd ./dph/quickhull && '/64playpen/
Hello,
On Mon, Feb 28, 2011 at 04:52:11PM +, Simon Marlow wrote:
> On 18/02/2011 08:31, Max Bolingbroke wrote:
> > ...
> >Unexpected failures:
> >1288(normal)
> >2276(normal)
> >2276_ghci(ghci)
>
> These three are probably related to #3336. I'm guessing OS X doesn't
> support st
On 18/02/2011 08:31, Max Bolingbroke wrote:
Hi,
I recently validated GHC HEAD again after a long break, and found to
my dismay that I'm getting a lot of unexpected failures:
"""
Unexpected failures:
1288(normal)
2276(normal)
2276_ghci(ghci)
These three are probably related to #333
On Fri, Feb 18, 2011 at 08:31:04AM +, Max Bolingbroke wrote:
>
> I recently validated GHC HEAD again after a long break, and found to
> my dismay that I'm getting a lot of unexpected failures:
>
> """
> Unexpected failures:
>1288(normal)
>2276(normal)
>2276_ghci(ghci)
>4850(no
Hi,
I recently validated GHC HEAD again after a long break, and found to
my dismay that I'm getting a lot of unexpected failures:
"""
Unexpected failures:
1288(normal)
2276(normal)
2276_ghci(ghci)
4850(normal)
T4113(normal)
T4801(normal)
"""
Is this known/expected behaviour?
T
Should be fixed now.
Roman
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
This is due to SimonPJ's recursive superclass patch (and the resulting changes
in the layout of dfuns). Roman is currently adapting the vectoriser to use the
new layout.
Manuel
Simon Marlow:
> I'm getting -dcore-lint errors in the dph tests in my validate build. Does
> anyone know anything ab
On 15/12/2010 14:59, Ian Lynagh wrote:
On Wed, Dec 15, 2010 at 02:35:01PM +, Simon Marlow wrote:
I'm getting -dcore-lint errors in the dph tests in my validate build.
Does anyone know anything about this?
http://www.haskell.org/pipermail/cvs-ghc/2010-December/058267.html
Ah, I missed tha
On Wed, Dec 15, 2010 at 02:35:01PM +, Simon Marlow wrote:
> I'm getting -dcore-lint errors in the dph tests in my validate build.
> Does anyone know anything about this?
http://www.haskell.org/pipermail/cvs-ghc/2010-December/058267.html
Thanks
Ian
I'm getting -dcore-lint errors in the dph tests in my validate build.
Does anyone know anything about this?
=> dph-quickhull-fast(normal) 1075 of 2688 [0, 1, 0]
cd ./dph/quickhull && '/64playpen/simonmar/validate/bindisttest/install
dir/bin/ghc' -fforce-recomp -dcore-lint -dcmm-lint -dno-de
file-descriptor-isatty-is-bogus
Excerpts from Edward Z. Yang's message of Sat Sep 04 14:19:44 -0400 2010:
> Hello all,
>
> I'm getting the following validate failures on a fresh checkout
> of Darcs HEAD run on Windows 7:
>
> OVERALL SUMMARY for test run started at The c
At least a few of these (2636 and most of the ghc-e* ones) are
due to the fact that we can't seem to get echo from Hello all,
>
> I'm getting the following validate failures on a fresh checkout
> of Darcs HEAD run on Windows 7:
>
> OVERALL SUMMARY for test run start
Hello all,
I'm getting the following validate failures on a fresh checkout
of Darcs HEAD run on Windows 7:
OVERALL SUMMARY for test run started at The current date is: Sat 09/04/2010
Enter the new date: (mm-dd-yy)
2540 total tests, which gave rise to
10708 test cases, of which
Validating on my Mac produces 150 failures. The problem is this:
+ghc: RTS options are disabled. Link with -rtsopts to enable them.
This is with up-to-date (as of yesterday) repos and no custom validate.mk.
Roman
___
Cvs-ghc mailing list
Cvs-ghc@hask
On 24/11/2009 03:19, Manuel M T Chakravarty wrote:
There are again more validate failures on Mac OS X (Leopard) today:
Unexpected failures:
T1969(normal)
T3294(normal)
ffi005(normal)
ghci011(ghci)
rtsflags001(normal)
tcfail073(normal)
T1969 and T3294 are the old
There are again more validate failures on Mac OS X (Leopard) today:
> Unexpected failures:
>T1969(normal)
>T3294(normal)
>ffi005(normal)
>ghci011(ghci)
>rtsflags001(normal)
>tcfail073(normal)
T1969 and T3294 are the old (allocation) performance on
Wed Sep 9 02:32:17 PDT 2009 Simon Marlow
* Omit visibility pragmas on Windows (fixes warnings/validate failures)
Ignore-this: 14cd79e7cded8c0a353544d272f3b974
M ./includes/Rts.h +12
M ./rts/Capability.h -2 +2
M ./rts/FrontPanel.h -2 +2
M ./rts/GetTime.h -2 +2
M ./rts
On Thu, Jul 03, 2008 at 12:01:49PM +0100, Claus Reinke wrote:
>
> I assumed the buildbot issues were related to the move,
> and that buildsystem fixes would start when the buildbots
> were back. Are there any estimates as to when the buildbot
> situation will get back to normal
There were a coup
Running validate before pushing changes is becoming somewhat annoying
because I have to run it twice in two different repos (one with and one
without my changes) and then compare the results. Why do people push
without validating? I thought we agreed that this shouldn't happen?
Given that the
Unexpected failures:
ghci019(ghci)
mod44(normal)
num009(normal)
read014(normal)
tc115(normal)
tc116(normal)
tc125(normal)
tc126(normal)
tc161(normal)
tcfail023(normal)
tcfail035(normal)
tcfail036(normal)
tcfail073(normal)
tcfail096(normal)
tcfail121(nor
54 matches
Mail list logo
