February 2013 - ghc-devs

Unicode support for Haddock
by Max Bolingbroke 10 Mar '13

10 Mar '13

Hi GHCers, I recently ran into a problem where Haddock does not correctly handle Unicode in doc comments. So for example with this file: """ module Example where -- | 好 ok :: Int -> Int ok x = x -- | 个 misinterp :: Int -> Int misinterp _ = (-1) -- | 漢 failure :: Int -> Int failure x = x-1 """ Current versions of Haddock will output the documentation for "ok" correctly, will output an empty bulleted list as the documentation for "misinterp" and not output any documentation at all for "failure" (echoing a warning to stderr instead). This is kind of sad. There is a very old open ticket about this issue: http://trac.haskell.org/haddock/ticket/20. The patches I've attached to that ticket fix the problem by using the native Unicode support in Alex 3. I've also attached to the ticket a patch which makes the necessary changes to GHC's build system required to build this new Haddock correctly. Do these patches seem OK? Is it fine to insist on Alex 3? I think it was released in 2011 so I think by now we can assume that it is available on all machines that will want to build GHC. If this patch is accepted, at some point we might want to think about switching to Alex 3's unicode support in GHC's own lexer rather than relying on the current hacks. My patches do not make any change along those lines. Cheers, Max

3 3

Trac source browser not working
by Simon Marlow 10 Mar '13

10 Mar '13

I tried to follow a link to a commit on Trac today, and got an error: internal error (got unexpected object kind 'commit') The link I followed: http://hackage.haskell.org/trac/ghc/changeset/109a1e53287f50103e8a5b5922759… This was working before, has anything changed recently that would break it? I tried browsing to a couple of other commits and got the same error, so it doesn't seem specific to that commit. Cheers, Simon

3 2

FW: [commit: ghc] tc-arrows: Rearrange the typechecking of arrows, especially arrow "forms" (49badc9)
by Simon Peyton-Jones 04 Mar '13

04 Mar '13

Ross I've pushed a new branch, tc-arrows, for the new typechecking of arrows, based on the discussion we had last week. It all compiles, but won't work because I have done nothing to the desugaring. It uses our new representation with (env, nested-tuple-with-unit-at-end) rather than (nested-tuple-with-env-at-the-end), so desugaring needs significant attention. Would you like to work on the desugarer? I'm out of my depth, but happy to advise. Thanks Simon | -----Original Message----- | From: ghc-commits-bounces(a)haskell.org [mailto:ghc-commits- | bounces(a)haskell.org] On Behalf Of Simon Peyton Jones | Sent: 14 February 2013 16:08 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] tc-arrows: Rearrange the typechecking of arrows, | especially arrow "forms" (49badc9) | | Repository : ssh://darcs.haskell.org//srv/darcs/ghc | | On branch : tc-arrows | | http://hackage.haskell.org/trac/ghc/changeset/49badc91c52fc1f65a3ff5bfb3 | edaecbd617de61 | | >--------------------------------------------------------------- | | commit 49badc91c52fc1f65a3ff5bfb3edaecbd617de61 | Author: Simon Peyton Jones <simonpj(a)microsoft.com> | Date: Thu Feb 14 15:25:23 2013 +0000 | | Rearrange the typechecking of arrows, especially arrow "forms" | | The typechecking of arrow forms (in GHC 7.6) is known to be bogus, | because it marches down tuple types that may not yet be fully worked | out, depending on when constraint solving happens. Moreover, | coercions are generated and simply discarded. The fact that it | works | at all is a miracle. | | This refactoring is based on a conversation with Ross, where we | rearranged the typing of the argument stack, so that the arrows | have the form | a (env, (arg1, (arg2, ...(argn, ())))) res | rather than | a (arg1, (arg2, ...(argn, env))) res | as it was before. | | This is vastly simpler to typecheck; just look at the beautiful, | simple type checking of arrow forms now! | | We need a new HsCmdCast to capture the coercions generated from | the argument stack. | | Current state of play: | * syntax done | * renamer done | * typechecker done | * desugarer NOT DONE | | So nothing will work yet, hence on a branch | | compiler/deSugar/Coverage.lhs | 3 + | compiler/deSugar/DsArrows.lhs | 6 +- | compiler/hsSyn/HsExpr.lhs | 13 ++- | compiler/hsSyn/HsUtils.lhs | 7 +- | compiler/parser/Parser.y.pp | 4 +- | compiler/parser/RdrHsSyn.lhs | 4 +- | compiler/rename/RnExpr.lhs | 4 +- | compiler/rename/RnTypes.lhs | 2 +- | compiler/typecheck/TcArrows.lhs | 270 ++++++++++++++++++-------------- | ------- | compiler/typecheck/TcHsSyn.lhs | 6 +- | 10 files changed, 156 insertions(+), 163 deletions(-) | | | Diff suppressed because of size. To see it, use: | | git show 49badc91c52fc1f65a3ff5bfb3edaecbd617de61 | | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | http://www.haskell.org/mailman/listinfo/ghc-commits

2 3

missing darcs repos?
by Malcolm Wallace 02 Mar '13

02 Mar '13

Hello, Has someone recently removed the (old) darcs repos for libraries from e.g. http://darcs.haskell.org/packages/array etc? My nightly builds of nhc98 have recently started failing because this is (and no doubt others are) missing. It is not a disaster, since I can start publishing the most recent state of these repos myself, but I just wanted to check that the removal was intentional. I con't recall any specific email about it, although I admit I do not keep up very well with mailing list traffic these days. Regards, Malcolm

2 2

RE: libtoolize
by Simon Peyton-Jones 01 Mar '13

01 Mar '13

Is this new? Does it matter? Can I ignore it? Does everyone now need to install a new tool? I'm not sure how to "install libtool on my linux". (I thought we'd been using libtool, whatever it is, for years, so I'm puzzled why this has just started to happen.) Simon | -----Original Message----- | From: Karel Gardas [mailto:karel.gardas@centrum.cz] | Sent: 27 February 2013 11:18 | To: Simon Peyton-Jones | Subject: Re: libtoolize | | | Simon, | | those messages should go away if you install libtool package on your linux. | | Cheers, | Karel | | On 02/27/13 11:17 AM, Simon Peyton-Jones wrote: | > I've started to get this when I say "sh validate". What's up? | > | > Simon | > | > Booting . | > | > Can't exec "libtoolize": No such file or directory at | > /usr/bin/autoreconf line 196. | > | > Use of uninitialized value in pattern match (m//) at /usr/bin/autoreconf | > line 196. | > | > Booting libraries/base/ | > | > Can't exec "libtoolize": No such file or directory at | > /usr/bin/autoreconf line 196. | > | > Use of uninitialized value in pattern match (m//) at /usr/bin/autoreconf | > line 196. | > | > | > | > _______________________________________________ | > ghc-devs mailing list | > ghc-devs(a)haskell.org | > http://www.haskell.org/mailman/listinfo/ghc-devs

3 7

Fwd: [GHC] #7704: Phantom types break new polykind Typeable with either StandaloneDeriving or AutoDeriveTypeable
by José Pedro Magalhães 01 Mar '13

01 Mar '13

Hi Simon, How should an instance of Typeable for a polykinded tycon look like? E.g. if we have data Proxy (a :: k) = Proxy -- Proxy :: forall (k :: BOX). k -> * I suppose we want an instance forall k. instance Typeable (k -> *) (Proxy k) Right? So the universally quantified kind variables of the tycon should end up universally quantified in the instance as well. How does this translate to the ds_tvs, ds_tys, and ds_tc_args arguments of a DerivSpec?... Thanks, Pedro ---------- Forwarded message ---------- From: GHC <cvs-ghc(a)haskell.org> Date: Mon, Feb 18, 2013 at 8:42 PM Subject: [GHC] #7704: Phantom types break new polykind Typeable with either StandaloneDeriving or AutoDeriveTypeable To: Cc: ghc-tickets(a)haskell.org #7704: Phantom types break new polykind Typeable with either StandaloneDeriving or AutoDeriveTypeable -----------------------------+---------------------------------------------- Reporter: nwf | Owner: Type: bug | Status: new Priority: normal | Component: Compiler Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- This test program, reduced from an attempt to bring ekmett's tagged package to HEAD, {{{ {-# LANGUAGE DeriveDataTypeable #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE AutoDeriveTypeable #-} newtype Tagged s b = Tagged { unTagged :: b } }}} results in {{{ GHCi, version 7.7.20130218: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. [1 of 1] Compiling Main ( typeable.hs, interpreted ) typeable.hs:5:1: Derived typeable instance must be of form (Typeable Tagged) In the stand-alone deriving instance for `Data.Typeable.Internal.Typeable Tagged' }}} This message is also emitted if I replace `AutoDeriveTypeable` `StandaloneDeriving` and `deriving instance Typeable Tagged`. However, a "deriving (Typeable)" clause on the newtype definition works just fine. -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7704> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler _______________________________________________ ghc-tickets mailing list ghc-tickets(a)haskell.org http://www.haskell.org/mailman/listinfo/ghc-tickets

2 2

RFC: omit write barrier instructions unless '-threaded'
by Gabor Greif 01 Mar '13

01 Mar '13

Hi all, from what I gathered so far no emission of write barriers is needed when - running on a uniprocessor (-threaded or not) - running on a multiprocessor sans having linked with -threaded. Below patch suppresses the emission of 'lwsync' when no '-threaded' is specified on PPC only. So it does not cover both criteria above. It helps me a lot since I have a uniprocessor target that does not understand the 'lwsync' instruction (instruction is newer than core). Still, I have some doubts: o do we want to extend this approach to other archs? o possibly suppress the emission of MO_WriteBarrier in compiler/codeGen/StgCmmBind.hs (more care is needed to also cover compiler/cmm/CmmParse.y). Anyway this should be a safe first step, and I'd like to push it. When we find a general solution be can back this commit out. What do you think? Cheers, Gabor $ git show c0d682fb98f32e4ce5d27ff3a30f43b6cd70733e commit c0d682fb98f32e4ce5d27ff3a30f43b6cd70733e Author: Gabor Greif <ggreif(a)gmail.com> Date: Fri Feb 22 18:47:00 2013 +0100 Do not emit barriers on PPC unless we go the threaded way diff --git a/compiler/nativeGen/PPC/CodeGen.hs b/compiler/nativeGen/PPC/CodeGen.hs index 92eff36..6c33cca 100644 --- a/compiler/nativeGen/PPC/CodeGen.hs +++ b/compiler/nativeGen/PPC/CodeGen.hs @@ -1,9 +1,8 @@ - ----------------------------------------------------------------------------- -- -- Generating machine code (instruction selection) -- --- (c) The University of Glasgow 1996-2004 +-- (c) The University of Glasgow 1996-2013 -- ----------------------------------------------------------------------------- @@ -906,8 +905,10 @@ genCCall' -} -genCCall' _ _ (PrimTarget MO_WriteBarrier) _ _ - = return $ unitOL LWSYNC +genCCall' dflags _ (PrimTarget MO_WriteBarrier) _ _ + = return (if WayThreaded `elem` ways dflags + then unitOL LWSYNC + else nilOL) genCCall' _ _ (PrimTarget MO_Touch) _ _ = return $ nilOL

3 8

Confusing commit messages about `type-nats`?
by Iavor Diatchki 28 Feb '13

28 Feb '13

Hello, I am receiving a bunch of commit messages for branch `type-nats`, that seem to be fake (i.e., by folks committing to other branches). Does any one know why that is? It seems to have started after my merge commit from yesterday, so did I mess something up? -Iavor

3 3

Build errors on HEAD
by Jan Stolarek 28 Feb '13

28 Feb '13

I get this error when building HEAD (8fe04eb): utils/ghc-pkg/Main.hs:881:3: No instance for (Bin.Binary (InstalledPackageInfo_ String)) arising from a use of `writeBinaryFileAtomic' Possible fix: add an instance declaration for (Bin.Binary (InstalledPackageInfo_ String)) In the first argument of `catchIO', namely `writeBinaryFileAtomic filename (map convertPackageInfoOut (packages db))' In a stmt of a 'do' block: writeBinaryFileAtomic filename (map convertPackageInfoOut (packages db)) `catchIO` \ e -> if isPermissionError e then die (filename ++ ": you don't have permission to modify this file") else ioError e In the expression: do { let filename = location db </> cachefilename; when (verbosity > Normal) $ infoLn ("writing cache " ++ filename); writeBinaryFileAtomic filename (map convertPackageInfoOut (packages db)) `catchIO` \ e -> if isPermissionError e then die (filename ++ ": you don't have permission to modify this file") else ioError e } Anyone else getting this or is it just me? Janek

1 0

RE: [commit: base] master: Change rules for RealFrac methods to pointfree, so that they can also fire in pointfree use. (4036a1a)
by Simon Peyton-Jones 27 Feb '13

27 Feb '13

I followed the link e http://hackage.haskell.org/trac/ghc/changeset/4036a1ae7a9694c9c69749ec8e361… but got No handler matched request to /changeset/4036a1ae7a9694c9c69749ec8e36143c31bce976 I wonder why? Simon | -----Original Message----- | From: ghc-commits-bounces(a)haskell.org [mailto:ghc-commits- | bounces(a)haskell.org] On Behalf Of Daniel Fischer | Sent: 27 February 2013 13:58 | To: ghc-commits(a)haskell.org | Subject: [commit: base] master: Change rules for RealFrac methods to pointfree, | so that they can also fire in pointfree use. (4036a1a) | | Repository : ssh://darcs.haskell.org//srv/darcs/packages/base | | On branch : master | | http://hackage.haskell.org/trac/ghc/changeset/4036a1ae7a9694c9c69749ec8e36 | 143c31bce976 | | >--------------------------------------------------------------- | | commit 4036a1ae7a9694c9c69749ec8e36143c31bce976 | Author: Daniel Fischer <daniel.is.fischer(a)googlemail.com> | Date: Wed Feb 13 16:10:12 2013 +0100 | | Change rules for RealFrac methods to pointfree, so that they can also fire in | pointfree use. | | GHC/Int.hs | 96 +++++++++++++++++++++++++++++------------------ | ----------- | GHC/Word.hs | 72 ++++++++++++++++++++++---------------------- | 2 files changed, 84 insertions(+), 84 deletions(-) | | | Diff suppressed because of size. To see it, use: | | git show 4036a1ae7a9694c9c69749ec8e36143c31bce976 | | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | http://www.haskell.org/mailman/listinfo/ghc-commits

2 1

RE: [commit: base] master: Change rules for RealFrac methods to pointfree, so that they can also fire in pointfree use. (4036a1a)
by Simon Peyton-Jones 27 Feb '13

27 Feb '13

