- Glasgow-haskell-users

GHC 6.4.1 for Solaris
by herington, dean 20 Jul '05

20 Jul '05

I'm trying to deploy GHC 6.4.1 on a Solaris 5.9 machine. I installed the binary release (in-place) from <http://www.haskell.org/ghc/dist/stable/dist/ghc-6.4.1-sparc-sun-solaris2> <http://www.haskell.org/ghc/dist/stable/dist/ghc-6.4.1-sparc-sun-solaris2.ta r.bz2> http://www.haskell.org/ghc/dist/stable/dist/ghc-6.4.1-sparc-sun-solaris2.tar .bz2, but it needs libreadline.so.5, libncurses.so.5, and libgmp.so.3, which my machine lacks. How should I obtain these shared libraries?

1 0

RE: GHC API: Access to nativeCodeGen?
by Simon Marlow 20 Jul '05

20 Jul '05

On 19 July 2005 17:17, Peter A Jonsson wrote: > Perl 5.6.0 seems to be released 2000-Mar-22, demanding that people who > build ghc have a perl that is no older than 5 years might be a > reasonable first step? Ok, done. >>> Needed a patch to build NCG. I tried to preserve as much of the >>> previous structure in order to avoid introducing bugs, but I wasn't >>> entirely successfull. I've attached the patch and would appreciate >>> if someone could glance over it looking for obvious errors. >> >> There are never any "obvious" errors in the NCG :-) I did glance >> over it, and it mostly looks like a straightforward change over to >> Cmm. Since your patch only touches code inside #ifdef >> sparc_TARGET_ARCH, which is currently broken anyway, I'm inclined to >> just merge it as-is. > > That sounds good to me, a smaller diff would hopefully make my life > easier. > > About the lack of sparc-support - is the problem that no active > developers have access to sparc-machines any longer or is there simply > no interest in sparc? If it is the former, contact me off list and > I'll try to help out. I can get access to a machine, but I don't have a lot of time to maintain the Sparc port (and it's always harder to fix things remotely). We've been advertising for a Sparc guru for a while, but no takers so far. > The stack-check sequence you are referring to, is that in Cmm > represented by "if ((Sp + -12) < SpLim) goto <label>"? If that is the > case, I can't find any errors in the asm produced. > > Any hints that would ease the burden of reading big chunks of > assembler would be much appreciated! Compiling programs with -debug is a good first step - that links in the debugging version of the RTS, with lots of ASSERTs and support for the debugging output flags (-Dxxx, -Ds and -DS are my favourites). Cheers, Simon

1 0

RE: GHC API: Access to nativeCodeGen?
by Simon Marlow 19 Jul '05

19 Jul '05

