GitLab

This commit didn't consider the fact that binary distributions on Windows must
have relative toolchain paths. This caused #13560.

This reverts commit 48385cb2 (except for a
helpful comment).

(cherry picked from commit 960589e89da3dbf60e88042d7e064ad4a98fb2ff)

Summary:
setProgramDynFlags invalidates the whole module graph, forcing
everything to be re-summarised (including preprocessing) on every
:reload.

Looks like this was a bad regression in 8.0, but we didn't notice
because there was no test for it.  Now there is!

Test Plan:
* validate
* new unit test

Reviewers: bgamari, triple, austin, niteria, erikd, jme

Subscribers: rwbarton, thomie

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

We do not need to keep an enrivonment around to implement letrec, as
long as we only do call-by-name. Instead, evaluate letrec by
substituting for all the variables with their RHS wrapped in the letrec
binding.

Since nothing adds to the enrivonment any more, there is no need for a
S_Var rule.

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

This is a follow-up to df679403
which missed `INSTALL_BINS`

this program should be rejected, but is not (and segfaults).

Previously rmtree's error callback would throw an exception, breaking
out of the retry loop.

Test Plan: Validate on Windows

Reviewers: Phyx, austin

Reviewed By: Phyx

Subscribers: rwbarton, thomie

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

Consider one-line module
    module B (v) where v = "hello"
in -fvia-C mode it generates code like
    static char gibberish_str[] = "hello";

It resides in data section (precious resource on ia64!).
The patch switches genrator to emit:
    static const char gibberish_str[] = "hello";

Other types if symbols that gained 'const' qualifier are:

- info tables (from haskell and CMM)
- static reference tables (from haskell and CMM)

Cleanups along the way:

- fixed info tables defined in .cmm to reside in .rodata
- split out closure declaration into 'IC_' / 'EC_'
- added label declaration (based on label type) right before
  each label definition (based on section type) so that C
  compiler could check if declaration and definition matches
  at definition site.
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>

Test Plan: ran testsuite on unregisterised x86_64 compiler

Reviewers: simonmar, ezyang, austin, bgamari, erikd

Reviewed By: bgamari, erikd

Subscribers: rwbarton, thomie

GHC Trac Issues: #8996

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

This is a derivation of a patch from @jophish.

This is necessary due to `haskeline`'s `terminfo` flag being marked as
`Manual` as of 43d7fa106027fcd4ec7f443923a8dd5b8c169f9c.

Reviewers: jophish, bgamari, austin

Reviewed By: bgamari

Subscribers: rwbarton, thomie, jophish

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

