- ghc-devs - Haskell.org

strip related failure [was: Re: solaris-x86-head (Solaris/x86 HEAD (Karel Gardas)), build 32, Failure]
by Karel Gardas 18 Apr '14

18 Apr '14

Folks, last two/three builds on Solaris builder fails due to a reason that someone added (probably) stripping of installed libraries. My bet is on 8992d5269804b727fb77249511e89df678526907 -- hence ccing you Herbert, but I'm not sure... The problem is that invoked strip command line is incompatible with Solaris' strip which then fails with: strip: --strip-unneeded: cannot open file: No such file or directory the problem is usage of --strip-unneeded command-line argument? It looks like this argument is supported by just GNU strip. Do we really need to use it? If not, removing this may solve the issue. If yes, then I'll need to come with some workaround for Solaris... Detailed log of failure is at the bottom of http://haskell.inf.elte.hu/builders/solaris-x86-head/32/20.html Thanks! Karel On 04/18/14 05:03 AM, Builder wrote: > solaris-x86-head (Solaris/x86 HEAD (Karel Gardas)), build 32 > > Build failed > Details: http://haskell.inf.elte.hu/builders/solaris-x86-head/32.html > > git clone | Success > create mk/build.mk | Success > get subrepos | Success > repo versions | Success > touching clean-check files | Success > setting version date | Success > booting | Success > configuring | Success > creating check-remove-before | Success > compiling | Success > creating check-remove-after | Success > compiling testremove | Success > simulating clean | Success > checking clean | Success > making bindist | Success > making srcdist | Success > uploading bindist | Success > uploading srcdist | Success > uploading tarball source | Success > testing bindist | Failure: Just (ExitFailure 2) > > Build failed > Details: http://haskell.inf.elte.hu/builders/solaris-x86-head/32.html > > > > > _______________________________________________ > ghc-builds mailing list > ghc-builds(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-builds

3 4

GHC's performance
by Simon Peyton Jones 18 Apr '14

18 Apr '14

Friends The thread below concerns GHC's performance. I'm writing to ask for your help. In developing GHC we always run 'validate', which runs a lot of regression tests. A few of those are performance tests, but because we do so frequently, none of these performance tests run for long, and none depend on other packages. And they tend to test something very specific. What we lack is a sustained effort to track a) The performance of GHC itself b) The performance of GHC-compiled programs At GHC HQ we *aspire* to track this stuff, but in practice we simply don't. Bug-fixing, portability, etc etc always ends up taking priority. But it's a pity that we don't. For example, Michal's comment below (that his GHC-compiled program has run 10-20% faster with each release of GHC from 6.12) is fantastic -- but we have no data to back it up, or know whether it's just Michael, or more widely true. I also suspect that sometimes we regress and don't know it. People do report this (e.g. #8971), but it's a bit random. Again, it would be great to have a more systematic way to know. In many cases it might be easy to fix; but we can only fix if we know. We have the nofib suite, and we take that very seriously, but it is showing its age, uses no advanced features, and I'm not sure how representative it is any more. Johan Tibell and Bryan O'Sullivan agreed to become GHC's Performance Tsars a year or two ago, with a view to focusing on (b) at least, but they are both extremely busy. And I don't think they even attempt to focus on (a). So I'm wondering: would anyone like to help here? It would mean * Soliciting and gathering together some more substantial benchmarks * Gathering performance numbers * Yelling quickly if the numbers go bad. * Investigating why (e.g. no one has seriously profiled GHC itself for a while, both space and time. I bet there are improvements to be had there.) Maybe it could be part of the new buildbot team's work? Certainly it'd make sense to use the same nightly-build infrastructure. Anyway, I'm advertising that there's an un-met need, and I'd love some help. Thanks Simon | -----Original Message----- | From: Michal J. Gajda [mailto:mjgajda@gmail.com] | Sent: 10 April 2014 07:26 | To: ghc-devs(a)haskell.org; Sergei Trofimovich; Manuel Chakravarty; Simon | Peyton Jones | Subject: Re: ghc-7.8-rc2 in -O2 mode eats all stack and RAM on pandoc- | ,citeproc / highlighting-kate | | Dear Devs, | | On 04/10/2014 09:09 AM, ghc-devs-request(a)haskell.org wrote: | > Filed the reproducer as a new ticket: | > https://ghc.haskell.org/trac/ghc/ticket/8980 | > | > [ Looks like highlighting-kate asks to be added to | > compiler performance benchmarks (are there such ones?) | > It tends to stress ghc all the time: | > http://hackage.haskell.org/trac/ghc/ticket/3664 | > ] | Please consider adding hPDB too, if you want to stress the optimizer. | It shows GHC optimizer at its best, with at least 10-20% improvement in | every major version of | the compiler since 6.12. Unfortunately at cost of very long compile | times. | Please let me know if I should submit a driver code for automatic | benchmarks it (it is in hPDB-examples.) Thanks! | >> > SpecConstr is too aggressive: it sometimes blows up the program | badly and we have no good | solution. See Trac #7898, #7068, #7944, #5550, #8836. | And #8960, where GHC runs out of memory. (Only in 7.8.) Should be easy | to reproduce by just `cabal install hPDB`. | >> > I notice that the latter three are actually fixed in 7.8, so worth | trying that. If it | still fails, do add instructions to reproduce to one of the above open | tickets, or make a new one. | >> > | >> > Meanwhile you can use -fno-spec-constr to simply switch it off for | offending modules. That should get you going. | -- | Best regards | Michal

4 6

Git problem
by Simon Peyton Jones 17 Apr '14

17 Apr '14

Friends I'm stuck with Git. Help please! Simon I tried to do a 'git stash pop', having just done a 'git pull' from the master repo. I got this: simonpj@cam-05-unx:~/code/HEAD-2$ git stash pop warning: Failed to merge submodule utils/haddock (commits don't follow merge-base) Auto-merging utils/haddock CONFLICT (submodule): Merge conflict in utils/haddock Auto-merging compiler/typecheck/TcRnMonad.lhs Now git status says simonpj@cam-05-unx:~/code/HEAD-2$ git status # On branch master # Your branch is ahead of 'origin/master' by 2 commits. # # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # modified: compiler/typecheck/TcMType.lhs # modified: compiler/typecheck/TcRnMonad.lhs # modified: compiler/typecheck/TcSimplify.lhs # modified: compiler/typecheck/TcUnify.lhs # # Unmerged paths: # (use "git reset HEAD <file>..." to unstage) # (use "git add/rm <file>..." as appropriate to mark resolution) # # both modified: utils/haddock The modified files are right. It's the "both modified utils/haddock" that is messing me up. I'm not modifying haddock! I just want to say "take the master haddock", but I don't know how. I tried 'git checkout utils/haddock' but that just led do `git status' saying # modified: utils/haddock (new commits)

