============================================================= The (Interactive) Glasgow Haskell Compiler -- version 6.8.3 ============================================================= The GHC Team is pleased to announce a new patchlevel release of GHC. This release contains a number of bugfixes relative to 6.8.2, so we recommend upgrading. Release notes are here: http://haskell.org/ghc/docs/6.8.3/html/users_guide/release-6-8-3.html How to get it ~~~~~~~~~~~~~ The easy way is to go to the web page, which should be self-explanatory: http://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~~~~~~~~~ Haskell is a standard lazy functional programming language; the current language version is Haskell 98, agreed in December 1998 and revised December 2002. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating good code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces (C, whatever). GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ GHC developers' home page http://hackage.haskell.org/trac/ghc/ Haskell home page http://www.haskell.org/ Supported Platforms ~~~~~~~~~~~~~~~~~~~ The list of platforms we support, and the people responsible for them, is here: http://hackage.haskell.org/trac/ghc/wiki/Contributors Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: http://hackage.haskell.org/trac/ghc/wiki/Building Developers ~~~~~~~~~~ We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site run by Trac: http://hackage.haskell.org/trac/ghc/ Mailing lists ~~~~~~~~~~~~~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at http://www.haskell.org/mailman/listinfo/glasgow-haskell-users http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see http://www.haskell.org/mailman/listinfo/ Some GHC developers hang out on #haskell on IRC, too: http://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: http://www.haskell.org/ghc/reportabug
Ian Lynagh:
============================================================= The (Interactive) Glasgow Haskell Compiler -- version 6.8.3 =============================================================
The GHC Team is pleased to announce a new patchlevel release of GHC. This release contains a number of bugfixes relative to 6.8.2, so we recommend upgrading.
An installer package for Mac OS X, Intel/Leopard, is available at http://www.cse.unsw.edu.au/~chak/haskell/GHC-6.8.3-i386.pkg The packages requires Xcode 3.0 to be already installed. You can find Xcode 3.0 on your Leopard installation DVD (or at <http://developer.apple.com
.)
IF you installed one of the pre-release packages AND the final release package doesn't install properly, just remove the pre-release first by executing sudo /Library/Frameworks/GHC.framework/Tools/Uninstaller (You can remove any other GHC installer package in the same way.) Manuel PS: I will post instructions on how to create a PPC/Leopard installer package in the next few days (unfortunately, the 6.8.3 release tar ball is not sufficient). Package creation does not currently work for Tiger.
On Wed, Jun 18, 2008 at 10:22:39PM +1000, Manuel M T Chakravarty wrote:
An installer package for Mac OS X, Intel/Leopard, is available at
Thanks Manuel; I've added this to the GHC download page. Thanks Ian
Hi, I've created the following binary distributions, but -- like Serge Mechveliani -- I'm not very happy with the results, because the created binaries are much bigger. http://www.dfki.de/sks/hets/pc-solaris/ghcs/ghc-6.8.3-i386-unknown-solaris2.... http://www.dfki.de/sks/hets/pc-solaris/ghcs/ghc-6.8.3-tests.log.bz2 http://www.dfki.de/sks/hets/mac/ghcs/ghc-6.8.3-powerpc-apple-darwin.tar.bz2 http://www.dfki.de/sks/hets/mac/ghcs/ghc-6.8.3-tests.log.bz2 The log files contain the results of running "(g)make stage=2" in testsuite/tests/ghc-regress. The summaries are below. The Tiger Mac OS PPC (8.11.0 Darwin) distribution relies on libreadline.5.2.dylib and libncurses.5.dylib under /opt/local/lib/. libgmp.a is statically linked in. Due to the increased code sizes it is more likely to get "relocation overflow" (therefore this distribution does not work for our hets project). http://hackage.haskell.org/trac/ghc/ticket/2031 For i386 Solaris it would be good to have a GHC build slave to improve the testsuite results (below) and to avoid building problems (that Ian Lynagh helped to resolve before. Thanks!). The sizes of our compressed hets binaries increased as follows: ghc-6.8.2 ghc-6.8.3 i386-Solaris 10 Mb 16 Mb i386-Darwin 7 Mb 13 Mb i386-Linux 7.2 Mb 10 Mb (i.e. compare http://www.dfki.de/sks/hets/linux/daily/ with a recent http://www.dfki.de/sks/hets/linux/versions/) I gave up (I'm not through) with sparc Solaris as it takes too long and gcc-4.2.2 crashed for one large .hc file from our sources (with segmentation fault). An unofficial i386-Darwin (Leopard) distribution can be found at http://www.dfki.de/sks/hets/intel-mac/ghcs/ (needs libgmp.3.dylib), but use http://www.cse.unsw.edu.au/~chak/haskell/GHC-6.8.3-i386.pkg if you can. Cheers Christian ppc-Darwin (Tiger): OVERALL SUMMARY for test run started at Thu Jun 19 12:42:52 CEST 2008 2148 total tests, which gave rise to 11032 test cases, of which 0 caused framework failures 2309 were skipped 8490 expected passes 195 expected failures 0 unexpected passes 38 unexpected failures Unexpected failures: conc049(threaded2) conc052(profc,profasm) conc053(threaded2) divbyzero(normal,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2) ffi009(ghci) galois_raytrace(optc,profc) ghci024(ghci) joao-circular(profc) net001(normal,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2) num012(normal,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2) seward-space-leak(ghci) signals002(ghci) i386-Solaris: OVERALL SUMMARY for test run started at Wed Jun 18 17:09:48 CEST 2008 2148 total tests, which gave rise to 11032 test cases, of which 0 caused framework failures 2315 were skipped 8448 expected passes 199 expected failures 0 unexpected passes 70 unexpected failures Unexpected failures: 1861(optc,profc) barton-mangler-bug(optc) bug1465(normal) cabal01(normal) conc052(profc,profasm) concprog002(threaded2) conflicting_flags(normal) derefnull(normal,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2) driver063(normal) expfloat(optc,profc) fun_insts(optc,profc) hClose002(normal,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2) joao-circular(profc) num009(normal,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2) num012(normal,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2) openFile003(normal,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2) regex001(ghci) user001(normal,optc,hpc,optasm,profc,profasm,ghci,threaded1,threaded2)
Christian Maeder wrote:
Hi,
I've created the following binary distributions, but -- like Serge Mechveliani -- I'm not very happy with the results, because the created binaries are much bigger.
http://www.dfki.de/sks/hets/pc-solaris/ghcs/ghc-6.8.3-i386-unknown-solaris2....
http://www.dfki.de/sks/hets/pc-solaris/ghcs/ghc-6.8.3-tests.log.bz2
http://www.dfki.de/sks/hets/mac/ghcs/ghc-6.8.3-powerpc-apple-darwin.tar.bz2 http://www.dfki.de/sks/hets/mac/ghcs/ghc-6.8.3-tests.log.bz2
The log files contain the results of running "(g)make stage=2" in testsuite/tests/ghc-regress. The summaries are below.
The Tiger Mac OS PPC (8.11.0 Darwin) distribution relies on libreadline.5.2.dylib and libncurses.5.dylib under /opt/local/lib/. libgmp.a is statically linked in.
Due to the increased code sizes it is more likely to get "relocation overflow" (therefore this distribution does not work for our hets project). http://hackage.haskell.org/trac/ghc/ticket/2031
For i386 Solaris it would be good to have a GHC build slave to improve the testsuite results (below) and to avoid building problems (that Ian Lynagh helped to resolve before. Thanks!).
The sizes of our compressed hets binaries increased as follows: ghc-6.8.2 ghc-6.8.3 i386-Solaris 10 Mb 16 Mb i386-Darwin 7 Mb 13 Mb i386-Linux 7.2 Mb 10 Mb
(i.e. compare http://www.dfki.de/sks/hets/linux/daily/ with a recent http://www.dfki.de/sks/hets/linux/versions/)
That's odd - I measured binary sizes thoroughly before the release and didn't see any difference between 6.8.3 and 6.8.2. Perhaps -split-objs got lost somewhere? Or maybe you upgraded gcc at some point? Cheers, Simon
Simon Marlow wrote:
That's odd - I measured binary sizes thoroughly before the release and didn't see any difference between 6.8.3 and 6.8.2.
The size of ghc itself did not increase.
Perhaps -split-objs got lost somewhere? Or maybe you upgraded gcc at some point?
No (at least I don't think so). I suspect that we some "expensive" class instances (for our class Logic). Here is a list of our biggest object-files under linux: ghc-6.8.2: 2.0M CASL_DL/PredefinedCASLAxioms.o 1.2M HasCASL/ATC_HasCASL.o 984K Haskell/ATC_Haskell.o 896K Haskell/TiATC.o 888K VSE/ATC_VSE.o 832K CspCASL/ATC_CspCASL.o 832K ATC/Sml_cats.o 788K Modal/ATC_Modal.o 780K CASL/ATC_CASL.o 704K CASL_DL/ATC_CASL_DL.o 696K OMDoc/OMDocInput.o 564K CoCASL/ATC_CoCASL.o 544K SoftFOL/Sign.o 540K SoftFOL/ATC_SoftFOL.o 536K ATC/DevGraph.o 516K HasCASL/As.o 500K OMDoc/OMDocInterface.o 476K Haskell/TiPropATC.o 468K CASL/AS_Basic_CASL.o 460K OMDoc/HetsDefs.o 436K CASL_DL/PredefinedSign.o 420K Static/DevGraph.o 408K Haskell/HatAna.o 376K DL/ATC_DL.o 368K CASL/StaticAna.o 348K SoftFOL/MathServParsing.o 344K Static/AnalysisStructured.o 324K OMDoc/OMDocOutput.o 324K CASL/ColimSign.o 324K CASL/Amalgamability.o 324K CoCASL/Logic_CoCASL.o 320K Logic/Grothendieck.o 316K OWL/AS.o 316K ConstraintCASL/Logic_ConstraintCASL.o 316K OWL/ReadWrite.o 312K CASL/Logic_CASL.o ghc-6.8.3: 11M COL/Logic_COL.o 11M CASL/Logic_CASL.o 11M ConstraintCASL/Logic_ConstraintCASL.o 11M CoCASL/Logic_CoCASL.o 11M Modal/Logic_Modal.o 11M VSE/Logic_VSE.o 10M CASL_DL/Logic_CASL_DL.o 4,8M CoCASL/ATC_CoCASL.o 2,6M Modal/ATC_Modal.o 2,0M CASL_DL/PredefinedCASLAxioms.o 1,3M Haskell/ATC_Haskell.o 1,3M HasCASL/ATC_HasCASL.o 1,2M CspCASL/Logic_CspCASL.o 997K Haskell/TiPropATC.o 889K VSE/ATC_VSE.o 877K CspCASL/ATC_CspCASL.o 777K ATC/DevGraph.o 757K ATC/Sml_cats.o 737K SoftFOL/ATC_SoftFOL.o 729K Haskell/TiDecorateATC.o 717K CASL_DL/ATC_CASL_DL.o 697K OMDoc/OMDocInput.o P.S. The sources can be checked out (if you dare) from https://svn-agbkb.informatik.uni-bremen.de/Hets/trunk see more http://trac.informatik.uni-bremen.de:8080/hets/wiki/HetsForDevelopers
Hi Simon, maybe you can suggest a global flag setting that avoids too much inlining during optimization. Cheers Christian Christian Maeder wrote:
No (at least I don't think so). I suspect that we some "expensive" class instances (for our class Logic). Here is a list of our biggest object-files under linux:
ghc-6.8.3: 11M COL/Logic_COL.o 11M CASL/Logic_CASL.o 11M ConstraintCASL/Logic_ConstraintCASL.o 11M CoCASL/Logic_CoCASL.o 11M Modal/Logic_Modal.o 11M VSE/Logic_VSE.o 10M CASL_DL/Logic_CASL_DL.o 4,8M CoCASL/ATC_CoCASL.o 2,6M Modal/ATC_Modal.o 2,0M CASL_DL/PredefinedCASLAxioms.o
| maybe you can suggest a global flag setting that avoids too much | inlining during optimization. As I said to Serge, I *think* all this arises from the *unconditional* inlining of instance declarations, which isn't under flag control unfortunately. The only fix at the moment is to write instance decls whose code is small -- just call a separate top-level function instance C T where op = op_T op_T = .... But this is highly unsatisfactory. I just need to find a clear day or two to look into this carefully. Stay tuned. Simon | Cheers Christian | | Christian Maeder wrote: | > No (at least I don't think so). I suspect that we some "expensive" class | > instances (for our class Logic). Here is a list of our biggest | > object-files under linux: | >
Maybe, -O needs to denote for the compiler some reasonable degree of inlininig, both for functions and instances? ----------- Mechveliani On Sat, Jun 21, 2008 at 03:00:15PM +0100, Simon Peyton-Jones wrote:
| maybe you can suggest a global flag setting that avoids too much | inlining during optimization.
As I said to Serge, I *think* all this arises from the *unconditional* inlining of instance declarations, which isn't under flag control unfortunately. The only fix at the moment is to write instance decls whose code is small -- just call a separate top-level function instance C T where op = op_T
op_T = ....
But this is highly unsatisfactory. I just need to find a clear day or two to look into this carefully. Stay tuned.
Simon
| Cheers Christian | | Christian Maeder wrote: | > No (at least I don't think so). I suspect that we some "expensive" class | > instances (for our class Logic). Here is a list of our biggest | > object-files under linux: | > _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Since I've switched back from ghc-6.8.3 to ghc-6.8.2 I would like to see a new minor ghc version 6.8.4 with this "bug" fixed. Cheers Christian Simon Peyton-Jones wrote:
As I said to Serge, I *think* all this arises from the *unconditional* inlining of instance declarations, which isn't under flag control unfortunately. The only fix at the moment is to write instance decls whose code is small -- just call a separate top-level function instance C T where op = op_T
op_T = ....
But this is highly unsatisfactory. I just need to find a clear day or two to look into this carefully. Stay tuned.
Simon Peyton-Jones wrote:
As I said to Serge, I *think* all this arises from the *unconditional* inlining of instance declarations, which isn't under flag control unfortunately. The only fix at the moment is to write instance decls whose code is small -- just call a separate top-level function instance C T where op = op_T
op_T = ....
I've changed our generation of instances to follow this pattern and indeed the object code size is much smaller! This is a workaround for http://hackage.haskell.org/trac/ghc/ticket/955 Thanks Christian
On Fri, Jun 20, 2008 at 11:13:54AM +0200, Christian Maeder wrote:
I've created the following binary distributions
http://www.dfki.de/sks/hets/pc-solaris/ghcs/ghc-6.8.3-i386-unknown-solaris2.... http://www.dfki.de/sks/hets/mac/ghcs/ghc-6.8.3-powerpc-apple-darwin.tar.bz2 http://www.dfki.de/sks/hets/intel-mac/ghcs/
Thanks Christian; I've added these to the GHC download page. Thanks Ian
participants (6)
-
Christian Maeder -
Ian Lynagh -
Manuel M T Chakravarty -
Serge D. Mechveliani -
Simon Marlow -
Simon Peyton-Jones