summaryrefslogtreecommitdiff
path: root/compiler/HsVersions.h
Commit message (Collapse)AuthorAgeFilesLines
* Modules: Utils and Data (#13009)Sylvain Henry2020-04-261-4/+4
| | | | | | | Update Haddock submodule Metric Increase: haddock.compiler
* TestBen Gamari2019-10-091-0/+3
|
* Clean up `#include`s in the compilerJohn Ericson2019-10-051-5/+0
| | | | | | | | - Remove unneeded ones - Use <..> for inter-package. Besides general clean up, helps distinguish between the RTS we link against vs the RTS we compile for.
* Per stage headers, ghc_boot_platform.h -> stage 0 ghcplatform.hJohn Ericson2019-10-041-8/+4
| | | | | | | | | | | | | | | | | | The generated headers are now generated per stage, which means we can skip hacks like `ghc_boot_platform.h` and just have that be the stage 0 header as proper. In general, stages are to be embraced: freely generate everything in each stage but then just build what you depend on, and everything is symmetrical and efficient. Trying to avoid stages because bootstrapping is a mind bender just creates tons of bespoke mini-mind-benders that add up to something far crazier. Hadrian was pretty close to this "stage-major" approach already, and so was fairly easy to fix. Make needed more work, however: it did know about stages so at least there was a scaffold, but few packages except for the compiler cared, and the compiler used its own counting system. That said, make and Hadrian now work more similarly, which is good for the transition to Hadrian. The merits of embracing stage aside, the change may be worthy for easing that transition alone.
* Remove COMPILING_GHCJohn Ericson2019-09-111-3/+0
| | | | | It is no longer used. I guess we are sharing fewer headers with the RTS than the comment claims. That's a relief!
* Remove most uses of TARGET platform macrosJohn Ericson2019-07-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | These prevent multi-target builds. They were gotten rid of in 3 ways: 1. In the compiler itself, replacing `#if` with runtime `if`. In these cases, we care about the target platform still, but the target platform is dynamic so we must delay the elimination to run time. 2. In the compiler itself, replacing `TARGET` with `HOST`. There was just one bit of this, in some code splitting strings representing lists of paths. These paths are used by GHC itself, and not by the compiled binary. (They are compiler lookup paths, rather than RPATHS or something that does matter to the compiled binary, and thus would legitamentally be target-sensative.) As such, the path-splitting method only depends on where GHC runs and not where code it produces runs. This should have been `HOST` all along. 3. Changing the RTS. The RTS doesn't care about the target platform, full stop. 4. `includes/stg/HaskellMachRegs.h` This file is also included in the genapply executable. This is tricky because the RTS's host platform really is that utility's target platform. so that utility really really isn't multi-target either. But at least it isn't an installed part of GHC, but just a one-off tool when building the RTS. Lying with the `HOST` to a one-off program (genapply) that isn't installed doesn't seem so bad. It's certainly better than the other way around of lying to the RTS though not to genapply. The RTS is more important, and it is installed, *and* this header is installed as part of the RTS.
* cpp: Use #pragma once instead of #ifndef guardsBen Gamari2017-04-231-5/+1
| | | | | | | | | | | | | | This both says what we mean and silences a bunch of spurious CPP linting warnings. This pragma is supported by all CPP implementations which we support. Reviewers: austin, erikd, simonmar, hvr Reviewed By: simonmar Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3482
* Make globals use sharedCAFMoritz Angermann2016-12-111-0/+16
| | | | | | | | | | | | | | | | | | | Summary: The use of globals is quite painful when multiple rts are loaded, e.g. when plugins are loaded, which bring in a second rts. The sharedCAF appraoch was employed for the FastStringTable; I've taken the libery to extend this to the other globals I could find. This is a reboot of D2575, that should hopefully not exhibit the same windows build issues. Reviewers: Phyx, simonmar, goldfire, bgamari, austin, hvr, erikd Reviewed By: Phyx, simonmar, bgamari Subscribers: mpickering, thomie Differential Revision: https://phabricator.haskell.org/D2773
* Revert "Make globals use sharedCAF"Ben Gamari2016-11-301-16/+0
| | | | | This reverts commit 6f7ed1e51bf360621a3c2a447045ab3012f68575 due to breakage of the build on Windows.
* Make globals use sharedCAFMoritz Angermann2016-11-291-0/+16
| | | | | | | | | | | | | | | The use of globals is quite painful when multiple rts are loaded, e.g. when plugins are loaded, which bring in a second rts. The sharedCAF appraoch was employed for the FastStringTable; I've taken the libery to extend this to the other globals I could find. Reviewers: rwbarton, simonmar, austin, hvr, erikd, bgamari Reviewed By: simonmar, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2575
* Remove directories from include pathsBen Gamari2016-09-161-1/+1
| | | | | | | | | | | | | | | | | | | Previously this was a relative path which worked in the GHC tree, but failed elsewhere. This caused trouble for out-of-tree users as well as Hadrian, which wants to move build artifacts out of the working directory. Fixes #8040. Test Plan: Validate Reviewers: thomie, austin, snowleopard, hvr Reviewed By: snowleopard, hvr Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2530 GHC Trac Issues: #8040
* Replace `STRICT[12345]` macros by `BangPatterns`Yuri de Wit2014-11-251-8/+0
| | | | | | | | | | This removes the macros `STRICT1()`, `STRICT2()`, `STRICT3()`, `STRICT4()`, and `STRICT5()` CPP macros from `HsVersions.hs` and replaces the few use sites by uses of `BangPatterns`. Reviewed By: hvr Differential Revision: https://phabricator.haskell.org/D525
* Delete all /* ! __GLASGOW_HASKELL__ */ codeThomas Miedema2014-09-231-5/+1
| | | | | | | | | | | | | | | | | Summary: ``` git grep -l '\(#ifdef \|#if defined\)(\?__GLASGOW_HASKELL__)\?' ``` Test Plan: validate Reviewers: rwbarton, hvr, austin Reviewed By: rwbarton, hvr, austin Subscribers: rwbarton, simonmar, ezyang, carter Differential Revision: https://phabricator.haskell.org/D218
* Remove some __HADDOCK__ CPPIan Lynagh2013-04-091-10/+0
| | | | I think these are all redundant, now that haddock uses the GHC API
* Change how macros like ASSERT are definedIan Lynagh2012-06-051-11/+2
| | | | | By using Haskell's debugIsOn rather than CPP's "#ifdef DEBUG", we don't need to kludge things to keep the warning checker happy etc.
* Remove unused CPP definitions of COMMAIan Lynagh2011-10-231-2/+0
|
* Remove unused elf_OBJ_FORMAT #defineIan Lynagh2011-10-201-5/+0
|
* Put the target platform in the settings fileIan Lynagh2011-10-191-1/+0
|
* ARMv5 compatibility for registerized runtime changes.Stephen Blackheath2011-08-101-0/+1
| | | | | | | When the bootstrap compiler does not include this patch, you must add this line to mk/build.mk, otherwise the ARM architecture cannot be detected due to a -undef option given to the C pre-processor. SRC_HC_OPTS = -pgmP 'gcc -E -traditional'
* Add CoreMonad.reinitializeGlobals so plugins can work around linker issuesMax Bolingbroke2011-07-291-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a plugin is loaded, it currently gets linked against a *newly loaded* copy of the GHC package. This would not be a problem, except that the new copy has its own mutable state that is not shared with that state that has already been initialized by the original GHC package. This leads to loaded plugins calling GHC code which pokes the static flags, and then dying with a panic because the static flags *it* sees are uninitialized. There are two possible solutions: 1. Export the symbols from the GHC executable from the GHC library and link against this existing copy rather than a new copy of the GHC library 2. Carefully ensure that the global state in the two copies of the GHC library matches I tried 1. and it *almost* works (and speeds up plugin load times!) except on Windows. On Windows the GHC library tends to export more than 65536 symbols (see #5292) which overflows the limit of what we can export from the EXE and causes breakage. (Note that if the GHC exeecutable was dynamically linked this wouldn't be a problem, because we could share the GHC library it links to.) We are going to try 2. instead. Unfortunately, this means that every plugin will have to say `reinitializeGlobals` before it does anything, but never mind. I've threaded the cr_globals through CoreM rather than giving them as an argument to the plugin function so that we can turn this function into (return ()) without breaking any plugins when we eventually get 1. working.
* provide shared libraries support on i386-unknown-solaris2 platformKarel Gardas2010-12-171-1/+1
|
* Enable shared libs on OpenBSDMatthias Kilian2010-09-181-1/+1
|
* Super-monster patch implementing the new typechecker -- at lastsimonpj@microsoft.com2010-09-131-1/+1
| | | | | | | | | This major patch implements the new OutsideIn constraint solving algorithm in the typecheker, following our JFP paper "Modular type inference with local assumptions". Done with major help from Dimitrios Vytiniotis and Brent Yorgey.
* Add WARNM2 macro, plus some refactoringsimonpj@microsoft.com2010-05-061-10/+15
|
* Patch for shared libraries support on FreeBSDIan Lynagh2010-01-061-0/+5
| | | | From Maxime Henrion <mhenrion@gmail.com>
* Make the dynamic linker thread-safe.Thomas Schilling2009-08-171-0/+9
| | | | | | | | | | | | The current implementation is rather pessimistic. The persistent linker state is now an MVar and all exported Linker functions are wrapped in modifyMVar calls. This is serves as a big lock around all linker functions. There might be a chance for more concurrency in a few places. E.g., extending the closure environment and loading packages might be independent in some cases. But for now it's better to be on the safe side.
* Make ASSERT2 mention msg even when debug is off (avoid warnings)simonpj@microsoft.com2008-09-051-1/+1
|
* Fix Haddock errors.Thomas Schilling2008-07-201-0/+6
|
* Now that we require GHC >= 6.4.2, System.IO.Error is always availableIan Lynagh2008-06-201-6/+0
|
* Don't use CPP for SLIT/FSLITIan Lynagh2008-04-121-8/+0
|
* Don't import FastString in HsVersions.hIan Lynagh2008-03-291-13/+4
| | | | Modules that need it import it themselves instead.
* Put debugIsOn in Util, rather than rely on it being CPPed inIan Lynagh2008-03-291-2/+0
|
* Fix warnings in main/StaticFlagsIan Lynagh2008-03-251-2/+3
|
* Added MASSERT macro for assertions in do notationTwan van Laarhoven2008-01-171-0/+4
|
* lots of portability changes (#1405)Isaac Dupree2008-01-171-2/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | re-recording to avoid new conflicts was too hard, so I just put it all in one big patch :-( (besides, some of the changes depended on each other.) Here are what the component patches were: Fri Dec 28 11:02:55 EST 2007 Isaac Dupree <id@isaac.cedarswampstudios.org> * document BreakArray better Fri Dec 28 11:39:22 EST 2007 Isaac Dupree <id@isaac.cedarswampstudios.org> * properly ifdef BreakArray for GHCI Fri Jan 4 13:50:41 EST 2008 Isaac Dupree <id@isaac.cedarswampstudios.org> * change ifs on __GLASGOW_HASKELL__ to account for... (#1405) for it not being defined. I assume it being undefined implies a compiler with relatively modern libraries but without most unportable glasgow extensions. Fri Jan 4 14:21:21 EST 2008 Isaac Dupree <id@isaac.cedarswampstudios.org> * MyEither-->EitherString to allow Haskell98 instance Fri Jan 4 16:13:29 EST 2008 Isaac Dupree <id@isaac.cedarswampstudios.org> * re-portabilize Pretty, and corresponding changes Fri Jan 4 17:19:55 EST 2008 Isaac Dupree <id@isaac.cedarswampstudios.org> * Augment FastTypes to be much more complete Fri Jan 4 20:14:19 EST 2008 Isaac Dupree <id@isaac.cedarswampstudios.org> * use FastFunctions, cleanup FastString slightly Fri Jan 4 21:00:22 EST 2008 Isaac Dupree <id@isaac.cedarswampstudios.org> * Massive de-"#", mostly Int# --> FastInt (#1405) Fri Jan 4 21:02:49 EST 2008 Isaac Dupree <id@isaac.cedarswampstudios.org> * miscellaneous unnecessary-extension-removal Sat Jan 5 19:30:13 EST 2008 Isaac Dupree <id@isaac.cedarswampstudios.org> * add FastFunctions
* Fix warnings in utils/UtilIan Lynagh2008-01-131-3/+5
|
* make it easier to have debugging code typechecked even when debugging is ↵Norman Ramsey2007-09-121-0/+2
| | | | turned off
* Make various assertions work when !DEBUGIan Lynagh2007-09-081-2/+3
|
* In ASSERT and friends, use all the expressions we are passed even if !DEBUGIan Lynagh2007-09-071-5/+7
| | | | | Otherwise we may get unused variable warnings. GHC should optimise them all out for us.
* Removed UNBOX_FIELD from HsVersions.h since it is not used anywhere.Michael D. Adams2007-05-111-6/+0
|
* Fixed apparent typo in STRICT1(f) of HsVersions.hMichael D. Adams2007-05-041-1/+1
|
* Module header tidyup #2Simon Marlow2006-10-111-0/+6
| | | | Push this further along, and fix build problems in the first patch.
* Module header tidyup, phase 1Simon Marlow2006-10-111-36/+0
| | | | | | | | | | | | This patch is a start on removing import lists and generally tidying up the top of each module. In addition to removing import lists: - Change DATA.IOREF -> Data.IORef etc. - Change List -> Data.List etc. - Remove $Id$ - Update copyrights - Re-order imports to put non-GHC imports last - Remove some unused and duplicate imports
* Reorganisation of the source treeSimon Marlow2006-04-071-0/+108
Most of the other users of the fptools build system have migrated to Cabal, and with the move to darcs we can now flatten the source tree without losing history, so here goes. The main change is that the ghc/ subdir is gone, and most of what it contained is now at the top level. The build system now makes no pretense at being multi-project, it is just the GHC build system. No doubt this will break many things, and there will be a period of instability while we fix the dependencies. A straightforward build should work, but I haven't yet fixed binary/source distributions. Changes to the Building Guide will follow, too.
View Lorry Controller Status