- Jul 21, 2019
-
-
Ben Gamari authored
* 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
-
Ben Gamari authored
-
- Jul 20, 2019
-
-
Ben Gamari authored
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.
-
Ben Gamari authored
-
Ben Gamari authored
-
Ben Gamari authored
-
- Jul 15, 2019
-
-
Ben Gamari authored
-
- Jul 13, 2019
-
-
Ben Gamari authored
This will hopefully become release 0.10.8.3.
-
- Jul 05, 2019
-
-
Ben Gamari authored
-
- Jul 04, 2019
-
-
Ben Gamari authored
-
- Jul 01, 2019
-
-
See Trac #15072, Trac #16349, Trac #16350 (cherry picked from commit 14586f5d)
-
Ben Gamari authored
This is the initial commit of a utility that I have been using to compare the user-facing interfaces exposed by GHC across releases
-
- Jun 30, 2019
-
-
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 11bac115)
-
Sylvain Henry authored
(cherry picked from commit 4ec233ec)
-
Sylvain Henry authored
(cherry picked from commit 90e0ab7d)
-
(cherry picked from commit d35cec7a)
-
(cherry picked from commit ef6d9a50)
-
- Jun 27, 2019
-
-
Ben Gamari authored
-
Ben Gamari authored
Sleep to avoid non-determinism due to Darwin's poor mtime resolution. Fixes #16855. (cherry picked from commit b90437d8)
-
- Jun 26, 2019
-
-
Ben Gamari authored
(cherry picked from commit 3acdc9a8)
-
Ben Gamari authored
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 2a960c3a)
-
Ben Gamari authored
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 4ae71eba)
-
Ben Gamari authored
The debugging involved in finding #16846 wouldn't have been necessary had the consistentCafInfo check been enabled. However, :wq (cherry picked from commit cd753410)
-
Ben Gamari authored
(cherry picked from commit 1faf4982)
-
Ben Gamari authored
(cherry picked from commit 4c2127c4)
-
Ben Gamari authored
Metric Increase: haddock.Cabal (cherry picked from commit 5c3f2080)
-
- Jun 25, 2019
-
-
(cherry picked from commit 581cbc28)
-
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 71aca77c)
-
Ben Gamari authored
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 cd177b44)
-
Ben Gamari authored
(cherry picked from commit 652b83be)
-
Ben Gamari authored
(cherry picked from commit 22743f72)
-
Ben Gamari authored
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 abee907f)
-
Richard Eisenberg authored
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 392210bf)
-
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 f320f3b2)
-
- Jun 24, 2019
-
-
Ben Gamari authored
We only started allowing constraints in kinds in 6cce36f8, which is not present in 8.8.
-
Ömer Sinan Ağacan authored
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 9d58554f)
-
Ryan Scott authored
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 25ee60cd)
-
Ben Gamari authored
Fixes #16689. (cherry picked from commit 29ec33cd)
-
`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 fc6b23be)
-
(cherry picked from commit ca721193)
-