| Change rules for RealFrac methods to pointfree, so that they can also fire in | pointfree use. Good, thanks . But could you add a Note [Write rules in point-free style ~~~~~~~~~~~~~~~~~~~~~~ to explain what the motivating reason for the change is. Also an example or two. Perhaps there is a ticket that motivates it? Maybe refer to the Note from all the places where it is important? Simon | -----Original Message----- | From: ghc-commits-bounces(a)haskell.org [mailto:ghc-commits- | bounces(a)haskell.org] On Behalf Of Daniel Fischer | Sent: 27 February 2013 13:58 | To: ghc-commits(a)haskell.org | Subject: [commit: base] master: Change rules for RealFrac methods to pointfree, | so that they can also fire in pointfree use. (4036a1a) | | Repository : ssh://darcs.haskell.org//srv/darcs/packages/base | | On branch : master | | http://hackage.haskell.org/trac/ghc/changeset/4036a1ae7a9694c9c69749ec8e36 | 143c31bce976 | | >--------------------------------------------------------------- | | commit 4036a1ae7a9694c9c69749ec8e36143c31bce976 | Author: Daniel Fischer <daniel.is.fischer(a)googlemail.com> | Date: Wed Feb 13 16:10:12 2013 +0100 | | Change rules for RealFrac methods to pointfree, so that they can also fire in | pointfree use. | | GHC/Int.hs | 96 +++++++++++++++++++++++++++++------------------ | ----------- | GHC/Word.hs | 72 ++++++++++++++++++++++---------------------- | 2 files changed, 84 insertions(+), 84 deletions(-) | | | Diff suppressed because of size. To see it, use: | | git show 4036a1ae7a9694c9c69749ec8e36143c31bce976 | | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | http://www.haskell.org/mailman/listinfo/ghc-commits

2 1

libtoolize
by Simon Peyton-Jones 27 Feb '13

27 Feb '13

I've started to get this when I say "sh validate". What's up? Simon Booting . Can't exec "libtoolize": No such file or directory at /usr/bin/autoreconf line 196. Use of uninitialized value in pattern match (m//) at /usr/bin/autoreconf line 196. Booting libraries/base/ Can't exec "libtoolize": No such file or directory at /usr/bin/autoreconf line 196. Use of uninitialized value in pattern match (m//) at /usr/bin/autoreconf line 196.

1 0

Top-level type signatures in TcGblEnv?
by Edsko de Vries 26 Feb '13

26 Feb '13

Dear Simon, other ghc devs, I hooked into genericHscRecompile to traverse the typechecked source and construct an environment of type [(SrcSpan, Id)] recording all identifiers in the source with their type, definition site, etc. To be precise, I am traversing the tcg_binds :: LHsBinds Id, -- Value bindings in this module field of the TcGblEnv structure returned by the type checker. The problem is that I have so far been unable to find top-level user-supplied type annotations inside LHsBinds. The closest thing I've found is the PostTcType of a MatchGroup, but that is not Located; what I'm really looking for is an LSig. Now, let-bindings get a HsValBindsLR instead of an LHsBinds, and that *does* contain signatures. My question is two-fold: 1. First, am I missing something? Are there LSigs somewhere inside the TcGblEnv where I simply haven't seen them? 2. If not, is there a good reason why tcg_binds is an LHsBinds rather than an HsValBindsLR? And if there isn't, would you accept a patch making the change? Thanks, Edsko

3 5

Fwd: RFC: omit write barrier instructions unless '-threaded'
by Gabor Greif 26 Feb '13

26 Feb '13

From: Gabor Greif <ggreif(a)gmail.com> Date: Tue, 26 Feb 2013 10:45:52 +0100 Subject: Re: RFC: omit write barrier instructions unless '-threaded' To: Simon Marlow <marlowsd(a)gmail.com> Cool, pushed https://github.com/ghc/ghc/commit/b7ae3cd9273da044384de4a327a4a5d71190129e Cheers, Gabor On 2/26/13, Simon Marlow <marlowsd(a)gmail.com> wrote: > On 25/02/13 22:07, Gabor Greif wrote: >> Thanks, this helped! >> >> >> Something like this? >> >> $ git show c3f5312 >> commit c3f53126fb0835cb21fc085e9b7cb5acb1ea1fba >> Author: Gabor Greif <ggreif(a)gmail.com> >> Date: Mon Feb 25 23:03:23 2013 +0100 >> >> Only emit %write_barrier primitive for THREADED_RTS >> >> diff --git a/includes/Cmm.h b/includes/Cmm.h >> index 1505b1c..bc5702c 100644 >> --- a/includes/Cmm.h >> +++ b/includes/Cmm.h >> @@ -583,6 +583,12 @@ >> #define OVERWRITING_CLOSURE(c) /* nothing */ >> #endif >> >> +#ifdef THREADED_RTS >> +#define prim_write_barrier prim %write_barrier() >> +#else >> +#define prim_write_barrier /* nothing */ >> +#endif >> + >> /* >> ----------------------------------------------------------------------------- >> Ticky macros >> >> -------------------------------------------------------------------------- >> */ >> diff --git a/rts/Updates.h b/rts/Updates.h >> index b4ff7d1..e6a2eb9 100644 >> --- a/rts/Updates.h >> +++ b/rts/Updates.h >> @@ -46,7 +46,7 @@ >> \ >> OVERWRITING_CLOSURE(p1); \ >> StgInd_indirectee(p1) = p2; \ >> - prim %write_barrier(); \ >> + prim_write_barrier; \ >> SET_INFO(p1, stg_BLACKHOLE_info); \ >> LDV_RECORD_CREATE(p1); \ >> bd = Bdescr(p1); \ >> >> >> Okay to commit? > > Yes, ok. > > Cheers, > Simon > > > >> Cheers, >> >> Gabor >> >> On 2/25/13, Simon Marlow <marlowsd(a)gmail.com> wrote: >>> On 25/02/13 14:53, Gabor Greif wrote: >>>> On 2/25/13, Simon Marlow <marlowsd(a)gmail.com> wrote: >>>>> On 24/02/13 20:40, Gabor Greif wrote: >>>>>> Hi all, >>>>>> >>>>>> from what I gathered so far no emission of write barriers is needed >>>>>> when >>>>>> - running on a uniprocessor (-threaded or not) >>>>>> - running on a multiprocessor sans having linked with -threaded. >>>>>> >>>>>> Below patch suppresses the emission of 'lwsync' when no '-threaded' >>>>>> is >>>>>> specified on PPC only. So it does not cover both criteria above. >>>>>> >>>>>> It helps me a lot since I have a uniprocessor target that does not >>>>>> understand the 'lwsync' instruction (instruction is newer than core). >>>>>> >>>>>> Still, I have some doubts: >>>>>> o do we want to extend this approach to other archs? >>>>>> o possibly suppress the emission of MO_WriteBarrier in >>>>>> compiler/codeGen/StgCmmBind.hs >>>>>> (more care is needed to also cover compiler/cmm/CmmParse.y). >>>>>> >>>>>> Anyway this should be a safe first step, and I'd like to push it. >>>>>> When >>>>>> we find a general solution be can back this commit out. >>>>>> >>>>>> What do you think? >>>>> >>>>> I don't think this is the right way to do it. The -threaded flag is >>>>> not >>>>> supposed to affect code generation, it only changes the RTS that gets >>>>> linked in. That is, you can compile all your code without -threaded >>>>> and >>>>> then just add -threaded at the link step, and it will work. >>>>> >>>> >>>> Hi Simon, >>>> >>>> thanks for your review! >>>> >>>>> Instead, use conditional compilation in the RTS so that the >>>>> write_barrer() calls are only present when THREADED_RTS is on. >>>> >>>> This is already done the way you suggest: >>>> >>>> #define write_barrier() /* nothing */ >>>> >>>> in includes/stg/SMP.h:368 >>>> >>>> Works perfectly, 'lwsync' only appears in .thr_*.o files. >>>> >>>> My problem stems from another call: >>>> >>>> emitPrimCall [] MO_WriteBarrier [] >>>> >>>> in compiler/codeGen/StgCmmBind.hs:614 >>>> >>>> or possibly >>>> >>>> callishMachOps = listToUFM $ >>>> map (\(x, y) -> (mkFastString x, y)) [ >>>> ( "write_barrier", MO_WriteBarrier ), >>>> ( "memcpy", MO_Memcpy ), >>>> ( "memset", MO_Memset ), >>>> ( "memmove", MO_Memmove ) >>>> -- ToDo: the rest, maybe >>>> ] >>>> >>>> in compiler/cmm/CmmParse.y:920 >>>> >>>> I doubt these files should be compiled with a dependency on >>>> THREADED_RTS, and indeed this symbol is only ever defined >>>> (-optc-DTHREADED_RTS) for the C compiler, and thus not available when >>>> compiling haskell source. >>>> >>>> So I am still stumped. >>>> >>>> The function where "lwsync" surfaces is: >>>> >>>> stg_marked_upd_frame_info which is rts/Updates.cmm:46. >>> >>> These come from rts/Updates.h:updateWithIndirection(), which expands to >>> some Cmm code that uses "prim %write_barrier()". So you want to use >>> some conditional compilation to make that prim %write_barrier() >>> disappear when THREADED_RTS is off. I suggest replacing it with >>> write_barrier(), and then #define write_barrier() in includes/Cmm.h. >>> >>> Cheers, >>> Simon >>> >>> >>>> This one is creating a blackhole (IISC) by means of StgCmmBind.hs:614. >>>> >>>> How can we go on from here? >>>> >>>> Cheers, >>>> >>>> Gabor >>>> >>>> >>>> >>>>> >>>>> Cheers, >>>>> Simon >>>>> >>>>> >>>>>> Cheers, >>>>>> >>>>>> Gabor >>>>>> >>>>>> $ git show c0d682fb98f32e4ce5d27ff3a30f43b6cd70733e >>>>>> commit c0d682fb98f32e4ce5d27ff3a30f43b6cd70733e >>>>>> Author: Gabor Greif <ggreif(a)gmail.com> >>>>>> Date: Fri Feb 22 18:47:00 2013 +0100 >>>>>> >>>>>> Do not emit barriers on PPC unless we go the threaded way >>>>>> >>>>>> diff --git a/compiler/nativeGen/PPC/CodeGen.hs >>>>>> b/compiler/nativeGen/PPC/CodeGen.hs >>>>>> index 92eff36..6c33cca 100644 >>>>>> --- a/compiler/nativeGen/PPC/CodeGen.hs >>>>>> +++ b/compiler/nativeGen/PPC/CodeGen.hs >>>>>> @@ -1,9 +1,8 @@ >>>>>> - >>>>>> >>>>>> ----------------------------------------------------------------------------- >>>>>> -- >>>>>> -- Generating machine code (instruction selection) >>>>>> -- >>>>>> --- (c) The University of Glasgow 1996-2004 >>>>>> +-- (c) The University of Glasgow 1996-2013 >>>>>> -- >>>>>> >>>>>> ----------------------------------------------------------------------------- >>>>>> >>>>>> @@ -906,8 +905,10 @@ genCCall' >>>>>> -} >>>>>> >>>>>> >>>>>> -genCCall' _ _ (PrimTarget MO_WriteBarrier) _ _ >>>>>> - = return $ unitOL LWSYNC >>>>>> +genCCall' dflags _ (PrimTarget MO_WriteBarrier) _ _ >>>>>> + = return (if WayThreaded `elem` ways dflags >>>>>> + then unitOL LWSYNC >>>>>> + else nilOL) >>>>>> >>>>>> genCCall' _ _ (PrimTarget MO_Touch) _ _ >>>>>> = return $ nilOL >>>>>> >>>>>> _______________________________________________ >>>>>> ghc-devs mailing list >>>>>> ghc-devs(a)haskell.org >>>>>> http://www.haskell.org/mailman/listinfo/ghc-devs >>>>>> >>>>> >>>>> >>> >>> > >

1 0

Why not rebase instead of merge?
by Geoffrey Mainland 25 Feb '13

25 Feb '13

I don't want to bike shed, but the prevalence of empty merge commits in the repo seems both undesirable and avoidable. I always rebase my work instead of merge. Is there a reason this is not standard practice in the repo? It certainly makes for a nicer history. Thanks, Geoff

11 19

scheduleWaitThread looping
by Gabor Greif 25 Feb '13

25 Feb '13

I have finally have a cross compiler building, but encounter a new problem with a simple "Hello World" program not working. I get in GDB: Breakpoint 1, 0x102b4718 in startHeapProfTimer () (gdb) Continuing. Breakpoint 3, 0x102b4708 in stopHeapProfTimer () (gdb) Continuing. Breakpoint 1, 0x102b4718 in startHeapProfTimer () (gdb) bt #0 0x102b4718 in startHeapProfTimer () #1 0x1028d918 in scheduleWaitThread () #2 0x102b5dd0 in rts_evalLazyIO () #3 0x1028b674 in real_main () #4 0x1028b79c in hs_main () #5 0x100021dc in main () The program seems to loop in scheduleWaitThread, toggling the HeapProfTimer endlessly and nothing useful happens. Any idea what could be wrong, or how I could tackle debugging this problem. The native build of the same program with same compiler version (HEAD) works well. Under what condition is scheduleWaitThread supposed to return? How can I enable source debugging for RTS files? I should note that this is a big-endian target (PPC) and I have seen trouble with certain fields being wrongly swapped in the past, but IIRC those resulted in crashes. Cheers and thanks, Gabor

3 2

Heads-up: new parallel I/O manager merged
by Johan Tibell 25 Feb '13

25 Feb '13

Hi, I've merged the new parallel I/O manager that Andreas Voellmy and Kazu Yamamoto have been working on. The new parallel I/O manager scales much better than the current one*: the number of requests per second scales almost linearly up to 32 cores I believe. Perhaps Andreas could post the numbers. If you see any bugs that you think are related to the new I/O manager, please let Andreas and Kazu know. * The current one (which replaced an even earlier one) scaled well in the number of open file descriptors and performed better than the I/O manager it replaced, but it didn't scale well to multiple cores. Cheers, Johan

8 10

online docs for GHC head seem to be stale
by Carter Schonwald 24 Feb '13

24 Feb '13

Hey All, I've been looking around in the documentation online for the current ghc head, and it looks to lack any information on the new SIMD ops. then i noticed the time stamp: http://www.haskell.org/ghc/dist/current/docs/html/libraries/ so those docs are from December? Whats needed to be done to bring those to be more up to date?

1 0

FFI to poll()
by Kazu Yamamoto 24 Feb '13

24 Feb '13

Hello, I'm now looking into a bug of the poll backend. base/GHC/Event/Poll.hsc declares FFI to poll() as follows: foreign import ccall safe "poll.h poll" c_poll :: Ptr PollFd -> CULong -> CInt -> IO CInt The second argument is defined unsigned long on Linux. However, it is unsigned int on Mac and FreeBSD. I think this is a source of the bug which I'm looking into. A simple fix is like this: #if defined(freebsd_HOST_OS) || defined(darwin_HOST_OS) foreign import ccall safe "poll.h poll" c_poll :: Ptr PollFd -> CUInt -> CInt -> IO CInt #else foreign import ccall safe "poll.h poll" c_poll :: Ptr PollFd -> CULong -> CInt -> IO CInt #endif But this is not generic enough. Any suggestions to fix this? --Kazu

2 5

[PATCH] Testsuite doesn't clean .tix files for hpc way
by Bill Tutt 24 Feb '13

24 Feb '13

The testsuite driver doesn't clean up the .exe.tix files in the default cleaning logic. Here's a patch that attempts to do this on Windows/* by adding '.exe.tix' and '.tix'. Fyi, Bill

1 0

iconv_open failure --- WAS: Re: scheduleWaitThread looping
by Gabor Greif 24 Feb '13

24 Feb '13

On 2/23/13, Stephen Paul Weber <singpolyma(a)singpolyma.net> wrote: > Somebody claiming to be Gabor Greif wrote: >>I have finally have a cross compiler building, but encounter a new >>problem with a simple "Hello World" program not working. >> >>HeapProfTimer endlessly and nothing useful happens. Any idea what >>could be wrong, or how I could tackle debugging this problem. The >>native build of the same program with same compiler version (HEAD) >>works well. > > This may be unrelated, but I've had a similar issue that I haven't finished > > debugging yet. > > Is the LANG environment variable set? Trying running with LANG="" Hi Stephen! This did not help. But you pointed me to the right direction :-) I observed that in each loop 'iconv_open' gets called, but returns a failure (-1) Breakpoint 1, 0x0fdac770 in iconv_open () from /lib/tls/libc.so.6 (gdb) p (char*)$r3 $1 = 0x3010401c "ANSI_X3.4-1968" (gdb) p (char*)$r4 $2 = 0x30104008 "UTF-32BE" (gdb) call iconv_open("ANSI_X3.4-1968","UTF-32BE") $3 = -1 (gdb) call iconv_open("ASCII","ASCII") $4 = 272079520 (gdb) call iconv_open("ASCII","UTF-32BE") $5 = -1 (gdb) call iconv_open("ASCII","UTF-32") $6 = -1 (gdb) call iconv_open("ASCII","UTF-8") $7 = 272088200 (gdb) call iconv_open("ANSI_X3.4-1968","UTF-8") $8 = 272120976 As you see my manual attempts to get a converter towards UTF-8 worked. The main problem is that upon failure, an error with a message is thrown, which restarts the scheduler loop again, but cannot display any message because in order to do that it needs to open iconv again... A veritable catch-22. So all keeps looping and nothing happens. Here is the relevant code from base/GHC/IO/Encoding/Iconv.hs: newIConv from to rec fn = -- Assume charset names are ASCII withCAString from $ \ from_str -> withCAString to $ \ to_str -> do iconvt <- throwErrnoIfMinus1 "mkTextEncoding" $ hs_iconv_open to_str from_str let iclose = throwErrnoIfMinus1_ "Iconv.close" $ hs_iconv_close iconvt return BufferCodec{ encode = fn iconvt, recover = rec, close = iclose, -- iconv doesn't supply a way to save/restore the state getState = return (), setState = const $ return () } What is disturbing me, that this simple hello-world program used to work a year ago, with no iconv-related problems at all, and I am wondering what has changed since 7.5 and how to salvage the situation now? I am thankful for any suggestions, cheers, Gabor > > -- > Stephen Paul Weber, @singpolyma > See <http://singpolyma.net> for how I prefer to be contacted > edition right joseph >

1 0

[PATCH] (base) Fix documentation
by shelarcy 23 Feb '13

23 Feb '13

Hello, Data.String's document decribes wrong option name. I made patch to fix that. Best Regards, -- shelarcy <shelarcy hotmail.co.jp> http://page.freett.com/shelarcy/

1 0

one other (relatively minor) issue building on Windows
by Daniel Pratt 22 Feb '13

22 Feb '13

I encountered one other (relatively minor) issue building on Windows: In my recently installed MinGW environment, there was no "usr/local" folder until I created it. For this reason, the "make install" process silently failed to copy the binaries to their intended location.

1 0

Re: [commit: ghc] master: Always quote arguments to removeFiles (fixes Windows install). (1a3247f)
by Gabor Greif 22 Feb '13

22 Feb '13

On 2/22/13, Geoffrey Mainland <gmainlan(a)microsoft.com> wrote: > Repository : ssh://darcs.haskell.org//srv/darcs/ghc > > On branch : master > > http://hackage.haskell.org/trac/ghc/changeset/1a3247f6a5d98c15139e8650c88a6… > >>--------------------------------------------------------------- > > commit 1a3247f6a5d98c15139e8650c88a61284a786731 > Author: Geoffrey Mainland <gmainlan(a)microsoft.com> > Date: Fri Feb 22 15:26:55 2013 +0000 > > Always quote arguments to removeFiles (fixes Windows install). > > Thanks to Daniel Pratt <colorblinddad(a)gmail.com> for pointing out the > failure > and fix. > ... > install_ghc_post: install_bins > - $(call removeFiles,$(DESTDIR)$(bindir)/ghc.exe) > + $(call removeFiles,"$(DESTDIR)$(bindir)/ghc.exe") This should be $(call removeFiles,"$(DESTDIR)$(bindir)/$(CrossCompilePrefix)ghc.exe") Cheers, Gabor > "$(MV)" -f $(DESTDIR)$(bindir)/ghc-stage$(INSTALL_GHC_STAGE).exe > $(DESTDIR)$(bindir)/$(CrossCompilePrefix)ghc.exe > endif > > http://www.haskell.org/mailman/listinfo/ghc-commits >

1 0

make install fails on Windows (8?) -- redux
by Daniel Pratt 22 Feb '13

22 Feb '13

My first attempt to build GHC (on Windows 8) from sources went pretty well until I got to the "make install" step. Some research revealed that at least one other person got the same error I did<http://www.haskell.org/pipermail/cvs-ghc/2012-November/078353.html>building on Windows. That other person "fixed" the problem by deleting the offending lines from the build scripts. I looked around a bit and noticed that pretty much every other place else that removeFiles was referenced, the path was quoted. I added quotes to the paths on the two offending lines and subsequently the "make install" process completed without errors. I'm happy to log a bug, submit a patch, etc., but since this would be my first time doing that, I thought I should run it by you folks first. The wiki suggests adding a test case for a bug, but since this is a build error, I suppose that wouldn't make sense?

2 1

libraries/binary does not compile with ghc-7.7
by Gabor Greif 20 Feb '13

20 Feb '13

Hi all, when bootstrapping with GHC-7.7 I get HC [stage 0] libraries/binary/dist-boot/build/Data/Binary/Get.o libraries/binary/src/Data/Binary/Get.hs:101:1: Warning: The import of `GHC.Int' is redundant except perhaps to import instances from `GHC.Int' To import instances alone, use: import GHC.Int() libraries/binary/src/Data/Binary/Get.hs:371:15: Warning: In the use of `unsafeInterleaveST' (imported from Control.Monad.ST): Deprecated: "Please import from Control.Monad.ST.Unsafe instead; This will be removed in the next release" libraries/binary/src/Data/Binary/Get.hs:383:44: Warning: In the use of `unsafeInterleaveST' (imported from Control.Monad.ST): Deprecated: "Please import from Control.Monad.ST.Unsafe instead; This will be removed in the next release" HC [stage 0] libraries/binary/dist-boot/build/Data/Binary/Builder/Base.o libraries/binary/src/Data/Binary/Builder/Base.hs:180:22: Ambiguous occurrence `unsafePerformIO' It could refer to either `Foreign.unsafePerformIO', imported from `Foreign' at libraries/binary/src/Data/Binary/Builder/Base.hs:69:1-14 or `System.IO.Unsafe.unsafePerformIO', imported from `System.IO.Unsafe' at libraries/binary/src/Data/Binary/Builder/Base.hs:71:1-23 (and originally defined in `GHC.IO') make[1]: *** [libraries/binary/dist-boot/build/Data/Binary/Builder/Base.o] Error 1 I have two commits to fix this: $ git show ded894cd6abb209406e2ce16361acbb7111774d0 commit ded894cd6abb209406e2ce16361acbb7111774d0 Author: Gabor Greif <ggreif(a)gmail.com> Date: Thu Oct 25 12:59:53 2012 +0200 fix import warnings diff --git a/src/Data/Binary/Get.hs b/src/Data/Binary/Get.hs index 7134217..eaba669 100644 --- a/src/Data/Binary/Get.hs +++ b/src/Data/Binary/Get.hs @@ -92,13 +92,13 @@ import Control.Applicative (Applicative(..)) import Foreign -- used by splitAtST -import Control.Monad.ST +import Control.Monad.ST (ST, runST) +import Control.Monad.ST.Unsafe (unsafeInterleaveST) import Data.STRef #if defined(__GLASGOW_HASKELL__) && !defined(__HADDOCK__) import GHC.Base import GHC.Word -import GHC.Int #endif -- | The parse state $ git show 9c8b00ab88b6b8b996e0725d242df9a225d4236e commit 9c8b00ab88b6b8b996e0725d242df9a225d4236e Author: Gabor Greif <ggreif(a)gmail.com> Date: Thu Oct 25 13:39:28 2012 +0200 do not import unsafePerformIO from Foreign (eliminating warning) diff --git a/src/Data/Binary/Builder/Base.hs b/src/Data/Binary/Builder/Base.hs index 8124f65..31b5115 100644 --- a/src/Data/Binary/Builder/Base.hs +++ b/src/Data/Binary/Builder/Base.hs @@ -67,6 +67,7 @@ import qualified Data.ByteString.Lazy as L import Data.Monoid import Data.Word import Foreign +import System.IO.Unsafe (unsafePerformIO) #ifdef BYTESTRING_IN_BASE import Data.ByteString.Base (inlinePerformIO) @@ -174,7 +175,7 @@ data Buffer = Buffer {-# UNPACK #-} !(ForeignPtr Word8) -- the lazy 'L.ByteString' is demanded. -- toLazyByteString :: Builder -> L.ByteString -toLazyByteString m = unsafePerformIO $ do +toLazyByteString m = System.IO.Unsafe.unsafePerformIO $ do buf <- newBuffer defaultSize runBuilder (m `append` flush) (const (return L.Empty)) buf {-# INLINE toLazyByteString #-} Okay to push to master? Cheers, Gabor

2 3

Re: No newline at end of file
by Kazu Yamamoto 20 Feb '13

20 Feb '13

Edward, > I went ahead and fixed it; Thanks. > why is FreeBSD choking on lack of trailing newlines though? I'm not sure. But I saw "error" and probably "-Werror" in "validate" stopped building. --Kazu

1 0

No newline at end of file
by Kazu Yamamoto 20 Feb '13

20 Feb '13

Hi, The current libraries/dph-lifted-copy/Data/Array/Parallel/PArray/ScalarInstances.hs does not have a new line at end of file. This is one of reasons why "validate" does not work on FreeBSD at this moment. --Kazu

1 0

libraries/unix: ghc-cabal: No buildable component found
by Karel Gardas 19 Feb '13

19 Feb '13

Hello, I'm trying to build GHC cross-compiler to RTEMS OS, but I'm stuck on getting this error message from ghc-cabal while configuring libraries/unix: ghc-cabal: No buildable component found gmake[1]: *** [libraries/unix/dist-install/package-data.mk] Error 1 I'm not able to find out under which condition(s) cabal signals "no buildable component found" on this particular library. Any idea? Thanks a lot! Karel

2 1

Dreaded "... has stopped working" with LLVM back end on Win64
by Geoffrey Mainland 18 Feb '13

18 Feb '13

I'm using the 7.6.2 Win64 port to try to compile HEAD with the quick-llvm BuildFlavour (I'm using LLVM 3.1). This entails setting -optlc-mtriple=x86_64-w64-mingw32 since the LLVM back-end doesn't output the right triple when producing .ll files. Unfortunately I get the dreaded "ghc-cabal.exe has stopped working" pop-up dialog as soon as ghc-cabal.exe is invoked. Interestingly, ghc-cabal.exe behaves as expected when invoked with no command line arguments. I have no idea where to start with this one. Any hints? Has anyone ever used the LLVM back end on Win64 (I'm guessing not). Thanks, Geoff

1 0

ticky/cc profiling and heap checks
by Nicolas Frisby 18 Feb '13

18 Feb '13

I noticed some suspicious wiggling in my ticky reports' entry counts. SPJ suggested they were due to the counter ticking before the heap check: if it fails, then it ticks again when we re-enter after the stg_gc function does its thing. After looking into it a bit further, I have a couple questions. Here's what I found. * for functions (StgCmmBind.closureCodeBody), tickyEnterFun and enterCostCentreFun are before the heap check * for thunks (StgCmmBind.thunkCode), tickyEnterThunk is before the heap check and enterCostCentreThunk is after. Questions: * Does any object to me moving both ticky counters after the heap check? * Is there a reason the two cost centre profiling entries are on opposite sides of the heap check? Thanks.

2 4

low-level profiling
by Nicolas Frisby 18 Feb '13

18 Feb '13

I'm way below my depth here, but I'd like to use the perf tool to see where a program is spending its time. Unfortunately, the recipe here http://hackage.haskell.org/trac/ghc/wiki/Debugging/LowLevelProfiling/Perf isn't working for me. I get output like this instead 90.20% drbg_test drbg_test [.] 0x2515ef 5.71% drbg_test [kernel.kallsyms] [k] 0xffffffff8103e0ca 1.53% drbg_test libc-2.15.so [.] bsearch 1.02% drbg_test libc-2.15.so [.] 0x9194c 0.43% drbg_test libgmp.so.10.0.2 [.] __gmpz_mul_2exp 0.27% drbg_test libgmp.so.10.0.2 [.] __gmpz_add 0.16% drbg_test [vdso] [.] 0x7fffd3d25983 0.16% drbg_test libgmp.so.10.0.2 [.] __gmpn_lshift 0.10% drbg_test libgmp.so.10.0.2 [.] 0x13565 0.05% drbg_test libgmp.so.10.0.2 [.] __gmpz_init 0.05% drbg_test libc-2.15.so [.] __select 0.05% drbg_test libgmp.so.10.0.2 [.] __gmpn_modexact_1_odd 0.05% drbg_test libgmp.so.10.0.2 [.] __gmpz_realloc 0.05% drbg_test libc-2.15.so [.] __errno_location 0.05% drbg_test drbg_test [.] __gmpz_init@plt 0.05% drbg_test librt-2.15.so [.] clock_gettime 0.05% drbg_test libgmp.so.10.0.2 [.] __gmpn_add_n Again --- below my depth here --- but I don't know how to investigate what 0x2515ef indicates. Does anyone have any pointers? I was hoping that the address would be a nice RTS-ish symbol, like in the Wiki's examples. Thanks for your time.

4 12

unprotected use of global variables in base:GHC.IO.Encoding
by Nicolas Frisby 18 Feb '13

18 Feb '13

I've noticed some suspicious code in base:GHC.IO.Encoding. setLocaleEncoding, setFileSystemEncoding, setForeignEncoding :: TextEncoding -> IO () (getLocaleEncoding, setLocaleEncoding) = mkGlobal initLocaleEncoding (getFileSystemEncoding, setFileSystemEncoding) = mkGlobal initFileSystemEncoding (getForeignEncoding, setForeignEncoding) = mkGlobal initForeignEncoding mkGlobal :: a -> (IO a, a -> IO ()) mkGlobal x = unsafePerformIO $ do x_ref <- newIORef x return (readIORef x_ref, writeIORef x_ref) I've not elided any pragmas and there's no relevant LANGUAGE or OPTIONS pragmas. With HEAD from a couple weeks ago, mkGlobal is not getting inlined. But with some of my experimental alterations of sizeExpr, it is getting inlined. So this code should probably have some of the guards for faking global variables, right?

2 1

Current testsuite failures
by José Pedro Magalhães 17 Feb '13

17 Feb '13

Hi all, (resending without attachment because the previous email got rejected) Last night I've built GHC HEAD with the default settings, and ran the testsuite with just `make`. It ran into 77 unexpected failures; the failure log is available at http://hpaste.org/82291. The summary is at the end of this email. I've fixed the Data.Typeable.Proxy ones in the meantime. The rest I don't know, but maybe some of you can relate to some of these failures. Cheers, Pedro Unexpected failures: ../../libraries/base/tests/IO hClose002 [bad exit code] (ghci,threaded1,threaded2) ../../libraries/directory/tests getPermissions001 [bad stdout] (normal,hpc,optasm,threaded1,threaded2) ../../libraries/hpc/tests/simple/tixs hpc_help_draft [bad stdout] (normal) ../../libraries/hpc/tests/simple/tixs hpc_help_markup [bad stdout] (normal) ../../libraries/hpc/tests/simple/tixs hpc_help_overlay [bad stdout] (normal) ../../libraries/hpc/tests/simple/tixs hpc_help_report [bad stdout] (normal) ../../libraries/hpc/tests/simple/tixs hpc_help_show [bad stdout] (normal) ../../libraries/hpc/tests/simple/tixs hpc_markup_error_001 [bad stdout] (normal) ../../libraries/hpc/tests/simple/tixs hpc_markup_error_002 [bad stdout] (normal) ../../libraries/hpc/tests/simple/tixs hpc_report_error_001 [bad stdout] (normal) ../../libraries/hpc/tests/simple/tixs hpc_report_error_002 [bad stdout] (normal) ../../libraries/hpc/tests/simple/tixs hpc_show_error_001 [bad stdout] (normal) ../../libraries/hpc/tests/simple/tixs hpc_show_error_002 [bad stdout] (normal) ../../libraries/hpc/tests/simple/tixs hpc_version [bad stdout] (normal) ../../libraries/process/tests process007 [bad stderr] (threaded1,threaded2) ../../libraries/process/tests process007 [bad stdout or stderr] (ghci) ../../libraries/unix/tests getEnvironment02 [bad exit code] (ghci) ../../libraries/unix/tests/libposix posix005 [bad stdout or stderr] (ghci) codeGen/should_compile jmp_tbl [exit code non-0] (hpc) codeGen/should_compile massive_array [exit code non-0] (hpc) codeGen/should_run cgrun068 [bad exit code] (ghci) concurrent/should_run T5611 [bad exit code] (ghci) concurrent/should_run foreignInterruptible [bad exit code] (ghci) driver/recomp006 recomp006 [bad stderr] (normal) ffi/should_run T1679 [bad exit code] (ghci) ffi/should_run T7170 [bad stdout or stderr] (ghci) ghc-api T6145 [bad exit code] (normal) ghc-api/T4891 T4891 [bad exit code] (normal) numeric/should_run arith016 [bad exit code] (ghci) numeric/should_run expfloat [bad exit code] (ghci) parser/should_run readRun002 [bad exit code] (ghci) parser/should_run readRun004 [bad exit code] (hpc) perf/compiler T1969 [stat not good enough] (normal) perf/compiler T3064 [stat not good enough] (normal) perf/compiler T3294 [stat not good enough] (normal) perf/compiler T4801 [stat not good enough] (normal) perf/compiler T5030 [stat not good enough] (normal) perf/compiler T5321FD [stat not good enough] (normal) perf/compiler T5321Fun [stat not good enough] (normal) perf/compiler T5631 [stat not good enough] (normal) perf/compiler T5642 [stat not good enough] (normal) perf/compiler T5837 [stat not good enough] (normal) perf/compiler T6048 [stat not good enough] (optasm) perf/compiler T783 [stat not good enough] (normal) perf/compiler parsing001 [stat not good enough] (normal) perf/should_run lazy-bs-alloc [stat too good] (normal) plugins plugins01 [bad stderr] (normal) programs/andy_cherry andy_cherry [bad exit code] (ghci) programs/barton-mangler-bug barton-mangler-bug [bad exit code] (hpc,optasm,threaded2) programs/life_space_leak life_space_leak [bad exit code] (ghci) programs/seward-space-leak seward-space-leak [bad exit code] (ghci) rts stack002 [bad exit code] (threaded1,threaded2) simplCore/should_compile T4908 [stderr mismatch] (optasm) simplCore/should_compile spec-inline [stderr mismatch] (optasm) th TH_emptycase [stderr mismatch] (normal)

2 1

[PATCH] fixes for android in libraries/unix
by Nathan Hüsken 17 Feb '13

17 Feb '13

Hey, These patches are for libraries/unix. They may need some discussing, because I am not sure if this is the right thing. 1. On android the passwd struct does not define pw_gecos. The first patch therefor sets it to the empty string. 2. The android ndk does not define _POSIX_VDISABLE, but it defines _PC_VDISABLE. The second patch defines _POSIX_VDISABLE to _PC_VIDISABLE, which is (as I undestand it) what the POSIX programmer guide suggests. 3. The android ndk does not define telldir and seekdir. The third patch removes them when compiling for android.

3 5

[PATCH] (haskeline) Include termios.h on android
by Nathan Hüsken 17 Feb '13

17 Feb '13

Hey, This patch is for libraries/haskeline. On android, winsize is defined in termios.h and therefor termios.h must be included.

2 3

Re: [commit: ghc] master: Build fix for dyn way on Windows; patch from nus (c39d315)
by Bill Tutt 17 Feb '13

17 Feb '13

On Sat, Feb 16, 2013 at 5:04 PM, Ian Lynagh <igloo(a)earth.li> wrote: > diff --git a/rts/Prelude.h b/rts/Prelude.h > index dcd7b94..89e80a0 100644 > --- a/rts/Prelude.h > +++ b/rts/Prelude.h > @@ -93,6 +93,7 @@ PRELUDE_INFO(base_GHCziStable_StablePtr_con_info); > > #define runSparks_closure > DLL_IMPORT_DATA_REF(base_GHCziConcziSync_runSparks_closure) > #define ensureIOManagerIsRunning_closure > DLL_IMPORT_DATA_REF(base_GHCziConcziIO_ensureIOManagerIsRunning_closure) > +#define ioManagerCapabilitiesChanged_closure > DLL_IMPORT_DATA_REF(base_GHCziConcziIO_ioManagerCapabilitiesChanged_closure) > #define runHandlers_closure > DLL_IMPORT_DATA_REF(base_GHCziConcziSignal_runHandlers_closure) > > #define flushStdHandles_closure > DLL_IMPORT_DATA_REF(base_GHCziTopHandler_flushStdHandles_closure) > > diff --git a/rts/Schedule.c b/rts/Schedule.c > index f39ef96..ea779dd 100644 > --- a/rts/Schedule.c > +++ b/rts/Schedule.c > @@ -2070,7 +2070,7 @@ setNumCapabilities (nat new_n_capabilities > USED_IF_THREADS) > // Notify IO manager that the number of capabilities has changed. > rts_evalIO( > &cap, > - &base_GHCziConcziIO_ioManagerCapabilitiesChanged_closure, > + > DLL_IMPORT_DATA_REF(base_GHCziConcziIO_ioManagerCapabilitiesChanged_closure), > NULL); > Shouldn't this use the new #define you added to Prelude.h just above? This bit in rts\Win32\ThrIOManager.c should also use the Prelude.h macro: #if defined(COMPILING_WINDOWS_DLL) # if defined(x86_64_HOST_ARCH) rts_evalIO(&cap,__imp_base_GHCziConcziIO_ensureIOManagerIsRunning_closure,NULL); # else rts_evalIO(&cap,_imp__base_GHCziConcziIO_ensureIOManagerIsRunning_closure,NULL); # endif #else rts_evalIO(&cap,&base_GHCziConcziIO_ensureIOManagerIsRunning_closure,NULL); #endif Bill

2 1

validate failure due to haddock
by Andreas Voellmy 16 Feb '13

16 Feb '13

Hi, I just ran ./sync-all pull and ran validate on Linux. I got the following error, apparently due to something missing in haddock: "/home/andi/temp/ghc-build/inplace/bin/haddock" --odir="libraries/ghc-prim/dist-install/doc/html/ghc-prim" --no-tmp-comp-dir --dump-interface=libraries/ghc-prim/dist-install/doc/html/ghc-prim/ghc-prim.haddock --html --hoogle --title="ghc-prim-0.3.1.0: GHC primitives" --prologue="libraries/ghc-prim/dist-install/haddock-prologue.txt" --optghc=-static --optghc=-H32m --optghc=-O --optghc=-Werror --optghc=-Wall --optghc=-H64m --optghc=-O0 --optghc=-package-name --optghc=ghc-prim-0.3.1.0 --optghc=-hide-all-packages --optghc=-i --optghc=-ilibraries/ghc-prim/. --optghc=-ilibraries/ghc-prim/dist-install/build --optghc=-ilibraries/ghc-prim/dist-install/build/autogen --optghc=-Ilibraries/ghc-prim/dist-install/build --optghc=-Ilibraries/ghc-prim/dist-install/build/autogen --optghc=-Ilibraries/ghc-prim/. --optghc=-optP-include --optghc=-optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h --optghc=-package --optghc=rts-1.0 --optghc=-package-name --optghc=ghc-prim --optghc=-XHaskell98 --optghc=-XCPP --optghc=-XMagicHash --optghc=-XForeignFunctionInterface --optghc=-XUnliftedFFITypes --optghc=-XUnboxedTuples --optghc=-XEmptyDataDecls --optghc=-XNoImplicitPrelude --optghc=-O2 --optghc=-O --optghc=-dcore-lint --optghc=-fno-warn-deprecated-flags --optghc=-no-user-package-db --optghc=-rtsopts --optghc=-odir --optghc=libraries/ghc-prim/dist-install/build --optghc=-hidir --optghc=libraries/ghc-prim/dist-install/build --optghc=-stubdir --optghc=libraries/ghc-prim/dist-install/build --optghc=-hisuf --optghc=hi --optghc=-osuf --optghc=o --optghc=-hcsuf --optghc=hc libraries/ghc-prim/./GHC/Classes.hs libraries/ghc-prim/./GHC/CString.hs libraries/ghc-prim/./GHC/Debug.hs libraries/ghc-prim/./GHC/Magic.hs libraries/ghc-prim/dist-install/build/GHC/PrimopWrappers.hs libraries/ghc-prim/./GHC/IntWord64.hs libraries/ghc-prim/./GHC/Tuple.hs libraries/ghc-prim/./GHC/Types.hs libraries/ghc-prim/dist-install/build/autogen/GHC/Prim.hs +RTS -tlibraries/ghc-prim/dist-install/doc/html/ghc-prim/ghc-prim.haddock.t --machine-readable Haddock coverage: 100% ( 1 / 1) in 'GHC.IntWord64' 78% ( 7 / 9) in 'GHC.Types' 17% ( 1 / 6) in 'GHC.CString' 3% ( 2 / 63) in 'GHC.Tuple' 0% ( 0 / 3) in 'GHC.Debug' 0% ( 0 /338) in 'GHC.PrimopWrappers' 30% (160 /527) in 'GHC.Prim' 100% ( 3 / 3) in 'GHC.Magic' 38% ( 6 / 16) in 'GHC.Classes' haddock: internal error: /home/andi/temp/ghc-build/inplace/lib/html/Ocean.std-theme/ocean.css: copyFile: does not exist (No such file or directory) make[1]: *** [libraries/ghc-prim/dist-install/doc/html/ghc-prim/ghc-prim.haddock] Error 1 make[1]: *** Deleting file `libraries/ghc-prim/dist-install/doc/html/ghc-prim/ghc-prim.haddock' make[1]: *** Waiting for unfinished jobs.... make: *** [all] Error 2 -Andi

1 0

Re: Heads-up: new parallel I/O manager merged
by Bill Tutt 16 Feb '13

16 Feb '13

Yes, it should. Here's the combined patch that just succeded in being built. Bill On Sat, Feb 16, 2013 at 11:26 AM, Andreas Voellmy <andreas.voellmy(a)gmail.com > wrote: > > > in rts/ThrIOManager.hs >> > > Sorry, this should have been rts/win32/ThrIOManager.c. >

1 0

Re: [commit: ghc] master: Find LLVM tools when version number at end (e.g., llc-3.0) (#7661) (64aaaa1)
by Ian Lynagh 16 Feb '13

16 Feb '13

On Wed, Feb 13, 2013 at 07:11:11PM -0800, David Terei wrote: > > +AC_DEFUN([FIND_LLVM_PROG],[ > + FP_ARG_WITH_PATH_GNU_PROG_OPTIONAL([$1], [$2], [$3]) > + if test "$1" == ""; then > + GOOD_PATH=`echo $PATH | tr ':,;' ' '` Hmm. I don't think we'll ever have a $PATH containing a path like c:/..., but there could certainly be paths containing spaces. > + $1=`${FindCmd} ${GOOD_PATH} -type f -perm +111 -maxdepth 1 -regex '.*/$3-[[0-9]]\.[[0-9]]' | ${SortCmd} -n | tail -1` This feels rather unpleasant to me. Is it likely that someone will have programs called llc-3.0 etc, but no llc? If not, I'd suggest that we just detect llc and they can override which llc gets used with a --with-llc flag if they want to. In fact, i think we should do that regardless. After all, we don't try searching for gcc-4.6 etc either. Thanks Ian

2 1

GHC failing to build due to errors in DPH?
by Iavor Diatchki 15 Feb '13

15 Feb '13

Hello, I am trying to build GHC head and get the following error: libraries/dph/dph-lifted-base/Data/Array/Parallel/PArray/Reference.hs:50:11: Ambiguous occurrence `fromList' It could refer to either `Data.Array.Parallel.PArray.Reference.fromList', defined at libraries/dph/dph-lifted-base/Data/Array This is using the stage 2 compiler and, I am guessing, is due to an interaction with the overloaded lists extension. I just deleted dph completely, and used `sync-all get` to get a fresh copy, but I get the same error. It looks like the nightly builds are working, so am I doing something wrong? More generally, I don't really need DPH, so is there an easy way to disable building it? -Iavor

5 4

RE: GHC failing to build due to errors in DPH?
by Simon Peyton-Jones 15 Feb '13

15 Feb '13

Sorry about that... I don’t know haw my validate worked. Anyway all good. Simon From: Ian Lynagh Sent: ‎15‎ ‎February‎ ‎2013 ‎20‎:‎10 To: Iavor Diatchki CC: ghc-devs(a)haskell.org Subject: Re: GHC failing to build due to errors in DPH? On Fri, Feb 15, 2013 at 11:09:33AM -0800, Iavor Diatchki wrote: > > I am trying to build GHC head and get the following error: > > libraries/dph/dph-lifted-base/Data/Array/Parallel/PArray/Reference.hs:50:11: > Ambiguous occurrence `fromList' > It could refer to either > `Data.Array.Parallel.PArray.Reference.fromList', > defined at > libraries/dph/dph-lifted-base/Data/Array I've just pushed a fix for this. Thanks Ian _______________________________________________ ghc-devs mailing list ghc-devs(a)haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

1 0

RE: OverloadedLists
by Simon Peyton-Jones 15 Feb '13

15 Feb '13

| Finally I managed to build again (don't know what's wrong with my | system, I built on a virtual machine instead now), and the tests pass. I | attached the four patches, they were created with git diff --no-prefix, | and their name specifies the submodule they are to be applied to. I hope | it isn't to late to include them in 7.8. Should I publish them somewhere | else also, or is this fine? Great. It's done! Thanks for all your work on this. Would you like to update the wiki page? http://hackage.haskell.org/trac/ghc/wiki/OverloadedLists You probably don't want to mention your repo any more; and please just check the rest to make sure it's accurate. I did quite a bit of refactoring, especially to the type checking of arithmetic sequences, which had lots of duplication; fixed the documentation which was out of date; fixed various error message changes in the main testsuite; and committed. Simon commit 3234a4ade7204c4206831b4c1dc4a8b23624cc6b Author: Simon Peyton Jones <simonpj(a)microsoft.com> Date: Thu Feb 14 13:04:14 2013 +0000 Add OverloadedLists, allowing list syntax to be overloaded This work was all done by Achim Krause <achim.t.krause(a)gmail.com> George Giorgidze <giorgidze(a)gmail.com> Weijers Jeroen <jeroen.weijers(a)uni-tuebingen.de> It allows list syntax, such as [a,b], [a..b] and so on, to be overloaded so that it works for a variety of types. The design is described here: http://hackage.haskell.org/trac/ghc/wiki/OverloadedLists Eg. you can use it for maps, so that [(1,"foo"), (4,"bar")] :: Map Int String The main changes * The ExplicitList constructor of HsExpr gets witness field * Ditto ArithSeq constructor * Ditto the ListPat constructor of HsPat Everything else flows from this. compiler/deSugar/Check.lhs | 15 ++-- compiler/deSugar/Coverage.lhs | 16 +++- compiler/deSugar/DsArrows.lhs | 2 +- compiler/deSugar/DsExpr.lhs | 42 +++++++---- compiler/deSugar/DsMeta.hs | 7 +- compiler/deSugar/Match.lhs | 31 ++++++-- compiler/hsSyn/Convert.lhs | 6 +- compiler/hsSyn/HsExpr.lhs | 12 ++- compiler/hsSyn/HsPat.lhs | 12 ++- compiler/hsSyn/HsUtils.lhs | 6 +- compiler/main/DynFlags.hs | 2 + compiler/parser/Parser.y.pp | 12 ++-- compiler/parser/RdrHsSyn.lhs | 4 +- compiler/prelude/PrelNames.lhs | 26 ++++++- compiler/prelude/TysWiredIn.lhs | 2 +- compiler/rename/RnEnv.lhs | 18 +++-- compiler/rename/RnExpr.lhs | 45 +++++++---- compiler/rename/RnPat.lhs | 21 ++++- compiler/typecheck/TcExpr.lhs | 111 ++++++++++++++++---------- compiler/typecheck/TcHsSyn.lhs | 30 ++++++-- compiler/typecheck/TcHsType.lhs | 2 +- compiler/typecheck/TcPat.lhs | 14 +++- compiler/typecheck/TcRnDriver.lhs | 2 +- compiler/typecheck/TcRnTypes.lhs | 2 + compiler/utils/Outputable.lhs | 4 +- docs/users_guide/flags.xml | 7 ++ docs/users_guide/glasgow_exts.xml | 157 +++++++++++++++++++++++++++++++++++++ 27 files changed, 469 insertions(+), 139 deletions(-)

4 5

Re: [commit: ghc] master: Find LLVM tools when version number at end (e.g., llc-3.0) (#7661) (64aaaa1)
by Ian Lynagh 15 Feb '13

15 Feb '13

On Fri, Feb 15, 2013 at 07:21:54PM +0100, Karel Gardas wrote: > On 02/15/13 07:03 PM, Ian Lynagh wrote: > >>+ $1=`${FindCmd} ${GOOD_PATH} -type f -perm +111 -maxdepth 1 -regex '.*/$3-[[0-9]]\.[[0-9]]' | ${SortCmd} -n | tail -1` > > > >This feels rather unpleasant to me. Is it likely that someone will have > >programs called llc-3.0 etc, but no llc? > > Yes, Ubuntu 12.04 LTS installs LLVM 3.0 package in a way that, the > package binaries are installed into /usr/lib/llvm-3.0 directory and > inside /usr/bin there are llc-3.0 and opt-3.0 links created linking > to ../lib/llvm-3.0/bin/{llc|opt}. > > So David is fixing real-world issue here. But if you install 'llvm' (rather than 'llvm-3.0') then you get a /usr/bin/llc Analogously, on ubuntu, if you install 'gcc' then you get /usr/bin/gcc, but if you install 'gcc-4.6' then you get /usr/bin/gcc-4.6; but we don't search for gcc-* executables. Thanks Ian

2 1

Re: [commit: ghc] simd: Fixup stack spills when generating AVX instructions. (b787b5d)
by David Terei 15 Feb '13

15 Feb '13

Do we have a longer term solution for this? I love the SIMD work, so please don't take this as a complaint, I agree with getting it done for now with the mangler and truth is it's doubtful we'll et around to adding TNTC support to LLVM anytime soon, so mangler is here to stay for now. BUT. I would like to see some thought about how in an ideal world with lots of free time to hack on GHC we'd kill the mangler. Do we know that plan for this patch? If so it may be nice to document it somewhere and perhaps create a trac ticket. On 14 February 2013 23:16, Geoffrey Mainland <gmainlan(a)microsoft.com> wrote: > Repository : ssh://darcs.haskell.org//srv/darcs/ghc > > On branch : simd > > http://hackage.haskell.org/trac/ghc/changeset/b787b5d1e687fb28643cdd6a847cc… > >>--------------------------------------------------------------- > > commit b787b5d1e687fb28643cdd6a847ccc26bb014a79 > Author: Geoffrey Mainland <gmainlan(a)microsoft.com> > Date: Sat Nov 26 12:45:23 2011 +0000 > > Fixup stack spills when generating AVX instructions. > > LLVM uses aligned AVX moves to spill values onto the stack, which requires > 32-bye aligned stacks. Since the stack in only 16-byte aligned, LLVM inserts > extra instructions that munge the stack pointer. This is very very bad for the > GHC calling convention, so we tell LLVM to assume the stack is 32-byte > aligned. This patch rewrites the spill instructions that LLVM generates so they > do not require an aligned stack. > >>--------------------------------------------------------------- > > compiler/llvmGen/LlvmMangler.hs | 38 ++++++++++++++++++++++++++++++++++++++ > 1 files changed, 38 insertions(+), 0 deletions(-) > > diff --git a/compiler/llvmGen/LlvmMangler.hs b/compiler/llvmGen/LlvmMangler.hs > index 83a2be7..745dcc6 100644 > --- a/compiler/llvmGen/LlvmMangler.hs > +++ b/compiler/llvmGen/LlvmMangler.hs > @@ -20,6 +20,10 @@ import System.IO > import Data.List ( sortBy ) > import Data.Function ( on ) > > +#if x86_64_TARGET_ARCH > +#define REWRITE_AVX > +#endif > + > -- Magic Strings > secStmt, infoSec, newLine, textStmt, dataStmt, syntaxUnified :: B.ByteString > secStmt = B.pack "\t.section\t" > @@ -47,6 +51,7 @@ llvmFixupAsm dflags f1 f2 = {-# SCC "llvm_mangler" #-} do > w <- openBinaryFile f2 WriteMode > ss <- readSections r w > hClose r > + let fixed = (map rewriteAVX . fixTables) ss > let fixed = fixTables ss > mapM_ (writeSection w) fixed > hClose w > @@ -90,6 +95,39 @@ writeSection w (hdr, cts) = do > B.hPutStrLn w hdr > B.hPutStrLn w cts > > +#if REWRITE_AVX > +rewriteAVX :: Section -> Section > +rewriteAVX = rewriteVmovaps . rewriteVmovdqa > + > +rewriteVmovdqa :: Section -> Section > +rewriteVmovdqa = rewriteInstructions vmovdqa vmovdqu > + where > + vmovdqa, vmovdqu :: B.ByteString > + vmovdqa = B.pack "vmovdqa" > + vmovdqu = B.pack "vmovdqu" > + > +rewriteVmovap :: Section -> Section > +rewriteVmovap = rewriteInstructions vmovap vmovup > + where > + vmovap, vmovup :: B.ByteString > + vmovap = B.pack "vmovap" > + vmovup = B.pack "vmovup" > + > +rewriteInstructions :: B.ByteString -> B.ByteString -> Section -> Section > +rewriteInstructions matchBS replaceBS (hdr, cts) = > + (hdr, loop cts) > + where > + loop :: B.ByteString -> B.ByteString > + loop cts = > + case B.breakSubstring cts matchBS of > + (hd,tl) | B.null tl -> hd > + | otherwise -> hd `B.append` replaceBS `B.append` > + loop (B.drop (B.length matchBS) tl) > +#else /* !REWRITE_AVX */ > +rewriteAVX :: Section -> Section > +rewriteAVX = id > +#endif /* !REWRITE_SSE */ > + > -- | Reorder and convert sections so info tables end up next to the > -- code. Also does stack fixups. > fixTables :: [Section] -> [Section] > > > > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits

2 2

Advice needed: programmatically generating primops?
by Geoffrey Mainland 15 Feb '13

15 Feb '13

Hi All, There is a huge amount of boilerplate involved in adding a full complement of vector primops to GHC. I would like to reduce this boilerplate by programmatically generating the vector primops. My plan is to add utils/genvecprimops and #include its output into primops.txt.pp. Does this sound reasonable? Any objections? While I'm at it, is there any related cleanup I could undertake? Thanks, Geoff

5 6

Re: takeOneMVar?
by Alexander Kjeldaas 15 Feb '13

15 Feb '13

On Fri, Feb 15, 2013 at 8:54 AM, Edward Z. Yang <ezyang(a)mit.edu> wrote: > Apologies for the kibitzing. > > If anyone, it's me proposing weird stuff :-) > > -- This will fail if the MVarGroup is not associated with the current > > process (if the MVarGroup's TSO is not the current TSO)! > > I'm not super keen about this requirement. What if I want to create an > MVarGroup > but pass it to another thread? > > Our emails crossed each other :-). As you can see, I think this is solvable. Alexander > Edward >

2 2

takeOneMVar?
by Alexander Kjeldaas 15 Feb '13

15 Feb '13

Hi, I ended up staring at the PrimOps.cmm file today, and porting tryPutMVar to C so it can be used from the RTS. During my staring, it occurred to me that it should be possible to implement a wait-on-multiple MVars with mostly no overhead. I am guessing that this would be desirable, but I am not sure. My rough idea is like this: -- wait for all MVars, return the value of one of them, and the corresponding index takeOneMVar :: [MVar a] -> IO (a, Int) This is implemented by this change: typedef struct StgMVarTSOQueue_ { StgHeader header; struct StgMVarTSOQueue_ *link; * // The group_head and group_link are used when a TSO is waiting on* * // multiple MVars. Multiple StgMVarTSOQueue objects* * // are created, one for each MVar, and they are linked using the* * // group_link pointer. group_head always points to the first* * // element. The tso pointer will always be the same in this case.* * // The group head acts as a synchronization element for the whole group.* * // When the group head lock is acquired, the owner can invalidate the group* * struct StgMVarTSOQueue *group_head;* * struct StgMVarTSOQueue *group_link;* struct StgTSO_ *tso; } StgMVarTSOQueue; Now, whenever a TSO should be woken up by the MVar code, if ... putMVar(...) { ... queue = mvar->queue... loop: if (end_of_queue(queue) { return 0; } * if (marked_as_invalid(queue) { // invalid = (queue->group_head == NULL) for example* * queue = queue->link;* * goto loop;* * }* * if (queue->group_head != queue) {* * // Try to win race to wake up the TSO with *our* MVar. * * won = TryLock(queue->group_head);* * if (!won) {* * // ignore this queue element for now, we can't get the lock, * * // and it will be marked_as_invalid at some point in the future anyways.* * queue = queue->link;* * goto loop; // try next* * }* * if (won) {* * for all in group, mark them as "invalid"* * Unlock(queue->group_head);* * goto wake_up_tso;* * } else { * * // Did not win* * goto loop;* * }* } else { ..what is currently done.. wake_up_tso: ... do wake up Alexander

2 3

Re: [commit: ghc] master: Add OverloadedLists, allowing list syntax to be overloaded (3234a4a)
by Johan Tibell 14 Feb '13

14 Feb '13

Did we end up supporting a length hint so we can efficiently create e.g. vectors that need upfront allocation of the space before writing the elements? Or is the plan to do like we for String and have literals desugar to e.g. fromIntList# :: Int# -> Ptr Int# -> [Int] intList# :: Ptr Int# intList# = [1,2,3,4]# myliteral = fromList (fromIntList# 4 intList#) On Thu, Feb 14, 2013 at 6:56 AM, Simon Peyton Jones <simonpj(a)microsoft.com>wrote: > Repository : ssh://darcs.haskell.org//srv/darcs/ghc > > On branch : master > > > http://hackage.haskell.org/trac/ghc/changeset/3234a4ade7204c4206831b4c1dc4a… > > >--------------------------------------------------------------- > > commit 3234a4ade7204c4206831b4c1dc4a8b23624cc6b > Author: Simon Peyton Jones <simonpj(a)microsoft.com> > Date: Thu Feb 14 13:04:14 2013 +0000 > > Add OverloadedLists, allowing list syntax to be overloaded > > This work was all done by > Achim Krause <achim.t.krause(a)gmail.com> > George Giorgidze <giorgidze(a)gmail.com> > Weijers Jeroen <jeroen.weijers(a)uni-tuebingen.de> > > It allows list syntax, such as [a,b], [a..b] and so on, to be > overloaded so that it works for a variety of types. > > The design is described here: > http://hackage.haskell.org/trac/ghc/wiki/OverloadedLists > > Eg. you can use it for maps, so that > [(1,"foo"), (4,"bar")] :: Map Int String > > The main changes > * The ExplicitList constructor of HsExpr gets witness field > * Ditto ArithSeq constructor > * Ditto the ListPat constructor of HsPat > > Everything else flows from this. > > compiler/deSugar/Check.lhs | 15 ++-- > compiler/deSugar/Coverage.lhs | 16 +++- > compiler/deSugar/DsArrows.lhs | 2 +- > compiler/deSugar/DsExpr.lhs | 42 +++++++---- > compiler/deSugar/DsMeta.hs | 7 +- > compiler/deSugar/Match.lhs | 31 ++++++-- > compiler/hsSyn/Convert.lhs | 6 +- > compiler/hsSyn/HsExpr.lhs | 12 ++- > compiler/hsSyn/HsPat.lhs | 12 ++- > compiler/hsSyn/HsUtils.lhs | 6 +- > compiler/main/DynFlags.hs | 2 + > compiler/parser/Parser.y.pp | 12 ++-- > compiler/parser/RdrHsSyn.lhs | 4 +- > compiler/prelude/PrelNames.lhs | 26 ++++++- > compiler/prelude/TysWiredIn.lhs | 2 +- > compiler/rename/RnEnv.lhs | 18 +++-- > compiler/rename/RnExpr.lhs | 45 +++++++---- > compiler/rename/RnPat.lhs | 21 ++++- > compiler/typecheck/TcExpr.lhs | 111 ++++++++++++++++---------- > compiler/typecheck/TcHsSyn.lhs | 30 ++++++-- > compiler/typecheck/TcHsType.lhs | 2 +- > compiler/typecheck/TcPat.lhs | 14 +++- > compiler/typecheck/TcRnDriver.lhs | 2 +- > compiler/typecheck/TcRnTypes.lhs | 2 + > compiler/utils/Outputable.lhs | 4 +- > docs/users_guide/flags.xml | 7 ++ > docs/users_guide/glasgow_exts.xml | 157 > +++++++++++++++++++++++++++++++++++++ > 27 files changed, 469 insertions(+), 139 deletions(-) > > > Diff suppressed because of size. To see it, use: > > git show 3234a4ade7204c4206831b4c1dc4a8b23624cc6b > > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits >

2 1

Today's validate failures
by Simon Marlow 14 Feb '13

14 Feb '13

On x86_64/Linux: Unexpected passes: perf/should_run T149 (normal) Unexpected failures: perf/compiler T3064 [stat too good] (normal) perf/haddock haddock.Cabal [stat not good enough] (normal) perf/haddock haddock.base [stat not good enough] (normal) simplCore/should_compile T3717 [stderr mismatch] (optasm) simplCore/should_compile T3772 [bad stdout] (normal) simplCore/should_compile T4908 [stderr mismatch] (optasm) simplCore/should_compile T4930 [stderr mismatch] (optasm) simplCore/should_compile T7360 [stderr mismatch] (optasm) simplCore/should_compile spec-inline [stderr mismatch] (optasm)

3 2

Why write out-of-line PrimOps in Cmm?
by Alexander Kjeldaas 14 Feb '13

14 Feb '13

I was looking at the eventlog code, and I wanted to move processing of a full eventlog buffer into Haskell, instead of the now fixed behavior of writing the data to a file. To do this, I though that having a haskell process blocked on an MVar, or Chan would be nice, and then some way to signal the process. But the low-level PrimOps for MVars, takeMVar, tryTakeMVar etc are in PrimOps.cmm and I don't know how to call them from the RTS. This lead me to question what the point of out-of-line PrimOps in PrimOps.cmm is. I don't think the commentary covers this. http://hackage.haskell.org/trac/ghc/wiki/Commentary/PrimOps So why aren't all the stuff in PrimOps.cmm just "ccall" wrappers around C implementations? Wouldn't that in general be more flexible for the RTS? Alexander

2 1

Merging polykinded typeable
by José Pedro Magalhães 14 Feb '13

14 Feb '13

Hi Simon, I think the polykinded stuff is now ready to merge. A few issues remain: 1) dynamic004 fails when run without optimisation (it times out). This is potentially worrying. It's doing a comparison of the typeReps of nested lists, up to 1000 nested lists. This worked fine before with -O0, but not anymore. With -O1 it works fine, though. Hopefully it's ok to just run this test with optimisation only, and assume that no one should expect great performance of Typeable on huge types with -O0... 2) With -XAutoDeriveTypeable, if you also derive Typeable instances in the module, you'll get a "duplicate instances" error. I think you'd rather have this be a warning, so that the semantics if -XAutoDeriveTypeable would be "derive Typeable for types/classes for which Typeable is not yet derived", instead of "derive Typeable for all types/classes declared". But I found this a bit tricky to check for, and as such haven't implemented it yet. I can point you to the place in the code where this is happening. 3) I don't know where to put `data Proxy t = Proxy`. I kind of need it for defining things in the library, but it doesn't need to be exported to the user, as we now have `typeRep :: forall proxy. proxy a -> TypeRep`. I do export it from Data.Typeable.Internal, because I want to use it in Data.Typeable, but I don't re-export it from Data.Typeable. This is, in principle, all fine, but I think that the Proxy datatype is so commonplace that it should probably be defined in GHC somewhere, so that it doesn't start showing up repeated in all sorts of libraries. Perhaps we can just put it in GHC.Exts? Either way, I'd like to merge this to the master branch now, and deal with the issues above after that. This is because it's tiresome to keep my branch up-to-date with master, and I don't think the remaining issues are blocking, or will affect the stability of the master branch. Regarding documentation, I've updated the user's guide to mention the new behaviour of Typeable, the fact that you can't define instances by hand, and the new flags (-XAutoDeriveTypeable and -fwarn-typeable-instances). I've written a blog post in the past about the new features ( http://hauptwerk.blogspot.co.uk/2012/11/coming-soon-in-ghc-head-poly-kinded…) and I'll write another one about how to make sure your old Typeable code works in the new version. If you want to have a look at the code before merging, let me know, and I'll update the new-typeable branch. (I've stopped working on that branch, and now I have a local branch ready for merging with a single commit to master). Cheers, Pedro

2 3

Vector primops sizes
by Michael Baikov 14 Feb '13

14 Feb '13

Recently merged vector primops support only 16 bytes operands - Int32 x 4, Double x 2 and so on. Current AVX instructions support 256 bit operands and with simple cut'n'paste work it's possible to support at least Double x 4 operands. I made those changes and GHC generates (using llvm) proper AVX code using ymm registers. Also it might make sense to support primops for vector types larger than any currently supported primitive types - I have those changes in my branch as well and llvm generates pretty good code as well - those changes might be useful to provide access for llvm shufflevector instruction or writing high performance processing of large vectors - with less potential overhead. Do we want to support larger vectors directly or ghc should be made smart enough to fuse operations with vector primops performed in parallel into larger vectors/registers for llvm? Do we want to provide access to llvm shufflevector instruction?

5 7

[PATCH] base: use --target as target, not uname
by Sergei Trofimovich 14 Feb '13

14 Feb '13

From: Sergei Trofimovich <slyfox(a)gentoo.org> Fixed bootstrap failure on linux for --target=mingw32 Signed-off-by: Sergei Trofimovich <slyfox(a)gentoo.org> --- configure.ac | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index b679520..7553a7a 100644 --- a/configure.ac +++ b/configure.ac @@ -5,17 +5,23 @@ AC_CONFIG_SRCDIR([include/HsBase.h]) AC_CONFIG_HEADERS([include/HsBaseConfig.h include/EventConfig.h]) +AC_CANONICAL_BUILD +AC_CANONICAL_HOST +AC_CANONICAL_TARGET + AC_ARG_WITH([cc], [C compiler], [CC=$withval]) AC_PROG_CC() -case `uname -s` in - MINGW*|CYGWIN*) +AC_MSG_CHECKING(for WINDOWS platform) +case $host in + *mingw32*|*cygwin*) WINDOWS=YES;; *) WINDOWS=NO;; esac +AC_MSG_RESULT($WINDOWS) # do we have long longs? AC_CHECK_TYPES([long long]) -- 1.8.1.2

