[Git][ghc/ghc][wip/marge_bot_batch_merge_job] 6 commits: rts: Flush eventlog buffers from flushEventLog

Marge Bot gitlab at gitlab.haskell.org
Tue Nov 3 10:49:27 UTC 2020



 Marge Bot pushed to branch wip/marge_bot_batch_merge_job at Glasgow Haskell Compiler / GHC


Commits:
44780e10 by Ben Gamari at 2020-11-03T05:49:14-05:00
rts: Flush eventlog buffers from flushEventLog

As noted in #18043, flushTrace failed flush anything beyond the writer.
This means that a significant amount of data sitting in capability-local
event buffers may never get flushed, despite the users' pleads for us to
flush.

Fix this by making flushEventLog flush all of the event buffers before
flushing the writer.

Fixes #18043.

- - - - -
f9888c86 by Matthew Pickering at 2020-11-03T05:49:15-05:00
Update inlining flags documentation

- - - - -
31974f3c by Sylvain Henry at 2020-11-03T05:49:17-05:00
Linker: reorganize linker related code

Move linker related code into GHC.Linker. Previously it was scattered
into GHC.Unit.State, GHC.Driver.Pipeline, GHC.Runtime.Linker, etc.

Add documentation in GHC.Linker

- - - - -
a333b650 by Alan Zimmerman at 2020-11-03T05:49:17-05:00
Restrict Linear arrow %1 to exactly literal 1 only

This disallows `a %001 -> b`, and makes sure the type literal is
printed from its SourceText so it is clear why.

Closes #18888

- - - - -
e2f46a26 by Sylvain Henry at 2020-11-03T05:49:19-05:00
Hadrian: don't fail if ghc-tarballs dir doesn't exist

- - - - -
d4d5c04f by Sylvain Henry at 2020-11-03T05:49:21-05:00
Constant-folding: don't pass through GHC's Int/Word (fix #11704)

Constant-folding rules for integerToWord/integerToInt were performing
the following coercions at compilation time:

    integerToWord: target's Integer -> ghc's Word -> target's Word
    integerToInt : target's Integer -> ghc's Int -> target's Int

1) It was wrong for cross-compilers when GHC's word size is smaller than
   the target one. This patch avoids passing through GHC's word-sized
   types:

    integerToWord: target's Integer -> ghc's Integer -> target's Word
    integerToInt : target's Integer -> ghc's Integer -> target's Int

2) Additionally we didn't wrap the target word/int literal to make it
   fit into the target's range! This broke the invariant of literals
   only containing values in range.

   The existing code is wrong only with a 64-bit cross-compiling GHC,
   targeting a 32-bit platform, and performing constant folding on a
   literal that doesn't fit in a 32-bit word. If GHC was built with
   DEBUG, the assertion in GHC.Types.Literal.mkLitWord would fail.
   Otherwise the bad transformation would go unnoticed.

- - - - -


30 changed files:

- compiler/GHC.hs
- compiler/GHC/Core.hs
- compiler/GHC/Core/Make.hs
- compiler/GHC/Core/Opt/ConstantFold.hs
- compiler/GHC/Driver/Backpack.hs
- compiler/GHC/Driver/Env.hs
- compiler/GHC/Driver/Main.hs
- compiler/GHC/Driver/Make.hs
- compiler/GHC/Driver/Pipeline.hs
- compiler/GHC/Hs/Type.hs
- compiler/GHC/HsToCore/Foreign/Decl.hs
- compiler/GHC/HsToCore/Usage.hs
- compiler/GHC/Iface/Tidy/StaticPtrTable.hs
- + compiler/GHC/Linker.hs
- + compiler/GHC/Linker/Dynamic.hs
- compiler/GHC/SysTools/ExtraObj.hs → compiler/GHC/Linker/ExtraObj.hs
- compiler/GHC/Runtime/Linker.hs → compiler/GHC/Linker/Loader.hs
- + compiler/GHC/Linker/MacOS.hs
- + compiler/GHC/Linker/Static.hs
- compiler/GHC/Runtime/Linker/Types.hs → compiler/GHC/Linker/Types.hs
- + compiler/GHC/Linker/Unit.hs
- + compiler/GHC/Linker/Windows.hs
- compiler/GHC/Parser/PostProcess.hs
- compiler/GHC/Runtime/Debugger.hs
- compiler/GHC/Runtime/Eval.hs
- compiler/GHC/Runtime/Interpreter.hs
- compiler/GHC/Runtime/Loader.hs
- compiler/GHC/SysTools.hs
- compiler/GHC/SysTools/Tasks.hs
- compiler/GHC/Unit/Finder.hs


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/adea95f6e7f4f369325eef133040517e902c3362...d4d5c04fc59ec24d52ebf778ba59381caec78c62

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/adea95f6e7f4f369325eef133040517e902c3362...d4d5c04fc59ec24d52ebf778ba59381caec78c62
You're receiving this email because of your account on gitlab.haskell.org.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-commits/attachments/20201103/01e41a57/attachment.html>


More information about the ghc-commits mailing list