summaryrefslogtreecommitdiff
path: root/compiler/main/SysTools.hs
Commit message (Collapse)AuthorAgeFilesLines
* Modules (#13009)Sylvain Henry2020-04-181-475/+0
| | | | | | | | | | | | | | * SysTools * Parser * GHC.Builtin * GHC.Iface.Recomp * Settings Update Haddock submodule Metric Decrease: Naperian parsing001
* Modules: Types (#13009)Sylvain Henry2020-03-291-1/+1
| | | | | | | Update Haddock submodule Metric Increase: haddock.compiler
* Use a Set to represent WaysSylvain Henry2020-03-111-1/+3
| | | | | | | | Should make `member` queries faster and avoid messing up with missing `nubSort`. Metric Increase: hie002
* Modules: Driver (#13009)Sylvain Henry2020-02-211-2/+2
| | | | submodule updates: nofib, haddock
* Refactor, document, and optimize LLVM configuration loadingBen Gamari2019-10-071-5/+27
| | | | | | | | | | | | As described in the new Note [LLVM Configuration] in SysTools, we now load llvm-targets and llvm-passes lazily to avoid the overhead of doing so when -fllvm isn't used (also known as "the common case"). Noticed in #17003. Metric Decrease: T12234 T12150
* Pull out the settings file parsing code into it's own module.John Ericson2019-10-041-214/+8
| | | | | | | | | | | This has two benefits: 1. One less hunk of code dependent on DynFlags 2. Add a little bit of error granularity to distrinugish between missing data and bad data. This could someday be shared with ghc-pkg which aims to work even with a missing file. I also am about to to make --supported-extensions use this too.
* Remove LLVM_TARGET platform macrosJohn Ericson2019-07-141-0/+3
| | | | | Instead following @angerman's suggestion put them in the config file. Maybe we could re-key llvm-targets someday, but this is good for now.
* ghc-pkg needs settings file to un-hardcode target platformJohn Ericson2019-06-191-37/+19
| | | | This matches GHC itself getting the target platform from there.
* Move 'Platform' to ghc-bootJohn Ericson2019-06-191-1/+1
| | | | | | | ghc-pkg needs to be aware of platforms so it can figure out which subdire within the user package db to use. This is admittedly roundabout, but maybe Cabal could use the same notion of a platform as GHC to good affect too.
* Maintain separate flags for C++ compiler invocationsBen Gamari2019-06-131-16/+17
| | | | | | | Previously we would pass flags intended for the C compiler to the C++ compiler (see #16738). This would cause, for instance, `-std=gnu99` to be passed to the C++ compiler, causing spurious test failures. Fix this by maintaining a separate set of flags for C++ compilation invocations.
* Inline `Settings` into `DynFlags`John Ericson2019-05-291-2/+2
| | | | | | | | | | After the previous commit, `Settings` is just a thin wrapper around other groups of settings. While `Settings` is used by GHC-the-executable to initalize `DynFlags`, in principle another consumer of GHC-the-library could initialize `DynFlags` a different way. It therefore doesn't make sense for `DynFlags` itself (library code) to separate the settings that typically come from `Settings` from the settings that typically don't.
* Break up `Settings` into smaller structsJohn Ericson2019-05-291-62/+77
| | | | | | | | | | | | | | | | | As far as I can tell, the fields within `Settings` aren't *intrinsicly* related. They just happen to be initialized the same way (in particular prior to the rest of `DynFlags`), and that is why they are grouped together. Within `Settings`, however, there are groups of settings that clearly do share something in common, regardless of how they anything is initialized. In the spirit of GHC being a library, where the end cosumer may choose to initialize this configuration in arbitrary ways, I made some new data types for thoses groups internal to `Settings`, and used them to define `Settings` instead. Hopefully this is a baby step towards a general decoupling of the stateful and stateless parts of GHC.
* Remove all target-specific portions of Config.hsJohn Ericson2019-05-141-5/+42
| | | | | | | | | | | | | | | | | | | 1. If GHC is to be multi-target, these cannot be baked in at compile time. 2. Compile-time flags have a higher maintenance than run-time flags. 3. The old way makes build system implementation (various bootstrapping details) with the thing being built. E.g. GHC doesn't need to care about which integer library *will* be used---this is purely a crutch so the build system doesn't need to pass flags later when using that library. 4. Experience with cross compilation in Nixpkgs has shown things work nicer when compiler's can *optionally* delegate the bootstrapping the package manager. The package manager knows the entire end-goal build plan, and thus can make top-down decisions on bootstrapping. GHC can just worry about GHC, not even core library like base and ghc-prim!
* Purge TargetPlatform_NAME and cTargetPlatformStringJohn Ericson2019-05-081-0/+2
|
* Remove cGhcEnableTablesNextToCodeJohn Ericson2019-05-061-1/+3
| | | | Get "Tables next to code" from the settings file instead.
* Move cGHC_UNLIT_PGM to be "unlit command" in settingsJohn Ericson2019-04-301-3/+3
| | | | | | | | | | | | The bulk of the work was done in #712, making settings be make/Hadrian controlled. This commit then just moves the unlit command rules in make/Hadrian from the `Config.hs` generator to the `settings` generator in each build system. I think this is a good change because the crucial benefit is *settings* don't affect the build: ghc gets one baby step closer to being a regular cabal executable, and make/Hadrian just maintains settings as part of bootstrapping.
* GHC no longer ever defines TABLES_NEXT_TO_CODE on its ownJoachim Breitner2019-04-091-7/+1
| | | | | | | | | | | | | | | It should be entirely the responsibility of make/Hadrian to ensure that everything that needs this flag gets it. GHC shouldn't be hardcoded to assist with bootstrapping since it builds other things besides itself. Reviewers: Subscribers: TerrorJack, rwbarton, carter GHC Trac Issues: #15548 -- progress towards but not fix Differential Revision: https://phabricator.haskell.org/D5082 -- extract from that
* Add `-optcxx` option (#16477)Yuriy Syrovetskiy2019-04-081-0/+1
|
* Update Trac ticket URLs to point to GitLabRyan Scott2019-03-151-2/+2
| | | | | This moves all URL references to Trac tickets to their corresponding GitLab counterparts.
* Rip out object splittingBen Gamari2019-03-051-15/+1
| | | | | | | | | | | | | | | The splitter is an evil Perl script that processes assembler code. Its job can be done better by the linker's --gc-sections flag. GHC passes this flag to the linker whenever -split-sections is passed on the command line. This is based on @DemiMarie's D2768. Fixes Trac #11315 Fixes Trac #9832 Fixes Trac #8964 Fixes Trac #8685 Fixes Trac #8629
* ghc, ghc-pkg: use getExecutablePath on Windows when base >= 4.11.0Tamar Christina2018-08-251-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This completes the work started in D4227 by using just 'getExecutablePath' in ghc and ghc-pkg when building with base >= 4.11.0. On the long term, we will be able to simply kill the existing code that follows (or not) symlinks and just get this behaviour for free from getExecutable. For now we however have to require base >= 4.11.0 to be able to just use getExecutablePath under Windows, and use the current code when building with an older base. Original code by @alpmestan commandeering since patch has been stale and bug remains open. Test Plan: Validate Reviewers: angerman, bgamari, erikd, alpmestan Reviewed By: bgamari Subscribers: carter, rwbarton, thomie GHC Trac Issues: #14483 Differential Revision: https://phabricator.haskell.org/D4229
* Avoid redundant invocation of 'findTopDir'Michael Sloan2018-07-201-9/+7
| | | | | | | | | | | | | | | | Summary: While working on [D904](https://phabricator.haskell.org/D4904), I noticed that 'findTopDir' was being invoked three times. This isn't a big problem, because it is usually very cheap. On windows, it does require some involved logic, though, so to me it would make sense to only run it once. Reviewers: bgamari, monoidal Reviewed By: monoidal Subscribers: rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4987
* driver: skip -Bsymbolic on unregisterised targets (Trac #15338)Sergei Trofimovich2018-07-161-2/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Trac #15338 is yet another example where -Bsymbolic breaks semantics of a C program: global variable duplication happens and unsafePerformIO creates two stdout copies. When -Bsymbolic is not used both C compiler and linker agree on how global variables are handled. In case of sh4 it consists on a few assertions: 1. global variable is exported from shared library 2. code is referred to this variable via GOT-like mechanism to allow interposition 3. global variable is present .bss section on an executable (as an R_*_COPY relocation: symbol contents is copied at executable startup time) 4. and symbol in executable interposes symbol in shared library. This way both code in shared library and code in executable refer to a copy of global variable in .bss section of an executable. Unfortunately -Bsymbolic option breaks assumption [2.] and generates direct references to the symbol. This causes mismatch between values seen from executable and values seen from shared library code. This change disables '-Bsymbolic' for unregisterised targets. Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> Test Plan: test 'ghc-pkg --version | cat' to emit data Reviewers: simonmar, bgamari, jrtc27 Reviewed By: jrtc27 Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15338 Differential Revision: https://phabricator.haskell.org/D4959
* dead strip dylibs on macOSMoritz Angermann2018-05-301-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When linking dynamic libraries or executables, we compute the full transitive closure over the dependencies, and instruct the linker to link all dependencies. With deep dependency trees the number of transitive dependencies can grow quickly. macOS since the Sierra release has an upper limit on the load command sizes the linker parses when loading dynamic lirbaries. As such it is mandatory to keep the number of load commands (and their size) small on recent macOS releases. An approach that would just link direct dependencies as specified by the -package-id flag is insufficient, because GHC can inline across packages and the library or executable being linked could refer to symbols deep in the dependency tree. If we just recursively linked librarys and re-exported their symbols, this increases the number of symbols in libraries with many dependencies and ultimately puts excessive strain on the linker to the point where linking takes a lot longer than even the compilation of the modules. We can however build a list of symbols from the obejcts we want to link, and try to compute the libraries we need to link that contain those symbols from the transitive dependency closure. Luckily, we don't need to write this ourselves, but can use the ld64 `-dead_strip_dylibs` linker flag on macOS to achive the same result. This will link only the libraries that are actually referenced, which is usually a small subset of the full transitive dependency closure. As such we should stay within the load command size limit for almost all but pathological cases. Reviewers: bgamari Reviewed By: bgamari Subscribers: lelf, rwbarton, thomie, carter GHC Trac Issues: #14444 Differential Revision: https://phabricator.haskell.org/D4714
* Extract hard-coded LLVM opt flags into a fileKavon Farvardin2018-05-301-10/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | To resolve ticket #11295, I think it makes sense to stop hard-coding the pass sequences used by GHC when compiling with LLVM into the compiler itself. This patchset introduces a companion to the existing `llvm-targets` file called `llvm-passes`. The passes file is a simple association list that holds the default LLVM `opt` pass sequence used by GHC. This allows end users to easily save their favorite optimization flags when compiling with LLVM. The main benefit for ticket #11295 is that when adding a custom pass sequence, it tends to be an extremely long string that would be unsightly in the code. This is essentially part 1 of 2 for ticket #11295. Test Plan: ./validate Reviewers: bgamari, angerman Reviewed By: angerman Subscribers: rwbarton, thomie, carter Differential Revision: https://phabricator.haskell.org/D4695
* Expand $tooldir in ghc --info outputAlp Mestanogullari2018-05-121-0/+1
| | | | | | | | | | | | | | | | | | | | | Summary: This requires adding an `sToolDir :: Maybe FilePath` field to Settings, since compilerInfo is pure and therefore needs to have all the information available in the DynFlags. This should fix #15101 and #15107. Test Plan: ./validate --fast Reviewers: Phyx, bgamari Reviewed By: Phyx Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15101, #15107 Differential Revision: https://phabricator.haskell.org/D4686
* Introduce a $tooldir variable for nicer toolchain detection on WindowsAlp Mestanogullari2018-04-171-10/+14
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch affects several files that affect how we detect mingw and perl on Windows. The initial motivation is: https://github.com/snowleopard/hadrian/issues/564 where, with Hadrian building relocatable (non-inplace) GHCs, the current detection mechanism falls short by e.g only trying $topdir/../mingw. But in Hadrian, for reasons given in that issue, we would need to store e.g mingw under $topdir/../../mingw except for binary distributions, where we want to follow the existing structure, in which case $topdir/../mingw is correct. So we need to support both, which is what this patch hopefully implements. Test Plan: ./validate Reviewers: Phyx, hvr, bgamari, erikd Reviewed By: Phyx Subscribers: snowleopard, thomie, carter Differential Revision: https://phabricator.haskell.org/D4598
* Cache the fingerprint of sOpt_PBartosz Nitka2018-03-021-0/+2
| | | | | | | | | | | | | | | | | | | | | Before this change we would compute a hash of all the command line -optP flags once per file. With a lot of files and many -optP flags, that's a lot of repeated work. I added a new Note that explains the approach and rationale. Test Plan: new test Reviewers: simonmar, simonpj, bgamari Reviewed By: simonpj Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14697 Differential Revision: https://phabricator.haskell.org/D4445
* Get rid of some stuttering in comments and docsGabor Greif2017-12-191-1/+1
|
* SysTools: Split up TopDir logic into new moduleBen Gamari2017-11-231-184/+3
| | | | | | | | | | Test Plan: Validate on Linux and Windows Reviewers: erikd Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D4225
* SysTools: Expand occurrences of $topdir anywhere in a Settings pathBen Gamari2017-11-231-18/+19
| | | | | | Subscribers: rwbarton, thomie, Phyx Differential Revision: https://phabricator.haskell.org/D4221
* Fix #elfi -> #elif; unbreak -Werror.Moritz Angermann2017-11-191-0/+3
| | | | | | | | | | Reviewers: bgamari, erikd Reviewed By: bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D4209
* Relocatable GHCMoritz Angermann2017-11-181-0/+21
| | | | | | | | | | | | | | GHC and the binary distribution that's produced is not relocatable outside of Windows. This diff tries to address this for at least Linux and macOS. Reviewers: austin, hvr, bgamari, erikd, goldfire, Phyx Reviewed By: bgamari Subscribers: duog, rwbarton, thomie, erikd Differential Revision: https://phabricator.haskell.org/D4121
* Split SysTools up someTamar Christina2017-10-101-891/+7
| | | | | | | | | | | | | | | | | Summary: SysTools and DriverTools have an annoying mutual dependency. They also each contain pieces of the linker. In order for changes to be shared between the library and the exe linking code this dependency needs to be broken in order to avoid using hs-boot files. Reviewers: austin, bgamari, erikd Reviewed By: bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D4071
* compiler: introduce custom "GhcPrelude" PreludeHerbert Valerio Riedel2017-09-191-0/+2
| | | | | | | | | | | | | | | | | | This switches the compiler/ component to get compiled with -XNoImplicitPrelude and a `import GhcPrelude` is inserted in all modules. This is motivated by the upcoming "Prelude" re-export of `Semigroup((<>))` which would cause lots of name clashes in every modulewhich imports also `Outputable` Reviewers: austin, goldfire, bgamari, alanz, simonmar Reviewed By: bgamari Subscribers: goldfire, rwbarton, thomie, mpickering, bgamari Differential Revision: https://phabricator.haskell.org/D3989
* Use ar for -staticlibMoritz Angermann2017-09-131-14/+35
| | | | | | | | | | | | | | | | Hopefully we can get rid of libtool, by using ar only Depends on: D3579 Test Plan: validate Reviewers: austin, hvr, bgamari, erikd Reviewed By: bgamari Subscribers: rwbarton, thomie, erikd Differential Revision: https://phabricator.haskell.org/D3721
* Drop special handling of iOS and AndroidMoritz Angermann2017-09-071-4/+1
| | | | | | | | | | | | | | | As far as GHC is concerned, iOS **is** Darwin, and Android **is** Linux. Depends on D3352 Reviewers: austin, hvr, bgamari Reviewed By: bgamari Subscribers: Ericson2314, ryantrinkle, rwbarton, thomie, erikd Differential Revision: https://phabricator.haskell.org/D3579
* Clean up opt and llcMoritz Angermann2017-09-061-2/+19
| | | | | | | | | | | | | | | | | | | | | The LLVM backend shells out to LLVMs `opt` and `llc` tools. This clean up introduces a shared data structure to carry the arguments we pass to each tool so that corresponding flags are next to each other. It drops the hard coded data layouts in favor of using `-mtriple` and have LLVM infer them. Furthermore we add `clang` as a proper tool, so we don't rely on assuming that `clang` is called `clang` on the `PATH` when using `clang` as the assembler. Finally this diff also changes the type of `optLevel` from `Int` to `Word`, as we do not have negative optimization levels. Reviewers: erikd, hvr, austin, rwbarton, bgamari, kavon Reviewed By: kavon Subscribers: michalt, Ericson2314, ryantrinkle, dfeuer, carter, simonpj, kavon, simonmar, thomie, erikd, snowleopard Differential Revision: https://phabricator.haskell.org/D3352
* Fix decomposition error on WindowsTamar Christina2017-08-291-2/+11
| | | | | | | | | | | | | | | | | | | Summary: Fix the path decomposition error that occurs when the Symlink resolver fails. `Win32.try` throws an exception, so catch it and assume the path isn't a symlink to use the old behavior. Test Plan: ./validate Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #14159 Differential Revision: https://phabricator.haskell.org/D3891
* Add support for producing position-independent executablesBen Gamari2017-08-221-14/+1
| | | | | | | | | | | | | | | | Previously due to #12759 we disabled PIE support entirely. However, this breaks the user's ability to produce PIEs. Add an explicit flag, -fPIE, allowing the user to build PIEs. Test Plan: Validate Reviewers: rwbarton, austin, simonmar Subscribers: trommler, simonmar, trofi, jrtc27, thomie GHC Trac Issues: #12759, #13702 Differential Revision: https://phabricator.haskell.org/D3589
* Recognize FreeBSD compiler as Clang.Gleb Popov2017-08-141-0/+3
| | | | | | | | | | Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3840
* Ensure that we always link against libmBen Gamari2017-07-281-0/+14
| | | | | | | | | | | | | | | ld.gold is particularly picky that we declare all of our link dependencies on Nix. See #14022. Test Plan: Validate on Nix Reviewers: austin Subscribers: hvr, rwbarton, thomie GHC Trac Issues: #14022 Differential Revision: https://phabricator.haskell.org/D3787
* Fix busy-wait in SysTools.builderMainLoopDouglas Wilson2017-07-201-43/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Test T13701 was failing sporadically. The problem manifested while the test was run on a system under load. Profiling showed the increased allocations were in SysTools.builderMainLoop.loop, during calls to the assembler. This was due to loop effectively busy-waiting from when both stdin and stderr handles were closed, until getProcessExitCode succeeded. This is fixed by removing exit code handling from loop. We now wait for loop to finish, then read the exit code with waitForProcess. Some exception safety is added: the readerProc threads will now be killed and the handles will be closed if an exception is thrown. A TODO saying that threads dying is not accounted for is removed. I believe that this case is handled by readerProc sending EOF in a finally clause. Test Plan: Replicate test failures using procedure on the ticket, verify that they do not occur with this patch. Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #13987 Differential Revision: https://phabricator.haskell.org/D3748
* Revert "Remove the Windows GCC driver."Simon Peyton Jones2017-06-291-25/+13
| | | | | | | | | | | | | | | | | | This reverts commit d6cecde585b0980ed8e0050c5a1d315789fb6356. The patch broke Simon PJ's Windows build, becuase he didn't have (and should not need) a separate msys2 gcc. Following an exchange on the ghc-devs list, Tamar wrote Oops, sorry, didn’t notice it because both mine and harbormaster’s msys2 have separate GCCs installed as well. I don’t see an easy fix that would also work for end user Configure based cabal installs. So I think I’ll have to go back to the drawing board for this one. You can just leave it reverted.
* Remove the Windows GCC driver.Tamar Christina2017-06-171-13/+25
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch drops the GCC driver and instead moves the only remaining path that we need to keep for backwards compatibility to the settings file. It also generalizes the code that expands `$TopDir` so it can expand it within any location in the string and also changes it so `$TopDir` is expanded only after the words call because `$TopDir` can contains spaces which would be horribly broken. Test Plan: ./validate Reviewers: austin, hvr, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, erikd GHC Trac Issues: #13709 Differential Revision: https://phabricator.haskell.org/D3592
* Refactor temp files cleanupDouglas Wilson2017-06-081-213/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Remove filesToNotIntermediateClean from DynFlags, create a data type FilesToClean, and change filesToClean in DynFlags to be a FilesToClean. Modify SysTools.newTempName and the Temporary constructor of PipelineMonad.PipelineOutput to take a TempFileLifetime, which specifies whether a temp file should live until the end of GhcMonad.withSession, or until the next time cleanIntermediateTempFiles is called. These changes allow the cleaning of intermediate files in GhcMake to be much more efficient. HscTypes.hptObjs is removed as it is no longer used. A new performance test T13701 is added, which passes both with and without -keep-tmp-files. The test fails by 25% without the patch, and passes when -keep-tmp-files is added. Note that there are still at two hotspots caused by algorithms quadratic in the number of modules, however neither of them allocate. They are: * DriverPipeline.compileOne'.needsLinker * GhcMake.getModLoop DriverPipeline.compileOne'.needsLinker is changed slightly to improve the situation. I don't like adding these Types to DynFlags, but they need to be seen by Dynflags, SysTools and PipelineMonad. The alternative seems to be to create a new module. Reviewers: austin, hvr, bgamari, dfeuer, niteria, simonmar, erikd Reviewed By: simonmar Subscribers: rwbarton, thomie GHC Trac Issues: #13701 Differential Revision: https://phabricator.haskell.org/D3620
* Typos [ci skip]Gabor Greif2017-05-101-1/+1
|
* Prefer #if defined to #ifdefBen Gamari2017-04-281-3/+3
| | | | Our new CPP linter enforces this.
* Drop special handling of iOSMoritz Angermann2017-04-121-2/+1
| | | | | | | | | | | | | | | | | | | | iOS at least since iOS8 (we are currently at iOS10.3), allows for dynamic libaries, hence any artificail restriction on dyanmic libraries should be lifted. Please ping me with any iOS related issues that should potentially resurface. The iOS toolchain has considerably changed over the years, and I'm willing to drop work arounds in good faith. Reviewers: bgamari, austin Reviewed By: bgamari Subscribers: rwbarton, thomie GHC Trac Issues: #13559, #7722 Differential Revision: https://phabricator.haskell.org/D3451
* askCc should be using the linker, not the compilerSimon Marlow2017-03-311-6/+7
| | | | | | | | | | | | | | | | | When GHCi tries to find a shared lib, it calls "gcc --print-file-name" to ask gcc where to find it. But since we're looking for libraries, we're really using the linker here, not the C compiler, so we should be respecting the values of -pgml and -optl rather than -pgmc and -optc. Test Plan: validate Reviewers: bgamari, niteria, austin, hvr, erikd Reviewed By: bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3393
View Lorry Controller Status