[Git][ghc/ghc][wip/backports] 24 commits: Note platform-specific Foreign.C.Types in context

Ben Gamari gitlab at gitlab.haskell.org
Mon May 25 00:42:37 UTC 2020



Ben Gamari pushed to branch wip/backports at Glasgow Haskell Compiler / GHC


Commits:
37956be4 by Viktor Dukhovni at 2020-05-21T17:42:48-04:00
Note platform-specific Foreign.C.Types in context

Also fix the markup in the general note at the top of the module.  Haddock
(usability trade-off), does not support multi-line emphasised text.

- - - - -
a16c24b7 by Ben Gamari at 2020-05-24T20:42:31-04:00
rts: Add getCurrentThreadCPUTime helper

(cherry picked from commit cedd6f3041de6abe64dfa3257bec7730a9dced9f)

- - - - -
d1f9d711 by Ben Gamari at 2020-05-24T20:42:31-04:00
rts: Prefer darwin-specific getCurrentThreadCPUTime

macOS Catalina now supports a non-POSIX-compliant version of clock_gettime
which cannot use the clock_gettime codepath.

Fixes #17906.

(cherry picked from commit bb586f894532baf1bcb822afd0df7f9fea198671)

- - - - -
39f3b172 by Ben Gamari at 2020-05-24T20:42:31-04:00
nonmoving-gc: Track time usage of nonmoving marking

(cherry picked from commit ace618cd2294989e783bd453cee88e0e1c0dad77)

- - - - -
35f50728 by Ben Gamari at 2020-05-24T20:42:31-04:00
nonmoving: Eagerly flush all capabilities' update remembered sets

(cherry picked from commit 2fa79119570b358a4db61446396889b8260d7957)

- - - - -
dc26ba87 by Ben Gamari at 2020-05-24T20:42:31-04:00
nonmoving: Explicitly memoize block count

A profile cast doubt on whether the compiler hoisted the bound out the
loop as I would have expected here. It turns out it did but nevertheless
it seems clearer to just do this manually.

- - - - -
ce49860d by Ben Gamari at 2020-05-24T20:42:32-04:00
nonmoving: Clear bitmap after initializing block size

Previously nonmovingInitSegment would clear the bitmap before
initializing the segment's block size. This is broken since
nonmovingClearBitmap looks at the segment's block size to determine how
much bitmap to clear.

- - - - -
1101739a by Ben Gamari at 2020-05-24T20:42:32-04:00
hadrian: Allow libnuma library path to be specified

- - - - -
6e8ede7e by Ben Gamari at 2020-05-24T20:42:32-04:00
rts: Zero block flags with -DZ

Block flags are very useful for determining the state of a block.
However, some block allocator users don't touch them, leading to
misleading values. Ensure that we zero then when zero-on-gc is set. This
is safe and makes the flags more useful during debugging.

- - - - -
185a870e by Ben Gamari at 2020-05-24T20:42:32-04:00
nonmoving: Fix incorrect failed_to_evac value during deadlock gc

Previously we would incorrectly set the failed_to_evac flag if we
evacuated a value due to a deadlock GC. This would cause us to mark more
things as dirty than strictly necessary. It also turned up a nasty but
which I will fix next.

- - - - -
124a40cc by Ben Gamari at 2020-05-24T20:42:32-04:00
nonmoving: Fix handling of dirty objects

Previously we (incorrectly) relied on failed_to_evac to be "precise".
That is, we expected it to only be true if *all* of an object's fields
lived outside of the non-moving heap. However, does not match the
behavior of failed_to_evac, which is true if *any* of the object's
fields weren't promoted (meaning that some others *may* live in the
non-moving heap).

This is problematic as we skip the non-moving write barrier for dirty
objects (which we can only safely do if *all* fields point outside of
the non-moving heap).

