May 2014 - ghc-devs - Haskell.org

C-- specfication
by Florian Weimer 05 May '14

05 May '14

I'm looking for a specification of C--. I can't find it on the cminuscminus.org web site, and it's also not included in the release tarball. Does anybody know where to get it?

6 8

Re: [commit: ghc] master: Per-thread allocation counters and limits (b0534f7)
by Mateusz Kowalczyk 04 May '14

04 May '14

On 05/02/2014 03:50 PM, git(a)git.haskell.org wrote: > Repository : ssh://git@git.haskell.org/ghc > > On branch : master > Link : http://ghc.haskell.org/trac/ghc/changeset/b0534f78a73f972e279eed4447a5687bd… > >> --------------------------------------------------------------- > > commit b0534f78a73f972e279eed4447a5687bd6a8308e > Author: Simon Marlow <marlowsd(a)gmail.com> > Date: Mon Apr 28 16:55:47 2014 +0100 > > Per-thread allocation counters and limits > > This tracks the amount of memory allocation by each thread in a > counter stored in the TSO. Optionally, when the counter drops below > zero (it counts down), the thread can be sent an asynchronous > exception: AllocationLimitExceeded. When this happens, given a small > additional limit so that it can handle the exception. See > documentation in GHC.Conc for more details. > > Allocation limits are similar to timeouts, but > > - timeouts use real time, not CPU time. Allocation limits do not > count anything while the thread is blocked or in foreign code. > > - timeouts don't re-trigger if the thread catches the exception, > allocation limits do. > > - timeouts can catch non-allocating loops, if you use > -fno-omit-yields. This doesn't work for allocation limits. > > I couldn't measure any impact on benchmarks with these changes, even > for nofib/smp. > > >> --------------------------------------------------------------- > > b0534f78a73f972e279eed4447a5687bd6a8308e > compiler/cmm/CmmLayoutStack.hs | 9 +- > compiler/codeGen/StgCmmForeign.hs | 268 ++++++++++++++------ > includes/CodeGen.Platform.hs | 4 +- > includes/rts/Constants.h | 6 + > includes/rts/Flags.h | 8 + > includes/rts/Threads.h | 8 +- > includes/rts/storage/TSO.h | 31 ++- > libraries/base/Control/Exception.hs | 1 + > libraries/base/Control/Exception/Base.hs | 1 + > libraries/base/GHC/Conc.lhs | 6 + > libraries/base/GHC/Conc/Sync.lhs | 92 ++++++- > libraries/base/GHC/IO/Exception.hs | 21 +- > rts/HeapStackCheck.cmm | 4 +- > rts/Linker.c | 4 + > rts/Prelude.h | 2 + > rts/RaiseAsync.c | 54 ++++ > rts/RaiseAsync.h | 4 + > rts/RtsFlags.c | 10 + > rts/RtsStartup.c | 1 + > rts/Schedule.c | 19 ++ > rts/Threads.c | 77 +++--- > rts/package.conf.in | 2 + > rts/sm/Storage.c | 6 + > testsuite/tests/concurrent/should_run/all.T | 7 + > .../tests/concurrent/should_run/allocLimit1.hs | 9 + > .../tests/concurrent/should_run/allocLimit1.stderr | 1 + > .../tests/concurrent/should_run/allocLimit2.hs | 17 ++ > .../tests/concurrent/should_run/allocLimit3.hs | 15 ++ > .../tests/concurrent/should_run/allocLimit3.stderr | 1 + > .../should_run/allocLimit3.stdout} | 1 - > .../tests/concurrent/should_run/allocLimit4.hs | 31 +++ > utils/deriveConstants/DeriveConstants.hs | 1 + > 32 files changed, 576 insertions(+), 145 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 b0534f78a73f972e279eed4447a5687bd6a8308e > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits > I just tried to compile a snapshot involving this commit and got a compile failure: http://lpaste.net/103540 I was compiling with GHC 7.8.2 on a 32-bit machine. -- Mateusz K.

7 10

Branch cleanup coming soon - please take inventory
by Austin Seipp 04 May '14

04 May '14

Hello all, I was talking about this on IRC the other day, and it reminded me I wanted to do this a while back. At the moment, we have a *lot* of branches hanging out in the GHC tree: $ git branch -r | grep origin | wc -l 89 $ So I'd like to start deleting all the old ones that are merged and don't need to hang around. A while back I kept a list that was curated of what branches were dead and could be removed. Here it is: https://ghc.haskell.org/trac/ghc/wiki/ActiveBranches This page is a bit out of date, but still many of the comments are accurate, particularly what can already be deleted. I will likely be *deleting* these merged branches soon unless someone speaks up. Note that: - Anything I cannot be 100% certain is merged will stay. - Anything which is effectively 'in-limbo' (like local-gc, or supercompiler) will stay. We also have a lot of WIP branches here too. If you all would all take inventory of your branches and make sure they're catalogued on that page, it would be really nice. Just add it for now - I'll get rid of the old entries once I delete them later. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

2 1

[PATCH] make UNREG build as a platform with 0 hardware registers
by slyich＠gmail.com 04 May '14

04 May '14

From: Sergei Trofimovich <slyfox(a)gentoo.org> 83a003fcaec93dbfd5b46837f2bf3353412b9877 introduced optimization which likes to know if a reg is a hardware reg via 'globalRegMaybe': But --enable-unregisterised does not define that function: ghc-stage1: panic! (the 'impossible' happened) (GHC version 7.9.20140419 for x86_64-unknown-linux): globalRegMaybe not defined for this platform CC: Simon Marlow <marlowsd(a)gmail.com> Signed-off-by: Sergei Trofimovich <slyfox(a)gentoo.org> --- includes/CodeGen.Platform.hs | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/includes/CodeGen.Platform.hs b/includes/CodeGen.Platform.hs index 3d6dd41..1e7c17d 100644 --- a/includes/CodeGen.Platform.hs +++ b/includes/CodeGen.Platform.hs @@ -743,7 +743,11 @@ globalRegMaybe CurrentNursery = Just (RealRegSingle REG_CurrentNursery # endif globalRegMaybe _ = Nothing #else +# ifdef NO_REGS +globalRegMaybe _ = Nothing +# else globalRegMaybe = panic "globalRegMaybe not defined for this platform" +# endif /* !NO_REGS */ #endif freeReg :: RegNo -> FastBool -- 1.9.2

2 1

[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