April 2014 - ghc-devs

Cloning ghc-7.8
by Simon Peyton Jones 24 Apr '14

24 Apr '14

How would I get a GHC 7.8 branch repo? Something like git clone http://git.haskell.org/ghc.git ghc-7.8-branch cd ghc-7.8-branch ./sync-all get git checkout ghc-7.8 git submodule update Is that enough? What about the non-submodule libraries? Do I need to do any more pull/get stuff? This would be another great entry on the workflow page. Thanks Simon

1 1

Porting GHC
by Simon Peyton Jones 24 Apr '14

24 Apr '14

Colin I saw your porting-ghc blog post<http://www.chiark.greenend.org.uk/ucgi/~cjwatson/blosxom/2014-04-15-porting…> (via the Haskell Weekly News) today. What a great post! Porting GHC to new architectures is way beyond the slender resources of GHC HQ, so depends utterly on volunteers. And you see to be a particularly skilled and knowledgeable one. Thank you! Simon PS: where you have offered patches to the main sources (e.g the function-prototype thing), did you elaborately comment the "technically wrong" prototype? I have this fear that in three year's time someone is going to say "oh, we could do better with that prototype" and re-introduce the bug! Aha. I've just checked #8965, and there's no comment at all. I'll add the commit message as a comment. Other ghc-devs, nb! Adding the ticket number to the comment is also fantastically helpful, because it often points to examples and discussion that are too long to include in the code.

1 0

checking clean reporting a lot of non-deleted files.
by Karel Gardas 23 Apr '14

23 Apr '14

Hello Herbert, I hope you are the right person to ask, but it looks like after folding base/template-haskell/ghc-prim/integer-gmp/ etc. libraries to ghc tree the build's checking clean step reports a lot of non-deleted files. This makes our builder logs quite huge: http://haskell.inf.elte.hu/builders/solaris-x86-head/36/14.html the situation just few days ago was quite different: http://haskell.inf.elte.hu/builders/solaris-x86-head/33/14.html Do you think this is caused by your change? If not, do you have an idea what's going wrong here? Thanks! Karel

2 1

Re: [commit: ghc] master: Be less untruthful about the prototypes of external functions (5a31f23)
by Simon Marlow 23 Apr '14

23 Apr '14

Could we have a comment with the ticket number next to the prototype please? Otherwise some well-meaning developer will "fix" it again in the future :-) Cheers, Simon On 22/04/2014 05:40, git(a)git.haskell.org wrote: > Repository : ssh://git@git.haskell.org/ghc > > On branch : master > Link : http://ghc.haskell.org/trac/ghc/changeset/5a31f231eebfb8140f9b519b166094d9d… > >> --------------------------------------------------------------- > > commit 5a31f231eebfb8140f9b519b166094d9d4fc2d79 > Author: Colin Watson <cjwatson(a)debian.org> > Date: Sat Apr 12 01:55:07 2014 +0100 > > Be less untruthful about the prototypes of external functions > > GHC's generated C code uses dummy prototypes for foreign imports. At the > moment these all claim to be (void), i.e. functions of zero arguments. On > most platforms this doesn't matter very much: calls to these functions put > the parameters in the usual places anyway, and (with the exception of > varargs) things just work. > > However, the ELFv2 ABI on ppc64 optimises stack allocation > (http://gcc.gnu.org/ml/gcc-patches/2013-11/msg01149.html) a call to a > function that has a prototype, is not varargs, and receives all parameters > in registers rather than on the stack does not require the caller to > allocate an argument save area. The incorrect prototypes cause GCC to > believe that all functions declared this way can be called without an > argument save area, but if the callee has sufficiently many arguments then > it will expect that area to be present, and will thus corrupt the caller's > stack. This happens in particular with calls to runInteractiveProcess in > libraries/process/cbits/runProcess.c. > > The simplest fix appears to be to declare these external functions with an > unspecified argument list rather than a void argument list. This is no > worse for platforms that don't care either way, and allows a successful > bootstrap of GHC 7.8 on little-endian Linux ppc64 (which uses the ELFv2 > ABI). > > Fixes #8965 > > Signed-off-by: Colin Watson <cjwatson(a)debian.org> > Signed-off-by: Austin Seipp <austin(a)well-typed.com> > > >> --------------------------------------------------------------- > > 5a31f231eebfb8140f9b519b166094d9d4fc2d79 > includes/Stg.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/includes/Stg.h b/includes/Stg.h > index be966aa..1707c9b 100644 > --- a/includes/Stg.h > +++ b/includes/Stg.h > @@ -213,7 +213,7 @@ typedef StgFunPtr F_; > #define II_(X) static StgWordArray (X) GNU_ATTRIBUTE(aligned (8)) > #define IF_(f) static StgFunPtr GNUC3_ATTRIBUTE(used) f(void) > #define FN_(f) StgFunPtr f(void) > -#define EF_(f) extern StgFunPtr f(void) > +#define EF_(f) extern StgFunPtr f() > > /* ----------------------------------------------------------------------------- > Tail calls > > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits >

