- ghc-devs - Haskell.org

HeapStackCheck.cmm
by Alexander Pakhomov 11 Dec '13

11 Dec '13

Hi. Trying to compile ghc HEAD on OpenBSD I got an error: rts/HeapStackCheck.cmm:97:18: parse error on input `[' The code is following: 96 if (HpAlloc <= BLOCK_SIZE 97 && bdescr_link(CurrentNursery) != NULL) { which preprocesses to: if (HpAlloc <= (1<<12) && b0[CurrentNursery+15] != (0::bits64)) { This is the first occurrence of b0 in preprocessed file. I believe that it is due to undefined b0. Command that fails is: "inplace/bin/ghc-stage1" -static -H32m -O -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -package-name rts -dcmm-lint -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen -O2 -c rts/HeapStackCheck.cmm -o rts/dist/build/HeapStackCheck.o To preprocess do the following: cpp -O -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -Irts/dist/build -Irts/dist/build/autogen rts/HeapStackCheck.cmm | less Can you please find source of b0 in preprocessed file?

3 5

Please help complete `.mailmap`
by Herbert Valerio Riedel 11 Dec '13

11 Dec '13

Hello *, I've been trying to (re)construct a .mailmap file[1] in ghc.git which allows `git shortlog` and `git log --use-mailmap` (and possibly other tools/commands) to fixup bogus author-ids when displaying the Git history, in the hopes to provide a more complete history of GHC and all contributors involved. I've been able to infer mappings for most users, but I'm stuck on a couple of older account usernames dating back a decade ago for which I have no idea what real names to associate with. These are specifically: $ git shortlog -es | grep unknown 16 apt <unknown> 1 cryder <unknown> 13 desrt <unknown> 8 dnt <unknown> 1 geoffw <unknown> 12 gla <unknown> 3 josefs <unknown> 5 krc <unknown> 1 kw <unknown> 5 kw217 <unknown> 1 mbs <unknown> 1 moran <unknown> 3 njn <unknown> 8 ralf <unknown> 11 rje <unknown> 1 sseefried <unknown> 1 tgedell <unknown> 1 uid245 <unknown> 1 umuta <unknown> 1 y.zhuang5(a)lse.ac.uk <unknown> If you happen to know who these past contributors are, please either tell me or update [1] accordingly. Moreover, if you stumble over any wrong entry in [1], feel free to correct it. Thanks, hvr [1] http://git.haskell.org/ghc.git/blob/HEAD:/.mailmap PS: If anyone's curious, the top-5 committers in ghc.git are currently: $ git shortlog -sn | head -n5 8513 Simon Marlow 5368 Simon Peyton Jones 4629 Ian Lynagh 2633 Sigbjorn Finne 941 Julian Seward

4 3

nofib’s cacheprof’s Allocations not deterministic
by Joachim Breitner 10 Dec '13

10 Dec '13

Hi, with most of nofib, one expects at least the Allocation numbers to be reliably and deterministic. This is not the case with cacheprof, they seem to wibble around by ~0.2%, which is strange. Has anyone else noticed this yes, and if so, tried to find out the cause? Is it expected and desired, or a bug somewhere? 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

3 2

benchmarks
by Alexander Pakhomov 10 Dec '13

10 Dec '13

Hi. Do you do performance testing? I would be interested in statistics by release. I worked at optimizing compiler at my previous job and we had quite huge amount of performance tests for each commit. When something slowed down we fixed it. It is strange but most of times we found and fixed slowdown.

3 2

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