On 18 July 2005 12:01, Peter A Jonsson wrote: > Ok, I gave it a spin, that was "interesting". Things I wrote down > while looking at it that might be of interest to others: > > I tried to build with gcc 3.4.1 and it didn't work very well. Found a > mail from November 2004 (<Message-Id: 419B599C.2020204(a)tzi.de>) which > had the same problem. In a reply you said that it was the JMP_-macro > in TailCall.h and changing the cast would make the warning go away. It > did, however I think I messed up with something else since it made > other problems appear. I reverted my changes and switched gcc > instead. > > I had perl 5.005_03 first in my path, that made the splitter not > work. Changing to a newer version made it work. Maybe a test could be > added to configure to avoid too old versions of perl? I'll be happy to - but I don't know exactly what version of Perl we require. Any clues? What went wrong with the splitter? > All those "Bad eta expand" looks slightly scary when building for the > first time. Found a mail from Simon Peyton Jones which made me less > worried. Maybe it could be documented that those are expected in the > building guide? Ok, we'll look into sqashing those. > The GHC commentary was written for pre-CMM NCG. I tried patching that > while going through the code but I just ended up butchering the > document to basically contain no information whatsoever. I'm not sure > it's helpful at all in its current shape though, unfortunately. True - I'd love to update this, but quite gigantic. A shame that Julian put so much effort into writing this doc, and it's now mostly out of date (and I don't think I even referred to it once when converting the NCG to Cmm :-(). > Needed a patch to build NCG. I tried to preserve as much of the > previous structure in order to avoid introducing bugs, but I wasn't > entirely successfull. I've attached the patch and would appreciate if > someone could glance over it looking for obvious errors. There are never any "obvious" errors in the NCG :-) I did glance over it, and it mostly looks like a straightforward change over to Cmm. Since your patch only touches code inside #ifdef sparc_TARGET_ARCH, which is currently broken anyway, I'm inclined to just merge it as-is. > With this patch a bunch of array tests with WAY=normal fails, all in > the same way: > > Stack space overflow: current size 8388608 bytes. > Use `+RTS -Ksize' to increase it. Best guess is the code generated for a stack-check sequence is incorrect. Match up the assembly file (use -keep-s-file) with the Cmm (-ddump-opt-cmm) and see if you can spot the incorrect code. I can provide some gdb tips - let me know if you need more help. Also, the codeGen tests are probably a better place to start (tests/ghc-regress/codeGen/should_run). Cheers, Simon

2 1

RE: Problem building GHC
by Simon Marlow 19 Jul '05

19 Jul '05

On 18 July 2005 17:29, Dinko Tenev wrote: > On 7/18/05, Simon Marlow <simonmar(a)microsoft.com> wrote: >> That's the general rule, anyway. It would be an interesting >> exercise to specify the GHC command-line semantics, or better still, >> redesign it :) > > I for one would find it quite helpful to see a warning line for each > overriden option, if without so much of an explanation -- a "red > light" to let me know something might be wrong. I think there's a difference of philosophy here: overriding options is considered normal usage on the GHC command line. We expect to be able to do things like "make EXTRA_HC_OPTS=-Onot" to turn off optimisation, for example - we don't want this usage to generate a warning for every compilation. Every flag you specify on the command line is in effect overriding the default. We often override global defaults by putting pragmas in source files. e.g. you wouldn't want a warning for putting {-# OPTIONS -fno-warn-overlapping-patterns #-} in a source file, despite the fact that this overrides -Wall on the command line. I think there's a case for warnings in some cases (e.g. -keep-hc-files vs. -fasm might warrant a warning), but not in general. Cheers, Simon

2 1

RE: Problem building GHC
by Simon Marlow 18 Jul '05

18 Jul '05

On 18 July 2005 16:03, Dinko Tenev wrote: > On 7/18/05, Simon Marlow <simonmar(a)microsoft.com> wrote: >> Two reasons: one, -O implies -fvia-C and two, -keep-hc-files also >> implies -fvia-C (because otherwise you don't get any .hc files). >> You'll need to modify the definition of GhcLibHcOpts in build.mk to >> put -fasm after -O, and also to remove -keep-hc-files. > > I'll try this tonight, thanks. > > BTW, am I the only one to find it alarming that GHC would allow > conflicting options to override one another without any warning? :) The GHC command-line isn't declarative, it's imperative. Options are processed left-to-right. That's the general rule, anyway. It would be an interesting exercise to specify the GHC command-line semantics, or better still, redesign it :) Cheers, Simon

2 1

RE: Problem building GHC
by Simon Marlow 18 Jul '05

18 Jul '05

On 18 July 2005 15:54, Dinko Tenev wrote: > On 7/18/05, Simon Marlow <simonmar(a)microsoft.com> wrote: >> You might be picking up the wrong version of ghc here. My guess is >> that the -ignore-package option is being interpreted as a -i flag by >> an older version of GHC. > > Hm...I have 6.2.2 installed, which may qualify for being an "older > version," but how is it being the "wrong" one? Or are those options > intended specifically for the ghc currently being built? For that > matter, does, by chance, the current snapshot require 6.4 to build? You tried to compile a library file using the installed compiler, by cut-and-pasting the command line issued by the build system that was designed for the 6.4 compiler being built. There's nothing particularly strange here - the libraries are always built by the compiler in the tree, so the build system can assume that it only has to create command lines for that particular version of GHC. Cheers, Simon

1 0

RE: Problem building GHC
by Simon Marlow 18 Jul '05

18 Jul '05

On 16 July 2005 08:42, Dinko Tenev wrote: > BTW, I tried to compile the file with the installed ghc, and I am kind > of puzzled by the error message I get: > > > ghc -O -fasm -W -fno-warn-unused-matches -fwarn-unused-imports > -ignore-package haskell-src -package base -fgenerics -hisuf p_hi > -hcsuf p_hc -osuf p_o -prof -c Language/Haskell/Syntax.hs -o > Language/Haskell/Syntax.p_o -ohi Language/Haskell/Syntax.p_hi > ghc-6.2.2: -ohi can only be used when compiling a single source file > Usage: For basic information, try the `--help' option. > > > How am I trying to compile anything other than a single source file > here??? You might be picking up the wrong version of ghc here. My guess is that the -ignore-package option is being interpreted as a -i flag by an older version of GHC. Cheers, Simon

2 1

RE: GHC API: Access to nativeCodeGen?
by Simon Marlow 18 Jul '05

18 Jul '05

On 04 July 2005 12:44, Peter A Jonsson wrote: > dons(a)cse.unsw.edu.au (Donald Bruce Stewart) writes: >> pj: >>> I would like to use nativeCodeGen outside of GHC to generate code >>> from an IR. The IR would be produced by a third party program, not >>> the GHC frontend. >>> >>> Looking at CVS HEAD I can see that GHC.hs exports plenty of things >>> (for the GHC API I presume), but I can't find anything that lets me >>> input some sort of IR and have ASM in return. Am I missing it >>> somewhere or is there no way to input IR and get ASM in return? If >>> there isn't, is such a feature planned/wanted? >>> >>> If such a feature isn't planned, I would appreciate any ideas on how >>> to to accomplish the same thing. I have no problems with having a >>> build tree of GHC laying around if that makes things easier. It >>> would be a nice bonus if it made my maintenance burden low. >> >> You could use External Core with GHC, couldn't you? > > Thanks for the quick answer! > > Maybe it's my lack of understanding of the inner workings of GHC but > reading "An External Representation for the GHC Core Language" I get > the impression that the dumping of Core Language is basically targeted > at researchers writing their own optimization passes or backends for > Haskell/GHC so they can use the existing infrastructure of GHC. My > request is the other way around - I want to throw out the frontend but > use* ("low-level") parts of the backend of GHC. > > The Core Language seems to be translated into STG-machine code, which > according to my understanding is an abstract machine desinged to > support non-strict higher-order functional languages. I was hoping > that the laziness was in the STG-syntax, not in Cmm. Looking at output > of -ddump-cmm it resembles C-- quite closely (also implied by comments > in PprCmm.hs), which makes me believe that is the "correct" level of > abstraction for me. > > *) The reasons are two-fold, one is that it is written in Haskell, the > other is that it generates code for more than one architecture > today. If the language you want to generate code for is at the level of C--, then you could indeed use GHC's native code generator. There isn't an interface to it exposed by the GHC API, but you can use the interfaces directly: the AsmCodeGen module is the top-level of the native code generator, and basically takes Cmm (defined in module Cmm) and produces assembly code. However, if you want to do this, I wonder whether you would be better off just using the real C-- compiler. Cheers, Simon

2 1

RE: Problem building GHC
by Simon Marlow 18 Jul '05

18 Jul '05

On 16 July 2005 11:50, Dinko Tenev wrote: > I did a "devel" build this time, which produced some verbose output > for the last line. > > One thing that troubles me is that gcc still manages to kick-in - what > exactly is going on??? > > > ------------------------------------------------------------------------ > ==fptools== make all -wr; > in /home/shinobi/build/fptools/libraries/haskell-src > ------------------------------------------------------------------------ > ../../ghc/compiler/ghc-inplace -H32m -O0 -fasm -W > -fno-warn-unused-matches -fwarn-unused-imports -ignore-package > haskell-src -O -dcore-lint -W -fno-warn-unused-matches > -fwarn-unused-imports -keep-hc-files -package base -fgenerics -c > Language/Haskell/Syntax.hs -o Language/Haskell/Syntax.o -ohi > Language/Haskell/Syntax.hi Two reasons: one, -O implies -fvia-C and two, -keep-hc-files also implies -fvia-C (because otherwise you don't get any .hc files). You'll need to modify the definition of GhcLibHcOpts in build.mk to put -fasm after -O, and also to remove -keep-hc-files. Cheers, Simon

1 0

RE: Unicode in GHC 6.2.2 and 6.4.x (was: Re: [Haskell-cafe] Unicode.hs)
by Simon Marlow 18 Jul '05

18 Jul '05

On 17 July 2005 04:42, Dimitry Golubovsky wrote: > Dear List Subscribers, > > Simon Marlow wrote: >> On 30 June 2005 14:36, Dimitry Golubovsky wrote: >> >> >>> It is in CVS now, and I believe will be in 6.4.1 >> >> >> Not planned for 6.4.1, but definitely in 6.6. >> > > I have put those files that work for me in GHC 6.2.2 (Unicode support) > for download. Please read the Wiki page: > > http://haskell.org/hawiki/GhcUnicode > > for instructions. > > Any feedback will be appreciated. I believe, the code will work with > GHC > 6.4.x as well. Please let me know if there are any problems. I should mention that 6.4.1 will contain Dimitry's updated Unicode character-class support, albeit without the changes to library APIs that went along with it. The upshot is that all platforms should have consistent behaviour for the isXXX functions from Data.Char in 6.4.1. Cheers, Simon

1 0