1 0

Coverity CID 43168
by Howard B. Golden 22 Apr '14

22 Apr '14

Hi, This is code I wrote for Trac ticket #2615. I will study it to see if it needs to be fixed. If so, I will submit a patch. I tried to put this into the triage section in Coverity, but I guess I don't have write access to update that. This is a minor memory leak (if at all). The semantics of the POSIX dlopen error isn't fully specified, so I'm unsure of whether I need to fix this or not. Howard B. Golden Northridge, CA, USA

1 0

Coverity Scan
by Austin Seipp 22 Apr '14

22 Apr '14

Hello all, As of this morning, GHC has been accepted into the Coverity Scan project! The results are in and a few of us are combing over them now. Some of you I'm sure would like to play around and see what it says. Please feel free to ask me for access. In general, Coverity is restrictive of access because of the security implications, but I think this is much less of a problem for us in general. That said, I won't give literally everyone in the world access, but there's no harm in having some eyes. The project is available here, and you can request access by giving your email address: https://scan.coverity.com/projects/1919 Currently me and Herbert are the owners, and so we can submit builds. I plan on inviting at least Simon M and Edward Yang as well. You two can also just apply via the UI and I will add you as well. Note that I think a few of these issues are quite real, but I do think we'll have to mitigate some by writing a Coverity model and tuning things to reduce the false impact rate. Luckily this shouldn't be too hard. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

2 3

Re: [commit: ghc] wip/orf: ghc: implement OverloadedRecordFields (fe77cbf)
by Chris Dornan 22 Apr '14

22 Apr '14

