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 6 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. 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
  15. 23 Jan, 2009 1 commit
  16. 30 Jan, 2009 1 commit
  17. 02 Feb, 2009 2 commits
  18. 30 Jan, 2009 3 commits
  19. 29 Jan, 2009 1 commit
    • simonpj@microsoft.com's avatar
      Two more wibbles to CorePrep (fixes HTTP package and DPH) · 6af98b2f
      simonpj@microsoft.com authored
      Ensuring that 
        a) lambdas show up only on the RHSs of binding after CorePrep
        b) the arity of a binding exactly matches the maifest lambdas
      is surprisingly tricky.
      
      I got it wrong (again) in my recent CorePrep shuffling, which broke
      packages HTTP and DPH.  This patch fixes both.
      6af98b2f
  20. 27 Jan, 2009 2 commits
  21. 26 Jan, 2009 1 commit
    • Simon Marlow's avatar
      Fix #2961: we lost some of the generated code for stack args in genCCall · ff124db4
      Simon Marlow authored
      A real bug in the x86_64 native code gen: nice!
      
      This bug would have been caught by -Wall, and I would have gone though
      and Walled this file but I know Ben is hacking on this file quite
      heavily and I don't want to create undue conflicts.  Ben: it would be
      nice to enable -Wall here when you have time.
      ff124db4