Clearly this arises due to a fundamental difference in the behavior
expected of failed_to_evac in the moving and non-moving collector.
e.g., in the moving collector it is always safe to conservatively say
failed_to_evac=true whereas in the non-moving collector the safe value
is false.

This issue went unnoticed as I never wrote down the dirtiness
invariant enforced by the non-moving collector. We now define this
invariant as

    An object being marked as dirty implies that all of its fields are
    on the mark queue (or, equivalently, update remembered set).

To maintain this invariant we teach nonmovingScavengeOne to push the
fields of objects which we fail to evacuate to the update remembered
set. This is a simple and reasonably cheap solution and avoids the
complexity and fragility that other, more strict alternative invariants
would require.

All of this is described in a new Note, Note [Dirty flags in the
non-moving collector] in NonMoving.c.

- - - - -
b23f16d0 by Ben Gamari at 2020-05-24T20:42:32-04:00
nonmoving: Optimise the write barrier

(cherry picked from commit a636eadac1f30bae37aeb6526f94893293f098b8)

- - - - -
d2581e98 by Ömer Sinan Ağacan at 2020-05-24T20:42:32-04:00
FastString: fix eager reading of string ptr in hashStr

This read causes NULL dereferencing when len is 0.

Fixes #17909

In the reproducer in #17909 this bug is triggered as follows:

