- ghc-devs - Haskell.org

Travis validation on a GHC fork?
by Richard Eisenberg 13 Nov '14

13 Nov '14

Hi Joachim, I just tried to use Travis for validation on my fork of GHC, to avoid sending out emails associated with a wip/... commit. But, Travis couldn't find the submodules. Here's the tail of my log: > Submodule 'libraries/vector' (git://github.com/goldfirere/packages/vector.git) registered for path 'libraries/vector' > Submodule 'libraries/xhtml' (git://github.com/goldfirere/packages/xhtml.git) registered for path 'libraries/xhtml' > Submodule 'nofib' (git://github.com/goldfirere/nofib.git) registered for path 'nofib' > Submodule 'utils/haddock' (git://github.com/goldfirere/haddock.git) registered for path 'utils/haddock' > Submodule 'utils/hsc2hs' (git://github.com/goldfirere/hsc2hs.git) registered for path 'utils/hsc2hs' > Cloning into 'libffi-tarballs'... > fatal: remote error: > Repository not found. > Clone of 'git://github.com/goldfirere/libffi-tarballs.git' into submodule path 'libffi-tarballs' failed > The command "git submodule update --init --recursive" failed and exited with 1 during . > Your build has been stopped. I could probably figure out the right commands to fix this, but then my local .travis.yml would be different than the proper one, and that can cause various headaches down the road. Any advice? Thanks, Richard

2 2

RFC: Dropping Windows XP support
by Austin Seipp 13 Nov '14

13 Nov '14

Hi all, This is a quick discussion about the current system requirements for Windows builds. Spurred by a recent[1] LLVM discussion, I'd like to raise the question of dropping support for Windows XP, and bumping the minimum required version to Windows Vista or even Windows 7. For one, Microsoft doesn't support XP anymore, so most people are moving off it anyway. 'Soon' even XP Embedded will be obsoleted. But second, Vista and beyond introduced useful new APIs we could use. I was digging through the LLVM thread and two came out to me: 1) We could switch to using slim reader/writer locks, which in some workloads may work out better than critical sections (they'll win on more read-heavy workloads). The downsides is there's no recursive locking but we don't use that anyway (and recursive locks are considered bad by many anyway[2]). 2) We could probably use an actual condition variables API that was introduced with Vista. Currently we use a giant EVENT object to emulate the API, which could be replaced with the real deal. Both of these could be nice wins for simplicity and performance I think. I know there are some corporate users out there who this may impact, and users as well. I'd like to know what people think. Particularly what version we should standardize on. FWIW, I don't plan on changing any of this until the 7.12 release at least. [1] http://article.gmane.org/gmane.comp.compilers.llvm.devel/78419 [2] http://www.zaval.org/resources/library/butenhof1.html -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

4 3

Error handling in the renamer
by Jan Stolarek 13 Nov '14

13 Nov '14

I'm improving my patch for injective type families and I have a question about error handling in the renamer. If I write this incorrect definition: type family F a b = r | r -> c I get these errors: T6018rnfail.hs:36:1: Not in scope: type variable ‘c’ T6018rnfail.hs:36:26: Unexpected type variable on the RHS of injectivity condition: ‘c’ All variables should be bound in type family head and appear at most once in exactly the same order as they were bound. I don't want to report two errors here, just the first one. This means I have to first run the renaming using RnTypes.rnTyVar and check if it reports errors. If it does I don't report the extra error. The question is how do I check if this piece of code returns errors: injFrom' <- rnTyVar True injFrom injTo' <- mapM (rnTyVar True) injTo I found some combinators in TcRnMonad (tryTc and friends) but I don't know how to use them. Ideally I'd want `TcRn a -> TcRn (Messages, a)` + isEmptyMessages but the existing combinators return `TcRn a -> TcRn (Messages, Maybe a)`. I'm not at all happy with getting Nothing - even if renaming fails my function has to return a result. Jan

1 0

TIL about arc diff
by Alan & Kim Zimmerman 12 Nov '14

12 Nov '14

I find if I get a timeout on upload at the end, it is time to rebase against master. Alan

1 0

expanded macros in parser?
by Richard Eisenberg 12 Nov '14

12 Nov '14

Hi devs, I just stumbled across commit 37d64a5, which (among other things) expands all the LL/L1/etc macros in Parser.y.pp and makes the go-to file Parser.y. Why was this done? I don't love macros, but I think the old format was easier to look at and edit. I know I missed the train a bit on this by not noticing D411, but this surprised me today. Thanks, Richard

2 2

query ghc for the linkerflags for -staticlib?
by Moritz Angermann 12 Nov '14

12 Nov '14

Hi, when building a library with -staticlib, how can we query ghc to tell us the linker flags, that would be needed to link the produced library. (e.g. -liconv and -lgmp)? I tried --print-ld-linker-flags and --print-gcc-linker-flags and found they were broken, as is specified in #9614. Also --info does not provide the needed information. Cheers, Moritz

1 0

let/app invariant violated by code generated with mkCoreApp
by Dr. ERDI Gergo 12 Nov '14

12 Nov '14

Hi, I'm trying to attach (f Void#) as a compulsory unfolding to an Id. Here's what I tried originally: let unfolding = mkCoreApp (Var worker_id) (Var voidPrimId) wrapper_id' = setIdUnfolding wrapper_id $ mkCompulsoryUnfolding unfolding However, when I try to use wrapper_id' in the desugarer, the Core linter looks at me strange. This is the original Core: f :: Int [LclIdX, Str=DmdType] f = break<1>() GHC.Types.I# Main.$WPAT and this is the error message ($WPAT is the wrapper_id', PAT is the worker_id in this example) <no location info>: Warning: In the expression: I# (PAT void#) This argument does not satisfy the let/app invariant: PAT void# Now, I thought I'd make sure mkCoreApp generated correct Core by writing it out by hand: let unfolding = Case (Var voidPrimId) voidArgId pat_ty [(DEFAULT,[],App (Var worker_id) (Var voidArgId))] however, bizarrely, this *still* results in *the same* error message, as if something was transforming it back to a straight App. Anyone have any hints what I'm doing wrong here? Bye, Gergo -- .--= ULLA! =-----------------. \ http://gergo.erdi.hu \ `---= gergo(a)erdi.hu =-------' You are in a twisty maze of little install diskettes.

3 4

RE: [commit: ghc] master: Implement new integer-gmp2 from scratch (re #9281) (c774b28)
by Simon Peyton Jones 12 Nov '14

12 Nov '14

Great stuff. But why do primetest, rsa, and mandel allocate so much more? You mention different accounting, but I've found that it is often worth really understanding what is happening because you discover "Oh, yes, that's egregiously bad, and easily fixed". Simon | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces@haskell.org] On Behalf | Of git(a)git.haskell.org | Sent: 12 November 2014 10:05 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] master: Implement new integer-gmp2 from scratch | (re #9281) (c774b28) | | Repository : ssh://git@git.haskell.org/ghc | | On branch : master | Link : | http://ghc.haskell.org/trac/ghc/changeset/c774b28f76ee4c220f7c1c9fd815 | 85e0e3af0e8a/ghc | | >--------------------------------------------------------------- | | commit c774b28f76ee4c220f7c1c9fd81585e0e3af0e8a | Author: Herbert Valerio Riedel <hvr(a)gnu.org> | Date: Sun Oct 19 20:37:40 2014 +0200 | | Implement new integer-gmp2 from scratch (re #9281) | | This is done as a separate `integer-gmp2` backend library because | it | turned out to become a complete rewrite from scratch. | | Due to the different (over)allocation scheme and potentially | different | accounting (via the new `{shrink,resize}MutableByteArray#` | primitives), | some of the nofib benchmarks actually results in increased | allocation | numbers (but not necessarily an increase in runtime!). I believe | the | allocation numbers could improve if | `{resize,shrink}MutableByteArray#` | could be optimised to reallocate in-place more efficiently. | | Here are the more apparent changes in the latest nofib comparision | between `integer-gmp` and `integer-gmp2`: | | ---------------------------------------------------------------- | -- | Program Size Allocs Runtime Elapsed TotalMem | ---------------------------------------------------------------- | -- | ... | bernouilli +1.6% +15.3% 0.132 0.132 0.0% | ... | cryptarithm1 -2.2% 0.0% -9.7% -9.7% 0.0% | ... | fasta -0.7% -0.0% +10.9% +10.9% 0.0% | ... | kahan +0.6% +38.9% 0.169 0.169 0.0% | ... | lcss -0.7% -0.0% -6.4% -6.4% 0.0% | ... | mandel +1.6% +33.6% 0.049 0.049 0.0% | ... | pidigits +0.8% +8.5% +3.9% +3.9% 0.0% | power +1.4% -23.8% -18.6% -18.6% -16.7% | ... | primetest +1.3% +50.1% 0.085 0.085 0.0% | ... | rsa +1.6% +53.4% 0.026 0.026 0.0% | ... | scs +1.2% +6.6% +6.5% +6.6% +14.3% | ... | symalg +1.0% +9.5% 0.010 0.010 0.0% | ... | transform -0.6% -0.0% -5.9% -5.9% 0.0% | ... | ---------------------------------------------------------------- | -- | Min -2.3% -23.8% -18.6% -18.6% -16.7% | Max +1.6% +53.4% +10.9% +10.9% +14.3% | Geometric Mean -0.3% +1.9% -0.8% -0.8% +0.0% | | (see P35 / https://phabricator.haskell.org/P35 for full report) | | By default, `INTEGER_LIBRARY=integer-gmp2` is active now, which | results | in the package `integer-gmp-1.0.0.0` being registered in the | package db. | The previous `integer-gmp-0.5.1.0` can be restored by setting | `INTEGER_LIBRARY=integer-gmp` (but will probably be removed | altogether | for GHC 7.12). In-tree GMP support has been stolen from the old | `integer-gmp` (while unpatching the custom memory-allocators, as | well as | forcing `-fPIC`) | | A minor hack to `ghc-cabal` was necessary in order to support two | different | `integer-gmp` packages (in different folders) with the same | package key. | | There will be a couple of follow-up commits re-implementing some | features | that were dropped to keep D82 minimal, as well as further | clean-ups/improvements. | | More information can be found via #9281 and | https://ghc.haskell.org/trac/ghc/wiki/Design/IntegerGmp2 | | Reviewed By: austin, rwbarton, simonmar | | Differential Revision: https://phabricator.haskell.org/D82 | | | >--------------------------------------------------------------- | | c774b28f76ee4c220f7c1c9fd81585e0e3af0e8a | compiler/basicTypes/Module.lhs | 7 +- | compiler/coreSyn/CorePrep.lhs | 3 +- | compiler/ghc.mk | 8 +- | compiler/prelude/PrelNames.lhs | 2 + | ghc.mk | 11 +- | libraries/base/GHC/Real.hs | 4 + | libraries/base/base.cabal | 19 +- | libraries/{integer-gmp => integer-gmp2}/.gitignore | 5 +- | libraries/integer-gmp2/LICENSE | 30 + | libraries/{base => integer-gmp2}/Setup.hs | 0 | libraries/{integer-gmp => integer-gmp2}/aclocal.m4 | 0 | libraries/integer-gmp2/cbits/wrappers.c | 281 ++++ | .../{integer-gmp => integer-gmp2}/changelog.md | 7 + | .../integer-gmp2/config.guess | 0 | config.sub => libraries/integer-gmp2/config.sub | 0 | .../{integer-gmp => integer-gmp2}/configure.ac | 2 +- | .../{integer-gmp => integer-gmp2}/gmp/config.mk.in | 0 | libraries/integer-gmp2/gmp/ghc.mk | 124 ++ | libraries/integer-gmp2/gmp/gmpsrc.patch | 37 + | {libffi => libraries/integer-gmp2/gmp}/ln | 0 | .../include/HsIntegerGmp.h.in | 0 | .../integer-gmp.buildinfo.in | 0 | libraries/integer-gmp2/integer-gmp.cabal | 65 + | .../src/GHC/Integer.hs} | 49 +- | .../integer-gmp2/src/GHC/Integer/GMP/Internals.hs | 126 ++ | .../integer-gmp2/src/GHC/Integer/Logarithms.hs | 73 + | .../src/GHC/Integer/Logarithms/Internals.hs | 118 ++ | libraries/integer-gmp2/src/GHC/Integer/Type.hs | 1663 | ++++++++++++++++++++ | mk/config.mk.in | 2 +- | rules/foreachLibrary.mk | 2 + | testsuite/tests/ghci/scripts/ghci025.stdout | 6 +- | testsuite/tests/lib/integer/all.T | 3 +- | testsuite/tests/llvm/should_compile/all.T | 2 +- | testsuite/tests/perf/should_run/all.T | 3 +- | testsuite/tests/perf/space_leaks/all.T | 6 +- | testsuite/tests/safeHaskell/check/pkg01/all.T | 1 + | testsuite/tests/simplCore/should_run/T5603.hs | 3 +- | testsuite/tests/typecheck/should_fail/T5095.stderr | 4 +- | .../tests/typecheck/should_fail/tcfail072.stderr | 2 +- | utils/ghc-cabal/Main.hs | 4 + | 40 files changed, 2628 insertions(+), 44 deletions(-) | | Diff suppressed because of size. To see it, use: | | git diff-tree --root --patch-with-stat --no-color --find-copies- | harder --ignore-space-at-eol --cc | c774b28f76ee4c220f7c1c9fd81585e0e3af0e8a | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | http://www.haskell.org/mailman/listinfo/ghc-commits

2 1

HEADS-UP: integer-gmp2 landed!
by Herbert Valerio Riedel 12 Nov '14

12 Nov '14

Hello GHC devs, A few minutes ago, I landed `integer-gmp2` to master! Ideally, you shouldn't notice any breakages (I've tried to make sure all tier-1 platform configuration work...), but if you do have problems, please report any issues/regressions you encounter to me! Morever, should something break in a way that blocks you on your platform, just add "INTEGER_LIBRARY=integer-gmp" to the end of your mk/build.mk (or edit mk/config.mk.in locally), and you'll get the "old" integer-gmp which worked previously, so you can continue hacking on GHC HEAD while I figure out what's broken for you with `integer-gmp2` (assuming you reported the issue to me...). Cheers, hvr [1]: http://git.haskell.org/ghc.git/commitdiff/c774b28f76ee4c220f7c1c9fd81585e0e…

1 0

Re: [GHC] #9781: Make list monad operations fuse
by Kim-Ee Yeoh 11 Nov '14

11 Nov '14

>From the patch fragment at https://phabricator.haskell.org/D455?id=1311#inline-3123 What's the justification for expanding out the definition of mapM from "sequence . map f" into do-notation and duplicated code? Observe how mapM now duplicates code from sequence. The absence of benchmarks is bad enough. What's worse is that the given excuse boils down to "Pity the poor compiler! Let's take over its work instead. Like, just in case, you know." This optimization work needs to take place at a higher level, with deep understanding of existing compiler transformations. Otherwise, it's all a code-muddying crapshoot in the dark. -- Kim-Ee On Tue, Nov 11, 2014 at 2:22 PM, GHC <ghc-devs(a)haskell.org> wrote: > #9781: Make list monad operations fuse > -------------------------------------+------------------------------------- > Reporter: dfeuer | Owner: dfeuer > Type: task | Status: patch > Priority: normal | Milestone: 7.10.1 > Component: Core | Version: 7.9 > Libraries | Keywords: > Resolution: | Architecture: Unknown/Multiple > Operating System: | Difficulty: Unknown > Unknown/Multiple | Blocked By: > Type of failure: Runtime | Related Tickets: > performance bug | > Test Case: | > Blocking: | > Differential Revisions: Phab:D455 | > -------------------------------------+------------------------------------- > > Comment (by Herbert Valerio Riedel <hvr@…>): > > In [changeset:"4923cea56345060faaf77e4c475eac6aa3c77506/ghc"]: > {{{ > #!CommitTicketReference repository="ghc" > revision="4923cea56345060faaf77e4c475eac6aa3c77506" > Define list monad operations using comprehensions > > Define list monad operations using list comprehensions. Code using monad > operations with lists did not fuse fully. Writing list code with `do` > notation or `(>>=)` and `(>>)` operations could allocate more than > equivalent code using list comprehensions. > > Define `mapM` directly, instead of using `sequence` and `map`. This > leads to substantially less allocation in `cryptarithm2`. > > Addresses #9781 > > Reviewed By: ekmett, nomeata > > Differential Revision: https://phabricator.haskell.org/D455 > }}} > > -- > Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9781#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 >

3 4