Re: gcc version to use on sparc/solaris

2009-01-11 Thread Duncan Coutts 
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

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: gcc version to use on sparc/solaris

2009-01-11 Thread Brandon S. Allbery KF8NH 

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] allb...@kf8nh.com
system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu
electrical and computer engineering, carnegie mellon universityKF8NH


___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

Re: gcc version to use on sparc/solaris

2009-01-11 Thread Duncan Coutts 
On Sun, 2009-01-11 at 14:48 +, 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

___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

gcc version to use on sparc/solaris

2009-01-11 Thread Duncan Coutts 
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)