This project is mirrored from https://gitlab.haskell.org/ghc/ghc.git. Pull mirroring failed .
Repository mirroring has been paused due to too many failed attempts. It can be resumed by a project maintainer.
Last successful update .
  1. 02 Jun, 2009 1 commit
  2. 15 May, 2009 1 commit
  3. 06 Mar, 2009 1 commit
    • Simon Marlow's avatar
      Partial fix for #2917 · 1b62aece
      Simon Marlow authored
       - add newAlignedPinnedByteArray# for allocating pinned BAs with
         arbitrary alignment
      
       - the old newPinnedByteArray# now aligns to 16 bytes
      
      Foreign.alloca will use newAlignedPinnedByteArray#, and so might end
      up wasting less space than before (we used to align to 8 by default).
      Foreign.allocaBytes and Foreign.mallocForeignPtrBytes will get 16-byte
      aligned memory, which is enough to avoid problems with SSE
      instructions on x86, for example.
      
      There was a bug in the old newPinnedByteArray#: it aligned to 8 bytes,
      but would have failed if the header was not a multiple of 8
      (fortunately it always was, even with profiling).  Also we
      occasionally wasted some space unnecessarily due to alignment in
      allocatePinned().
      
      I haven't done anything about Foreign.malloc/mallocBytes, which will
      give you the same alignment guarantees as malloc() (8 bytes on
      Linux/x86 here).
      1b62aece
  4. 27 Jan, 2009 1 commit
  5. 10 Dec, 2008 1 commit
  6. 06 Nov, 2008 1 commit
  7. 10 Oct, 2008 1 commit
  8. 10 Jul, 2008 1 commit
  9. 09 Jul, 2008 1 commit
  10. 23 Jun, 2008 1 commit
  11. 14 Jun, 2008 1 commit
  12. 27 May, 2008 1 commit
  13. 21 Apr, 2008 1 commit
  14. 17 Apr, 2008 1 commit
  15. 29 Mar, 2008 1 commit
  16. 25 Sep, 2007 1 commit
  17. 01 Sep, 2007 1 commit
  18. 30 Aug, 2007 1 commit
  19. 14 May, 2007 1 commit
  20. 10 May, 2007 1 commit
  21. 03 May, 2007 1 commit
  22. 17 Apr, 2007 1 commit
    • Simon Marlow's avatar
      Re-working of the breakpoint support · cdce6477
      Simon Marlow authored
      This is the result of Bernie Pope's internship work at MSR Cambridge,
      with some subsequent improvements by me.  The main plan was to
      
       (a) Reduce the overhead for breakpoints, so we could enable 
           the feature by default without incurrent a significant penalty
       (b) Scatter more breakpoint sites throughout the code
      
      Currently we can set a breakpoint on almost any subexpression, and the
      overhead is around 1.5x slower than normal GHCi.  I hope to be able to
      get this down further and/or allow breakpoints to be turned off.
      
      This patch also fixes up :print following the recent changes to
      constructor info tables.  (most of the :print tests now pass)
      
      We now support single-stepping, which just enables all breakpoints.
      
        :step <expr>     executes <expr> with single-stepping turned on
        :step            single-steps from the current breakpoint
      
      The mechanism is quite different to the previous implementation.  We
      share code with the HPC (haskell program coverage) implementation now.
      The coverage pass annotates source code with "tick" locations which
      are tracked by the coverage tool.  In GHCi, each "tick" becomes a
      potential breakpoint location.
      
      Previously breakpoints were compiled into code that magically invoked
      a nested instance of GHCi.  Now, a breakpoint causes the current
      thread to block and control is returned to GHCi.
      
      See the wiki page for more details and the current ToDo list:
      
        http://hackage.haskell.org/trac/ghc/wiki/NewGhciDebugger
      cdce6477
  23. 17 Mar, 2007 1 commit
  24. 14 Mar, 2007 2 commits
  25. 06 Mar, 2007 1 commit
    • Simon Marlow's avatar
      add noDuplicate# · 78c491b1
      Simon Marlow authored
      This primop ensures that the current computation is not being
      duplicated, by calling threadPaused().  The idea is to use it inside
      unsafePerformIO/unsafeInterleaveIO (see #986).
      78c491b1
  26. 01 Mar, 2007 1 commit
  27. 28 Feb, 2007 1 commit
  28. 27 Feb, 2007 1 commit
  29. 09 Dec, 2006 1 commit
  30. 07 Oct, 2006 1 commit
  31. 07 Apr, 2006 1 commit
    • Simon Marlow's avatar
      Reorganisation of the source tree · 0065d5ab
      Simon Marlow authored
      Most of the other users of the fptools build system have migrated to
      Cabal, and with the move to darcs we can now flatten the source tree
      without losing history, so here goes.
      
      The main change is that the ghc/ subdir is gone, and most of what it
      contained is now at the top level.  The build system now makes no
      pretense at being multi-project, it is just the GHC build system.
      
      No doubt this will break many things, and there will be a period of
      instability while we fix the dependencies.  A straightforward build
      should work, but I haven't yet fixed binary/source distributions.
      Changes to the Building Guide will follow, too.
      0065d5ab
  32. 27 Mar, 2006 1 commit
    • Simon Marlow's avatar
      Add a new primitive forkOn#, for forking a thread on a specific Capability · c520a3a2
      Simon Marlow authored
      This gives some control over affinity, while we figure out the best
      way to automatically schedule threads to make best use of the
      available parallelism.
      
      In addition to the primitive, there is also:
       
        GHC.Conc.forkOnIO :: Int -> IO () -> IO ThreadId
      
      where 'forkOnIO i m' creates a thread on Capability (i `rem` N), where
      N is the number of available Capabilities set by +RTS -N.
      
      Threads forked by forkOnIO do not automatically migrate when there are
      free Capabilities, like normal threads do.  Still, if you're using
      forkOnIO exclusively, it's a good idea to do +RTS -qm to disable work
      pushing anyway (work pushing takes too much time when the run queues
      are large, this is something we need to fix).
      c520a3a2
  33. 25 Nov, 2005 1 commit
  34. 25 Jul, 2005 1 commit
    • simonmar's avatar
      [project @ 2005-07-25 14:12:48 by simonmar] · e792bb84
      simonmar authored
      Remove the ForeignObj# type, and all its PrimOps.  The new efficient
      representation of ForeignPtr doesn't use ForeignObj# underneath, and
      there seems no need to keep it.
      e792bb84
  35. 07 Mar, 2005 2 commits
  36. 04 Mar, 2005 1 commit
    • sof's avatar
      [project @ 2005-03-04 19:19:56 by sof] · 75d52d81
      sof authored
      Since MachDeps.h doesn't include ghcconfig.h, include it specifically here
      (for the benefit of mingw). That may not be the right file to use in the
      grander scheme of things tho.
      
      Merge to STABLE (or something equivalent; as-is STABLE doesn't build on mingw.)
      75d52d81
  37. 31 Jan, 2005 1 commit
    • simonpj's avatar
      [project @ 2005-01-31 13:25:33 by simonpj] · f25b9225
      simonpj authored
      ---------------------------
      	Types and evaluated-ness in
      	  CoreTidy and CorePrep
      	---------------------------
      
      This commmit fixes two problems.
      
      1.  DataToTagOp requires its argument to be evaluated, otherwise it silently
          gives the wrong answer.  This was not happening because we had
      	case (tag2Enum x) of y -> ...(dataToTag y)...
          and the tag2Enum was being inlined (it's non-speculative), giving
      	...(dataToTag (tag2Enum x))...
      
          Rather than relying on a somewhat-delicate global invariant, CorePrep
          now establishes the invariant that DataToTagOp's argument is evaluated.
          It does so by putting up-to-date is-evaluated information into each
          binder's UnfoldingInfo; not a full unfolding, just the (OtherCon [])
          for evaluated binders.
      
          Then there's a special case for DataToTag where applications are dealt with.
      
          Finally, we make DataToTagOp strict, which it really is.
      
      
      2.  CoreTidy now does GADT refinement as it goes. This is important to ensure that
          each variable occurrence has informative type information, which in turn is
          essential to make exprType work (otherwise it can simply crash).
          [This happened in test gadt/tdpe]
      
          CorePrep has the same problem, but the solution is a little different:
          when looking up in the cloning environment, use the type at the occurrence
          site if we're inside a GADT.  It might be cleaner to use the same story as
          CoreTidy, but then we'd need to keep an in-scope set for type variables.
          No big deal either way.
      f25b9225
  38. 18 Nov, 2004 1 commit