Marvellous On 22/04/2014 12:17, "git(a)git.haskell.org" <git(a)git.haskell.org> wrote: >Repository : ssh://git@git.haskell.org/ghc > >On branch : wip/orf >Link : >http://ghc.haskell.org/trac/ghc/changeset/fe77cbf15dd44bb72943357d65bd8adf >9f4deee5/ghc > >>--------------------------------------------------------------- > >commit fe77cbf15dd44bb72943357d65bd8adf9f4deee5 >Author: Adam Gundry <adam(a)well-typed.com> >Date: Tue Apr 22 02:12:03 2014 -0500 > > ghc: implement OverloadedRecordFields > > This fully implements the new ORF extension, developed during the >Google > Summer of Code 2013, and as described on the wiki: > > https://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields > > This also updates the Haddock submodule. > > Reviewed-by: Simon Peyton Jones <simonpj(a)microsoft.com> > Signed-off-by: Austin Seipp <austin(a)well-typed.com> > > >>--------------------------------------------------------------- > >fe77cbf15dd44bb72943357d65bd8adf9f4deee5 > compiler/basicTypes/Avail.hs | 149 ++++++- > compiler/basicTypes/DataCon.lhs | 21 +- > compiler/basicTypes/DataCon.lhs-boot | 2 + > compiler/basicTypes/FieldLabel.lhs | 128 ++++++ > compiler/basicTypes/Id.lhs | 12 +- > compiler/basicTypes/MkId.lhs | 2 +- > compiler/basicTypes/OccName.lhs | 8 + > compiler/basicTypes/RdrName.lhs | 123 +++-- > compiler/deSugar/Check.lhs | 4 +- > compiler/deSugar/Coverage.lhs | 4 +- > compiler/deSugar/Desugar.lhs | 2 + > compiler/deSugar/DsExpr.lhs | 18 +- > compiler/deSugar/DsMeta.hs | 4 +- > compiler/deSugar/DsMonad.lhs | 1 + > compiler/deSugar/MatchCon.lhs | 6 +- > compiler/ghc.cabal.in | 3 + > compiler/ghc.mk | 7 + > compiler/hsSyn/Convert.lhs | 23 +- > compiler/hsSyn/HsDecls.lhs | 6 + > compiler/hsSyn/HsExpr.lhs | 5 +- > compiler/hsSyn/HsImpExp.lhs | 33 +- > compiler/hsSyn/HsPat.lhs | 39 +- > compiler/hsSyn/HsTypes.lhs | 51 ++- > compiler/hsSyn/HsUtils.lhs | 80 ++-- > compiler/iface/BuildTyCl.lhs | 2 +- > compiler/iface/IfaceSyn.lhs | 52 +-- > compiler/iface/LoadIface.lhs | 19 +- > compiler/iface/MkIface.lhs | 27 +- > compiler/iface/TcIface.lhs | 36 +- > compiler/main/DynFlags.hs | 9 + > compiler/main/GHC.hs | 19 +- > compiler/main/HscMain.hs | 16 +- > compiler/main/HscTypes.lhs | 27 +- > compiler/main/InteractiveEval.hs | 2 +- > compiler/main/PprTyThing.hs | 12 +- > compiler/main/TidyPgm.lhs | 12 +- > compiler/parser/Parser.y.pp | 6 +- > compiler/parser/RdrHsSyn.lhs | 6 +- > compiler/prelude/PrelInfo.lhs | 2 +- > compiler/prelude/PrelNames.lhs | 43 +- > compiler/prelude/TysWiredIn.lhs | 2 +- > compiler/rename/RnEnv.lhs | 321 ++++++++++--- > compiler/rename/RnExpr.lhs | 20 +- > compiler/rename/RnNames.lhs | 470 >+++++++++++++++----- > compiler/rename/RnPat.lhs | 75 ++-- > compiler/rename/RnSource.lhs | 90 ++-- > compiler/rename/RnTypes.lhs | 53 ++- > compiler/typecheck/FamInst.lhs | 53 ++- > compiler/typecheck/Inst.lhs | 3 +- > compiler/typecheck/TcEnv.lhs | 57 +-- > compiler/typecheck/TcErrors.lhs | 54 ++- > compiler/typecheck/TcEvidence.lhs | 1 + > compiler/typecheck/TcExpr.lhs | 320 ++++++++++--- > compiler/typecheck/TcFldInsts.lhs | 468 >+++++++++++++++++++ > compiler/typecheck/TcGenDeriv.lhs | 11 +- > compiler/typecheck/TcGenGenerics.lhs | 16 +- > compiler/typecheck/TcHsSyn.lhs | 4 +- > compiler/typecheck/TcHsType.lhs | 16 +- > compiler/typecheck/TcInstDcls.lhs | 4 +- > compiler/typecheck/TcInteract.lhs | 65 ++- > compiler/typecheck/TcPat.lhs | 24 +- > compiler/typecheck/TcRnDriver.lhs | 25 +- > compiler/typecheck/TcRnMonad.lhs | 5 +- > compiler/typecheck/TcRnTypes.lhs | 31 +- > compiler/typecheck/TcSMonad.lhs | 18 +- > compiler/typecheck/TcSplice.lhs | 2 +- > compiler/typecheck/TcTyClsDecls.lhs | 79 ++-- > compiler/typecheck/TcType.lhs | 9 + > compiler/typecheck/TcValidity.lhs | 19 +- > compiler/types/TyCon.lhs | 54 ++- > compiler/types/Type.lhs | 29 +- > compiler/types/Type.lhs-boot | 2 + > compiler/types/TypeRep.lhs | 43 +- > compiler/utils/Binary.hs | 1 - > compiler/utils/FastStringEnv.lhs | 77 ++++ > docs/users_guide/glasgow_exts.xml | 307 +++++++++++++ > libraries/base/GHC/Base.lhs | 3 + > libraries/base/GHC/Records.hs | 249 +++++++++++ > libraries/base/GHC/TypeLits.hs | 8 +- > libraries/base/base.cabal | 1 + > testsuite/tests/driver/T4437.hs | 1 + > testsuite/tests/ghci/scripts/ghci042.stdout | 2 +- > testsuite/tests/module/mod176.stderr | 2 +- > .../{annotations => overloadedrecflds}/Makefile | 0 > .../ghci}/Makefile | 0 > testsuite/tests/overloadedrecflds/ghci/all.T | 3 + > .../ghci/overloadedrecfldsghci01.script | 13 + > .../ghci/overloadedrecfldsghci01.stdout | 11 + > .../should_fail}/Makefile | 0 > .../should_fail/OverloadedRecFldsFail04_A.hs | 9 + > .../should_fail/OverloadedRecFldsFail06_A.hs | 16 + > .../should_fail/OverloadedRecFldsFail08_A.hs | 14 + > .../tests/overloadedrecflds/should_fail/all.T | 16 + > .../should_fail/overloadedrecfldsfail01.hs | 17 + > .../should_fail/overloadedrecfldsfail01.stderr | 16 + > .../should_fail/overloadedrecfldsfail02.hs | 19 + > .../should_fail/overloadedrecfldsfail02.stderr | 50 +++ > .../should_fail/overloadedrecfldsfail03.hs | 7 + > .../should_fail/overloadedrecfldsfail03.stderr | 5 + > .../should_fail/overloadedrecfldsfail04.hs | 9 + > .../should_fail/overloadedrecfldsfail04.stderr | 5 + > .../should_fail/overloadedrecfldsfail05.hs | 10 + > .../should_fail/overloadedrecfldsfail05.stderr | 10 + > .../should_fail/overloadedrecfldsfail06.hs | 10 + > .../should_fail/overloadedrecfldsfail06.stderr | 15 + > .../should_fail/overloadedrecfldsfail07.hs | 11 + > .../should_fail/overloadedrecfldsfail07.stderr | 6 + > .../should_fail/overloadedrecfldsfail08.hs | 13 + > .../should_fail/overloadedrecfldsfail08.stderr | 47 ++ > .../should_fail/overloadedrecfldsfail09.hs | 9 + > .../should_fail/overloadedrecfldsfail09.stderr | 20 + > .../should_fail/overloadedrecfldsfail10.hs | 11 + > .../should_fail/overloadedrecfldsfail10.stderr | 9 + > .../should_run}/Makefile | 0 > .../should_run/OverloadedRecFldsRun01_A.hs | 9 + > .../should_run/OverloadedRecFldsRun02_A.hs | 9 + > .../should_run/OverloadedRecFldsRun07_A.hs | 11 + > .../should_run/OverloadedRecFldsRun07_B.hs | 7 + > .../should_run/OverloadedRecFldsRun08_A.hs | 11 + > .../should_run/OverloadedRecFldsRun08_B.hs | 7 + > .../should_run/OverloadedRecFldsRun08_C.hs | 7 + > .../should_run/OverloadedRecFldsRun11_A.hs | 9 + > .../should_run/OverloadedRecFldsRun11_A.hs-boot | 5 + > .../should_run/OverloadedRecFldsRun11_B.hs | 7 + > .../should_run/OverloadedRecFldsRun12_A.hs | 11 + > .../should_run/OverloadedRecFldsRun12_B.hs | 7 + > testsuite/tests/overloadedrecflds/should_run/all.T | 26 ++ > .../should_run/overloadedrecfldsrun01.hs | 70 +++ > .../should_run/overloadedrecfldsrun01.stdout | 13 + > .../should_run/overloadedrecfldsrun02.hs | 6 + > .../should_run/overloadedrecfldsrun02.stdout | 0 > .../should_run/overloadedrecfldsrun03.hs | 18 + > .../should_run/overloadedrecfldsrun03.stdout | 4 + > .../should_run/overloadedrecfldsrun04.hs | 18 + > .../should_run/overloadedrecfldsrun04.stdout | 3 + > .../should_run/overloadedrecfldsrun05.hs | 34 ++ > .../should_run/overloadedrecfldsrun05.stdout | 2 + > .../should_run/overloadedrecfldsrun06.hs | 28 ++ > .../should_run/overloadedrecfldsrun06.stdout | 1 + > .../should_run/overloadedrecfldsrun07.hs | 7 + > .../should_run/overloadedrecfldsrun07.stdout} | 0 > .../should_run/overloadedrecfldsrun08.hs | 7 + > .../should_run/overloadedrecfldsrun08.stdout | 2 + > .../should_run/overloadedrecfldsrun09.hs | 8 + > .../should_run/overloadedrecfldsrun09.stdout | 2 + > .../should_run/overloadedrecfldsrun10.hs | 12 + > .../should_run/overloadedrecfldsrun10.stderr | 2 + > .../should_run/overloadedrecfldsrun11.hs | 5 + > .../should_run/overloadedrecfldsrun11.stdout} | 0 > .../should_run/overloadedrecfldsrun12.hs | 6 + > .../should_run/overloadedrecfldsrun12.stdout | 2 + > .../should_run/overloadedrecfldsrun13.hs | 9 + > .../should_run/overloadedrecfldsrun13.stdout} | 0 > testsuite/tests/rename/should_fail/T5892a.stderr | 2 +- > .../tests/typecheck/should_fail/tcfail102.stderr | 3 +- > utils/ghctags/Main.hs | 2 +- > utils/haddock | 2 +- > 157 files changed, 4131 insertions(+), 759 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 >fe77cbf15dd44bb72943357d65bd8adf9f4deee5 >_______________________________________________ >ghc-commits mailing list >ghc-commits(a)haskell.org >http://www.haskell.org/mailman/listinfo/ghc-commits

