1. 16 Nov, 2009 1 commit
  2. 13 Nov, 2009 1 commit
  3. 17 Nov, 2009 4 commits
  4. 15 Nov, 2009 1 commit
  5. 13 Nov, 2009 2 commits
  6. 12 Nov, 2009 1 commit
  7. 13 Nov, 2009 2 commits
  8. 12 Nov, 2009 5 commits
  9. 11 Nov, 2009 1 commit
    • Simon Marlow's avatar
      Second attempt to fix #1185 (forkProcess and -threaded) · 2d5e052d
      Simon Marlow authored
      Patch 1/2: second part of the patch is to libraries/base
      
      This time without dynamic linker hacks, instead I've expanded the
      existing rts/Globals.c to cache more CAFs, specifically those in
      GHC.Conc.  We were already using this trick for signal handlers, I
      should have realised before.
      
      It's still quite unsavoury, but we can do away with rts/Globals.c in
      the future when we switch to a dynamically-linked GHCi.
      2d5e052d
  10. 12 Nov, 2009 3 commits
    • simonpj@microsoft.com's avatar
      A radical overhaul of the coercion infrastucture · cd0e2c0c
      simonpj@microsoft.com authored
      * Core Lint now does full checking of kinds and coercion terms
        which picks up kind errors in coercions that were previously
        simply not checked for
      
      * Coercion.lhs now provides optCoercion which optimises coercion
        terms.  It implements all of Dimitrios's rules
      
      * The constructors for coercion terms now make no attempt to be
        "smart"; instead we rely solely on the coercion optimiser
      
      * CoercionTyCons in TyCon.lhs always had a "custom" kinding rule
        (the coKindFun field of CoercionTyCon) but its type was not 
        clever enough to do both 
           (a) *figure out the result kind*, assuming the whole thing
               is well-kinded in the first place
           (b) *check* the kinds of everything, failing gracefully if
               they aren't right. 
        We need (b) for the new CoreLint stuff. The field now has type
              CoTyConKindChecker
        which does the job nicely.
      cd0e2c0c
    • simonpj@microsoft.com's avatar
      Improve warning message · 74bc2267
      simonpj@microsoft.com authored
      74bc2267
    • simonpj@microsoft.com's avatar
  11. 05 Nov, 2009 1 commit
    • dias@cs.tufts.edu's avatar
      Loop problems in native back ends, update to T3286 fix · c55eee3a
      dias@cs.tufts.edu authored
      The native back ends had difficulties with loops;
      in particular the code for branch-chain elimination
      could run in infinite loops or drop basic blocks.
      The old codeGen didn't expose these problems.
      
      Also, my fix for T3286 in the new codegen was getting
      applied to too many (some wrong) cases; a better pattern
      match fixed that.
      c55eee3a
  12. 18 Sep, 2009 6 commits
  13. 11 Nov, 2009 1 commit
  14. 10 Nov, 2009 1 commit
  15. 08 Nov, 2009 1 commit
  16. 11 Nov, 2009 3 commits
  17. 09 Nov, 2009 1 commit
  18. 11 Nov, 2009 1 commit
    • simonpj@microsoft.com's avatar
      No CoreLint warnings if -dno-debug-output is on · c4ea6c7d
      simonpj@microsoft.com authored
      The Core Lint warnings are new.  There's only one at the moment,
      namely one to identify recursive INLINE things:
      
          [RHS of $c>>_als :: forall s_afT a_alJ b_alK.
                              Cpr001_imp.StateTrans s_afT a_alJ
                              -> Cpr001_imp.StateTrans s_afT b_alK
                              -> Cpr001_imp.StateTrans s_afT b_alK]
          INLINE binder is loop breaker: $c>>_als
      
      This is definitely non-fatal, and typically gets unravelled after
      another simplifier run anyway.  So I'm suppressing such warnings
      for the testsuite, when -dno-debug-output is on.
      c4ea6c7d
  19. 10 Nov, 2009 4 commits