- ghc-devs - Haskell.org

RE: [commit: ghc] master: Remove the final vestiges of InlineWrappers (e4a1d2d)
by Simon Peyton-Jones 02 Sep '13

02 Sep '13

This patch makes an interface-file format change, so you'll need to blow away your build tree when you pull it. Simon | -----Original Message----- | From: ghc-commits [mailto:ghc-commits-bounces@haskell.org] On Behalf Of | git(a)git.haskell.org | Sent: 02 September 2013 11:13 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] master: Remove the final vestiges of | InlineWrappers (e4a1d2d) | | Repository : ssh://git@git.haskell.org/ghc | | On branch : master | Link : | http://ghc.haskell.org/trac/ghc/changeset/e4a1d2d0a71bf335a04eaf93deb440 | b709f9430e/ghc | | >--------------------------------------------------------------- | | commit e4a1d2d0a71bf335a04eaf93deb440b709f9430e | Author: Simon Peyton Jones <simonpj(a)microsoft.com> | Date: Mon Sep 2 09:46:59 2013 +0100 | | Remove the final vestiges of InlineWrappers | | Part of Nick Frisby's patch | (c080f727ba5f83921b842fcff71e9066adbdc250) | for late demand-analysis removed the over-zealous short-cut whereby | strictness wrappers were not spelled out in detail in interface | files. | | This patch completes the process by | * removing InlineWrapper from UnfoldingSource | * removing IfWrapper from IfaceUnfolding | | There was a tiny bit of special ad-hocery for wrappers, in | OccurAnal, | but fortunately that too turns out to be rendered irrelevant by | the more uniform treatment, and after that there was no need | to remember which functions are wrappers. | | | >--------------------------------------------------------------- | | e4a1d2d0a71bf335a04eaf93deb440b709f9430e | compiler/coreSyn/CoreSyn.lhs | 31 ++++++++++++----- | compiler/coreSyn/CoreUnfold.lhs | 2 +- | compiler/coreSyn/PprCore.lhs | 1 - | compiler/iface/IfaceSyn.lhs | 15 ++------ | compiler/iface/MkIface.lhs | 1 - | compiler/iface/TcIface.lhs | 29 ---------------- | compiler/simplCore/OccurAnal.lhs | 70 ++++++++++++++++++++----------- | ------- | 7 files changed, 63 insertions(+), 86 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 | e4a1d2d0a71bf335a04eaf93deb440b709f9430e | | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | http://www.haskell.org/mailman/listinfo/ghc-commits

1 0

Nightlies not working?
by Edward Z. Yang 02 Sep '13

02 Sep '13

The last nightly I see is from the 22nd; did they get turned off? Edward

3 2

Current state of ghc boot lib versions vs. hackage
by Herbert Valerio Riedel 01 Sep '13

01 Sep '13

I've compared what versions current GHC HEAD uses w/ vs. what's currently available on Hackage (see below); So currently, the following packages have newer versions available on hackage than are used in GHC HEAD: - binary - containers - primitive - time - vector In order to clarify a point that has been an issue in the past: Can it be assumed that the GHC 7.8 feature-freeze scheduled for 14 Sept 2013[1] is also the library version freeze deadline, by which upstream package authors shall submit new package versions they want to ship as GHC boot libs w/ GHC 7.8.1? (and thus should be given an "heads-up" asap) ------------------------------------------------------------ package hackage GHC HEAD ------------------------------------------------------------ Cabal 1.18.0 == 1.18.0 array 0.4.0.1 < 0.4.0.2 base 4.6.0.1 < 4.7.0.0 bin-package-db 0.0.0.0 == 0.0.0.0 binary 0.7.1.0 > 0.7.0.0 bytestring 0.10.2.0 < 0.10.3.0 containers 0.5.2.1 > 0.5.0.0 deepseq 1.3.0.1 < 1.3.0.2 directory 1.2.0.1 == 1.2.0.1 dph-base 0.7.0.1 < 0.8.0.1 (dph-lifted-base) 0.7.0.1 < 0.8.0.1 (dph-lifted-boxed) - 0.8.0.1 (dph-lifted-copy) 0.7.0.1 < 0.8.0.1 (dph-lifted-vseg) 0.7.0.1 < 0.8.0.1 (dph-prim-interface) 0.7.0.1 < 0.8.0.1 (dph-prim-par) 0.7.0.1 < 0.8.0.1 (dph-prim-seq) 0.7.0.1 < 0.8.0.1 filepath 1.3.0.1 < 1.3.0.2 (ghc) 7.6.3 < 7.7.20130826 ghc-prim 0.3.0.0 < 0.3.1.0 haskeline 0.7.0.3 < 0.7.0.4 (haskell2010) 1.1.1.0 == 1.1.1.0 (haskell98) 2.0.0.2 < 2.0.0.3 hoopl 3.9.0.0 < 3.10.0.0 hpc 0.6.0.0 < 0.6.0.1 integer-gmp 0.5.0.0 < 0.5.1.0 old-locale 1.0.0.5 == 1.0.0.5 old-time 1.1.0.1 == 1.1.0.1 pretty 1.1.1.0 == 1.1.1.0 primitive 0.5.0.1 > 0.4.0.1 process 1.1.0.2 < 1.2.0.0 random 1.0.1.1 == 1.0.1.1 rts 1.0 == 1.0 template-haskell 2.8.0.0 < 2.9.0.0 terminfo 0.3.2.5 == 0.3.2.5 time 1.4.1 > 1.4.0.2 transformers 0.3.0.0 == 0.3.0.0 unix 2.6.0.1 < 2.7.0.0 vector 0.10.0.1 > 0.9.1 xhtml 3000.2.1 == 3000.2.1 ------------------------------------------------------------ Cheers, hvr [1]: http://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.8