3 4

[PATCH] Fix comment to use correct option name
by shelarcy 14 Feb '13

14 Feb '13

Hello, Source Code Comments decribe wrong (old) option name in two place. I made patch to fix that. Best Regards, -- shelarcy <shelarcy hotmail.co.jp> http://page.freett.com/shelarcy/

2 1

[PATCH] hsc2hs: use configuration of current compiler, not built
by Sergei Trofimovich 13 Feb '13

13 Feb '13

From: Sergei Trofimovich <slyfox(a)gentoo.org> Fixed bootstrap failure on linux for --target=mingw32 of such kind: "/usr/bin/ghc" -o utils/hsc2hs/dist/build/tmp/hsc2hs -static -H32m -O -w -package-db libraries/bootstrapping.conf -hide-all-packages -i -iutils/hsc2hs/. -iutils/hsc2hs/dist/build -iutils/hsc2hs/dist/build/autogen -Iutils/hsc2hs/dist/build -Iutils/hsc2hs/dist/build/autogen -optP-include -optPutils/hsc2hs/dist/build/autogen/cabal_macros.h -package base-4.6.0.0 -package containers-0.5.0.0 -package directory-1.2.0.0 -package filepath-1.3.0.1 -package process-1.1.0.2 -XHaskell98 -XCPP -XForeignFunctionInterface -no-user-package-db -rtsopts -odir utils/hsc2hs/dist/build -hidir utils/hsc2hs/dist/build -stubdir utils/hsc2hs/dist/build -hisuf hi -osuf o -hcsuf hc utils/hsc2hs/dist/build/Main.o utils/hsc2hs/dist/build/HSCParser.o utils/hsc2hs/dist/build/DirectCodegen.o utils/hsc2hs/dist/build/CrossCodegen.o utils/hsc2hs/dist/build/UtilsCodegen.o utils/hsc2hs/dist/build/Common.o utils/hsc2hs/dist/build/C.o utils/hsc2hs/dist/build/Flags.o utils/hsc2hs/dist/build/Paths_hsc2hs.o utils/hsc2hs/dist/build/Main.o: In function `s4cN_info': (.text+0x182): undefined reference to `GetModuleFileNameW' Signed-off-by: Sergei Trofimovich <slyfox(a)gentoo.org> --- Main.hs | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Main.hs b/Main.hs index 30b3a2d..5309179 100644 --- a/Main.hs +++ b/Main.hs @@ -11,7 +11,7 @@ -- See the documentation in the Users' Guide for more details. #if defined(__GLASGOW_HASKELL__) && !defined(BUILD_NHC) -#include "../../includes/ghcconfig.h" +#include "ghcconfig.h" #endif import Control.Monad ( liftM, forM_ ) -- 1.8.1.1

