1. 03 Aug, 2015 10 commits
    • Ben Gamari's avatar
      CmmParse: Don't force alignment in memcpy-ish operations · 64b6733e
      Ben Gamari authored
      This was initially made in 681973c3.
      Here I wanted to enforce that the alignment passed to %memcpy was a
      constant expression, as this is required by LLVM. However, this breaks
      the knot-tying done in `loopDecls`, causing T8131 to hang.
      Here I remove the `seq` and mark T8131 as `expect_broken` in the case
      of the NCG, which doesn't force the alignment in this case.
      Fixes #10664.
    • Gabor Greif's avatar
      Typos in comments [skip ci] · 7ec6ffc4
      Gabor Greif authored
    • thomasw's avatar
      Support wild cards in data/type family instances · d9d2102e
      thomasw authored
      Handle anonymous wild cards in type or data family instance
      declarations like
      unnamed type variables. For instance (pun intented):
          type family F (a :: *) (b :: *) :: *
          type instance F Int _ = Int
      Is now the same as:
          type family F (a :: *) (b :: *) :: *
          type instance F Int x = Int
      Note that unlike wild cards in partial type signatures, no errors (or
      with -XPartialTypeSignatures) are generated for these wild cards, as
      there is
      nothing interesting to report to the user, i.e. the inferred kind.
      Only anonymous wild cards are supported here, named and
      extra-constraints wild
      card are not.
      Test Plan: pass new tests
      Reviewers: goldfire, austin, simonpj, bgamari
      Reviewed By: simonpj, bgamari
      Subscribers: goldfire, thomie
      Differential Revision: https://phabricator.haskell.org/D1092
      GHC Trac Issues: #3699, #10586
    • skvadrik's avatar
      4 reduce/reduce parser conflicts resolved · 697079f1
      skvadrik authored
      As GHC documentation (section 7.4.4, Type operators) says:
      > "There is now some potential ambiguity in import and export lists;
      for example if you write import M( (+) ) do you mean the function (+)
      or the type constructor (+)? The default is the former, but with
      -XExplicitNamespaces (which is implied by -XExplicitTypeOperators) GHC
      allows you to specify the latter by preceding it with the keyword type"
      Turns out this ambiguity causes 4 of 6 reduce/reduce conflicts in GHC
      parser.  All 4 conflicts arise from a single production:
              :  qvar
              |  oqtycon
      Recursive inlining of 'qvar' and 'oqtycon' helps reveal the faulty
              | '(' QVARSYM ')'
              | '(' VARSYM ')'
              | '(' '*'    ')'
              | '(' '-'    ')'
      These productions can either be parsed as variable or type constructor,
      but variable constuctor is always preferred. My patch removes ambiguity
      while preserving the existing behaviour:
        - all unambigous productions are left as-is
        - ambigous productions for variable constuctors are left
        - ambigous productions for type constructors are removed (there's no
          way they could be triggered)
      Updated comment.
      Test Plan: Tested with 'make fasttest'
      Reviewers: austin, simonpj, trofi, bgamari, simonmar
      Reviewed By: trofi, bgamari, simonmar
      Subscribers: thomie, mpickering
      Projects: #ghc
      Differential Revision: https://phabricator.haskell.org/D1111
    • Simon Peyton Jones's avatar
      Test Trac #10134 · 30b32f4c
      Simon Peyton Jones authored
    • Simon Peyton Jones's avatar
      Minor improvement to user guide · d7ced09a
      Simon Peyton Jones authored
      Specify that the type variables for a class/instance decl scope
      over the body even without a 'forall'.
      Provoked by Trac #10722.
    • Simon Peyton Jones's avatar
      Typos in comments · 4d8859cc
      Simon Peyton Jones authored
    • Ben Gamari's avatar
      Fix incorrect stack pointer usage in StgRun() on x86_64 · b38ee89c
      Ben Gamari authored
      The STG_RETURN code from StgCRun.c is incorrect for x86_64 variants
      where the ABI doesn't impose a mandatory red zone for the stack, like on
      Windows or Xen/HaLVM. The current implementation restores the stack
      pointer first, which effectively marks the area with the saved registers
      as reusable. Later, the CPU registers are restored from this "free"
      This ordering happens to work by accident on operating systems that
      strictly adhere to the System V ABI, because any interrupt/signal
      delivery is guaranteed to leave the first 128 bytes past the stack
      pointer untouched (red zone). On other systems this might result in
      corrupted CPU registers if an interruption happens just after restoring
      the stack pointer.
      The red zone is usually only used by small leaf functions to avoid
      updates to the stack pointer and exploiting it doesn't give us any
      advantage in this case.
      Reviewers: austin, rwbarton
      Reviewed By: rwbarton
      Subscribers: thomie, simonmar
      Differential Revision: https://phabricator.haskell.org/D1120
      GHC Trac Issues: #10155
    • Simon Marlow's avatar
      Update parallel submodule, and re-enable warnings · 948e03e5
      Simon Marlow authored
      Test Plan: using remote validate
      Reviewers: austin, hvr, simonpj, bgamari
      Reviewed By: bgamari
      Subscribers: thomie
      Differential Revision: https://phabricator.haskell.org/D1117
    • Michal Terepeta's avatar
      Support MO_U_QuotRem2 in LLVM backend · 92f5385d
      Michal Terepeta authored
      This adds support for MO_U_QuotRem2 in LLVM backend.  Similarly to
      MO_U_Mul2 we use the standard LLVM instructions (in this case 'udiv'
      and 'urem') but do the computation on double the word width (e.g., for
      64-bit we will do them on 128 registers).
      Test Plan: validate
      Reviewers: rwbarton, austin, bgamari
      Reviewed By: bgamari
      Subscribers: thomie
      Differential Revision: https://phabricator.haskell.org/D1100
      GHC Trac Issues: #9430
  2. 02 Aug, 2015 3 commits
    • Gabor Greif's avatar
      Make BranchFlag a new kind · 37227d34
      Gabor Greif authored
      this is resolving an old TODO comment
    • Gabor Greif's avatar
      Typo in comment · d9b618ff
      Gabor Greif authored
    • Alan Zimmerman's avatar
      Replace (SourceText,FastString) with StringLiteral data type · 15dd7007
      Alan Zimmerman authored
      Phab:D907 introduced SourceText for a number of data types, by replacing
      FastString with (SourceText,FastString). Since this has an Outputable
      instance, no warnings are generated when ppr is called on it, but
      unexpected output is generated. See Phab:D1096 for an example of this.
      Replace the (SourceText,FastString) tuples with a new data type,
      data StringLiteral = StringLiteral SourceText FastString
      Update haddock submodule accordingly
      Test Plan: ./validate
      Reviewers: hvr, austin, rwbarton, trofi, bgamari
      Reviewed By: trofi, bgamari
      Subscribers: thomie, trofi, rwbarton, mpickering
      Differential Revision: https://phabricator.haskell.org/D1101
      GHC Trac Issues: #10692
  3. 01 Aug, 2015 1 commit
  4. 31 Jul, 2015 7 commits
  5. 30 Jul, 2015 19 commits