Opened 7 years ago

Last modified 4 years 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 Difficulty: Unknown
Test Case: Blocked By:
Blocking: Related Tickets:

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 (18)

comment:1 Changed 7 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 7 years ago by Isaac Dupree

  • Description modified (diff)

comment:3 Changed 7 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 7 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 7 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 7 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 7 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 7 years ago by igloo

Yup, please do remove any such checks.

comment:9 Changed 7 years ago by Isaac Dupree

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

comment:10 Changed 7 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 7 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 7 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 7 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 7 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 6 years ago by simonmar

  • Architecture changed from Unknown to Unknown/Multiple

comment:16 Changed 6 years ago by simonmar

  • Operating System changed from Unknown to Unknown/Multiple

comment:17 Changed 5 years ago by PHO

  • Cc pho@… added

comment:18 Changed 4 years ago by slyfox

  • Cc slyfox@… added
  • Type of failure set to None/Unknown
Note: See TracTickets for help on using tickets.