4 4

Link failure
by Simon Peyton Jones 17 Apr '14

17 Apr '14

On 64-bit Linux I'm getting this in the link step for the template-haskell library: /usr/bin/ld: libraries/template-haskell/dist-install/build/Language/Haskell/TH/Syntax.dyn_o: relocation R_X86_64_PC32 against undefined symbol `templatezmhaskell_LanguageziHaskellziTHziSyntax_OccName_closure' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Bad value collect2: ld returned 1 exit status make[2]: *** [libraries/template-haskell/dist-install/build/libHStemplate-haskell-2.10.0.0-ghc7.9.20140416.so] Error 1 make[1]: *** [all_libraries/template-haskell] Error 2 make[1]: Leaving directory `/5playpen/simonpj/HEAD-1' My compiler is not vanilla HEAD, but I have changed only stuff in the Core simplifier, nothing in the back end. Does anyone have the faintest idea what is going on? It's extremely annoying because I can't make progress without working around it somehow. Thanks Simon

1 1

ghc-builder: builder-client: fd:13: hGetLine: resource exhausted (Resource temporarily unavailable)
by Alain O'Dea 17 Apr '14

17 Apr '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I get the following error every time I run the ghc-builder: builder-client: fd:13: hGetLine: resource exhausted (Resource temporarily unavailable) This appears to be the kernel returning EAGAIN (non-fatal) on an IO request. I'm not sure why it crashes the builder-client. I would expect hGetLine to retry in this case. I'm running this on SmartOS, which is an Illumos (OpenSolaris 10 compatible) distro. Here's a log of an entire run: https://gist.github.com/AlainODea/12a74a05b52c334614d9 Here's a snippet around the problem: Running "touching clean-check files" Running "setting version date" Running "booting" builder-client: fd:13: hGetLine: resource exhausted (Resource temporarily unavailable) [2014-04-17 02:21:08] [smartos-x86-head] Sending: "UPLOAD 14 1" Received: "202 Send name" Received: "202 Send subdir" Received: "202 Send program" Has anyone seen something like this before? Thanks, Alain -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTT0ApAAoJEP0rIXJNjNSAFbcH/29X7XvvMjGg/DWocap7D40f QOrVNTAipRcRSvEeCQh61hAAouabC2MkXts/8qM171xSghHArlYqe5XLkeKUDpo+ RiuyQER2t5fiZU1u8TywdMOm0NegxySiltEKooKpWzIzDzZHX7ggDUQlWTVzFgmR S50OsF8z9i3t8EF4N23J/Y78qca97iTn+Rw9qYl8Nc4vbhd+1Mqrsd25KDBK73Vk 5Hzy+HFy6yaJIEF3Rpda1Wr1CYKT4mwW6wAoTOeAK3obogwWX1mBzpV4MDt/5NBZ 9qet+2n59jkk0aaXJszXqNz4T0MTpMXgummjiLghyxtFJu71bvv3Xs6FXwgP23I= =6fKZ -----END PGP SIGNATURE-----

1 0

7.8.2 bugs and beyond
by Austin Seipp 16 Apr '14

16 Apr '14

Hello all, 7.8.1 is out. Yay! Now, on to the next thing. Here's the very preliminary 7.8.2 buglist: - https://ghc.haskell.org/trac/ghc/query?group=status&milestone=7.8.2 Note that this list has effectively received zero curation so far. I plan on fixing that soon, and in the process I am probably going to touch a lot of trac tickets (so I apologize in advance for the mail spam, because y'all are probably going to get a lot of it). This will include re-prioritizing these bugs, so take things with a grain of salt right now. Note that the bug tracker now has 7.8.1 as the default version - if you're filing bugs, please be sure to try it first of course. :) And don't forget to set the milestone to 7.8.2 if you think it qualifies for a fix. There are already a couple of things in the merge queue. There's currently no expected date for 7.8.2. Should it arrive quickly? Or slowly? Simon, Simon and I are inclined to just let things play out for a while of course, which is the traditional way things are done. But this release window has been especially awkward, so we'll see what happens. This of course leaves timeline questions for 7.10 open - but before we decide that, now's a time to just get some hacking done I suppose... -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

5 6

The build is broken (Solaris/x86, FreeBSD/{i386,amd64})
by Páli Gábor János 15 Apr '14

15 Apr '14

The failing command: "inplace/bin/ghc-stage2" -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -H32m -O -hide-all-packages -i -iutils/haddock/driver -iutils/haddock/src -iutils/haddock/vendor/attoparsec-0.10.4.0 -iutils/haddock/dist/build -iutils/haddock/dist/build/autogen -Iutils/haddock/dist/build -Iutils/haddock/dist/build/autogen -optP-DIN_GHC_TREE -optP-include -optPutils/haddock/dist/build/autogen/cabal_macros.h -package Cabal-1.18.1.3 -package array-0.5.0.0 -package base-4.7.0.0 -package bytestring-0.10.4.0 -package containers-0.5.5.1 -package deepseq-1.3.0.2 -package directory-1.2.1.0 -package filepath-1.3.0.2 -package ghc-7.9.20140414 -package xhtml-3000.2.1 -funbox-strict-fields -Wall -fwarn-tabs -O2 -XHaskell2010 -no-user-package-db -rtsopts -odir utils/haddock/dist/build -hidir utils/haddock/dist/build -stubdir utils/haddock/dist/build -c utils/haddock/src/Haddock/Interface/Create.hs -o utils/haddock/dist/build/Haddock/Interface/Create.dyn_o utils/haddock/src/Haddock/Interface/Create.hs:367:44: Couldn't match type 'GenLocated SrcSpan (HsBindLR Name Name)' with '(a1, Located (HsBind id))' Expected type: TyClDecl Name -> Bag (a1, Located (HsBind id)) Actual type: TyClDecl Name -> LHsBinds Name Relevant bindings include defs :: [Located (HsDecl id)] (bound at utils/haddock/src/Haddock/Interface/Create.hs:367:5) In the second argument of '(.)', namely 'tcdMeths' In the second argument of '(.)', namely 'bagToList . tcdMeths' utils/haddock/src/Haddock/Interface/Create.hs:393:22: Couldn't match type 'GenLocated SrcSpan (HsBindLR Name Name)' with '(a0, Located (HsBind Name))' Expected type: HsValBindsLR Name Name -> [(a0, Located (HsBind Name))] Actual type: HsValBindsLR Name Name -> [LHsBindLR Name Name] In the first argument of '(.)', namely 'valbinds' In the second argument of '(.)', namely 'valbinds . hs_valds' gmake[1]: *** [utils/haddock/dist/build/Haddock/Interface/Create.dyn_o] Error 1 gmake: *** [all] Error 2 Please consult the details at http://haskell.inf.elte.hu/builders/solaris-x86-head/28/10.html

7 6

Help with coercion & roles?
by Conal Elliott 14 Apr '14

14 Apr '14

I’m working on a GHC plugin (as part of my Haskell-to-hardware work) and running into trouble with coercions & roles. Error message from Core Lint: Warning: In the expression: LambdaCCC.Lambda.lamvP# @ (GHC.Types.Bool → GHC.Types.Bool → GHC.Types.Bool → GHC.Types.Bool) @ (Simple.HasIf GHC.Types.Bool) "tpl"# ((LambdaCCC.Lambda.varP# @ (GHC.Types.Bool → GHC.Types.Bool → GHC.Types.Bool → GHC.Types.Bool) "tpl"#) `cast` (<LambdaCCC.Lambda.EP>_N (Sym (Simple.NTCo:HasIf[0] <GHC.Types.Bool>_N)) ∷ LambdaCCC.Lambda.EP (GHC.Types.Bool → GHC.Types.Bool → GHC.Types.Bool → GHC.Types.Bool) ~# LambdaCCC.Lambda.EP (Simple.HasIf GHC.Types.Bool))) Role incompatibility: expected nominal, got representationalin <LambdaCCC.Lambda.EP>_N (Sym (Simple.NTCo:HasIf[0] <GHC.Types.Bool>_N)) Do you see anything inconsistent/incompatible in the coercions or roles above? I constructed the nominal EP Refl coercion, and applied it (AppCo) an existing coercion of a simpler type. Thanks, -- Conal

3 7

Re: [commit: ghc] master: Fix linked list manipulation code (buggy on consecutive deletion) (e3938f3)
by Simon Marlow 14 Apr '14

14 Apr '14

Thanks Edward. Austin, can you cherry-pick this for 7.8.3 please? Cheers, Simon On 13/04/2014 07:37, git(a)git.haskell.org wrote: > Repository : ssh://git@git.haskell.org/ghc > > On branch : master > Link : http://ghc.haskell.org/trac/ghc/changeset/e3938f3adac0093b23694fd347774244c… > >> --------------------------------------------------------------- > > commit e3938f3adac0093b23694fd347774244ce121478 > Author: Edward Z. Yang <ezyang(a)cs.stanford.edu> > Date: Sat Apr 12 23:02:13 2014 -0700 > > Fix linked list manipulation code (buggy on consecutive deletion) > > Signed-off-by: Edward Z. Yang <ezyang(a)cs.stanford.edu> > > >> --------------------------------------------------------------- > > e3938f3adac0093b23694fd347774244ce121478 > rts/CheckUnload.c | 3 ++- > rts/Linker.c | 6 ++++-- > 2 files changed, 6 insertions(+), 3 deletions(-) > > diff --git a/rts/CheckUnload.c b/rts/CheckUnload.c > index f1f454c..98f184b 100644 > --- a/rts/CheckUnload.c > +++ b/rts/CheckUnload.c > @@ -298,7 +298,7 @@ void checkUnload (StgClosure *static_objects) > // marked as unreferenced can be physically unloaded, because we > // have no references to it. > prev = NULL; > - for (oc = unloaded_objects; oc; prev = oc, oc = next) { > + for (oc = unloaded_objects; oc; oc = next) { > next = oc->next; > if (oc->referenced == 0) { > if (prev == NULL) { > @@ -312,6 +312,7 @@ void checkUnload (StgClosure *static_objects) > } else { > IF_DEBUG(linker, debugBelch("Object file still in use: %" > PATH_FMT "\n", oc->fileName)); > + prev = oc; > } > } > > diff --git a/rts/Linker.c b/rts/Linker.c > index af26d74..ab235e9 100644 > --- a/rts/Linker.c > +++ b/rts/Linker.c > @@ -3016,8 +3016,8 @@ unloadObj( pathchar *path ) > IF_DEBUG(linker, debugBelch("unloadObj: %" PATH_FMT "\n", path)); > > prev = NULL; > - for (oc = objects; oc; prev = oc, oc = next) { > - next = oc->next; > + for (oc = objects; oc; oc = next) { > + next = oc->next; // oc might be freed > > if (!pathcmp(oc->fileName,path)) { > > @@ -3075,6 +3075,8 @@ unloadObj( pathchar *path ) > /* This could be a member of an archive so continue > * unloading other members. */ > unloadedAnyObj = HS_BOOL_TRUE; > + } else { > + prev = oc; > } > } > > > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits >

1 0

Has the behavior of -fno-ghci-sandbox changed with ghc-7.8.2?
by Dominick Samperi 13 Apr '14

13 Apr '14

I ticket #8371 I reported a problem using embedded R with ghci (no problem when application is compiled with ghc). The work-around was to use the option -fno-ghci-sandbox with ghci, as this prevented ghci from starting a new thread (R is not thread-safe). This worked fine with pre-release ghci 7.7 (built from source using BuildFlavour = quick), but now I get a segfault on startup using ghci 7.8.2, suggesting that the behavior of -fno-ghci-sandbox may have changed, perhaps because of the way the Linux binary distribution was built. Has the behavior of -fno-ghci-sandbox changed, or could it have been changed because of the way the Linux binary distribution was built? BTW, I would have posted this as a follow-up to the ticket but I forgot my password. How does one reset the password on the ticket tracker site? Thanks, Dominick

1 1