- Glasgow-haskell-users

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 09 Aug '05

09 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

RE: 6.4.1 release candidate testing on OS X
by Simon Marlow 09 Aug '05

09 Aug '05

On 09 August 2005 14:15, Gregory Wright wrote: > ghc-6.4.1.20050806 builds successfully on OS X 10.4.2 using Apple's > gcc-4.0. > > > Bug 1249527 is still fixed, and I was able to build darcs with the > compiler. Nice to hear, thanks Greg! Cheers, Simon

1 0

RE: 6.4.1 release candidate testing on OS X
by Simon Marlow 09 Aug '05

09 Aug '05

On 05 August 2005 23:05, Gregory Wright wrote: > ghc-6.4.1.20050804 builds successfully on Mac OS X 10.4.2 using gcc > 3.3. > > This snapshot also appears to fix bug 1249527, "runhaskell causes GHC > to segfault on OS X". > > The new compiler was also tested by building darcs-1.0.3. > > The build was done under the darwinports infrastructure using ghc-6.4 > as the bootstrap > compiler. > > I haven't yet tried to build using gcc 4.0; should I expect that to > work yet? It might - we've been testing with gcc 4.0, but I believe the MacOS X version has some differences. Cheers, Simon

2 1