1. 06 Feb, 2009 1 commit
    • Ian Lynagh's avatar
      When generating C, don't pretend functions are data · 497302c4
      Ian Lynagh authored
      We used to generated things like:
          extern StgWordArray (newCAF) __attribute__((aligned (8)));
          ((void (*)(void *))(W_)&newCAF)((void *)R1.w);
      (which is to say, pretend that newCAF is some data, then cast it to a
      function and call it).
      This goes wrong on at least IA64, where:
          A function pointer on the ia64 does not point to the first byte of
          code. Intsead, it points to a structure that describes the function.
          The first quadword in the structure is the address of the first byte
          of code
      so we end up dereferencing function pointers one time too many, and
      segfaulting.
      497302c4
  2. 05 Feb, 2009 1 commit
  3. 04 Feb, 2009 4 commits
  4. 05 Feb, 2009 1 commit
  5. 04 Feb, 2009 2 commits
  6. 03 Feb, 2009 5 commits
  7. 02 Feb, 2009 1 commit
  8. 23 Jan, 2009 3 commits
  9. 22 Jan, 2009 1 commit
  10. 04 Feb, 2009 7 commits
  11. 15 Jan, 2009 1 commit
    • simonpj@microsoft.com's avatar
      Robustify lookupFamInstEnv, plus some refactoring · 027e6be2
      simonpj@microsoft.com authored
      This patch deals with the following remark
      
           Suppose we have
                  type family T a :: * -> *
                  type instance T Int = []
      
           and now we encounter the type (T Int Bool).  If we call
           lookupFamInstEnv on (T Int Bool) we'll fail, because T has arity 1.
           Indeed, I *think* it's a precondition of lookupFamInstEnv that the
           supplied types exactly match the arity of the type function.  But
           that precondition is neither stated, nor is there an assertion to
           check it.
      
      With this patch, lookupFamInstEnv can take "extra" type arguments in
      the over-saturated case, and does the Right Thing.
      
      There was a nearly-identical function lookupFamInstEnvUnify, which
      required the precisely analogous change, so I took the opportunity 
      to combine the two into one function, so that bugs can be fixed in one
      place.  This was a bit harder than I expected, but I think the result
      is ok.  The conflict-decision function moves from FamInst to FamInstEnv.
      Net lines code decreases, although there are more comments.
      
      
      027e6be2
  12. 14 Jan, 2009 1 commit
    • simonpj@microsoft.com's avatar
      Robustify lookupFamInstEnv · 27759873
      simonpj@microsoft.com authored
      Suppose we have
              type family T a :: * -> *
              type instance T Int = []
      
      and now we encounter the type (T Int Bool).  That is perfectly
      fine, even though T is over-saturated here.
      
      This patch makes lookupFamInstEnv robust to such over-saturation.
      Previously one caller (TcTyFuns.tcUnfoldSynFamInst) dealt with
      the over-saturation case, but the others did not. It's better
      to desl with the issue at the root, in lookupFamInstEnv itself.
      27759873
  13. 13 Jan, 2009 1 commit
  14. 03 Feb, 2009 1 commit
  15. 02 Feb, 2009 1 commit
    • Simon Marlow's avatar
      Optimise writing out the .s file · 6ba3d614
      Simon Marlow authored
      I noticed while working on the new IO library that GHC was writing out
      the .s file in lots of little chunks.  It turns out that this is a
      result of using multiple printDocs to avoid space leaks in the NCG,
      where each printDoc is finishing up with an hFlush.  
      
      What's worse, is that this makes poor use of the optimisation inside
      printDoc that uses its own buffering to avoid hitting the Handle all
      the time.
      
      So I hacked around this by making the buffering optimisation inside
      Pretty visible from the outside, for use in the NCG.  The changes are
      quite small.
      6ba3d614
  16. 23 Jan, 2009 1 commit
  17. 30 Jan, 2009 2 commits
  18. 02 Feb, 2009 2 commits
  19. 30 Jan, 2009 1 commit
  20. 01 Feb, 2009 1 commit
  21. 30 Jan, 2009 2 commits
    • simonpj@microsoft.com's avatar
      Fix Trac #2985: generating superclasses and recursive dictionaries · c04a5fe3
      simonpj@microsoft.com authored
      The Note [Recursive instances and superclases] explains the subtle
      issues to do with generating the bindings for superclasses when
      we compile an instance declaration, at least if we want to do the
      clever "recursive superclass" idea from the SYB3 paper.
      
      The old implementation of tcSimplifySuperClasses stumbled when
      type equalities entered the picture (details in the Note); this
      patch fixes the problem using a slightly hacky trick.  When we
      re-engineer the constraint solver we'll want to keep an eye on 
      this.
      
      Probably worth merging to the 6.10 branch.
      
      c04a5fe3
    • simonpj@microsoft.com's avatar
      White space only · 6a104dcf
      simonpj@microsoft.com authored
      6a104dcf