| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
It looks like this was an incomplete cherry-pick.
|
|
|
|
|
|
|
|
|
|
| |
* Use show! in source tarball job. Since we aren't actually building
anything in this job `show` won't
work.
* Fix Docker image name
* Make `version` file contain only version string
|
| |
|
|
|
|
|
| |
As fromFlag is partial. The only case where we used fromFlag is when
determining whether to strip libraries; we now assume that we shouldn't.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
This will hopefully become release 0.10.8.3.
|
|\ |
|
| | |
|
| |
| |
| |
| |
| |
| | |
See Trac #15072, Trac #16349, Trac #16350
(cherry picked from commit 14586f5d737ec5dc828633267b50dcf0d47e1696)
|
| |
| |
| |
| |
| | |
This is the initial commit of a utility that I have been using to
compare the user-facing interfaces exposed by GHC across releases
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Here the following changes are introduced:
- A read barrier machine op is added to Cmm.
- The order in which a closure's fields are read and written is changed.
- Memory barriers are added to RTS code to ensure correctness on
out-or-order machines with weak memory ordering.
Cmm has a new CallishMachOp called MO_ReadBarrier. On weak memory machines, this
is lowered to an instruction that ensures memory reads that occur after said
instruction in program order are not performed before reads coming before said
instruction in program order. On machines with strong memory ordering properties
(e.g. X86, SPARC in TSO mode) no such instruction is necessary, so
MO_ReadBarrier is simply erased. However, such an instruction is necessary on
weakly ordered machines, e.g. ARM and PowerPC.
Weam memory ordering has consequences for how closures are observed and mutated.
For example, consider a closure that needs to be updated to an indirection. In
order for the indirection to be safe for concurrent observers to enter, said
observers must read the indirection's info table before they read the
indirectee. Furthermore, the entering observer makes assumptions about the
closure based on its info table contents, e.g. an INFO_TYPE of IND imples the
closure has an indirectee pointer that is safe to follow.
When a closure is updated with an indirection, both its info table and its
indirectee must be written. With weak memory ordering, these two writes can be
arbitrarily reordered, and perhaps even interleaved with other threads' reads
and writes (in the absence of memory barrier instructions). Consider this
example of a bad reordering:
- An updater writes to a closure's info table (INFO_TYPE is now IND).
- A concurrent observer branches upon reading the closure's INFO_TYPE as IND.
- A concurrent observer reads the closure's indirectee and enters it. (!!!)
- An updater writes the closure's indirectee.
Here the update to the indirectee comes too late and the concurrent observer has
jumped off into the abyss. Speculative execution can also cause us issues,
consider:
- An observer is about to case on a value in closure's info table.
- The observer speculatively reads one or more of closure's fields.
- An updater writes to closure's info table.
- The observer takes a branch based on the new info table value, but with the
old closure fields!
- The updater writes to the closure's other fields, but its too late.
Because of these effects, reads and writes to a closure's info table must be
ordered carefully with respect to reads and writes to the closure's other
fields, and memory barriers must be placed to ensure that reads and writes occur
in program order. Specifically, updates to a closure must follow the following
pattern:
- Update the closure's (non-info table) fields.
- Write barrier.
- Update the closure's info table.
Observing a closure's fields must follow the following pattern:
- Read the closure's info pointer.
- Read barrier.
- Read the closure's (non-info table) fields.
This patch updates RTS code to obey this pattern. This should fix long-standing
SMP bugs on ARM (specifically newer aarch64 microarchitectures supporting
out-of-order execution) and PowerPC. This fixes issue #15449.
Co-Authored-By: Ben Gamari <ben@well-typed.com>
(cherry picked from commit 11bac11545b19a63f5cec3c5bbd5c3f9a7dae0b2)
|
| |
| |
| |
| | |
(cherry picked from commit 4ec233ecfc7f061c19d0c5ef98ad05719b1161e7)
|
| |
| |
| |
| | |
(cherry picked from commit 90e0ab7d80d88463df97bc3514fc89d2ab9fcfca)
|
| |
| |
| |
| | |
(cherry picked from commit d35cec7a9c07a0fc3b40e45d64e5794c3567a523)
|
| |
| |
| |
| | |
(cherry picked from commit ef6d9a50db115e296d2d9bec3e94c7369f1d504c)
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
Sleep to avoid non-determinism due to Darwin's poor mtime resolution.
Fixes #16855.
(cherry picked from commit b90437d8b5c2727450cf45b12fd65cc87a8ab80e)
|
| |
| |
| |
| | |
(cherry picked from commit 3acdc9a8844a5f9bddf27379b3e74c2bb94bff5f)
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When we revert a CAF we must reset the STATIC_LINK field lest the GC
might ignore the CAF (e.g. as it carries the STATIC_FLAG_LIST flag) and
will consequently overlook references to object code that we are trying
to unload. This would result in the reachable object code being
unloaded. See Note [CAF lists] and Note [STATIC_LINK fields].
This fixes #16842.
Idea-due-to: Phuong Trinh <lolotp@fb.com>
(cherry picked from commit 2a960c3a04afcfcdb25a13e9a6e65c94c22a169f)
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Previously, as described in Note [Primop wrappers], `hasNoBinding` would
return False in the case of `PrimOpId`s. This would result in eta
expansion of unsaturated primop applications during CorePrep. Not only
did this expansion result in unnecessary allocations, but it also meant
lead to rather nasty inconsistencies between the CAFfy-ness
determinations made by TidyPgm and CorePrep.
This fixes #16846.
(cherry picked from commit 4ae71eba8c1f680f3163fa27fd83cc5a5214770a)
|
| |
| |
| |
| |
| |
| |
| | |
The debugging involved in finding #16846 wouldn't have been necessary
had the consistentCafInfo check been enabled. However, :wq
(cherry picked from commit cd753410da64bc1c2b1e8a9dc0331e96f4990004)
|
| |
| |
| |
| | |
(cherry picked from commit 1faf4982e26dc89d5e9d68810e0d764596587fdd)
|
| |
| |
| |
| | |
(cherry picked from commit 4c2127c4837d7e2588399c06b56b45b2d4c2f9b0)
|
| |
| |
| |
| |
| |
| |
| | |
Metric Increase:
haddock.Cabal
(cherry picked from commit 5c3f20801c4149d6a950cfb36c7a841dd32d17e0)
|
| |
| |
| |
| | |
(cherry picked from commit 581cbc28e143a4ed8e7f794ed1618161222a5646)
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
LLVM version numberinf changed recently. Previously, releases were numbered
4.0, 5.0 and 6.0 but with version 7, they dropped the redundant ".0".
Fix requires for Llvm detection and some code.
(cherry picked from commit 71aca77c780dad8496054a06a7fe65704a13a742)
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Previously in the case where GHC was dynamically linked we would load
static objects one-by-one by linking each into its own shared object and
dlopen'ing each in order. However, this meant that the link would fail
in the event that the objects had cyclic symbol dependencies.
Here we fix this by merging each "run" of static objects into a single
shared object and loading this.
Fixes #13786 for the case where GHC is dynamically linked.
(cherry picked from commit cd177b44695382878eca7800fb2493b72b20c1e7)
|
| |
| |
| |
| | |
(cherry picked from commit 652b83be7a13f35deefc778d89fd11c9dd46cfa3)
|
| |
| |
| |
| | |
(cherry picked from commit 22743f728a55e851bd079511df0812a1275d1fee)
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Previously we would hackily evaluate a textual code snippet to compute
actions to disable I/O buffering and flush the stdout/stderr handles.
This broke in a number of ways (#15336, #16563).
Instead we now ship a module (`GHC.GHCi.Helpers`) with `base` containing
the needed actions. We can then easily refer to these via `Orig` names.
(cherry picked from commit abee907f20ec9b8465be6587b3c74df9a1d1b1a6)
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Fixes #16509.
See Note [Levity-polymorphic join points] in ByteCodeGen,
which tells the full story.
This commit also adds some comments and cleans some code
in the byte-code generator, as I was exploring around trying
to understand it.
test case: ghci/scripts/T16509
(cherry picked from commit 392210bf8a27b3604f8642d76c39e391c2d4b5e0)
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We use "touch -r" to set modification timestamps, which leads to precision loss
on Darwin. For example,
before: 2019-02-25 01:11:23.807627350 +0300
after: 2019-02-25 01:11:23.807627000 +0300
^^^
This means we can't trick GHCi into thinking the file hasn't been changed by
restoring its old timestamp, as we cannot faithfully restore all digits.
The solution is to nullify the insignificant digits before the first :load
(cherry picked from commit f320f3b2f2f421af41b8f7588529ed46bbe6ccf3)
|
| |
| |
| |
| |
| | |
We only started allowing constraints in kinds in
6cce36f83aec33d33545e0ef2135894d22dff5ca, which is not present in 8.8.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Not doing this right caused #16608. We now properly trim IdInfos of
DFunIds and PatSyns.
Some further refactoring done by SPJ.
Two regression tests T16608_1 and T16608_2 added.
Fixes #16608
(cherry picked from commit 9d58554f7b19c52896796e8c3b6de20c154a67b2)
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Issue #15862 demonstrated examples of type constructors on which
`TcTypeable.tyConIsTypeable` would return `False`, but the `Typeable`
constraint solver in `ClsInst` (in particular, `doTyConApp`) would
try to generate `Typeable` evidence for anyway, resulting in
disaster. This incongruity was caused by the fact that `doTyConApp`
was using a weaker validity check than `tyConIsTypeable` to determine
if a type constructor warrants `Typeable` evidence or not. The
solution, perhaps unsurprisingly, is to use `tyConIsTypeable` in
`doTyConApp` instead.
To avoid import cycles between `ClsInst` and `TcTypeable`, I factored
out `tyConIsTypeable` into its own module, `TcTypeableValidity`.
Fixes #15862.
(cherry picked from commit 25ee60cdae6ddedaf6b4677c6327c0f31c81073a)
|
| |
| |
| |
| |
| |
| | |
Fixes #16689.
(cherry picked from commit 29ec33cd3ee390e8006a88d34f5ea0ac236663d0)
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
`checkUnload` currently doesn't check the info header of static objects.
Thus, it may free an `ObjectCode` struct wrongly even if there's still a
live static object whose info header lies in a mapped section of that
`ObjectCode`. This fixes the issue by adding an appropriate check.
(cherry picked from commit fc6b23be509e290f8d27775a1c637284a335ed81)
|
| |
| |
| |
| | |
(cherry picked from commit ca721193fc71c065036deecfb9d4274fbfc6850d)
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Unboxed tuples and sums take extra RuntimeRep arguments,
which must be manually passed in a few places.
This was not done in deSugar/Check.
This error was hidden because zipping functions in TyCoRep
ignored lists with mismatching length. This is now fixed;
the lengths are now checked by calling zipEqual.
As suggested in #16565, I moved checking for isTyVar and
isCoVar to zipTyEnv and zipCoEnv.
(cherry picked from commit 69b1633104a43d5654e65f2c05fa6b73775936e2)
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When ghc was built for powerpc32 built failed as:
It's a fallout of commit 3f46cffcc2850e68405a1
("PPC NCG: Refactor stack allocation code") where
word size used to be
II32/II64
and changed to
II8/panic "no width for given number of bytes"
widthFromBytes ((platformWordSize platform) `quot` 8)
The change restores initial behaviour by removing extra division.
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
(cherry picked from commit bb2ee86a4cf47eb56d4b8b4a552537449d492f88)
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
On powerpc32 64-bit comparison code generated dangling
target labels. This caused ghc build failure as:
$ ./configure --target=powerpc-unknown-linux-gnu && make
...
SCCs aren't in reverse dependent order
bad blockId n3U
This happened because condIntCode' in PPC codegen generated
label name but did not place the label into `cmp_lo` code block.
The change adds the `cmp_lo` label into the case of negative
comparison.
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
(cherry picked from commit 973077ac63c79988f2d5f25d13b60dce82f9e8dd)
|
| |
| |
| |
| | |
(cherry picked from commit e87b9f8731460a7d8c0b45507be2d83935683d56)
|
| |
| |
| |
| |
| | |
* Disable in profasm way when GHC is dynamically linked
* Drop -optcxx as fix for #16477 is not present in 8.8
|
| |
| |
| |
| | |
(cherry picked from commit cfd3e0f1cfd16c8f35cae139d2a871a32eb4d2e1)
|
| |
| |
| |
| | |
(cherry picked from commit 41bf4045c5a85651db8ceb631a1b67edec0c1216)
|
| |
| |
| |
| |
| |
| | |
This fixes #16586, see `Note [NOINLINE someNatVal]` for details.
(cherry picked from commit 59f4cb6fb73ade6f9b0bdc85380dfddba93bf14b)
|