Summary:
Commit b207b536 (#11714) happened to
fix #13603 as well. Let's add a regression test so that it stays fixed.

Test Plan: make test TEST=T13603

Reviewers: bgamari, austin, simonpj

Reviewed By: bgamari, simonpj

Subscribers: simonpj, rwbarton, thomie

GHC Trac Issues: #13603

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

Test Plan: Validate

Reviewers: austin

Subscribers: rwbarton, thomie

GHC Trac Issues: #13587

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

Reviewers: austin

Subscribers: rwbarton, thomie

GHC Trac Issues: #13591

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

By default GhcThreaded is set by
```
GhcThreaded = $(if $(findstring thr,$(GhcRTSWays)),YES,NO)
```
so it seems incorrect to try to build iserv with -threaded when
GhcThreaded is not set. This came up when I was building GHC with
some strange combination of flavours (debugged and profiled but not
threaded).

Test Plan: harbormaster

Reviewers: simonmar, austin, bgamari

Reviewed By: bgamari

Subscribers: thomie, snowleopard

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

The conclusion of #13555 was that a program which began to fail to
typecheck (starting in GHC 8.2) was never correct to begin with. Let's
document why this is the case with respect to `MonoLocalBinds`'
interaction with kind generalization. Also adds the reported program as
a `compile_fail` testcase.

Test Plan: make test TEST=T13555 # Also, read the docs

Reviewers: goldfire, simonpj, austin, bgamari

Reviewed By: goldfire, simonpj, bgamari

Subscribers: rwbarton, thomie

GHC Trac Issues: #13555

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

Further cleanup of the linker, we'll add elf_compat.h for a more
complete set of relocations.

Also Util.h has been added as suggested in the code already.

Depends on D3444, D3445

Reviewers: bgamari, austin, erikd, simonmar

Reviewed By: simonmar

Subscribers: rwbarton, thomie

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

This diff introduces ElfTypes similar to provide the linker
code with a richer data structure, similar to the approach
taken for mach-o already.

Reviewers: bgamari, austin, erikd, simonmar

Reviewed By: simonmar

Subscribers: rwbarton, thomie

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

Reviewers: austin, erikd, simonmar

Reviewed By: erikd

Subscribers: rwbarton, thomie

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

This both says what we mean and silences a bunch of spurious CPP linting
warnings. This pragma is supported by all CPP implementations which we
support.

Reviewers: austin, erikd, simonmar, hvr

Reviewed By: simonmar

Subscribers: rwbarton, thomie

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

While debugging an unrelated issue I noticed that we leak a
TimerQueueTimer on exit since we don't necessarily call stopTicker
before exitTicker. Fix this.

Test Plan: Validate on Windows

Reviewers: simonmar, austin, erikd

Reviewed By: simonmar

Subscribers: rwbarton, thomie

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

Attempt to install cross-compiled mingw32 GHC built on linux failed as:

    $ make install DESTDIR=$(pwd)/__i__

    "mv" "$(pwd)/__i__/usr/local/lib/ghc-8.3.20170422/bin/ghc-stage2" \
         "$(pwd)/__i__/usr/local/lib/ghc-8.3.20170422/bin/ghc"
    mv: failed to stat
         '$(pwd)/__i__/usr/local/lib/ghc-8.3.20170422/bin/ghc-stage2': \
         No such file or directory

The rename should not be performed for windows targets.
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>

The build failure when cross-compiling from
linux to windows looks like:

    HC [stage 1] ghc/stage2/build/tmp/ghc-stage2.exe
      Call hs_init_ghc() from your main() function to set these options.
  /usr/libexec/gcc/i686-w64-mingw32/ld: cannot find -lHSghc-8.3-0

Similar to commit 745032dd
("rts: tweak cross-compilation to mingw32") decision to split
stage2 should be done based based on TargetOS, not HostOS.
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>

This helps ensure that system includes on some more fragile
platforms (like e.g. AIX) see a more consistent set of CPP defines,
and consequently reduce the risk of conflicting typdefs/prototypes
being exposed.

Found the problem on x86_64-linux host where
I tried to cross-compile GHC to windows as:

    $ ./configure --target=i686-w64-mingw32 \
                  Windres=i686-w64-mingw32-windres \
                  DllWrap=i686-w64-mingw32-dllwrap

As a result build failed as POSIX bits of RTS.
For example 'rts/posix/OSMem.c' contains unix-specific
mmap() syscalls and constants and thus can't be compiled
by i686-w64-mingw32 toolchain.

It's caused by the following part of 'rts/ghc.mk':

  ifeq "$(HostOS_CPP)" "mingw32"
  ALL_DIRS += win32
  else
  ALL_DIRS += posix
  endif

In our case _CPP variables are defined this way (project.mk):
  BuildOS_CPP                = linux
  HostOS_CPP                 = linux
  TargetOS_CPP               = mingw32

RTS should never be built for 'BuildOS' or 'HostOS' as it's
always built by ghc-stage1 (targeted at TargetOS).

The change is to flip 'HostOS_CPP' to 'TargetOS_CPP' in 'rts/ghc.mk'.
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>

Noticed when tried to cross-compile GHC from x86_64-linux
to --target=i686-w64-mingw32. Final ghc executables did
not have '.exe' extensions.
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>

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

Summary: Updating to get latest binutils etc.

Test Plan: ./validate

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie, snowleopard

GHC Trac Issues: #12913

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

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

Reviewers: austin, hvr, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie

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

* Add missing filters in EVENT_HEAP_PROF_BEGIN and reorder them
* EVENT_HEAP_PROF_SAMPLE_COST_CENTRE isn't used in retainer profiling
* Modify EVENT_HEAP_PROF_SAMPLE_STRING's format
* Biography break-down isn't implemented