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. 07 Oct, 2014 1 commit
    • rwbarton's avatar
      Bump haddock.base perf numbers · e87135ce
      rwbarton authored
      We were so close to the max that the test failed if the pathname to
      the GHC repository was more than a few dozen characters, causing the
      haddock.base test to fail on Phab but not locally.
      e87135ce
  2. 24 Sep, 2014 1 commit
    • Edward Z. Yang's avatar
      Update Cabal submodule & ghc-pkg to use new module re-export types · 4b648be1
      Edward Z. Yang authored
      Summary:
      The main change is that Cabal changed the representation of module
      re-exports to distinguish reexports in source .cabal files versus
      re-exports in installed package registraion files.
      
      Cabal now also does the resolution of re-exports to specific installed
      packages itself, so ghc-pkg no longer has to do this. This is a cleaner
      design overall because re-export resolution can fail so it is better to
      do it during package configuration rather than package registration.
      It also simplifies the re-export representation that ghc-pkg has to use.
      
      Add extra ghc-pkg sanity check for module re-exports and duplicates
      
      For re-exports, check that the defining package exists and that it
      exposes the defining module (or for self-rexport exposed or hidden
      modules). Also check that the defining package is actually a direct
      or indirect dependency of the package doing the re-exporting.
      
      Also add a check for duplicate modules in a package, including
      re-exported modules.
      
      Test Plan:
      So far the sanity checks are totally untested. Should add some test
      case to make sure the sanity checks do catch things correctly, and
      don't ban legal things.
      
      Reviewers: austin, duncan
      
      Subscribers: angerman, simonmar, ezyang, carter
      
      Differential Revision: https://phabricator.haskell.org/D183
      
      GHC Trac Issues:
      4b648be1
  3. 10 Sep, 2014 1 commit
    • Joachim Breitner's avatar
      Update performance numbers · 71c85300
      Joachim Breitner authored
      including some that are not failing yet, but did show a significant
      change, and some that Austing changed post-AMP, but where both
      harbormaster and ghcspeed reported something else. Numbers taken from
      the ghcspeed machine.
      71c85300
  4. 09 Sep, 2014 1 commit
    • Austin Seipp's avatar
      Make Applicative a superclass of Monad · d94de872
      Austin Seipp authored
      
      
      Summary:
      This includes pretty much all the changes needed to make `Applicative`
      a superclass of `Monad` finally. There's mostly reshuffling in the
      interests of avoid orphans and boot files, but luckily we can resolve
      all of them, pretty much. The only catch was that
      Alternative/MonadPlus also had to go into Prelude to avoid this.
      
      As a result, we must update the hsc2hs and haddock submodules.
      Signed-off-by: default avatarAustin Seipp <austin@well-typed.com>
      
      Test Plan: Build things, they might not explode horribly.
      
      Reviewers: hvr, simonmar
      
      Subscribers: simonmar
      
      Differential Revision: https://phabricator.haskell.org/D13
      d94de872
  5. 06 Sep, 2014 2 commits
  6. 05 Sep, 2014 1 commit
  7. 04 Sep, 2014 3 commits
  8. 02 Sep, 2014 1 commit
  9. 01 Sep, 2014 2 commits
  10. 29 Aug, 2014 1 commit
    • Simon Peyton Jones's avatar
      Performance improvement of the compiler itself · 5da580be
      Simon Peyton Jones authored
      This is a result of one of these, or a combination
        002b7a2b * Give the worker for an INLINABLE function a suitably-phased Activation
        ca666b8b * When finding loop breakers, distinguish INLINE from INLINEABLE
        a98c9c5e * Fix a bug in CSE, for INLINE/INLNEABLE things
      
      Some changes are quite big: for bytes_allocated we have
        T6048: 13% below expected
        T5837: 15% below expected
        T3064:  5% below expected
      
      Of course, these might have already been close to their lower
      threshold, so perhaps not all the improvement is from here.
      But it is good news all the same.
      5da580be
  11. 08 Aug, 2014 1 commit
  12. 07 Aug, 2014 1 commit
    • Edward Z. Yang's avatar
      Permanently accept the Haddock performance number bump, and add some TODOs · d026e9e8
      Edward Z. Yang authored
      I bisected the performance difference in Haddock and found it was due to
      d6aec63c009c4e57181900eb03847d7dc0fc3c7c, which I accidentally picked up
      when updating Haddock 00b8f8c5
      
      .  The
      performance regression is justified by the fact that we are now actually
      processing URLs in Haddock comments that we were not previously, so
      there would be more allocation.  Time use was not affected.
      
      The TODOs simply reflect the fact that we need updated numbers for
      32-bit Linux and Windows.  Please add them when you get a chance.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      d026e9e8
  13. 05 Aug, 2014 1 commit
  14. 01 Aug, 2014 1 commit
    • Joachim Breitner's avatar
      Bump haddock.base max_bytes_used · 8df7fea7
      Joachim Breitner authored
      It has reliably increased with commit 1ae5fa45, and has been stable
      since then, so it does not seem to be a fluke. I did not investigate why
      that commit might have increased this value.
      8df7fea7
  15. 17 Jul, 2014 1 commit
    • Joachim Breitner's avatar
      Adjust a few performance numbers · 13cb4c27
      Joachim Breitner authored
      These did not yet trigger a failure, but are more than 1% away from the
      expected value. Since I now start collecting logs to investigate
      deviations from the expected value, it makes sense to reset them. This
      way we know that every significat deviation was caused since this
      commit.
      
      I only updated bytes_allocated numbers, as these are (mostly)
      deterministic. Other depend, AFAIK, on sampling timing, so I did not
      bother.
      13cb4c27
  16. 14 Jul, 2014 1 commit
  17. 29 Jun, 2014 1 commit
    • Herbert Valerio Riedel's avatar
      Update 32bit & 64bit performance numbers · f12075d3
      Herbert Valerio Riedel authored
      Some numbers have decreased but the haddock numbers have generally
      increased noticeable again (see also last update in 970e5d99)
      
      This updates all numbers I noticed in the "fast" test-mode, *except* for
      the T9203 test-case on 32bit, which needs more investigation before
      bumping due to its significant increase:
      
        bytes allocated value is too high:
            Expected    bytes allocated: 50000000 +/-5%
            Lower bound bytes allocated: 47500000
            Upper bound bytes allocated: 52500000
            Actual      bytes allocated: 85093548
        *** unexpected failure for T9203(normal)
      f12075d3
  18. 12 Jun, 2014 1 commit
  19. 28 Apr, 2014 1 commit
  20. 07 Apr, 2014 1 commit
  21. 28 Jan, 2014 1 commit
    • Austin Seipp's avatar
      Update some mingw32 perf numbers. · db9baf08
      Austin Seipp authored
      
      
      I forgot to push these from my win32 machine. A lot of them actually
      look like a result of Herbert doing his GMP work, which might slightly
      affect allocations on platforms like Windows (where we always use
      in-tree GMP - but presumably Windows allocations could fluxuate slightly
      due to minute details in the GMP implementation, too.)
      Signed-off-by: default avatarAustin Seipp <austin@well-typed.com>
      db9baf08
  22. 23 Jan, 2014 1 commit
  23. 22 Jan, 2014 1 commit
  24. 14 Jan, 2014 1 commit
  25. 12 Jan, 2014 1 commit
  26. 28 Dec, 2013 1 commit
  27. 12 Dec, 2013 1 commit
  28. 27 Nov, 2013 1 commit
  29. 22 Nov, 2013 2 commits
  30. 18 Oct, 2013 1 commit
  31. 18 Sep, 2013 1 commit
  32. 17 Sep, 2013 1 commit
  33. 27 Aug, 2013 2 commits
  34. 08 Jun, 2013 1 commit