2 2

Re: GHC 7.8 release?
by Simon Marlow 13 Feb '13

13 Feb '13

On 13/02/13 07:06, wren ng thornton wrote: > On 2/12/13 3:37 AM, Simon Marlow wrote: >> One reason for the major version bumps is that base is a big >> conglomeration of modules, ranging from those that hardly ever change >> (Prelude) to those that change frequently (GHC.*). For example, the new >> IO manager that is about to get merged in will force a major bump of >> base, because it changes GHC.Event. The unicode support in the IO >> library was similar: although it only added to the external APIs that >> most people use, it also changed stuff inside GHC.* that we expose for a >> few clients. >> >> The solution to this would be to split up base further, but of course >> doing that is itself a major upheaval. However, having done that, it >> might be more feasible to have non-API-breaking releases. > > While it will lead to much wailing and gnashing of teeth in the short > term, if it's feasible to break GHC.* off into its own package, then I > think we should. The vast majority of base seems quite stable or else is > rolling along at a reasonable pace. And yet, every time a new GHC comes > out, there's a new wave of fiddling the knobs on cabal files because > nothing really changed. On the other hand, GHC.* moves rather quickly. > Nevertheless, GHC.* is nice to have around, so we don't want to just > hide that churning. The impedance mismatch here suggests that they > really should be separate packages. I wonder whether GHC.* should be > moved in with ghc-prim, or whether they should remain separate... > > But again, this depends on how feasible it would be to actually split > the packages apart. Is it feasible? So I think we'd need to add another package, call it ghc-base perhaps. The reason is that ghc-prim sits below the integer package (integer-simple or integer-gmp). It's feasible to split base, but to a first approximation what you end up with is base renamed to ghc-base, and then the new base contains just stub modules that re-export stuff from ghc-base. In fact, maybe you want to do it exactly like this for simplicity - all the code goes in ghc-base. There would be some impact on compilation time, as we'd have twice as many interfaces to read. I believe Ian has done some experiments with splitting base further, so he might have more to add here. Cheers, Simon

5 4

