1. 15 Mar, 2016 4 commits
    • eir@cis.upenn.edu's avatar
      Fix #11401. · 35d37ff8
      eir@cis.upenn.edu authored
      This commit teaches shortCutReduction about Derived constraints.
      
      [skip ci]
      35d37ff8
    • eir@cis.upenn.edu's avatar
      Fix #11334. · 84c773e1
      eir@cis.upenn.edu authored
      Now we fail when trying to default non-*-kinded kind variables
      with -XNoPolyKinds.
      
      test case: dependent/should_fail/T11334
      
      [skip ci]
      84c773e1
    • eir@cis.upenn.edu's avatar
      Fix #11407. · e9bf7bb5
      eir@cis.upenn.edu authored
      This removes the `defer_me` check that was in checkTauTvUpdate
      and uses only a type family check instead. The old defer_me check
      repeated work done by fast_check in occurCheckExpand.
      
      There is also some error message improvement, necessitated by
      the terrible error message that the test case produced, even when
      it didn't consume all of memory.
      
      test case: dependent/should_fail/T11407
      
      [skip ci]
      e9bf7bb5
    • eir@cis.upenn.edu's avatar
      Move and expand (slightly) TypeApplications docs · 18fbfa39
      eir@cis.upenn.edu authored
      [skip ci]
      18fbfa39
  2. 14 Mar, 2016 2 commits
  3. 13 Mar, 2016 1 commit
  4. 12 Mar, 2016 3 commits
    • Erik de Castro Lopo's avatar
      LlvmCodeGen: Fix generation of malformed LLVM blocks · 92821ec9
      Erik de Castro Lopo authored
      Commit 673efccb uncovered a bug in LLVM code generation that produced
      LLVM code that the LLVM compiler refused to compile:
      
          {
          clpH:
            br label %clpH
          }
      
      This may well be a bug in LLVM itself. The solution is to keep the
      existing entry label and rewrite the function as:
      
          {
          clpH:
            br label %nPV
          nPV:
            br label %nPV
          }
      
      Thanks to Ben Gamari for pointing me in the right direction on this
      one.
      
      Test Plan: Build GHC with BuildFlavour=quick-llvm
      
      Reviewers: hvr, austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1996
      
      GHC Trac Issues: #11649
      92821ec9
    • lukyanov's avatar
      ghci: add message when reusing compiled code #9887 · 41051dd8
      lukyanov authored
      Reviewers: austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1991
      
      GHC Trac Issues: #9887
      41051dd8
    • Ben Gamari's avatar
      Simplify: Make generated names more useful · 4d791b4f
      Ben Gamari authored
      makeTrivial is responsible for concocting names during simplification.
      Previously, however, it would make no attempt to generate a name that
      might be useful to later readers of the resulting Core. Here we add a
      bit of state to SimplEnv: a finite depth stack of binders within which
      we are currently simplifying. We then derive generated binders from this
      context.
      
      See #11676.
      
      Open questions:
        * Is there a better way to accomplish this?
        * Is `maxContextDepth` too large/small?
      
      Test Plan: Validate, look at Core.
      
      Reviewers: austin, simonpj
      
      Reviewed By: simonpj
      
      Subscribers: thomie, simonpj
      
      Differential Revision: https://phabricator.haskell.org/D1970
      
      GHC Trac Issues: #11676
      4d791b4f
  5. 11 Mar, 2016 19 commits
  6. 10 Mar, 2016 1 commit
    • Sergei Trofimovich's avatar
      fix Float/Double unreg cross-compilation · c42cdb7f
      Sergei Trofimovich authored
      Looking at more failures on m68k (Trac #11395)
      I've noticed the arith001 and arith012 test failures.
      (--host=x86_64-linux --target=m68k-linux).
      
      The following example was enough to reproduce a problem:
      
          v :: Float
          v = 43
          main = print v
      
      m68k binaries printed '0.0' instead of '43.0'.
      
      The bug here is how we encode Floats and Double
      as Words with the same binary representation.
      
      Floats:
        Before the patch we just coerced Float to Int.
        That breaks when we cross-compile from
        64-bit LE to 32-bit BE.
      
        The patch fixes conversion by accounting for padding.
        when we extend 32-bit value to 64-bit value (LE and BE
        do it slightly differently).
      
      Doubles:
        Before the patch Doubles were coerced to a pair of Ints
        (not correct as x86_64 can hold Double in one Int) and
        then trucated this pair of Ints to pair of Word32.
      
        The patch fixes conversion by always decomposing in
        Word32 and accounting for host endianness (newly
        introduced hostBE)  and target endianness (wORDS_BIGENDIAN).
      
      I've tested this patch on Double and Float conversion on
          --host=x86_64-linux --target=m68k-linux
      crosscompiler. It fixes 10 tests related to printing Floats
      and Doubles.
      
      Thanks to Bertram Felgenhauer who poined out this probem.
      Signed-off-by: default avatarSergei Trofimovich <siarheit@google.com>
      
      Test Plan: checked some examples manually, fixed 10 tests in test suite
      
      Reviewers: int-e, austin, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1990
      
      GHC Trac Issues: #11395
      c42cdb7f
  7. 09 Mar, 2016 3 commits
  8. 08 Mar, 2016 4 commits
    • Herbert Valerio Riedel's avatar
      template-haskell: define `MonadFail Q` instance · 1c76e168
      Herbert Valerio Riedel authored
      When `MonadFail`is available, this patch makes `MonadFail` a superclass
      of `Quasi`, and `Q` an instance of `MonadFail`.
      
      NB: Since f16ddcee, we need to be able
          to compile `template-haskell` with stage0 compilers that don't provide
          a `MonadFail` class yet. Once we reach GHC 8.3 development we can drop
          the CPP conditionals again.
      
      Addresses #11661
      
      Reviewed By: bgamari, goldfire
      
      Differential Revision: https://phabricator.haskell.org/D1982
      1c76e168
    • Herbert Valerio Riedel's avatar
      template-haskell: remove redundant CPP use · 941b8f5f
      Herbert Valerio Riedel authored
      GHC 8.1's template-haskell package requires base>=4.8 anyway, so
      we can assume Numeric.Natural to be available unconditionally.
      941b8f5f
    • Herbert Valerio Riedel's avatar
      template-haskell: Drop use of Rank2Types/PolymorphicComponents · 1a9734a6
      Herbert Valerio Riedel authored
      As per #6032, `Rank2Types` and `PolymorphicComponents` have been
      deprecated in favour of `RankNTypes`.
      
      also update `other-extensions` in template-haskell.cabal flag to
      reflect reality.
      1a9734a6
    • Sergei Trofimovich's avatar
      Split external symbol prototypes (EF_) (Trac #11395) · 90e1e160
      Sergei Trofimovich authored
      Before the patch both Cmm and C symbols were declared
      with 'EF_' macro:
      
          #define EF_(f)    extern StgFunPtr f()
      
      but for Cmm symbols we know exact prototypes.
      
      The patch splits there prototypes in to:
      
          #define EFF_(f)   void f() /* See Note [External function prototypes] */
          #define EF_(f)    StgFunPtr f(void)
      
      Cmm functions are 'EF_' (External Functions),
      C functions are 'EFF_' (External Foreign Functions).
      
      While at it changed external C function prototype
      to return 'void' to workaround ghc bug on m68k.
      Described in detail in Trac #11395.
      
      This makes simple tests work on m68k-linux target!
      
      Thanks to Michael Karcher for awesome analysis
      happening in Trac #11395.
      Signed-off-by: default avatarSergei Trofimovich <siarheit@google.com>
      
      Test Plan: ran "hello world" on m68k successfully
      
      Reviewers: simonmar, austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1975
      
      GHC Trac Issues: #11395
      90e1e160
  9. 07 Mar, 2016 3 commits