Opened 8 years ago

Last modified 10 months ago

#1405 new task

Make ghc (stage1) be compilable by non-GHC

Reported by: Isaac Dupree Owned by:
Priority: normal Milestone:
Component: Compiler Version: 6.6.1
Keywords: Cc: pho@…, slyfox@…
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Revisions:

Description (last modified by Isaac Dupree)

This depends a bit on the existence of a good-enough non-GHC compiler. Possibility to do recursively dependent modules (I think) presently rules out everything except JHC, which is not entirely working yet. Also pattern guards might need to be implemented in that compiler. Maybe for testing, a ghc that doesn't define GLASGOW_HASKELL (and doesn't use ghc-specific flags ?? possibly a wrapper script of some sort) could be used too.

See http://thread.gmane.org/gmane.comp.lang.haskell.cvs.ghc/20962 ... GHC also uses things like IORefs, (unsafeCoerce? only in stage2 I think) that everyone provides, but would still be good to document.

I'm working on this now, we'll see how far I get --Isaac

Change History (19)

comment:1 Changed 8 years ago by Isaac Dupree

Also grepping the source for GLASGOW_HASKELL finds many things that need examining. Mostly it is "#if"s for compatibility with old versions of libraries that old versions of GHC have; for non-GHC compilers I think the best thing to do with these is to make sure it assumes the latest version of the libraries (old versions of ghc need to be able to compile new ones for a special reason, and the older versions also had more difficulty having upgradeable packages)

comment:2 Changed 8 years ago by Isaac Dupree

  • Description modified (diff)

comment:3 Changed 8 years ago by Isaac Dupree

Hmm, looking again, it does look like GHC's code sometimes uses unboxed stuff and imports GHC.stuff. Some of the places at least, it seems there's really no excuse for doing so... I can change those (at least if I feel sure there are no performance regressions thereby).

comment:4 Changed 8 years ago by simonpj

The other thing to watch out for is that we keep GHC in a state in which it can be compiled by several earlier versions of GHC. I forget what our current earlier-version threshold is (Simon M would know), but in doing your refactoring please be careful to maintain this property. We don't want to pull up the ladder after ourselvese too quickly!

Simon

comment:5 Changed 8 years ago by Isaac Dupree

Yes, certainly, I think it's ghc-5.04 currently. Is there an easy way to get a copy of that version of ghc (or other versions between that and the current) to test with? Or should I just rely on my intuition while watching for buildbots breaking that use old versions of ghc?

I think it's okay if GHC is merely slower when compiled with older versions of GHC (since normally you'll be using recent GHC for development, and stage2, anyway), for example if older versions of GHC optimized worse or didn't implement UNPACK pragma...

comment:6 Changed 8 years ago by igloo

We abandoned 5.04 support recently as the differences in its hierarchical libraries compared to 6.x were causing too much pain. I think any 6.x is supposed to still work, though.

Bindists are the simplest way of getting older versions, but you might have problems due to them being compiled against older libraries. If it proves tricky then just keeping an eye on the nightly builds is the way to go.

comment:7 Changed 8 years ago by Isaac Dupree

OK, it's now 6.0 or greater (according to http://hackage.haskell.org/trac/ghc/wiki/Building/Prerequisites ). Is it preferred, discouraged or neither, to remove #if __GLASGOW_HASKELL__ > 5.04 sorts of checks in the code now?

comment:8 Changed 8 years ago by igloo

Yup, please do remove any such checks.

comment:9 Changed 8 years ago by Isaac Dupree

Should such checks for really old ghc also be removed in the various ghc/utils programs?

comment:10 Changed 8 years ago by igloo

Support for building with old GHCs, yes. Support for things like looking at the output of old GHCs, possibly not.

comment:11 Changed 8 years ago by Isaac Dupree

random notes:

unsafeCoerce# appears to be only used by ghci and template-haskell (i.e. stage2). It would still be nice to use the Unsafe.Coerce "unsafeCoerce" name (IMHO).