5 4

Anyone having trouble with "make install" in HEAD?
by Ryan Newton 01 Sep '13

01 Sep '13

Earlier this summer I had no problem with "configure; make; make install" But recently I'm getting errors like this on GHC HEAD: /u/rrnewton/opt/ghc-7.7.20130831/lib/ghc-7.7.20130831/bin/ghc-pkg: error while loading shared libraries: libHSbin-package-db-0.0.0 .0-ghc7.7.20130831.so: cannot open shared object file: No such file or directory That is, the inplace build is fully functional but it just won't install. Any ideas? Thanks, -Ryan

2 1

Building GHCi with static linking
by Edward Z. Yang 31 Aug '13

31 Aug '13

We now build GHC with dynamic linking by default, but I recently attempted a build with static linking instead. Using: DYNAMIC_GHC_PROGRAMS=NO GhcDebugged=YES I got: "inplace/bin/ghc-stage2" -hisuf hi -osuf o -hcsuf hc -static -H64m -O -fasm -package-name vector-0.9.1 -hide-all-packages -i -ilibraries/vector/. -ilibraries/vector/dist-install/build -ilibraries/vector/dist-install/build/autogen -Ilibraries/vector/dist-install/build -Ilibraries/vector/dist-install/build/autogen -Ilibraries/vector/include -Ilibraries/vector/internal -optP-DVECTOR_BOUNDS_CHECKS -optP-include -optPlibraries/vector/dist-install/build/autogen/cabal_macros.h -package base-4.7.0.0 -package ghc-prim-0.3.1.0 -package primitive-0.4.0.1 -O2 -XHaskell98 -XCPP -XDeriveDataTypeable -O -dcore-lint -no-user-package-db -rtsopts -odir libraries/vector/dist-install/build -hidir libraries/vector/dist-install/build -stubdir libraries/vector/dist-install/build -c libraries/vector/./Data/Vector/Fusion/Stream/Monadic.hs -o libraries/vector/dist-install/build/Data/Vector/Fusion/Stream/Monadic.o Loading package ghc-prim ... <command line>: can't load .so/.DLL for: libHSghc-prim-0.3.1.0.so (libHSghc-prim-0.3.1.0.so: cannot open shared object file: No such file or directory) Is there another build flag I have to trigger? It looks like ghc-stage2 is still attempting load things dynamically. Cheers, Edward

1 0

Nofib missing dependencies
by Edward Z. Yang 31 Aug '13

31 Aug '13

Hey Ian, I'm not sure, but I think when you made the nofib build system independent of the GHC build system, we may have lost dependency calculation for the HS files. For example, when I try to build spectral/awards, make tries to ghc -c Main.hs before it has done ghc -c QSort.hs (I hacked up the Makefile to explicitly have this dependency, but there are others). Unfortunately, my Makefile-fu is not great enough to resolve this. Do you know what is the problem? Edward

1 1

Compiling GHC with something like distcc?
by Erik de Castro Lopo 31 Aug '13

31 Aug '13

Hi all, Does anyone have any experience reports on compiling GHC with something like distcc? Don Stewart reports doing it here: http://stackoverflow.com/questions/10323419/is-there-a-distcc-like-tool-for… but there are no detail. Cheers, Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

1 0

include the new -flate-dmd-anal in -O2?
by Nicolas Frisby 30 Aug '13

30 Aug '13

