September 2013 - ghc-devs

GHC 7.8 release status
by Simon Peyton-Jones 15 Nov '13

15 Nov '13

Friends The 7.8 release is imminent. This email is to ask abou the status of your contributions. In each case could you update the wiki with the current state of play, and your intentions, including dates. That is, don't put your reply in email: it on the status page below; though by all means send email too! Summary here: http://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8 Also : What is missing from the list that should be done? · Patrick Palka: status of ghc -make -j? · Nick: status of your three items? · Pedro/Richard: is all the Typeable stuff, and gcast and friends, finished? · Geoff: what about the new Template Haskell story? · Iavor: when do you think you can merge? · Austin: what about ARMv7? · Edsko/Thomas/Luite: if you want anything for 7.8 it'll have to be jolly soon. At the moment I don't even know the motivation or design, let alone implementation. Could you make a wiki page explaining the proposed design? Is it really important to do this for 7.8? · Dynamic GHCi. I have no idea who is driving this, or how important it is. · Ryan: atomic stuff. All merged? · AMP warnings: David Luposchainsky is driving this. Thanks! Simon Microsoft Research Limited (company number 03369488) is registered in England and Wales Registered office is at 21 Station Road, Cambridge, CB1 2FB

7 10

Restrictions on polytypes with type families
by Richard Eisenberg 12 Nov '13

12 Nov '13

Hi all, GHC doesn't allow type families to be used with polytypes: 1) The right-hand side of a type family instance cannot have a "forall". 2) A type family cannot be applied to a type containing a "forall". 3) A pattern in a type family instance is (oddly) allowed to contain "forall", but this is silly because of (2). Do these restrictions have known reasons for their existence? Or, are there any that are restricted because someone needs to think hard before lifting it, and no one has yet done that thinking? I know, for example, that the unify function in types/Unify.lhs will have to be completed to work with foralls, but this doesn't seem hard. I've run into two separate cases where I've hit this restriction, so this isn't just idle thought. Thanks, Richard

8 15

simd branch ready for review/merge
by Geoffrey Mainland 07 Nov '13

07 Nov '13

The SIMD branch, available as wip/simd, is ready for review/merge. It could use some review---Simon and Simon, I'd be especially grateful if you both had a quick look. Some major points: 1) I have added support for AVX 512, although this is necessarily untested. AVX and AVX2 are also both supported. 2) After the recent churn regarding patching LLVM's GHC calling convention, by default only 128-bit wide SIMD vectors are passed in registers, and then only on X86_64. There is a "hidden" flag, -fllvm-pass-vectors-in-regs, that causes GHC to generate LLVM code that assumes all vectors are passed in registers by LLVM. This can be used with a suitably patched version of LLVM, and if we get LLVM 3.4 patched, we can consider turning it on by default for LLVM 3.4+. This would mean that we couldn't mix LLVM <3.3-compiled object files with LLVM >3.4-compiled object files, but I don't see that as much of a problem. 3) utils/genprimcode has been hacked up to allow us to write vector operations once and have them instantiated at multiple vector types. I'm not thrilled with this solution, but after discussing with Simon PJ, what I've implemented seems to be the minimal reasonable solution to the problem of exploding primop boilerplate. The changes are documented in compiler/prelude/primops.txt.pp. 4) Error handling is sub-optimal. My patch checks to make sure that vector primops can be compiled efficiently based on the current set of dynamic flags. For example, if -mavx is not specified and the user tries to use a primop that adds together two 256-bit wide vectors of double-precision elements, the user will see an error message like: ghc-stage2: sorry! (unimplemented feature or known bug) (GHC version 7.7.20130916 for x86_64-unknown-linux): 256-bit wide floating point SIMD vector instructions require at least -mavx. This is because the only good place to check for this kind of error is during STG->Cmm translation (in compiler/codeGen/StgCmmPrim.hs), and we don't have much of an error handling infrastructure there in contrast to when we're working in the typechecking/renaming monad. If there is a better way/place to do this, please let me know. Thanks, Geoff

4 8

Build error: No (or multiple) ghc rts package is registered
by Roman Cheplyaka 15 Oct '13

15 Oct '13

