- ghc-devs - Haskell.org

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

Control.Exception.assert vs HsVersions.h's ASSERT?
by RodLogic 11 Nov '14

11 Nov '14

Having spent a bit of time staring at GHC's sources, I noticed that there are around 140 modules using a set of C macros for assertions, namely: ASSERT > ASSERT2 > MASSERT > MASSERT2 > ASSERTM > ASSERTM2 However, I see that Control.Exception already provides a first class Haskell assertion function: assert :: Bool -> a -> a that is turned off automatically when optimizations are turned on, and provides an error containing the filename and line number, which was why I thought the above macros existed and were still in use. My question is: is there any reason to keep using these macros instead of *assert*?

1 0

RFC: Concrete syntax for pattern synonym type signatures
by Dr. ERDI Gergo 11 Nov '14

11 Nov '14

Background ---------- As explained on https://ghc.haskell.org/trac/ghc/wiki/PatternSynonyms#Staticsemantics the type of a pattern synonym can be fully described with the following pieces of information: * If the pattern synonym is bidirectional * Universially-bound type variables, and required constraints on them * The type of the pattern itself, closed over the universially-bound type variables * Existentially-bound type variables, and the constraints provided by them * The types of the arguments, closed over the universially and existentially bound type variables Here's an example showing all of these axes in action: data T a b where MkT :: (Eq a, Ord b, Show c) => a -> (b, b) -> c -> T a b pattern P x y = MkT 5 (y, True) x In this case: * The name of the pattern synonym is `P` * The pattern synonym is bidirectional * The universially-bound tyvars/required constraints are `forall a. Num a` * The type of the pattern is `T a Bool` * The existentially-bound tyvars/provided constraints are `forall c. (Eq a, Ord Bool, Show c)` * The type of the arguments are `c` and `Bool`. The problem, then, is finding a concrete syntax that captures all of this information. This syntax is needed for at least two purposes: * Showing pattern synonym type information in Haddock/GHCi * Pattern synonym type signatures (#8584) Current state of things ----------------------- GHCi 7.8.3 shows the type above as: pattern (Eq t, Ord Bool, Show c) => P c Bool :: Num t => (T t Bool) Not only does it not show directionality, I think this is very confusing in every other way as well, especially with explicit foralls: pattern forall c. (Eq t, Ord Bool, Show c) => P c Bool :: forall t. Num t => (T t Bool) I am currently working on implementing #8584, which means I need to parse these type signatures. I managed to get the above monstrosity to parse (unambigiously from actual pattern synonym definitions) by throwing in an extra 'type' keyword: pattern type (Eq t, Ord Bool, Show c) => P c Bool :: Num t => (T t Bool) Request for help ---------------- Surely we can do better than that! So let's come up with a nice syntax for pattern synonym type signatures. It will be used in the pattern synonym type signature annotations of GHC 7.10, and we could also retrofit it into GHC 7.8.4 and its Haddock, so that documentation generated with today's tools will look consistent with code you will be able to enter in tomorrow's version. Bye, Gergo

5 25

RE: [commit: ghc] master: Define list monad operations using comprehensions (4923cea)
by Simon Peyton Jones 11 Nov '14

11 Nov '14

