RE: Which of the following PrimTyCons have a pointer-sized representations

Johan, Well, I started to review your patch. And then I re-discovered how horribly messy that code is; with independent decisions taken in the desugarer, MkId, and TcTyClsDcls, all of which must line up. So I totally refactored everything which cost me a couple of days (because it has quite w

Re: Which of the following PrimTyCons have a pointer-sized representations

On 11/12/12 12:29, Simon Peyton-Jones wrote: Johan, Well, I started to review your patch. And then I re-discovered how horribly messy that code is; with independent decisions taken in the desugarer, MkId, and TcTyClsDcls, all of which must line up. So I totally refactored everything which co

[commit: ghc] master: document special "this" syntax for PackageImports (#7409) (b0339aa)

Repository : ssh://darcs.haskell.org//srv/darcs/ghc On branch : master http://hackage.haskell.org/trac/ghc/changeset/b0339aa1e298c700c849813fbd16b29c92e27055 >--- commit b0339aa1e298c700c849813fbd16b29c92e27055 Author: Simon Marlow D

[commit: ghc] master: add enabled_capabilities (#7491) (d684114)

Repository : ssh://darcs.haskell.org//srv/darcs/ghc On branch : master http://hackage.haskell.org/trac/ghc/changeset/d68411496b1cad0e2e912875f32457372b5c2fcd >--- commit d68411496b1cad0e2e912875f32457372b5c2fcd Author: Simon Marlow D

Re: Mailing list reorganisation

On Tue, Dec 11, 2012 at 7:04 AM, Ian Lynagh wrote: > Does that sound reasonable? Does anyone have any further questions or > comments? Sound good to me. Thanks for working on this. -- Johan ___ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haske

Re: Which of the following PrimTyCons have a pointer-sized representations

Simon, On Tue, Dec 11, 2012 at 4:29 AM, Simon Peyton-Jones wrote: > So I totally refactored everything which cost me a couple of days (because it > has quite wide span). I'm validating now. Yay for code clean-ups! > So I changed it to "...AND the unboxed version is at most one field wide".

RE: Hoopl vs LLVM?

| In my opinion we should only implement optimizations in Hoopl that | LLVM cannot do due to lack high-level information that we might have | gotten rid of before we reach the LLVM code generator*. I don't think Indeed. And I think there is probably quite a lot that is in reach for C--, but o

[nightly] 11-Dec-2012 build of HEAD (unreg) on x86_64-unknown-linux (cam-04-unx)

Build description = HEAD (unreg) on x86_64-unknown-linux (cam-04-unx) Build location= /64playpen/simonmar/nightly/HEAD-unreg-cam-04-unx Build config file = /home/simonmar/nightly/site/msrc/conf-HEAD-unreg-cam-04-unx Nightly build started on cam-04-unx at Tue Dec 11 18:20:01 GMT 2012. chec

RE: Which of the following PrimTyCons have a pointer-sized representations

| >data T = MkT !S | >data S = MkS Int | > | > then my impl will unbox the S field of MkT because the result is only one field | wide, namely an Int. | | Wouldn't Johan's have unboxed S too? (if not, I misunderstood what he did) No, that would change the semantics! W

Re: Hoopl vs LLVM?

Cool info! Would love to see that report if you can dig it up :) -Carter On Tue, Dec 11, 2012 at 2:16 PM, Simon Peyton-Jones wrote: > | In my opinion we should only implement optimizations in Hoopl that > | LLVM cannot do due to lack high-level information that we might have > | gotten rid of

Re: Which of the following PrimTyCons have a pointer-sized representations

On Tue, Dec 11, 2012 at 1:02 PM, Simon Peyton-Jones wrote: > | >data T = MkT !S > | >data S = MkS Int > | > > | > then my impl will unbox the S field of MkT because the result is only > one field > | wide, namely an Int. > | > | Wouldn't Johan's have unboxed S too? (if not,

Re: Hoopl vs LLVM?

On Tue, Dec 11, 2012 at 11:16 AM, Simon Peyton-Jones wrote: > Notice that the stack is now *explicit* rather than implicit, and LLVM has no > hope of moving the assignment to z past the call to g (which is trivial in > the original). I can explain WHY we do this (there is stuff on the wiki) but

Re: [base] CLK_TCK issue for QNXNTO

Somebody claiming to be Stephen Paul Weber wrote: When I try to build base for QNXNTO (BlackBerry 10) using my cross-compiler I get an error about "test_array is not of static size" or similar. -#if defined(CLK_TCK) +#if defined(CLK_TCK) && !defined(__QNXNTO__) (#const CLK_TCK) #else u

Re: base not detecting Double/Float machine sizes (QNXNTO)

Somebody claiming to be Stephen Paul Weber wrote: When building base with my QNXNTO cross-compiling GHC, I get the following: libraries/base/Foreign/C/Types.hs:162:25: Not in scope: type constructor or class `HTYPE_FLOAT' Another question: if `base` cannet build without these constants, then

[PATCH] QNXNTO and cross-compiling patches

The attached patches are needed to cross-compile with GHC for QNXNTO (the BlackBerry 10 Operating System). They have been tested for the x86 and ARM targets both. One more patch to the LLVM driver will be required to get ARM to go with the LLVM in the Ubuntu repos, but otherwise this should be

Re: [PATCH] QNXNTO and cross-compiling patches

Somebody claiming to be Stephen Paul Weber wrote: The attached patches are needed to cross-compile with GHC for QNXNTO And I forgot to attach... Attached now. -- Stephen Paul Weber, @singpolyma See for how I prefer to be contacted edition right joseph >From aac2690dbe4

Re: [PATCH] [base] CLK_TCK issue for QNXNTO

Somebody claiming to be Stephen Paul Weber wrote: Somebody claiming to be Stephen Paul Weber wrote: When I try to build base for QNXNTO (BlackBerry 10) using my cross-compiler I get an error about "test_array is not of static size" or similar. Looking up CLK_TCK in the QNXNTO time.h: /* CLK_T

am-deb7-64 (HEAD), build 266, Success

am-deb7-64 (HEAD), build 266 Build succeeded Details: http://darcs.haskell.org/ghcBuilder/builders/am-deb7-64/266.html git clone| Success create mk/build.mk | Success get subrepos | Success repo versions| Success touching clean-check f

[nightly] 11-Dec-2012 build of STABLE on x86_64-unknown-linux (cam-04-unx)

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 Tue Dec 11 18:10:01 GMT 2012. checking out new s

Re: Mailing list reorganisation

Good plan! Ian Lynagh : > Hi all, > > Following a recent discussion, we propose to reorganise the GHC-related > mailing lists so that we end up with: > >glasgow-haskell-users >For user discussions > >ghc-devs >For developer discussions > >ghc-commits >For au

[commit: ghc] master: Merge branch 'master' of http://darcs.haskell.org/ghc (d7d25db)

Repository : ssh://darcs.haskell.org//srv/darcs/ghc On branch : master http://hackage.haskell.org/trac/ghc/changeset/d7d25db3e58f3edfb950ebfa466c1e1e06d175d6 >--- commit d7d25db3e58f3edfb950ebfa466c1e1e06d175d6 Merge: 609aecb... 1435e

[commit: ghc] master: Add replaceDynFlags to the ContainsDynFlags class (e5182b7)

Repository : ssh://darcs.haskell.org//srv/darcs/ghc On branch : master http://hackage.haskell.org/trac/ghc/changeset/e5182b7c8c7466a81de6d82d99e7d272b968691b >--- commit e5182b7c8c7466a81de6d82d99e7d272b968691b Author: Ian Lynagh Dat

[commit: ghc] master: Add a function to change DynFlags to be suitable for compiling for way=dynamic (0c4a9f3)

Repository : ssh://darcs.haskell.org//srv/darcs/ghc On branch : master http://hackage.haskell.org/trac/ghc/changeset/0c4a9f38637dfc3bc8fd48e8ba6bf64da51b727b >--- commit 0c4a9f38637dfc3bc8fd48e8ba6bf64da51b727b Author: Ian Lynagh Dat

[commit: ghc] master: Fix loading dynamic interfaces when using -dynamic-too (ecd9676)

Repository : ssh://darcs.haskell.org//srv/darcs/ghc On branch : master http://hackage.haskell.org/trac/ghc/changeset/ecd967612877e1965ddebefe9b83acd837bb413a >--- commit ecd967612877e1965ddebefe9b83acd837bb413a Author: Ian Lynagh Dat

[commit: ghc] master: Merge branch 'master' of http://darcs.haskell.org/ghc (cea7aa3)

Repository : ssh://darcs.haskell.org//srv/darcs/ghc On branch : master http://hackage.haskell.org/trac/ghc/changeset/cea7aa335b52c9fbb12fbfecc5a9ad69b240c3de >--- commit cea7aa335b52c9fbb12fbfecc5a9ad69b240c3de Merge: d7d25db... 713c5

[commit: ghc] master: Merge branch 'master' of http://darcs.haskell.org/ghc (497cb61)

Repository : ssh://darcs.haskell.org//srv/darcs/ghc On branch : master http://hackage.haskell.org/trac/ghc/changeset/497cb612ec598aa925fc33042ca0e49e59066af1 >--- commit 497cb612ec598aa925fc33042ca0e49e59066af1 Merge: ecd9676... d6841

[commit: ghc] master: Tweak how 'count' is handled in the nativeCodeGen (8246c7a)

Repository : ssh://darcs.haskell.org//srv/darcs/ghc On branch : master http://hackage.haskell.org/trac/ghc/changeset/8246c7a4aff8ac763dafc6bdd63f647accafab06 >--- commit 8246c7a4aff8ac763dafc6bdd63f647accafab06 Author: Ian Lynagh Dat

[commit: ghc] master: Small refactoring: Use more idiomatic strictness forcing in AsmCodeGen (48bb69a)

Repository : ssh://darcs.haskell.org//srv/darcs/ghc On branch : master http://hackage.haskell.org/trac/ghc/changeset/48bb69ac4d5de847774657042d6b935d49445cb0 >--- commit 48bb69ac4d5de847774657042d6b935d49445cb0 Author: Ian Lynagh Dat

[commit: ghc] master: Implement the -dynamic-too optimised path for the NCG (bd8f7fc)

Repository : ssh://darcs.haskell.org//srv/darcs/ghc On branch : master http://hackage.haskell.org/trac/ghc/changeset/bd8f7fc56b84369f4e820263c0bcdc85760de6d4 >--- commit bd8f7fc56b84369f4e820263c0bcdc85760de6d4 Author: Ian Lynagh Dat

[commit: ghc] master: Add more plumbing to the nativeCodeGen (8685535)

Repository : ssh://darcs.haskell.org//srv/darcs/ghc On branch : master http://hackage.haskell.org/trac/ghc/changeset/8685535cfdfc68223162070c50d604072c3213b7 >--- commit 8685535cfdfc68223162070c50d604072c3213b7 Author: Ian Lynagh Dat

[commit: ghc] master: Package the NativeGen state up into a named type (d23148a)

Repository : ssh://darcs.haskell.org//srv/darcs/ghc On branch : master http://hackage.haskell.org/trac/ghc/changeset/d23148a9bbec06bc737b13572e5ee8c353060b29 >--- commit d23148a9bbec06bc737b13572e5ee8c353060b29 Author: Ian Lynagh Dat

[commit: nofib] master: Fix mandel in slow mode (890caa4)

Repository : ssh://darcs.haskell.org//srv/darcs/nofib On branch : master http://hackage.haskell.org/trac/ghc/changeset/890caa4077655494f83fa3b6670f6d99d8c58744 >--- commit 890caa4077655494f83fa3b6670f6d99d8c58744 Author: Ian Lynagh D

[commit: nofib] master: Detabbing (9f9d5df)

Repository : ssh://darcs.haskell.org//srv/darcs/nofib On branch : master http://hackage.haskell.org/trac/ghc/changeset/9f9d5dfc143803364f8a7853ec77d6677abc1b21 >--- commit 9f9d5dfc143803364f8a7853ec77d6677abc1b21 Author: Ian Lynagh D

[commit: nofib] master: Remove -fglasgow-exts when building nofib-analyse (6fc6e54)

Repository : ssh://darcs.haskell.org//srv/darcs/nofib On branch : master http://hackage.haskell.org/trac/ghc/changeset/6fc6e54a6f40aff06c4a9ea5e872f7b88b6e38e6 >--- commit 6fc6e54a6f40aff06c4a9ea5e872f7b88b6e38e6 Author: Ian Lynagh D

[commit: nofib] master: Add slow output for fft2 on x86_64/Linux (57944ff)

Repository : ssh://darcs.haskell.org//srv/darcs/nofib On branch : master http://hackage.haskell.org/trac/ghc/changeset/57944ffef0b8e08baa0f58e3a9c86749973e5b05 >--- commit 57944ffef0b8e08baa0f58e3a9c86749973e5b05 Author: Ian Lynagh D

[commit: nofib] master: Use a larger stack for spectral/hartel/event in slow mode (442a39f)

Repository : ssh://darcs.haskell.org//srv/darcs/nofib On branch : master http://hackage.haskell.org/trac/ghc/changeset/442a39f777e35e3a6d42c80b652e0e5a0f9b09b8 >--- commit 442a39f777e35e3a6d42c80b652e0e5a0f9b09b8 Author: Ian Lynagh D

[commit: nofib] master: Fix slow output for the power benchmark (8ccd4d1)

Repository : ssh://darcs.haskell.org//srv/darcs/nofib On branch : master http://hackage.haskell.org/trac/ghc/changeset/8ccd4d14d1dc6de670f33c3bb6624495ba320d17 >--- commit 8ccd4d14d1dc6de670f33c3bb6624495ba320d17 Author: Ian Lynagh D

tn23 (x86 OSX HEAD), build 780, Success

tn23 (x86 OSX HEAD), build 780 Build succeeded Details: http://darcs.haskell.org/ghcBuilder/builders/tn23/780.html git clone| Success create mk/build.mk | Success get subrepos | Success repo versions| Success touching clean-check files