- ghc-devs - Haskell.org

GHC Weekly News - 2015/01/19
by Austin Seipp 19 Jan '15

19 Jan '15

Hi *, It's time for some more GHC news! The GHC 7.10 release is closing in, which has been the primary place we're focusing our attention. In particular, we're hoping RC2 will be Real Soon Now. Some notes from the past GHC HQ meetings this week: - GHC 7.10 is still rolling along smoothly, and it's expected that RC2 will be cut this Friday, January 23rd. Austin sent out an email about this to `ghc-devs`, so we can hopefully get all the necessary fixes in. - Our status page for GHC 7.10 lists all the current bullet points and tickets we hope to address: https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.1 - Currently, GHC HQ isn't planning on focusing many cycles on any GHC 7.10 tickets that aren't '''highest priority'''. We're otherwise going to fix things as we see fit, at our leisure - but a highest priority bug is a showstopper for us. This means if you have something you consider a showstopper for the next release, you should bump the priority on the ticket and yell at us! - We otherwise think everything looks pretty smooth for 7.10.1 RC2 - our libraries are updated, and most of the currently queued patches (with a few minor exceptions) are done and merged. Some notes from the mailing list include: - Austin announced the GHC 7.10.1 RC2 cutoff, which will be on '''Friday the 23rd'''. https://www.haskell.org/pipermail/ghc-devs/2015-January/008026.html - Austin has alerted everyone that soon, Phabricator will run all builds with `./validate --slow`, which will increase the time taken for most builds, but will catch a wider array of bugs in commits and submitted patches - there are many cases the default `./validate` script still doesn't catch. https://www.haskell.org/pipermail/ghc-devs/2015-January/008030.html - Johan Tibell asked about some clarifications for the `HsBang` datatype inside GHC. In response, Simon came back with some clarifications, comments, and refactorings, which greatly helped Johan. ttps://www.haskell.org/pipermail/ghc-devs/2015-January/007905.html - Jens Petersen announced a Fedora Copr repo for GHC 7.8.4: https://www.haskell.org/pipermail/ghc-devs/2015-January/007978.html - Richard Eisenberg had a question about the vectoriser: can we disable it? DPH seems to have stagnated a bit recently, bringing into question the necessity of keeping it on. There hasn't been anything done yet, but it looks like the build will get lighter, with a few more modules soon: https://www.haskell.org/pipermail/ghc-devs/2015-January/007986.html - Ben Gamari has an interesting email about trying to optimize `bytestring`, but he hit a snag with small literals being floated out causing very poor assembly results. Hopefully Simon (or anyone!) can follow up soon with some help: https://www.haskell.org/pipermail/ghc-devs/2015-January/007997.html - Konrad Gądek asks: why does it seem the GHC API is slower at calling native code than a compiled executable is? Konrad asks as this issue of performance is particularly important for their work. https://www.haskell.org/pipermail/ghc-devs/2015-January/007990.html - Jan Stolarek has a simple question: what English spelling do we aim for in GHC? It seems that while GHC supports an assortment of British and American english syntactic literals (e.g. `SPECIALIZE` and `SPECIALISE`), the compiler sports an assortment of British/American identifiers on its own! https://www.haskell.org/pipermail/ghc-devs/2015-January/007999.html - Luis Gabriel has a question about modifying the compiler's profiling output, particularly adding a new CCS (Cost Centre Structure) field. He's hit a bug it seems, and is looking for help with his patch. https://www.haskell.org/pipermail/ghc-devs/2015-January/008015.html Closed tickets the past few weeks include: #9966, #9904, #9969, #9972, #9934, #9967, #9875, #9900, #9973, #9890, #5821, #9984, #9997, #9998, #9971, #10000, #10002, #9243, #9889, #9384, #8624, #9922, #9878, #9999, #9957, #7298, and #9836. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

1 0

RC2 Cutoff at the end of this week
by Austin Seipp 19 Jan '15

19 Jan '15

Hi *, I just wanted to let everyone know we plan on releasing RC2 at the end of this week, on Friday. We're hoping this will be the final RC before we do the actual release, so if you want to get your fixes in for users to test - now is the time! Specifically, here are a few things: - Edward, can you please merge D614 and D603? I think we should pull these into the 7.10 branch. - Erik, can you follow up on D599? It would be nice to have this in early. - Alan, I'll get D538 & D620 into 7.10 today, it just requires a more delicate merge I think (there are probably some parent commits to pick up). - Peter W, I'll get to #9961 later today, but if you don't mind, please post future things to Phabricator - it makes it much easier for a proper review (although your fix looks good still!) - Peter T, D622 looks OK to go into 7.10 and HEAD to me, so I can merge it. I'll follow up with a curated list of Trac tickets for the final release (in another email). Let me know if you have questions. Thanks. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

3 2

Re: ANNOUNCE: GHC 7.10.1 Release Candidate 1 - questions on Mac OS platform
by George Colpitts 19 Jan '15

19 Jan '15

- Has anybody successfully used llvm on the Mac with 7.10.1 RC1? My problem is described below. - Which is the recommended gcc to use when building source? - GNU gcc 4.9.2 - Apple LLVM version 6.0 (clang-600.0.56) (based on LLVM 3.5svn) - When using ghci with 7.10.1 RC1 I get the following errors intermittently. Is anybody else seeing these? - Too late for parseStaticFlags: call it before runGhc or runGhcT *** Exception: ExitFailure 1 - ld: library not found for -l:ghc31505_10.dylib collect2: error: ld returned 1 exit status phase `Linker' failed (exitcode = 1) Thanks On Fri, Jan 2, 2015 at 9:12 AM, George Colpitts <george.colpitts(a)gmail.com> wrote: > Only problem remaining is compiling with -fllvm and running resulting > executable > > . > .. > > > > - llvm , compiling with llvm (3.4.2) gives the following warnings: > - $ ghc -fllvm cubeFast.hs > [1 of 1] Compiling Main ( cubeFast.hs, cubeFast.o ) > 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 .' > clang: warning: argument unused during compilation: '-fno-common' > clang: warning: argument unused during compilation: '-U __PIC__' > clang: warning: argument unused during compilation: '-D __PIC__' > Linking cubeFast ... > - running the resulting executable crashes (compiling without > -fllvm gives no warnings and executable works properly) > - cat bigCube.txt | ./cubeFast > /dev/null > Segmentation fault: 11 > - Exception Type: EXC_BAD_ACCESS (SIGSEGV) > Exception Codes: KERN_INVALID_ADDRESS at 0xfffffffd5bfd8460 > > >> - ... >> >> Configuration details: >> >> >> - Mac OS 10.10.1 (Yosemite) >> - uname -a >> Darwin iMac27-5.local 14.0.0 Darwin Kernel Version 14.0.0: Fri Sep 19 >> 00:26:44 PDT 2014; root:xnu-2782.1.97~2/RELEASE_X86_64 x86_64 >> - llvm info: >> - opt --version >> LLVM (http://llvm.org/) >> LLVM version 3.4.2 >> Optimized build with assertions. >> Built Oct 31 2014 (23:14:30). >> Default target: x86_64-apple-darwin14.0.0 >> Host CPU: corei7 >> - gcc --version >> gcc (Homebrew gcc 4.9.1) 4.9.1 >> Copyright (C) 2014 Free Software Foundation, Inc. >> This is free software; see the source for copying conditions. There >> is NO >> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR >> PURPOSE. >> - /usr/bin/ghc --info >> [("Project name","The Glorious Glasgow Haskell Compilation System") >> ,("GCC extra via C opts"," -fwrapv") >> ,("C compiler command","/usr/bin/gcc") >> ,("C compiler flags"," -m64 -fno-stack-protector") >> ,("C compiler link flags"," -m64") >> ,("Haskell CPP command","/usr/bin/gcc") >> ,("Haskell CPP flags","-E -undef -traditional -Wno-invalid-pp-token >> -Wno-unicode -Wno-trigraphs") >> ,("ld command","/usr/bin/ld") >> ,("ld flags"," -arch x86_64") >> ,("ld supports compact unwind","YES") >> ,("ld supports build-id","NO") >> ,("ld supports filelist","YES") >> ,("ld is GNU ld","NO") >> ,("ar command","/usr/bin/ar") >> ,("ar flags","clqs") >> ,("ar supports at file","NO") >> ,("touch command","touch") >> ,("dllwrap command","/bin/false") >> ,("windres command","/bin/false") >> ,("libtool command","libtool") >> ,("perl command","/usr/bin/perl") >> ,("target os","OSDarwin") >> ,("target arch","ArchX86_64") >> ,("target word size","8") >> ,("target has GNU nonexec stack","False") >> ,("target has .ident directive","True") >> ,("target has subsections via symbols","True") >> ,("Unregisterised","NO") >> ,("LLVM llc command","llc") >> ,("LLVM opt command","opt") >> ,("Project version","7.8.3") >> ,("Booter version","7.6.3") >> ,("Stage","2") >> ,("Build platform","x86_64-apple-darwin") >> ,("Host platform","x86_64-apple-darwin") >> ,("Target platform","x86_64-apple-darwin") >> ,("Have interpreter","YES") >> ,("Object splitting supported","YES") >> ,("Have native code generator","YES") >> ,("Support SMP","YES") >> ,("Tables next to code","YES") >> ,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn >> thr_dyn thr_debug_dyn l_dyn thr_l_dyn") >> ,("Support dynamic-too","YES") >> ,("Support parallel --make","YES") >> ,("Dynamic by default","NO") >> ,("GHC Dynamic","YES") >> ,("Leading underscore","YES") >> ,("Debug on","False") >> >> ,("LibDir","/Library/Frameworks/GHC.framework/Versions/7.8.3-x86_64/usr/lib/ghc-7.8.3") >> ,("Global Package >> DB","/Library/Frameworks/GHC.framework/Versions/7.8.3-x86_64/usr/lib/ghc-7.8.3/package.conf.d") >> ] >> - Not sure I found the correct instructions for building from >> source, I used the following: >> - >> >> $ autoreconf >> $ ./configure >> $ make >> $ make install >> >> >> >> >> On Tue, Dec 23, 2014 at 10:36 AM, Austin Seipp <austin(a)well-typed.com> >> wrote: >> >>> We are pleased to announce the first release candidate for GHC 7.10.1: >>> >>> https://downloads.haskell.org/~ghc/7.10.1-rc1/ >>> >>> This includes the source tarball and bindists for 64bit/32bit Linux >>> and Windows. Binary builds for other platforms will be available >>> shortly. (CentOS 6.5 binaries are not available at this time like they >>> were for 7.8.x). These binaries and tarballs have an accompanying >>> SHA256SUMS file signed by my GPG key id (0x3B58D86F). >>> >>> We plan to make the 7.10.1 release sometime in February of 2015. We >>> expect another RC to occur during January of 2015. >>> >>> Please test as much as possible; bugs are much cheaper if we find them >>> before the release! >>> >>> -- >>> Regards, >>> >>> Austin Seipp, Haskell Consultant >>> Well-Typed LLP, http://www.well-typed.com/ >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs(a)haskell.org >>> http://www.haskell.org/mailman/listinfo/ghc-devs >>> >> >> >

2 3

HEADS UP: Enabling --slow validate on Phabricator
by Austin Seipp 19 Jan '15

19 Jan '15

Hi *, This is just a warning that soon, I'd like to enable --slow ./validate on Phabricator. What does this mean? It means that builds will take longer, but GHC will be tested much more thoroughly with each commit and with each patch that's submitted. Unfortunately, the bad news is that we've been pretty sloppy about making sure the --slow configuration always works... last I tried it (admittedly a little while ago) there were quite a few extra failures. However, this is just a pre-emptive warning that things may take longer, and a few things may break more soon. Particularly, there's now the chance Harbormaster will see failures that you did not see before! (for example, if you changed the code generator and broke the profiling build). But that's probably a good thing, since you can defer to checking slow tests afterwords. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

1 0

Out of memory mystery
by Lennart Augustsson 19 Jan '15

19 Jan '15

I'm running the 32-bit Windows version of ghc-7.8.3. Here are two runs: $ RunMu +RTS -A64M -h -Sstat.log -i1 -RTS -c Strat.App.Abacus.Main Compiling afresh Strat.App.Abacus.Main Compiled afresh Strat.App.Abacus.Main, 1302.84s $ RunMu +RTS -A64M -Sstat.log -i1 -RTS -c Strat.App.Abacus.Main Compiling afresh Strat.App.Abacus.Main RunMu.exe: out of memory The binary is compiled without profiling, but in the first run I'm using the -h flag to get the rudimentary heap profile. And with -h it works, but without the flag it runs out of memory. Any bright ideas from the RTS experts on why this could happen? -- Lennart

3 2

Re: GHC 7.4.2 on Ubuntu Trusty
by Herbert Valerio Riedel 19 Jan '15

19 Jan '15

Hello Edward, On 2015-01-04 at 08:54:58 +0100, Edward Z. Yang wrote: [...] > There are also some changes to hoopl, transformers and hpc (mostly > because their bootstrap libraries.) ...what kind of changes specifically? Once thing that needs to be considered is that we'd require to upstream changes to transformers (it's not under GHC HQ's direct control) for a transformers point(?) release ... and we'd need that as we can't release any source-tarball that contains libraries (which get installed into the pkg-db) that don't match their upstream version on Hackage. Cheers, hvr

3 6

Re: ANNOUNCE: GHC 7.10.1 Release Candidate 1 - questions on Mac OS platform
by George Colpitts 18 Jan '15

18 Jan '15

Eric, thanks for the quick response, that is good news that you are not seeing the problems I see. However after I rebuilt with Apple gcc and still see the errors when calling main from ghci. One is an open ticket, https://ghc.haskell.org/trac/ghc/ticket/9277# which was reported in versions before 7.10.1 so I updated it with the details of my experience. I am running Yosemite 10.10.1. What version are you running? I did notice some difference between our two systems. I have /usr/bin/gcc --version Configured with: *--prefix=/Applications/Xcode.app/Contents/Developer/usr* --with-gxx-include-dir=/usr/include/c++/4.2.1 Apple LLVM version 6.0 (clang-600.0.56) (based on LLVM 3.5svn) Target: x86_64-apple-darwin14.0.0 Thread model: posix while you have *--prefix=/Library/Developer/CommandLineTools/usr* When I try bash-3.2$ xcode-select --install xcode-select: error: command line tools are already installed, use "Software Update" to install updates it doesn't change anything, I still have the above prefix. Also, you are right, my last email had info for the wrong ghc, when I look at the right one and yours I see the following difference. You have ,("LibDir","/Library/Frameworks/GHC.framework/Versions/7.10.0-rc1-x86_64/usr/lib/ghc-7.10.0.20141222") ,("Global Package DB","/Library/Frameworks/GHC.framework/Versions/7.10.0-rc1-x86_64/usr/lib/ghc-7.10.0.20141222/package.conf.d") I have ,("LibDir","/usr/local/lib/ghc-7.10.0.20141222") ,("Global Package DB","/usr/local/lib/ghc-7.10.0.20141222/package.conf.d") I am doing a build by doing the following: $ autoreconf $ ./configure $ make $ make install The correct output from ghc --info for me is: ghc --info [("Project name","The Glorious Glasgow Haskell Compilation System") ,("GCC extra via C opts"," -fwrapv") ,("C compiler command","/usr/bin/gcc") ,("C compiler flags"," -m64 -fno-stack-protector") ,("C compiler link flags"," -m64") ,("Haskell CPP command","/usr/bin/gcc") ,("Haskell CPP flags","-E -undef -traditional -Wno-invalid-pp-token -Wno-unicode -Wno-trigraphs ") ,("ld command","/usr/bin/ld") ,("ld flags"," -arch x86_64") ,("ld supports compact unwind","YES") ,("ld supports build-id","NO") ,("ld supports filelist","YES") ,("ld is GNU ld","NO") ,("ar command","/usr/bin/ar") ,("ar flags","clqs") ,("ar supports at file","NO") ,("touch command","touch") ,("dllwrap command","/bin/false") ,("windres command","/bin/false") ,("libtool command","libtool") ,("perl command","/usr/bin/perl") ,("target os","OSDarwin") ,("target arch","ArchX86_64") ,("target word size","8") ,("target has GNU nonexec stack","False") ,("target has .ident directive","True") ,("target has subsections via symbols","True") ,("Unregisterised","NO") ,("LLVM llc command","/usr/local/bin/llc") ,("LLVM opt command","/usr/local/bin/opt") ,("Project version","7.10.0.20141222") ,("Project Git commit id","a8c556dfca3eca5277615cc2bf9d6c8f1f143c9a") ,("Booter version","7.8.3") ,("Stage","2") ,("Build platform","x86_64-apple-darwin") ,("Host platform","x86_64-apple-darwin") ,("Target platform","x86_64-apple-darwin") ,("Have interpreter","YES") ,("Object splitting supported","YES") ,("Have native code generator","YES") ,("Support SMP","YES") ,("Tables next to code","YES") ,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn thr_debug_dyn l_dyn thr_l_dyn") ,("Support dynamic-too","YES") ,("Support parallel --make","YES") ,("Support reexported-modules","YES") ,("Support thinning and renaming package flags","YES") ,("Uses package keys","YES") ,("Dynamic by default","NO") ,("GHC Dynamic","YES") ,("Leading underscore","YES") ,("Debug on","False") ,("LibDir","/usr/local/lib/ghc-7.10.0.20141222") ,("Global Package DB","/usr/local/lib/ghc-7.10.0.20141222/package.conf.d") ] On Sat, Jan 17, 2015 at 2:38 PM, Erik Hesselink <hesselink(a)gmail.com> wrote: > Hi George, > > I've not tried compiling via llvm, but I have a working Mac GHC 7.10 > build that I've been using, and haven't seen any of the other issues > you mentioned. I'm not sure what's recommended but I believe I'm using > clang (see output below). If you want to try my build, you can > download it at [1]. BTW, the info you posted seems to be from 7.8, not > 7.10. > > Regards, > > Erik > > [1] > https://docs.google.com/a/silk.co/uc?id=0B5E6EvOcuE0nNFR4WUVNZzRtbGs&export… > > $ gcc --version > Configured with: --prefix=/Library/Developer/CommandLineTools/usr > --with-gxx-include-dir=/usr/include/c++/4.2.1 > Apple LLVM version 6.0 (clang-600.0.56) (based on LLVM 3.5svn) > Target: x86_64-apple-darwin13.4.0 > Thread model: posix > > $ ghc --info > [("Project name","The Glorious Glasgow Haskell Compilation System") > ,("GCC extra via C opts"," -fwrapv") > ,("C compiler command","/usr/bin/gcc") > ,("C compiler flags"," -m64 -fno-stack-protector") > ,("C compiler link flags"," -m64") > ,("Haskell CPP command","/usr/bin/gcc") > ,("Haskell CPP flags","-E -undef -traditional -Wno-invalid-pp-token > -Wno-unicode -Wno-trigraphs ") > ,("ld command","/usr/bin/ld") > ,("ld flags"," -arch x86_64") > ,("ld supports compact unwind","YES") > ,("ld supports build-id","NO") > ,("ld supports filelist","YES") > ,("ld is GNU ld","NO") > ,("ar command","/usr/bin/ar") > ,("ar flags","clqs") > ,("ar supports at file","NO") > ,("touch command","touch") > ,("dllwrap command","/bin/false") > ,("windres command","/bin/false") > ,("libtool command","libtool") > ,("perl command","/usr/bin/perl") > ,("target os","OSDarwin") > ,("target arch","ArchX86_64") > ,("target word size","8") > ,("target has GNU nonexec stack","False") > ,("target has .ident directive","True") > ,("target has subsections via symbols","True") > ,("Unregisterised","NO") > ,("LLVM llc command","llc") > ,("LLVM opt command","opt") > ,("Project version","7.10.0.20141222") > ,("Project Git commit id","a8c556dfca3eca5277615cc2bf9d6c8f1f143c9a") > ,("Booter version","7.8.3") > ,("Stage","2") > ,("Build platform","x86_64-apple-darwin") > ,("Host platform","x86_64-apple-darwin") > ,("Target platform","x86_64-apple-darwin") > ,("Have interpreter","YES") > ,("Object splitting supported","NO") > ,("Have native code generator","YES") > ,("Support SMP","YES") > ,("Tables next to code","YES") > ,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn > thr_debug_dyn l_dyn thr_l_dyn") > ,("Support dynamic-too","YES") > ,("Support parallel --make","YES") > ,("Support reexported-modules","YES") > ,("Support thinning and renaming package flags","YES") > ,("Uses package keys","YES") > ,("Dynamic by default","NO") > ,("GHC Dynamic","YES") > ,("Leading underscore","YES") > ,("Debug on","False") > > ,("LibDir","/Library/Frameworks/GHC.framework/Versions/7.10.0-rc1-x86_64/usr/lib/ghc-7.10.0.20141222") > ,("Global Package > > DB","/Library/Frameworks/GHC.framework/Versions/7.10.0-rc1-x86_64/usr/lib/ghc-7.10.0.20141222/package.conf.d") > ] > > On Sat, Jan 17, 2015 at 1:36 PM, George Colpitts > <george.colpitts(a)gmail.com> wrote: > > Has anybody successfully used llvm on the Mac with 7.10.1 RC1? My > problem is > > described below. > > Which is the recommended gcc to use when building source? > > > > GNU gcc 4.9.2 > > Apple LLVM version 6.0 (clang-600.0.56) (based on LLVM 3.5svn) > > > > When using ghci with 7.10.1 RC1 I get the following errors > intermittently. > > Is anybody else seeing these? > > > > Too late for parseStaticFlags: call it before runGhc or runGhcT > > *** Exception: ExitFailure 1 > > ld: library not found for -l:ghc31505_10.dylib > > collect2: error: ld returned 1 exit status > > phase `Linker' failed (exitcode = 1) > > > > Thanks > > > > On Fri, Jan 2, 2015 at 9:12 AM, George Colpitts < > george.colpitts(a)gmail.com> > > wrote: > >> > >> Only problem remaining is compiling with -fllvm and running resulting > >> executable > >> > >> . > >> .. > >> > >> > >> llvm , compiling with llvm (3.4.2) gives the following warnings: > >> > >> $ ghc -fllvm cubeFast.hs > >> [1 of 1] Compiling Main ( cubeFast.hs, cubeFast.o ) > >> 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 .' > >> clang: warning: argument unused during compilation: '-fno-common' > >> clang: warning: argument unused during compilation: '-U __PIC__' > >> clang: warning: argument unused during compilation: '-D __PIC__' > >> Linking cubeFast ... > >> running the resulting executable crashes (compiling without -fllvm gives > >> no warnings and executable works properly) > >> cat bigCube.txt | ./cubeFast > /dev/null > >> Segmentation fault: 11 > >> Exception Type: EXC_BAD_ACCESS (SIGSEGV) > >> Exception Codes: KERN_INVALID_ADDRESS at 0xfffffffd5bfd8460 > >>> > >>> ... > >>> > >>> Configuration details: > >>> > >>> Mac OS 10.10.1 (Yosemite) > >>> uname -a > >>> Darwin iMac27-5.local 14.0.0 Darwin Kernel Version 14.0.0: Fri Sep 19 > >>> 00:26:44 PDT 2014; root:xnu-2782.1.97~2/RELEASE_X86_64 x86_64 > >>> llvm info: > >>> opt --version > >>> LLVM (http://llvm.org/) > >>> LLVM version 3.4.2 > >>> Optimized build with assertions. > >>> Built Oct 31 2014 (23:14:30). > >>> Default target: x86_64-apple-darwin14.0.0 > >>> Host CPU: corei7 > >>> gcc --version > >>> gcc (Homebrew gcc 4.9.1) 4.9.1 > >>> Copyright (C) 2014 Free Software Foundation, Inc. > >>> This is free software; see the source for copying conditions. There is > >>> NO > >>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR > >>> PURPOSE. > >>> /usr/bin/ghc --info > >>> [("Project name","The Glorious Glasgow Haskell Compilation System") > >>> ,("GCC extra via C opts"," -fwrapv") > >>> ,("C compiler command","/usr/bin/gcc") > >>> ,("C compiler flags"," -m64 -fno-stack-protector") > >>> ,("C compiler link flags"," -m64") > >>> ,("Haskell CPP command","/usr/bin/gcc") > >>> ,("Haskell CPP flags","-E -undef -traditional -Wno-invalid-pp-token > >>> -Wno-unicode -Wno-trigraphs") > >>> ,("ld command","/usr/bin/ld") > >>> ,("ld flags"," -arch x86_64") > >>> ,("ld supports compact unwind","YES") > >>> ,("ld supports build-id","NO") > >>> ,("ld supports filelist","YES") > >>> ,("ld is GNU ld","NO") > >>> ,("ar command","/usr/bin/ar") > >>> ,("ar flags","clqs") > >>> ,("ar supports at file","NO") > >>> ,("touch command","touch") > >>> ,("dllwrap command","/bin/false") > >>> ,("windres command","/bin/false") > >>> ,("libtool command","libtool") > >>> ,("perl command","/usr/bin/perl") > >>> ,("target os","OSDarwin") > >>> ,("target arch","ArchX86_64") > >>> ,("target word size","8") > >>> ,("target has GNU nonexec stack","False") > >>> ,("target has .ident directive","True") > >>> ,("target has subsections via symbols","True") > >>> ,("Unregisterised","NO") > >>> ,("LLVM llc command","llc") > >>> ,("LLVM opt command","opt") > >>> ,("Project version","7.8.3") > >>> ,("Booter version","7.6.3") > >>> ,("Stage","2") > >>> ,("Build platform","x86_64-apple-darwin") > >>> ,("Host platform","x86_64-apple-darwin") > >>> ,("Target platform","x86_64-apple-darwin") > >>> ,("Have interpreter","YES") > >>> ,("Object splitting supported","YES") > >>> ,("Have native code generator","YES") > >>> ,("Support SMP","YES") > >>> ,("Tables next to code","YES") > >>> ,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn > >>> thr_debug_dyn l_dyn thr_l_dyn") > >>> ,("Support dynamic-too","YES") > >>> ,("Support parallel --make","YES") > >>> ,("Dynamic by default","NO") > >>> ,("GHC Dynamic","YES") > >>> ,("Leading underscore","YES") > >>> ,("Debug on","False") > >>> > >>> > ,("LibDir","/Library/Frameworks/GHC.framework/Versions/7.8.3-x86_64/usr/lib/ghc-7.8.3") > >>> ,("Global Package > >>> > DB","/Library/Frameworks/GHC.framework/Versions/7.8.3-x86_64/usr/lib/ghc-7.8.3/package.conf.d") > >>> ] > >>> Not sure I found the correct instructions for building from source, I > >>> used the following: > >>> > >>> $ autoreconf > >>> $ ./configure > >>> $ make > >>> $ make install > >>> > >>> > >>> > >>> On Tue, Dec 23, 2014 at 10:36 AM, Austin Seipp <austin(a)well-typed.com> > >>> wrote: > >>>> > >>>> We are pleased to announce the first release candidate for GHC 7.10.1: > >>>> > >>>> https://downloads.haskell.org/~ghc/7.10.1-rc1/ > >>>> > >>>> This includes the source tarball and bindists for 64bit/32bit Linux > >>>> and Windows. Binary builds for other platforms will be available > >>>> shortly. (CentOS 6.5 binaries are not available at this time like they > >>>> were for 7.8.x). These binaries and tarballs have an accompanying > >>>> SHA256SUMS file signed by my GPG key id (0x3B58D86F). > >>>> > >>>> We plan to make the 7.10.1 release sometime in February of 2015. We > >>>> expect another RC to occur during January of 2015. > >>>> > >>>> Please test as much as possible; bugs are much cheaper if we find them > >>>> before the release! > >>>> > >>>> -- > >>>> Regards, > >>>> > >>>> Austin Seipp, Haskell Consultant > >>>> Well-Typed LLP, http://www.well-typed.com/ > >>>> _______________________________________________ > >>>> ghc-devs mailing list > >>>> ghc-devs(a)haskell.org > >>>> http://www.haskell.org/mailman/listinfo/ghc-devs > >>> > >>> > >> > > > > > > _______________________________________________ > > Glasgow-haskell-users mailing list > > Glasgow-haskell-users(a)haskell.org > > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > > >

1 0

ANNOUNCE: GHC 7.10.1 Release Candidate 1
by Austin Seipp 17 Jan '15

17 Jan '15

We are pleased to announce the first release candidate for GHC 7.10.1: https://downloads.haskell.org/~ghc/7.10.1-rc1/ This includes the source tarball and bindists for 64bit/32bit Linux and Windows. Binary builds for other platforms will be available shortly. (CentOS 6.5 binaries are not available at this time like they were for 7.8.x). These binaries and tarballs have an accompanying SHA256SUMS file signed by my GPG key id (0x3B58D86F). We plan to make the 7.10.1 release sometime in February of 2015. We expect another RC to occur during January of 2015. Please test as much as possible; bugs are much cheaper if we find them before the release! -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

11 14

vectorisation code?
by Richard Eisenberg 17 Jan '15

17 Jan '15

Hi devs, There's a sizable number of modules in the `vectorise` subdirectory of GHC. I'm sure these do all sorts of wonderful things. But what, exactly? And, does anyone make use of these wonderful things? A quick poking through the code shows a tiny link between the vectorise code and the rest of GHC -- the function `vectorise` exported from the module `Vectorise`, which is named in exactly one place from SimplCore. From what I can tell, the function will be called only when `-fvectorise` is specified, and then it seems to interact with a {-# VECTORISE #-} pragma. However, `{-# VECTORISE #-}` doesn't appear in the manual at all, and `-fvectorise` is given only a cursory explanation. It seems these work with DPH... which has been disabled, no? Searching online finds several hits, but nothing more recent than 2012. I hope this question doesn't offend -- it seems that vectorisation probably has amazing performance gains. Yet, the feature also seems unloved. In the meantime, compiling (and recompiling, and recompiling...) the modules takes time, as does going through them to propagate changes from elsewhere. If this feature is truly orphaned, unloved, and unused at the moment, is it reasonable to consider putting it on furlough? Thanks, Richard

5 6

Floating through small case analyses
by Ben Gamari 15 Jan '15

15 Jan '15

Hello Simon, Today I've been working on trying to whip bytestring's Builder into shape [1,2]. The last remaining issue is a performance problem that appears to be due to over-zealous floating of some small literals in every GHC version I've tested (7.6, 7.8, and 7.10). The test case can be found here [3] and is characterized by repeated monoidal appends (reproduced roughly here in half-Core/half-Haskell), loop s n | s `seq` n `seq` False = undefined loop _ 0 = mempty loop s n = singleton (s + (fromInteger @Word8 (__integer 0))) <> singleton (s + (fromInteger @Word8 (__integer 1))) <> singleton (s + (fromInteger @Word8 (__integer 2))) <> singleton (s + (fromInteger @Word8 (__integer 3))) <> ... singleton (s + (fromInteger @Word8 (__integer 15))) <> loop (s+16) (s-16) The initial float-out stage floats all of the (fromInteger ...) expressions out to the top level, resulting in definitions of the form, lvl_s1b3j :: Integer lvl_s1b3j = __integer 0 lvl_s1b3k :: Word8 lvl_s1b3k = $fBitsWord8_$cfromInteger lvl_s1b3j Simplifier phase 2 then does some inlining and in so doing introduces a boolean case analysis. Both alternatives of the case require the now-top-level literals. Unfortunately, the float-in pass is quite strict about when it will float expressions inside case analyses. Specifically, it requires the float to be both small [4] (which I believe these are) and used in more than one but not all alternatives [5]. Given that there are only two alternatives here this seems a bit too restrictive. The end result is that we end up producing a bunch of bindings outside of a boolean case analysis, case narrow8Word# sc_s1c39 of a_s1c3g { __DEFAULT -> case plusWord# sc_s1c39 (__word 1) of sat_s1c3i { __DEFAULT -> case narrow8Word# sat_s1c3i of a1_s1c3h { __DEFAULT -> case plusWord# sc_s1c39 (__word 2) of sat_s1c3k { __DEFAULT -> ... case plusWord# sc_s1c39 (__word 16) of sat_s1c3M { __DEFAULT -> case narrow8Word# sat_s1c3M of a16_s1c3L { __DEFAULT -> case tagToEnum# @ Bool sat_s1c3P of _ { False -> {-# write each of the values above to memory #-} True -> {-# write each of the values above to memory #-} } This ends up producing extremely poor assembly, with the compiler first computing all 16 store addresses, placing them on the stack, and then performing all 16 stores. I'm a bit unsure of what to blame this on. Perhaps it would make sense to always float small dupable expressions in to sufficiently small case expressions (say, three or fewer alternatives)? Perhaps these near-literals should never have been floated out at all? Perhaps there another option I've not thought of? Thoughts? Cheers, - Ben [1]: https://github.com/kolmodin/binary/pull/65 [2]: https://github.com/haskell/bytestring/pull/40 [3]: https://gist.github.com/bgamari/22d127779a48113c1153#file-test-hs [4]: https://github.com/ghc/ghc/blob/master/compiler/coreSyn/CoreUtils.hs#L710 [5]: https://github.com/ghc/ghc/blob/master/compiler/simplCore/FloatIn.hs#L527

1 0