August 2005 - Glasgow-haskell-users

RE: C--
by Simon Peyton-Jones 17 Aug '05

17 Aug '05

| I am trying to understand the role of cmm files in the current GHC | compiler build process (I am guessing, they have replaced .hc files | like PrimOps and AutoApply). Yes, that's exactly right. | They are compiled by the stage1 compiler. Is ability to compile cmm | preserved in the compiler finally built at stage3 and installed? Yes it is. | What compiler flags are available for cmm files compilation? The | User's guide says nothing specific. Are -E, -C, -S available (along | with -c and -fvia-c seen in the nightly build log)? I think -C and -S are. I'm not sure about -E. Try it! You're right that it ought to say. I suspect that the whole "compile Foo.cmm" route is ill-described in the manual; even .cmm language (which is only a subset of C--) isn't described. Reason: we think of it as an internal thing. But it's fine for you to use it, and if it becomes useful to others we should document it better. If you can suggest specifically what would be helpful to you, and specifically where in the manual, and better still provide some specific words, I'll gladly paste them in. Simon

1 0

Re: [loeh@iai.uni-bonn.de: Re: -odir behaviour change in 6.4.1?]
by Isaac Jones 16 Aug '05

16 Aug '05

"Andres Loeh" <loeh(a)iai.uni-bonn.de> writes: > Hello again, (snip) Simon Says: >> Yes, this change was made for consistency (someone else reported the >> breakage). I've also patched Cabal, so perhaps you're using a version >> from before the fix? > > I must be doing something wrong, then. (snip) > /usr/bin/ghc -odir dist/build/foo/foo-tmp/foo -hidir dist/build -c foo/foo.c That's the wrong part. > /usr/bin/ghc -odir dist/build/foo/foo-tmp -hidir dist/build/foo/foo-tmp -o dist/build/foo/foo -hide-all-packages --make -i -i. -package base-1.0 dist/build/foo/foo-tmp/foo/foo.o Main.hs > Chasing modules from: Main.hs > Compiling Main ( Main.hs, dist/build/foo/foo-tmp/Main.o ) > Linking ... > gcc: dist/build/foo/foo-tmp/foo/foo.o: No such file or directory > > The file foo.o is at dist/build/foo/foo-tmp/foo/foo/foo.o ... Build.hs has this logic: odir | versionBranch ghc_vers >= [6,4,1] = pref | otherwise = pref `joinFileName` dirOf c -- ghc 6.4.1 fixed a bug in -odir handling -- for C compilations. which is good, but it only does that for libraries, not executables. Damn. This needs to get refactored to share code. I think I fixed this. Should be in the latest darcs and CVS. Andres, can you try this and let me know? peace, isaac

1 0

C--
by Dimitry Golubovsky 12 Aug '05

12 Aug '05

I am trying to understand the role of cmm files in the current GHC compiler build process (I am guessing, they have replaced .hc files like PrimOps and AutoApply). They are compiled by the stage1 compiler. Is ability to compile cmm preserved in the compiler finally built at stage3 and installed? What compiler flags are available for cmm files compilation? The User's guide says nothing specific. Are -E, -C, -S available (along with -c and -fvia-c seen in the nightly build log)? -- Dimitry Golubovsky Anywhere on the Web

1 0

RE: -odir behaviour change in 6.4.1?
by Simon Marlow 11 Aug '05

11 Aug '05

On 10 August 2005 00:05, Andres Loeh wrote: > Is this change in behaviour between ghc-6.4 and ghc-6.4.1 desired: > > ~/trans $ ls foo > foo.c > ~/trans $ ghc-6.4 -odir foo -c foo/foo.c > ~/trans $ ls foo > foo.c foo.o > ~/trans $ rm foo/foo.o > ~/trans $ ls foo > foo.c > ~/trans $ ghc-6.4.1.20050804 -odir foo -c foo/foo.c > ~/trans $ ls foo > foo foo.c > ~/trans $ ls foo/foo > foo.o > > It seems to break cabal-1.1.1, in the case that I have something > like > > c-sources: foo/foo.c > > in my .cabal file ... Yes, this change was made for consistency (someone else reported the breakage). I've also patched Cabal, so perhaps you're using a version from before the fix? Cheers, Simon

2 1

6.4.1 release candidate testing on Solaris
by Geisler, Tim (EXT) 11 Aug '05

11 Aug '05

ghc-6.4.1.20050806 (and before ghc-6.4.1.20050731) built successfully on Solaris (Sparc). bash-2.05$ uname -a SunOS kleopatra 5.9 Generic_118558-04 sun4u sparc SUNW,Sun-Fire-V240 bash-2.05$ gcc -v Reading specs from /export/home/haskells/geisler/sw/lib/gcc/sparc-sun-solaris2.9/3.4.4/spec s Configured with: ./configure --prefix=/export/home/haskells/geisler/sw --with-ld=/export/home/haskells/geisler/sw/bin/ld --with-as=/export/home/haskells/geisler/sw/bin/as Thread model: posix gcc version 3.4.4 bash-2.05$ ld -v GNU ld version 2.16 bash-2.05$ as -v GNU assembler version 2.16 (sparc-sun-solaris2.9) using BFD version 2.16 ghc was configured with: ./configure --prefix=/export/home/haskells/geisler/sw --disable-opengl --disable-glut --disable-openal To build ghc-6.4.1.20050806, I used ghc-6.4.1.20050731 which was built with Christian Maeder's binary distribution for Solaris (http://www.haskell.org/ghc/dist/stable/dist/ghc-6.4.1-sparc-sun-solaris 2.tar.bz2) from June 2005. I was able to build all our Haskell code. Some first tests were successful. Tim