1 0

OverloadedRecordFields merge
by Austin Seipp 22 Apr '14

22 Apr '14

Hello all, As some of you might have seen last week, my colleague Adam took the time to get his OverloadedRecordFields back up to date with regards to HEAD. I'm now wondering: when should we pull the trigger? I am inclined to say 'soon'. In particular, the ORF changes are rather large, and Adam has hinted to me it touches a lot of components of e.g. name resolution. A large change with some fairly big impacts, in other words. I think it is perhaps best to merge soon - so that it does not get out of date and cause undue burden to Adam, but also so that we have maximal amounts of time to sort out issues in the long haul that it might expose. Simon - I believe you reviewed Adam's work in the past, yes? I am wondering what you think we should do here. I am more than willing to defer to you and let you do the merge after another review. On the other hand, if you already did review it and feel confident after a look or two, I'm more than willing to take over sometime this week. Adam - since you emailed us last week, Herbert went ahead and merged 'base' into GHC's repository. This does not invalidate the changes you gave us, it just means the two commits can be collapsed into one. Also, the performance failures seem like minor anomalies, but I have not yet directly built the ORF branch to confirm this. You're free to rebase yourself, or I can likely handle it without much issue soon. If anyone else has opinions here - please speak up, I'm all ears. For those reading, Adam's implementation is available in current form here: - https://github.com/adamgundry/ghc - https://github.com/adamgundry/packages-base - https://github.com/adamgundry/haddock -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

