GitLab

Before this commit, GHC only supported LLVM 3.6. Now it only supports
LLVM 3.7 which was released in August 2015. LLVM version 3.6 and earlier
do not work on AArch64/Arm64, but 3.7 does.

Also:
* Add CC_Ghc constructor to LlvmCallConvention.
* Replace `maxSupportLlvmVersion`/`minSupportLlvmVersion` with
  a single `supportedLlvmVersion` variable.
* Get `supportedLlvmVersion` from version specified in configure.ac.
* Drop llvmVersion field from DynFlags (no longer needed because only
  one version is supported).

Test Plan: Validate on x86_64 and arm

Reviewers: bgamari, austin

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D1320

GHC Trac Issues: #10953

Pushed by mistacke before it was ready.

This reverts commit 5dc3db74.

Reviewers: austin, bgamari

Subscribers: erikd

Differential Revision: https://phabricator.haskell.org/D1303

	modified:   configure.ac

`configure` currently detects when the docbook and hscolour tools aren't
available, and instead of failing outright (as it does for missing alex
and happy), sets some variables in mk/config.mk to tell `make` not to
build the documentation.

Sometimes, however, you want to really make sure all documentation gets
built, fully colourized. For example when making a release. To do so,
you can override the mentioned variables from mk/config.mk in
mk/build.mk (e.g. set HSCOLOUR_SRCS=YES).

This patch adds some error checking to make sure that doing so will not
result in weird build failures when those tools are still missing.

Test Plan: ran `make` a couple of times, with different mk/config.mk settings.

Reviewed by: austin

Differential Revision: https://phabricator.haskell.org/D1232

Cross-compilation on Mac OSX currently doesn't work. While building
stage 1, the build system uses the `ar` for the target architecture
instead of the `ar` for build/host architecture.

The cause is a hack added in 24746fe7
(2010), to supporting bootstrap compilers built with older versions of
Xcode. Xcode 4.3 started installing command line tools in a different
location. Assuming this all behind us now, and the paths didn't change
again (you never now), we can delete the hack.

Deleting the hack fixes the cross compilation issue. Tested by Trac user
jakzale.

Reviewed by: austin

Differential Revision: https://phabricator.haskell.org/D1231

Recent changes (commit 0d1a8d09) for 64 bit platforms allowed GHC
to mmap one huge (currently 1 terrabyte) memory region from which to
do its own allocations. This is enabled by default, but it would be
nice (even just from the point of view of testing) to be able to
disable this at configure time.

Test Plan: configure and grep mk/config.h for USE_LARGE_ADDRESS_SPACE

Reviewers: austin, ezyang, bgamari, rwbarton

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D1170

GHC Trac Issues: #10791

This patch does a few things

