| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
This reverts commit 8736715857d08cc1f88d766c257b39c05df20639.
I hadn't intended on merging this.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously we would prevent any operating system not providing the
MEM_NORESERVE flag
from using the two-step allocator. Afterall, Linux will reserve
swap-space for
a mapping unless this flag is given, which is most certainly not what
we want.
However, it seems that FreeBSD provides the reservation-only mapping
behavior
that we expect despite not providing the MEM_NORESERVE macro. In fact,
it
provided the macro until 2014, when it was removed on account of not
being
implemented in the kernel. However, empirical evidence suggests that
just plain
mmap does what we want.
Reviewers: erikd, simonmar
Subscribers: rwbarton, thomie, erikd, carter
GHC Trac Issues: #15348
Differential Revision: https://phabricator.haskell.org/D4939
|
|
|
|
|
| |
This is an unstable release, hence it must be x.y.$DATE, rather than x.y.0.$DATE
which would denote a stable pre-release snapshot.
|
|
|
|
| |
Bumps haddock submodule.
|
|
|
|
|
|
|
|
| |
Test Plan: Validate with numa support
Subscribers: rwbarton, thomie, erikd, carter
Differential Revision: https://phabricator.haskell.org/D4869
|
|
|
|
| |
Bumps haddock submodule.
|
|
|
|
| |
See #15281
|
|
|
|
|
|
|
|
|
|
|
|
| |
This appears to inexplicably break the OS X build, which fails with:
```
make[1]: *** No rule to make target `utils/unlit/fs.c', needed by
`utils/unlit/dist/build/.depend.c_asm'. Stop.
make[1]: *** Waiting for unfinished jobs....
make: *** [all] Error 2
```
This reverts commit 8ee9c574a6d2105ace858f0fee31750acafe0a0f.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: ./validate
Reviewers: bgamari
Subscribers: rwbarton, thomie, erikd, carter
GHC Trac Issues: #15257
Differential Revision: https://phabricator.haskell.org/D4853
|
|
|
|
| |
This seems to fix a number of segmentation faults.
|
|
|
|
|
|
|
|
| |
On Fedora: `/usr/libexec/sphinx-build --version` outputs `sphinx-build
1.7.2`. In bindir we actually have sphinx-build-2 and sphinx-build-3
(python2 and python3 versions), which output `sphinx-build-2 1.7.2` and
`sphinx-build-3 1.7.2` respectively. Dunno what version others are
using but at least this change should works for most versions I suppose.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This pulls parts of Joachim Breitner's ghc-heap-view library inside GHC.
The bits added are the C hooks into the RTS and a basic Haskell wrapper
to these C hooks. The main reason for these to be added to GHC proper
is that the code needs to be kept in sync with the closure types
defined by the RTS. It is expected that the version of HeapView shipped
with GHC will always work with that version of GHC and that extra
functionality can be layered on top with a library like ghc-heap-view
distributed via Hackage.
Test Plan: validate
Reviewers: simonmar, hvr, nomeata, austin, Phyx, bgamari, erikd
Reviewed By: bgamari
Subscribers: carter, patrickdoc, tmcgilchrist, rwbarton, thomie
Differential Revision: https://phabricator.haskell.org/D3055
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: Validate with Hadrian and `libnuma` support
Reviewers: snowleopard, hvr, erikd, simonmar
Subscribers: izgzhen, alpmestan, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4616
|
|
|
|
|
|
|
|
| |
Reviewers: hvr, bgamari
Subscribers: lelf, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4575
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This shims out fopen and sopen so that they use modern APIs under the hood
along with namespaced paths.
This lifts the MAX_PATH restrictions from Haskell programs and makes the new
limit ~32k.
There are only some slight caveats that have been documented.
Some utilities have not been upgraded such as lndir, since all these things are
different cabal packages I have been forced to copy the source in different places
which is less than ideal. But it's the only way to keep sdist working.
Test Plan: ./validate
Reviewers: hvr, bgamari, erikd, simonmar
Reviewed By: bgamari
Subscribers: rwbarton, thomie, carter
GHC Trac Issues: #10822
Differential Revision: https://phabricator.haskell.org/D4416
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: hvr, bgamari, angerman
Reviewed By: angerman
Subscribers: rwbarton, thomie, erikd, carter, angerman
Differential Revision: https://phabricator.haskell.org/D4513
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: hvr
Subscribers: rwbarton, thomie, erikd, carter
GHC Trac Issues: #14910
Differential Revision: https://phabricator.haskell.org/D4495
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: bgamari, hvr, RyanGlScott
Reviewed By: RyanGlScott
Subscribers: RyanGlScott, rwbarton, thomie, erikd, carter
Differential Revision: https://phabricator.haskell.org/D4509
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Adds quick-cross-ncg flavour.
- Fix windows wchar with `_s` for mingw
- Lookup windres, dllwrap and objdump
- Fix type.
Reviewers: bgamari, hvr, Phyx, erikd, simonmar
Reviewed By: bgamari
Subscribers: rwbarton, thomie, erikd, carter
Differential Revision: https://phabricator.haskell.org/D4430
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
ld.gold is buggy when using -r and a linker script. See upstream bug
https://sourceware.org/bugzilla/show_bug.cgi?id=22266
This has been causing various brokenness for the GHC runtime linker,
where we load these broken object files.
Test Plan: Test program from #14675
Reviewers: bgamari, RyanGlScott, alpmestan, hvr, erikd
Subscribers: rwbarton, thomie, erikd, carter
GHC Trac Issues: #14328, #14675, #14291
Differential Revision: https://phabricator.haskell.org/D4431
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: bgamari, hvr
Reviewed By: bgamari
Subscribers: erikd, hvr, rwbarton, thomie, carter
Differential Revision: https://phabricator.haskell.org/D4378
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GCC's __sync primitives apparently "usually" imply a full barrier,
meaning they can be used to emulate the more precise C11 atomics albeit
with a loss of efficiency. This restores compatibility with GCC 4.4.
This partially reverts commit 59de290928e6903337f31c1f8107ac8a98ea145d.
Test Plan: Validate on Centos
Reviewers: hvr, simonmar, trommler
Subscribers: rwbarton, thomie, erikd, carter
GHC Trac Issues: #14244
Differential Revision: https://phabricator.haskell.org/D4364
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Substitute RanlibCmd for consistency, and other configure cleanups that
should have no effect
The other commands are so substituted. Maybe we don't need ranlib at
all, and the configure snippet can be removed all together, but that
can always be done later.
Reviewers: bgamari, hvr, angerman
Reviewed By: bgamari, angerman
Subscribers: rwbarton, thomie, erikd, carter
Differential Revision: https://phabricator.haskell.org/D4286
|
|
|
|
| |
The ghc-8.4 branch has now been cut. Updates the haddock submodule.
|
|
|
|
|
| |
This is a regression affecting Windows introduced by
3bed4aa703c41ccbd310496420fbb71afdfd99e7.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is in preparation for cabalification of the `rts`. To be actually
able to parse this file, a rather recent Cabal is required. One after
commit 357d49d of haskell/cabal. The relevant PR to support the new
`asm-sources` and `cmm-sources` is haskell/cabal/pull/4857.
Not that this does *not* allow cabal to build the RTS. It does however
provide enough information such that cabal can `copy` and `register`
the package properly in the package database, if all the build
artifacts have been build properly.
As such it does not require any custom handling of the `rts` package.
As the rts as well as all the other packages built by the GHC built
system are built outside of cabal anyway.
Reviewers: bgamari, hvr, erikd, simonmar
Reviewed By: bgamari
Subscribers: rwbarton, thomie, erikd
Differential Revision: https://phabricator.haskell.org/D4174
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: austin, hvr, erikd, simonmar, bgamari
Reviewed By: bgamari
Subscribers: snowleopard, raichoo, rwbarton, thomie, erikd
Differential Revision: https://phabricator.haskell.org/D3994
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
One step closer to being able to drop the Windows Perl tarball. We
previously attempted to do this in D3567 but were forced to revert due
to Windows problems.
Acknowledgements:
* @Phyx kindly contributed the codepath allowing this to work on
Windows.
Test Plan: Validate
Reviewers: hvr, austin, Phyx
Subscribers: erikd, thomie, rwbarton
Differential Revision: https://phabricator.haskell.org/D3918
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For reasons that I don't entirely understand we didn't previously detect
`strip` using autoconf. This naturally broke during cross-compilation.
How did this ever work? I have no idea.
Test Plan: Try cross-compiling
Reviewers: austin, hvr, angerman
Subscribers: rwbarton, thomie, erikd
Differential Revision: https://phabricator.haskell.org/D4008
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Ar was being checked twice prior to D3883 where I removed one of the checks
because the converted path was being overridden after the check because of
the second check for Ar. However the one in configure.ac was a target check
so I'm changing the path check to a target check now.
Test Plan: ./configure
Reviewers: angerman, austin, hvr, bgamari
Reviewed By: bgamari
Subscribers: rwbarton, thomie, erikd
GHC Trac Issues: #14274
Differential Revision: https://phabricator.haskell.org/D4020
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This bumps our LLVM version requirement to LLVM5,
which will likely be released before GHC 8.4.
Test Plan: validate
Reviewers: austin, hvr, bgamari
Reviewed By: bgamari
Subscribers: rwbarton, thomie, erikd
Differential Revision: https://phabricator.haskell.org/D3797
|
|
|
|
|
|
| |
This isn't needed anymore as we don't support GHC < 8 anymore.
This is a follow-up to 122f183
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This tool can be used to generate dll's for any list of object files
given to it. It will then repartition them automatically to fit within
a dll and generates as many dll's as needed to do this. Cyclic dependencies
between these generated dlls are handle automatically so there is no need
to tell it how to partition.
It is also a lot more general than `dll-split` as it is able to split any
package not just `libGHC`. It also uses a trick using GNU style import libraries
to hide the splitting from the rest of the pipeline. Which means come linking time
you don't need to know which dll contains what symbol or how many split dlls were
created.
The import libraries are by default created with libtool. However since libtool is BFD
based it is very slow. So if present and detected by configure the `genlib` tool
from the msys2 project is used. This makes a difference of about ~45 minutes when compiling.
To install `genlib` run `pacman -Sy mingw-w64-$(uname -m)-tools-git`.
More detailed explaination of the process can be found here
https://ghc.haskell.org/trac/ghc/wiki/WindowsDynamicLinking
Test Plan: ./validate
Reviewers: austin, hvr, bgamari, erikd, simonmar
Reviewed By: bgamari
Subscribers: snowleopard, rwbarton, thomie, erikd, #ghc_windows_task_force
GHC Trac Issues: #5987
Differential Revision: https://phabricator.haskell.org/D3883
|
|
|
|
|
|
|
|
| |
Reviewers: austin, hvr
Subscribers: rwbarton, thomie, erikd
Differential Revision: https://phabricator.haskell.org/D3886
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Cabal's parser has been rewritten in terms of Parsec (which is not
enabled yet in Cabal-2.0 by default, but can be enabled by a cabal
flag). The plan for Cabal is to drop support for the non-parsec parser,
so we need to prepare GHC to cope with new situation.
However, this means that lib:Cabal requires three new library
dependency submodules,
- parsec
- text
- mtl
What complicates matters is that we need to build `ghc-cabal` early on
during the bootstrap phase which currently needs to invoke `ghc --make`
directly. So these additional dependencies need to be integrated into
the monolithic `ghc --make` invocation which produces the `ghc-cabal`
executable.
Test Plan: `./validate --fast` passed
Reviewers: austin, bgamari
Subscribers: erikd, phadej, rwbarton, thomie
Differential Revision: https://phabricator.haskell.org/D3757
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Always set dllwrap and windres values.
Reviewers: austin, hvr, bgamari, trofi
Reviewed By: trofi
Subscribers: rwbarton, thomie, erikd
GHC Trac Issues: #13792
Differential Revision: https://phabricator.haskell.org/D3775
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a sure sign that something is terribly wrong.
We also now verify that the word size that the binary distribution
expects matches the word size produced by the local target toolchain.
Finally we rename WordSize to TargetWordSize, since non-host/target
qualified quantities are terribly confusing.
Reviewers: austin, hvr, Phyx
Reviewed By: Phyx
Subscribers: Phyx, rwbarton, thomie, erikd
Differential Revision: https://phabricator.haskell.org/D3711
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The decisions made by configure later in the script may depend upon the
linker used. Consequently, it is important that configure uses the same
linker as GHC will eventually use.
For instance, on Nix I found that a program requiring `libpthread` would
link fine with only `-lrt` when linked with BFD ld. However, with gold
we needed to explicitly provide the `-lpthread` dependency. Presumably
the former would happily loaded any `NEEDED` libraries whereas the
latter wants them explicitly given. Regardless, since `configure`'s
`NEED_PTHREAD_LIB` check didn't use the `-fuse-ld` flag that GHC would
eventually use, we inferred the wrong value, resulting in link errors
later in the build.
Test Plan: Validate
Reviewers: austin, hvr
Subscribers: rwbarton, thomie, erikd
GHC Trac Issues: #13541
Differential Revision: https://phabricator.haskell.org/D3694
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The configure script will now try to coerce gcc to use the linker
pointed to by $LD instead of the system default (typically bfd ld).
Moreover, we now check for `ld.gold` and `ld.lld` before trying `ld`.
The previous behavior can be reverted to by using the new
--disable-ld-override flag.
On my machine gold seems to trigger an apparent infelicity in
constructor behavior, causing T5435_asm to fail. I've opened #13883 to
record this issue and have accepted the questionable constructor
ordering for the time being.
Test Plan: Validate with `config_args='--enable-ld-override'`
Reviewers: austin, hvr, simonmar
Subscribers: duog, nh2, rwbarton, thomie, erikd, snowleopard
GHC Trac Issues: #13541, #13810, #13883
Differential Revision: https://phabricator.haskell.org/D3449
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
deriveConstants requires objdump for both of these operating systems, in
addition to Windows. See #13812.
Test Plan: Validate on OpenBSD and AIX
Reviewers: hvr, austin
Reviewed By: hvr
Subscribers: rwbarton, thomie, erikd
GHC Trac Issues: #13812
Differential Revision: https://phabricator.haskell.org/D3638
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
There are various distros that build GHC using their own C compilers
such as MSYS2. Currently they have to patch the build scripts everytime.
This patch provides the configure argument `--enable-distro-toolchain`
which allows one to build using any C compiler on the path.
This is also useful for testing new versions of GCC.
Test Plan:
./configure --enable-distro-toolchain && make - && make THREADS=9 test
./validate
Reviewers: austin, hvr, bgamari
Reviewed By: bgamari
Subscribers: rwbarton, thomie, erikd, #ghc_windows_task_force
GHC Trac Issues: #13792
Differential Revision: https://phabricator.haskell.org/D3637
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This will qualify the libtool with the target, e.g.
arch-vendor-os-libtool, instead of simply using libtool.
Reviewers: austin, hvr, bgamari
Reviewed By: bgamari
Subscribers: Ericson2314, ryantrinkle, rwbarton, thomie, erikd
Differential Revision: https://phabricator.haskell.org/D3617
|
|
|
|
|
|
| |
This reverts commit 0440af6abe592c2366d302d603664fe763ad0828.
Unfortunately this breaks on Windows for tiresome reasons. I'll need to
reevaluate this.
|
|
|
|
|
|
|
|
|
|
| |
Test Plan: Validate
Reviewers: hvr, austin
Subscribers: rwbarton, thomie, erikd
Differential Revision: https://phabricator.haskell.org/D3567
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The llvm textual ir seems to have stayed sufficiently similar from llvm
3.9 to llvm 4.0, such that a simple bump is possible.
Reviewers: austin, hvr, bgamari, erikd
Reviewed By: bgamari, erikd
Subscribers: rwbarton, thomie, erikd
Differential Revision: https://phabricator.haskell.org/D3591
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This should be handled appropriately by a wrapper script around the compiler,
if one wants to insist on the specific linker to be used. Otherwise this
breaks if the used compiler fails to understand this directive.
I believe that using a specific linker should be part of the compilers
toolchain, we delegate to and not hardcoded here in ghc.
Reviewers: dfeuer, erikd, hvr, austin, rwbarton, bgamari
Reviewed By: bgamari
Subscribers: snowleopard, davean, dfeuer, thomie, erikd
Differential Revision: https://phabricator.haskell.org/D3351
|
|
|
| |
9373994acaf1b73fe0e7cf8e03594c63cec8d235 killed the `--with-*` arguments for `configure`.
|