2 3

Folding in base, integer-{gmp, single}, ghc-prim, and haskell-template into ghc.git
by Herbert Valerio Riedel 22 Apr '14

22 Apr '14

Hello *, Now that GHC 7.8.[12] is out of the door, the Git reorganization can be tackled further... After a short conversion with Austin and Edward it appears that the sensible course of action with respect towards moving to a proper Git submodule set-up is to fold-in the 5 Git repos listed below (which btw are all GHC wired-in packages) directly into ghc.git (the same way testsuite.git was a few months ago): - base - ghc-prim - integer-gmp - integer-simple - template-haskell IMO, the benefit/cost ratio of simplifying the workflow outweighs the benefit/cost ratio of turning those into proper Git submodules. This incremental step towards a fully git-bisect-able ghc.git does already allow bisecting to work on a larger time-range than it does now, as those wired-in packages are the most likely to break compilation if out-of-sync with ghc.git. If no objections are raised, I'm planning to implement this change next weekend (April 19th/20th). Any comments/questions/...? Cheers, hvr PS: After this step, the next remaining step would be to turn the remaining not-yet-submodule Git repos into proper submodule Repos (like haddock.git) and figure out how to get the sync-all convenience-tooling a bit more submodule friendly...

5 8

Validate Failures
by Daniel Fischer 22 Apr '14

22 Apr '14

I'm getting three or four validate failures on 64-bit Linux (openSuSE 12.3): Unexpected failures: perf/compiler T3064 [stat not good enough] (normal) perf/compiler T6048 [stat not good enough] (optasm) simplCore/should_compile simpl015 [exit code non-0] (optasm) th T8333 [bad stdout] (normal) The perf tests allocate about 2% more than they are allowed to. > bytes allocated value is too high: > Expected bytes allocated: 308422280 +/-5% > Lower bound bytes allocated: 293001166 > Upper bound bytes allocated: 323843394 > Actual bytes allocated: 329638208 > *** unexpected failure for T3064(normal) > bytes allocated value is too high: > Expected bytes allocated: 110646312 +/-10% > Lower bound bytes allocated: 99581680 > Upper bound bytes allocated: 121710944 > Actual bytes allocated: 123103232 > *** unexpected failure for T6048(optasm) The T8333 failure is due to it reading my .ghci file, thus getting additional output. Is there a way to automatically check that all tests that use the "--interactive" flag also use "-ignore-dot-ghci" like the ghci tests do, or must one wait for validate failures due to that and add it then? Finally, simpl015 is a test that does only sometimes fail. It uses on my box an estimated 2GB of memory, and when I haven't anything else memory-hungry running, it passes, but when I have (as I do by default) SeaMonkey running (with tons of open tabs), my box quasi-freezes, the test times out, and the browser is OOM-killed. I am not happy with that behaviour. And looking at what the test is, I am somewhat irritated that it uses so much memory. Cheers, Daniel

2 2