1. 26 Mar, 2007 2 commits
  2. 23 Mar, 2007 3 commits
  3. 22 Mar, 2007 6 commits
  4. 21 Mar, 2007 1 commit
    • simonpj@microsoft.com's avatar
      Fix checkHiBootIface for instances declared in hs-boot files · 9ac57e65
      simonpj@microsoft.com authored
      Hs-boot files can contain instance declarations, but Duncan used this feature
      for the first time today, and it didn't quite work.  I'm not sure whether
      it worked before; anyway it does now.
      The point is that the hs-boot file advertises an instance for, say, Num Int,
      with the arbitrary name $fx1.  The main module declares Num Int, and gives
      it the name, say, $f3.  So we need to generate a declaration
      	$fx1 = $f3
      to make it all line up.  And (this is the bit that was wrong) we need
      to make that new binding visible to imported unfoldings that mention
  5. 18 Mar, 2007 1 commit
    • red5_2@hotmail.com's avatar
      mangler and runtime updates for gcc 4 on ia64 · 79adecdb
      red5_2@hotmail.com authored
      Gcc 4 is doing more clever optimizations than earlier gccs. 
      These changes let ghc compile and run on ia64 with gcc 4.0.3.
      Register stack frames are enlarged so that all functions use the 
      same size stack frame.
      The code to mangle tail calls has been cleaned up and made more 
      Additional floating-point and special-purpose registers used by 
      GCC are saved upon entering the STG runtime.
      More general handling of NOP instructions.
      Handling of functions with multiple epilogues or no epilogue.
  6. 17 Mar, 2007 1 commit
    • red5_2@hotmail.com's avatar
      ia64 tailcall fix · 123ed121
      red5_2@hotmail.com authored
      Tail-calls now branch to the end of the function after the call.  This 
      stops gcc from trying to move instructions into the space immediately 
      after the call, which confuses the mangler.
  7. 21 Mar, 2007 5 commits
  8. 20 Mar, 2007 1 commit
  9. 19 Mar, 2007 1 commit
  10. 17 Mar, 2007 1 commit
  11. 16 Mar, 2007 4 commits
    • simonpj@microsoft.com's avatar
      Desugar applications of 'seq' specially; fix Trac #1031 · 3bdbcf16
      simonpj@microsoft.com authored
      Merge to 6.6 branch.  Test case is dsrun014.
      Note [Desugaring seq]  cf Trac #1031
         f x y = x `seq` (y `seq` (# x,y #))
      The [CoreSyn let/app invariant] means that, other things being equal, because 
      the argument to the outer 'seq' has an unlifted type, we'll use call-by-value thus:
         f x y = case (y `seq` (# x,y #)) of v -> x `seq` v
      But that is bad for two reasons: 
        (a) we now evaluate y before x, and 
        (b) we can't bind v to an unboxed pair
      Seq is very, very special!  So we recognise it right here, and desugar to
      	case x of _ -> case y of _ -> (# x,y #)
      The special case would be valid for all calls to 'seq', but it's only *necessary*
      for ones whose second argument has an unlifted type. So we only catch the latter
      case here, to avoid unnecessary tests.
    • simonpj@microsoft.com's avatar
      Improve error messages for 'deriving' clauses · ed81632e
      simonpj@microsoft.com authored
      This patch improves the misleading error message reported in Trac #1133.
      Please merge the patch to the 6.6.1 branch.
    • simonpj@microsoft.com's avatar
      Refactor TcRnDriver, and check exports on hi-boot files · ec0b8599
      simonpj@microsoft.com authored
      This patch refactors TcRnDriver to make the top-level structure
      easier to understand.  
      The change was driven by Trac #924, and this patch fixes that bug.
      When comparing a module against its hs-boot file, we must ensure that
      the module exports everything that the hs-boot file exports.
    • simonpj@microsoft.com's avatar
      Comment out debug traces · 7fcfb091
      simonpj@microsoft.com authored
  12. 15 Mar, 2007 3 commits
    • sven.panne@aedion.de's avatar
      Use update-alternatives for handling generic tool names · 1ee08bbe
      sven.panne@aedion.de authored
      ATTENTION: Packagers should read the following stuff carefully!
      GHC, Hugs and nhc come with various tools like runhaskell or hsc2hs. On the
      one hand this is quite handy, avoiding lots of tiny native packages, but OTOH
      this leads to a few problems:
         * The tools are not always identical in functionality.
         * The tools fight for a global generic name like "/usr/bin/runhaskell".
      These problems are not new and not unique to Haskell implementations, so for
      *nix-based system there is a tool called update-alternatives which handles
      those cases. The idea is as follows:
         * Each program/man page/etc. installs itself with a very specific name
           like /usr/bin/hsc2hs-ghc or /usr/share/man/man1/lua5.1.1.gz, so nothing
         * The (un-)installation scripts call update-alternatives to notify the
           system about new alternatives for a generic tool/manpage/etc.
         * Alternatives can be grouped together ("link groups"), so e.g. switching
           from Sun's Java to Kaffe switches compiler, JRE, manpages etc. together.
           Alas, this doesn't work well with the Haskell implementations yet,
           because they come with different sets of tools (in addition to runFOO):
             GHC:  hsc2hs
             Hugs: hsc2hs, cpphs
             nhc:  cpphs
           Either these tools should be disentangled fromt the Haskell
           implementations or all implementations should offer the same set.
           Opinions and recommendations on this topic are highly welcome.
         * This mechanism can be used to easily switch between several versions of
           the same implementation, too, but we are not yet fully prepared for that.
      As a first step, GHC now installs hsc2hs as 'hsc2hs-ghc' and does *not*
      install runhaskell directly anymore, only runghc. hsc2hs and runhaskell are
      created via update-alternatives now. What is currently missing is a mechanism
      for platforms like Windows and probably Mac OS X.
    • simonpj@microsoft.com's avatar
      Make the type-defaulting in GHCi use () as the first default type · d4b95ea9
      simonpj@microsoft.com authored
      See Trac #1200
      This is a somewhat experimental fix.  I'm not sure we want it in 6.6.1
      The idea is explained in Note [Default unitTy] in TcSimplify.  In
      interative mode (or with -fextended-default-rules) we add () as the
      first type we try when defaulting.  This has very little real impact,
      except in the following case.  Consider:
      	Text.Printf.printf "hello"
      This has type (forall a. IO a); it prints "hello", and returns
      'undefined'.  We don't want the GHCi repl loop to try to print that
      'undefined'.  The neatest thing is to default the 'a' to (), rather
      than to Integer (which is what would otherwise happen; and then GHCi
      doesn't attempt to print the ().  So in interactive mode, we add () to
      the list of defaulting types.  
    • sven.panne@aedion.de's avatar
      Added support for parallel builds · cbb81129
      sven.panne@aedion.de authored
      With this patch, one can define the degree of build parallelism via a 'jobs'
      rpm variable. A comfortable way to use this is having a ~/.rpmmacros file with
      a line like:
         %jobs 2
      Alternatively, one could use a '--define "jobs 2"' command line flag for
      rpmbuild. On a Core 2 Duo using 2 jobs brings down the time for a full build
      including extralibs from 36m to 27m. If 'jobs' is not defined, a normal
      sequential build is done, following the usual conventions on e.g. openSUSE.
  13. 14 Mar, 2007 11 commits