Hi all,
I'm having some problem understanding these two GHC primitives.
Is the result of dataToTag unique globally, or just per data type? Is
there any assumption on the range or order?
For tagToEnum, does the following isomorphism hold?
iso :: Enum a => a -> a
iso = tagToEnum . dataToTag
Any
pgj-freebsd-amd64-stable (amd64 FreeBSD STABLE), build 371
Build succeeded
Details:
http://darcs.haskell.org/ghcBuilder/builders/pgj-freebsd-amd64-stable/371.html
git clone| Success
create mk/build.mk | Success
get subrepos | Success
repo versions| Success
setting v
pgj-freebsd-i386-stable (x86 FreeBSD STABLE), build 354
Build succeeded
Details:
http://darcs.haskell.org/ghcBuilder/builders/pgj-freebsd-i386-stable/354.html
git clone| Success
create mk/build.mk | Success
get subrepos | Success
repo versions| Success
setting versi
pgj2 (amd64 FreeBSD HEAD), build 489
Build succeeded
Details: http://darcs.haskell.org/ghcBuilder/builders/pgj2/489.html
git clone| Success
create mk/build.mk | Success
get subrepos | Success
repo versions| Success
setting version date | Success
booting
pgj (x86 FreeBSD HEAD), build 491
Build succeeded
Details: http://darcs.haskell.org/ghcBuilder/builders/pgj/491.html
git clone| Success
create mk/build.mk | Success
get subrepos | Success
repo versions| Success
setting version date | Success
booting | Su
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 Mon Oct 3 18:00:01 BST 2011.
checking out new source t
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 Mon Oct 3 18:10:01 BST 2011.
checking out new so
tn23 (x86 OSX HEAD), build 446
Build failed
Details: http://darcs.haskell.org/ghcBuilder/builders/tn23/446.html
git clone | Failure: Just (ExitFailure 128)
Build failed
Details: http://darcs.haskell.org/ghcBuilder/builders/tn23/446.html
Cloning into build...
dyld: Library not loaded: /opt/local
Repository : ssh://darcs.haskell.org//srv/darcs/haddock
On branches: development,ghc-7.2
http://hackage.haskell.org/trac/ghc/changeset/8301dd47670a2377474d96ce55ce977b3a8d7c03
>---
commit 8301dd47670a2377474d96ce55ce977b3a8d7c03
Author
Repository : ssh://darcs.haskell.org//srv/darcs/haddock
On branches: development,ghc-7.2
http://hackage.haskell.org/trac/ghc/changeset/2b948f6297befc463493f78fdfdd995b2cbabe10
>---
commit 2b948f6297befc463493f78fdfdd995b2cbabe10
Author
Repository : ssh://darcs.haskell.org//srv/darcs/haddock
On branches: development,ghc-7.2
http://hackage.haskell.org/trac/ghc/changeset/754413bb131a8cf4bda3b9bd959d44d2b347c1cc
>---
commit 754413bb131a8cf4bda3b9bd959d44d2b347c1cc
Author
Repository : ssh://darcs.haskell.org//srv/darcs/haddock
On branches: development,ghc-7.2
http://hackage.haskell.org/trac/ghc/changeset/9331d3a35c2d370a974dced5515d2e4357ec0d6f
>---
commit 9331d3a35c2d370a974dced5515d2e4357ec0d6f
Author
On Sat, 2011-09-17 at 16:51 -0700, Mark Lentczner wrote:
> In preparation for building the Haskell Platform 2011.3.0.0 installer for
> Mac OS X, I've run into a snag: The GHC central distributed version of 7.0.4
> can't produce running executables. The problem comes at final link time,
> which fail
Hello GHC developers,
if you're making changes to Haddock that are not directly related to
GHC HEAD development, then please commit them on the "development"
branch, or if it's a bug fix, on the "ghc-7.2" branch.
Thanks!
A message from the Haddock maintainer
simonmar-win32-head (x86 Windows HEAD), build 402
Build failed
Details:
http://darcs.haskell.org/ghcBuilder/builders/simonmar-win32-head/402.html
git clone | Success
create mk/build.mk | Success
get subrepos | Failure: Just (ExitFailure 2)
Build failed
Details:
http://darcs.hask
Repository : ssh://darcs.haskell.org//srv/darcs/ghc
On branch : fix#5464
http://hackage.haskell.org/trac/ghc/changeset/3a9fddde75b60603f36190f365791cfde752c06e
>---
commit 3a9fddde75b60603f36190f365791cfde752c06e
Author: Simon Peyton
Repository : ssh://darcs.haskell.org//srv/darcs/ghc
On branch : master
http://hackage.haskell.org/trac/ghc/changeset/b926bd65c66ed4018101531eacf5bb7c3068c624
>---
commit b926bd65c66ed4018101531eacf5bb7c3068c624
Author: Ian Lynagh
Dat
Repository : ssh://darcs.haskell.org//srv/darcs/ghc
On branch : master
http://hackage.haskell.org/trac/ghc/changeset/aff9d6908525567cdeca09c7ef40bee34459cd31
>---
commit aff9d6908525567cdeca09c7ef40bee34459cd31
Author: Ian Lynagh
Dat
Repository : ssh://darcs.haskell.org//srv/darcs/ghc
On branch : master
http://hackage.haskell.org/trac/ghc/changeset/25f8f25a494f765d644a7dd1ead5c0a5058b8c36
>---
commit 25f8f25a494f765d644a7dd1ead5c0a5058b8c36
Author: Ian Lynagh
Dat
Repository : ssh://darcs.haskell.org//srv/darcs/ghc
On branch : master
http://hackage.haskell.org/trac/ghc/changeset/1f56b6cc076968d7d20bd960332443875d445153
>---
commit 1f56b6cc076968d7d20bd960332443875d445153
Author: Ian Lynagh
Dat
simonmar-win32-head (x86 Windows HEAD), build 401
Build succeeded
Details:
http://darcs.haskell.org/ghcBuilder/builders/simonmar-win32-head/401.html
git clone| Success
create mk/build.mk | Success
get subrepos | Success
repo versions| Success
setting version date |
simonmar-win32-stable (x86 Windows STABLE), build 334
Build succeeded
Details:
http://darcs.haskell.org/ghcBuilder/builders/simonmar-win32-stable/334.html
git clone| Success
create mk/build.mk | Success
get subrepos | Success
repo versions| Success
setting version d
New patches in /srv/darcs/git-mirrors/Win32
___
Cvs-ghc mailing list
Cvs-ghc@haskell.org
http://www.haskell.org/mailman/listinfo/cvs-ghc
On 30/09/2011 09:54, Max Bolingbroke wrote:
Hi GHCers,
As those of you who use the LLVM backend know, it often doesn't
optimise as aggressively as you would like. The reason for this is
often to do with aliasing. I've written a blog post outlining the
problem and a solution, in the form of a GHC
On 3 October 2011 09:49, austin seipp wrote:
> The machine is a Core i5, running Linux (2.6.38.) I haven't tested any
> of this with Max's analysis plugin because it seems to trip a bug in
> my linux build of LLVM. I'll update to a more recent LLVM revision and
> try it on my Mac OS X box, LLVM tr
I tried this with a recent checkout, by running:
$ make TESTS="plugins02"
in ./testsuite/tests, and it failed with a similar error, but with
another checkout of the testsuite repository, I can't seem to
reproduce this failure at all anymore after several attempts.
This is an Ubuntu Linux machine
I tested the greedy and PBQP register allocators with a recent GHC
HEAD (today) build and LLVM v3.0svn (revision 139459.) With nofib they
actually both give worse results than linear scan it seems.
Results of GHC's regular NCG vs LLVM:
NoFib Results
-
27 matches
Mail list logo
