- ghc-devs - Haskell.org

[PATCH] fix rts exported symbols base_GHCziIOziException_allocationLimitExceeded_closure
by Sergei Trofimovich 03 May '14

03 May '14

From: Sergei Trofimovich <slyfox(a)gentoo.org> Commit b0534f78a73f972e279eed4447a5687bd6a8308e added new exported rts symbols, but slightly misspelled them. Observer on first compiled program: > Linking dist/build/haskell-updater/haskell-updater ... > /usr/lib64/ghc-7.9.20140503/rts-1.0/libHSrts.a(Schedule.o): In function `scheduleWaitThread': > (.text+0xc4c): undefined reference to `base_GHCziIOziException_allocationLimitExceeded_closure' > /usr/lib64/ghc-7.9.20140503/rts-1.0/libHSrts.a(RtsStartup.o): In function `hs_init_ghc': > (.text+0x2fa): undefined reference to `base_GHCziIOziException_allocationLimitExceeded_closure' > collect2: error: ld returned 1 exit status CC: Simon Marlow <marlowsd(a)gmail.com> Signed-off-by: Sergei Trofimovich <slyfox(a)gentoo.org> --- rts/package.conf.in | 4 ++-- rts/win32/libHSbase.def | 1 + 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/rts/package.conf.in b/rts/package.conf.in index 25fb5eb..914dd9c 100644 --- a/rts/package.conf.in +++ b/rts/package.conf.in @@ -98,7 +98,7 @@ ld-options: , "-Wl,-u,_base_ControlziExceptionziBase_nonTermination_closure" , "-Wl,-u,_base_GHCziIOziException_blockedIndefinitelyOnMVar_closure" , "-Wl,-u,_base_GHCziIOziException_blockedIndefinitelyOnSTM_closure" - , "-Wl,-u,_base_GHCziIOziException_allocationQuotaExceeded_closure" + , "-Wl,-u,_base_GHCziIOziException_allocationLimitExceeded_closure" , "-Wl,-u,_base_ControlziExceptionziBase_nestedAtomically_closure" , "-Wl,-u,_base_GHCziWeak_runFinalizzerBatch_closure" , "-Wl,-u,_base_GHCziTopHandler_flushStdHandles_closure" @@ -139,7 +139,7 @@ ld-options: , "-Wl,-u,base_ControlziExceptionziBase_nonTermination_closure" , "-Wl,-u,base_GHCziIOziException_blockedIndefinitelyOnMVar_closure" , "-Wl,-u,base_GHCziIOziException_blockedIndefinitelyOnSTM_closure" - , "-Wl,-u,base_GHCziIOziException_allocationQuotaExceeded_closure" + , "-Wl,-u,base_GHCziIOziException_allocationLimitExceeded_closure" , "-Wl,-u,base_ControlziExceptionziBase_nestedAtomically_closure" , "-Wl,-u,base_GHCziWeak_runFinalizzerBatch_closure" , "-Wl,-u,base_GHCziTopHandler_flushStdHandles_closure" diff --git a/rts/win32/libHSbase.def b/rts/win32/libHSbase.def index 119237b..6bb19da 100644 --- a/rts/win32/libHSbase.def +++ b/rts/win32/libHSbase.def @@ -36,6 +36,7 @@ EXPORTS base_GHCziPack_unpackCString_closure base_GHCziIOziException_blockedIndefinitelyOnMVar_closure base_GHCziIOziException_blockedIndefinitelyOnSTM_closure + base_GHCziIOziException_allocationLimitExceeded_closure base_GHCziIOziException_stackOverflow_closure base_ControlziExceptionziBase_nonTermination_closure -- 1.9.2

1 0

validate on Mavericks
by Kazu Yamamoto 02 May '14

02 May '14

Hi, Many tests for validate on master fail on Mavericks. This is because clang produces some warnings. Here is an example: =====> AssocTyDef03(normal) 3519 of 3960 [0, 1649, 0] cd ./typecheck/should_fail && '/Users/kazu/work/ghc/bindisttest/install dir/bin/ghc ' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopt s -fno-ghci-history -c AssocTyDef03.hs >AssocTyDef03.comp.stderr 2>&1 --- ./typecheck/should_fail/tcfail218.stderr 2014-04-23 09:26:45.000000000 +0900 +++ ./typecheck/should_fail/tcfail218.comp.stderr 2014-05-01 11:28:31.000000000 +0900 @@ -1,3 +1,6 @@ +clang: warning: argument unused during compilation: '-fno-stack-protector' +clang: warning: argument unused during compilation: '-D TABLES_NEXT_TO_CODE' +clang: warning: argument unused during compilation: '-I .' tcfail218.hs:10:5: Overlapping instances for C [a] b arising from a use of ‘foo’ Any ideas to fix this? --Kazu

2 2

Relocating (some of) GHC's core-libraries to github.com/haskell
by Herbert Valerio Riedel 02 May '14

02 May '14

Hi GHC devs, In accordance with Edward and Austin, I want to move the primary home of the non-GHC specific core-library packages to the http://github.com/haskell/ organization. Specifically, I plan to move the following package Git repositories to the github.com/haskell organization: - array - directory - filepath - old-locale - old-time - process - stm - unix (N.B.: the 'Win32' package already lives at github.com/haskell) I'm not sure yet about the following packages, those are not officially maintained by the committee (@Simon, maybe you can state your preference where you want your packages to be hosted/issue-tracked in the future?) - parallel - deepseq - hpc - hoopl - haskell2010 - haskell98 The practical effects to GHC developers of this switch would be that: - Issue tracking for those packages moves over to GitHub. (the official maintaing entity is the core-library committee) - In ghc.git those packages will be *turned into Git submodules* (i.e. they will be handled just like the other existing 3rd party upstream packages such as 'Win32' or 'Cabal' are already handled[1], see also next item) - Using pull-requests on GitHub is highly recommended for submitting changes which are not urgent (instead of diverging the respective git.haskell.org lagged mirror repo) -- note also that pull-requests will be validated by Travis-CI for multiple GHC versions to help detect compat-breaking changes. However, GHC developers can easily be given push-rights to the respective repos in the github.com/haskell/ organization should this turn out to be a more appropriate workflow. [1]: https://ghc.haskell.org/trac/ghc/wiki/Repositories/Upstream#Modifiyinglibra… PS: 'haddock.git' is planned to move its issue tracking over to GitHub as well, however it's going to be handled slightly different (mostly because haddock is tightly coupled to the GHC API) and will be explained in more detail in a future separate email. Cheers, hvr

6 10

Unexpected failure to inline, even with pragma
by p.k.f.holzenspies＠utwente.nl 02 May '14

02 May '14

Dear GHC-ers, It seems I do not quite understand the behaviour of the inliner. Consider these two modules: module Foo.Bar where foo :: Char -> IO () foo = putChar {-# INLINE bar #-} bar :: String -> IO () bar = mapM_ foo module Main where import Foo.Bar main = bar "done" I would expect the inliner to produce at least (considering the pragma) main = mapM_ foo "done" or maybe even main=mapM_ putChar "done" However, when I compile this code, that inlining does not seem to happen: $ ghc -ddump-inlinings -fforce-recomp Main.hs [1 of 2] Compiling Foo.Bar ( Foo/Bar.hs, Foo/Bar.o ) Inlining done: Foo.Bar.foo [2 of 2] Compiling Main ( Main.hs, Main.o ) Linking Main ... Indeed, when I use -ddump-simpl, ghc reports: ==================== Tidy Core ==================== Result size of Tidy Core = {terms: 7, types: 5, coercions: 0} Main.main :: GHC.Types.IO () [GblId, Str=DmdType] Main.main = Foo.Bar.bar (GHC.CString.unpackCString# "done"#) :Main.main :: GHC.Types.IO () [GblId, Str=DmdType] :Main.main = GHC.TopHandler.runMainIO @ () Main.main Can anyone explain why Foo.Bar.bar isn't inlined in Main.main? Regards, Philip

3 3

Overloaded record fields: we ought to change the name of FldTy
by Johan Tibell 01 May '14

01 May '14

Hi, I'm currently watching the Skills Matter talks you gave (great!) and I'm slightly worried that we're going to expose beginners (and intermediate users!) to a name called FldTy, which might be OK for a GHC-internal name, but is not very readable. If this is going to be exposed to users, could we name is something readable, like FieldType, Field, or something similar? -- Johan

3 3

Related to #8677, I'm getting "p_dyn" libraries for package ‘integer-gmp’
by Rob Stewart 01 May '14

01 May '14

HI, I'm getting hit by an issue relating to tick 8677 https://ghc.haskell.org/trac/ghc/ticket/8677 I'm sure the problem I'm facing is a user error, though I'm not sure how to resolve it. I'm compiling with `-Odph -rtsopts -threaded -fno-liberate-case -funfolding-use-threshold1000 -funfolding-keeness-factor1000 -fllvm -optlo-O3 -prof -auto-all` --8<---------------cut here---------------start------------->8--- Top level: Failed to load interface for ‘GHC.Integer.Type’ Perhaps you haven't installed the "p_dyn" libraries for package ‘integer-gmp’? Use -v to see a list of the files searched for. cabal: Error: some packages failed to install: ripl-frontend-0.0.1 failed during the building phase. The exception was: ExitFailure 1--8<---------------cut here---------------end--------------->8--- >From reading the ticket details, I see that I probably should not be using -dynamic-too. But how do I enforce this? I'm not using this flag (see above). Moreover my ~/.cabal/config files includes the following: --8<---------------cut here---------------start------------->8--- library-profiling: False executable-dynamic: False executable-profiling: False --8<---------------cut here---------------end--------------->8--- What else am I to do? -- Rob

1 0

Removing -fext-core
by Austin Seipp 30 Apr '14

30 Apr '14

Hello all, Recently I was wondering something: is there any reason to keep -fext-core around? In particular, it's been broken for a while at this point, see GHC bug #5630[1] As far as I'm aware there really aren't any users of it still around these days, at least none working with a modern GHC. And it seems like if people were to need access to Core, they could use a plugin or some such to get direct access to what they want. Simon mentioned removing ExtCore in face of replacing it with IfaceSyn in the compiler. I'm not entirely sure how much work that would be to bring it all up to scratch if people needed it, but maybe it's worth thinking about. One other issue is a notion of semantics which is present in External Core, but we also now have a documented semantics for GHC's core language as well (which has evolved quite a bit), so I don't know how much that matters. So long story short: I don't think anyone is using it, maintaining it, and it seems subsumed by more recent events. Therefore, if nobody objects, I'd vote to remove -fext-core from GHC, unless someone is willing to step up and really maintain it. If you're using it, you should probably speak up soon I'd imagine... [1] https://ghc.haskell.org/trac/ghc/ticket/5630 -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

4 4

RE: [commit: ghc] master: Improve implementation of unSubCo_maybe. (a3896ab)
by Simon Peyton Jones 29 Apr '14

29 Apr '14

Richard, Looks good, but *surely* worth a Note [unSubCo] in the file? It's manifestly non-obvious or you'd have done this from day 1. Moreover, the *reason* Conal needed it, and the new optimsations it enables, are also non-obvious and deserve examples! Evernyone: my obsession with Notes is born of the hours I have spent staring at code that has cases I don't understand; or "fixing" something turned out to be there for a good but undocumented reason. Going back to unSubCo, I think the start of the documentation could be if g :: t1 ~R t2 then unSubCo g :: t ~N t2 (if it succeeds at all). But why do we need it? And what optimisations do we get? Thanks Simon | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces@haskell.org] On Behalf Of | git(a)git.haskell.org | Sent: 29 April 2014 00:51 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] master: Improve implementation of unSubCo_maybe. | (a3896ab) | | Repository : ssh://git@git.haskell.org/ghc | | On branch : master | Link : | http://ghc.haskell.org/trac/ghc/changeset/a3896ab5d2dc88160f710705bf23e6 | e25e327da5/ghc | | >--------------------------------------------------------------- | | commit a3896ab5d2dc88160f710705bf23e6e25e327da5 | Author: Richard Eisenberg <eir(a)cis.upenn.edu> | Date: Mon Apr 28 13:33:13 2014 -0400 | | Improve implementation of unSubCo_maybe. | | This is the result of an email conversation (off list) with | Conal Elliott, who needed a stronger unSubCo_maybe. This | commit adds cases to upgrade the role of a coercion when | recursion is necessary to do say (for example, for a use of | TransCo). As a side effect, more coercion optimizations are | now possible. | | This was not done previously because unSubCo_maybe was used | only during coercion optimization, and the recursive cases | looked to be unlikely. However, adding them can cause no harm. | | unSubCo_maybe is now also exported from Coercion, for use | cases like Conal's. | | | >--------------------------------------------------------------- | | a3896ab5d2dc88160f710705bf23e6e25e327da5 | compiler/types/Coercion.lhs | 20 +++++++++++++++----- | 1 file changed, 15 insertions(+), 5 deletions(-) | | diff --git a/compiler/types/Coercion.lhs b/compiler/types/Coercion.lhs | index af2b2fa..f60fcbd 100644 | --- a/compiler/types/Coercion.lhs | +++ b/compiler/types/Coercion.lhs | @@ -38,7 +38,7 @@ module Coercion ( | splitAppCo_maybe, | splitForAllCo_maybe, | nthRole, tyConRolesX, | - nextRole, | + nextRole, unSubCo_maybe, | | -- ** Coercion variables | mkCoVar, isCoVar, isCoVarType, coVarName, setCoVarName, | setCoVarUnique, @@ -1051,16 +1051,26 @@ maybeSubCo2 r1 r2 co | | -- if co is Nominal, returns it; otherwise, unwraps a SubCo; otherwise, | fails unSubCo_maybe :: Coercion -> Maybe Coercion | +unSubCo_maybe co | + | Nominal <- coercionRole co = Just co | unSubCo_maybe (SubCo co) = Just co | unSubCo_maybe (Refl _ ty) = Just $ Refl Nominal ty -unSubCo_maybe | (TyConAppCo Representational tc cos) | - = do { cos' <- mapM unSubCo_maybe cos | +unSubCo_maybe (TyConAppCo Representational tc coes) | + = do { cos' <- mapM unSubCo_maybe coes | ; return $ TyConAppCo Nominal tc cos' } unSubCo_maybe (UnivCo | Representational ty1 ty2) = Just $ UnivCo Nominal ty1 ty2 | -- We do *not* promote UnivCo Phantom, as that's unsafe. | -- UnivCo Nominal is no more unsafe than UnivCo Representational - | unSubCo_maybe co | - | Nominal <- coercionRole co = Just co | +unSubCo_maybe (TransCo co1 co2) | + = TransCo <$> unSubCo_maybe co1 <*> unSubCo_maybe co2 unSubCo_maybe | +(AppCo co1 co2) | + = AppCo <$> unSubCo_maybe co1 <*> pure co2 unSubCo_maybe (ForAllCo tv | +co) | + = ForAllCo tv <$> unSubCo_maybe co | +unSubCo_maybe (NthCo n co) | + = NthCo n <$> unSubCo_maybe co | +unSubCo_maybe (InstCo co ty) | + = InstCo <$> unSubCo_maybe co <*> pure ty | unSubCo_maybe _ = Nothing | | -- takes any coercion and turns it into a Phantom coercion | | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | http://www.haskell.org/mailman/listinfo/ghc-commits

3 4

optllvm failures
by Daniel Fischer 29 Apr '14

29 Apr '14

I have done a bit of testing with regards to my optllvm failures in the testsuite. Some tests compile but segfault when they are run, others fail to compile, both with HEAD and 7.8.2, but those I tested all work with 7.6.3, although 7.6 gives the warning: You are using a new version of LLVM that hasn't been tested yet! We will try though... I suspect that the LLVM backend thinks I have a different version than I actually have, or maybe the LLVM tools think I have a different CPU than I have: dafis@schwartz:~/JNthPrime> llc --version LLVM (http://llvm.org/) LLVM version 3.2svn Optimized build. Default target: x86_64-unknown-linux-gnu Host CPU: corei7-avx Registered Targets: arm - ARM ppc32 - PowerPC 32 ppc64 - PowerPC 64 thumb - Thumb x86 - 32-bit X86: Pentium-Pro and above x86-64 - 64-bit X86: EM64T and AMD64 dafis@schwartz:~/JNthPrime> opt --version LLVM (http://llvm.org/) LLVM version 3.2svn Optimized build. Default target: x86_64-unknown-linux-gnu Host CPU: corei7-avx But my CPU is a Core i5, not i7. Can somebody confirm or deny that that may be the cause?

4 7

GHC builder: out of memory from ghc during make
by Alain O'Dea 29 Apr '14

29 Apr '14

I am trying to get GHC builder-clients running for x86 and x86_64 GHC on SmartOS. I have been trying to get to the bottom of this memory issue and have had no luck. I've set it aside for the past couple of days to try to get a clear head to attack it afresh tonight. The three latest builds die with the following message: ghc: out of memory (requested 2097152 bytes) compiler/ghc.mk:641: recipe for target 'compiler/stage1/build/DynFlags.o' failed http://haskell.inf.elte.hu/builders/smartos-x86_64-head/16/10.html http://haskell.inf.elte.hu/builders/smartos-x86_64-head/17/10.html http://haskell.inf.elte.hu/builders/smartos-x86_64-head/18/10.html All of these were run interactively from the builder directory: builder-client --do-build Here's my zone setup: image: SmartOS base64 13.4.2 max_physical_memory: 4GB max_swap: 8GB disk_quota: 200GB # ulimit -a core file size (blocks, -c) unlimited data seg size (kbytes, -d) unlimited file size (blocks, -f) unlimited open files (-n) 65536 pipe size (512 bytes, -p) 10 stack size (kbytes, -s) 10240 cpu time (seconds, -t) unlimited max user processes (-u) 12261 virtual memory (kbytes, -v) unlimited It doesn't use anywhere near the 4GB of memory or 8GB of swap allocated to the zone. Total zone RSS (physical memory usage) stays under 200MB for the entire builder-client run. I took regular snaps of memory during the build run and saw no evidence of memory saturation or errors. It's nowhere near hitting swap limits either. I think I've done all I can do to remove system imposed resource limits. This doesn't happen when I run make directly from a shell myself. It looks like a defect in the GHC builder-client itself. If POSIX resources are available on the host (which they are on SmartOS) builder-client sets a 1GB ResourceTotalMemory limit using System.Posix.Resource.setResourceLimit: https://github.com/haskell/ghc-builder/blob/master/client/client.hs#L54 I'm trying a build with the resource limit code commented out. Hopefully that will finally put this to bed. Speaking of bed, I should probably sleep too. If anyone has any other ideas I'd be very happy for the help. Best, Alain

2 1