pgj-freebsd-i386-stable (x86 FreeBSD STABLE), build 140, Success

2011-02-18 Thread Builder
pgj-freebsd-i386-stable (x86 FreeBSD STABLE), build 140 Build succeeded Details: http://darcs.haskell.org/ghcBuilder/builders/pgj-freebsd-i386-stable/140.html darcs checkout| Success create mk/build.mk| Success get subrepos | Success repo versions | S

Recent HEAD breakage in libraries/base/Data/Maybe.hs:67:7

2011-02-18 Thread Karel Gardas
Hello, yesterday night build of HEAD fails with: libraries/base/Data/Maybe.hs:67:7: Can't find interface-file declaration for data constructor GHC.Generics.Inl Probable cause: bug in .hi-boot file, or inconsistent .hi file Use -ddump-if-trace to get an idea of which file caused the error In the

[nightly] 18-Feb-2011 build of HEAD on i386-unknown-linux (cam-02-unx)

2011-02-18 Thread GHC Build Reports
Build description = HEAD on i386-unknown-linux (cam-02-unx) Build location= /playpen/simonmar/nightly/HEAD Build config file = /home/simonmar/nightly/site/msrc/conf-HEAD-cam-02-unx Nightly build started on cam-02-unx at Fri Feb 18 18:00:01 GMT 2011. checking out new source tree

[nightly] 18-Feb-2011 build of STABLE on i386-unknown-linux (cam-02-unx)

2011-02-18 Thread GHC Build Reports
Build description = STABLE on i386-unknown-linux (cam-02-unx) Build location= /playpen/simonmar/nightly/STABLE Build config file = /home/simonmar/nightly/site/msrc/conf-STABLE-cam-02-unx Nightly build started on cam-02-unx at Fri Feb 18 18:10:01 GMT 2011. checking out new source tree

simonmar-win32-head (x86 Windows HEAD), build 238, Success

2011-02-18 Thread Builder
simonmar-win32-head (x86 Windows HEAD), build 238 Build succeeded Details: http://darcs.haskell.org/ghcBuilder/builders/simonmar-win32-head/238.html darcs checkout| Success create mk/build.mk| Success get subrepos | Success repo versions | Success set

simonmar-win32-stable (x86 Windows STABLE), build 173, Success

2011-02-18 Thread Builder
simonmar-win32-stable (x86 Windows STABLE), build 173 Build succeeded Details: http://darcs.haskell.org/ghcBuilder/builders/simonmar-win32-stable/173.html darcs checkout| Success create mk/build.mk| Success get subrepos | Success repo versions | Succe

pgj2 (amd64 FreeBSD HEAD), build 275, Failure

2011-02-18 Thread Builder
pgj2 (amd64 FreeBSD HEAD), build 275 Build failed Details: http://darcs.haskell.org/ghcBuilder/builders/pgj2/275.html darcs checkout | Success create mk/build.mk | Success get subrepos | Success repo versions| Success setting version date | Success booting | S

[nightly] 18-Feb-2011 build of HEAD on x86_64-unknown-linux (cam-04-unx)

2011-02-18 Thread GHC Build Reports
Build description = HEAD on x86_64-unknown-linux (cam-04-unx) Build location= /64playpen/simonmar/nightly/HEAD-cam-04-unx Build config file = /home/simonmar/nightly/site/msrc/conf-HEAD-cam-04-unx Nightly build started on cam-04-unx at Fri Feb 18 18:00:01 GMT 2011. checking out new source

pgj (x86 FreeBSD HEAD), build 277, Failure

2011-02-18 Thread Builder
pgj (x86 FreeBSD HEAD), build 277 Build failed Details: http://darcs.haskell.org/ghcBuilder/builders/pgj/277.html darcs checkout | Success create mk/build.mk | Success get subrepos | Success repo versions| Success setting version date | Success booting | Succe

[nightly] 18-Feb-2011 build of STABLE on x86_64-unknown-linux (cam-04-unx)

2011-02-18 Thread GHC Build Reports
Build description = STABLE on x86_64-unknown-linux (cam-04-unx) Build location= /64playpen/simonmar/nightly/STABLE-cam-04-unx Build config file = /home/simonmar/nightly/site/msrc/conf-STABLE-cam-04-unx Nightly build started on cam-04-unx at Fri Feb 18 18:10:01 GMT 2011. checking out new s

tn23 (x86 OSX HEAD), build 261, Failure

2011-02-18 Thread Builder
tn23 (x86 OSX HEAD), build 261 Build failed Details: http://darcs.haskell.org/ghcBuilder/builders/tn23/261.html darcs checkout | Success create mk/build.mk | Success get subrepos | Success repo versions| Success setting version date | Success booting | Success

how frowned-upon is "recursive coreView"?

2011-02-18 Thread Adam Megacz
The function at the end of this email walks over a Type, basically (recursivey) replacing it with its coreView. The resulting tree has no PredTy's except for (PredTy (EqPred _ _)). How problematic is it for a core-to-core translation to replace all the Type's in an Expr with their coreView-ifica

mbolingbroke (x86 OSX HEAD), build 67, Failure

2011-02-18 Thread Builder
mbolingbroke (x86 OSX HEAD), build 67 Build failed Details: http://darcs.haskell.org/ghcBuilder/builders/mbolingbroke/67.html darcs checkout | Success create mk/build.mk | Success get subrepos | Success repo versions| Success setting version date | Success booting

