summaryrefslogtreecommitdiff
path: root/compiler/main
Commit message (Collapse)AuthorAgeFilesLines
* CodeGen: Way to dump cmm only once (#11717)Vladimir Trubilov2016-07-172-12/+23
| | | | | | | | | | | | | | | | | | | | | | | | | The `-ddump-cmm` put all stages of Cmm processing into one output. This patch changes its behavior and adds two more options to make Cmm dumping flexible. - `-ddump-cmm-from-stg` dumps only initial version of Cmm right after STG->Cmm codegen - `-ddump-cmm` dumps the final result of the Cmm pipeline processing - `-ddump-cmm-verbose` dumps intermediate output of each Cmm pipeline step - `-ddump-cmm-proc` and `-ddump-cmm-caf` seems were lost. Now enabled Test Plan: ./validate Reviewers: thomie, simonmar, austin, bgamari Reviewed By: thomie, simonmar Subscribers: simonpj, thomie Differential Revision: https://phabricator.haskell.org/D2393 GHC Trac Issues: #11717
* Log heap profiler samples to event logBen Gamari2016-07-162-2/+3
| | | | | | | | | | | | Test Plan: Try it Reviewers: hvr, simonmar, austin, erikd Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1722 GHC Trac Issues: #11094
* Kill varEnvElts in zonkEnvIdsBartosz Nitka2016-07-051-1/+4
| | | | | | | | | | | | | | | This localizes the nondeterminism that varEnvElts could have introduced, so that it's obvious that it's benign. Test Plan: ./validate Reviewers: simonpj, austin, bgamari Subscribers: thomie, simonmar Differential Revision: https://phabricator.haskell.org/D2390 GHC Trac Issues: #4012
* Tidy up tidyingSimon Peyton Jones2016-07-051-8/+2
| | | | | This is a tiny refactor, replacing an ad-hoc local function (TidyPgm.loookup_aux_id) with a solid global one (tidyVarOcc).
* Use DVarEnv for vectInfoVarBartosz Nitka2016-07-052-20/+15
| | | | | | | | | This makes sure that we don't introduce unnecessary nondeterminism from vectorization. Also updates dph submodule to reflect the change in types. GHC Trac: #4012
* Extra ASSERTs for nameModuleSimon Peyton Jones2016-07-051-1/+2
|
* Document some benign nondeterminismBartosz Nitka2016-07-011-2/+8
|
* Stop the simplifier from removing StaticPtr binds.Facundo Domínguez2016-06-281-7/+3
| | | | | | | | | | | | | | | | | | | | | | | Summary: We have the FloatOut pass create exported ids for floated StaticPtr bindings. The simplifier doesn't try to remove those. This patch also improves on 7fc20b by making a common definition collectStaticPtrSatArgs to test for StaticPtr binds. Fixes #12207. Test Plan: ./validate Reviewers: simonpj, austin, bgamari, simonmar, goldfire Reviewed By: simonpj Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2366 GHC Trac Issues: #12207
* Allow building static libs.Moritz Angermann2016-06-251-0/+2
| | | | | | | | | | | | | | | | | | Summary: Commit 90538d86af579595987826cd893828d6f379f35a, seems to have broken static linking. The introduction of `argFixup` in `runLink` rearranges libs, and considers anything with an `-l` prefix or `.a` suffix a lib, which fails for libs that are just being linked together (e.g. `-o lib.a`). The proposed solution explicitly checks for the existance of the `-o` flag. Reviewers: rwbarton, erikd, Phyx, bgamari, austin Reviewed By: Phyx Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2362
* Fix #10963 and #11975 by adding new cmds to GHCi.Richard Eisenberg2016-06-233-9/+9
| | | | | | See the user's guide entry or the Note [TcRnExprMode] in TcRnDriver. Test cases: ghci/scripts/T{10963,11975}
* Provide Uniquable version of SCCBartosz Nitka2016-06-231-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | We want to remove the `Ord Unique` instance because there's no way to implement it in deterministic way and it's too easy to use by accident. We sometimes compute SCC for datatypes whose Ord instance is implemented in terms of Unique. The Ord constraint on SCC is just an artifact of some internal data structures. We can have an alternative implementation with a data structure that uses Uniquable instead. This does exactly that and I'm pleased that I didn't have to introduce any duplication to do that. Test Plan: ./validate I looked at performance tests and it's a tiny bit better. Reviewers: bgamari, simonmar, ezyang, austin, goldfire Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2359 GHC Trac Issues: #4012
* Give lookupGRE_Name a better APISimon Peyton Jones2016-06-231-2/+1
| | | | | | | | | | lookupGRE_Name should return either zero or one GREs, never several. This is a consequence of INVARIANT 1 on GlobalRdrEnv. So it's better if it returns a Maybe; the panic on multiple results is put in one place, instead of being scattered or ignored. Just refactoring, no change in behaviour
* More typos in comments [skip ci]Gabor Greif2016-06-221-1/+1
|
* Driver: `ghc ../Test` (without file extension) should workThomas Miedema2016-06-181-1/+1
| | | | | | | | Reviewed by: bgamari Differential Revision: https://phabricator.haskell.org/D2331 GHC Trac Issues: #12192
* Abort the build when a Core plugin pass is specified in stage1 compilerÖmer Sinan Ağacan2016-06-171-0/+23
| | | | | | | | | | | | | | | | | | | This also makes the behavior the same with frontend plugin errors -- frontend was failing with an exception (`CmdLineError`) while the simplifier was just ignoring plugins. Now we abort with `CmdLineError` in both cases with a slightly improved error message. Test Plan: - add tests (will add tests once #12197 is implemented) - validate (done) Reviewers: austin, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2334 GHC Trac Issues: #11690
* Major patch to introduce TyConBinderSimon Peyton Jones2016-06-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before this patch, following the TypeInType innovations, each TyCon had two lists: - tyConBinders :: [TyBinder] - tyConTyVars :: [TyVar] They were in 1-1 correspondence and contained overlapping information. More broadly, there were many places where we had to pass around this pair of lists, instead of a single list. This commit tidies all that up, by having just one list of binders in a TyCon: - tyConBinders :: [TyConBinder] The new data types look like this: Var.hs: data TyVarBndr tyvar vis = TvBndr tyvar vis data VisibilityFlag = Visible | Specified | Invisible type TyVarBinder = TyVarBndr TyVar VisibilityFlag TyCon.hs: type TyConBinder = TyVarBndr TyVar TyConBndrVis data TyConBndrVis = NamedTCB VisibilityFlag | AnonTCB TyCoRep.hs: data TyBinder = Named TyVarBinder | Anon Type Note that Var.TyVarBdr has moved from TyCoRep and has been made polymorphic in the tyvar and visiblity fields: type TyVarBinder = TyVarBndr TyVar VisibilityFlag -- Used in ForAllTy type TyConBinder = TyVarBndr TyVar TyConBndrVis -- Used in TyCon type IfaceForAllBndr = TyVarBndr IfaceTvBndr VisibilityFlag type IfaceTyConBinder = TyVarBndr IfaceTvBndr TyConBndrVis -- Ditto, in interface files There are a zillion knock-on changes, but everything arises from these types. It was a bit fiddly to get the module loops to work out right! Some smaller points ~~~~~~~~~~~~~~~~~~~ * Nice new functions TysPrim.mkTemplateKiTyVars TysPrim.mkTemplateTyConBinders which help you make the tyvar binders for dependently-typed TyCons. See comments with their definition. * The change showed up a bug in TcGenGenerics.tc_mkRepTy, where the code was making an assumption about the order of the kind variables in the kind of GHC.Generics.(:.:). I fixed this; see TcGenGenerics.mkComp.
* Re-add FunTy (big patch)Simon Peyton Jones2016-06-151-4/+4
| | | | | | | | | | | | | | | | | | | | | | With TypeInType Richard combined ForAllTy and FunTy, but that was often awkward, and yielded little benefit becuase in practice the two were always treated separately. This patch re-introduces FunTy. Specfically * New type data TyVarBinder = TvBndr TyVar VisibilityFlag This /always/ has a TyVar it. In many places that's just what what we want, so there are /lots/ of TyBinder -> TyVarBinder changes * TyBinder still exists: data TyBinder = Named TyVarBinder | Anon Type * data Type = ForAllTy TyVarBinder Type | FunTy Type Type | .... There are a LOT of knock-on changes, but they are all routine. The Haddock submodule needs to be updated too
* Simplify readProcessEnvWithExitCode + set LANGUAGE=CThomas Miedema2016-06-141-39/+13
| | | | | | | | | | | | | | | | | | `readProcessEnvWithExitCode` was added in 4d4d07704ee78221607a18b8118294b0aea1bac4, to start an external process after making some modifications to the environment. Since then, the `process` library has exposed `readCreateProcessWithExitCode`, which allows for the refactoring we do here. Also change "en" to "C", as suggested in ticket:8825#comment:11. Reviewed by: trofi Differential Revision: https://phabricator.haskell.org/D2332 GHC Trac Issues: #8825
* Use UniqFM for SigOfBartosz Nitka2016-06-131-4/+5
| | | | | | | | | | | | | | | | | | | | | | Summary: The Ord instance for ModuleName is currently implemented in terms of Uniques causing potential determinism problems. I plan to change it to use the actual FastStrings and in preparation for that I'm switching to UniqFM where it's possible (you need *one* Unique per key, and you can't get the keys back), so that the performance doesn't suffer. Test Plan: ./validate Reviewers: simonmar, austin, ezyang, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2320 GHC Trac Issues: #4012
* Refine imports slightlySimon Peyton Jones2016-06-101-1/+1
|
* Fix #12099: Remove bogus flagsSean Gillespie2016-06-101-4/+4
| | | | | | | | | | | | | | | | | | Remove -fwarn- and -fno-warn- from flagsForCompletion Testcase: Fix linter error on T12099 For Issue #12099 Reviewers: austin, thomie, bgamari Reviewed By: austin, thomie, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2281 GHC Trac Issues: #12099
* Fix #12076 by inlining trivial expressions in CorePrep.Edward Z. Yang2016-06-081-2/+2
| | | | | | | | | | | | | | | | | | | | | | | Summary: This mostly follows the plan detailed by the discussion Simon and I had, with one difference: instead of grabbing the free variables of the trivial expressions to get the embedded Ids, we just use getIdFromTrivialExpr_maybe to extract out the Id. If there is no Id, the expression cannot refer to a function (as there are no literal functions) and thus we do not need to saturate. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: simonpj, austin, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2309 GHC Trac Issues: #12076
* Make vectInfoParallelVars a DVarSetBartosz Nitka2016-06-072-8/+9
| | | | | | | | | | | | | | | | We dump it in the interface file, so we need to do it in a deterministic order. I haven't seen any problems with this during my testing, but that's probably because it's unused. Test Plan: ./validate Reviewers: simonmar, austin, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2313 GHC Trac Issues: #4012
* Merge MatchFixity and HsMatchContextAlan Zimmerman2016-06-061-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: MatchFixity was introduced to facilitate use of API Annotations. HsMatchContext does the same thing with more detail, but is chased through all over the place to provide context when processing a Match. Since we already have MatchFixity in the Match, it may as well provide the full context. updates submodule haddock Test Plan: ./validate Reviewers: austin, goldfire, bgamari Subscribers: thomie, mpickering Differential Revision: https://phabricator.haskell.org/D2271 GHC Trac Issues: #12105 (cherry picked from commit 306ecad591951521ac3f5888ca8be85bf749d271)
* Make UnitIdMap a deterministic mapBartosz Nitka2016-06-061-26/+27
| | | | | | | | | | | | | | | | | | | This impacts at least the order in which version macros are generated. It's pretty hard to track what kind of nondeterminism is benign and this should have no performance impact as the number of packages should be relatively small. Test Plan: ./validate Reviewers: simonmar, austin, bgamari, ezyang Reviewed By: ezyang Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2308 GHC Trac Issues: #4012
* Use UniqDFM for HomePackageTableBartosz Nitka2016-06-065-41/+75
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This isn't strictly necessary for deterministic ABIs. The results of eltsHpt are consumed in two ways: 1) they determine the order of linking 2) if you track the data flow all the family instances get put in FamInstEnvs, so the nondeterministic order is forgotten. 3) same for VectInfo stuff 4) same for Annotations The problem is that I haven't found a nice way to do 2. in a local way and 1. is nice to have if we went for deterministic object files. Besides these maps are keyed on ModuleNames so they should be small relative to other things and the overhead should be negligible. As a bonus we also get more specific names. Test Plan: ./validate Reviewers: bgamari, austin, hvr, ezyang, simonmar Reviewed By: simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2300 GHC Trac Issues: #4012
* Better comment for orIfNotFound.Edward Z. Yang2016-06-051-1/+5
| | | | Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
* HscMain: Minor simplificationÖmer Sinan Ağacan2016-06-031-3/+2
|
* Kill nameSetElems in getInfoBartosz Nitka2016-06-021-1/+1
| | | | nameSetAll is more precise here
* Fix: #12084 deprecate old profiling flagsSeraphime Kirkovski2016-05-241-12/+18
| | | | | | | | | | | | | | | | | | | | Change help message so it doesn't specify -auto-all. Make old profiling flags deprecated as they are no longer documented. Update Makefile and documentation accordingly. Update release notes for ghc 8.2 Test Plan: ./verify; `ghc --help` shouldn't specify the -auto-all flag. Furthermore `ghc -fprof -auto-all` should emit a warning Reviewed By: thomie, austin Differential Revision: https://phabricator.haskell.org/D2257 GHC Trac Issues: #12084 Update submodule nofib
* Remove 'deriving Typeable' statementsRyan Scott2016-05-241-4/+1
| | | | | | | | | | | | | | | | | Summary: Deriving `Typeable` has been a no-op since GHC 7.10, and now that we require 7.10+ to build GHC, we can remove all the redundant `deriving Typeable` statements in GHC. Test Plan: ./validate Reviewers: goldfire, austin, hvr, bgamari Reviewed By: austin, hvr, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2260
* Document some benign nondeterminismBartosz Nitka2016-05-241-1/+3
| | | | | | | | | | | | | | | | | | I've changed the functions to their nonDet equivalents and explained why they're OK there. This allowed me to remove foldNameSet, foldVarEnv, foldVarEnv_Directly, foldVarSet and foldUFM_Directly. Test Plan: ./validate, there should be no change in behavior Reviewers: simonpj, simonmar, austin, goldfire, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2244 GHC Trac Issues: #4012
* Use `setSession` instead of `modifySession` when setting `HscEnv`Ömer Sinan Ağacan2016-05-222-9/+9
| | | | | | | | | | Reviewers: austin, hvr, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2253
* Rework parser to allow use with DynFlagsDave Laing2016-05-183-4/+4
| | | | | | | | | | | | | | | | | Split out the options needed by the parser from DynFlags, making the parser more friendly to standalone usage. Test Plan: validate Reviewers: simonmar, alanz, bgamari, austin, thomie Reviewed By: simonmar, alanz, bgamari, thomie Subscribers: thomie, mpickering Differential Revision: https://phabricator.haskell.org/D2208 GHC Trac Issues: #10961
* Move Extension type to ghc-boot-thBen Gamari2016-05-161-2/+2
| | | | | | | | | | | | | | | | | | | | This creates a new package, `ghc-boot-th`, to contain the `Extension` type, which now lives in `GHC.LanguageExtension.Type`. This ensures that the transitive dependency set of the `template-haskell` package remains minimal. The `GHC.LanguageExtensions.Type` module is also re-exported by `ghc-boot`, which provides an orphan `binary` instance as well. Test Plan: Validate Reviewers: goldfire, thomie, hvr, austin Reviewed By: thomie Subscribers: RyanGlScott, thomie, erikd, ezyang Differential Revision: https://phabricator.haskell.org/D2224
* Refactor some ppr functions to use pprUFMBartosz Nitka2016-05-121-3/+3
| | | | | | | | | | | | | | | | | Nondeterminism doesn't matter in these places and pprUFM makes it obvious. I've flipped the order of arguments for convenience. Test Plan: ./validate Reviewers: simonmar, bgamari, austin, simonpj Reviewed By: simonpj Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2205 GHC Trac Issues: #4012
* Comments about static formsSimon Peyton Jones2016-05-102-2/+7
|
* StaticPointers: Allow closed vars in the static form.Facundo Domínguez2016-05-022-7/+148
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: With this patch closed variables are allowed regardless of whether they are bound at the top level or not. The FloatOut pass is always performed. When optimizations are disabled, only expressions that go to the top level are floated. Thus, the applications of the StaticPtr data constructor are always floated. The CoreTidy pass makes sure the floated applications appear in the symbol table of object files. It also collects the floated bindings and inserts them in the static pointer table. The renamer does not check anymore if free variables appearing in the static form are top-level. Instead, the typechecker looks at the tct_closed flag to decide if the free variables are closed. The linter checks that applications of StaticPtr only occur at the top of top-level bindings after the FloatOut pass. The field spInfoName of StaticPtrInfo has been removed. It used to contain the name of the top-level binding that contains the StaticPtr application. However, this information is no longer available when the StaticPtr is constructed, as the binding name is determined now by the FloatOut pass. Test Plan: ./validate Reviewers: goldfire, simonpj, austin, hvr, bgamari Reviewed By: simonpj Subscribers: thomie, mpickering, mboes Differential Revision: https://phabricator.haskell.org/D2104 GHC Trac Issues: #11656
* added docstring for '-fhistory-size' flagSergei Trofimovich2016-05-021-1/+1
| | | | Signed-off-by: Sergei Trofimovich <siarheit@google.com>
* Make sure record pattern synonym selectors are in scope in GHCi.Matthew Pickering2016-05-021-7/+9
| | | | | | | | | | | | | | | | | | Beforehand, when a record pattern synonym was defined in GHCi the selectors would not be in scope. This is because of `is_sub_bndr` in `HscTypes.icExtendGblRdrEnv` was throwing away the selectors. This was broken by the fix to #10520 but it is easy to resolve. Reviewers: austin, bgamari, simonpj Reviewed By: simonpj Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2147 GHC Trac Issues: #11985
* Warn about simplifiable class constraintsSimon Peyton Jones2016-04-221-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Provoked by Trac #11948, this patch adds a new warning to GHC -Wsimplifiable-class-constraints It warns if you write a class constraint in a type signature that can be simplified by an existing instance declaration. Almost always this means you should simplify it right now; type inference is very fragile without it, as #11948 shows. I've put the warning as on-by-default, but I suppose that if there are howls of protest we can move it out (as happened for -Wredundant-constraints. It actually found an example of an over-complicated context in CmmNode. Quite a few tests use these weird contexts to trigger something else, so I had to suppress the warning in those. The 'haskeline' library has a few occurrences of the warning (which I think should be fixed), so I switched it off for that library in warnings.mk. The warning itself is done in TcValidity.check_class_pred. HOWEVER, when type inference fails we get a type error; and the error suppresses the (informative) warning. So as things stand, the warning only happens when it doesn't cause a problem. Not sure what to do about this, but this patch takes us forward, I think.
* Reduce use of instances in hs-boot filesSimon Peyton Jones2016-04-201-2/+4
| | | | | | | | | | | | | | | Several things here * GHC no longer allows user-written Typeable instances, so remove them from hs-boot files. * Generally, reduce the use of instances in hs-boot files. They are hard to track. Mainly this involves using pprType, pprKind etc instead of just ppr. There were a lot of instances in hs-boot files that weren't needed at all. * Take TyThing out of Eq; it was used in exactly one place (in InteractiveEval), and equality is too big a hammer for that.
* Remove unused import of emptyNameEnvSimon Peyton Jones2016-04-191-1/+0
|
* Resolve symlinks when attempting to find GHC's lib folder on WindowsTamar Christina2016-04-171-1/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Systools makes some pretty hard assumptions about where GHC is on Windows. One of these is that ghc be in a folder named `bin` and that `../lib` exists. This pattern doesn't hold for symlinks as a link `C:\ghc-bin\` pointing to `C:\ghc\ghc-7.10.3\bin` will break this assumption. This patch resolves symlinks by finding where they point to and uses that location as the base for GHC. This uses an API that's been introduced in Vista. For older systems it falls back to the current behavior of not resolving symlinks. Test Plan: 1) Create symlink to GHC's bin folder. 2) Run GHC from that folder. Reviewers: austin, bgamari Reviewed By: austin Subscribers: #ghc_windows_task_force, thomie Differential Revision: https://phabricator.haskell.org/D2101 GHC Trac Issues: #11759
* Add flag to control number of missing patterns in warningsDavid Luposchainsky2016-04-171-0/+5
| | | | | | | | | | | | | | | | | | Non-exhaustive pattern warnings had their number of patterns to show hardcoded in the past. This patch implements the TODO remark that this should be made a command line flag. -fmax-uncovered-patterns=<n> can now be used to influence the number of patterns to be shown. Reviewers: hvr, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2076
* Kill some unnecessary varSetElemsBartosz Nitka2016-04-152-5/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When you do `varSetElems (tyCoVarsOfType x)` it's equivalent to `tyCoVarsOfTypeList x`. Why? If you look at the implementation: ``` tyCoVarsOfTypeList ty = runFVList $ tyCoVarsOfTypeAcc ty tyCoVarsOfType ty = runFVSet $ tyCoVarsOfTypeAcc ty ``` they use the same helper function. The helper function returns a deterministically ordered list and a set. The only difference between the two is which part of the result they take. It is redundant to take the set and then immediately convert it to a list. This helps with determinism and we eventually want to replace the uses of `varSetElems` with functions that don't leak the values of uniques. This change gets rid of some instances that are easy to kill. I chose not to annotate every place where I got rid of `varSetElems` with a comment about non-determinism, because once we get rid of `varSetElems` it will not be possible to do the wrong thing. Test Plan: ./validate Reviewers: goldfire, austin, simonmar, bgamari, simonpj Reviewed By: simonpj Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2115 GHC Trac Issues: #4012
* Fix typos: tyars -> tyvarsBartosz Nitka2016-04-141-1/+1
|
* Change runtime linker to perform lazy loading of symbols/sectionsTamar Christina2016-04-111-2/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Runtime Linker is currently eagerly loading all object files on all platforms which do not use the system linker for `GHCi`. The problem with this approach is that it requires all symbols to be found. Even those of functions never used/called. This makes the number of libraries required to link things like `mingwex` quite high. To work around this the `rts` was relying on a trick. It itself was compiled with `MingW64-w`'s `GCC`. So it was already linked against `mingwex`. As such, it re-exported the symbols from itself. While this worked it made it impossible to link against `mingwex` in user libraries. And with this means no `C99` code could ever run in `GHCi` on Windows without having the required symbols re-exported from the rts. Consequently this rules out a large number of packages on Windows. SDL2, HMatrix etc. After talking with @rwbarton I have taken the approach of loading entire object files when a symbol is needed instead of doing the dependency tracking on a per symbol basis. This is a lot less fragile and a lot less complicated to implement. The changes come down to the following steps: 1) modify the linker to and introduce a new state for ObjectCode: `Needed`. A Needed object is one that is required for the linking to succeed. The initial set consists of all Object files passed as arguments to the link. 2) Change `ObjectCode`'s to be indexed but not initialized or resolved. This means we know where we would load the symbols, but haven't actually done so. 3) Mark any `ObjectCode` belonging to `.o` passed as argument as required: ObjectState `NEEDED`. 4) During `Resolve` object calls, mark all `ObjectCode` containing the required symbols as `NEEDED` 5) During `lookupSymbol` lookups, (which is called from `linkExpr` and `linkDecl` in `GHCI.hs`) is the symbol is in a not-yet-loaded `ObjectCode` then load the `ObjectCode` on demand and return the address of the symbol. Otherwise produce an unresolved symbols error as expected. 6) On `unloadObj` we then change the state of the object and remove it's symbols from the `reqSymHash` table so it can be reloaded. This change affects all platforms and OSes which use the runtime linker. It seems there are no real perf tests for `GHCi`, but performance shouldn't be impacted much. We gain a lot of time not loading all `obj` files, and we lose some time in `lookupSymbol` when we're finding sections that have to be loaded. The actual finding itself is O(1) (Assuming the hashtnl is perfect) It also consumes slighly more memory as instead of storing just the address of a symbol I also store some other information, like if the symbol is weak or not. This change will break any packages relying on renamed POSIX functions that were re-named and re-exported by the rts. Any packages following the proper naming for functions as found on MSDN will work fine. Test Plan: ./validate on all platforms which use the Runtime linker. Reviewers: thomie, rwbarton, simonmar, erikd, bgamari, austin, hvr Reviewed By: erikd Subscribers: kgardas, gridaphobe, RyanGlScott, simonmar, rwbarton, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D1805 GHC Trac Issues: #11223
* Reduce default for -fmax-pmcheck-iterations from 1e7 to 2e6Herbert Valerio Riedel2016-04-101-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | The commit 28f951edfe50ea5182065144340061ec326781f5 introduced the `-fmax-pmcheck-iterations` flag and set the default limit to 1e7 iterations. However, this value is still high enough that it can result GHC to exhibit memory spikes beyond 1 GiB of RAM usage (heap profile showed several `(:)`s, as well as `THUNK_2_0`, and `PmCon` during the memory spikes) A value of 2e6 seems to be a safer upper bound which still manages to let the checker not run into the limit in most cases. Test Plan: Validate, try building a few Hackage packages Reviewers: austin, gkaracha, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2095
* Add -f(no-)version-macro to explicitly control macros.Edward Z. Yang2016-03-302-2/+5
| | | | | | | | | | | | | | Test Plan: validate Reviewers: thomie, austin, bgamari Reviewed By: bgamari Subscribers: hvr Differential Revision: https://phabricator.haskell.org/D2058 GHC Trac Issues: #11763
View Lorry Controller Status