Re: [commit: ghc] master: add $(CrossCompilePrefix) to hp2ps (#7639) (b0fad0c)
by Gabor Greif 13 Feb '13

13 Feb '13

Hi Simon, all, this reminds me of a local patch (see below), that allows one to keep different 'build.mk' customizations for cross targets and normal builds at the same time, so the error-prone manual swapping of these is automated. OK to push? Cheers, Gabor ##################################################### [ggreif-hc_stm-r6.0][!1180] git show b716a1132010cccbf87612b4c1b0816c0585eb91 commit b716a1132010cccbf87612b4c1b0816c0585eb91 Author: Gabor Greif <ggreif(a)gmail.com> Date: Fri Nov 23 17:54:00 2012 +0100 allow different customizations per cross target diff --git a/mk/custom-settings.mk b/mk/custom-settings.mk index e64bb36..3390888 100644 --- a/mk/custom-settings.mk +++ b/mk/custom-settings.mk @@ -5,7 +5,7 @@ ifeq "$(Validating)" "YES" include mk/validate-settings.mk -include mk/validate.mk else --include mk/build.mk +-include mk/$(CrossCompilePrefix)build.mk endif ifeq "$(BINDIST)" "YES" On 2/1/13, Simon Marlow <marlowsd(a)gmail.com> wrote: > Repository : ssh://darcs.haskell.org//srv/darcs/ghc > > On branch : master > > http://hackage.haskell.org/trac/ghc/changeset/b0fad0c580e0dd52d73743a877608… > >>--------------------------------------------------------------- > > commit b0fad0c580e0dd52d73743a877608af60408ec89 > Author: Simon Marlow <marlowsd(a)gmail.com> > Date: Thu Jan 31 12:05:03 2013 +0000 > > add $(CrossCompilePrefix) to hp2ps (#7639) > >>--------------------------------------------------------------- > > utils/hp2ps/ghc.mk | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/utils/hp2ps/ghc.mk b/utils/hp2ps/ghc.mk > index 59791c8..097f912 100644 > --- a/utils/hp2ps/ghc.mk > +++ b/utils/hp2ps/ghc.mk > @@ -16,7 +16,7 @@ utils/hp2ps_dist_C_SRCS = AreaBelow.c Curves.c > Error.c Main.c \ > Axes.c Dimensions.c Key.c PsFile.c > Shade.c \ > Utilities.c > utils/hp2ps_dist_EXTRA_LIBRARIES = m > -utils/hp2ps_dist_PROG = hp2ps$(exeext) > +utils/hp2ps_dist_PROG = $(CrossCompilePrefix)hp2ps$(exeext) > utils/hp2ps_dist_INSTALL = YES > utils/hp2ps_dist_INSTALL_INPLACE = YES > > > > > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits >

2 5

RE: [GHC] #7631: Allow to differentiate between newtypes and datatypes when using Generics
by Simon Peyton-Jones 13 Feb '13

13 Feb '13

Thanks for fixing Pedro Our usual test-case nomenclature would be to use "T7631" as the test name. Not worth changing now. Simon | -----Original Message----- | From: ghc-tickets-bounces(a)haskell.org [mailto:ghc-tickets-bounces@haskell.org] | On Behalf Of GHC | Sent: 13 February 2013 10:44 | Cc: ghc-tickets(a)haskell.org | Subject: Re: [GHC] #7631: Allow to differentiate between newtypes and | datatypes when using Generics | | #7631: Allow to differentiate between newtypes and datatypes when using | Generics | ---------------------------------+------------------------------------------ | Reporter: Feuerbach | Owner: dreixel | Type: feature request | Status: closed | Priority: normal | Component: libraries (other) | Version: 7.7 | Resolution: fixed | Keywords: generics | Os: Unknown/Multiple | Architecture: Unknown/Multiple | Failure: None/Unknown | Blockedby: | Blocking: | Related: | | ---------------------------------+------------------------------------------ | Changes (by dreixel): | | * status: new => closed | * resolution: => fixed | | | Comment: | | Done. New test is `GenNewtype`. | | -- | Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7631#comment:4> | GHC <http://www.haskell.org/ghc/> | The Glasgow Haskell Compiler | | _______________________________________________ | ghc-tickets mailing list | ghc-tickets(a)haskell.org | http://www.haskell.org/mailman/listinfo/ghc-tickets

1 0

Re: RFC: Singleton equality witnesses
by Gabor Greif 13 Feb '13

13 Feb '13

Richard and all, sorry for reviving such an ancient thread, but I'd like to move this forward a bit :-) In the meantime Iavor has added the (:~:) GADT, so I can reuse it. It has been commented that it could (finally) end up in GHC.Exts, but for now I want my changes minimized. I have added the class @SingEquality@ and have implemented the @sameSing@ method in terms of Iavor's functions. This is rather pretty now. Here is the patch: ------------------------------------------------------ $ git show 0eacf265255b9c5e0191b6a5100f3076b8eb5520 commit 0eacf265255b9c5e0191b6a5100f3076b8eb5520 Author: Gabor Greif <ggreif(a)gmail.com> Date: Fri Nov 30 12:23:28 2012 +0100 Introduce the SingEquality class with customizable witness type and a sameSing method that may produce the latter. diff --git a/GHC/TypeLits.hs b/GHC/TypeLits.hs index f8b759e..5546a5a 100644 --- a/GHC/TypeLits.hs +++ b/GHC/TypeLits.hs @@ -30,7 +30,7 @@ module GHC.TypeLits , type (-) -- * Comparing for equality - , type (:~:) (..), eqSingNat, eqSingSym + , type (:~:) (..), eqSingNat, eqSingSym, SingEquality (..) -- * Destructing type-nat singletons. , isZero, IsZero(..) @@ -56,6 +56,7 @@ import Unsafe.Coerce(unsafeCoerce) -- import Data.Bits(testBit,shiftR) import Data.Maybe(Maybe(..)) import Data.List((++)) +import Control.Monad (guard, return, (>>)) -- | (Kind) A kind useful for passing kinds as parameters. data OfKind (a :: *) = KindParam @@ -133,6 +134,11 @@ class (kparam ~ KindParam) => SingE (kparam :: OfKind k) where type DemoteRep kparam :: * fromSing :: Sing (a :: k) -> DemoteRep kparam +class (kparam ~ KindParam, SingE (kparam :: OfKind k)) => SingEquality (kparam :: OfKind k) where + type SameSing kparam :: k -> k -> * + type SameSing kparam = (:~:) + sameSing :: Sing a -> Sing b -> Maybe (SameSing kparam a b) + instance SingE (KindParam :: OfKind Nat) where type DemoteRep (KindParam :: OfKind Nat) = Integer fromSing (SNat n) = n @@ -141,6 +147,12 @@ instance SingE (KindParam :: OfKind Symbol) where type DemoteRep (KindParam :: OfKind Symbol) = String fromSing (SSym s) = s +instance SingEquality (KindParam :: OfKind Nat) where + sameSing = eqSingNat + +instance SingEquality (KindParam :: OfKind Symbol) where + sameSing = eqSingSym + {- | A convenient name for the type used to representing the values for a particular singleton family. For example, @Demote 2 ~ Integer@, and also @Demote 3 ~ Integer@, but @Demote "Hello" ~ String@. -} ------------------------------------------------------ Regarding Richard's decidable equality suggestion, I think this would be the next step. IIRC, empty case expressions have been implemented, so GHC HEAD should be prepared. What do you think? Okay to push in this form? Cheers, Gabor On 12/5/12, Richard Eisenberg <eir(a)cis.upenn.edu> wrote: > I don't think anything here is *high priority*, just musings on how best to > move forward. > > About empty case, consider this: > >> data a :~: b where >> Refl :: a :~: a >> >> absurd :: True :~: False -> a > > Now, I want to write a term binding for absurd. GHC can figure out that > (True :~: False) is an empty type. So, if we have (absurd x = case x of …), > there are no valid patterns, other than _, that could be used. Instead of > writing (absurd _ = undefined), I would much prefer to write (absurd x = > case x of {}). Why? If I compile with -fwarn-incomplete-patterns and > -Werror, then the latter has no possible source of partiality and yet > compiles. The former looks dangerous, and GHC doesn't check to make sure > that, in fact, the function can never get called. > > The bottom line, for me at least, is that I want to avoid the partial > constructs (incomplete patterns, undefined, etc) in Haskell as much as > possible, especially when I'm leveraging the type system to a high degree. > The lack of empty case statements forces me to use undefined where it isn't > really necessary. > > I'll leave it to others to comment on TypeRep, as I'm a little hazy there > myself. > > Richard > >

5 14

[PATCH] GHC_CONVERT_VENDOR: allow 'w64' vendor, like x86_64-w64-mingw32
by Sergei Trofimovich 12 Feb '13

12 Feb '13

From: Sergei Trofimovich <slyfox(a)gentoo.org> Gentoo calls 'w64' a mingw flavour with mingw-w64 runtime. Signed-off-by: Sergei Trofimovich <slyfox(a)gentoo.org> --- aclocal.m4 | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/aclocal.m4 b/aclocal.m4 index 9f9593a..30d492c 100644 --- a/aclocal.m4 +++ b/aclocal.m4 @@ -1812,7 +1812,7 @@ case "$1" in # converts vendor from gnu to ghc naming, and assigns the result to $target_var AC_DEFUN([GHC_CONVERT_VENDOR],[ case "$1" in - pc|gentoo) # like i686-pc-linux-gnu and i686-gentoo-freebsd8 + pc|gentoo|w64) # like i686-pc-linux-gnu, i686-gentoo-freebsd8, x86_64-w64-mingw32 $2="unknown" ;; softfloat) # like armv5tel-softfloat-linux-gnueabi -- 1.8.1.1

2 1

RE: GHC 7.8 release?
by Simon Peyton-Jones 12 Feb '13

12 Feb '13

(a) There are packages which tend to track GHC's latest version instead of the HP (yesod used to do this, which was a source of much pain). (b) There are linux distributions which always track the latest everything, often in a rolling-release fashion (notably Arch). They are actively hostile to the Platform, and a source of even greater pain. Many package authors update because Arch users demand it and openly insult anyone who points them to the Platform or any policy which suggests that anything other then the absolutely latest version is acceptable. These must be social questions (what I was earlier calling “signposting”) rather than technical ones. For example, you say that (b) is not subject to any variety of reason, and yet no linux distribution tracks HEAD, does it? They don’t openly insult anyone who points to a release just because HEAD has new cool stuff! No, they track things we call “releases”. Very well, maybe we should call them “previews” instead, and only dignify it as a “release” when, and only when a preview is picked by HP as worthy of incorporation in the next HP. Or something. I’m just looking for a way to reconcile · Release early, release often · Stability for the Haskell Platform It seems to me that such a reconciliation is within reach, and is actually very close to what we do, if we only signpost what is what far more vigorously and clearly than we do now. But maybe I’m wrong. Simon From: Brandon Allbery [mailto:allbery.b@gmail.com] Sent: 11 February 2013 01:15 To: Simon Peyton-Jones Cc: Simon Marlow; Mark Lentczner; Manuel M T Chakravarty; kostirya(a)gmail.com; glasgow-haskell-users; ghc-devs(a)haskell.org; Edsko de Vries Subject: Re: GHC 7.8 release? On Sun, Feb 10, 2013 at 4:02 PM, Simon Peyton-Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> wrote: What causes the "wave of package updates"? Just because GHC 7.8 (say) comes out, no package author need lift a finger. The Haskell Platform sets the pace for package updates. When the Haskell Platform comes out, now THAT is indeed a trigger for a wave of updates. Authors of packages in HP are forced to act; authors of other packages want their packages to work with the next HP. (a) There are packages which tend to track GHC's latest version instead of the HP (yesod used to do this, which was a source of much pain). (b) There are linux distributions which always track the latest everything, often in a rolling-release fashion (notably Arch). They are actively hostile to the Platform, and a source of even greater pain. Many package authors update because Arch users demand it and openly insult anyone who points them to the Platform or any policy which suggests that anything other then the absolutely latest version is acceptable. You *might* be able to control expectations with respect to (a); (b) is not subject to any variety of reason. It will produce as much pressure as it has users, plus multiply that pressure by the number of package authors who are also users. -- brandon s allbery kf8nh sine nomine associates allbery.b(a)gmail.com<mailto:allbery.b@gmail.com> ballbery(a)sinenomine.net<mailto:ballbery@sinenomine.net> unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

8 9

RFC: Changes to help GHCJS, GHC API multi-target cross compile
by Luite Stegeman 12 Feb '13

12 Feb '13

Hi all, I'm looking for comments on two minor patches that would greatly help GHCJS [1]. The goal is to make a cabal-installable GHCJS compiler that uses the GHC API to generate both JavaScript (always 32 bit) and native code (to run Template Haskell). This way we can release updates frequently and have an easy installation procedure for users. I have an experimental branch [2] that uses the patches below to make working compiler that can generate 32 bit JavaScript from a 64 bit host compiler, with working TH. 1. Add a Way for custom build tags. Since we generate code for two architectures, we need to make sure that we don't mix the native and JavaScript .hi files. Setting the buildTag manually in DynFlags does not work, because it gets reset every time a file is preprocessed (due to OPTIONS pragma handling). This patch adds an extra Way that just adds something to the build tag, it could be extended to also add custom program options and extras. 2. Make GHC.Prim interface overridable. Since JavaScript does not support 64 bit integers, we want to generate 32 bit code, even if our host platform is 64 bit. HEAD has wORD_SIZE_IN_BITS already configurable though DynFlags, but unfortunately the primop interface (GHC.Prim) is also platform dependent, some primops have a different type on a 64 bit system. This patch makes it possible for a GHC API user to supply a custom interface for GHC.Prim. It's rather hacky, requires an extra hs-boot file and requires the user to mess with the NameCache to make it work correctly [3]. Probably a stopgap measure until GHC supports multitarget cross compilation out of the box. Is there a better way of doing this? Luite [1] https://github.com/ghcjs [2] https://github.com/ghcjs/ghcjs/tree/gen2-64 [3] https://github.com/ghcjs/ghcjs/blob/1a84f82fa149b4e9510586c10864694efe7820b…

2 1

RE: [commit: ghc] master: Fix Trac #7681. (7b098b6)
by Simon Peyton-Jones 12 Feb '13

12 Feb '13

Thanks for fixing. You removed lookupType_mod from TrieMap. It was defined and exported but not called. How did validate spot that? I'm sure there are quite a few such functions in GHC. Simon | -----Original Message----- | From: ghc-commits-bounces(a)haskell.org [mailto:ghc-commits- | bounces(a)haskell.org] On Behalf Of Richard Eisenberg | Sent: 12 February 2013 04:10 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] master: Fix Trac #7681. (7b098b6) | | Repository : ssh://darcs.haskell.org//srv/darcs/ghc | | On branch : master | | http://hackage.haskell.org/trac/ghc/changeset/7b098b6009727a012cb1f3ff0c | a51698d302cae1 | | >--------------------------------------------------------------- | | commit 7b098b6009727a012cb1f3ff0ca51698d302cae1 | Author: Richard Eisenberg <eir(a)cis.upenn.edu> | Date: Mon Feb 11 23:07:25 2013 -0500 | | Fix Trac #7681. | | Removed checks for empty lists for case expressions and lambda-case. | If -XEmptyCase is not enabled, compilation still fails | (appropriately) | in the renamer. | | Had to remove dead code from TrieMap to pass the validator. | | >--------------------------------------------------------------- | | compiler/coreSyn/TrieMap.lhs | 38 +---------------------------------- | --- | compiler/deSugar/DsMeta.hs | 6 ++++-- | compiler/hsSyn/Convert.lhs | 8 ++------ | libraries/random | 2 +- | 4 files changed, 8 insertions(+), 46 deletions(-) | | diff --git a/compiler/coreSyn/TrieMap.lhs b/compiler/coreSyn/TrieMap.lhs | index 148464b..c013b5d 100644 | --- a/compiler/coreSyn/TrieMap.lhs | +++ b/compiler/coreSyn/TrieMap.lhs | @@ -14,7 +14,7 @@ | {-# LANGUAGE TypeFamilies #-} | module TrieMap( | CoreMap, emptyCoreMap, extendCoreMap, lookupCoreMap, foldCoreMap, | - TypeMap, foldTypeMap, lookupTypeMap_mod, | + TypeMap, foldTypeMap, -- lookupTypeMap_mod, | CoercionMap, | MaybeMap, | ListMap, | @@ -32,8 +32,6 @@ import UniqFM | import Unique( Unique ) | import FastString(FastString) | | -import Unify ( niFixTvSubst ) | - | import qualified Data.Map as Map | import qualified Data.IntMap as IntMap | import VarEnv | @@ -632,40 +630,6 @@ lkT env ty m | go (ForAllTy tv ty) = tm_forall >.> lkT (extendCME env tv) ty >=> | lkBndr env tv | | | -lkT_mod :: CmEnv | - -> TyVarEnv Type -- TvSubstEnv | - -> Type | - -> TypeMap b -> Maybe b | -lkT_mod env s ty m | - | EmptyTM <- m = Nothing | - | Just ty' <- coreView ty | - = lkT_mod env s ty' m | - | [] <- candidates | - = go env s ty m | - | otherwise | - = Just $ snd (head candidates) -- Yikes! | - where | - -- Hopefully intersects is much smaller than traversing the whole | vm_fvar | - intersects = eltsUFM $ | - intersectUFM_C (,) s (vm_fvar $ tm_var m) | - candidates = [ (u,ct) | (u,ct) <- intersects | - , Type.substTy (niFixTvSubst s) u `eqType` ty | ] | - | - go env _s (TyVarTy v) = tm_var >.> lkVar env v | - go env s (AppTy t1 t2) = tm_app >.> lkT_mod env s t1 >=> | lkT_mod env s t2 | - go env s (FunTy t1 t2) = tm_fun >.> lkT_mod env s t1 >=> | lkT_mod env s t2 | - go env s (TyConApp tc tys) = tm_tc_app >.> lkNamed tc >=> lkList | (lkT_mod env s) tys | - go _env _s (LitTy l) = tm_tylit >.> lkTyLit l | - go _env _s (ForAllTy _tv _ty) = const Nothing | - | - {- DV TODO: Add proper lookup for ForAll -} | - | -lookupTypeMap_mod :: TyVarEnv a -- A substitution to be applied to the | /keys/ of type map | - -> (a -> Type) | - -> Type | - -> TypeMap b -> Maybe b | -lookupTypeMap_mod s f = lkT_mod emptyCME (mapVarEnv f s) | - | ----------------- | xtT :: CmEnv -> Type -> XT a -> TypeMap a -> TypeMap a xtT env ty f m | diff --git a/compiler/deSugar/DsMeta.hs b/compiler/deSugar/DsMeta.hs | index 9a9f89d..4f5ba2d 100644 | --- a/compiler/deSugar/DsMeta.hs | +++ b/compiler/deSugar/DsMeta.hs | @@ -920,7 +920,8 @@ repE (HsLit l) = do { a <- repLiteral l; | repLit a } | repE (HsLam (MG { mg_alts = [m] })) = repLambda m repE (HsLamCase _ | (MG { mg_alts = ms })) | = do { ms' <- mapM repMatchTup ms | - ; repLamCase (nonEmptyCoreList ms') } | + ; core_ms <- coreList matchQTyConName ms' | + ; repLamCase core_ms } | repE (HsApp x y) = do {a <- repLE x; b <- repLE y; repApp a b} | | repE (OpApp e1 op _ e2) = | @@ -938,7 +939,8 @@ repE (SectionR x y) = do { a <- repLE x; b <- | repLE y; repSectionR a b } | repE (HsCase e (MG { mg_alts = ms })) | = do { arg <- repLE e | ; ms2 <- mapM repMatchTup ms | - ; repCaseE arg (nonEmptyCoreList ms2) } | + ; core_ms2 <- coreList matchQTyConName | ms2 | + ; repCaseE arg core_ms2 } | repE (HsIf _ x y z) = do | a <- repLE x | b <- repLE y | diff --git a/compiler/hsSyn/Convert.lhs b/compiler/hsSyn/Convert.lhs | index a21caf4..ce15071 100644 | --- a/compiler/hsSyn/Convert.lhs | +++ b/compiler/hsSyn/Convert.lhs | @@ -524,9 +524,7 @@ cvtl e = wrapL (cvt e) | cvt (AppE x y) = do { x' <- cvtl x; y' <- cvtl y; return $ | HsApp x' y' } | cvt (LamE ps e) = do { ps' <- cvtPats ps; e' <- cvtl e | ; return $ HsLam (mkMatchGroup | [mkSimpleMatch ps' e']) } | - cvt (LamCaseE ms) | - | null ms = failWith (ptext (sLit "Lambda-case expression | with no alternatives")) | - | otherwise = do { ms' <- mapM cvtMatch ms | + cvt (LamCaseE ms) = do { ms' <- mapM cvtMatch ms | ; return $ HsLamCase placeHolderType | (mkMatchGroup ms') | } | @@ -543,9 +541,7 @@ cvtl e = wrapL (cvt e) | ; return $ HsMultiIf placeHolderType alts' | } | cvt (LetE ds e) = do { ds' <- cvtLocalDecs (ptext (sLit "a let | expression")) ds | ; e' <- cvtl e; return $ HsLet ds' e' } | - cvt (CaseE e ms) | - | null ms = failWith (ptext (sLit "Case expression with no | alternatives")) | - | otherwise = do { e' <- cvtl e; ms' <- mapM cvtMatch ms | + cvt (CaseE e ms) = do { e' <- cvtl e; ms' <- mapM cvtMatch ms | ; return $ HsCase e' (mkMatchGroup ms') } | cvt (DoE ss) = cvtHsDo DoExpr ss | cvt (CompE ss) = cvtHsDo ListComp ss | diff --git a/libraries/random b/libraries/random index 0531d37..69bfde2 | 160000 | --- a/libraries/random | +++ b/libraries/random | @@ -1 +1 @@ | -Subproject commit 0531d37602d6e7c0b2b5adbf2d5fdd2d01830216 | +Subproject commit 69bfde219bab869729fdbe9c1496371f912bf41e | | | | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | http://www.haskell.org/mailman/listinfo/ghc-commits

2 2

Re: Patch to vector
by José Pedro Magalhães 12 Feb '13

12 Feb '13

Hi Roman, Just to remind you of the patch to vector I've previously sent you. Whenever you can apply it, we can remove the "temporary fix" patch on the GHC copy of the repo. Thanks, Pedro On Wed, Nov 28, 2012 at 3:03 PM, José Pedro Magalhães <jpm(a)cs.uu.nl> wrote: > Hi Roman, > > I'm attaching a patch to the vector package to make it derive Typeable > instances instead of defining them manually. GHC HEAD will soon ignore > handwritten Typeable instances, so this replacement is necessary. > > > Thanks, > Pedro > >

2 1

Missing change?
by Simon Peyton-Jones 12 Feb '13

12 Feb '13

Pedro: did you miss something? This is breaking my build. I have your last patch 12ba4321d34d646cf9040ad12810c4257d26ade9 Simon url = http://darcs.haskell.org/libraries/time.git/ libraries/time/Data/Time/Calendar/Days.hs:30:9: `typeOf' is not a (visible) method of class `Typeable' libraries/time/Data/Time/Calendar/Days.hs:30:32: Not in scope: `mkTyCon' Perhaps you meant `mkTyCon3' (imported from Data.Data)

2 2

nofib regressions in HEAD since 7.6.2 release
by Johan Tibell 12 Feb '13

12 Feb '13

Hi all, I just ran nofib on current HEAD and compared it to 7.6.2 on my 64-bit Linux machine. There are some regressions I think we should look into before a release: -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- anna -0.8% +1.5% 0.08 0.08 +0.0% ansi -0.5% +0.5% 0.00 0.00 +0.0% atom -0.9% -0.0% -3.1% -0.8% +0.0% awards -0.9% +0.1% 0.00 0.00 +0.0% banner +0.1% +2.2% 0.00 0.00 +0.0% bernouilli -0.6% +2.7% 0.12 0.13 +0.0% boyer -0.7% +0.0% 0.03 0.04 +0.0% boyer2 -0.1% +0.0% 0.01 0.01 +0.0% bspt -0.6% -0.0% 0.01 0.02 +0.0% cacheprof -0.9% +6.9% +0.8% +4.0% +0.0% calendar -0.9% +0.1% 0.00 0.00 +0.0% cichelli -0.1% -0.0% 0.06 0.06 +9.4% circsim -0.7% +0.1% +1.6% +7.0% +13.6% clausify -0.8% +0.0% 0.03 0.03 +0.0% comp_lab_zift -0.7% +0.0% 0.14 0.14 -12.5% compress -0.1% +0.0% 0.12 0.13 +0.0% compress2 -0.0% +0.0% 0.12 0.14 +2.3% constraints -0.8% +0.0% -3.3% -0.7% +0.0% cryptarithm1 -0.1% +0.0% +2.1% +4.1% +0.0% cryptarithm2 -0.0% -0.8% 0.01 0.01 +0.0% cse -0.0% -0.0% 0.00 0.00 +0.0% eliza +0.1% +7.7% 0.00 0.00 +0.0% event -0.8% +0.0% 0.09 0.10 -8.7% exp3_8 -0.8% +0.0% 0.15 0.15 +100.0% expert -0.2% +18.4% 0.00 0.00 +0.0% fem +1.5% +0.5% 0.02 0.02 +0.0% fft -0.9% +0.0% 0.02 0.03 +0.0% fft2 +3.7% +31.9% 0.05 0.05 +20.0% fibheaps -1.0% +0.3% 0.03 0.03 +0.0% fish -0.0% -0.0% 0.01 0.01 +0.0% fluid -1.3% +13.0% 0.01 0.01 +0.0% fulsom -0.2% -0.0% 0.19 0.20 +8.3% gamteb -0.7% -0.2% 0.03 0.04 +0.0% gcd -0.8% +0.0% 0.02 0.03 +0.0% gen_regexps +0.0% +2.2% 0.00 0.00 +0.0% genfft -0.8% -0.3% 0.03 0.03 +0.0% gg -0.6% +40.4% 0.01 0.02 +50.0% grep -1.8% +2.3% 0.00 0.00 +0.0% hidden -0.7% +3.5% +4.1% +7.6% +0.0% hpg -1.3% -1.3% 0.05 0.10 +0.0% ida -0.7% -1.0% 0.07 0.08 +11.1% infer -0.9% +0.5% 0.05 0.05 +30.0% integer -0.8% +1.1% +1.1% +2.3% +0.0% integrate -0.9% +56.2% 0.20 0.23 +1.0% kahan -0.9% +144.9% +77.6% +78.4% +0.0% knights -0.1% -0.4% 0.01 0.01 +0.0% lcss -0.7% +0.7% -24.3% -18.4% +1.9% life -0.2% +0.0% 0.16 0.16 +0.0% lift -0.0% +0.1% 0.00 0.00 +0.0% listcompr -0.1% -0.0% 0.06 0.06 +0.0% listcopy -0.1% -0.0% 0.06 0.06 +0.0% maillist +0.0% +1.9% 0.02 0.04 +16.5% mandel -0.8% +0.0% 0.05 0.05 +0.0% mandel2 -0.1% -4.0% 0.00 0.01 +0.0% minimax -0.2% -0.0% 0.00 0.00 +0.0% mkhprog -0.1% +1.1% 0.00 0.00 +0.0% multiplier -1.2% +0.0% 0.07 0.08 +0.0% nucleic2 -3.3% +19.5% 0.05 0.05 +0.0% para -0.0% +25.0% 0.22 0.23 +0.0% paraffins -0.8% +0.0% 0.06 0.08 +7.5% parser -1.3% +22.2% 0.03 0.03 +0.0% parstof -0.5% +4.6% 0.01 0.00 +0.0% pic +0.5% +0.0% 0.00 0.00 +0.0% power -1.0% +0.0% -0.5% +1.0% +0.0% pretty -0.2% +0.0% 0.00 0.00 +0.0% primes -0.8% -0.0% 0.04 0.05 +0.0% primetest -0.7% +0.0% 0.07 0.07 +0.0% prolog -0.2% +16.0% 0.00 0.00 +0.0% puzzle -0.1% -2.1% 0.09 0.10 +0.0% queens -0.8% +0.0% 0.02 0.02 +0.0% reptile -0.8% +0.6% 0.01 0.02 +0.0% rewrite -0.8% +0.7% 0.02 0.02 +0.0% rfib -1.0% +0.4% 0.02 0.02 +0.0% rsa -0.7% +2.5% 0.02 0.02 +0.0% scc -0.1% +0.0% 0.00 0.00 +0.0% sched -0.8% +0.0% 0.01 0.02 +0.0% scs -1.9% +0.8% -5.3% -2.7% +0.0% simple -0.3% -0.0% 0.15 0.16 +6.9% solid -0.7% +0.0% 0.09 0.09 +0.0% sorting +0.0% +55.9% 0.00 0.00 +0.0% sphere -0.9% -1.8% 0.04 0.04 +0.0% symalg -0.8% +0.3% 0.01 0.01 +0.0% tak -0.8% +0.9% 0.01 0.01 +0.0% transform -0.8% +0.0% -3.3% -5.7% +0.0% treejoin +0.1% +109.3% 0.15 0.17 -7.4% typecheck -0.8% +0.0% 0.14 0.15 +0.0% veritas -0.8% +0.0% 0.00 0.00 +0.0% wang -0.9% +0.0% 0.07 0.08 +0.0% wave4main -0.8% +1.8% 0.18 0.19 -7.1% wheel-sieve1 -0.7% +0.0% +0.0% +1.5% -12.5% wheel-sieve2 -0.7% +0.0% 0.11 0.12 +2.1% x2n1 +7.4% +43.3% 0.01 0.01 +200.0% -------------------------------------------------------------------------------- Min -3.3% -4.0% -24.3% -18.4% -12.5% Max +7.4% +144.9% +77.6% +78.4% +200.0% Geometric Mean -0.5% +5.5% +1.8% +4.3% +3.2% I haven't had time to look through the regressions yet, so if someone has time, please grab a benchmark that looks bad and have a look at the Core to see what's going on. I suggest starting with "kahan", which is a relatively simple benchmark. -- Johan

4 14

Re: Patch to time
by José Pedro Magalhães 12 Feb '13

12 Feb '13

Hi Ashley, Just to remind you of the patch to time I've previously sent you. Whenever you can apply it, we can remove the "temporary fix" patch on the GHC copy of the repo. Thanks, Pedro On Wed, Nov 28, 2012 at 3:05 PM, José Pedro Magalhães <jpm(a)cs.uu.nl> wrote: > Hi Ashley, > > I'm attaching a patch to the time package to make it derive Typeable > instances instead of defining them manually. GHC HEAD will soon ignore > handwritten Typeable instances, so this replacement is necessary. > > > Thanks, > Pedro > >

1 0

RE: [commit: vector] master: Implement poly-kinded Typeable (8b27167)
by Simon Peyton-Jones 12 Feb '13

12 Feb '13

Hang on... vector has an upstream repo; see http://hackage.haskell.org/trac/ghc/wiki/Repositories and in particular the "Upstream repo?" bullet. So we may need to do more than push to the mirror? Simon | -----Original Message----- | From: ghc-commits-bounces(a)haskell.org [mailto:ghc-commits- | bounces(a)haskell.org] On Behalf Of José Pedro Magalhães | Sent: 12 February 2013 10:41 | To: ghc-commits(a)haskell.org | Subject: [commit: vector] master: Implement poly-kinded Typeable | (8b27167) | | Repository : ssh://darcs.haskell.org//srv/darcs/packages/vector | | On branch : master | | http://hackage.haskell.org/trac/ghc/changeset/8b271670f79a3b50d7e15ca924 | 878212f042f259 | | >--------------------------------------------------------------- | | commit 8b271670f79a3b50d7e15ca924878212f042f259 | Author: Jose Pedro Magalhaes <jpm(a)cs.ox.ac.uk> | Date: Thu Feb 7 14:00:33 2013 +0000 | | Implement poly-kinded Typeable | | This patch makes the Data.Typeable.Typeable class work with | arguments of any | kind. In particular, this removes the Typeable1..7 class hierarchy, | greatly | simplyfing the whole Typeable story. Also added is the | AutoDeriveTypeable | language extension, which will automatically derive Typeable for all | types and | classes declared in that module. Since there is now no good reason | to give | handwritten instances of the Typeable class, those are ignored (for | backwards | compatibility), and a warning is emitted. | | The old, kind-* Typeable class is now called OldTypeable, and lives | in the | Data.OldTypeable module. It is deprecated, and should be removed in | some future | version of GHC. | | >--------------------------------------------------------------- | | Data/Vector/Generic.hs | 9 +++++++++ | Data/Vector/Unboxed/Base.hs | 14 +++++++++++++- | 2 files changed, 22 insertions(+), 1 deletions(-) | | diff --git a/Data/Vector/Generic.hs b/Data/Vector/Generic.hs index | b8f2e81..f17ff23 100644 | --- a/Data/Vector/Generic.hs | +++ b/Data/Vector/Generic.hs | @@ -194,7 +194,12 @@ import Prelude hiding ( length, null, | showsPrec ) | | import qualified Text.Read as Read | + | +#if __GLASGOW_HASKELL__ >= 707 | +import Data.Typeable ( Typeable, gcast1 ) #else | import Data.Typeable ( Typeable1, gcast1 ) | +#endif | | #include "vector.h" | | @@ -2020,7 +2025,11 @@ mkType :: String -> DataType {-# INLINE mkType | #-} mkType = mkNoRepType | | +#if __GLASGOW_HASKELL__ >= 707 | +dataCast :: (Vector v a, Data a, Typeable v, Typeable t) #else | dataCast :: (Vector v a, Data a, Typeable1 v, Typeable1 t) | +#endif | => (forall d. Data d => c (t d)) -> Maybe (c (v a)) {-# | INLINE dataCast #-} dataCast f = gcast1 f diff --git | a/Data/Vector/Unboxed/Base.hs b/Data/Vector/Unboxed/Base.hs index | 2d9822e..359b001 100644 | --- a/Data/Vector/Unboxed/Base.hs | +++ b/Data/Vector/Unboxed/Base.hs | @@ -1,4 +1,7 @@ | {-# LANGUAGE MultiParamTypeClasses, TypeFamilies, FlexibleContexts #-} | +#if __GLASGOW_HASKELL__ >= 707 | +{-# LANGUAGE DeriveDataTypeable, StandaloneDeriving #-} #endif | {-# OPTIONS_HADDOCK hide #-} | | -- | | @@ -29,6 +32,9 @@ import Data.Word ( Word, Word8, Word16, Word32, Word64 | ) import Data.Int ( Int8, Int16, Int32, Int64 ) import Data.Complex | | +#if __GLASGOW_HASKELL__ >= 707 | +import Data.Typeable ( Typeable ) | +#else | import Data.Typeable ( Typeable1(..), Typeable2(..), mkTyConApp, #if | MIN_VERSION_base(4,4,0) | mkTyCon3 | @@ -36,6 +42,8 @@ import Data.Typeable ( Typeable1(..), Typeable2(..), | mkTyConApp, | mkTyCon | #endif | ) | +#endif | + | import Data.Data ( Data(..) ) | | #include "vector.h" | @@ -53,7 +61,10 @@ class (G.Vector Vector a, M.MVector MVector a) => | Unbox a | -- ----------------- | -- Data and Typeable | -- ----------------- | - | +#if __GLASGOW_HASKELL__ >= 707 | +deriving instance Typeable Vector | +deriving instance Typeable MVector | +#else | #if MIN_VERSION_base(4,4,0) | vectorTyCon = mkTyCon3 "vector" | #else | @@ -65,6 +76,7 @@ instance Typeable1 Vector where | | instance Typeable2 MVector where | typeOf2 _ = mkTyConApp (vectorTyCon "Data.Vector.Unboxed.Mutable" | "MVector") [] | +#endif | | instance (Data a, Unbox a) => Data (Vector a) where | gfoldl = G.gfoldl | | | | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | http://www.haskell.org/mailman/listinfo/ghc-commits

2 1

RE: [commit: base] type-reasoning: Reorganized TypeLits and related files as a strawman proposal. (3b04724)
by Simon Peyton-Jones 12 Feb '13

12 Feb '13

Richard Thanks. I'm content for you, Iavor, Stephanie, Conor, Adam, Pedro, Dimitrios (etc) to figure out what to do here, and merge to HEAD. Simon | -----Original Message----- | From: ghc-commits-bounces(a)haskell.org [mailto:ghc-commits- | bounces(a)haskell.org] On Behalf Of Richard Eisenberg | Sent: 12 February 2013 02:24 | To: ghc-commits(a)haskell.org | Subject: [commit: base] type-reasoning: Reorganized TypeLits and related | files as a strawman proposal. (3b04724) | | Repository : ssh://darcs.haskell.org//srv/darcs/packages/base | | On branch : type-reasoning | | http://hackage.haskell.org/trac/ghc/changeset/3b04724f6060ddde071b41ab9d | d5b73b349bf9a0 | | >--------------------------------------------------------------- | | commit 3b04724f6060ddde071b41ab9dd5b73b349bf9a0 | Author: Richard Eisenberg <eir(a)cis.upenn.edu> | Date: Mon Feb 11 21:21:07 2013 -0500 | | Reorganized TypeLits and related files as a strawman proposal. | | This commit breaks TypeLits up into four new files: | - GHC.TypeEq, which contains definitions relating to (:~:) | - GHC.Singletons, which contains all singletons definitions | that are not specific to type-level literals | - GHC.TypeLits.Internals, which is needed to create an "Unsafe" | module | - GHC.TypeLits.Unsafe, which defines unsafeSingNat and | unsafeSingSymbol. | | These changes are intended purely to provoke discussion, not | properly | as a recommendation of what we should do. | | GHC/Singletons.hs | 109 +++++++++++++++++++++++++ | GHC/TypeEq.hs | 34 ++++++++ | GHC/TypeLits.hs | 198 ++++++++++---------------------------- | ------- | GHC/TypeLits.hs-boot | 10 +++ | GHC/TypeLits/Internals.hs | 17 ++++ | GHC/TypeLits/Unsafe.hs | 17 ++++ | base.cabal | 5 + | 7 files changed, 235 insertions(+), 155 deletions(-) | | | Diff suppressed because of size. To see it, use: | | git show 3b04724f6060ddde071b41ab9dd5b73b349bf9a0 | | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | http://www.haskell.org/mailman/listinfo/ghc-commits

1 0

GHC 7.8 release?
by Simon Peyton-Jones 12 Feb '13

12 Feb '13

Dear GHC users, Carter: Will this RTS update make it into ghc 7.8 update thats coming up in the next monthish? Andreas: We are almost there - we are now trying to sort out a problem on mac os x. It would be helpful to know if there is a cutoff date for getting things into 7.8. Simon, Ian, and I have just been discussing 7.8, and would be interested in what you guys think. At ICFP we speculated that we'd make a release of GHC soon after Christmas to embody tons of stuff that has been included since 7.6, specifically: · major improvements in DPH (vectorisation avoidance, new vectoriser) · type holes · rebindable list syntax · major changes to the type inference engine · type level natural numbers · overlapping type families · the new code generator · support for vector (SSE/AVX) instructions Whenever it comes it would definitely be great to include Andreas & friends' work: · Scheduler changes to the RTS to improve latency The original major reason for proposing a post-Xmas release was to get DPH in a working state out into the wild. However, making a proper release imposes costs on everyone else. Library authors have to scurry around to make their libraries work, etc. Some of the new stuff hasn't been in HEAD for that long, and hence has not been very thoroughly tested. (But of course making a release unleashes a huge wave of testing that doesn't happen otherwise.) So another alternative is to leave it all as HEAD, and wait another few months before making a release. You can still use all the new stuff by compiling HEAD, or grabbing a snapshot distribution. And it makes it hard for the Haskell platform if GHC moves too fast. Many people are still on 7.4. There seem to be pros and cons each way. I don't have a strong opinion. If you have a view, let us know. Simon