- Moved GHC x86 to MinGW-w64 (Using Awson's patch)
- Moves Both GHCs to MSYS2 toolchains
- Completely removes the dependencies on the git tarball repo
  - Downloads only the required tarball for the architecture for
    which we are building
  - Downloads the perl tarball is missing as well
  - Fixed a few bugs in the linker to fix tests on Windows

The links currently point to repo.msys2.org and GitHub, it might be
more desirable to mirror them on
http://downloads.haskell.org/~ghc/mingw/ as with the previous patch
attempt.

For more details on what the MSYS2 packages I include see #10726
(Awson's comment). but it should contain all we need
and no python or fortran, which makes the uncompressed tar a 1-2
hundreds mb smaller.

The `GCC 5.2.0` in the package supports `libgcc` as a shared library,
this is a problem since
when compiling with -shared the produced dll now has a dependency on
`libgcc_s_sjlj-1.dll`.
To solve this the flag `-static-libgcc` is now being used for all GCC
calls on windows.

Test Plan:
./validate was ran both on x86 and x86_64 windows and compared against
the baseline.

A few test were failing due to Ld no longer being noisy. These were
updated.

The changes to the configure script *should* be validated by the build
bots for the other platforms before landing

Reviewers: simonmar, awson, bgamari, austin, thomie

Reviewed By: thomie

Subscribers: #ghc_windows_task_force, thomie, awson

Differential Revision: https://phabricator.haskell.org/D1123

GHC Trac Issues: #10726, #9014, #9218, #10435

This fixes the FreeBSD build.

Currently checking out the source on windows requires two git
checkouts. One for the GHC sources and one for the GHC-tarballs.

This patch will make configure issue an error if compiling under
windows and the GHC-tarballs folder is missing.

On failure the user is told which command they need to run to get the
tarballs or if they want configure to handle it for them configure
provide the `--enable-tarballs-autodownload` flag.

Test Plan:
1. make sure ghc-tarballs folder is not present
2. run ./configure which should fail giving an error that tarballs is
missing and how to get it
3. run ./configure --enable-tarballs-autodownload and the tarballs
should be downloaded and configure finishes
4. rerun the command in 3, no new download should be done.
5. run configure without --enable-tarballs-autodownload, configure
should finish correctly.

Reviewers: bgamari, austin, thomie

Reviewed By: thomie

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D1108

GHC Trac Issues: #10705

Summary:
The current OS memory allocator conflates the concepts of allocating
address space and allocating memory, which makes the HEAP_ALLOCED()
implementation excessively complicated (as the only thing it cares
about is address space layout) and slow. Instead, what we want
is to allocate a single insanely large contiguous block of address
space (to make HEAP_ALLOCED() checks fast), and then commit subportions
of that in 1MB blocks as we did before.
This is currently behind a flag, USE_LARGE_ADDRESS_SPACE, that is only enabled for
certain OSes.

Test Plan: validate

Reviewers: simonmar, ezyang, austin

Subscribers: thomie, carter

Differential Revision: https://phabricator.haskell.org/D524

GHC Trac Issues: #9706

Extend the PowerPC 32-bit native code generator for "64-bit
PowerPC ELF Application Binary Interface Supplement 1.9" by
Ian Lance Taylor and "Power Architecture 64-Bit ELF V2 ABI Specification --
OpenPOWER ABI for Linux Supplement" by IBM.
The latter ABI is mainly used on POWER7/7+ and POWER8
Linux systems running in little-endian mode. The code generator
supports both static and dynamic linking. PowerPC 64-bit
code for ELF ABI 1.9 and 2 is mostly position independent
anyway, and thus so is all the code emitted by the code
generator. In other words, -fPIC does not make a difference.

rts/stg/SMP.h support is implemented.

Following the spirit of the introductory comment in
PPC/CodeGen.hs, the rest of the code is a straightforward
extension of the 32-bit implementation.

Limitations:
* Code is generated only in the medium code model, which
  is also gcc's default
* Local symbols are not accessed directly, which seems to
  also be the case for 32-bit
* LLVM does not work, but this does not work on 32-bit either
* Must use the system runtime linker in GHCi, because the
  GHC linker for "static" object files (rts/Linker.c) for
  PPC 64-bit is not implemented. The system runtime
  (dynamic) linker works.
* The handling of the system stack (register 1) is not ELF-
  compliant so stack traces break. Instead of allocating a new
  stack frame, spill code should use the "official" spill area
  in the current stack frame and deallocation code should restore
  the back chain
* DWARF support is missing

Fixes #9863

Test Plan: validate (on powerpc, too)

Reviewers: simonmar, trofi, erikd, austin

Reviewed By: trofi

Subscribers: bgamari, arnons1, kgardas, thomie

Differential Revision: https://phabricator.haskell.org/D629

GHC Trac Issues: #9863

* distrib/configure.ac.in : Detect correct version of LLVM tools as
  was done for the top level configure.ac in 42448e37.
* aclocal.m4 : Add a FIND_LD macro that can be used in both
  configure scripts.
* Use new FIND_LD macro in both configure scripts.
Signed-off-by: Erik de Castro Lopo <erikd@mega-nerd.com>

Test Plan: validate on amd64-linux and armhf-linux.

Reviewers: rwbarton, austin

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D828

GHC Trac Issues: #10234

The LLVM developers seem to make breaking changes in the LLVM IR
language between major releases. As a consumer of the LLVM tools
GHC now needs to be locked more tightly to a single version of
the LLVM tools.

GHC HEAD currently only supports LLVM version 3.6. This commit
changes the configure script to look for `llc-3.6` and `opt-3.6`
before looking for `llc` and `opt`. If the former are not found,
but the later are, check that they actually are version 3.6.

At the same time, when detecting known problems with the LLVM
tools (ie #9439) test for it using the versions of the LLVM tools
retrieved from the bootstrap compiler's settings file.

Test Plan: Manual testing.

Reviewers: thomie, rwbarton, nomeata, austin

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D745

GHC Trac Issues: #10170

Fixes #8976 and #9873 by making use of the Binutils ld.gold
linker explicit whenever the target is linux/ARM or android/ARM.
This does not affect iOS where Apple provides its own linker.

In order to achieve this, we need to add `-fuse-ld=gold` to
the SettingsCCompilerLinkFlags setting and set
SettingsLdCommand to `ld.gold` (or `${target}-ld.gold` when
cross-compiling). In addition, simplifying the use of
`$(CONF_GCC_LINKER_OPTS_STAGEn)`.

This patch was tested by ensuring that the following worked
as expected:

  * Native builds on linux/x86_64 (nothing changed).
  * Native builds on linux/arm (and uses the gold linker).
  * Linux to linux/arm cross compiles (and uses the cross
    gold linker).

Contributions by Ben Gamari, Joachim Breitner and Reid Barton.

Reviewers: nomeata, bgamari, austin, rwbarton

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D715

GHC Trac Issues: #8976 #9873

Summary:
Four bug fixes and a little refactoring.
* `find -perm \mode` should be `find -perm /mode` (#9697)

* `find -regex '$3' should be `find -regex "$3"` (#7661)

From `man sh` on my system (Ubuntu 14.04):
"Enclosing characters in single quotes preserves the literal meaning of all
the characters ..."

* LlcCmd and OptCmd should be passed to ghc, using `-pgmlo` and `-pgmlc`, for
  detection of #9439.

* -pgmlo and -pgmlc were undocumented because of an xml tag misplacement.

Test Plan:
The aclocal.m4 macro has seen about 10 iterations since its inception. Without a
testsuite, I can't guarantee this version is bug free either. It's all pretty
frustrating.

Reviewers: bgamari, austin

Reviewed By: austin

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D683

GHC Trac Issues: #9697, #7661, #9439

Summary:
If curses is installed into some non-standard path, we currently have
to say something like the following in mk/build.mk:

  libraries/terminfo_CONFIGURE_OPTS += \
      --configure-option=--with-curses-includes=/somewhere/include \
      --configure-option=--with-curses-libraries=/somewhere/lib

This is because the top-level configure does not accept nor propagate
--with-curses-{includes,libraries} to libraries while it does so for
iconv, gmp and libffi. It would be nice if curses were handled in the
same manner.

Test Plan: Install curses into some non-standard path. Then run the top-level "configure" script with options "--with-curses-includes=/path/to/curses/include" and "--with-curses-libraries=/path/to/curses/lib".

Reviewers: austin

Reviewed By: austin

Subscribers: thomie, PHO

Differential Revision: https://phabricator.haskell.org/D665

GHC Trac Issues: #10096

Reviewers: carter, austin

Reviewed By: austin

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D648

GHC Trac Issues: #9094

Summary:
The relevant aspect is that the libffi configuration's AC_CHECK_LIB
and AC_CHECK_HEADERS are moved after FIND_GCC. There are two reasons
to do this:

1. We should detect the presence of libffi using the C compiler
that we are eventually going to use to build GHC.

2. Running AC_CHECK_HEADERS before FIND_GCC pollutes the CPP variable
with "gcc -E" (wrong when cross-compiling), and CPP is not reset
by FIND_GCC. Thus this patch fixes x86_64 -> i386 cross-compilation
of integer-gmp2.

Test Plan: Local x86_64 -> i386 cross-compiling validate; Harbormaster

Reviewers: austin

Reviewed By: austin

Subscribers: erikd, carter, thomie

Differential Revision: https://phabricator.haskell.org/D597

This needs to update the Haddock submodule as well
Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>

This reverts commit 18bf6d5d.

We forgot to tweak some of the submodule bounds. Fixes incoming soon.

Signed-off-by: Austin Seipp <austin@well-typed.com>

Since we switched to a Git submodule based GHC Git repo, `ghc.git`'s
commit id uniquely identifies the state of the GHC source-tree. So
having that information embedded into the `ghc` executable provides
valuable information to track accurately (especially when created by
buildbots) from which source-tree-state a given `ghc` snapshot
(distribution) was generated.

So this commit adds a new field `"Project Git commit id"` to the
`ghc --info` meta-data containing the `./configure`-time Git commit id
as reported by `git rev-parse HEAD`.

This field can also be queried with `ghc --print-project-git-commit-id`.

For source distributions, the file `GIT_COMMIT_ID` is created (with some
sanity checking to detect stale commit ids, as that would render this
information rather useless)

Reviewed By: austin

Differential Revision: https://phabricator.haskell.org/D528

Signed-off-by: Austin Seipp <austin@well-typed.com>

Reviewers: bgamari, austin

Reviewed By: austin

Subscribers: thomie, carter

Differential Revision: https://phabricator.haskell.org/D500

GHC Trac Issues: #9807

Summary: We should escape path to ghc.On wondows usually ghc comes from HP, which is installed somewhere in "...\Haskell Platform\..." Note space in the middle.

Test Plan: not necessary

Reviewers: rwbarton, hvr, austin

Reviewed By: rwbarton, hvr, austin

Subscribers: rwbarton, simonmar, ezyang, carter, thomie

Projects: #ghc

Differential Revision: https://phabricator.haskell.org/D304

Summary:
Patch does the following:
- fixes detection of working libbfd on modern linux
  platforms (where bfd_uncompress_section_contents is a macro)
- disables 'bfd' by default and adds '--enable-bfd-debug'
  configure option. As bfd's ABI is unstable
  the feature is primarily useful by ghc hackers.

Not done (subject for another patch):
- one-time bfd object memory leak in DEBUG_LoadSymbols
- in '-dynamic' mode debugging symbols are loaded only for
  current executable, not all libraries it is linked against.

Fixes Issue #8790
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>

Test Plan: built unregisterised ghc on amd64 and ran './hello +RTS -Di' there

Reviewers: simonmar, austin

Reviewed By: simonmar, austin

Subscribers: thomie, simonmar, ezyang, carter

Differential Revision: https://phabricator.haskell.org/D193

GHC Trac Issues: #8790

Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>

Summary:
Per the usual standards, a build of GHC is only compileable
by the last two releases (e.g. 7.8 only by 7.4 and 7.6). To make sure
we don't get suckered into supporting older compilers, let's remove
this support now.
Signed-off-by: Austin Seipp <austin@well-typed.com>

Test Plan:
Try to bootstrap with GHC 7.4, watch it fail. Bootstrap
with 7.6 or better, and everything works.

Reviewers: hvr

Reviewed By: hvr

Subscribers: simonmar, ezyang, carter

Differential Revision: https://phabricator.haskell.org/D167

Summary:
Bug #9439 will cause miscompilation of GHC's LLVM backend. Here we
ensure that an affected compiler isn't used to bootstrap.

Test Plan: Attempt to bootstrap GHC with an affected stage 0 compiler.

Reviewers: rwbarton, austin

Reviewed By: austin

Subscribers: simonmar, relrod, ezyang, carter

Differential Revision: https://phabricator.haskell.org/D159

Summary:
Solaris 11 distributed GNU C 4.5.x is configured in a way that its
CPP is not working well while invoked from GHC. GHC runs it with
-x assembler-with-cpp and in this particular configuration GNU C CPP
does not provide any line-markers so GHC's output of errors or warnings
is confusing since it points to preprocessed file in /tmp and not
to the original Haskell file. Fortunately old GNU C 3.4.x is still
provided by the OS and when installed it'll be used automatically
as GHC CPP which is whole logic of this patch. So although we use modern
GCC as a C compiler and assembler we use old GCC as a C preprocessor.

Test Plan: validate

Reviewers: austin

Reviewed By: austin

Subscribers: phaskell, simonmar, relrod, ezyang, carter

Differential Revision: https://phabricator.haskell.org/D151

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Summary:
This hugs heritage gone away with commit f1dffa02
in 2001
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>

Test Plan: tried to find HAVE_BIN_SH in internet, no success

Reviewers: simonmar, austin

Reviewed By: austin

Subscribers: phaskell, simonmar, relrod, ezyang, carter

Differential Revision: https://phabricator.haskell.org/D117

Summary:
Another macro borrowed from hugs, gone aways in
commit 528a7d2cSigned-off-by: Sergei Trofimovich <slyfox@gentoo.org>

Test Plan: build-tested

Reviewers: simonmar, austin, ezyang

Reviewed By: austin, ezyang

Subscribers: phaskell, simonmar, relrod, ezyang, carter

Differential Revision: https://phabricator.haskell.org/D118

Signed-off-by: Austin Seipp <austin@well-typed.com>

Summary:
Allow the CPP program and flag choices for GHC
be configured via the the ghc settings file

Test Plan: ran validate yesterday

Reviewers: hvr, austin, mzero, simonmar

Reviewed By: austin, mzero, simonmar

Subscribers: mzero, simonmar, relrod, carter

Differential Revision: https://phabricator.haskell.org/D26