The "Note" doesn't mention one of the main points, which is (if I understand rightly) to improve fusion. Would it be wotth making this point, and giving an example in the Note? Simon | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces@haskell.org] On Behalf | Of git(a)git.haskell.org | Sent: 11 November 2014 07:23 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] master: Define list monad operations using | comprehensions (4923cea) | | Repository : ssh://git@git.haskell.org/ghc | | On branch : master | Link : | http://ghc.haskell.org/trac/ghc/changeset/4923cea56345060faaf77e4c475e | ac6aa3c77506/ghc | | >--------------------------------------------------------------- | | commit 4923cea56345060faaf77e4c475eac6aa3c77506 | Author: David Feuer <David.Feuer(a)gmail.com> | Date: Tue Nov 11 07:59:34 2014 +0100 | | 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 | | | >--------------------------------------------------------------- | | 4923cea56345060faaf77e4c475eac6aa3c77506 | libraries/base/GHC/Base.hs | 51 | +++++++++++++++++++++++++++++++++++++++------- | 1 file changed, 44 insertions(+), 7 deletions(-) | | diff --git a/libraries/base/GHC/Base.hs b/libraries/base/GHC/Base.hs | index 501a6d5..0d20e34 100644 | --- a/libraries/base/GHC/Base.hs | +++ b/libraries/base/GHC/Base.hs | @@ -225,8 +225,32 @@ class Monoid a where | mconcat = foldr mappend mempty | | instance Monoid [a] where | + {-# INLINE mempty #-} | mempty = [] | + {-# INLINE mappend #-} | mappend = (++) | + {-# INLINE mconcat #-} | + mconcat xss = [x | xs <- xss, x <- xs] | +-- See Note: [List comprehensions and inlining] | + | +{- | +Note: [List comprehensions and inlining] | +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | +The list monad operations are traditionally described in terms of | concatMap: | + | +xs >>= f = concatMap f xs | + | +Similarly, mconcat for lists is just concat. Here in Base, however, | we | +don't have concatMap, and we'll refrain from adding it here so it | won't | +have to be hidden in imports. Instead, we use GHC's list | comprehension | +desugaring mechanism to define mconcat and the Applicative and Monad | instances for lists. | +We mark them INLINE because the inliner is not generally too keen to | +inline build forms such as the ones these desugar to without our | +insistence. Defining these using list comprehensions instead of | foldr | +has an additional potential benefit, as described in | +compiler/deSugar/DsListComp.lhs: if optimizations needed to make | +foldr/build forms efficient are turned off, we'll get reasonably | efficient translations anyway. | +-} | | instance Monoid b => Monoid (a -> b) where | mempty _ = mempty | @@ -501,7 +525,9 @@ sequence ms = foldr k (return []) ms | -- | @'mapM' f@ is equivalent to @'sequence' . 'map' f@. | mapM :: Monad m => (a -> m b) -> [a] -> m [b] {-# INLINE mapM #-} | -mapM f as = sequence (map f as) | +mapM f as = foldr k (return []) as | + where | + k a r = do { x <- f a; xs <- r; return (x:xs) } | | -- | Promote a function to a monad. | liftM :: (Monad m) => (a1 -> r) -> m a1 -> m r | @@ -667,16 +693,27 @@ instance MonadPlus Maybe | -- The list type | | instance Functor [] where | + {-# INLINE fmap #-} | fmap = map | | +-- See Note: [List comprehensions and inlining] | instance Applicative [] where | - pure = return | - (<*>) = ap | - | -instance Monad [] where | - m >>= k = foldr ((++) . k) [] m | - m >> k = foldr ((++) . (\ _ -> k)) [] m | + {-# INLINE pure #-} | + pure x = [x] | + {-# INLINE (<*>) #-} | + fs <*> xs = [f x | f <- fs, x <- xs] | + {-# INLINE (*>) #-} | + xs *> ys = [y | _ <- xs, y <- ys] | + | +-- See Note: [List comprehensions and inlining] instance Monad [] | +where | + {-# INLINE (>>=) #-} | + xs >>= f = [y | x <- xs, y <- f x] | + {-# INLINE (>>) #-} | + (>>) = (*>) | + {-# INLINE return #-} | return x = [x] | + {-# INLINE fail #-} | fail _ = [] | | instance Alternative [] where | | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | http://www.haskell.org/mailman/listinfo/ghc-commits

1 0

RE: [GHC] #9741: Interpreter stack checks are not quite right
by Simon Peyton Jones 11 Nov '14

11 Nov '14

| Oh, and the reason you have the debug RTS in your compiler is because | `-ticky` implies `-debug Interesting. I didn't know that. Is that a good idea? Wouldn't it be better to make them independent? Simon | -----Original Message----- | From: ghc-tickets [mailto:ghc-tickets-bounces@haskell.org] On Behalf | Of GHC | Sent: 06 November 2014 08:37 | Cc: ghc-tickets(a)haskell.org | Subject: Re: [GHC] #9741: Interpreter stack checks are not quite right | | #9741: Interpreter stack checks are not quite right | -------------------------------------+-------------------------------- | -- | -------------------------------------+--- | Reporter: simonpj | Owner: simonmar | Type: bug | Status: closed | Priority: highest | Milestone: 7.10.1 | Component: Compiler | Version: 7.8.3 | Resolution: fixed | Keywords: | Operating System: | Architecture: | Unknown/Multiple | Unknown/Multiple | Difficulty: Unknown | Type of failure: | Blocked By: | None/Unknown | Related Tickets: | Test Case: | | Blocking: | | Differential Revisions: | | -------------------------------------+-------------------------------- | -- | -------------------------------------+--- | | Comment (by simonmar): | | Oh, and the reason you have the debug RTS in your compiler is because | `-ticky` implies `-debug`. Incidentally this is probably slowing down | your builds quite a lot, so you might want to turn it off. | | -- | Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9741#comment:5> | 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 1

Re: [Msys2-users] Debugging undeterministic segfaults
by David Macek 10 Nov '14

10 Nov '14

On 4. 11. 2014 1:30, Ray Donnelly wrote: > Finally, can anyone else confirm the problem? I'm sorry if I missed it, but I can't find what source version you're using, Gintautas. Release/trunk? -- David Macek

3 15