18 45

Regression in -fregs-graph
by Johan Tibell 11 Feb '13

11 Feb '13

Hi, Simon M asked me to check if -fregs-graph has regressed in HEAD. It looks like it has: HEAD vs HEAD with -fregs-graph: -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- anna +0.1% +0.0% 0.08 0.08 +0.0% ansi +0.0% +0.0% 0.00 0.00 +0.0% atom +0.0% +0.0% +0.0% -0.8% +0.0% awards -0.0% +0.0% 0.00 0.00 +0.0% banner -0.0% +0.0% 0.00 0.00 +0.0% bernouilli +0.0% +0.0% 0.12 0.12 +0.0% binary-trees +0.0% +0.0% +0.0% +0.0% +0.0% boyer -0.0% +0.0% 0.04 0.04 +0.0% boyer2 -0.0% +0.0% 0.01 0.01 +0.0% bspt -0.0% +0.0% 0.02 0.02 +0.0% cacheprof +0.0% +0.0% -3.1% -3.1% +0.0% calendar -0.0% +0.0% 0.00 0.00 +0.0% cichelli +0.0% +0.0% 0.05 0.05 +3.0% circsim +0.0% +0.0% -0.3% -0.3% +0.0% clausify -0.0% +0.0% 0.03 0.03 +0.0% comp_lab_zift -0.0% +0.0% 0.14 0.14 +0.0% compress +0.0% +0.0% 0.11 0.11 +0.0% compress2 +0.0% +0.0% 0.14 0.14 +0.0% constraints +0.0% +0.0% -1.4% -1.4% +0.0% cryptarithm1 +0.0% +0.0% +1.6% +1.0% +0.0% cryptarithm2 +0.0% +0.0% 0.01 0.01 +0.0% cse +0.0% +0.0% 0.00 0.00 +0.0% eliza -0.0% +0.0% 0.00 0.00 +0.0% event +0.0% +0.0% 0.10 0.10 +0.0% exp3_8 +0.0% +0.0% 0.14 0.14 +0.0% expert +0.0% +0.0% 0.00 0.00 +0.0% fannkuch-redux +0.0% +0.0% +10.6% +10.4% +0.0% fasta -0.0% +0.0% -0.6% -0.6% +0.0% fem +0.0% +0.0% 0.03 0.03 +0.0% fft -0.0% +0.0% 0.03 0.03 +0.0% fft2 +0.0% +0.0% 0.04 0.04 +0.0% fibheaps -0.0% +0.0% 0.03 0.03 +0.0% fish +0.0% +0.0% 0.01 0.01 +0.0% fluid +0.0% +0.0% 0.01 0.01 +0.0% fulsom +0.1% +0.0% -5.9% -5.9% -5.3% gamteb +0.0% +0.0% 0.04 0.04 +0.0% gcd +0.0% +0.0% 0.03 0.03 +0.0% gen_regexps +0.0% +0.0% 0.00 0.00 +0.0% genfft +0.0% +0.0% 0.03 0.03 +0.0% gg +0.0% +0.0% 0.02 0.02 +0.0% grep +0.1% +0.0% 0.00 0.00 +0.0% hidden +0.0% +0.0% +3.4% +2.7% +0.0% hpg +0.0% +0.0% 0.10 0.10 +0.0% ida -0.0% +0.0% 0.06 0.06 +0.0% infer +0.0% +0.0% 0.05 0.05 +0.0% integer -0.0% +0.0% +3.0% +2.9% +0.0% integrate +0.0% +0.0% 0.13 0.13 +0.0% k-nucleotide +0.4% +0.0% +3.4% +3.5% +0.0% kahan +0.0% +0.0% 0.18 0.18 +0.0% knights -0.1% +0.0% 0.01 0.01 +0.0% lcss +0.0% +0.0% +0.7% +0.7% +0.0% life -0.0% +0.0% 0.16 0.16 +0.0% lift +0.0% +0.0% 0.00 0.00 +0.0% listcompr -0.0% +0.0% 0.06 0.06 +0.0% listcopy -0.0% +0.0% 0.06 0.06 +0.0% maillist -0.0% +0.0% 0.04 0.04 -11.2% mandel +0.0% +0.0% 0.05 0.05 +0.0% mandel2 -0.0% +0.0% 0.00 0.00 +0.0% minimax +0.0% +0.0% 0.00 0.00 +0.0% mkhprog +0.0% +0.0% 0.00 0.00 +0.0% multiplier -0.0% +0.0% 0.08 0.08 +0.0% n-body -0.0% +0.0% +28.2% +28.2% +0.0% nucleic2 +0.0% +0.0% 0.05 0.05 +0.0% para -0.1% +0.0% +1.0% +1.0% +0.0% paraffins -0.0% +0.0% 0.08 0.08 +0.0% parser +0.0% +0.0% 0.03 0.03 +0.0% parstof -0.0% +0.0% 0.00 0.00 +0.0% pic -0.0% +0.0% 0.00 0.00 +0.0% pidigits -0.0% +0.0% -0.6% +0.0% +0.0% power +0.0% +0.0% +1.9% +1.9% +0.0% pretty +0.0% +0.0% 0.00 0.00 +0.0% primes -0.0% +0.0% 0.05 0.05 +0.0% primetest -0.0% +0.0% 0.07 0.07 +0.0% prolog +0.0% +0.0% 0.00 0.00 +0.0% puzzle -0.0% +0.0% 0.10 0.10 +0.0% queens +0.0% +0.0% 0.02 0.02 +0.0% reptile +0.0% +0.0% 0.02 0.02 +0.0% reverse-complem -0.0% +0.0% 0.08 0.08 +0.0% rewrite +0.0% +0.0% 0.02 0.02 +0.0% rfib +0.0% +0.0% 0.02 0.02 +0.0% rsa +0.0% +0.0% 0.03 0.03 +0.0% scc -0.0% +0.0% 0.00 0.00 +0.0% sched -0.0% +0.0% 0.02 0.02 +0.0% scs -0.0% +0.0% -1.1% -0.5% +0.0% simple -0.1% +0.0% 0.16 0.16 +0.0% solid -0.0% +0.0% 0.10 0.10 +0.0% sorting -0.0% +0.0% 0.00 0.00 +0.0% spectral-norm -0.0% +0.0% +0.0% +0.0% +0.0% sphere +0.1% +0.0% 0.03 0.03 +0.0% symalg -0.0% +0.0% 0.01 0.01 +0.0% tak +0.0% +0.0% 0.01 0.01 +0.0% transform -0.0% +0.0% +0.0% +0.0% +0.0% treejoin +0.0% +0.0% 0.15 0.15 +0.0% typecheck +0.0% +0.0% 0.15 0.15 +0.0% veritas +0.1% +0.0% 0.00 0.00 +0.0% wang +0.0% +0.0% 0.08 0.08 +0.0% wave4main +0.0% +0.0% 0.19 0.19 +0.0% wheel-sieve1 -0.0% +0.0% -0.8% -0.8% +0.0% wheel-sieve2 -0.0% +0.0% 0.13 0.13 +0.0% x2n1 -0.0% +0.0% 0.01 0.01 +0.0% -------------------------------------------------------------------------------- Min -0.1% +0.0% -5.9% -5.9% -11.2% Max +0.4% +0.0% +28.2% +28.2% +3.0% Geometric Mean +0.0% -0.0% +1.7% +1.7% -0.1% Look at n-body and fannkuch-refux (two of the shootout benchmarks). I know containers uses -fregs-graph, so perhaps those two benchmarks use containers? -- Johan

2 1

RE: GHC 7.8 release?
by Simon Peyton-Jones 10 Feb '13

10 Feb '13

, even a point release (7.6.2 vs. 7.6.1) of ghc tends to be moderately violent with respect to the Platform. Ideally, such a point release should not be difficult to slot in because it should be compatible modulo bug fixes, but with ghc's release strategy nobody has any confidence in it being that simple. Well our clear intention for point releases (7.6.1 to 7.6.1) is that they should break nothing. I am concerned that in your experience point releases are “moderately violent”. We go to some pains to make sure that we don’t break anything. If we don’t succeed on this point-release policy, please do tell us when the release candidate comes out. If we don’t know we are causing pain, we can’t stop inflicting it :-) (Major releases are another matter. There, things are likely to break.) Simon From: Brandon Allbery [mailto:allbery.b@gmail.com] Sent: 09 February 2013 13:41 To: Simon Peyton-Jones Cc: Carter Schonwald; Manuel Chakravarty; parallel-haskell; Mark Lentczner; GHC Users List; ghc-devs(a)haskell.org; Edsko de Vries Subject: Re: GHC 7.8 release? On Sat, Feb 9, 2013 at 6:27 AM, Simon Peyton-Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> wrote: In short, I think we already have the situation that you desire. Perhaps we just need to market it better? Or am I mistaken? Except the current question is about how ghc releases interact with the Platform; this thread was set off by a question about getting 7.6.2 into the next Platform.... And the main issue there is that ghc releases tend to break things and need a lot of testing in general to make it into the Platform; while this would be expected anyway, even a point release (7.6.2 vs. 7.6.1) of ghc tends to be moderately violent with respect to the Platform. Ideally, such a point release should not be difficult to slot in because it should be compatible modulo bug fixes, but with ghc's release strategy nobody has any confidence in it being that simple. -- brandon s allbery kf8nh sine nomine associates allbery.b(a)gmail.com<mailto:allbery.b@gmail.com> ballbery(a)sinenomine.net<mailto:ballbery@sinenomine.net> unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

1 0

Compiling DynFlags is jolly slow
by Ian Lynagh 09 Feb '13

09 Feb '13

On Thu, Jan 31, 2013 at 12:23:02PM -0000, GHC wrote: > > I can't compile `DynFlags` on my 256MB Raspberry Pi. Could we do > something about having less auto-generated code in this module please? > > -- > Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7258#comment:13> The ticket's really about performance problems in the compiler rather than DynFlags in particular, so moving to the list. Even the non-generated code in DynFlags is quite large, and ungainly to edit. What would you think about splitting it up, perhaps moving DumpFlag, GeneralFlag and WarningFlag into separate modules? Ideally each module would also export a [Flag (CmdLineP DynFlags)], which would then be ++ed together in DynFlags, but I'm not sure if that's possible without making the modules mutually recursive. On the other hand, perhaps there's a way to split it up which would remove the need for (some of) the existing import loops; I'm not sure how feasible that is OTTOMH. Thanks Ian

2 2

Re: [commit: testsuite] master: Replace 'if_platform' and 'unless_platform' with 'platform' (22951cd)
by Johan Tibell 09 Feb '13

09 Feb '13

I think you might have missed some cases: ====> Scanning ../../libraries/directory/tests/all.T *** framework failure: found an error while executing ../../libraries/directory/tests/all.T : Traceback (most recent call last): File "../driver/runtests.py", line 251, in <module> execfile(file) File "../../libraries/directory/tests/all.T", line 27, in <module> test('T4113', if_platform('i386-apple-darwin', expect_broken(7604)), compile_and_run, ['']) NameError: name 'if_platform' is not defined ====> Scanning ../../libraries/base/tests/all.T *** framework failure: found an error while executing ../../libraries/base/tests/all.T : Traceback (most recent call last): File "../driver/runtests.py", line 251, in <module> execfile(file) File "../../libraries/base/tests/all.T", line 12, in <module> if_platform('i386-unknown-openbsd', expect_fail), NameError: name 'if_platform' is not defined ====> Scanning ../../libraries/base/tests/IO/all.T *** framework failure: found an error while executing ../../libraries/base/tests/IO/all.T : Traceback (most recent call last): File "../driver/runtests.py", line 251, in <module> execfile(file) File "../../libraries/base/tests/IO/all.T", line 107, in <module> expect_fail_if_windows)), compile_and_run, ['-package unix']) File "/Users/tibbe/src/ghc/testsuite/driver/testlib.py", line 651, in test setup(name, myTestOpts) File "/Users/tibbe/src/ghc/testsuite/driver/testlib.py", line 587, in <lambda> return lambda name, opts, f=f, g=g: _compose(name, opts, f, g) File "/Users/tibbe/src/ghc/testsuite/driver/testlib.py", line 591, in _compose g(name, opts) File "/Users/tibbe/src/ghc/testsuite/driver/testlib.py", line 587, in <lambda> return lambda name, opts, f=f, g=g: _compose(name, opts, f, g) File "/Users/tibbe/src/ghc/testsuite/driver/testlib.py", line 591, in _compose g(name, opts) File "/Users/tibbe/src/ghc/testsuite/driver/testlib.py", line 587, in <lambda> return lambda name, opts, f=f, g=g: _compose(name, opts, f, g) File "/Users/tibbe/src/ghc/testsuite/driver/testlib.py", line 591, in _compose g(name, opts) TypeError: expect_fail_if_windows() takes exactly 1 argument (2 given) ====> Scanning ../../libraries/base/tests/Numeric/all.T *** framework failure: found an error while executing ../../libraries/base/tests/Numeric/all.T : Traceback (most recent call last): File "../driver/runtests.py", line 251, in <module> execfile(file) File "../../libraries/base/tests/Numeric/all.T", line 10, in <module> , if_platform('i386-apple-darwin', expect_broken(2370)) NameError: name 'if_platform' is not defined On Fri, Feb 8, 2013 at 6:19 AM, Ian Lynagh <igloo(a)earth.li> wrote: > Repository : ssh://darcs.haskell.org//srv/darcs/testsuite > > On branch : master > > > http://hackage.haskell.org/trac/ghc/changeset/22951cdab93ab21dab9fe5597954b… > > >--------------------------------------------------------------- > > commit 22951cdab93ab21dab9fe5597954b922c9c89a48 > Author: Ian Lynagh <ian(a)well-typed.com> > Date: Fri Feb 8 00:38:42 2013 +0000 > > Replace 'if_platform' and 'unless_platform' with 'platform' > > >--------------------------------------------------------------- > > driver/testlib.py | 13 ++----------- > tests/codeGen/should_gen_asm/all.T | 6 +++--- > tests/ffi/should_run/all.T | 2 +- > tests/ghci/scripts/all.T | 2 +- > tests/numeric/should_run/all.T | 2 +- > tests/perf/compiler/all.T | 6 +++--- > tests/rts/all.T | 12 ++++++------ > 7 files changed, 17 insertions(+), 26 deletions(-) > > diff --git a/driver/testlib.py b/driver/testlib.py > index 4c9b2c2..aa601f7 100644 > --- a/driver/testlib.py > +++ b/driver/testlib.py > @@ -312,17 +312,8 @@ def when(b, f): > def unless(b, f): > return when(not b, f) > > -def if_platform( plat, f ): > - if config.platform == plat: > - return f > - else: > - return normal > - > -def unless_platform( plat, f ): > - if config.platform != plat: > - return f > - else: > - return normal > +def platform( plat ): > + return config.platform == plat > > def if_os( os, f ): > if config.os == os: > diff --git a/tests/codeGen/should_gen_asm/all.T > b/tests/codeGen/should_gen_asm/all.T > index a24ae31..be30d5f 100644 > --- a/tests/codeGen/should_gen_asm/all.T > +++ b/tests/codeGen/should_gen_asm/all.T > @@ -1,6 +1,6 @@ > test('memcpy', > - unless_platform('x86_64-unknown-linux',skip), compile_cmp_asm, ['']) > + unless(platform('x86_64-unknown-linux'),skip), compile_cmp_asm, ['']) > test('memcpy-unroll', > - unless_platform('x86_64-unknown-linux',skip), compile_cmp_asm, ['']) > + unless(platform('x86_64-unknown-linux'),skip), compile_cmp_asm, ['']) > test('memcpy-unroll-conprop', > - unless_platform('x86_64-unknown-linux',skip), compile_cmp_asm, ['']) > + unless(platform('x86_64-unknown-linux'),skip), compile_cmp_asm, ['']) > diff --git a/tests/ffi/should_run/all.T b/tests/ffi/should_run/all.T > index 1811f42..09e6944 100644 > --- a/tests/ffi/should_run/all.T > +++ b/tests/ffi/should_run/all.T > @@ -33,7 +33,7 @@ test('ffi004', skip, compile_and_run, ['']) > # > test('ffi005', [ omit_ways(prof_ways), > if_arch('i386', skip), > - if_platform('i386-apple-darwin', expect_broken(4105)), > + when(platform('i386-apple-darwin'), expect_broken(4105)), > exit_code(3) ], > compile_and_run, ['']) > > diff --git a/tests/ghci/scripts/all.T b/tests/ghci/scripts/all.T > index f204af7..0b8f62e 100755 > --- a/tests/ghci/scripts/all.T > +++ b/tests/ghci/scripts/all.T > @@ -38,7 +38,7 @@ test('ghci022', normal, ghci_script, ['ghci022.script']) > test('ghci023', normal, ghci_script, ['ghci023.script']) > test('ghci024', > [skip_if_fast, > - if_platform("powerpc-apple-darwin", expect_broken(1845))], > + when(platform("powerpc-apple-darwin"), expect_broken(1845))], > run_command, > ['$MAKE -s --no-print-directory ghci024']) > test('ghci025', normal, ghci_script, ['ghci025.script']) > diff --git a/tests/numeric/should_run/all.T > b/tests/numeric/should_run/all.T > index b2109de..d2f017a 100644 > --- a/tests/numeric/should_run/all.T > +++ b/tests/numeric/should_run/all.T > @@ -7,7 +7,7 @@ test('arith001', normal, compile_and_run, ['']) > test('arith002', normal, compile_and_run, ['']) > test('arith003', normal, compile_and_run, ['']) > test('arith004', normal, compile_and_run, ['']) > -test('arith005', if_platform('i386-apple-darwin', expect_broken_for(7043, > 'ghci')), compile_and_run, ['']) > +test('arith005', when(platform('i386-apple-darwin'), > expect_broken_for(7043, 'ghci')), compile_and_run, ['']) > test('arith006', normal, compile_and_run, ['']) > test('arith007', normal, compile_and_run, ['']) > > diff --git a/tests/perf/compiler/all.T b/tests/perf/compiler/all.T > index 09a0297..1ba4c15 100644 > --- a/tests/perf/compiler/all.T > +++ b/tests/perf/compiler/all.T > @@ -117,7 +117,7 @@ test('T4801', > # 12/11/2012: 49 (amd64/Linux) (REASON UNKNOWN!) > > # expected value: 58 (amd64/OS X): > - if_platform('x86_64-apple-darwin', > + when(platform('x86_64-apple-darwin'), > compiler_stats_range_field('peak_megabytes_allocated', 58, 1)), > # expected value: 228286660 (x86/OS X) > when(wordsize(32), > @@ -130,7 +130,7 @@ test('T4801', > # 19/10/2012: 392409984 (amd64/Linux) (-fPIC turned > off) > > # expected value: 510938976 (amd64/OS X): > - if_platform('x86_64-apple-darwin', > + when(platform('x86_64-apple-darwin'), > compiler_stats_range_field('bytes allocated', 510938976, 5)), > > when(wordsize(32), > @@ -144,7 +144,7 @@ test('T4801', > # 19/10/2012: 26882576 (-fPIC turned on) > # 19/10/2012: 18619912 (-fPIC turned off) > # 24/12/2012: 21657520 (perhaps gc sampling time wibbles?) > - if_platform('x86_64-apple-darwin', > + when(platform('x86_64-apple-darwin'), > compiler_stats_range_field('max_bytes_used', 21657520, 5)), > only_ways(['normal']), > extra_hc_opts('-static') > diff --git a/tests/rts/all.T b/tests/rts/all.T > index 05510e9..380ce85 100644 > --- a/tests/rts/all.T > +++ b/tests/rts/all.T > @@ -9,7 +9,7 @@ test('testblockalloc', compose(c_src, > test('bug1010', normal, compile_and_run, ['+RTS -c -RTS']) > test('derefnull', > composes([ > - if_platform('x86_64-unknown-mingw32', expect_broken(6079)), > + when(platform('x86_64-unknown-mingw32'), > expect_broken(6079)), > # LLVM Optimiser considers dereference of a null pointer > # undefined and marks the code as unreachable which means > # that later optimisations remove it altogether. > @@ -21,13 +21,13 @@ test('derefnull', > # the right exit code we're OK. > if_os('linux', ignore_output), > # SIGBUS on OX X (PPC and x86 only; amd64 gives SEGV) > - if_platform('i386-apple-darwin', exit_code(138)), > - if_platform('powerpc-apple-darwin', exit_code(138)), > + when(platform('i386-apple-darwin'), exit_code(138)), > + when(platform('powerpc-apple-darwin'), exit_code(138)), > if_os('mingw32', exit_code(1))]), > compile_and_run, ['']) > test('divbyzero', > composes([ > - if_platform('x86_64-unknown-mingw32', expect_broken(6079)), > + when(platform('x86_64-unknown-mingw32'), > expect_broken(6079)), > # SIGFPE on Linux > exit_code(136), > # Apparently the output can be different on different > @@ -121,8 +121,8 @@ def config_T5250(name, opts): > > test('T5250', [ config_T5250, > # stack ptr is not 16-byte aligned on 32-bit Windows > - if_platform('i386-unknown-mingw32', expect_fail), > - if_platform('i386-unknown-linux', > + when(platform('i386-unknown-mingw32'), expect_fail), > + when(platform('i386-unknown-linux'), > expect_broken_for(4211,['llvm'])), > extra_clean(['spalign.o']), > omit_ways(['ghci']) ], > > > > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits >

