GitLab

This macro is doubly redundant, first off all, ancient GCCs prior to
version 3.0 are not supported anymore, but more importantly, we require
a ISO C99 compliant compiler, so we can use the proper ISO C syntax
without worrying about compatibility.

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: carter, thomie

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

Saves us a CPP #if in MachDeps.h since we now can always rely on a
64-bit type being available.

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: thomie, erikd

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

Test Plan: Read it

Reviewers: hvr, austin

Subscribers: carter, thomie

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

GHC Trac Issues: #11744

The version of `haddock` that ghc has as a submodule has an option
for generating linkified sources. I don't think it hurts to have this
and they are great for exploring the codebase.

I'd be nice if harbormaster or travis published them somewhere, but
I don't know how to do that yet.

Test Plan:
uncomment, run `make` and look at the
nicely linkified sources in `compiler/stage2/doc/html/ghc/`

Reviewers: hvr, austin, bgamari

Reviewed By: bgamari

Subscribers: thomie, simonmar

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

This fixes a build-failure on OSX

Summary:
Systools makes some pretty hard assumptions about where GHC is on Windows.
One of these is that ghc be in a folder named `bin` and that `../lib` exists.

This pattern doesn't hold for symlinks as a link `C:\ghc-bin\`
pointing to `C:\ghc\ghc-7.10.3\bin` will break this assumption.

This patch resolves symlinks by finding where they point to and uses that location
as the base for GHC.

This uses an API that's been introduced in Vista. For older systems it falls back to
the current behavior of not resolving symlinks.

Test Plan:
1) Create symlink to GHC's bin folder.
2) Run GHC from that folder.

Reviewers: austin, bgamari

Reviewed By: austin

Subscribers: #ghc_windows_task_force, thomie

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

GHC Trac Issues: #11759

Test Plan:
 - Run tests on x86_64/linux, x86_64/darwin and powerpc/linux
 - Cross compile rts/Linker.c with the i686-w64-mingw32-gcc and
   x86_64-w64-mingw32-gcc Linux to Windows cross-compilers.

Reviewers: hvr, austin, thomie, bgamari, simonmar, Phyx

Reviewed By: Phyx

Subscribers: thomie

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

Prevent shared objects from being unloaded if cost centre stacks point
at the object. This will prevent segfault in #11776, but also prevents
objects from ever being unloaded when profiling. Pruning CCS tree will
enable that in another diff.

Test Plan: make TEST=linker_profiled, examine linker_profiled.run.stderr

Reviewers: austin, simonmar, bgamari

Reviewed By: simonmar, bgamari

Subscribers: thomie

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

GHC Trac Issues: #11776

Non-exhaustive pattern warnings had their number of patterns to
show hardcoded in the past. This patch implements the TODO remark
that this should be made a command line flag.

    -fmax-uncovered-patterns=<n>

can now be used to influence the number of patterns to be shown.

Reviewers: hvr, austin, bgamari

Reviewed By: bgamari

Subscribers: thomie

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

Reviewers: hvr, goldfire, austin, RyanGlScott, bgamari

Reviewed By: RyanGlScott, bgamari

Subscribers: RyanGlScott, thomie

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

Summary:
Import libraries are files ending in `.dll.a` and `.lib` depending on which
compiler creates them (GCC, vs MSVC).

Import Libraries are standard `archive` files that contain object files.
These object files can have two different formats:

1) The normal COFF Object format for object files
    (contains all ascii data and very little program code, so do not
     try to execute.)
2) "short import" format which just contains a symbol name and
   the dll in which the symbol can be found.

Import Libraries are useful for two things:

1) Allowing applications that don't support dynamic linking to
   link against the import lib (non-short format) which then
   makes calls into the DLL by loading it at runtime.

2) Allow linking of mutually recursive dlls. if `A.DLL` requires
   `B.DLL` and vice versa, import libs can be used to break the cycle
   as they can be created from the expected exports of the DLLs.

A side effect of having these two capabilities is that Import libs are often
used to hide specific versions of DLLs behind a non-versioned import lib.

e.g. GCC_S.a (non-conventional import lib) will point to the correct
`libGCC` DLL. With this support Windows Haskell files can now just link
to `-lGCC_S` and not have to worry about what the actual name of libGCC is.

Also third party libraries such as `icuuc` use import libs to forward to
versioned DLLs. e.g. `icuuc.lib` points to `icuuc51.dll` etc.

Test Plan:
./validate

Two new tests added T11072gcc T11072msvc

Two binary files have been added to the test folder because the "short"
import library format doesn't seem to be creatable via `dlltool`
and requires Microsoft's `lib.exe`.

Reviewers: bgamari, RyanGlScott, erikd, goldfire, austin, hvr

Reviewed By: RyanGlScott, erikd

Subscribers: thomie

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

GHC Trac Issues: #11072

Rather than using the non-standard/idiomatic `--with-{gcc,clang}=...`
scheme use the `CC=...` style scheme.

The basic idea is to have Autoconf's CC/CFLAG/CPPFLAG apply to
stage{1,2,3}, while having a separate _STAGE0 set of env-vars
denote the bootstrap-toolchain flags/programs.