2 1

[ ghc-Feature Requests-1256514 ] Declare large amounts of constant data
by SourceForge.net 11 Aug '05

11 Aug '05

Feature Requests item #1256514, was opened at 2005-08-11 11:42 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1256514&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Priority: 5 Submitted By: Antti-Juhani Kaijanaho (ajk) Assigned to: Nobody/Anonymous (nobody) Summary: Declare large amounts of constant data Initial Comment: Simon Marlow wrote in Bug#635718: "It is true that GHC doesn't have a good way to declare large amounts of constant data. This is a shortcoming, but not a bug (please by all means submit a feature request)." Submitting as requested:) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=358032&aid=1256514&group_…

1 0

ANN: C->Haskell version 0.14.3 "Travelling Lightly"
by Manuel M T Chakravarty 10 Aug '05

10 Aug '05

I like to announce version 0.14.3 of C->Haskell, which brings the following advances over 0.14.1: * gcc's asm construct is supported, which is apparently important for some libraries on Mac OS X (thanks to Duncan Coutts for the patch); * C->Haskell supports cross compilation (see details below); [NB: C->Haskell now generates completely portable Haskell code (needs only H98 + FFI) and can target C compilers on platforms that cannot build C->Haskell itself; eg, PalmOS. In particular, C->Haskell generated bindings are suitable for nhc98 and Hugs, too.] * hierarchical modules syntax can be used in import hooks (again thanks to Duncan for the patch); and * two new built-in translation functions "upcaseFirstLetter" and "downcaseFirstLetter" are supported to generated suitable Haskell names from C names (eg, for variants of enums). Source code is available as a tar ball from http://www.cse.unsw.edu.au/~chak/haskell/c2hs/ or via Darcs (binary packages may appear later). Happy Hacking, Manuel -=- Cross compilation -=- C->Haskell needs to take system-specific parameters of the C compiler used to compile the libraries for which an interface is generated into account (most notably when bitfields are used in this library). By default C->Haskell uses the conventions of the C compiler that was used to build C->Haskell itself. From this version, C->Haskell accepts the --platform=PLATFORM flag that enables the explicit specification of the target platform. This works only for platforms that are in C->Haskell's platform specification database. At the moment, that's only i686-pc-linux-gnu and m68k-palmos. However, it is very easy to determine the platform specification for any platform on which you can build C->Haskell: Just invoke it as `c2hs --version' and it will tell you. If you send me the output of `c2hs --version', I'll happily add it to the database. (If you'd like to target a platform on which you cannot build C->Haskell, such as an embedded system, let me know.)

1 0

-odir behaviour change in 6.4.1?
by Andres Loeh 09 Aug '05

09 Aug '05

Is this change in behaviour between ghc-6.4 and ghc-6.4.1 desired: ~/trans $ ls foo foo.c ~/trans $ ghc-6.4 -odir foo -c foo/foo.c ~/trans $ ls foo foo.c foo.o ~/trans $ rm foo/foo.o ~/trans $ ls foo foo.c ~/trans $ ghc-6.4.1.20050804 -odir foo -c foo/foo.c ~/trans $ ls foo foo foo.c ~/trans $ ls foo/foo foo.o It seems to break cabal-1.1.1, in the case that I have something like c-sources: foo/foo.c in my .cabal file ... Cheers, Andres

1 0

RE: Re[4]: C--
by Simon Peyton-Jones 09 Aug '05

09 Aug '05

| so, C-- will never be compiled faster than asm, and, at this moment, | cannot give a better optimization than C? as a result, it's use will have no | meaning until qc-- compiler will advance in it's optimization? For those people interested only in getting their Haskell programs compiled, that's pretty much it. Of course, other people might be interested in C-- itself, but that's a different matter. Simon

1 0

RE: Re[2]: C--
by Simon Peyton-Jones 09 Aug '05

09 Aug '05

| SPJ> Actually using C-- itself as an output medium keeps slipping down the | SPJ> agenda, mainly because no one asks for it! | | because you don't advertise it! :) if you will advertise the | following, preferably with less or more concrete numbers, then we will | know whether we want it or not. just asking "whether you want to have C | or C-- compilation path?" is not enough Fair point. I have not advertised it because it doesn't currently work. I'm not sure what priority to give it. We will use qc--, certainly. It isn't optimised for good code, so we will certainly keep the C and asm routes for the foreseeable future. Simon

2 1