Hi, I tried to build GHC HEAD today, but eventually got this error: ghc-cabal: No (or multiple) ghc rts package is registered!! make[1]: *** [libraries/ghc-prim/dist-install/package-data.mk] Error 1 make: *** [all] Error 2 I did "make clean" before starting the build — is it not sufficient? Roman

2 3

HEAD vs Hackage status report
by Bryan O'Sullivan 10 Oct '13

10 Oct '13

I spent a little time the other day building all of Hackage with GHC HEAD. Here's a quick writeup of what I found. Total packages: 5564 Succeeded with 7.6.3: 3234 Succeeded with HEAD: 2061 Succeeded with 7.6.3 *but failed with HEAD: 1186* (A few dozen packages built with HEAD, but not with 7.6.3, which is why the numbers don't add up.) I think the condensed version of the story is that we're actually in good shape, the above numbers notwithstanding. There are only a few categories of build regression, which I detail below. Except for one genuine bug, the rest (at least those I've seen so far) are upgrade details that could be written about in release notes or a blog post. There currently exists just one panic-related bug, which prevents all 23 packages in the Snap web framework from building: ghc: panic! (the 'impossible' happened) (GHC version 7.7.20130923 for x86_64-unknown-linux): dmdTransformDictSelSig: split failed<http://ghc.haskell.org/trac/ghc/ticket/8329> Of the 1186 packages that build with 7.6.3 but not HEAD: 311 fail due to cabal being unable to solve dependency constraints. As usual, most (195) have excessively tight constraints on base. 37 packages fail due to GeneralizedNewtypeDeriving and the new role infrastructure, due to the following failures in packages upon which they depend. 12 language-c-0.4.2 the last parameter of ‛Error’ is at role Nominal 11 logfloat-0.12.1 the last parameter of ‛IArray’ is at role Nominal 5 diagrams-lib-0.7.1.1 the last parameter of ‛Transformable’ is at role Nominal 4 smallcheck-1.0.4 the last parameter of ‛MonadLogic’ is at role Nominal 2 monadiccp-0.7.6 the last parameter of ‛ReaderM’ is at role Nominal 2 histogram-fill-0.8.1.0 the last parameter of ‛BinEq’ is at role Nominal 1 acme-schoenfinkel-0.1.1 the last parameter of ‛ArrowApply’ is at role Nominal There's quite a bit of transitive primop-related breakage. 364 template-haskell-2.8.0.0 Couldn't match expected type ‛Bool’ with actual type ‛Int#’ 48 primitive-0.4.1 Couldn't match expected type ‛Bool’ with actual type ‛Int#’ 6 primitive-0.5.0.1 Couldn't match expected type ‛Bool’ with actual type ‛Int#’ Most of the breakage could be fixed by loosening the dependencies on the template-haskell and primitive packages, and here are the rest. 63 uulib-0.9.15 Couldn't match expected type ‛Bool’ with actual type ‛Int#’ 20 utf8-light-0.4.0.1 Couldn't match expected type ‛Bool’ with actual type ‛Int#’ 19 safeint-0.5.3 Couldn't match expected type ‛Bool’ with actual type ‛Int#’ 16 permutation-0.4.1 Couldn't match expected type ‛Bool’ with actual type ‛Int#’ 9 floatshow-0.2.3 Couldn't match expected type ‛Bool’ with actual type ‛Int#’ 9 bytestring-show-0.3.5.5 Couldn't match expected type ‛Bool’ with actual type ‛Int#’ 8 STMonadTrans-0.3.1 Couldn't match expected type ‛Bool’ with actual type ‛Int#’ 7 hashtables-1.1.0.2 Couldn't match expected type ‛Bool’ with actual type ‛Int#’ 2 word24-1.0.3 Couldn't match expected type ‛Bool’ with actual type ‛Int#’ 2 arithmoi-0.4.0.3 Couldn't match expected type ‛Bool’ with actual type ‛Int#’ 1 word8-0.0.3 Couldn't match expected type ‛Bool’ with actual type ‛Int#’ 1 IORefCAS-0.2.0.1 Couldn't match expected type ‛Bool’ with actual type ‛Int#’ Roughly 45 packages are broken by changes to Typeable.

7 8

newSession
by Kazu Yamamoto 02 Oct '13

02 Oct '13

