1. 13 Sep, 2018 4 commits
  2. 12 Sep, 2018 5 commits
  3. 11 Sep, 2018 3 commits
  4. 10 Sep, 2018 2 commits
  5. 08 Sep, 2018 2 commits
  6. 07 Sep, 2018 4 commits
  7. 06 Sep, 2018 2 commits
    • Ömer Sinan Ağacan's avatar
      Fix a race between GC threads in concurrent scavenging · c6fbac6a
      Ömer Sinan Ağacan authored
      While debugging #15285 I realized that free block lists (free_list in
      BlockAlloc.c) get corrupted when multiple scavenge threads allocate and
      release blocks concurrently. Here's a picture of one such race:
          Thread 2 (Thread 32573.32601):
          #0  check_tail
              (bd=0x940d40 <stg_TSO_info>) at rts/sm/BlockAlloc.c:860
          #1  0x0000000000928ef7 in checkFreeListSanity
              () at rts/sm/BlockAlloc.c:896
          #2  0x0000000000928979 in freeGroup
              (p=0x7e998ce02880) at rts/sm/BlockAlloc.c:721
          #3  0x0000000000928a17 in freeChain
              (bd=0x7e998ce02880) at rts/sm/BlockAlloc.c:738
          #4  0x0000000000926911 in freeChain_sync
              (bd=0x7e998ce02880) at rts/sm/GCUtils.c:80
          #5  0x0000000000934720 in scavenge_capability_mut_lists
              (cap=0x1acae80) at rts/sm/Scav.c:1665
          #6  0x000000000092b411 in gcWorkerThread
              (cap=0x1acae80) at rts/sm/GC.c:1157
          #7  0x000000000090be9a in yieldCapability
              (pCap=0x7f9994e69e20, task=0x7e9984000b70, gcAllowed=true) at rts/Capability.c:861
          #8  0x0000000000906120 in scheduleYield
              (pcap=0x7f9994e69e50, task=0x7e9984000b70) at rts/Schedule.c:673
          #9  0x0000000000905500 in schedule
              (initialCapability=0x1acae80, task=0x7e9984000b70) at rts/Schedule.c:293
          #10 0x0000000000908d4f in scheduleWorker
              (cap=0x1acae80, task=0x7e9984000b70) at rts/Schedule.c:2554
          #11 0x000000000091a30a in workerStart
              (task=0x7e9984000b70) at rts/Task.c:444
          #12 0x00007f99937fa6db in start_thread
              (arg=0x7f9994e6a700) at pthread_create.c:463
          #13 0x000061654d59f88f in clone
              () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
          Thread 1 (Thread 32573.32573):
          #0  checkFreeListSanity
              () at rts/sm/BlockAlloc.c:887
          #1  0x0000000000928979 in freeGroup
              (p=0x7e998d303540) at rts/sm/BlockAlloc.c:721
          #2  0x0000000000926f23 in todo_block_full
              (size=513, ws=0x1aa8ce0) at rts/sm/GCUtils.c:264
          #3  0x00000000009583b9 in alloc_for_copy
              (size=513, gen_no=0) at rts/sm/Evac.c:80
          #4  0x000000000095850d in copy_tag_nolock
              (p=0x7e998c675f28, info=0x421d98 <Main_Large_con_info>, src=0x7e998d075d80, size=513,
              gen_no=0, tag=1) at rts/sm/Evac.c:153
          #5  0x0000000000959177 in evacuate
              (p=0x7e998c675f28) at rts/sm/Evac.c:715
          #6  0x0000000000932388 in scavenge_small_bitmap
              (p=0x7e998c675f28, size=1, bitmap=0) at rts/sm/Scav.c:271
          #7  0x0000000000934aaf in scavenge_stack
              (p=0x7e998c675f28, stack_end=0x7e998c676000) at rts/sm/Scav.c:1908
          #8  0x0000000000934295 in scavenge_one
              (p=0x7e998c66e000) at rts/sm/Scav.c:1466
          #9  0x0000000000934662 in scavenge_mutable_list
              (bd=0x7e998d300440, gen=0x1b1d880) at rts/sm/Scav.c:1643
          #10 0x0000000000934700 in scavenge_capability_mut_lists
              (cap=0x1aaa340) at rts/sm/Scav.c:1664
          #11 0x00000000009299b6 in GarbageCollect
              (collect_gen=0, do_heap_census=false, gc_type=2, cap=0x1aaa340, idle_cap=0x1b38aa0)
              at rts/sm/GC.c:378
          #12 0x0000000000907a4a in scheduleDoGC
              (pcap=0x7ffdec5b5310, task=0x1b36650, force_major=false) at rts/Schedule.c:1798
          #13 0x0000000000905de7 in schedule
              (initialCapability=0x1aaa340, task=0x1b36650) at rts/Schedule.c:546
          #14 0x0000000000908bc4 in scheduleWaitThread
              (tso=0x7e998c0067c8, ret=0x0, pcap=0x7ffdec5b5430) at rts/Schedule.c:2537
          #15 0x000000000091b5a0 in rts_evalLazyIO
              (cap=0x7ffdec5b5430, p=0x9c11f0, ret=0x0) at rts/RtsAPI.c:530
          #16 0x000000000091ca56 in hs_main
              (argc=1, argv=0x7ffdec5b5628, main_closure=0x9c11f0, rts_config=...) at rts/RtsMain.c:72
          #17 0x0000000000421ea0 in main
      In particular, dbl_link_onto() which is used to add a freed block to a
      doubly-linked free list is not thread safe and corrupts the list when
      called concurrently.
      Note that thread 1 is to blame here as thread 2 is properly taking the
      spinlock. With this patch we now take the spinlock when freeing a todo
      block in GC, avoiding this race.
      Test Plan:
      - Tried slow validate locally: this patch does not introduce new failures.
      - circleci: https://circleci.com/gh/ghc/ghc-diffs/283 The test got killed
        because it took 5 hours but T7919 (which was previously failing on circleci)
      Reviewers: simonmar, bgamari, erikd
      Reviewed By: simonmar
      Subscribers: rwbarton, carter
      GHC Trac Issues: #15285
      Differential Revision: https://phabricator.haskell.org/D5115
    • Ömer Sinan Ağacan's avatar
      Remove an incorrect assertion in threadPaused: · 16bc7ae8
      Ömer Sinan Ağacan authored
      The assertion is triggered when we have a loop in the program (in which case we
      see the same update frame multiple times in the stack). See #14915 for more
      Reviewers: simonmar, bgamari, erikd
      Reviewed By: simonmar
      Subscribers: rwbarton, carter
      GHC Trac Issues: #14915
      Differential Revision: https://phabricator.haskell.org/D5133
  8. 05 Sep, 2018 7 commits
    • Simon Peyton Jones's avatar
      Preserve specialisations despite CSE · 3addf72a
      Simon Peyton Jones authored
      Trac #15445 showed that, as a result of CSE, a function with an
      automatically generated specialisation RULE could be inlined
      before the RULE had a chance to fire.
      This patch attaches a NOINLINE[2] activation to the Id, during
      CSE, to stop this happening.
      See Note [Delay inlining after CSE]
      ---- Historical note ---
      This patch is simpler and more direct than an earlier
        commit 2110738b
        Author: Simon Peyton Jones <simonpj@microsoft.com>
        Date:   Mon Jul 30 13:43:56 2018 +0100
        Don't inline functions with RULES too early
      We had to revert this patch because it made GHC itself slower.
      Why? It delayed inlining of /all/ functions with RULES, and that was
      very bad in TcFlatten.flatten_ty_con_app
      * It delayed inlining of liftM
      * That delayed the unravelling of the recursion in some dictionary
      * That delayed some eta expansion, leaving
           flatten_ty_con_app = \x y. let <stuff> in \z. blah
      * That allowed the float-out pass to put sguff between
        the \y and \z.
      * And that permanently stopped eta expasion of the function,
        even once <stuff> was simplified.
      -- End of historical note ---
    • Simon Peyton Jones's avatar
      Define activeAfterInitial, activeDuringFinal · 1152a3be
      Simon Peyton Jones authored
      This is pure refactoring, just adding a couple of
      definitions to BasicTypes, and using them.
      Plus some whitespace stuff.
    • Alec Theriault's avatar
      Expose 'moduleToPkgConfAll' from 'PackageState' · e29ac2db
      Alec Theriault authored
      Having direct access to this field is going to enable Haddock to
      compute in batch which modules to load before looking up instances
      of external packages.
      Reviewers: bgamari, monoidal
      Reviewed By: monoidal
      Subscribers: rwbarton, carter
      Differential Revision: https://phabricator.haskell.org/D5100
    • Ben Gamari's avatar
      testsuite: Use bools for booleans, not ints · ecde9546
      Ben Gamari authored
      Summary: Just as it says on the tin.
      Test Plan: Validate
      Reviewers: bgamari, osa1
      Reviewed By: osa1
      Subscribers: osa1, monoidal, rwbarton, thomie, carter
      Differential Revision: https://phabricator.haskell.org/D5010
    • Chaitanya Koparkar's avatar
      base: Add references to Notes for certain special imports · a811d938
      Chaitanya Koparkar authored
      Modules like GHC.Integer, GHC.Natural etc. are special and sometimes
      have to be imported just to resolve build ordering issues. It's useful
      to refer to the appropriate Notes at such import sites.
      Test Plan: Read it.
      Reviewers: RyanGlScott, bgamari, hvr, simonpj
      Reviewed By: RyanGlScott, simonpj
      Subscribers: simonpj, rwbarton, carter
      GHC Trac Issues: #15526
      Differential Revision: https://phabricator.haskell.org/D5092
    • Ben Gamari's avatar
      testsuite: Add test for #15368 · 49d50b2b
      Ben Gamari authored
      Reviewers: bgamari, osa1
      Reviewed By: osa1
      Subscribers: osa1, monoidal, rwbarton, thomie, carter
      GHC Trac Issues: #15368
      Differential Revision: https://phabricator.haskell.org/D4958
    • Ömer Sinan Ağacan's avatar
      Skip eventlog tests in GHCi way · c0e5087d
      Ömer Sinan Ağacan authored
      Summary: (GHCi doesn't generate event logs)
      Test Plan:
      These tests were failing in GHCi way, they're now skipped in GHCi way as GHCi
      doesn't generate eventlogs
      Reviewers: bgamari, simonmar, maoe, alpmestan
      Reviewed By: alpmestan
      Subscribers: rwbarton, carter
      GHC Trac Issues: #15587
      Differential Revision: https://phabricator.haskell.org/D5119
  9. 04 Sep, 2018 5 commits
  10. 03 Sep, 2018 2 commits
  11. 02 Sep, 2018 2 commits
    • Alp Mestanogullari's avatar
      make iToBase62's inner loop stricter in one of its arguments · ed789516
      Alp Mestanogullari authored
      hadrian's support for dynamic ways is currently broken (see hadrian#641 [1]).
      The stage 1 GHCs that hadrian produces end up producing bad code for
      the `iToBase62` function after a few optimisation passes.
      In the case where `quotRem` returns (overflowError, 0),
      GHC isn't careful enough to realise q is _|_ and happily inlines,
      distributes and floats code around until we end up trying to access
      index `minBound :: Int` of an array of 62 chars, as a result of inlining
      the definition of `quotRem` for Ints, in particular the minBound branch [2].
      I will separately look into reproducing the bad transformation on a small
      self-contained example and filling a ticket.
      [1]: https://github.com/snowleopard/hadrian/issues/641
      [2]: https://git.haskell.org/ghc.git/blob/HEAD:/libraries/base/GHC/Real.hs#l366
      Test Plan: fixes hadrian#641
      Reviewers: bgamari, tdammers
      Reviewed By: tdammers
      Subscribers: tdammers, rwbarton, carter
      Differential Revision: https://phabricator.haskell.org/D5106
    • Ryan Scott's avatar
      Reject class instances with type families in kinds · 6dea7c16
      Ryan Scott authored
      GHC doesn't know how to handle type families that appear in
      class instances. Unfortunately, GHC didn't reject instances where
      type families appear in //kinds//, leading to #15515. This is easily
      rectified by calling `checkValidTypePat` on all arguments to a class
      in an instance (and not just the type arguments).
      Test Plan: make test TEST=T15515
      Reviewers: bgamari, goldfire, simonpj
      Reviewed By: simonpj
      Subscribers: simonpj, rwbarton, carter
      GHC Trac Issues: #15515
      Differential Revision: https://phabricator.haskell.org/D5068
  12. 31 Aug, 2018 2 commits
    • Simon Peyton Jones's avatar
      Remove knot-tying bug in TcHsSyn.zonkTyVarOcc · 565ef4cc
      Simon Peyton Jones authored
      There was a subtle knot-tying bug in TcHsSyn.zonkTyVarOcc, revealed
      in Trac #15552.
      I fixed it by
      * Eliminating the short-circuiting optimisation in zonkTyVarOcc,
        instead adding a finite map to get sharing of zonked unification
        See Note [Sharing when zonking to Type] in TcHsSyn
      * On the way I /added/ the short-circuiting optimisation to
        TcMType.zonkTcTyVar, which has no such problem.  This turned
        out (based on non-systematic measurements) to be a modest win.
        See Note [Sharing in zonking] in TcMType
      On the way I renamed some of the functions in TcHsSyn:
      * Ones ending in "X" (like zonkTcTypeToTypeX) take a ZonkEnv
      * Ones that do not end in "x" (like zonkTcTypeToType), don't.
        Instead they whiz up an empty ZonkEnv.
    • Simon Peyton Jones's avatar
      Commets on flatten_args_tc · fda2ea58
      Simon Peyton Jones authored