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. 21 Jul, 2019 2 commits
  2. 20 Jul, 2019 4 commits
  3. 15 Jul, 2019 1 commit
  4. 13 Jul, 2019 1 commit
  5. 05 Jul, 2019 1 commit
  6. 04 Jul, 2019 1 commit
  7. 01 Jul, 2019 2 commits
  8. 30 Jun, 2019 5 commits
    • Travis Whitaker's avatar
      Correct closure observation, construction, and mutation on weak memory machines. · cc2f96d2
      Travis Whitaker authored
      
      
      Here the following changes are introduced:
          - A read barrier machine op is added to Cmm.
          - The order in which a closure's fields are read and written is changed.
          - Memory barriers are added to RTS code to ensure correctness on
            out-or-order machines with weak memory ordering.
      
      Cmm has a new CallishMachOp called MO_ReadBarrier. On weak memory machines, this
      is lowered to an instruction that ensures memory reads that occur after said
      instruction in program order are not performed before reads coming before said
      instruction in program order. On machines with strong memory ordering properties
      (e.g. X86, SPARC in TSO mode) no such instruction is necessary, so
      MO_ReadBarrier is simply erased. However, such an instruction is necessary on
      weakly ordered machines, e.g. ARM and PowerPC.
      
      Weam memory ordering has consequences for how closures are observed and mutated.
      For example, consider a closure that needs to be updated to an indirection. In
      order for the indirection to be safe for concurrent observers to enter, said
      observers must read the indirection's info table before they read the
      indirectee. Furthermore, the entering observer makes assumptions about the
      closure based on its info table contents, e.g. an INFO_TYPE of IND imples the
      closure has an indirectee pointer that is safe to follow.
      
      When a closure is updated with an indirection, both its info table and its
      indirectee must be written. With weak memory ordering, these two writes can be
      arbitrarily reordered, and perhaps even interleaved with other threads' reads
      and writes (in the absence of memory barrier instructions). Consider this
      example of a bad reordering:
      
      - An updater writes to a closure's info table (INFO_TYPE is now IND).
      - A concurrent observer branches upon reading the closure's INFO_TYPE as IND.
      - A concurrent observer reads the closure's indirectee and enters it. (!!!)
      - An updater writes the closure's indirectee.
      
      Here the update to the indirectee comes too late and the concurrent observer has
      jumped off into the abyss. Speculative execution can also cause us issues,
      consider:
      
      - An observer is about to case on a value in closure's info table.
      - The observer speculatively reads one or more of closure's fields.
      - An updater writes to closure's info table.
      - The observer takes a branch based on the new info table value, but with the
        old closure fields!
      - The updater writes to the closure's other fields, but its too late.
      
      Because of these effects, reads and writes to a closure's info table must be
      ordered carefully with respect to reads and writes to the closure's other
      fields, and memory barriers must be placed to ensure that reads and writes occur
      in program order. Specifically, updates to a closure must follow the following
      pattern:
      
      - Update the closure's (non-info table) fields.
      - Write barrier.
      - Update the closure's info table.
      
      Observing a closure's fields must follow the following pattern:
      
      - Read the closure's info pointer.
      - Read barrier.
      - Read the closure's (non-info table) fields.
      
      This patch updates RTS code to obey this pattern. This should fix long-standing
      SMP bugs on ARM (specifically newer aarch64 microarchitectures supporting
      out-of-order execution) and PowerPC. This fixes issue #15449.
      Co-Authored-By: Ben Gamari's avatarBen Gamari <ben@well-typed.com>
      (cherry picked from commit 11bac115)
      cc2f96d2
    • Sylvain Henry's avatar
      Fix GCC warnings with __clear_cache builtin (#16867) · 8706cebc
      Sylvain Henry authored
      (cherry picked from commit 4ec233ec)
      8706cebc
    • Sylvain Henry's avatar
      Fix Happy deps for Stack (#16825) · 6e255b62
      Sylvain Henry authored
      (cherry picked from commit 90e0ab7d)
      6e255b62
    • Fraser Tweedale's avatar
      getExecutablePath: get path from sysctl on FreeBSD · 59fdb0f5
      Fraser Tweedale authored
      (cherry picked from commit d35cec7a)
      59fdb0f5
    • Artem Pelenitsyn's avatar
      typo in the docs for DynFlags.hs · 406a1383
      Artem Pelenitsyn authored
      (cherry picked from commit ef6d9a50)
      406a1383
  9. 27 Jun, 2019 2 commits
  10. 26 Jun, 2019 7 commits
  11. 25 Jun, 2019 8 commits
    • Erik de Castro Lopo's avatar
      Add MonadFail instance for ParserM · 73598b14
      Erik de Castro Lopo authored
      (cherry picked from commit 581cbc28)
      73598b14
    • Erik de Castro Lopo's avatar
      Fixes for LLVM 7 · 8dd80930
      Erik de Castro Lopo authored
      LLVM version numberinf changed recently. Previously, releases were numbered
      4.0, 5.0 and 6.0 but with version 7, they dropped the redundant ".0".
      
      Fix requires for Llvm detection and some code.
      
      (cherry picked from commit 71aca77c)
      8dd80930
    • Ben Gamari's avatar
      ghci: Load static objects in batches · 921c18de
      Ben Gamari authored
      Previously in the case where GHC was dynamically linked we would load
      static objects one-by-one by linking each into its own shared object and
      dlopen'ing each in order. However, this meant that the link would fail
      in the event that the objects had cyclic symbol dependencies.
      
      Here we fix this by merging each "run" of static objects into a single
      shared object and loading this.
      
      Fixes #13786 for the case where GHC is dynamically linked.
      
      (cherry picked from commit cd177b44)
      921c18de
    • Ben Gamari's avatar
      testsuite: Test for #13786 · bbf5dfa6
      Ben Gamari authored
      (cherry picked from commit 652b83be)
      bbf5dfa6
    • Ben Gamari's avatar
      testsuite: Add test for #16563 · 1c06d9e7
      Ben Gamari authored
      (cherry picked from commit 22743f72)
      1c06d9e7
    • Ben Gamari's avatar
      ghci: Don't rely on resolution of System.IO to base module · ce029689
      Ben Gamari authored
      Previously we would hackily evaluate a textual code snippet to compute
      actions to disable I/O buffering and flush the stdout/stderr handles.
      This broke in a number of ways (#15336, #16563).
      
      Instead we now ship a module (`GHC.GHCi.Helpers`) with `base` containing
      the needed actions. We can then easily refer to these via `Orig` names.
      
      (cherry picked from commit abee907f)
      ce029689
    • Richard Eisenberg's avatar
      GHCi support for levity-polymorphic join points · 7ffe0681
      Richard Eisenberg authored
      Fixes #16509.
      
      See Note [Levity-polymorphic join points] in ByteCodeGen,
      which tells the full story.
      
      This commit also adds some comments and cleans some code
      in the byte-code generator, as I was exploring around trying
      to understand it.
      
      test case: ghci/scripts/T16509
      
      (cherry picked from commit 392210bf8a27b3604f8642d76c39e391c2d4b5e0)
      7ffe0681
    • Vladislav Zavialov's avatar
      Fix the ghci063 test on Darwin (Trac #16201) · f9da172c
      Vladislav Zavialov authored
      We use "touch -r" to set modification timestamps, which leads to precision loss
      on Darwin. For example,
      
         before: 2019-02-25 01:11:23.807627350 +0300
         after:  2019-02-25 01:11:23.807627000 +0300
                                           ^^^
      This means we can't trick GHCi into thinking the file hasn't been changed by
      restoring its old timestamp, as we cannot faithfully restore all digits.
      
      The solution is to nullify the insignificant digits before the first :load
      
      (cherry picked from commit f320f3b2)
      f9da172c
  12. 24 Jun, 2019 6 commits