TO: Performance czars and devs I pushed a patch yesterday enabling a second demand analysis at the end of the core2core simplification pipeline. The flag is -flate-dmd-anal, and it is off by default. My question: What's the protocol for deciding if -O2 should imply it? See http://ghc.haskell.org/trac/ghc/wiki/LateDmd for context. In particular, this section includes highlights of some nofib runs I did. http://ghc.haskell.org/trac/ghc/wiki/LateDmd#Newperformancenumbers For some tests, it decreases allocation by 10% to 20%. But on the platforms I have tried, it causes a couple repeatable slowdowns, up to 10%. I've investigated a bit, but haven't found any clear explanations. I'm worried that it's caching effects, eg. Any suggestions on how I should proceed with my investigation? Also: I'd appreciate if any developer would generously run some benchmarks on various platforms they might have and add them to the same section in the wiki page. http://ghc.haskell.org/trac/ghc/wiki/LateDmd#Newperformancenumbers NB That it is unfortunately key to build the libraries twice: once with -flate-dmd-anal in GhcLibHcOpts and once without. I have not determined how to do this robustly without a distclean — please let me know if you have a better method. So I've used # one of the following #GhcLibHcOpts = -O2 # both with and without -flate-dmd-anal GhcLibHcOpts = -O2 -flate-dmd-anal SplitObjs = NO DYNAMIC_BY_DEFAULT = NO DYNAMIC_GHC_PROGRAMS = NO The last three aren't necessary, but please record what you use, if you are so generous as to run it :). Thanks.

3 2

Re: Cannot make ghc: Failed to load interface for GHC.Base
by Dan Rosén 30 Aug '13

30 Aug '13

No! Sorry for the confusion Simon, it is HEAD _PLUS_ my own commit that triggers these errors. Oh, and I should add that 'my own commit' is only in my own development repository. So, no worries! /Dan On Fri, Aug 30, 2013 at 4:44 PM, Simon Peyton-Jones <simonpj(a)microsoft.com>wrote: > Wait.. are you saying that with HEAD several test suite programs fail as > you describe below? If so, which? > > Simion**** > > ** ** > > *From:* ghc-devs [mailto:ghc-devs-bounces@haskell.org] *On Behalf Of *Dan > Rosén > *Sent:* 30 August 2013 14:26 > *To:* David Luposchainsky > *Cc:* ghc-devs(a)haskell.org > *Subject:* Re: Cannot make ghc: Failed to load interface for GHC.Base**** > > ** ** > > Closed, but a note to interested readers: > > killy9999 on #ghc realized the reason why the stage1 compiler cannot be > built with this patch is related to that several test suite programs exit > with erros like this:**** > > GHC/Base.lhs:1:1:**** > > GHC internal error: 'GHC.Base.Monad' is not in scope during type checking, but it passed the renamer**** > > tcl_env of environment: []**** > > > So the error is resolved, and now productive debugging can start.**** > > ** ** > > On Fri, Aug 30, 2013 at 2:50 PM, Dan Rosén <danr(a)chalmers.se> wrote:**** > > Sorry! I thought I got this build error when making HEAD, but I don't. > It builds fine. > > However, if I just cherry-pick this simple commit onto HEAD > https://github.com/danr/ghc/commit/86631ffd294af320cb9b00e1a593201af887ed72 > , > then I do get this error, which is very puzzling. I did a make > maintainer-clean in between. **** > > ** ** > > On Thu, Aug 29, 2013 at 6:05 PM, David Luposchainsky < > dluposchainsky(a)googlemail.com> wrote:**** > > On 2013-08-29 18:03, Austin Seipp wrote: > > When was the last time you cleaned your tree? Earlier this week I made a > > breaking change to the interface file format. If you have a build from > > before then, update and incrementally rebuild, it will break.**** > > I tried all of clean, distclean and maintainer-clean, followed by the > usual build process. The issue remains.**** > > > David > > > _______________________________________________ > ghc-devs mailing list > ghc-devs(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-devs**** > > ** ** > > ** ** >

1 0

Re: Cannot make ghc: Failed to load interface for GHC.Base
by Dan Rosén 30 Aug '13

30 Aug '13

Closed, but a note to interested readers: killy9999 on #ghc realized the reason why the stage1 compiler cannot be built with this patch is related to that several test suite programs exit with erros like this: GHC/Base.lhs:1:1: GHC internal error: 'GHC.Base.Monad' is not in scope during type checking, but it passed the renamer tcl_env of environment: [] So the error is resolved, and now productive debugging can start. On Fri, Aug 30, 2013 at 2:50 PM, Dan Rosén <danr(a)chalmers.se> wrote: > Sorry! I thought I got this build error when making HEAD, but I don't. > It builds fine. > > However, if I just cherry-pick this simple commit onto HEAD > https://github.com/danr/ghc/commit/86631ffd294af320cb9b00e1a593201af887ed72 > , > then I do get this error, which is very puzzling. I did a make > maintainer-clean in between. > > > > On Thu, Aug 29, 2013 at 6:05 PM, David Luposchainsky < > dluposchainsky(a)googlemail.com> wrote: > >> On 2013-08-29 18:03, Austin Seipp wrote: >> > When was the last time you cleaned your tree? Earlier this week I made a >> > breaking change to the interface file format. If you have a build from >> > before then, update and incrementally rebuild, it will break. >> >> I tried all of clean, distclean and maintainer-clean, followed by the >> usual build process. The issue remains. >> >> David >> >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs(a)haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs >> > >

2 1