'.#' and 'import.*GHC' are good things to grep for to find non-portable code (although especially the first one will find lots of false positives - the . weeds out preprocessor commands that begin with # at the beginning of lines)

comment:12 Changed 8 years ago by Isaac Dupree

I made FiniteMap use {-# UNPACK #-} !Int instead of Int#. Probably it would be better to change to FastInt (which is good for when GHC compiles itself without optimizations).

Thoughts about FastInt and unboxing: A compiler that doesn't have unboxed types could represent them like newtype !FastInt = I__ Int. That ! somewhere indicates to the compiler that wherever this type is used, it is used strictly: with the same restrictions as unboxed types, as if it were !Int everywhere: in data declarations, in function arguments as if the !Int -> x syntax were implemented (only, clearer, because there is a clear source-type-level distinction between the strict and non-strict versions). This has a semantic effect in FastInt -> x but no effect in x -> FastInt, I believe. (And many constructions, like (FastInt, x) are not allowed for unboxed types, and FastInt sometimes _is_ unboxed...)

For now, changing to Int or FastInt as appropriate, seems the best course. But I'm busy with school soon so I might not get to it for a while (and I'm sure someone else could do as good a job as me, if they want).

comment:13 Changed 8 years ago by Isaac Dupree

In future we may want to aim for compiling GHC with just the extensions it needs, e.g. stage1 with -XPatternGuards not full -fglasgow-exts (except when compiling with an older GHC that doesn't support -X flags).

comment:14 Changed 8 years ago by Isaac Dupree

now working on hard work portabilizing! Will send some darcs patches soon. The more suspicious things (e.g. messing with unboxing) I will make sure to run through performance-checker first.

I found out that ghc's code uses Rank2Types in a few places, in a way that would require changing code substantively to remove, so I guess GHC will just require that useful extension implemented in compilers that want to build GHC :-) (unless someone is really interested in changing that sometime -- and only n/Yhc which doesn't implement cyclically-importing modules either, doesn't implement Rank2Types, IIRC)

details come later

comment:15 Changed 7 years ago by simonmar

  • Architecture changed from Unknown to Unknown/Multiple

comment:16 Changed 7 years ago by simonmar

  • Operating System changed from Unknown to Unknown/Multiple

comment:17 Changed 6 years ago by PHO

  • Cc pho@… added

comment:18 Changed 5 years ago by slyfox

  • Cc slyfox@… added
  • Type of failure set to None/Unknown

comment:19 Changed 10 months ago by thomie

In 206b4dec78250efef3cd927d64dc6cbc54a16c3d/ghc:

lots of portability changes (#1405)

re-recording to avoid new conflicts was too hard, so I just put it
all in one big patch :-(  (besides, some of the changes depended on
each other.)  Here are what the component patches were:

Fri Dec 28 11:02:55 EST 2007  Isaac Dupree <[email protected]>
  * document BreakArray better

Fri Dec 28 11:39:22 EST 2007  Isaac Dupree <[email protected]>
  * properly ifdef BreakArray for GHCI

Fri Jan  4 13:50:41 EST 2008  Isaac Dupree <[email protected]>
  * change ifs on __GLASGOW_HASKELL__ to account for... (#1405)
  for it not being defined. I assume it being undefined implies
  a compiler with relatively modern libraries but without most
  unportable glasgow extensions.

Fri Jan  4 14:21:21 EST 2008  Isaac Dupree <[email protected]>
  * MyEither-->EitherString to allow Haskell98 instance

Fri Jan  4 16:13:29 EST 2008  Isaac Dupree <[email protected]>
  * re-portabilize Pretty, and corresponding changes

Fri Jan  4 17:19:55 EST 2008  Isaac Dupree <[email protected]>
  * Augment FastTypes to be much more complete

Fri Jan  4 20:14:19 EST 2008  Isaac Dupree <[email protected]>
  * use FastFunctions, cleanup FastString slightly

Fri Jan  4 21:00:22 EST 2008  Isaac Dupree <[email protected]>
  * Massive de-"#", mostly Int# --> FastInt (#1405)

Fri Jan  4 21:02:49 EST 2008  Isaac Dupree <[email protected]>
  * miscellaneous unnecessary-extension-removal

Sat Jan  5 19:30:13 EST 2008  Isaac Dupree <[email protected]>
  * add FastFunctions
Note: See TracTickets for help on using tickets.