- Apr 30, 2019
-
-
Travis Whitaker authored
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 fixesd issue #15449.
-
- Apr 09, 2019
-
-
Hopefully fixes Windows Hadrian build.
-
GHC now works out-of-the-box (i.e. without any wrapper script) by assuming that @bin@ and @lib@ directories sit next to each other. In particular, its RUNPATH uses $ORIGIN-based relative path to find the libraries. However, to be good citizens we want to support the case where @bin@ and @lib@ directories (respectively BINDIR and LIBDIR) don't sit next to each other or are renamed. To do that the install script simply creates GHC specific @bin@ and @lib@ siblings directories into: LIBDIR/ghc-VERSION/{bin,lib} Then it installs wrapper scripts into BINDIR that call the appropriate programs into LIBDIR/ghc-VERSION/bin/. The issue fixed by this patch is that libraries were not installed into LIBDIR/ghc-VERSION/lib but directly into LIBDIR. -
-
-
Fixes #16052 When the offset in `setByteArray#` is statically known, we can provide better alignment guarantees then just 1 byte. Also, memset can now do 64-bit wide sets. The current memset intrinsic is not optimal however and can be improved for the case when we know that we deal with (baseAddress at known alignment) + offset For instance, on 64-bit `setByteArray# s 1# 23# 0#` given that bytearray is 8 bytes aligned could be unrolled into `movb, movw, movl, movq, movq`; but currently it is `movb x23` since alignment of 1 is all we can embed into MO_Memset op.
-
As noted in #16309 this somehow went undocumented.
-
- Apr 08, 2019
-
-
Currently, the `hpc` submodule is pinned against the `wip/final-mfp` branch, not against `master`. This pins it back against `master`.
-
We're might be about to switch to generating it in Hadrian/Make. This reformat makes it easier to programmingmatically generate and end up with the exact same thing, which is good for diffing to ensure no regressions. I had this as part of !712, but given the difficulty of satisfying CI, I figured I should break things up even further.
-
-
These tests use unboxed tuples, which GHCi doesn't support
-
Previously, `singleConstructor` didn't handle singleton `COMPLETE` sets of a single pattern synonym, resulting in incomplete pattern warnings in #15753. This is fixed by making `singleConstructor` (now named `singleMatchConstructor`) query `allCompleteMatches`, necessarily making it effectful. As a result, most of this patch is concerned with threading the side-effect through to `singleMatchConstructor`. Unfortunately, this is not enough to completely fix the original reproduction from #15753 and #15884, which are related to function applications in pattern guards being translated too conservatively.
-
-
-
Was broken via #16389 yet strangely it has started passing despite the fact that the suggested root cause has not changed.
-
-
We are currently ignoring options set in the hiDir field of hsc_dflags when looking for interface files while compiling in OneShot mode. This is inconsistent with the behaviour of other directory redirecting fields (such as objectDir or hieDir). It is also inconsistent with the behaviour of compilation in CompManager mode (a.k.a `ghc --make`) which looks for interface files in the directory set in hidir flag. This changes Finder.hs so that we use the value of hiDir while looking for interface in OneShot mode.
-
GHC has an optimization for allocating arrays when the size is statically known -- it'll generate the code allocating and initializing the array inline (instead of a call to a procedure from `rts/PrimOps.cmm`). However, the generated code uses a loop to do the initialization. Since we already check that the requested size is small (we check against `maxInlineAllocSize`), we can generate faster straightline code instead. This brings about 15% improvement for `newSmallArray#` in my testing and slightly simplifies the code in GHC. Signed-off-by:Michal Terepeta <michal.terepeta@gmail.com>
-
- Apr 07, 2019
-
-
Previously, -W(all-)missed-specs was created with 'NoReason', so no information about the flag was printed along with the warning. Now, -Wall-missed-specs is listed as the Reason if it was set, otherwise -Wmissed-specs is listed as the reason.
-
- Apr 04, 2019
-
-
This program, from #13971, currently has a rather confusing error message: ```hs class C a where type T a :: k type T a = Int ``` ``` • Kind mis-match on LHS of default declaration for ‘T’ • In the default type instance declaration for ‘T’ In the class declaration for ‘C’ ``` It's not at all obvious why GHC is complaining about the LHS until you realize that the default, when printed with `-fprint-explicit-kinds`, is actually `type T @{k} @* a = Int`. That is to say, the kind of `a` is being instantiated to `Type`, whereas it ought to be a kind variable. The primary thrust of this patch is to weak the error message to make this connection more obvious: ``` • Illegal argument ‘*’ in: ‘type T @{k} @* a = Int’ The arguments to ‘T’ must all be type variables • In the default type instance declaration for ‘T’ In the class declaration for ‘C’ ``` Along the way, I performed some code cleanup suggested by @rae in ghc/ghc#13971 (comment 191287). Before, we were creating a substitution from the default declaration's type variables to the type family tycon's type variables by way of `tcMatchTys`. But this is overkill, since we already know (from the aforementioned validity checking) that all the arguments in a default declaration must be type variables anyway. Therefore, creating the substitution is as simple as using `zipTvSubst`. I took the opportunity to perform this refactoring while I was in town. Fixes #13971. -
This fixes #16514: Xmm6-15 was restored based off rax instead of rsp. The code was introduced in the fix for #14619.
-
-
A simple oversight. Fixes #16527.
-
This patch corrects two simple oversights that led to #16518: 1. `HsUtils.typeToLHsType` was taking visibility into account in the `TyConApp` case, but not the `AppTy` case. I've factored out the visibility-related logic into its own `go_app` function and now invoke `go_app` from both the `TyConApp` and `AppTy` cases. 2. `Type.fun_kind_arg_flags` did not properly split kinds with nested `forall`s, such as `(forall k. k -> Type) -> (forall k. k -> Type)`. This was simply because `fun_kind_arg_flags`'s `FunTy` case always bailed out and assumed all subsequent arguments were `Required`, which clearly isn't the case for nested `forall`s. I tweaked the `FunTy` case to recur on the result kind.
-
-
- Apr 03, 2019
-
-
Ben Gamari authored
-
Ben Gamari authored
Fixes #16445.
-
Issues #16289 and #15713 are proof that the pattern match checker did an unsound job of estimating the value set abstraction corresponding to the uncovered set. The reason is that the fix from #11303 introducing `NLit` was incomplete: The `LitCon` case desugared to `Var` rather than `LitVar`, which would have done the necessary case splitting analogous to the `ConVar` case. This patch rectifies that by introducing the fresh unification variable in `LitCon` in value abstraction position rather than pattern postition, recording a constraint equating it to the constructor expression rather than the literal. Fixes #16289 and #15713.
-
This fixes #16440, where the build system incorrectly concluded that the `.subsections_via_symbols` assembler directive was supported on a Linux system. This was caused by the fact that gcc was invoked with `-flto`; when so-configured gcc does not call the assembler but rather simply serialises its AST for compilation during the final link. This is described in Note [autoconf assembler checks and -flto].
-
The law as it is currently written is meaningless, because nowhere have we defined the implementation of 'ap'. The reader of the Control.Monad documentation is provided with only a type signature, > ap :: Monad m => m (a -> b) -> m a -> m b an informal description, > In many situations, the liftM operations can be replaced by uses of > ap, which promotes function application. and a relationship between 'ap' and the 'liftM' functions > return f `ap` x1 `ap` ... `ap` xn > is equivalent to > liftMn f x1 x2 ... xn Without knowing how 'ap' is defined, a law involving 'ap' cannot provide any guidance for how to write a lawful Monad instance, nor can we conclude anything from the law. I suspect that a reader equipped with the understanding that 'ap' was defined prior to the invention of the Applicative class could deduce that 'ap' must be defined in terms of (>>=), but nowhere as far as I can tell have we written this down explicitly for readers without the benefit of historical context. If the law is meant to express a relationship among (<*>), (>>=), and 'return', it seems that it is better off making this statement directly, sidestepping 'ap' altogether.
-
-
-
-
-
-
-
`substBndr` should rename bindings which shadow existing ids. However while it was renaming the bindings it was not adding proper substitutions for renamed bindings. Instead of adding a substitution of the form `old -> new` for renamed bindings it mistakenly added `old -> old` if no replacement had taken place while adding none if `old` had been renamed. As a byproduct this should improve performance, as we no longer add useless substitutions for unshadowed bindings.
-
- Apr 02, 2019
-
-