- SimplOpt.dealWithStringLiteral is called with a single-char string
  ("=" in #17909)

- tailFS gets called on the FastString of the single-char string.

- tailFS checks the length of the string, which is 1, and calls
  mkFastStringByteString on the tail of the ByteString, which is an
  empty ByteString as the original ByteString has only one char.

- ByteString's unsafeUseAsCStringLen returns (NULL, 0) for the empty
  ByteString, which is passed to mkFastStringWith.

- mkFastStringWith gets hash of the NULL pointer via hashStr, which
  fails on empty strings because of this bug.

(cherry picked from commit d15b61608a542f6349b42224140b7d227b88ef4e)

- - - - -
76059e3e by Simon Peyton Jones at 2020-05-24T20:42:32-04:00
Improve error handling for VTA + deferred type errors

This fixes #17792

See Note [VTA for out-of-scope functions] in TcExpr

(cherry picked from commit 335b18bac3c361d243f427b66e67c2c94f5c6494)

- - - - -
a7dd83db by Simon Peyton Jones at 2020-05-24T20:42:32-04:00
Add a missing zonk in tcHsPartialType

I omitted a vital zonk when refactoring tcHsPartialType in
   commit 48fb3482f8cbc8a4b37161021e846105f980eed4
   Author: Simon Peyton Jones <simonpj at microsoft.com>
   Date:   Wed Jun 5 08:55:17 2019 +0100

   Fix typechecking of partial type signatures

This patch fixes it and adds commentary to explain why.

Fixes #18008

(cherry picked from commit 658bda511237593bb80389280d0364180648058d)

- - - - -
e3fcf26d by Sylvain Henry at 2020-05-24T20:42:32-04:00
Rts: show errno on failure (#18033)

(cherry picked from commit 4875d419ba066e479f7ac07f8b39ebe10c855859)

- - - - -
ba788d22 by Ryan Scott at 2020-05-24T20:42:32-04:00
Fix two ASSERT buglets in reifyDataCon

Two `ASSERT`s in `reifyDataCon` were always using `arg_tys`, but
`arg_tys` is not meaningful for GADT constructors. In fact, it's
worse than non-meaningful, since using `arg_tys` when reifying a
GADT constructor can lead to failed `ASSERT`ions, as #17305
demonstrates.

This patch applies the simplest possible fix to the immediate
problem. The `ASSERT`s now use `r_arg_tys` instead of `arg_tys`, as
the former makes sure to give something meaningful for GADT
constructors. This makes the panic go away at the very least. There
is still an underlying issue with the way the internals of
`reifyDataCon` work, as described in
https://gitlab.haskell.org/ghc/ghc/issues/17305#note_227023, but we
leave that as future work, since fixing the underlying issue is
much trickier (see
https://gitlab.haskell.org/ghc/ghc/issues/17305#note_227087).

(cherry picked from commit cfb66d181ac45ce3d934bda3521b94277e6eb683)

- - - - -
25d84fa2 by Adam Gundry at 2020-05-24T20:42:32-04:00
Reject all duplicate declarations involving DuplicateRecordFields (fixes #17965)

This fixes a bug that resulted in some programs being accepted that used the same
identifier as a field label and another declaration, depending on the order they
appeared in the source code.

(cherry picked from commit 0d8c7a6c7c3513089668f49efb0a2dd8b4bbe74a)

- - - - -
646648a9 by Ben Gamari at 2020-05-24T20:42:32-04:00
Ensure that printMinimalImports closes handle

Fixes #18166.

(cherry picked from commit 5afc160dee7142c96a842037fb64bee1429ad9ec)

- - - - -
123c386b by Ben Gamari at 2020-05-24T20:42:32-04:00
rts: Make non-existent linker search path merely a warning

As noted in #18105, previously this resulted in a rather intrusive error
message. This is in contrast to the general expectation that search
paths are merely places to look, not places that must exist.

Fixes #18105.

(cherry picked from commit 24af9f30681444380c25465f555599da563713cb)

- - - - -
06f05573 by Ben Gamari at 2020-05-24T20:42:32-04:00
nonmoving: Optimise log2_ceil

(cherry picked from commit 5f69016115414d0dd921e72f3edcd0b365966141)

- - - - -
dae01c10 by Ben Gamari at 2020-05-24T20:42:32-04:00
rts: Enable tracing of nonmoving heap census with -ln

Previously this was not easily available to the user. Fix this.
Non-moving collection lifecycle events are now reported with -lg.

(cherry picked from commit 7bfe9ac514e18c0b0e24ff55230fe98ec9db894c)

- - - - -
72218602 by Ben Gamari at 2020-05-24T20:42:32-04:00
users guide: Move eventlog documentation users guide

(cherry picked from commit c560dd07f506810eaabae2f582491138aa224819)

- - - - -
79da3ca2 by Ben Gamari at 2020-05-24T20:42:33-04:00
users guide: Add documentation for non-moving GC events

(cherry picked from commit 02543d5ef9bd7a910fc9fece895780583ab9635a)

- - - - -


30 changed files:

- compiler/basicTypes/RdrName.hs
- compiler/rename/RnNames.hs
- compiler/typecheck/TcExpr.hs
- compiler/typecheck/TcHsType.hs
- compiler/typecheck/TcSplice.hs
- compiler/utils/FastString.hs
- configure.ac
- docs/users_guide/conf.py
- docs/users_guide/eventlog-formats.rst
- docs/users_guide/runtime_control.rst
- hadrian/cfg/system.config.in
- hadrian/src/Oracles/Flag.hs
- hadrian/src/Oracles/Setting.hs
- hadrian/src/Settings/Packages.hs
- includes/RtsAPI.h
- includes/rts/EventLogFormat.h
- includes/rts/Time.h
- libraries/base/Foreign/C/Types.hs
- libraries/base/GHC/Stats.hsc
- rts/GetTime.h
- rts/ProfHeap.c
- rts/RtsFlags.c
- rts/Stats.c
- rts/Stats.h
- rts/Updates.h
- rts/linker/PEi386.c
- rts/posix/GetTime.c
- rts/posix/itimer/Pthread.c
- rts/sm/BlockAlloc.c
- rts/sm/Evac.c


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/729922a5276f7a35b4090929acc1c9b07b618f75...79da3ca28d12306e5bc073d2f1b7ba130e12cd99

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/729922a5276f7a35b4090929acc1c9b07b618f75...79da3ca28d12306e5bc073d2f1b7ba130e12cd99
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/20200524/426bcb81/attachment-0001.html>


More information about the ghc-commits mailing list