- Jan 04, 2016
-
-
Ben Gamari authored
-
Ben Gamari authored
This ends up being important since there is a subtle difference between two CmmUnwinds and one in the presence of the (-1) offset applied to frame information for blocks with info tables. This is because the offset will only be applied to the first CmmUnwind within a block, even if the two nodes apply to the same address.
-
Ben Gamari authored
-
Ben Gamari authored
We now wrap the set of unwinding points within a block in a newtype to mark the fact that they must be sorted by the order that the labels occur in the block. Moreover, we fix an oversight in the previous design where unwind information would be duplicated while propagating unwinding information from predecessor blocks.
-
Ben Gamari authored
-
Ben Gamari authored
Otherwise we might end up with a reference to a block that was eliminated during flow control. Ideally we would just ensure that these unwindings are dropped along with the block itself.
-
- Jan 03, 2016
-
-
Ben Gamari authored
-
Ben Gamari authored
-
- Jan 02, 2016
-
-
Ben Gamari authored
-
Ben Gamari authored
-
Ben Gamari authored
This actually just gives us the *ability* to produce unwind information. The unwind information itself will be implemented next.
-
Ben Gamari authored
Fixes #11337.
-
Ben Gamari authored
-
Ben Gamari authored
Previously we can only use unwind information at the beginning of a block since we otherwise have no label to apply it to. This, of course, isn't nearly expressive enough to properly encode unwinding for general programs. For this reason, we want to be able to include unwind information at arbitrary points within a block. This is a first step in this direction, ensuring that all unwind nodes We accomplish this by making `CmmUnwind` carry a label, which the NCG will emit into the block and which the Dwarf generator can refer to in the unwind tables it produces.
-
Ben Gamari authored
-
If a procedure has an info table we should also assume that its first block does lest it will not get the necessary offset to ensure that C-debugging tools find valid debug information. This was manifested as backtrace acquisition entering an infinite loop while attempting to unwind `stg_forceIO`, which had invalid call frame information on account this bug. Test Plan: Validate Reviewers: scpmw, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1532
-
Ben Gamari authored
The interfaces to {save,load}ThreadState were quite messy due to the need to pass in local registers (produced with draws from a unique supply) since they were used from both FCode and UniqSM. This, however, is entirely unnecessary as we already have an abstraction to capture this effect: MonadUnique. Use it.
-
- Jan 01, 2016
-
-
Alan Zimmerman authored
In T10689a.hs, the fragment data instance Sing (z :: [a]) = z ~ '[] => SNil | forall (m :: a) (n :: [a]). z ~ (:) m n => SCons (Sing m) (Sing n) ends up with the AnnTilde annotations for the two tildes not attached to the final AST. This patch moves the AnnTilde to the right place. Closes #11321
-
Simon Peyton Jones authored
runRW# isn't inlined until CorePrep, so it's good to expose its strictness. Moreover, if we don't we can get obscure failures in coreToStg; see Note [runRW arg] in CorePrep. This fixes Trac #11291, and makes DfltProb1 compile with -O always in order to expose it more vigorously
-
Herbert Valerio Riedel authored
This refactoring exploits the fact that since AMP, in most cases, `instance MonadPlus` can be automatically derived from the respective `Alternative` instance. This is because `MonadPlus`'s default method implementations are fully defined in terms of `Alternative(empty, (<>))`.
-
- Dec 31, 2015
-
-
Herbert Valerio Riedel authored
As we're requiring GHC >= 7.10 now, the conditional handling introduced in 9e133b9d for addressing #8182 can be made unconditional, and thus simplify the build-system a little bit.
-
Herbert Valerio Riedel authored
Starting with GHC 7.10 and base-4.8, `Monad` implies `Applicative`, which allows to simplify some definitions to exploit the superclass relationship. This a first refactoring to that end.
-
Herbert Valerio Riedel authored
Since GHC 8.1/8.2 only needs to be bootstrap-able by GHC 7.10 and GHC 8.0 (and GHC 8.2), we can now finally drop all that pre-AMP compatibility CPP-mess for good! Reviewers: austin, goldfire, bgamari Subscribers: goldfire, thomie, erikd Differential Revision: https://phabricator.haskell.org/D1724
-
Herbert Valerio Riedel authored
Quoting the POSIX standard for the `-D` C compiler flag: -D name[=value] Define name as if by a C-language #define directive. If no `=value` is given, a value of 1 shall be used. [...] Removing this explicit `=1` definition from `-D` flags which are used to define boolean macro constants makes the CLI invocation a bit more idiomatic and reduces visual noise in debugging output (flags containing `=`s are additionally put in single-quotes by GHC)
-
Herbert Valerio Riedel authored
Using `YES`/`NO` causes all sorts of problems as CPP doesn't work on symbolic tokens but rather on scalar values. A use like #if __GLASGOW_HASKELL_TH__==YES {-# LANGUAGE TemplateHaskell #-} #endif doesn't do what one may naively expect, and neither does #if __GLASGOW_HASKELL_TH__ {-# LANGUAGE TemplateHaskell #-} #endif *unless* `YES` happens to evaluate to a non-zero scalar. `__GLASGOW_HASKELL_TH__ was originally introduced via D396 / #9734. Fixes #11322 Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D1723
-
Herbert Valerio Riedel authored
In 3549c952 a `include/ghcversions.h` include file was introduced which defines `__GLASGOW_HASKELL__` as well. So there's no need to define it twice.
-
Simon Peyton Jones authored
-
Simon Peyton Jones authored
This fixes Trac #11290, by being sligthtly cleverer about finding what expressions are bottom. Actually this might have minor other side benefits.
-
Alan Zimmerman authored
- Export unicodeAnn from GHC - unicodeAnn for Annlarrowtail was wrong - Use actual source for a CImport SourceText
-
- Dec 30, 2015
-
-
When there is an uncovered vector of length 0 (which in turn means that it represents a guard failure) print "(incomplete guards)" instead of an empty list of non-covered vectors. Test Plan: validate Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1717 GHC Trac Issues: #11245
-
Gabor Greif authored
-
Richard Eisenberg authored
Summary: In the fallthrough case when doing a subsumption case, we need to deeply instantiate to remove any buried foralls in the "actual" type. Once this validates, please feel free to commit it; I may not have the chance to do this on Tuesday. Back in full action on Wed. Test Plan: ./validate, typecheck/should_compiler/T11305 Reviewers: austin, bgamari, hvr Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1715 GHC Trac Issues: #11305
-
- Dec 29, 2015
-
-
Introduce negative patterns for literals. In addition to storing term constraints for literals (checked at the end by the term oracle), also check eagerly, using negative patterns. This means generation of smaller sets (covered, uncovered, and divergent), instead of generating big sets and pruning afterwards. Test Plan: validate Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1716 GHC Trac Issues: #11303
-
Ben Gamari authored
-
Edward Z. Yang authored
Working on some code using the GHC API, I found these functions were useful and wished they were exported. This commit exports them. Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: hvr, thomie Differential Revision: https://phabricator.haskell.org/D1710
-
This fixes a `find_tycon` panic when constructing a record pattern synonym when `DisambiguateRecordFields` (turned on by `RecordWildCards`) is enabled. The handling of record wild cards in such constructions isn't completely satisfactory, but doing better will require the `Parent` type to be more informative, as I'll explain on #11228. Test Plan: New test patsyn/should_compile/T11283.hs Reviewers: mpickering, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1695 GHC Trac Issues: #11283
-
- Dec 28, 2015
-
-
Herbert Valerio Riedel authored
In order to simplify the task, the version munging logic has been radically simplified: Previously, in cases where the version contained dates as version components, the build-system would munge the version of the stage1 ghc package before registering the `ghc` package. However, this hack was already questionable at the time of its introduction (c.f. 7b45c46c). Simplifying the build-systems by avoiding such hacks may also help the shaking-up-ghc effort. So now we simply munge directly via the `.cabal` files, which gives a simpler picture, as now every stage is munged the same. Munging is only active when the first patch-level version component is a date. So stable snapshots and release candidates are unaffacted (as those have the date in the second patch-level version component) Reviewers: simonmar, bgamari, austin, thomie, ezyang Reviewed By: bgamari, thomie, ezyang Differential Revision: https://phabricator.haskell.org/D1673
-
- Dec 27, 2015
-
-
Edward Z. Yang authored
The shadowing and default behavior (in the absence of -hide-all-packages) prefers packages that come from "later" package databases. So for example if tmp1.d and tmp2.d both expose p-1.0, then ghc -package-db tmp1.d -package-db tmp2.d brings the p-1.0 from tmp2.d into scope (and if they have the same IPID, tmp2.d shadows tmp1.d). HOWEVER, -package flags do NOT respect this behavior. ghc -package-db tmp1.d -package-db tmp2.d -package p-1.0 this will force the p-1.0 from tmp1.d to be exposed! This is confusing, so this patch makes the behavior of -package flags consistent. Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1709
-
Introduction of two new flags, for more precise control over the new pattern match checker's behaviour when reasoning about guards. This is supposed to address #11195 (and maybe more performance bugs related to the NP-Hardness of coverage checking). Expected behaviour: * When `-ffull-guard-reasoning` is on, run the new pattern match checker in its full power * When `-ffull-guard-reasoning` is off (the default), for every match, check a metric to see whether pattern match checking for it has high probability of being non performant (at the the moment we check whether the number of guards is over 20 but I would like to use a more precise measure in the future). If the probability is high: - Oversimplify the guards (less expressive but more performant) and run the checker, and - Issue a warning about the simplification that happened. A new flag `-Wtoo-many-guards/-Wno-too-many-guards` suppresses the warning about the simplification (useful when combined with -Werror). Test Plan: validate Reviewers: goldfire, austin, hvr, bgamari Reviewed By: bgamari Subscribers: mpickering, thomie Differential Revision: https://phabricator.haskell.org/D1676 GHC Trac Issues: #11195
-
Edward Z. Yang authored
Signed-off-by:
Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: VAlidate Reviewers: austin, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1703
-