2 1

No instance for (Fractional Int32)
by Gabor Greif 09 Feb '13

09 Feb '13

Hi all, This is what I get while building a cross-ghc: libraries/base/Foreign/C/Types.hs:162:72: No instance for (Fractional Int32) arising from the 'deriving' clause of a data type declaration Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself When deriving the instance for (Fractional CFloat) Has anybody seen this with HEAD? Cheers, Gabor

3 5

Validate failures
by Simon Marlow 09 Feb '13

09 Feb '13

A batch of testsuite failures this morning - forgotten push to testsuite perhaps? Unexpected failures: perf/should_run T5113 [stat not good enough] (normal) simplCore/should_compile T3717 [stderr mismatch] (optasm) simplCore/should_compile T4908 [stderr mismatch] (optasm) simplCore/should_compile T7360 [stderr mismatch] (optasm) simplCore/should_compile spec-inline [stderr mismatch] (optasm) typecheck/should_compile holes [stderr mismatch] (normal) typecheck/should_compile holes2 [stderr mismatch] (normal) typecheck/should_compile holes3 [stderr mismatch] (normal) Cheers, Simon

4 8

Re: nofib regressions in HEAD since 7.6.2 release
by Johan Tibell 08 Feb '13

08 Feb '13

Here are the numbers using -O2. Again on my 64-bit Core i7-3770 @ 3.40GHz, running Linux. 7.6.1 vs HEAD: -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- anna +0.1% -1.5% 0.08 0.08 +0.0% ansi -1.5% -0.4% 0.00 0.00 +0.0% atom -0.4% +0.0% +0.8% +0.8% +0.0% awards -1.0% -0.1% 0.00 0.00 +0.0% banner -2.7% -2.1% 0.00 0.00 +0.0% bernouilli -0.5% -2.6% 0.13 0.13 +0.0% binary-trees +5.6% +0.0% +4.5% +2.8% +8.0% boyer -1.5% -0.0% 0.04 0.04 +0.0% boyer2 -2.8% -0.0% 0.01 0.01 +0.0% bspt -0.4% -0.1% 0.01 0.01 -33.3% cacheprof -0.5% -6.4% +6.6% +0.0% -4.0% calendar -1.3% -0.1% 0.00 0.00 +0.0% cichelli -2.4% +0.0% 0.06 0.06 -5.7% circsim -1.1% -0.1% +6.6% +3.2% +1.0% clausify -1.4% -0.0% 0.03 0.03 +0.0% comp_lab_zift -1.3% -0.0% 0.14 0.14 -12.5% compress -1.3% -0.0% 0.12 0.12 +0.0% compress2 -1.7% -0.0% 0.13 0.14 -2.1% constraints -1.4% -0.0% +4.3% +2.6% +0.0% cryptarithm1 -2.8% +0.0% -0.5% -3.5% +0.0% cryptarithm2 -3.3% +1.0% 0.01 0.01 +0.0% cse -2.7% +0.0% 0.00 0.00 +0.0% eliza -2.6% -7.1% 0.00 0.00 +0.0% event -1.6% -0.0% 0.10 0.10 +9.5% exp3_8 -1.4% -0.0% 0.14 0.14 -50.0% expert -1.8% -15.5% 0.00 0.00 +0.0% fannkuch-redux -0.9% -0.0% -1.7% -2.1% +0.0% fasta -1.5% +8.7% +9.2% -0.6% -50.0% fem -2.1% -0.5% 0.03 0.03 +0.0% fft -0.6% -0.0% 0.03 0.03 +0.0% fft2 -3.5% -24.6% 0.04 0.04 -33.3% fibheaps -1.3% -0.2% 0.03 0.03 +0.0% fish -2.2% +0.0% 0.01 0.01 +0.0% fluid +0.8% -11.9% 0.01 0.01 -50.0% fulsom -0.0% +0.0% 0.20 0.20 -6.2% gamteb -0.8% +0.1% 0.04 0.04 +0.0% gcd -0.6% -0.0% 0.03 0.03 +0.0% gen_regexps -2.7% -2.1% 0.00 0.00 +0.0% genfft -0.9% +0.3% 0.03 0.03 +0.0% gg -0.4% -29.0% 0.02 0.02 +0.0% grep -0.1% -2.3% 0.00 0.00 +0.0% hidden +0.3% -3.4% -6.4% -10.4% +0.0% hpg -0.6% +1.3% 0.10 0.10 +0.0% ida -0.9% +1.0% 0.06 0.06 -20.0% infer -0.8% -0.5% 0.05 0.05 -38.5% integer -0.5% -1.0% -1.9% -2.6% +0.0% integrate +0.6% -36.0% 0.14 -38.2% -2.9% k-nucleotide +7.2% +5.2% +0.5% -0.6% +46.2% kahan -0.5% -99.7% -53.0% -52.8% +0.0% knights -1.7% +0.4% 0.01 0.01 +0.0% lcss -2.0% -0.7% +35.0% +22.7% -3.7% life -2.2% -0.0% 0.16 0.16 +0.0% lift -2.0% -0.1% 0.00 0.00 +0.0% listcompr -2.7% +0.0% 0.06 0.06 +0.0% listcopy -2.7% +0.0% 0.06 0.06 +0.0% maillist -2.7% -0.9% 0.04 0.04 -2.9% mandel +0.8% -0.0% 0.05 0.05 +0.0% mandel2 -2.7% -0.0% 0.00 0.00 +0.0% minimax -2.5% +0.0% 0.00 0.00 +0.0% mkhprog -2.5% -1.1% 0.00 0.00 +0.0% multiplier -1.0% -0.0% 0.08 0.08 +0.0% n-body +5.4% +0.0% -22.3% -23.1% +0.0% nucleic2 +2.2% -16.3% 0.05 0.05 +0.0% para -1.7% -18.5% -8.1% -12.8% +0.0% paraffins -1.4% -0.0% 0.07 0.07 -7.0% parser -1.3% -18.4% 0.03 0.03 +0.0% parstof -1.8% -4.5% 0.00 0.00 +0.0% pic -1.0% -0.0% 0.00 0.00 +0.0% pidigits -0.6% -0.0% +4.8% -2.3% +0.0% power +0.0% -0.0% +2.9% +0.5% +0.0% pretty -1.1% -0.0% 0.00 0.00 +0.0% primes -1.0% +0.0% 0.05 0.05 +0.0% primetest -0.6% -0.0% 0.07 0.07 +0.0% prolog -2.1% -14.0% 0.00 0.00 +0.0% puzzle -2.6% +2.2% 0.10 0.10 +0.0% queens -1.5% -0.0% 0.02 0.02 +0.0% reptile -0.8% -0.8% 0.02 0.02 +0.0% reverse-complem -2.5% +0.0% 0.08 0.08 +0.0% rewrite -1.2% -0.7% 0.02 0.02 +0.0% rfib +1.0% -0.4% 0.02 0.02 +0.0% rsa -0.7% -2.5% 0.03 0.03 +0.0% scc -2.8% -0.0% 0.00 0.00 +0.0% sched -1.5% -0.0% 0.02 0.02 +0.0% scs +2.0% -0.6% +2.2% +0.5% +0.0% simple -0.7% +0.0% 0.16 0.16 -6.5% solid -0.5% -0.0% 0.10 0.10 +0.0% sorting -2.7% -35.9% 0.00 0.00 +0.0% spectral-norm +5.4% +16.1% +0.0% +0.0% +0.0% sphere -1.1% +1.8% 0.03 0.03 +0.0% symalg +0.8% -0.3% 0.01 0.01 +0.0% tak -1.5% -0.9% 0.01 0.01 +0.0% transform -1.0% -0.0% +4.3% +2.6% +0.0% treejoin -2.7% -52.4% 0.15 0.15 +3.8% typecheck -1.3% -0.0% 0.15 0.15 +0.0% veritas -0.3% -0.0% 0.00 0.00 +0.0% wang -0.8% -0.0% 0.08 0.08 +0.0% wave4main -1.3% -1.8% 0.19 0.19 +7.7% wheel-sieve1 -1.0% -0.0% +8.3% +3.1% +14.3% wheel-sieve2 -1.0% -0.0% 0.12 0.12 -2.1% x2n1 -7.1% -48.0% 0.01 0.01 -66.7% -------------------------------------------------------------------------------- Min -7.1% -95.0% -53.0% -52.8% -66.7% Max +7.2% +16.1% +35.0% +22.7% +46.2% Geometric Mean -1.0% -6.8% -1.7% -6.6% -4.4% lcss is definitely worth looking into, as it regressed ~35%. fast might be worth looking into, as it regressed with ~10%. There are also some ~5% regressions that are probably not worth looking into, unless someone has spare time. 7.6.2 vs HEAD: -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- anna +0.8% -1.5% 0.08 0.08 +0.0% ansi +0.5% -0.4% 0.00 0.00 +0.0% atom +0.9% +0.0% +0.8% +0.8% +0.0% awards +0.9% -0.1% 0.00 0.00 +0.0% banner -0.1% -2.1% 0.00 0.00 +0.0% bernouilli +0.6% -2.6% 0.13 0.13 +0.0% binary-trees +6.9% +0.0% +3.2% +1.6% +8.0% boyer +0.7% -0.0% 0.04 0.04 +0.0% boyer2 -0.2% -0.0% 0.01 0.01 +0.0% bspt +0.7% -0.1% 0.01 0.01 -33.3% cacheprof +0.9% -6.4% +4.0% +0.0% -4.0% calendar +0.9% -0.1% 0.00 0.00 +0.0% cichelli +0.2% +0.0% 0.06 0.06 -5.7% circsim +0.8% -0.1% +7.0% +1.9% +1.0% clausify +0.8% -0.0% 0.03 0.03 +0.0% comp_lab_zift +0.8% -0.0% 0.14 0.14 -12.5% compress +0.1% -0.0% 0.12 0.12 +0.0% compress2 +0.1% -0.0% 0.13 0.14 -2.1% constraints +0.8% -0.0% +2.3% +0.2% +0.0% cryptarithm1 +0.1% +0.0% -2.5% -4.0% +0.0% cryptarithm2 -0.6% +1.0% 0.01 0.01 +0.0% cse +0.0% +0.0% 0.00 0.00 +0.0% eliza -0.1% -7.1% 0.00 0.00 +0.0% event +0.7% -0.0% 0.10 0.10 +9.5% exp3_8 +0.8% -0.0% 0.14 0.14 -50.0% expert +0.2% -15.5% 0.00 0.00 +0.0% fannkuch-redux +0.8% -0.0% +3.7% +3.7% +0.0% fasta +0.8% -0.0% +7.8% +0.6% +0.0% fem -1.4% -0.5% 0.03 0.03 +0.0% fft +0.7% -0.0% 0.03 0.03 +0.0% fft2 -3.5% -24.6% 0.04 0.04 -33.3% fibheaps +0.9% -0.2% 0.03 0.03 +0.0% fish +0.0% +0.0% 0.01 0.01 +0.0% fluid +1.2% -11.9% 0.01 0.01 -50.0% fulsom +0.2% +0.0% 0.20 0.20 -5.1% gamteb +0.3% +0.1% 0.04 0.04 +0.0% gcd +0.8% -0.0% 0.03 0.03 +0.0% gen_regexps -0.0% -2.1% 0.00 0.00 +0.0% genfft +0.8% +0.3% 0.03 0.03 +0.0% gg +0.6% -29.0% 0.02 0.02 +0.0% grep +2.5% -2.3% 0.00 0.00 +0.0% hidden +0.7% -3.4% -6.4% -8.2% +0.0% hpg +0.5% +1.3% 0.10 0.10 +0.0% ida +0.8% +1.0% 0.06 0.06 -20.0% infer +1.2% -0.5% 0.05 0.05 -38.5% integer +0.9% -1.0% -4.7% -5.6% +0.0% integrate +0.9% -36.0% -34.6% -41.9% -1.0% k-nucleotide +8.5% +5.2% +2.7% +1.7% +46.2% kahan +0.9% -99.7% -52.2% -52.0% +0.0% knights +0.2% +0.4% 0.01 0.01 +0.0% lcss +0.2% -0.7% 0.27 +25.0% -3.7% life +0.1% -0.0% 0.16 0.16 +0.0% lift +0.0% -0.1% 0.00 0.00 +0.0% listcompr +0.1% +0.0% 0.06 0.06 +0.0% listcopy +0.1% +0.0% 0.06 0.06 +0.0% maillist -0.1% -1.8% 0.04 0.04 +6.3% mandel +0.8% -0.0% 0.05 0.05 +0.0% mandel2 +0.1% -0.0% 0.00 0.00 +0.0% minimax +0.2% +0.0% 0.00 0.00 +0.0% mkhprog +0.2% -1.1% 0.00 0.00 +0.0% multiplier +1.2% -0.0% 0.08 0.08 +0.0% n-body +6.6% +0.0% -21.4% -22.2% +0.0% nucleic2 +3.4% -16.3% 0.05 0.05 +0.0% para +0.3% -18.5% -12.8% -15.0% +0.0% paraffins +0.8% -0.0% 0.07 0.07 -7.0% parser +0.7% -18.4% 0.03 0.03 +0.0% parstof +0.5% -4.5% 0.00 0.00 +0.0% pic -0.8% -0.0% 0.00 0.00 +0.0% pidigits +0.8% -0.0% +3.6% -0.6% +0.0% power +1.0% -0.0% +1.4% -0.9% +0.0% pretty +0.2% -0.0% 0.00 0.00 +0.0% primes +0.8% +0.0% 0.05 0.05 +0.0% primetest +0.7% -0.0% 0.07 0.07 +0.0% prolog +0.2% -14.0% 0.00 0.00 +0.0% puzzle +0.1% +2.2% 0.10 0.10 +0.0% queens +0.8% -0.0% 0.02 0.02 +0.0% reptile +0.6% -0.8% 0.02 0.02 +0.0% reverse-complem +0.4% +0.0% 0.08 0.08 +0.0% rewrite +1.0% -0.7% 0.02 0.02 +0.0% rfib +1.0% -0.4% 0.02 0.02 +0.0% rsa +0.7% -2.5% 0.03 0.03 +0.0% scc +0.1% -0.0% 0.00 0.00 +0.0% sched +0.8% -0.0% 0.02 0.02 +0.0% scs +2.0% -0.6% +5.2% +1.7% +0.0% simple +0.2% +0.0% 0.16 0.16 -6.5% solid +0.7% -0.0% 0.10 0.10 +0.0% sorting -0.0% -35.9% 0.00 0.00 +0.0% spectral-norm +6.7% +16.1% +0.2% +0.0% +0.0% sphere +0.8% +1.8% 0.03 0.03 +0.0% symalg +0.8% -0.3% 0.01 0.01 +0.0% tak +0.8% -0.9% 0.01 0.01 +0.0% transform +0.9% -0.0% +6.2% +3.4% +0.0% treejoin -0.0% -52.4% 0.15 0.15 +3.8% typecheck +0.8% -0.0% 0.15 0.15 +0.0% veritas +0.7% -0.0% 0.00 0.00 +0.0% wang +0.5% -0.0% 0.08 0.08 +0.0% wave4main +0.8% -1.8% 0.19 0.19 +7.7% wheel-sieve1 +0.7% -0.0% +3.1% +0.8% +14.3% wheel-sieve2 +0.7% -0.0% 0.12 0.12 -2.1% x2n1 -6.8% -48.0% 0.01 0.01 -66.7% -------------------------------------------------------------------------------- Min -6.8% -95.0% -52.2% -52.0% -66.7% Max +8.5% +16.1% +7.8% +25.0% +46.2% Geometric Mean +0.7% -6.9% -5.5% -6.6% -3.6% 7.6.1 vs 7.6.2: -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- anna -0.6% +0.0% 0.07 0.08 +0.0% ansi -2.0% +0.0% 0.00 0.00 +0.0% atom -1.3% +0.0% +0.0% +0.0% +0.0% awards -1.8% +0.0% 0.00 0.00 +0.0% banner -2.6% +0.0% 0.00 0.00 +0.0% bernouilli -1.0% +0.0% 0.13 0.13 +0.0% binary-trees -1.2% +0.0% +1.2% +1.2% +0.0% boyer -2.2% +0.0% 0.03 0.04 +0.0% boyer2 -2.6% +0.0% 0.01 0.01 +0.0% bspt -1.1% +0.0% 0.01 0.02 +0.0% cacheprof -1.4% +0.0% +2.5% +0.0% +0.0% calendar -2.2% +0.0% 0.00 0.00 +0.0% cichelli -2.6% +0.0% 0.05 0.06 +0.0% circsim -1.9% +0.0% -0.3% +1.3% +0.0% clausify -2.2% +0.0% 0.03 0.03 +0.0% comp_lab_zift -2.1% +0.0% 0.13 0.14 +0.0% compress -1.4% +0.0% 0.11 0.11 +0.0% compress2 -1.8% +0.0% 0.12 0.14 +0.0% constraints -2.2% +0.0% +2.0% +2.4% +0.0% cryptarithm1 -2.8% +0.0% +2.1% +0.5% +0.0% cryptarithm2 -2.7% +0.0% 0.01 0.01 +0.0% cse -2.7% +0.0% 0.00 0.00 +0.0% eliza -2.5% +0.0% 0.00 0.00 +0.0% event -2.2% +0.0% 0.09 0.10 +0.0% exp3_8 -2.2% +0.0% 0.14 0.14 +0.0% expert -2.0% +0.0% 0.00 0.00 +0.0% fannkuch-redux -1.7% +0.0% -5.2% -5.6% +0.0% fasta -2.3% +8.7% +1.3% -1.2% -50.0% fem -0.7% +0.0% 0.02 0.03 +0.0% fft -1.3% +0.0% 0.02 0.03 +0.0% fft2 +0.0% +0.0% 0.04 0.05 +0.0% fibheaps -2.2% +0.0% 0.03 0.03 +0.0% fish -2.2% +0.0% 0.01 0.01 +0.0% fluid -0.3% +0.0% 0.01 0.01 +0.0% fulsom -0.2% +0.0% 0.19 0.19 -1.3% gamteb -1.1% +0.0% 0.03 0.04 +0.0% gcd -1.4% +0.0% 0.02 0.03 +0.0% gen_regexps -2.7% +0.0% 0.00 0.00 +0.0% genfft -1.7% +0.0% 0.03 0.03 +0.0% gg -1.0% +0.0% 0.01 0.02 +0.0% grep -2.5% +0.0% 0.00 0.00 +0.0% hidden -0.4% +0.0% +0.0% -2.5% +0.0% hpg -1.1% +0.0% 0.05 0.10 +0.0% ida -1.7% +0.0% 0.06 0.06 +0.0% infer -2.0% +0.0% 0.05 0.05 +0.0% integer -1.3% +0.0% +3.0% +3.1% +0.0% integrate -0.3% +0.0% 0.21 +6.4% -1.9% k-nucleotide -1.1% +0.0% -2.2% -2.3% +0.0% kahan -1.4% +0.0% -1.7% -1.7% +0.0% knights -1.9% +0.0% 0.00 0.01 +0.0% lcss -2.2% +0.0% -1.0% -1.8% +0.0% life -2.3% +0.0% 0.16 0.16 +0.0% lift -2.0% +0.0% 0.00 0.00 +0.0% listcompr -2.8% +0.0% 0.06 0.06 +0.0% listcopy -2.8% +0.0% 0.06 0.06 +0.0% maillist -2.6% +1.0% 0.03 0.05 -8.7% mandel -0.0% +0.0% 0.04 0.05 +0.0% mandel2 -2.8% +0.0% 0.00 0.00 +0.0% minimax -2.6% +0.0% 0.00 0.00 +0.0% mkhprog -2.6% +0.0% 0.00 0.00 +0.0% multiplier -2.2% +0.0% 0.08 0.08 +0.0% n-body -1.2% +0.0% -1.1% -1.3% +0.0% nucleic2 -1.2% +0.0% 0.05 0.05 +0.0% para -2.0% +0.0% +5.4% +2.6% +0.0% paraffins -2.2% +0.0% 0.06 0.08 +0.0% parser -2.1% +0.0% 0.03 0.03 +0.0% parstof -2.2% +0.0% 0.01 0.00 +0.0% pic -0.3% +0.0% 0.00 0.00 +0.0% pidigits -1.5% +0.0% +1.2% -1.7% +0.0% power -1.0% +0.0% +1.4% +1.4% +0.0% pretty -1.4% +0.0% 0.00 0.00 +0.0% primes -1.8% +0.0% 0.05 0.05 +0.0% primetest -1.3% +0.0% 0.08 0.07 +0.0% prolog -2.4% +0.0% 0.00 0.00 +0.0% puzzle -2.7% +0.0% 0.10 0.10 +0.0% queens -2.3% +0.0% 0.02 0.02 +0.0% reptile -1.4% +0.0% 0.01 0.02 +0.0% reverse-complem -2.9% +0.0% 0.06 0.08 +0.0% rewrite -2.1% +0.0% 0.02 0.02 +0.0% rfib +0.0% +0.0% 0.02 0.02 +0.0% rsa -1.4% +0.0% 0.02 0.02 +0.0% scc -2.9% +0.0% 0.00 0.00 +0.0% sched -2.2% +0.0% 0.02 0.02 +0.0% scs +0.0% +0.0% -2.8% -1.1% +0.0% simple -1.0% +0.0% 0.15 0.16 +0.0% solid -1.3% +0.0% 0.09 0.10 +0.0% sorting -2.6% +0.0% 0.00 0.00 +0.0% spectral-norm -1.2% +0.0% -0.2% +0.0% +0.0% sphere -1.9% +0.0% 0.03 0.03 +0.0% symalg -0.0% +0.0% 0.00 0.01 +0.0% tak -2.3% +0.0% 0.01 0.01 +0.0% transform -1.9% +0.0% -1.7% -0.9% +0.0% treejoin -2.7% +0.0% 0.15 0.16 +0.0% typecheck -2.2% +0.0% 0.15 0.15 +0.0% veritas -1.1% +0.0% 0.00 0.00 +0.0% wang -1.3% +0.0% 0.07 0.08 +0.0% wave4main -2.1% +0.0% 0.19 0.18 +0.0% wheel-sieve1 -1.7% +0.0% +5.0% +2.4% +0.0% wheel-sieve2 -1.7% +0.0% 0.11 0.13 +0.0% x2n1 -0.3% +0.0% 0.01 0.01 +0.0% -------------------------------------------------------------------------------- Min -2.9% +0.0% -5.2% -5.6% -50.0% Max +0.0% +8.7% +5.4% +6.4% +0.0% Geometric Mean -1.7% +0.1% +0.4% +0.0% -0.8% The big regression Bryan and I saw in hashable between 7.6.1 and 7.6.2 isn't visible here, so we might need to extract a separate benchmark for it. -- Johan

