gcc version to use on sparc/solaris
On Fri, 2009-01-02 at 21:06 +1100, Ben Lippmeier wrote:
I'm running into some huge compile times that I'm hoping someone will have some suggestions about. When compiling Parser.hs the intermediate .hc file is 4MB big, and is taking GCC 4.2.1 more than 2 hours to get through.
Another attempted compile of GHC 6.8.3 is stuck on libraries/template-haskell/Language/Haskell/TH/Syntax.hs with a 4MB intermediate .hc file.
Here is what I've discovered... I built four versions of gcc and used them to build ghc-6.8.3. I selected the last point release of the last four major gcc releases: gcc-4.0.4 gcc-4.1.2 gcc-4.2.4 gcc-4.3.2 Summary: gcc-4.0.4 or gcc-4.1.2 seems to be the best choice at the moment for ghc on sparc/solaris. gcc-4.0.4 ========= This version passes all expected tests on the gcc testsuite. Using it to build ghc-6.8.3 works fine and it does not take too long. The ghc testsuite result looks like: 2128 total tests, which gave rise to 8040 test cases, of which 1 caused framework failures 1561 were skipped 6130 expected passes 281 expected failures 0 unexpected passes 48 unexpected failures Unexpected failures: 1861(normal,optc,hpc,profc,threaded1,threaded2) barton-mangler-bug(normal,hpc,threaded1) cabal01(normal) conc042(threaded2) conc043(threaded2) conc044(threaded2) conc045(threaded2) conflicting_flags(normal) enum01(hpc) ffi017(ghci) ffi019(normal,optc,hpc,profc,ghci,threaded1,threaded2) ghciprog004(normal) hClose002(normal,optc,hpc,profc,ghci,threaded1,threaded2) joao-circular(normal,optc,hpc,profc,threaded1,threaded2) num012(normal,optc,hpc,profc,ghci,threaded1,threaded2) seward-space-leak(ghci) testblockalloc(normal,threaded1) Some fail in fairly simple ways: cabal01 fails because Solaris tar does not support -C conflicting_flags fails due to a difference in output: -ghc: cannot use `-V' with `--print-libdir' +ghc-6.8.3: cannot use `-V' with `--print-libdir' hClose002 fails with a different error: -Left hClose: invalid argument (Bad file descriptor) +Left hClose: invalid argument (Bad file number) 1861 fails because ghc uses C99 INFINITY macro without using C99 and Solaris header files are more strict about standards than other systems. http://hackage.haskell.org/trac/ghc/ticket/2929 Some look a bit more scary: testblockalloc fails with "out of memory (requested 8388608 bytes)" num012 produces different output: --2147483648 +2147483647 looks like overflow, so definitely something wrong. A number of tests timeout: seward-space-leak(ghci) joao-circular(all) barton-mangler-bug(all) A few tests get bus errors: conc042, conc043, conc044, conc045 ghciprog004 ffi019(all) gcc-4.1.2 ========= This version passes all expected tests on the gcc testsuite. Using it to build ghc-6.8.3 works fine and it does not take too long. The ghc testsuite result looks like: 2128 total tests, which gave rise to 8040 test cases, of which 1 caused framework failures 1561 were skipped 6125 expected passes 281 expected failures 0 unexpected passes 49 unexpected failures Unexpected failures: 1861(normal,optc,hpc,profc,threaded1,threaded2) barton-mangler-bug(normal,optc,hpc,threaded1,threaded2) cabal01(normal) conc042(threaded2) conc043(threaded2) conc044(threaded2) conc045(threaded2) conflicting_flags(normal) ffi017(ghci) ffi019(normal,optc,hpc,profc,ghci,threaded1,threaded2) ghciprog004(normal) hClose002(normal,optc,hpc,profc,ghci,threaded1,threaded2) joao-circular(normal,optc,hpc,profc,threaded1,threaded2) num012(normal,optc,hpc,profc,ghci,threaded1,threaded2) seward-space-leak(ghci) testblockalloc(normal,threaded1) The only difference is that enum01(hpc) does not fail and barton-mangler-bug fails in two more ways (optc, threaded2) gcc-4.2.4 ========= This fails 4 tests on the gcc testsuite. This is the version that gives us massive compile times for larger .hc files (8 hours+ for Syntax.hc). I thought that using -fno-unit-at-a-time would help but ghc is already using that so no luck. It does eventually build but takes nearly 2 days. No testsuite results yet. I'm not sure I can be bothered. gcc-4.3.2 ========= This fails 50 tests on the gcc testsuite. Does not work with ghc-6.8.3 at all, presumably due to the evil mangler. This manifests itself as ./configure failing when it tries to compile and run utils/pwd/pwd: checking for path to top of build tree... /tmp/ghc15055_0/ghc15055_0.hc: In function 'sqD_ret': /tmp/ghc15055_0/ghc15055_0.hc:95:0: note: if this code is reached, the program will abort [...] /tmp/ghc15055_0/ghc15055_0.hc: In function '__stginit_Main': /tmp/ghc15055_0/ghc15055_0.hc:750:0: note: if this code is reached, the program will abort configure: error: cannot determine current directory Indeed it does abort: $ utils/pwd/pwd Illegal Instruction (core dumped) Duncan
On Sun, 2009-01-11 at 14:48 +0000, Duncan Coutts wrote:
I built four versions of gcc and used them to build ghc-6.8.3.
While on the subject, the annoyances I bumped into while doing this are: discovering a ghc/gcc combination does not work is not obvious. The first symptom is ./configure failing to find the path to top of build tree. Of course I realised this happened to be because we build a Haskell pwd program during configure. It'll confuse other users. It would be nice if after detecting the location and version of ghc, ./configure would explicitly test that ghc to make sure it can compile, link and run a hello world program. Each of these stages can fail. On different occasions I've managed to get all three stages to fail independently so it would be nice if each were checked explicitly. The compile phase can fail if the ghc/gcc combo is bad. The link phase can fail if the ghc cannot find libgmp/libreadline/libwhatever. The run phase can fail if the ghc/gcc combo generated bad code or if the libgmp is not on the runtime linker path but was on the static linker path. It's rather tricky to configure ghc to use libraries from a non-standard location, one that is not on the standard linker link-time or runtime paths. See http://hackage.haskell.org/trac/ghc/ticket/2933 It's tricky to get configure ghc to use gcc from a non-standard location. The ./configure --with-gcc flag works for gcc used at build time but the installed ghc still uses ghc from the $PATH. Duncan
On 2009 Jan 11, at 9:48, Duncan Coutts wrote:
On Fri, 2009-01-02 at 21:06 +1100, Ben Lippmeier wrote:
I'm running into some huge compile times that I'm hoping someone will have some suggestions about. When compiling Parser.hs the intermediate .hc file is 4MB big, and is taking GCC 4.2.1 more than 2 hours to get through.
Here is what I've discovered...
I built four versions of gcc and used them to build ghc-6.8.3. I selected the last point release of the last four major gcc releases: gcc-4.0.4 gcc-4.1.2 gcc-4.2.4 gcc-4.3.2
Summary: gcc-4.0.4 or gcc-4.1.2 seems to be the best choice at the moment for ghc on sparc/solaris.
FWIW I've built 6.8.2 with gcc-4.2.2, ti was slow but it built and the testsuite didn't look too horrible. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH
On Sun, 2009-01-11 at 10:29 -0500, Brandon S. Allbery KF8NH wrote:
On 2009 Jan 11, at 9:48, Duncan Coutts wrote:
On Fri, 2009-01-02 at 21:06 +1100, Ben Lippmeier wrote:
I'm running into some huge compile times that I'm hoping someone will have some suggestions about. When compiling Parser.hs the intermediate .hc file is 4MB big, and is taking GCC 4.2.1 more than 2 hours to get through.
Here is what I've discovered...
I built four versions of gcc and used them to build ghc-6.8.3. I selected the last point release of the last four major gcc releases: gcc-4.0.4 gcc-4.1.2 gcc-4.2.4 gcc-4.3.2
Summary: gcc-4.0.4 or gcc-4.1.2 seems to be the best choice at the moment for ghc on sparc/solaris.
FWIW I've built 6.8.2 with gcc-4.2.2, ti was slow but it built and the testsuite didn't look too horrible.
Yes, I built ghc-6.8.3 with gcc-4.2.4 and it builds ok, it just takes two days to do so. So it's not really usable for ghc development. It may be fine for using ghc, but not for hacking ghc. In future it should not matter once we get the -fasm route working. Then we'll only need gcc to build the rts and to assemble things, not to compile massive .hc files. Duncan
participants (2)
-
Brandon S. Allbery KF8NH -
Duncan Coutts