Skip to content
Snippets Groups Projects
  1. Jan 08, 2024
  2. Jan 07, 2024
  3. Jan 05, 2024
    • Krzysztof Gogolewski's avatar
      VoidRep-related refactor · 90ea574e
      Krzysztof Gogolewski authored and Marge Bot's avatar Marge Bot committed
      * In GHC.StgToByteCode, replace bcIdPrimId with idPrimRep,
        bcIdArgRep with idArgRep, atomPrimRep with stgArgRep1.
        All of them were duplicates.
      * In GHC.Stg.Unarise, we were converting a PrimRep to a Type and back to
        PrimRep. Remove the calls to primRepToType and typePrimRep1 which cancel out.
      * In GHC.STG.Lint, GHC.StgToCmm, GHC.Types.RepType we were filtering out
        VoidRep from the result of typePrimRep. But typePrimRep never returns
        VoidRep - remove the filtering.
      90ea574e
    • Krzysztof Gogolewski's avatar
      Fix VoidRep handling in ghci debugger · 67dbcc0a
      Krzysztof Gogolewski authored and Marge Bot's avatar Marge Bot committed
      'go' inside extractSubTerms was giving a bad result given a VoidRep,
      attempting to round towards the next multiple of 0.
      I don't understand much about the debugger but the code should be better
      than it was.
      
      Fixes #24306
      67dbcc0a
  4. Jan 04, 2024
  5. Jan 01, 2024
  6. Dec 31, 2023
  7. Dec 29, 2023
  8. Dec 25, 2023
  9. Dec 24, 2023
  10. Dec 23, 2023
  11. Dec 21, 2023
    • Matthew Pickering's avatar
      hadrian: Build all executables in bin/ folder · f7e21fab
      Matthew Pickering authored
      In the end the bindist creation logic copies them all into the bin
      folder. There is no benefit to building a specific few binaries in the
      lib/bin folder anymore.
      
      This also removes the ad-hoc logic to copy the touchy and unlit
      executables from stage0 into stage1. It takes <1s to build so we might
      as well just build it.
      f7e21fab
  12. Dec 20, 2023
    • Vladislav Zavialov's avatar
      docs: Fix link to 051-ghc-base-libraries.rst · f4b53538
      Vladislav Zavialov authored and Marge Bot's avatar Marge Bot committed
      The proposal is no longer available at the previous URL.
      f4b53538
    • Ben Gamari's avatar
      Fix thunk update ordering · 9a52ae46
      Ben Gamari authored and Marge Bot's avatar Marge Bot committed
      Previously we attempted to ensure soundness of concurrent thunk update
      by synchronizing on the access of the thunk's info table pointer field.
      This was believed to be sufficient since the indirectee (which may
      expose a closure allocated by another core) would not be examined
      until the info table pointer update is complete.
      
      However, it turns out that this can result in data races in the presence
      of multiple threads racing a update a single thunk. For instance,
      consider this interleaving under the old scheme:
      
                  Thread A                             Thread B
                  ---------                            ---------
          t=0     Enter t
            1     Push update frame
            2     Begin evaluation
      
            4     Pause thread
            5     t.indirectee=tso
            6     Release t.info=BLACKHOLE
      
            7     ... (e.g. GC)
      
            8     Resume thread
            9     Finish evaluation
            10    Relaxed t.indirectee=x
      
            11                                         Load t.info
            12                                         Acquire fence
            13                                         Inspect t.indirectee
      
            14    Release t.info=BLACKHOLE
      
      Here Thread A enters thunk `t` but is soon paused, resulting in `t`
      being lazily blackholed at t=6. Then, at t=10 Thread A finishes
      evaluation and updates `t.indirectee` with a relaxed store.
      
      Meanwhile, Thread B enters the blackhole. Under the old scheme this
      would introduce an acquire-fence but this would only synchronize with
      Thread A at t=6. Consequently, the result of the evaluation, `x`, is not
      visible to Thread B, introducing a data race.
      
      We fix this by treating the `indirectee` field as we do all other
      mutable fields. This means we must always access this field with
      acquire-loads and release-stores.
      
      See #23185.
      9a52ae46
  13. Dec 15, 2023
  14. Dec 14, 2023
  15. Dec 13, 2023
Loading