1 4

Re: [commit: testsuite] master: Convert remaining *_range_field's to *_num_field (478da8f)
by Simon Marlow 08 Feb '13

08 Feb '13

On 08/02/13 14:19, Ian Lynagh wrote: > Repository : ssh://darcs.haskell.org//srv/darcs/testsuite > > On branch : master > > http://hackage.haskell.org/trac/ghc/changeset/478da8fea8c7aca287a0a6270e202… > >> --------------------------------------------------------------- > > commit 478da8fea8c7aca287a0a6270e20254221c60c84 > Author: Ian Lynagh <ian(a)well-typed.com> > Date: Fri Feb 8 13:35:34 2013 +0000 > > Convert remaining *_range_field's to *_num_field Great work on the testsuite, all these changes look really good! Cheers, Simon

1 0

RE: Stable pointers and hash table performance
by Simon Peyton-Jones 07 Feb '13

07 Feb '13

The ticket contains vastly less information than Eyal's post, though. Simon | -----Original Message----- | From: Edward Z. Yang [mailto:ezyang@MIT.EDU] | Sent: 07 February 2013 08:34 | To: Simon Peyton-Jones | Cc: Eyal Lotem; "ghc-devs(a)haskell.org" | Subject: RE: Stable pointers and hash table performance | | http://hackage.haskell.org/trac/ghc/ticket/7670 | | Excerpts from Simon Peyton-Jones's message of Thu Feb 07 00:30:21 -0800 | 2013: | > Would it be worth turning this into a Trac ticket? | > | > Simon | > | > From: ghc-devs-bounces(a)haskell.org [mailto:ghc-devs- | bounces(a)haskell.org] On Behalf Of Eyal Lotem | > Sent: 07 February 2013 02:14 | > To: ghc-devs(a)haskell.org | > Subject: Stable pointers and hash table performance | > | > Hey, | > | > Background | > ---------------- | > I built a hash table in C: https://github.com/Peaker/small_hash | > | > According to a few simple benchmarks (mainly, 10 million insertions), | my C hash table is much faster than any Haskell data structure I tried | (e.g: 8 times faster than IntMap). | > You can run the C benchmark (in small_hash) via: "make && ./benchmark | 10000000". | > | > The other benchmarks are at: | https://github.com/Peaker/hashtable_benchmarks | > Benchmarks results on my hardware: http://hpaste.org/81902 | > | > I was hoping to get that fast mapping goodness to Haskell, by building | an FFI to it: | > https://github.com/Peaker/small_hash_hs | > | > In order to do FFI bindings to a C data structure, that can contain | arbitrary Haskell values, I must create a lot of StablePtrs (for each | Haskell value stored in the C hash table). | > | > Problem 1: | > ------------- | > Disappointingly, the FFI bindings were dozens of times slower(!) than | the C code. | > | > When using +RTS -H200M the speed is about 10 times slower(!) than the | C code. | > oprofile shows that the culprit is the Stable Ptr code. | > | > Digging in, I found that stable ptrs and stable names shared a table, | despite having quite different characteristics: | > * Stable Names aren't considered roots by GC, ptrs are. | > * Making two stable ptrs for the same Haskell value doesn't really | require them to unify -- so there's no need for the hash table or the | "refs" counter for stable ptrs. | > | > My Changes: | > ----------------- | > I split the Stable Names into their own table (which allowed removing | the "refs" field from them). | > Stable Ptrs no longer use a hash table to unify, don't need "refs", or | "sn_obj", or "old". | > | > This made Stable Ptrs cost just 1 C ptr in the table and really cheap | to create/destroy. | > | > The commits are here: | > https://github.com/Peaker/ghc/commits/master | > | > They are not polished (I didn't thoroughly review myself yet, didn't | run the test suite, fix out-of-date comments involved) and not ready for | integration yet. | > | > Result: | > --------- | > The hash table benchmark via the FFI is now only ~2 times slower than | the C data structure and much faster than any other mapping structure | for that particular benchmark (10 million insertions of identity | integers, sequentially). A lot of the cost here is due to fine-grained | allocation, as the C code does bulk allocation. I shall improve this | benchmark later, and I believe it will tighten the gap some more. | > | > Problem 2: | > -------------- | > http://hackage.haskell.org/trac/ghc/ticket/7670 | > | > Every minor GC iterates a whole lot of stable ptrs. This means that | with the default heap size, runtime is about 8 times longer (than with a | 200M heap size). | > | > To avoid this, I'd like to split the stable ptrs table into | generations. | > | > To do this, I need to know which of the pointed objects were promoted | and to what generation, so I can promote my stable ptrs accordingly. | > It seems like the correct time to do this is in the | updateStablePtrTable (now named "updateStableTables") | > | > This is the part I need help with. | > How do I know if an object was promoted to a higher generation when I | traverse the objects? | > | > Thanks! | > Eyal

2 1

nofib comparisons between 7.0.4, 7.4.2, 7.6.1, and 7.6.2
by Johan Tibell 07 Feb '13

07 Feb '13

Hi all, I haven't had much time to do performance tzar work yet, but I did run nofib on the last few GHC releases to see the current trend. The benchmarks where run on my 64-bit Core i7-3770 @ 3.40GHz Linux machine. Here are the results: 7.0.4 to 7.4.2: ------------------------------------------------------------ -------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- Min -1.6% -57.3% -39.1% -36.4% -25.0% Max +21.5% +121.5% +24.5% +25.4% +300.0% Geometric Mean +8.5% -0.7% -7.1% -5.2% +2.0% The big loser here in terms of runtime is "kahan", which I added to test tight loops involving unboxed arrays and floating point arithmetic. I believe there was a regression in fromIntegral RULES during this release, which meant that some conversions between fixed-width types went via Integer, causing unnecessary allocation. 7.4.2 to 7.6.1: -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- Min -5.1% -23.8% -11.8% -12.9% -50.0% Max +5.3% +225.5% +7.2% +8.8% +200.0% Geometric Mean -0.4% +2.1% +0.3% +0.2% +0.7% The biggest loser here in terms of runtime is "integrate". I haven't looked into why yet. 7.6.1 to 7.6.2: -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- Min -2.9% +0.0% -4.8% -4.4% -1.9% Max +0.0% +1.0% +4.5% +6.4% +20.8% Geometric Mean -1.7% +0.0% +0.1% +0.3% +0.2% I have two takeaways: * It's worthwhile running nofib before releases as it does find some programs that regressed. * There are some other regressions out there (i.e. in code on Hackage) that aren't reflected here, suggesting that we need to add more programs to nofib. Cheers, Johan

8 21

Stable pointers and hash table performance
by Eyal Lotem 07 Feb '13

07 Feb '13

Hey, Background ---------------- I built a hash table in C: https://github.com/Peaker/small_hash According to a few simple benchmarks (mainly, 10 million insertions), my C hash table is much faster than any Haskell data structure I tried (e.g: 8 times faster than IntMap). You can run the C benchmark (in small_hash) via: "make && ./benchmark 10000000". The other benchmarks are at: https://github.com/Peaker/hashtable_benchmarks Benchmarks results on my hardware: http://hpaste.org/81902 I was hoping to get that fast mapping goodness to Haskell, by building an FFI to it: https://github.com/Peaker/small_hash_hs In order to do FFI bindings to a C data structure, that can contain arbitrary Haskell values, I must create a lot of StablePtrs (for each Haskell value stored in the C hash table). Problem 1: ------------- Disappointingly, the FFI bindings were dozens of times slower(!) than the C code. When using +RTS -H200M the speed is about 10 times slower(!) than the C code. oprofile shows that the culprit is the Stable Ptr code. Digging in, I found that stable ptrs and stable names shared a table, despite having quite different characteristics: * Stable Names aren't considered roots by GC, ptrs are. * Making two stable ptrs for the same Haskell value doesn't really require them to unify -- so there's no need for the hash table or the "refs" counter for stable ptrs. My Changes: ----------------- I split the Stable Names into their own table (which allowed removing the "refs" field from them). Stable Ptrs no longer use a hash table to unify, don't need "refs", or "sn_obj", or "old". This made Stable Ptrs cost just 1 C ptr in the table and really cheap to create/destroy. The commits are here: https://github.com/Peaker/ghc/commits/master They are not polished (I didn't thoroughly review myself yet, didn't run the test suite, fix out-of-date comments involved) and not ready for integration yet. Result: --------- The hash table benchmark via the FFI is now only ~2 times slower than the C data structure and much faster than any other mapping structure for that particular benchmark (10 million insertions of identity integers, sequentially). A lot of the cost here is due to fine-grained allocation, as the C code does bulk allocation. I shall improve this benchmark later, and I believe it will tighten the gap some more. Problem 2: -------------- http://hackage.haskell.org/trac/ghc/ticket/7670 Every minor GC iterates a whole lot of stable ptrs. This means that with the default heap size, runtime is about 8 times longer (than with a 200M heap size). To avoid this, I'd like to split the stable ptrs table into generations. To do this, I need to know which of the pointed objects were promoted and to what generation, so I can promote my stable ptrs accordingly. It seems like the correct time to do this is in the updateStablePtrTable (now named "updateStableTables") This is the part I need help with. How do I know if an object was promoted to a higher generation when I traverse the objects? Thanks! Eyal

2 1

simd branch ready for review
by Geoffrey Mainland 06 Feb '13

06 Feb '13

Hi Simon, I've pushed my simd branch to darcs.haskell.org. Everything has been rebased against HEAD. Simon PJ and I looked over the changes together already, but I wanted to give you (and everyone on ghc-devs) the opportunity to look things over before I merge to HEAD. Simon PJ and I came up with a few questions/notes for you, but hopefully nothing that should delay a merge. * Win32 issues Modern 32-bit x86 *NIX systems align the stack to 16-bytes, but Win32 aligns only to 4-bytes. LLVM does not assume 16-byte stack alignment. Instead, on platforms where 16-byte stack alignment is not guaranteed, it 1) always outputs a function prologue that 2) aligns the stack to a 16-byte boundary with an "and" instructions, and it also 3) disables tail calls. Because LLVM aligns the stack for a function that has SSE register spills, it also generates movaps instructions (aligned SSE moves) for the spills. This makes SSE support on Win32 difficult, and in my opinion not worth worrying about. The alternative is to 1) patch LLVM to disable the stack-alignment code so that we recover the ability to use tail calls and so that ebp scribbled over by the prologue and 2) patch the mangler to rewrite LLVM's movaps (move aligned) instructions to movups (move unaligned) instructions. I have these patches, but they are not included in the simd branch. * How hard would it be to dump ArgRep for PrimRep? It looks straightforward. Is it worth doing? * How hard would it be to track bit width in PrimRep? I recall chatting with you once about adding explicit support for, e.g., 8- and 16-bit Word/Int primops instead of relying on narrowing. Since SIMD vectors need to know the exact bit-width of their elements, I've had to create a PrimElemRep data type in compiler/types/TyCon.lhs, but I'd really like to be able to re-use PrimRep instead. * If we replaced all old-style C-- code, could we get rid of the explicit STG registers completely? Simon PJ suggested that we use real machine registers directly, so, for example, GlobalReg's constructors would have FastString fields instead of Int fields. * Could we add a CmmType field to GlobalReg's constructors? You'll see that I added a new XmmReg constructor to GlobalReg, but because I don't know the type of an XmmReg, I have to bitcast everywhere in the generated LLVM code because LLVM wants to know not just that a value is a 16-byte vector, but that it is, e.g., a 16-byte vector containing 2 64-bit doubles. Having a CmmType attached to a GlobalReg---or pairing a GlobalReg with a CmmType when assigning registers---would let me avoid all these casts. Thanks! Geoff

8 27

Re: [commit: ghc] master: Rewrote vectorisation avoidance (based on the HS paper) (b77da25)
by David Terei 06 Feb '13

06 Feb '13

Hi Manuel, I recently committed a patch to document the -fvectorise and -favoid-vect flags. Would you mind taking a look at the documentation for these flags to ensure they are valid still with these recent changes? docs/userguide/using.xml is the file in question. Cheers, David On 5 February 2013 19:16, Manuel Chakravarty <chak(a)cse.unsw.edu.au> wrote: > Repository : ssh://darcs.haskell.org//srv/darcs/ghc > > On branch : master > > http://hackage.haskell.org/trac/ghc/changeset/b77da25ef0d95e776a43779bbb484… > >>--------------------------------------------------------------- > > commit b77da25ef0d95e776a43779bbb4843eb01d33552 > Author: Manuel M T Chakravarty <chak(a)cse.unsw.edu.au> > Date: Wed Dec 5 15:28:19 2012 +1100 > > Rewrote vectorisation avoidance (based on the HS paper) > > * Vectorisation avoidance is now the default > * Types and values from unvectorised modules are permitted in scalar code > * Simplified the VECTORISE pragmas (see http://hackage.haskell.org/trac/ghc/wiki/DataParallel/VectPragma for the spec) > * Vectorisation information is now included in the annotated Core AST > > compiler/coreSyn/CoreFVs.lhs | 11 +- > compiler/coreSyn/CoreSubst.lhs | 11 +- > compiler/coreSyn/CoreSyn.lhs | 4 +- > compiler/coreSyn/PprCore.lhs | 3 +- > compiler/deSugar/Desugar.lhs | 2 +- > compiler/hsSyn/HsDecls.lhs | 10 +- > compiler/iface/LoadIface.lhs | 14 +- > compiler/iface/MkIface.lhs | 18 +- > compiler/iface/TcIface.lhs | 30 +- > compiler/main/HscTypes.lhs | 54 +- > compiler/main/TidyPgm.lhs | 10 +- > compiler/parser/Parser.y.pp | 5 +- > compiler/rename/RnSource.lhs | 10 +- > compiler/typecheck/TcBinds.lhs | 9 +- > compiler/typecheck/TcHsSyn.lhs | 2 +- > compiler/vectorise/Vectorise.hs | 394 ++++------ > compiler/vectorise/Vectorise/Convert.hs | 18 +- > compiler/vectorise/Vectorise/Env.hs | 86 +-- > compiler/vectorise/Vectorise/Exp.hs | 1026 +++++++++++++------------ > compiler/vectorise/Vectorise/Monad.hs | 26 +- > compiler/vectorise/Vectorise/Monad/Global.hs | 60 +- > compiler/vectorise/Vectorise/Monad/InstEnv.hs | 13 +- > compiler/vectorise/Vectorise/Monad/Local.hs | 22 +- > compiler/vectorise/Vectorise/Type/Classify.hs | 42 +- > compiler/vectorise/Vectorise/Type/Env.hs | 211 +++--- > compiler/vectorise/Vectorise/Type/Type.hs | 13 +- > compiler/vectorise/Vectorise/Utils.hs | 25 +- > 27 files changed, 1066 insertions(+), 1063 deletions(-) > > > Diff suppressed because of size. To see it, use: > > git show b77da25ef0d95e776a43779bbb4843eb01d33552 > > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits

1 0

Re: [commit: nofib] master: Note why all shootout benchmarks couldn't be added (c82455f)
by Ian Lynagh 06 Feb '13

06 Feb '13

Hi Johan, On Tue, Feb 05, 2013 at 03:19:59PM -0800, Johan Tibell wrote: > > + * The k-nucleotide benchmark wasn't included as it segfaults on my > + 64-bit OS X 10.8.2 machine. That sounds more serious than a performance regression! Or is it a bug in the benchmark? Thanks Ian

2 1

Re: [commit: ghc] master: Add the new random commit again (6a46b46)
by Gabor Greif 05 Feb '13

05 Feb '13

Hi Ian, since you have pinned a commit that is on a branch, people whose clones do not track that branch will never see the commit: $ ( cd libraries/random ; git remote show; git remote show origin ) origin * remote origin Fetch URL: https://github.com/ghc/packages-random.git Push URL: https://github.com/ghc/packages-random.git HEAD branch: master Remote branch: master tracked Local ref configured for 'git push': master pushes to master (up to date) This may be the problem what we see. Possibly the 'sync-all' script could be amended, so that your 'ghc-head' branch is added to the remote? Cheers, Gabor On 2/5/13, Ian Lynagh <igloo(a)earth.li> wrote: > Repository : ssh://darcs.haskell.org//srv/darcs/ghc > > On branch : master > > http://hackage.haskell.org/trac/ghc/changeset/6a46b4627d4f3f81d65bf6b5b5c0b… > >>--------------------------------------------------------------- > > commit 6a46b4627d4f3f81d65bf6b5b5c0bcf86607c463 > Author: Ian Lynagh <ian(a)well-typed.com> > Date: Tue Feb 5 14:08:05 2013 +0000 > > Add the new random commit again > >>--------------------------------------------------------------- > > libraries/random | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/libraries/random b/libraries/random > index 69bfde2..2117e38 160000 > --- a/libraries/random > +++ b/libraries/random > @@ -1 +1 @@ > -Subproject commit 69bfde219bab869729fdbe9c1496371f912bf41e > +Subproject commit 2117e38729adaa4f465f3c5b7a8c5c4d77702d3f > > > > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits >

2 2

Git confusion
by Ian Lynagh 04 Feb '13

04 Feb '13

Hi all, If I do git clone darcs.haskell.org:/srv/darcs/ghc.git cd ghc git show origin then the output is [...] Local branch configured for 'git pull': master merges with remote master [...] However, none of: git remote rm origin git remote add origin darcs.haskell.org:/srv/darcs/ghc.git git remote show origin git remote rm origin git remote add origin darcs.haskell.org:/srv/darcs/ghc.git -m master git remote show origin git remote rm origin git remote add origin darcs.haskell.org:/srv/darcs/ghc.git -t master git remote show origin git remote rm origin git remote add origin darcs.haskell.org:/srv/darcs/ghc.git -t master -m master git remote show origin have the "Local branch configured for 'git pull':" section. So having done "git remote rm origin", how do I configure the git pull branches again? Thanks Ian

3 3

links to diffs on ghc-commit emails seem to be broken
by Carter Schonwald 04 Feb '13

04 Feb '13

Hey all, links seem to not work, though they are included in the emails eg from the email [commit: ghc] master: Move AsmCodeGen.makeFarBranches to PPC.Instr (#709) (aa1d7d3) http://hackage.haskell.org/trac/ghc/changeset/aa1d7d35ac27625c9aa67fe71c186… *should* these be broken or is something needing to be fixed up? thanks -Carter

2 1

Re: [commit: ghc] master: Follow random submodule change (ca5d15a)
by Manuel M T Chakravarty 04 Feb '13

04 Feb '13

Ian, That still doesn't work: > Cloning into 'libraries/random'... > fatal: reference is not a tree: 2117e38729adaa4f465f3c5b7a8c5c4d77702d3f > Unable to checkout '2117e38729adaa4f465f3c5b7a8c5c4d77702d3f' in submodule path 'libraries/random' Also: http://darcs.haskell.org/ghcBuilder/builders/tn23/826/3.html Manuel Ian Lynagh <igloo(a)earth.li>: > Repository : ssh://darcs.haskell.org//srv/darcs/ghc > > On branch : master > > http://hackage.haskell.org/trac/ghc/changeset/ca5d15a61c45d6ea763872df46efe… > >> --------------------------------------------------------------- > > commit ca5d15a61c45d6ea763872df46efe5c7b33f8186 > Author: Ian Lynagh <igloo(a)earth.li> > Date: Sun Feb 3 16:29:17 2013 +0000 > > Follow random submodule change > >> --------------------------------------------------------------- > > libraries/random | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/libraries/random b/libraries/random > index 69bfde2..2117e38 160000 > --- a/libraries/random > +++ b/libraries/random > @@ -1 +1 @@ > -Subproject commit 69bfde219bab869729fdbe9c1496371f912bf41e > +Subproject commit 2117e38729adaa4f465f3c5b7a8c5c4d77702d3f > > > > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits

1 0