This should be simpler, less confusing, and somewhat more in line with
Autoconf's idioms (allowing us to reuse more of Autoconf rather than
(re)inventing our own confusing non-standard m4 macros to do stuff that
Autoconf could almost do already for us)

Morever, expose CC_STAGE0 as a so-called "precious" variable.

So now we can better control which bootstrapping gcc is used
(by default the one used by the stage0 ghc, unless CC_STAGE0 is
overriden)

```
Some influential environment variables:
  CC_STAGE0   C compiler command (bootstrap)
  CC          C compiler command
  CFLAGS      C compiler flags
  ...

Use these variables to override the choices made by `configure' or to
help it to find libraries and programs with nonstandard names/locations.
```

Test Plan: I've tested that cross-compiling with
`--target=powerpc-linux-gnu` still works, and tried a few variants of
settting `CC=` and `CC_STAGE0=`; `./validate` passed as well

Reviewers: erikd, austin, bgamari, simonmar

Reviewed By: simonmar

Subscribers: Phyx, thomie

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

Add a sanity check ensuring that nm emits valid hexadecimal output, as
required by POSIX. See #11744 for motivation.

Reviewers: austin, bgamari

Subscribers: thomie

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

GHC Trac Issues: #11744

Reported in #11777.

Test Plan: Try configure in an environment with older `libdw`

Reviewers: hvr, austin

Subscribers: thomie, erikd

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

GHC Trac Issues: #11820

This patch tides up the structure, simplifying FlattenTvResult.

It also replaces a use of zonkTcType (which I hated) with
coercionKind, in that same function.  Happily, the result is
little faster, maybe even a percentage point or two, which is
a lot for a compiler.

This also removes the line
   || not (map binderVisibility bndrs1 == map binderVisibility bndrs2)
from TcCanonical.can_eq_nc', in the ForAllTy/ForAllTy case.

Why? Becuase I can't see why binder-visiblity should matter, and
when we use coercionKind instead of zonkTcType in flattenTyVar,
this case pops up and rejects a program that should pass.  I did
discuss this with Richard.

Test Plan: Read it

Reviewers: austin, kosmikus

Reviewed By: kosmikus

Subscribers: thomie

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

GHC Trac Issues: #11318, #11762

Test Plan: Validate on OS X

Reviewers: erikd, austin, Phyx

Reviewed By: austin, Phyx

Subscribers: Phyx, thomie

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

GHC Trac Issues: #11828

Test Plan: Validate

Reviewers: austin

Reviewed By: austin

Subscribers: thomie

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

GHC Trac Issues: #11827

Test Plan: Validate

Reviewers: goldfire, austin

Reviewed By: austin

Subscribers: thomie

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

GHC Trac Issues: #11824

Test Plan: Validate

Reviewers: gridaphobe, austin

Reviewed By: austin

Subscribers: thomie

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

This is a further fix for #11814

Summary:
`varSetElemsWellScoped` uses `varSetElems` under the hood which
introduces unnecessary nondeterminism.
This does the same thing, possibly cheaper, while preserving
determinism.

Test Plan: ./validate

Reviewers: simonmar, goldfire, austin, bgamari, simonpj

Reviewed By: simonpj

Subscribers: thomie, RyanGlScott

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

GHC Trac Issues: #4012

Fixes Trac #11793.  Nothing deep here.

When you do `varSetElems (tyCoVarsOfType x)` it's equivalent to
`tyCoVarsOfTypeList x`.

Why? If you look at the implementation:
```
tyCoVarsOfTypeList ty = runFVList $ tyCoVarsOfTypeAcc ty
tyCoVarsOfType ty = runFVSet $ tyCoVarsOfTypeAcc ty
```
they use the same helper function. The helper function returns a
deterministically ordered list and a set. The only difference
between the two is which part of the result they take. It is redundant
to take the set and then immediately convert it to a list.

This helps with determinism and we eventually want to replace the uses
of `varSetElems` with functions that don't leak the values of uniques.
This change gets rid of some instances that are easy to kill.

I chose not to annotate every place where I got rid of `varSetElems`
with a comment about non-determinism, because once we get rid of
`varSetElems` it will not be possible to do the wrong thing.

Test Plan: ./validate

Reviewers: goldfire, austin, simonmar, bgamari, simonpj

Reviewed By: simonpj

Subscribers: thomie

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

GHC Trac Issues: #4012

in order to have precise used-once information in the exported
strictness signatures, as well as precise used-once information on
thunks. This avoids the bad effects of #11731.

The subsequent worker-wrapper pass is responsible for removing the
demand environment part of the strictness signature. It does not run
after the final demand analyzer pass, so remove this also in CoreTidy.

The subsequent worker-wrapper pass is also responsible for removing
used-once-information from the demands and strictness signatures, as
these might not be preserved by the simplifier. This is _not_ done by
CoreTidy, because we _do_ want this information, as produced by the last
round of the demand analyzer, to be available to the code generator.

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

This looks like some traces of an experiment to check if shadowing is good for
STG. The code refers to things that don't exist anymore and this part of
code hasn't been touched for ages, so I think this should be safe to
remove.

Test Plan: just comments

Reviewers: austin, bgamari, simonpj

Reviewed By: simonpj

Subscribers: thomie, simonmar

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