- Jul 04, 2019
-
-
Ben Gamari authored
-
- Jul 03, 2019
-
-
Commit cef80c0b debuted a breaking change to `template-haskell`, so in order to guard against it properly with CPP, we need to bump the `template-haskell` version number accordingly.
-
Previously we used the deb9-debug job which used the `validate` build flavour which disabled `BUILD_SPHINX_PDF`. Fix this. Fixes #16890.
-
This adds support for constructing vector types from Float#, Double# etc and performing arithmetic operations on them Cleaned-Up-By:Ben Gamari <ben@well-typed.com>
-
- Jul 02, 2019
-
-
-
-
-
-
-
-
As such the internal linker will fail for them. The alternative would be to implement them as stubs in the linker and have them barf when called. > Not all operations are supported by all target processors. If a particular operation cannot be implemented on the target processor, a warning is generated and a call an external function is generated. The external function carries the same name as the built-in version, with an additional suffix ‘_n’ where n is the size of the data type. (https://gcc.gnu.org/onlinedocs/gcc/_005f_005fsync-Builtins.html)
-
-
This adds lookup logic for _GLOBAL_OFFSET_TABLE_ as well as relocation logic for R_ARM_BASE_PREL and R_ARM_GOT_BREL which the gnu toolchain (gas, gcc, ...) prefers to produce. Apparently recent llvm toolchains will produce those as well.
-
- Jun 28, 2019
-
-
Ben Gamari authored
I'm not entirely sure we are careful about ensuring this; this is a last-ditch check.
-
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: -
-
-
- Jun 27, 2019
-
-
-
-
-
-
-
-
It is important that `heapCensus` and `LdvCensusForDead` traverse the same areas. `heapCensus` increases the `not_used` counter which tracks how many closures are live but haven't been used yet. `LdvCensusForDead` increases the `void_total` counter which tracks how many dead closures there are. The `LAG` is then calculated by substracting the `void_total` from `not_used` and so it is essential that `not_used >= void_total`. This fact is checked by quite a few assertions. However, if a program has low maximum residency but allocates a lot in the nursery then these assertions were failing (see #16753 and #15903) because `LdvCensusForDead` was observing dead closures from the nursery which totalled more than the `not_used`. The same closures were not counted by `heapCensus`. Therefore, it seems that the correct fix is to make `LdvCensusForDead` agree with `heapCensus` and not traverse the nursery for dead closures. Fixes #16100 #16753 #15903 #8982
-
It is possible that void_total is exactly equal to not_used and the other assertions for this check for <= rather than <.
-
This implements the correct fix for #11627 by skipping over the slop (which is zeroed) rather than adding special case logic for LARGE ARR_WORDS which runs the risk of not performing a correct census by ignoring any subsequent blocks. This approach implements similar logic to that in Sanity.c
-
- Jun 26, 2019
-
-
Ben Gamari authored
-
Ben Gamari authored
This allows us to run (but ignore the result of) fragile testcases. Hopefully this should allow us to more easily spot when a fragile test becomes un-fragile.
-
Ben Gamari authored
-
Ben Gamari authored
This is the same as T5611 but with an unsafe call to sleep.
-
Ben Gamari authored
The original issue, #5611, was concerned with safe calls. However, the test inexplicably used an unsafe call. Fix this.
-
Siddharth authored
-
Ben Gamari authored
The test seems to have been missing the name of its script and didn't build with HEAD. How it made it through CI is beyond me.
-
-
This commit partly reverts e69619e9 commit by reintroducing Sf_SafeInferred SafeHaskellMode. We preserve whether module was declared or inferred Safe. When declared-Safe module imports inferred-Safe, we warn. This inferred status is volatile, often enough it's a happy coincidence, something which cannot be relied upon. However, explicitly Safe or Trustworthy packages won't accidentally become Unsafe. Updates haddock submodule.
-
Metric Increase: haddock.Cabal -
-
-
Sleep to avoid non-determinism due to Darwin's poor mtime resolution. Fixes #16855.
-
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.
-
