1. 30 May, 2018 13 commits
    • Kavon Farvardin's avatar
      Extract hard-coded LLVM opt flags into a file · a4ae199c
      Kavon Farvardin authored
      To resolve ticket #11295, I think it makes sense to stop hard-coding
      the pass sequences used by GHC when compiling with LLVM into the
      This patchset introduces a companion to the existing `llvm-targets` file
      called `llvm-passes`. The passes file is a simple association list that
      holds the default LLVM `opt` pass sequence used by GHC. This allows end
      users to easily save their favorite optimization flags when compiling
      with LLVM.
      The main benefit for ticket #11295 is that when adding a custom pass
      sequence, it tends to be an extremely long string that would be
      unsightly in the code.
      This is essentially part 1 of 2 for ticket #11295.
      Test Plan: ./validate
      Reviewers: bgamari, angerman
      Reviewed By: angerman
      Subscribers: rwbarton, thomie, carter
      Differential Revision: https://phabricator.haskell.org/D4695
    • Ningning Xie's avatar
      Define MCoercion type · 9aac442f
      Ningning Xie authored
      An attempt on #14975:
      During compilation, reflexive casts is discarded for computation.
      Currently in some places we use Maybe coercion as inputs. So if a cast
      is reflexive it is denoted as Nothing, otherwise Just coercion.
      This patch defines the type
      data MCoercion = MRefl | MCo Coercion
      which is isomorphic to Maybe Coercion but useful in a number of places,
      and super-helpful documentation.
      Test Plan: validate
      Reviewers: bgamari, goldfire, simonpj
      Reviewed By: goldfire
      Subscribers: mpickering, rwbarton, thomie, carter
      GHC Trac Issues: #14975
      Differential Revision: https://phabricator.haskell.org/D4699
    • Ben Gamari's avatar
      rts: Don't madvise if mmap failed · 34464fed
      Ben Gamari authored
      On 32-bit Linux `outofmem` did not fail with the expected out-of-memory
      error message, instead failing with,
          outofmem: internal error: getMBlock: mmap: Invalid argument
      This happened because, `my_mmap` would attempt to `madvise` even if the
      `mmap` call failed. So while `mmap` returns `ENOMEM` we nevertheless try
      to `madvise`, which clobbers `errno`, giving us the unexpected `EINVAL`
      error. Consequently we don't detect this to be an out-of-memory error.
      This should fix #15060.
      Test Plan: `make test TEST=outofmem` on i386
      Reviewers: simonmar, erikd
      Reviewed By: simonmar
      Subscribers: rwbarton, thomie, carter
      GHC Trac Issues: #15060
      Differential Revision: https://phabricator.haskell.org/D4704
    • Tao He's avatar
      Put the `ev_binds` of main function inside `runMainIO` · 49e423e9
      Tao He authored
      This ensures that the deferred type error can be emitted correctly.
      For `main` function in `Main` module, we have
          :Main.main = GHC.TopHandler.runMainIO main
      When the type of `main` is not `IO t` and the
      `-fdefer-type-errors` is enabled, the `ev_binds`
      of `main` function will contain deferred type
      Previously, the `ev_binds` are bound to `runMainIO main`,
      rather than `main`, the type error exception at runtime
      cannot be handled properly. See Trac #13838.
      This patch fix that.
      Test Plan: make test TEST="T13838"
      Reviewers: bgamari
      Reviewed By: bgamari
      Subscribers: rwbarton, thomie, carter
      GHC Trac Issues: #13838
      Differential Revision: https://phabricator.haskell.org/D4708
    • Alp Mestanogullari's avatar
      T14732 now passes with the profasm way · c65159dc
      Alp Mestanogullari authored
      Simon PJ recently fixed the problem behind this failure
      so we can now expect this test to pass in all ways again.
      The fixes got introduced in the following commits:
      Test Plan: T14732 (profasm way)
      Reviewers: bgamari, RyanGlScott, simonpj
      Reviewed By: RyanGlScott, simonpj
      Subscribers: simonpj, RyanGlScott, rwbarton, thomie, carter
      GHC Trac Issues: #15163
      Differential Revision: https://phabricator.haskell.org/D4725
    • Simon Jakobi's avatar
    • Simon Jakobi's avatar
      Remove incorrect comment · 8fe99c74
      Simon Jakobi authored
      Moving fingerprintByteString to GHC.Fingerprint would require
      adding a dependency on bytestring to base.
    • AntC's avatar
      Improve the documentation of lexically scoped type variables · 2ea93a7d
      AntC authored
      Section 10.16 in the Users Guide. Also reviewed mentions/links from
      other sections: none need revision.
      Fixes #15146.
    • Alp Mestanogullari's avatar
      Update repository sub-dir for ghc-heap in ghc-heap.cabal.in · bd429dc6
      Alp Mestanogullari authored
      Reviewers: bgamari
      Reviewed By: bgamari
      Subscribers: rwbarton, thomie, carter
      Differential Revision: https://phabricator.haskell.org/D4735
    • Peter Trommler's avatar
      Fix validate for GHCi without TABLES_NEXT_TO_CODE · bdfc85b8
      Peter Trommler authored
      Suppress warning about unused match.
      Fixes #15187
      Reviewers: bgamari, simonmar, erikd, hvr
      Reviewed By: bgamari, simonmar
      Subscribers: rwbarton, thomie, carter
      Differential Revision: https://phabricator.haskell.org/D4741
    • Guillaume GARDET's avatar
      llvm-targets: Add versioned ARM targets · e4003b6d
      Guillaume GARDET authored
      Namely armv6l-unknown-linux-gnueabihf and
    • Ömer Sinan Ağacan's avatar
    • Ömer Sinan Ağacan's avatar
      Handle TREC_CHUNK in printClosure · 929bbe4f
      Ömer Sinan Ağacan authored
  2. 29 May, 2018 10 commits
  3. 28 May, 2018 3 commits
    • Tamar Christina's avatar
      Clean up Windows testsuite failures · 60fb2b21
      Tamar Christina authored
      Another round and attempt at getting these down to 0.
      We really should re-enable the CI and not wait for those cloud based ones.
      I've disabled the backpack tests on windows as they are too broad, they test
      as much the shell as they do the compiler.
      The perf tests have been too long to track down. but the numbers are horrible
      but I don't see them getting fixed so just have to accept them.
      T9293 has new windows specific output because a Dyn way only flag was added.
      This will of course not work on non-Dyn way builds.
      Test Plan: ./validate
      Reviewers: bgamari, hvr, simonmar
      Reviewed By: bgamari
      Subscribers: rwbarton, thomie, carter
      GHC Trac Issues: #15107
      Differential Revision: https://phabricator.haskell.org/D4668
    • Tamar Christina's avatar
      Fix 32 bit windows build · 4778cba1
      Tamar Christina authored
      Fix a number of issues that have broken the 32 bit build.
      This makes it build again.
      Test Plan: ./validate
      Reviewers: hvr, goldfire, bgamari, erikd, simonmar
      Reviewed By: bgamari
      Subscribers: rwbarton, thomie, carter
      Differential Revision: https://phabricator.haskell.org/D4691
    • Ömer Sinan Ağacan's avatar
      Update GHC.Stats docs · a5446c45
      Ömer Sinan Ağacan authored
      Make it clear that max_live_bytes is updated after a major GC whereas
      live_bytes is updated after all GCs (including minor collections) and
      considers data in uncollected generations as live.
      Reviewers: bgamari, simonmar, hvr
      Reviewed By: bgamari
      Subscribers: rwbarton, thomie, carter
      Differential Revision: https://phabricator.haskell.org/D4734
  4. 27 May, 2018 1 commit
  5. 26 May, 2018 5 commits
  6. 25 May, 2018 3 commits
    • Simon Peyton Jones's avatar
    • Simon Marlow's avatar
      isDllName: use Opt_ExternalDynamicRefs, not WayDyn · c618732e
      Simon Marlow authored
      This should have been part of D4477, but got missed.
    • Simon Marlow's avatar
      Add -fghci-leak-check to check for space leaks · 5b6ef59f
      Simon Marlow authored
      (re-applying this patch now that D4659 is committed)
      Space leaks in GHCi emerge from time to time and tend to come back again
      after they get fixed. This is an attempt to limit regressions by
      * adding a reliable detection for some classes of space leaks in GHCi
      * turning on leak checking for all GHCi tests in the test suite, so that
        we'll notice if the leak appears again.
      The idea for detecting space leaks is quite simple:
      * find some data that we expect to be GC'd later, make a weak pointer to it
      * when we expect the data to be dead, do a `performGC` and then check
        the status of the weak pointer.
      It would be nice to apply this trick to lots of things in GHC,
      e.g. ensuring that HsSyn is not retained after the desugarer, or
      ensuring that CoreSyn from the previous simplifier pass is not retained.
      Test Plan: validate
      Reviewers: bgamari, simonpj, erikd, niteria
      Subscribers: thomie, carter
      GHC Trac Issues: #15111
  7. 24 May, 2018 4 commits
    • Ryan Scott's avatar
      Minor typos · 5ca623a5
      Ryan Scott authored
    • Ryan Scott's avatar
      Clean up the conflicting data family instances error message · 979f085c
      Ryan Scott authored
      The way we were pretty-printing conflicting data family
      instances in an error message was far from ideal:
      1. If a data type had no constructors, it would print an equals sign
         with nothing to the right of it.
      2. It would try to print GADTs using Haskell98 syntax.
      3. It eta-reduced away some type variables from the LHS.
      This patch addresses these three issues:
      1. We no longer print constructors at all in this error message.
         There's really no reason to do so in the first place, since
         duplicate data family instances always conflict, regardless of
         their constructors.
      2. Since we no longer print constructors, we no longer have to
         worry about whether we're using GADT or Haskell98 syntax.
      3. I've put in a fix to ensure that type variables are no longer
         eta-reduced away from the LHS.
      Test Plan: make test TEST=T14179
      Reviewers: goldfire, bgamari
      Reviewed By: bgamari
      Subscribers: rwbarton, thomie, carter
      GHC Trac Issues: #14179
      Differential Revision: https://phabricator.haskell.org/D4711
    • Ryan Scott's avatar
      Check for mismatched class methods during typechecking · 1879d9d2
      Ryan Scott authored
      Template Haskell provides a wormhole through which you can
      sneak methods that don't belong to a class into an instance for that
      class, bypassing the renamer's validity checks. The solution adopted
      here is to mirror the treatment for associated type family instances,
      which have an additional check in the typechecker which catch
      mismatched associated type families that were snuck through using
      Template Haskell. I've put a similar check for class methods into
      Test Plan: make test TEST=T12387
      Reviewers: bgamari, simonpj
      Reviewed By: bgamari, simonpj
      Subscribers: simonpj, rwbarton, thomie, carter
      GHC Trac Issues: #12387
      Differential Revision: https://phabricator.haskell.org/D4710
    • Ben Gamari's avatar
      testsuite: Bump OS X performance numbers · 49691c4f
      Ben Gamari authored
      Sadly I can't easily determine the cause of T13701's regression since the tree
      was broken.
  8. 23 May, 2018 1 commit
    • Ben Gamari's avatar
      Disable the SRT offset optimisation on MachO platforms · bf10456e
      Ben Gamari authored
      Unfortunately, this optimisation is infeasible on MachO platforms (e.g.
      Darwin) due to an object format limitation. Specifically, linking fails
      with errors of the form:
           error: unsupported relocation with subtraction expression, symbol
           '_integerzmgmp_GHCziIntegerziType_quotInteger_closure' can not be
           undefined in a subtraction expression
      Apparently MachO does not permit relocations' subtraction expressions to
      refer to undefined symbols. As far as I can tell this means that it is
      essentially impossible to express an offset between symbols living in
      different compilation units. This means that we lively can't use this
      optimisation on MachO platforms.
      Test Plan: Validate on Darwin
      Reviewers: simonmar, erikd
      Subscribers: rwbarton, thomie, carter, angerman
      GHC Trac Issues: #15169
      Differential Revision: https://phabricator.haskell.org/D4715