- ghc-devs - Haskell.org

Re: vectorisation code?
by David Feuer 20 Jan '15

20 Jan '15

Richard Eisenberg wrote: > Here's an alternate suggestion: in SimplCore, keep the call to vectorise around, but commented out (not just with CPP, for better syntax highlighting). Include a Note explaining what `vectorise` does and why it's not there at the moment. However, move the actual vectorisation code somewhere else in the repo, outside of the source directories (`utils`? a new `attic` directory?). I don't know too much about git, but I would think we'd want to remove it from master and add a commit putting it back in to a dph branch.

1 0

RE: cminusminus.org does not have a link to the spec
by Simon Peyton Jones 20 Jan '15

20 Jan '15

Sergei C-- was originally envisaged as a target language for a variety of compilers. But in fact LLVM, which was developed at a similar time, "won" that race and has built a far larger ecosystem. That's fine with us -- it's great how successful LLVM has been -- but it means that C-- is now used essentially only in GHC. I'm not sure where the original C-- documents now are; Norman can you say? (I do know that the cminusminus.org has lapsed.) The GHC variant of C-- is defined mainly by the Cmm data type in GHC's source code. It does have a concrete syntax, because some bits of GHC's runtime system are written in Cmm. But I fear that this concrete language is not well documented. (Simon Marlow may know more here.) Because GHC's Cmm is part of GHC, we are free to change it. Would you like to say more about the change you want to make, and why you want to make it? Is this relating directly to GHC or to some other project? Simon | -----Original Message----- | From: Sergei Trofimovich [mailto:slyich@gmail.com] | Sent: 14 September 2014 17:16 | To: Simon Peyton Jones | Subject: cminusminus.org does not have a link to the spec | | Hello Simon! | | I had a plan to tweak a bit "import" statement | syntax of Cmm in GHC. | | Namely, to distinct between | import some_c_function; | import some_c_global_variable; | | To try it I first attempted to find latest c-- spec | (to find some design sketches if available) at | | http://www.cminusminus.org/c-downloads/ | | But seems the links (and images?) have gone away | as well as rsync server described at: | | http://www.cminusminus.org/the-c-rsync-server/ | | Maybe you could forward it to site admins so they would | tweak links or point me to working copy. | | Apologies for bothering you on such minor | | Thank you! | | -- | | Sergei

4 6

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