[Git][ghc/ghc][wip/backports] 15 commits: hadrian: Refactor gmp arguments
Ben Gamari
gitlab at gitlab.haskell.org
Thu May 14 16:59:08 UTC 2020
Ben Gamari pushed to branch wip/backports at Glasgow Haskell Compiler / GHC
Commits:
a077ea75 by Ben Gamari at 2020-05-14T12:58:58-04:00
hadrian: Refactor gmp arguments
Move the gmp configuration to its own binding.
- - - - -
6e1bfe5e by Ben Gamari at 2020-05-14T12:59:01-04:00
hadrian: Tell Cabal about integer-gmp library location
- - - - -
ff430471 by Ben Gamari at 2020-05-14T12:59:01-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.
- - - - -
cca97fa0 by Ben Gamari at 2020-05-14T12:59:01-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.
- - - - -
f5d32432 by Ben Gamari at 2020-05-14T12:59:01-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.
- - - - -
9e57f3ef by Ben Gamari at 2020-05-14T12:59:01-04:00
nonmoving: Optimise the write barrier
(cherry picked from commit a636eadac1f30bae37aeb6526f94893293f098b8)
- - - - -
f8776330 by Ömer Sinan Ağacan at 2020-05-14T12:59:01-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)
- - - - -
ee13fe28 by Simon Peyton Jones at 2020-05-14T12:59:01-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)
- - - - -
b0fd1e2b by Simon Peyton Jones at 2020-05-14T12:59:01-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)
- - - - -
f3f98a26 by Sylvain Henry at 2020-05-14T12:59:01-04:00
Rts: show errno on failure (#18033)
(cherry picked from commit 4875d419ba066e479f7ac07f8b39ebe10c855859)
- - - - -
249683ab by Simon Peyton Jones at 2020-05-14T12:59:01-04:00
Major improvements to the specialiser
This patch is joint work of Alexis King and Simon PJ. It does some
significant refactoring of the type-class specialiser. Main highlights:
* We can specialise functions with types like
f :: Eq a => a -> Ord b => b => blah
where the classes aren't all at the front (#16473). Here we can
correctly specialise 'f' based on a call like
f @Int @Bool dEqInt x dOrdBool
This change really happened in an earlier patch
commit 2d0cf6252957b8980d89481ecd0b79891da4b14b
Author: Sandy Maguire <sandy at sandymaguire.me>
Date: Thu May 16 12:12:10 2019 -0400
work that this new patch builds directly on that work, and refactors
it a bit.
* We can specialise functions with implicit parameters (#17930)
g :: (?foo :: Bool, Show a) => a -> String
Previously we could not, but now they behave just like a non-class
argument as in 'f' above.
* We can specialise under-saturated calls, where some (but not all of
the dictionary arguments are provided (#17966). For example, we can
specialise the above 'f' based on a call
map (f @Int dEqInt) xs
even though we don't (and can't) give Ord dictionary.
This may sound exotic, but #17966 is a program from the wild, and
showed significant perf loss for functions like f, if you need
saturation of all dictionaries.
* We fix a buglet in which a floated dictionary had a bogus demand
(#17810), by using zapIdDemandInfo in the NonRec case of specBind.
* A tiny side benefit: we can drop dead arguments to specialised
functions; see Note [Drop dead args from specialisations]
* Fixed a bug in deciding what dictionaries are "interesting"; see
Note [Keep the old dictionaries interesting]
This is all achieved by by building on Sandy Macguire's work in
defining SpecArg, which mkCallUDs uses to describe the arguments of
the call. Main changes:
* Main work is in specHeader, which marched down the [InBndr] from the
function definition and the [SpecArg] from the call site, together.
* specCalls no longer has an arity check; the entire mechanism now
handles unders-saturated calls fine.
* mkCallUDs decides on an argument-by-argument basis whether to
specialise a particular dictionary argument; this is new.
See mk_spec_arg in mkCallUDs.
It looks as if there are many more lines of code, but I think that
all the extra lines are comments!
(cherry picked from commit 7052d7c7ce3418db9e66ad6ff31e80b2a2c724bb)
- - - - -
2cfa4cba by Ryan Scott at 2020-05-14T12:59:01-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)
- - - - -
99e2054b by Adam Gundry at 2020-05-14T12:59:01-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)
- - - - -
bd3b58b2 by Ben Gamari at 2020-05-14T12:59:01-04:00
Ensure that printMinimalImports closes handle
Fixes #18166.
(cherry picked from commit 5afc160dee7142c96a842037fb64bee1429ad9ec)
- - - - -
98ea4b70 by Ben Gamari at 2020-05-14T12:59:01-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)
- - - - -
30 changed files:
- compiler/basicTypes/RdrName.hs
- compiler/coreSyn/CoreSubst.hs
- compiler/coreSyn/CoreUnfold.hs
- compiler/deSugar/DsBinds.hs
- compiler/rename/RnNames.hs
- compiler/specialise/Specialise.hs
- compiler/typecheck/TcExpr.hs
- compiler/typecheck/TcHsType.hs
- compiler/typecheck/TcSplice.hs
- compiler/utils/FastString.hs
- hadrian/src/Settings/Packages.hs
- rts/Updates.h
- rts/linker/PEi386.c
- rts/posix/itimer/Pthread.c
- rts/sm/BlockAlloc.c
- rts/sm/Evac.c
- rts/sm/NonMoving.c
- rts/sm/NonMovingMark.c
- rts/sm/NonMovingScav.c
- rts/sm/Storage.c
- + testsuite/tests/overloadedrecflds/should_fail/T17965.hs
- + testsuite/tests/overloadedrecflds/should_fail/T17965.stderr
- testsuite/tests/overloadedrecflds/should_fail/all.T
- + testsuite/tests/partial-sigs/should_compile/T18008.hs
- + testsuite/tests/partial-sigs/should_compile/T18008.stderr
- testsuite/tests/partial-sigs/should_compile/all.T
- testsuite/tests/perf/compiler/T16473.stdout
- testsuite/tests/simplCore/should_compile/Makefile
- + testsuite/tests/simplCore/should_compile/T17810.hs
- + testsuite/tests/simplCore/should_compile/T17810a.hs
The diff was not included because it is too large.
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/c54556ec1a6864b620d7eafcc10a7f55ac0c69b1...98ea4b70f1122b264399e004cfab00904cb7720c
--
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/c54556ec1a6864b620d7eafcc10a7f55ac0c69b1...98ea4b70f1122b264399e004cfab00904cb7720c
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/20200514/fa9792da/attachment-0001.html>
More information about the ghc-commits
mailing list