1. 24 Oct, 2007 5 commits
  2. 23 Oct, 2007 1 commit
  3. 24 Oct, 2007 2 commits
  4. 23 Oct, 2007 2 commits
  5. 22 Oct, 2007 1 commit
  6. 18 Oct, 2007 1 commit
    • Simon Marlow's avatar
      add PIC relocations for x86_64, and use a simpler hack in place of x86_64_high_symbol() · 2fc88e73
      Simon Marlow authored
      This is Wolfgang Thaller's patch sent to cvs-ghc recently, with extra
      commentary by me.  It turns out that this patch is not just a cleanup,
      it is also necessary for GHCi to work on x86_64 with shared libraries,
      because previously lookupSymbol() was creating jump-table entries for
      all symbols looked up that resolved outside 2Gb, whereas Wolfgang's
      version only generates jump-table entries for 32-bit symbol references
      in object code that we load.
      2fc88e73
  7. 17 Oct, 2007 1 commit
  8. 16 Oct, 2007 1 commit
  9. 19 Oct, 2007 2 commits
    • Simon Marlow's avatar
      second attempt to fix C compiler warnings with -fhpc · a0d2d5bb
      Simon Marlow authored
      The hs_hpc_module() prototype in RtsExternal.h didn't match its usage:
      we were passing StgWord-sized parameters but the prototype used C
      ints.  I think it accidentally worked because we only ever passed
      constants that got promoted.  The constants unfortunately were
      sometimes negative, which caused the C compiler to emit warnings.
      
      I suspect PprC.pprHexVal may be wrong to emit negative constants in
      the generated C, but I'm not completely sure.  Anyway, it's easy to
      fix this in CgHpc, which is what I've done.
      a0d2d5bb
    • chak@cse.unsw.edu.au.'s avatar
      Zonk quantified tyvars with skolems · cad764aa
      chak@cse.unsw.edu.au. authored
      We used to zonk quantified type variables to regular TyVars.  However, this
      leads to problems.  Consider this program from the regression test suite:
      
        eval :: Int -> String -> String -> String
        eval 0 root actual = evalRHS 0 root actual
      
        evalRHS :: Int -> a
        evalRHS 0 root actual = eval 0 root actual
      
      It leads to the deferral of an equality
      
        (String -> String -> String) ~ a
      
      which is propagated up to the toplevel (see TcSimplify.tcSimplifyInferCheck).
      In the meantime `a' is zonked and quantified to form `evalRHS's signature.
      This has the *side effect* of also zonking the `a' in the deferred equality
      (which at this point is being handed around wrapped in an implication
      constraint).
      
      Finally, the equality (with the zonked `a') will be handed back to the
      simplifier by TcRnDriver.tcRnSrcDecls calling TcSimplify.tcSimplifyTop.
      If we zonk `a' with a regular type variable, we will have this regular type
      variable now floating around in the simplifier, which in many places assumes to
      only see proper TcTyVars.
      
      We can avoid this problem by zonking with a skolem.  The skolem is rigid
      (which we requirefor a quantified variable), but is still a TcTyVar that the
      simplifier knows how to deal with.
      cad764aa
  10. 18 Oct, 2007 1 commit
  11. 19 Oct, 2007 2 commits
  12. 18 Oct, 2007 8 commits
  13. 17 Oct, 2007 2 commits
  14. 18 Oct, 2007 2 commits
  15. 17 Oct, 2007 5 commits
  16. 25 Sep, 2007 1 commit
  17. 17 Oct, 2007 1 commit
  18. 16 Oct, 2007 2 commits
    • simonpj@microsoft.com's avatar
      Fix #1709: do not expose the worker for a loop-breaker · 592269df
      simonpj@microsoft.com authored
      The massive 'Uni' program produced a situation in which a function that
      had a worker/wrapper split was chosen as a loop breaker.  If the worker
      is exposed in the interface file, then an importing module may go into
      an inlining loop: see comments on TidyPgm.tidyWorker.
      
      This patch fixes the inlining bug.  The code that gives rise to this
      bizarre case is still not good (it's a bunch of implication constraints
      and we are choosing a bad loop breaker) but the first thing is to fix the
      bug.
      
      It's rather hard to produce a test case!
      
      Please merge to the 6.8 branch.
      
      
      592269df
    • simonpj@microsoft.com's avatar
      Fix #1662: do not simplify constraints for vanilla pattern matches · 56a39804
      simonpj@microsoft.com authored
      See Note [Arrows and patterns] in TcPat.  
      
      This fixes Trac 1662.   Test is arrows/should_compile/arrowpat.hs
      
      Please merge
      56a39804