Hi, It seems to me that "newSession" does not exist. But it is used in comments and error messages. % grep -r newSession * compiler/main/DynFlags.hs:-- | Used by 'GHC.newSession' to partially initialize a new 'DynFlags' value compiler/main/DynFlags.hs:-- and must be fully initialized by 'GHC.newSession' first. compiler/main/StaticFlags.hs: when ready $ throwGhcExceptionIO (ProgramError "Too late for parseStaticFlags: call it before newSession") compiler/main/StaticFlags.hs: then panic "Static flags have not been initialised!\n Please call GHC.newSession or GHC.parseStaticFlags early enough." I think they should be updated. --Kazu

3 3

I've moved the primitive package to github
by Bryan O'Sullivan 30 Sep '13

30 Sep '13

Roman seems to have gone silent, and primitive being broken with GHC HEAD means that there's a ton of packages we can't build right now. Accordingly, I've imported the old darcs repo into git and published it on github. https://github.com/haskell/primitive Austin, please plan to fix the GHC build to get its copy of primitive from here, once we have it working with HEAD.

5 14

Re: [commit: ghc] master: Fix AMP warnings for explicit Prelude imports (#8004) (b9127f4)
by Patrick Palka 30 Sep '13

30 Sep '13

On Sun, Sep 29, 2013 at 9:10 PM, <git(a)git.haskell.org> wrote: > + isPrelude :: ImportDecl Name -> Bool > + isPrelude = (== "Prelude") . moduleNameString . unLoc . ideclName Can't you just do unLoc (ideclName imp) == pRELUDE_NAME here?

2 1

Re: [commit: packages/base] master: Expose performMinorGC (#8257) (c1491e6)
by Christiaan Baaij 30 Sep '13

30 Sep '13

Shouldn't the last line of the patch be?: > +foreign import ccall "performGC" performMinorGC :: IO () the rts doesn't export a function called "performMinorGC". -- Christiaan On Sep 30, 2013, at 12:24 AM, git(a)git.haskell.org wrote: > Repository : ssh://git@git.haskell.org/base > > On branch : master > Link : http://ghc.haskell.org/trac/ghc/changeset/c1491e683d3edc31fd20bd3b3021d3a62… > >> --------------------------------------------------------------- > > commit c1491e683d3edc31fd20bd3b3021d3a620aa0184 > Author: Austin Seipp <austin(a)well-typed.com> > Date: Sun Sep 29 09:42:06 2013 -0500 > > Expose performMinorGC (#8257) > > Signed-off-by: Austin Seipp <austin(a)well-typed.com> > > >> --------------------------------------------------------------- > > c1491e683d3edc31fd20bd3b3021d3a620aa0184 > System/Mem.hs | 20 ++++++++++++++------ > 1 file changed, 14 insertions(+), 6 deletions(-) > > diff --git a/System/Mem.hs b/System/Mem.hs > index f162a75..2ad75ce 100644 > --- a/System/Mem.hs > +++ b/System/Mem.hs > @@ -14,11 +14,19 @@ > -- > ----------------------------------------------------------------------------- > > -module System.Mem ( > - performGC > - ) where > - > +module System.Mem > + ( performGC > + , performMajorGC > + , performMinorGC > + ) where > import Prelude > > --- | Triggers an immediate garbage collection > -foreign import ccall {-safe-} "performMajorGC" performGC :: IO () > +-- | Triggers an immediate garbage collection. > +performGC :: IO () > +performGC = performMajorGC > + > +-- | Triggers an immediate garbage collection. > +foreign import ccall "performMajorGC" performMajorGC :: IO () > + > +-- | Triggers an immediate minor garbage collection. > +foreign import ccall "performMinorGC" performMinorGC :: IO () > > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits

1 0

Re: [GHC] #8173: GHC uses nub
by Kim-Ee Yeoh 29 Sep '13

29 Sep '13

On Sun, Sep 29, 2013 at 2:56 PM, GHC <ghc-devs(a)haskell.org> wrote: > According to the results, sadly the 5% performance gain in compile time > was complete bogus. Sorry. =( > Does anyone have any insight into why? How can a future benchmark avoid such bogusity? The only -- I might add, implicit -- rec is to run things twice. -- Kim-Ee

1 0