- ghc-devs - Haskell.org

Better GHC builds for Windows users
by Austin Seipp 09 Dec '13

09 Dec '13

Hello all, After fiddling around this weekend I've written a quick, comprehensive guide to a Better Build Environment for windows users. It pretty much "Just works" and I think should make it easy to get started with new machines: https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows/MSYS2 Many thanks to Kyra for pointing this out to us on the GHC developer list. It is a much nicer to use mingw/msys environment with a lot of bugs fixed, and it's easy to install. Following the instructions should mostly be copy-paste. In particular, this resolves some weird issues with `validate` and traditional `make`, including a horrible deadlocking bug with make (and also 'tee', it seems.) So windows users can build in parallel again and everything works as expected. It also gives a simple and complete guide to build for x86_64 users (we didn't really mention it previously.) Please shout if you have problems. I've tested this with both an x86 and x86_64 build. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

1 0

Moving travis CI repo to git.haskell.org?
by Joachim Breitner 06 Dec '13

06 Dec '13

Hi, so far the experiment with https://travis-ci.org/nomeata/ghc-complete/builds is quite successful. Now that I started to also run the testsuite with -DDEBUG I was able spot some tests broken due to asserts in a timely manner, timely enough to identify (with high certainty) the causing commit. So it is a useful tool, and I would like to see it at https://travis-ci.org/ghc/ghc-complete/ghc instead, i.e. not tied to my name. Unfortunately, I cannot do that myself. Therefore, if you agree that this is a good thing (until we have a CI of our own), would someone with appropriate permissions please * Pull the repo from https://github.com/nomeata/ghc-complete to git.haskell.org. * Set up the mirror on github.com/ghc for ghc-complete (if that is a separate step) * and enable it on travis-ci.org. Once that is done I can change my cronjob (which is generating the commits) to push to git.haskell.org. If you also want to run that code, even better: just set up a cronjob that calls update.sh in a checkout of the repo, and adjust the --author flag therein. Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nomeata(a)debian.org

2 3

RE: [GHC] #8598: IO hack in demand analyzer gets in the way of CPR
by Simon Peyton-Jones 06 Dec '13

06 Dec '13

Well spotted. I'm on a train, hence email response. Maybe you can paste this into the ticket? There are two different issues here. '''First''', `isDoubleFinite` is declared as non-side-effecting: {{{ foreign import ccall unsafe "isDoubleFinite" isDoubleFinite :: Double -> Int }}} But (as you can see from the code you give) we currently desugar it into something that looks (to Core) as though it might have a side effect, or raise a (synchronous) exception. That is stupid. How might we fix that? I can think of two ways. * Generate a `FCallId` whose type is `Double -> Int` rather than (as now) `Double -> IO Int`. There would be a few knock-on consequences to make sure they were correctly code-generated. I like this path best, because it reflects the truth. * Currently {{{ IO a = State# RealWorld# -> (# State# RealWorld#, a #) }}} For these non-side-effecting things we could instead generate a `FCallId` with a type involving `SafeIO` instead of `IO`: {{{ SafeIO a = State# SafeWorld# -> (# State# SafeWorld#, a #) }}} The different "world token" would express the idea that the function can't throw an exception. I don't like this as much, but it might in any case be useful for things that ''do'' have side effects but ''don't'' throw exceptions. My preference is for the first. '''Second''', as you point out, consider {{{ f x = do { when (x>3) exit ; return (True, False) } }}} Function `f` might throw an exception or exit rather than returning, but ''if it does return'' it will certainly have the CPR property. So yes, CPR-ness is quite safe. It's not quite so obvious for divergence: {{{ g x = do { when (x>3) exit ; g x } h 0 y = y h x y = g x }}} Is `h` strict in `y`? You might say (reasonably) that we can ignore the possible IO exception/exit in `g` when figuring out that `g` is sure to diverge. If so, we'd say that `h` is strict in `y`. But if `(x>3)` then really `y` is not evaluated... and spotting that is exactly what the IO hack in the demand analyser is spotting. So I think it is ''not'' safe to propagate divergence information. In short, CPR info yes, guaranteed-divergence no. Simon | -----Original Message----- | From: ghc-tickets [mailto:ghc-tickets-bounces@haskell.org] On Behalf Of | GHC | Sent: 06 December 2013 10:54 | Cc: ghc-tickets(a)haskell.org | Subject: [GHC] #8598: IO hack in demand analyzer gets in the way of CPR | | #8598: IO hack in demand analyzer gets in the way of CPR | ------------------------------------+---------------------------------- | --- | Reporter: nomeata | Owner: | Type: task | Status: new | Priority: normal | Milestone: | Component: Compiler | Version: 7.6.3 | Keywords: | Operating System: | Unknown/Multiple | Architecture: Unknown/Multiple | Type of failure: None/Unknown | Difficulty: Unknown | Test Case: | Blocked By: | Blocking: | Related Tickets: | | ------------------------------------+---------------------------------- | --- | After a lot of staring at code and comparing unexpected nofib results | I | found the following: | | The IO hack in the demand analyzer (see `dmdAnalAlt` in `StrAnal.lhs` | and | #1592 for a good discussion) prevents CPR in any function that uses a | C | call. This is a small example, reduced from the `scaleFloat` method | for | doubles: | | {{{ | module Float(fun) where | | import GHC.Float (Double(..)) | import GHC.Integer (decodeDoubleInteger, encodeDoubleInteger) | | fun :: Double -> Double | fun x | isFix = x | | otherwise = case x of | (D# x#) -> case decodeDoubleInteger x# of | (# i, j #) -> D# (encodeDoubleInteger i j) | where | isFix = isDoubleFinite x == 0 | | foreign import ccall unsafe "isDoubleFinite" isDoubleFinite :: Double | -> | Int | }}} | | Here, `fun` does current not get the CPR property, and the work gets | type | `GHC.Prim.Double# -> GHC.Types.Double`. Why? Because in core, there | will | be a | {{{ | case {__pkg_ccall main isDoubleFinite GHC.Prim.Double# | -> GHC.Prim.State# GHC.Prim.RealWorld | -> (# GHC.Prim.State# | GHC.Prim.RealWorld, | GHC.Prim.Int# #)}_dQD | ds_dQA GHC.Prim.realWorld# | of _ [Occ=Dead, Dmd=<L,A>] | { (# ds_dQC [Dmd=<L,A>, OS=OneShot], ds_dQB [Dmd=<S,1*U>] #) -> | ... | }}} | where the case body has `DmdType m {dQz-><L,1*U(U)> dQA-><L,U>}`, but | `dmdAnalAlt` detects that this is evaluating a possibly exiting | function | and throws aways the information using `alt_ty `lubDmdType` | topDmdType`. | | Would it be ok to `lub` only the demand on the free variables, but | keep | the CPR information? | | In nofib (if I managed to compare the right results) this does nothing | for | almost all benchmarks, `-9.2%` of allocations for `mandel` and `+4.9%` | for | reverse-complement (but these numbers are not obtained very cleanly, | and | all is happening on top of the better-ho-cardinality branch. | | -- | Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8598> | 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

__builtin___clear_cache
by Kazu Yamamoto 05 Dec '13

05 Dec '13

Hi, 5bab1a57f572e29dfdffd6d1ce8e53a2772b18fd introduced __builtin___clear_cache. I think this is GCC specific. So, Storage.c cannot be compiled with clang: ---- rts/sm/Storage.c:1294:3: error: use of unknown builtin '__builtin___clear_cache' [-Wimplicit-function-declaration] __builtin___clear_cache(begin, end); ^ 1 error generated. ---- --Kazu

2 3

Compare-and-swap semantics in GHC
by KwangYul Seo 05 Dec '13

05 Dec '13

Hi, java.util.concurrent.atomic package provides two flavors of compare and set operations: compareAndSet and weakCompareAndSet. The latter does not create any happens-before orderings, so we can use it where no guarantees with respect to previous or subsequent reads and writes of any variables other than the target of the weakCompareAndSet are required. I'd like to ask if the compare-and-swap function provided by GHC runtime (cas() in includes/stg/SMP.h) is strong or weak. If it is strong, do all use cases of cas() require this semantics? Regards, Kwang Yul Seo

3 3

Simple script to make existing GHC or HP installation work with Xcode 5
by Mark Lentczner 05 Dec '13

05 Dec '13

Friends - I've developed a simple shell script that should enable your existing GHC 7. or HP installation work with Xcode 5. https://gist.github.com/mzero/7245290 Place that script somewhere, make it executable, and run it. *Then follow the instructions it tells you!* You will end up having to run it more than once: First time it will tell you where to install a copy of the script Second time it will patch your GHC settings file(s) The script is safe to install and setup before you upgrade to Xcode 5, as it reverts to "getting out of the way" if it detects Xcode 4 based installation. It has been tested on two machines: - OS X 10.8 and Xcode 4 - OS X 10.9 and Xcode 5 If a few more intrepid souls test it and it works, I'll post instructions in more prominent places! I'll be testing OS X 10.9 and Xcode 4, tomorrow, and expect it should work fine on OS X10.8 with Xcode 5. But looking for reports that it all works. - Mark "Mac Packager" Lentczner

2 1

Re: [commit: ghc] wip/nested-cpr: Add a flag -fnested-cpr-off to conveniently test the effect of nested CPR (90529b1)
by Johan Tibell 04 Dec '13

04 Dec '13

Nitpick: don't we usually name these flags -fno-nested-cpr? On Wed, Dec 4, 2013 at 10:19 AM, <git(a)git.haskell.org> wrote: > Repository : ssh://git@git.haskell.org/ghc > > On branch : wip/nested-cpr > Link : > http://ghc.haskell.org/trac/ghc/changeset/90529b15c02ef03dcece13c267b76d470… > > >--------------------------------------------------------------- > > commit 90529b15c02ef03dcece13c267b76d470941b808 > Author: Joachim Breitner <mail(a)joachim-breitner.de> > Date: Wed Dec 4 09:14:26 2013 +0000 > > Add a flag -fnested-cpr-off to conveniently test the effect of nested > CPR > > > >--------------------------------------------------------------- > > 90529b15c02ef03dcece13c267b76d470941b808 > compiler/basicTypes/Demand.lhs | 28 +++++++++++++++++++--------- > compiler/main/StaticFlags.hs | 9 +++++++-- > 2 files changed, 26 insertions(+), 11 deletions(-) > > diff --git a/compiler/basicTypes/Demand.lhs > b/compiler/basicTypes/Demand.lhs > index 557a9bd..e955195 100644 > --- a/compiler/basicTypes/Demand.lhs > +++ b/compiler/basicTypes/Demand.lhs > @@ -791,20 +791,29 @@ botRes = Diverges > maxCPRDepth :: Int > maxCPRDepth = 3 > > +-- This is the depth we use with -fnested-cpr-off, in order > +-- to get precisely the same behaviour as before introduction of nested > cpr > +-- -fnested-cpr-off can eventually be removed if nested cpr is deemd to be > +-- a good thing always. > +flatCPRDepth :: Int > +flatCPRDepth = 1 > + > -- With nested CPR, DmdResult can be arbitrarily deep; consider e.g. the > -- DmdResult of repeat > -- > -- So we need to forget information at a certain depth. We do that at all > points > -- where we are building RetCon constructors. > -cutDmdResult :: Int -> DmdResult -> DmdResult > -cutDmdResult 0 _ = topRes > -cutDmdResult _ Diverges = Diverges > -cutDmdResult n (Converges c) = Converges (cutCPRResult n c) > -cutDmdResult n (Dunno c) = Dunno (cutCPRResult n c) > - > cutCPRResult :: Int -> CPRResult -> CPRResult > -cutCPRResult _ NoCPR = NoCPR > +cutCPRResult 0 _ = NoCPR > +cutCPRResult _ NoCPR = NoCPR > cutCPRResult n (RetCon tag rs) = RetCon tag (map (cutDmdResult (n-1)) rs) > + where > + cutDmdResult :: Int -> DmdResult -> DmdResult > + cutDmdResult 0 _ = topRes > + cutDmdResult _ Diverges = Diverges > + cutDmdResult n (Converges c) = Converges (cutCPRResult n c) > + cutDmdResult n (Dunno c) = Dunno (cutCPRResult n c) > + > > -- Forget that something might converge for sure > divergeDmdResult :: DmdResult -> DmdResult > @@ -819,8 +828,9 @@ forgetCPR (Dunno _) = Dunno NoCPR > > cprConRes :: ConTag -> [DmdType] -> CPRResult > cprConRes tag arg_tys > - | opt_CprOff = NoCPR > - | otherwise = cutCPRResult maxCPRDepth $ RetCon tag (map get_res > arg_tys) > + | opt_CprOff = NoCPR > + | opt_NestedCprOff = cutCPRResult flatCPRDepth $ RetCon tag (map > get_res arg_tys) > + | otherwise = cutCPRResult maxCPRDepth $ RetCon tag (map > get_res arg_tys) > where > get_res :: DmdType -> DmdResult > get_res (DmdType _ [] r) = r -- Only for data-typed arguments! > diff --git a/compiler/main/StaticFlags.hs b/compiler/main/StaticFlags.hs > index 01dc3b7..feb7235 100644 > --- a/compiler/main/StaticFlags.hs > +++ b/compiler/main/StaticFlags.hs > @@ -27,6 +27,7 @@ module StaticFlags ( > -- optimisation opts > opt_NoStateHack, > opt_CprOff, > + opt_NestedCprOff, > opt_NoOptCoercion, > > -- For the parser > @@ -140,7 +141,8 @@ flagsStaticNames :: [String] > flagsStaticNames = [ > "fno-state-hack", > "fno-opt-coercion", > - "fcpr-off" > + "fcpr-off", > + "fnested-cpr-off" > ] > > -- We specifically need to discard static flags for clients of the > @@ -195,10 +197,13 @@ opt_NoDebugOutput = lookUp (fsLit > "-dno-debug-output") > opt_NoStateHack :: Bool > opt_NoStateHack = lookUp (fsLit "-fno-state-hack") > > --- Switch off CPR analysis in the new demand analyser > +-- Switch off CPR analysis in the demand analyser > opt_CprOff :: Bool > opt_CprOff = lookUp (fsLit "-fcpr-off") > > +opt_NestedCprOff :: Bool > +opt_NestedCprOff = lookUp (fsLit "-fnested-cpr-off") > + > opt_NoOptCoercion :: Bool > opt_NoOptCoercion = lookUp (fsLit "-fno-opt-coercion") > > > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits >

2 1

arising from the dependency ... in the instance declaration
by Joachim Breitner 03 Dec '13

03 Dec '13

Hi, I have an error message, and I’m looking for code that produces it (how is that for a change...) While fixing https://ghc.haskell.org/trac/ghc/ticket/8576 I’d like to clean up some error reporting in FunDeps.lhs, in particular code that is involved in producing errors like Couldn't match type 'False with 'True When using functional dependencies to combine And 'False 'False 'False, arising from the dependency `a b -> c' in the instance declaration in `UnitTyped.Units' And 'False 'False 'True, arising from a use of `+' at <interactive>:14:7 In the expression: meter + second In an equation for `it': it = meter + second but unfortunately, the test suite does _not_ contain any code that creates this error message. Also, the results obtained from googling for that error message yield either no code, or only unhelpful code fragments, or code that produces a different error message with current HEAD. Unfortunately, I cannot produce code that triggers it. Does anyone have code lying around that triggers that error message? Also: I found code that had this kind of error message in 7.6, e.g. the attached code’s error changed from FunDepError.hs:86:27: Couldn't match type `F a1' with `U' When using functional dependencies to combine UpdateR (xs :> s) (S n) t (xs' :> s), arising from the dependency xs n t -> xs' in the instance declaration at FunDepError.hs:54:10 UpdateR ((xs' :> F a0) :> F a1) (S O) U ((jj0 :> U) :> U), arising from a use of `var' at FunDepError.hs:86:27-29 In the expression: var a In the first argument of `lam', namely `(\ b -> var a)' (sorry for not finding something simpler) to FunDepError.hs:86:5: No instance for (Consume xs' jj) arising from a use of ‛lam’ Possible fix: add (Consume xs' jj) to the context of the inferred type of x :: LLC t xs' jj (a :-> (a1 :-> a)) In the expression: lam (\ a -> lam (\ b -> var a)) In an equation for ‛x’: x = lam (\ a -> lam (\ b -> var a)) FunDepError.hs:86:27: No instance for (UpdateR ((xs' :> F a) :> F a1) (S O) U ((jj :> U) :> U)) arising from a use of ‛var’ In the expression: var a In the first argument of ‛lam’, namely ‛(\ b -> var a)’ In the expression: lam (\ b -> var a) Is that desired or a regression? Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nomeata(a)debian.org

2 3

Getting Involved
by Blair Archibald 03 Dec '13

03 Dec '13

Hi, I'm looking to get involved working on GHC - I've been using Haskell for quite a while now and thought I'd give back to the community. Bit about me: I'm Blair an (4th year) Undergraduate at the University of Glasgow and my main interests at the moment are Functional Programming, Runtime systems (mainly memory management/GC work) and Transactional Memory (making GHC a great place to be!) I've noticed that there is talk of adding a better flags parser to the RTS and this seems like a good place to start (less likely to break things!). Ticket: #4243 Is anyone currently working in this area or have plans to start work in this area? Many thanks, Blair

6 7

Can cardinality analysis subsume strictness analysis
by Joachim Breitner 02 Dec '13

02 Dec '13

Hi, after playing a bit with the Demand analyser and trying debug tricky bugs (#8569), I begin to wonder: Can cardinality analysis subsume strictness analysis? Not directly, obviously, but if we change data Count = One | Many to data Count = AtMostOne | ExactlyOne | AtLeastOne | Many (or some other form that would allow us to express all possible intervals in {0,1,∞}), would the demand and cardinality analysis then not subsume strictness, given that: A value is used strictly if is definitely used at least once? That might simplify the Demand.lhs code, and also the demand signatures, quite a bit, because currently it carries strictness and demand data around separately, duplicating lots of stuff. Greetings, Joachim -- Joachim “nomeata” Breitner mail(a)joachim-breitner.de • http://www.joachim-breitner.de/ Jabber: nomeata(a)joachim-breitner.de • GPG-Key: 0x4743206C Debian Developer: nomeata(a)debian.org

1 1