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

2011-02-20 Thread Ben Lippmeier
On 18/02/2011, at 9:41 PM, Roman Leshchinskiy wrote: > 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

pgj-freebsd-amd64-stable (amd64 FreeBSD STABLE), build 159, Success

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

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

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

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

2011-02-20 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 Sun Feb 20 18:10:01 GMT 2011. checking out new source tree

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

2011-02-20 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 Sun Feb 20 18:00:01 GMT 2011. checking out new source tree

Re: DPH build breakage

2011-02-20 Thread Manuel M T Chakravarty
Fixed by Mon Feb 21 13:20:24 EST 2011 Manuel M T Chakravarty * Add a missing dependency (implicit in the vectoriser) The missing dependency only seemed to matter depending on the number of cores used for building. That's why validate didn't catch it. Manuel Ben Lippmeier: > limitingfact

pgj2 (amd64 FreeBSD HEAD), build 277, Failure

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

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

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

tn23 (x86 OSX HEAD), build 263, Failure

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

pgj (x86 FreeBSD HEAD), build 279, Failure

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

DPH build breakage

2011-02-20 Thread Ben Lippmeier
limitingfactor:ghc-head benl$ "inplace/bin/ghc-stage2" -H32m -O -package-name dph-seq-0.5 -hide-all-packages -i -ilibraries/dph/dph-seq/../dph-common -ilibraries/dph/dph-seq/dist-install/build -ilibraries/dph/dph-seq/dist-install/build/autogen -Ilibraries/dph/dph-seq/dist-install/build

simonmar-win32-head (x86 Windows HEAD), build 240, Failure

2011-02-20 Thread Builder
simonmar-win32-head (x86 Windows HEAD), build 240 Build failed Details: http://darcs.haskell.org/ghcBuilder/builders/simonmar-win32-head/240.html darcs checkout | Success create mk/build.mk | Success get subrepos | Success repo versions| Success setting version date | Suc

mbolingbroke (x86 OSX HEAD), build 68, Failure

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

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

2011-02-20 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 Sun Feb 20 18:10:01 GMT 2011. checking out new s

kgardas-opensolaris-x86-head (x86 Solaris HEAD), build 137, Success

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

Re: Compacting GC interacting with new codegen strangely

2011-02-20 Thread Edward Z. Yang
Thanks for your reply! Excerpts from Ben Lippmeier's message of Sun Feb 20 18:57:30 -0500 2011: > As you suggest, it may well be a bug in the runtime system or libraries due > to not untagging pointers. I have fixed a few of these myself. The > hard-and-fast rule is that all pointers from the heap

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

2011-02-20 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 Sun Feb 20 18:00:02 GMT 2011. checking out new source

Re: Compacting GC interacting with new codegen strangely

2011-02-20 Thread Ben Lippmeier
On 20/02/2011, at 11:57 AM, Edward Z. Yang wrote: > > If I: > >- Turn off compacting GC >- Reduce the size of master-data >- Turn off optimizations >- Use the old codegen >- Put all of the code in one file >- Remove the seqs from 'sort' (which isn't actually a sort) >

patch applied (testsuite): Error msg wibbles due to VECTORISE patch

2011-02-20 Thread Manuel Chakravarty
Sun Feb 20 04:34:10 PST 2011 Manuel M T Chakravarty * Error msg wibbles due to VECTORISE patch M ./tests/ghc-regress/annotations/should_fail/annfail10.stderr -2 +2 M ./tests/ghc-regress/indexed-types/should_compile/T3017.stderr -1 +1 M ./tests/ghc-regress/indexed-types/should_fail/

patch applied (ghc): Added a VECTORISE pragma

2011-02-20 Thread Manuel Chakravarty
Sun Feb 20 02:50:32 PST 2011 Manuel M T Chakravarty * Added a VECTORISE pragma - Added a pragma {-# VECTORISE var = exp #-} that prevents the vectoriser from vectorising the definition of 'var'. Instead it uses the binding '$v_var = exp' to vectorise 'var'. The vectoriser checks