January 2015 - ghc-devs

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 16 Jan '15

16 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

API Annotations question
by Jan Stolarek 15 Jan '15

15 Jan '15

Alan, devs, since API annotations were added some data types in the source code have extra comments related to these annotations, eg. -- | A type or class declaration. data TyClDecl name = -- | @type/data family T :: *->*@ -- -- - 'ApiAnnotation.AnnKeywordId' : 'ApiAnnotation.AnnType', -- 'ApiAnnotation.AnnData', -- 'ApiAnnotation.AnnFamily','ApiAnnotation.AnnWhere', -- 'ApiAnnotation.AnnOpen','ApiAnnotation.AnnDcolon', -- 'ApiAnnotation.AnnClose' FamDecl { tcdFam :: FamilyDecl name } I'm totally clueless about what these comments mean. Where can I find an explanation? Couldn't find anything on the wiki. Janek

2 4

RE: [Diffusion] [Build Failed] rGHCe4cb8370eb91: Tiny refactoring (shorter, simpler code)
by Simon Peyton Jones 14 Jan '15

14 Jan '15

This failure message leads me to https://phabricator.haskell.org/harbormaster/build/2964/ which says that ghcirun003 is failing. But how can I see the failure log???? (It doesn't fail for me.) Simon | -----Original Message----- | From: noreply(a)phabricator.haskell.org | [mailto:noreply@phabricator.haskell.org] | Sent: 14 January 2015 17:37 | To: Simon Peyton Jones | Subject: [Diffusion] [Build Failed] rGHCe4cb8370eb91: Tiny refactoring | (shorter, simpler code) | | Harbormaster failed to build B2940: rGHCe4cb8370eb91: Tiny refactoring | (shorter, simpler code)! | | USERS | simonpj (Author) | GHC - Type checker/inferencer (Auditor) | | COMMIT | https://phabricator.haskell.org/rGHCe4cb8370eb91 | | EMAIL PREFERENCES | https://phabricator.haskell.org/settings/panel/emailpreferences/ | | To: simonpj, GHC - Type checker/inferencer

1 0