kgardas-opensolaris-x86-head (x86 Solaris HEAD), build 135, Failure

2011-02-18 Thread Builder
kgardas-opensolaris-x86-head (x86 Solaris HEAD), build 135 Build failed Details: http://darcs.haskell.org/ghcBuilder/builders/kgardas-opensolaris-x86-head/135.html darcs checkout | Success create mk/build.mk | Success get subrepos | Success repo versions| Success setting

Re: semantics of Eq instance for Var.Var

2011-02-18 Thread Adam Megacz
Roman Leshchinskiy writes: > Two Vars are Eq-equal iff they could shadow each other. Simon Peyton-Jones writes: > Two Vars are considered equal if their Names are the same. Max Bolingbroke writes: > If you weren't using Uniques, presumably your variables would be > compared just by their OccN

patch applied (ghc-7.0/testsuite): Test Trac #4966

2011-02-18 Thread Ian Lynagh
Thu Feb 17 05:32:17 PST 2011 simo...@microsoft.com * Test Trac #4966 A ./tests/ghc-regress/deriving/should_compile/T4966.hs M ./tests/ghc-regress/deriving/should_compile/all.T +1 View patch online: http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=ghc-7.0/testsuite;a=darcs_commitdiff;h=2

patch applied (ghc-7.0/testsuite): Follow error message wibbles

2011-02-18 Thread Ian Lynagh
Thu Feb 17 06:10:42 PST 2011 simo...@microsoft.com * Follow error message wibbles M ./tests/ghc-regress/deriving/should_fail/T3621.stderr -6 +10 M ./tests/ghc-regress/indexed-types/should_compile/Gentle.stderr -11 M ./tests/ghc-regress/indexed-types/should_compile/all.T -1 +1 M

patch applied (ghc-7.0/ghc): Use "on the spot" solving for fundeps

2011-02-18 Thread Ian Lynagh
Thu Feb 17 06:09:21 PST 2011 simo...@microsoft.com * Use "on the spot" solving for fundeps When we spot an equality arising from a functional dependency, we now use that equality (a "wanted") to rewrite the work-item constraint right away. This avoids two dangers Danger 1: If we

patch applied (ghc-7.0/ghc): Fix Trac #4966

2011-02-18 Thread Ian Lynagh
Thu Feb 17 06:10:00 PST 2011 simo...@microsoft.com * Fix Trac #4966 This is just a program that exploits overlapping instances in a delicate way. The fix makes GHC a bit more friendly towards such programs. See Note [Overlap and deriving] in TcSimplify M ./compiler/typecheck/

patch applied (ghc-7.0/ghc): makeSolvedByInst is only called on wanteds

2011-02-18 Thread Ian Lynagh
Fri Feb 11 09:34:15 PST 2011 simo...@microsoft.com * makeSolvedByInst is only called on wanteds This patch just adds an assert error. M ./compiler/typecheck/TcSMonad.lhs -2 +4 View patch online: http://darcs.haskell.org/cgi-bin/darcsweb.cgi?r=ghc-7.0/ghc;a=darcs_commitdiff;h=201102111

Re: Redundancy elimination, and how to prevent bindings from being floated.

2011-02-18 Thread Roman Leshchinskiy
Ben Lippmeier wrote: > > Another idea would be to add some primops like the following: > > > noopInt# :: Int# -> State# s -> State# s > noopFloat# :: Float# -> State# s -> State# s > ... Have a look at GHC.Prim.touch#. Note that it's special and can be instantiated with unboxed types, too. Ro

Redundancy elimination, and how to prevent bindings from being floated.

2011-02-18 Thread Ben Lippmeier
Continuing the previous discussion... The "CSE modulo equality on integers" optimisation is actually called "Value Based Partial Redundancy Elimination". There's a long line of prior work, and a recentish paper by Thomas VanDrunen and Antony Hoskin at CC 2004. The algorithm was implemented as

Re: FW: darcs patch: New codegen: GC calling convention must use registers.

2011-02-18 Thread Edward Z. Yang
Hello, It's for the new codegen only (it touches CmmCallConv, whereas the old codegen bypasses the issue entirely by piggy-backing off the return convention for functions.) Cheers, Edward Excerpts from Simon Peyton-Jones's message of Fri Feb 18 03:29:53 -0500 2011: > Edward > > Does this patch

[nightly] DPH Performance Test Succeeded

2011-02-18 Thread DPH Buildbot
Full logs at http://log.ouroborus.net/limitingfactor/dph Environment Platform host: limitingfactor.cse.unsw.EDU.AU arch: i386 processor: i386 system:Darwin 10.6.0 Versions GHC The Glorious Glasgow Haskell Compilation System, version 7.1.20110217 GCC i686-a

Validate failures (HEAD, OS X 10.6)

2011-02-18 Thread Max Bolingbroke
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

mbolingbroke (x86 OSX HEAD), build 66, Success

2011-02-18 Thread Builder
mbolingbroke (x86 OSX HEAD), build 66 Build succeeded Details: http://darcs.haskell.org/ghcBuilder/builders/mbolingbroke/66.html darcs checkout| Success create mk/build.mk| Success get subrepos | Success repo versions | Success setting version date