| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With this change, `Backend` becomes an abstract type
(there are no more exposed value constructors).
Decisions that were formerly made by asking "is the
current back end equal to (or different from) this named value
constructor?" are now made by interrogating the back end about
its properties, which are functions exported by `GHC.Driver.Backend`.
There is a description of how to migrate code using `Backend` in the
user guide.
Clients using the GHC API can find a backdoor to access the Backend
datatype in GHC.Driver.Backend.Internal.
Bumps haddock submodule.
Fixes #20927
|
|
|
|
|
|
|
|
| |
In the validate script we are careful to use the $make variable as this
stores whether we are using gmake, make, quiet mode etc. There was just
this one place where we failed to use it.
Fixes #21598
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This firstly caused spurious output to be emitted (as evidenced by
#21555) but even worse caused a massive coercion to be attempted to be
printed (> 200k terms) which would invariably eats up all the memory of
your computer.
The good news is that removing this trace allows the program to compile
to completion, the bad news is that the program exhibits a core lint
error (on 9.0.2) but not any other releases it seems.
Fixes #21577 and #21555
|
|
|
|
|
|
| |
These were previously incorrect.
Fixes #21553.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit adds module `GHC.Cmm.Dominators`, which provides a wrapper
around two existing algorithms in GHC: the Lengauer-Tarjan dominator
analysis from the X86 back end and the reverse postorder ordering from
the Cmm Dataflow framework. Issue #20726 proposes that we evaluate
some alternatives for dominator analysis, but for the time being, the
best path forward is simply to use the existing analysis on
`CmmGraph`s.
This commit addresses a bullet in #21200.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We previously only checked the stage 1/2 compiler
for --target support. We got away with this for quite a while but it
eventually caught up with us in #21579, where `bytestring`'s new NEON
implementation was unbuildable on Darwin due to Rosetta's seemingly
random logic for determining which executable image to execute. This
lead to a confusing failure to build `bytestring`'s cbits, when `clang`
tried to compile NEON builtins while targetting x86-64.
Fix this by checking CC_STAGE0 for --target support.
Fixes #21579.
|
|
|
|
|
|
|
|
| |
We only support building static profiling libraries, the transformer was
requesting things like a dynamic, threaded, debug, profiling RTS, which
we have never produced nor distributed.
Fixes #21567
|
|
|
|
| |
This seems to fail on the ancient version of bash present on CentOS
|
|
|
|
|
|
|
| |
The centos docker image lacks the sphinx builder so we disable building
sphinx docs for these jobs.
Fixes #21580
|
|
|
|
|
|
|
|
| |
The release flavour is essentially the same as the perf flavour
currently but also enables `-haddock`. I have hopefully updated all the
relevant places where the `-perf` flavour was hardcoded.
Fixes #21486
|
| |
|
|
|
|
| |
Fixes #21336.
|
|
|
|
|
| |
This introduces a global hook which is called when an exception is
thrown during finalization.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
LlvmConfig contains information read from llvm-passes and llvm-targets
files in GHC's top directory. Reading these files is done only when
needed (i.e. when the LLVM backend is used) and cached for the whole
compiler session. This patch changes the way this is done:
- Split LlvmConfig into LlvmConfig and LlvmConfigCache
- Store LlvmConfigCache in HscEnv instead of DynFlags: there is no
good reason to store it in DynFlags. As it is fixed per session, we
store it in the session state instead (HscEnv).
- Initializing LlvmConfigCache required some changes to driver functions
such as newHscEnv. I've used the opportunity to untangle initHscEnv
from initGhcMonad (in top-level GHC module) and to move it to
GHC.Driver.Main, close to newHscEnv.
- I've also made `cmmPipeline` independent of HscEnv in order to remove
the call to newHscEnv in regalloc_unit_tests.
|
|
|
|
|
|
| |
This is now fixed on master and 9.2 branch.
Closes #21558
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When generating an SRT for a recursive group, GHC.Cmm.Info.Build.oneSRT
filters out recursive references, as described in Note [recursive SRTs].
However, doing so for static functions would be unsound, for the reason
described in Note [Invalid optimisation: shortcutting].
However, the same argument applies to static data constructor
applications, as we discovered in #20959. Fix this by ensuring that
static data constructor applications are included in recursive SRTs.
The approach here is not entirely satisfactory, but it is a starting
point.
Fixes #20959.
|
|
|
|
|
|
|
|
|
|
| |
Here we implement a few measures to improve the clarity of the CAF
analysis implementation. Specifically:
* Use CafInfo instead of Bool since the former is more descriptive
* Rename CAFLabel to CAFfyLabel, since not all CAFfyLabels are in fact
CAFs
* Add numerous comments
|
|
|
|
|
| |
Those files were moved to the perf/ subtree in 11c9a469, and then
accidentally reintroduced in 680ef2c8.
|
|
|
|
|
|
| |
This bumps the time submodule to the 1.12.2 release.
Fixes #21571
|
|
|
|
|
|
|
|
|
|
|
|
| |
This MR fixes a bad bug, where the withDict was inlined too
vigorously, which in turn made the type-class Specialiser generate
a bogus specialisation, because it saw the same overloaded function
applied to two /different/ dictionaries.
Solution: inline `withDict` later. See (WD8) of Note [withDict]
in GHC.HsToCore.Expr
See #21575, which is fixed by this change.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We were using defaultSDocContext for pprTrace, which suppresses
lots of useful infomation. This small MR adds
GHC.Utils.Outputable.traceSDocContext
and uses it for pprTrace and pprTraceUserWarning.
traceSDocContext is a global, and hence not influenced by flags,
but that seems unavoidable. But I made the sdocPprDebug bit
controlled by unsafeHasPprDebug, since we have the latter for
exactly this purpose.
Fixes #21569
|
|
|
|
| |
for better disambiguation (#17420)
|
|
|
|
|
|
|
| |
Test that we can successfully link against C++ code both in GHCi and
batch compilation.
See #20010
|
|
|
|
|
|
|
|
| |
Here we introduce a new "virtual" package into the initial package
database, `system-cxx-std-lib`. This gives users a convenient, platform
agnostic way to link against C++ libraries, addressing #20010.
Fixes #20010.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Here we introduce proper support for compilation of C++ objects. This
includes:
* logic in `configure` to detect the C++ toolchain and propagating this
information into the `settings` file
* logic in the driver to use the C++ toolchain when compiling C++
sources
|
| |
|
|
|
|
|
|
|
|
| |
- Remove groupWithName (unused)
- Use the RuntimeRepType synonym where possible
- Replace getUniqueM + mkSysLocalOrCoVar with mkSysLocalOrCoVarM
No functional changes.
|
|
|
|
|
| |
The lack of INLNE arity was exposed by #21531. The fix is
simple enough, if a bit clumsy.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds a CI job (hackage-doc-tarball) which generates the necessary
tarballs for uploading libraries and documentation to hackage. The
release script knows to download this folder and the upload script will
also upload the release to hackage as part of the release.
The `ghc_upload_libs` script is moved from ghc-utils into .gitlab/ghc_upload_libs
There are two modes, preparation and upload.
* The `prepare` mode takes a link to a bindist and creates a folder containing the
source and doc tarballs ready to upload to hackage.
* The `upload` mode takes the folder created by prepare and performs the upload to
hackage.
Fixes #21493
Related to #21512
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Implements #21424.
The RTS macros get_itbl and friends are extremely helpful during debugging.
However only a select few of those were available in the compiled RTS as actual symbols
as the rest were INLINE macros.
This commit marks all of them as EXTERN_INLINE. This will still inline them at use sites
but allow us to use their compiled counterparts during debugging.
This allows us to use things like `p get_fun_itbl(ptr)` in the gdb shell
since `get_fun_itbl` will now be available as symbol!
|
|
|
|
|
|
|
|
|
|
| |
This fixes some bugs where
* -dcore-lint was being passed when building stage1 libraries with the
boot compiler
* -dcore-lint was not being passed when building executables.
Fixes #20135
|
|
|
|
|
|
|
| |
The linting flavour enables -dlint uniformly across anything build by
the stage1 compiler.
-dcmm-lint is not currently enabled because it fails on i386 (see #21563)
|
| |
|
|
|
|
| |
Resolves https://gitlab.haskell.org/ghc/ghc/-/issues/19127
|
| |
|
|
|
|
|
|
|
|
| |
Previously we would flag the symbol as weak but failed
to set its address, which must be computed from an "auxiliary"
symbol entry the follows the weak symbol.
Fixes #21556.
|
|
|
|
| |
This makes it easier to see how resolution failures nest.
|
|
|
|
|
|
|
|
|
| |
Change mulArrow to allow for printing of correct application precedence
where necessary and update callers of mulArrow to reflect this.
As part of this, move mulArrow from GHC/Utils/Outputtable to GHC/Iface/Type.
Fixes #20315
|
|
|
|
|
| |
The documentation still mentioned Derived constraints and
an outdated datatype TcPluginResult.
|
|
|
|
|
| |
Metric Decrease:
T16875
|
| |
|
| |
|
| |
|
|
|
|
| |
Fixes #21546
|