While windows and macOS are currently on case-insensitive file
systems, this poses no issue on those.  When cross compiling from
linux with a case sensitive file system and mingw providing only
lowercase headers, this in fact produces an issue.  As such we just
lowercase the import headers, which should still work fine on a
case insensitive file system and also enable mingw's headers to
be usable porperly.

Takenobu Tani authored 6 years ago and Marge Bot committed 6 years ago

This moves all URL references to Trac Wiki to their corresponding
GitLab counterparts.

This substitution is classified as follows:

1. Automated substitution using sed with Ben's mapping rule [1]
    Old: ghc.haskell.org/trac/ghc/wiki/XxxYyy...
    New: gitlab.haskell.org/ghc/ghc/wikis/xxx-yyy...

2. Manual substitution for URLs containing `#` index
    Old: ghc.haskell.org/trac/ghc/wiki/XxxYyy...#Zzz
    New: gitlab.haskell.org/ghc/ghc/wikis/xxx-yyy...#zzz

3. Manual substitution for strings starting with `Commentary`
    Old: Commentary/XxxYyy...
    New: commentary/xxx-yyy...

See also !539

[1]: https://gitlab.haskell.org/bgamari/gitlab-migration/blob/master/wiki-mapping.json

Ben Gamari authored 6 years ago and Marge Bot committed 6 years ago

The splitter is an evil Perl script that processes assembler code.
Its job can be done better by the linker's --gc-sections flag. GHC
passes this flag to the linker whenever -split-sections is passed on
the command line.

This is based on @DemiMarie's D2768.

Fixes Trac #11315
Fixes Trac #9832
Fixes Trac #8964
Fixes Trac #8685
Fixes Trac #8629

Simon Jakobi authored 7 years ago and Ben Gamari committed 7 years ago

The variable was already unused when the file was introduced in
b35a6ce0.

Reviewers: bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie, carter

GHC Trac Issues: #11777

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

Do not use $SHELL as $SHELL is the user's preferred interactive shell.
We do not want this to leak into the wrapper scripts.

Summary:
It seems the call that caused issues with the gcc wrapper before
was needed for the ghci wrapper in order for the child process
to be the one handling console events.

This code slightly refactors the wrappers to make sure only ghci
calls FreeConsole and nothing else.

Test Plan: ./validate , open ghci.exe press ctrl+c

Reviewers: RyanGlScott, austin, hvr, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie, erikd

GHC Trac Issues: #14150

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

Summary:
Initial implementation of split-section on Windows.

This also corrects section namings and uses the platform
convention of `$` instead of `.` to separate sections.

Implementation is based on @awson's patches to binutils.

Binutils requires some extra help when compiling the libraries
for GHCi usage. We drop the `-T` and use implicit scripts to amend
the linker scripts instead of replacing it.

Because of these very large GHCi object files, we need big-obj support,
which will be added by another patch.

Test Plan: ./validate

Reviewers: awson, austin, bgamari

Subscribers: dfeuer, rwbarton, thomie, snowleopard, #ghc_windows_task_force

GHC Trac Issues: #12913

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

This reverts commit d6cecde5.

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.

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: Escape `\` in paths on Windows in `cwapper.c` when we re-output the paths.

Test Plan: ./validate

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: rwbarton, thomie

GHC Trac Issues: #13666

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

Our new CPP linter enforces this.

Ben Gamari authored 7 years ago and Ben Gamari committed 7 years ago

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

When Stage1Only=YES install mode is used one of rare tools
that lack $(CrossCompilePrefix) prefix are 'runghc' and 'ghci'.

This causes file collisions when multiple GHC crosscompilers
are installed in system.

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

Tamar Christina authored 8 years ago and Ben Gamari committed 8 years ago

In Windows 10 Insiders build 15019+ which will probably be released
mainstream somewhere this year Microsoft seems to have started being
stricter with API calls.

The call to `FreeConsole` just after `CreateProcess` is making Windows
treat the process
as an interactive process. In which case it tries to use the `Desktop
session` but fails resulting
in the cryptic error reported.

I don't understand why the call to `FreeConsole` was there and it
doesn't seem to be needed,
so removed.

This fixes #13411

Test Plan: ./validate, alternative just do anything with ghc which
requires compilation.

Reviewers: austin, bgamari, simonmar

Reviewed By: bgamari

Subscribers: rwbarton, thomie, #ghc_windows_task_force

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

dobenour authored 8 years ago and Ben Gamari committed 8 years ago

Test Plan: GHC CI

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: thomie

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

Before, we detecting the presence of MinTTY on Windows in a very
imprecise way: by checking if the `_` environment variable was set. Not
only is this easy to circumvent, but it also yields false positives on
terminals like ConEmu.

This changes the test to use the `GetFileInformationByHandleEx` function
instead, which provides a far more accurate check for MinTTY's presence.
I've tested this on PowerShell, MSYS2, Cygwin, ConEmu, and Git Bash, and
it does the right thing on each one.

Fixes #12958.

Test Plan: Run GHCi on many different Windows and MinTTY consoles

Reviewers: erikd, Phyx, austin, bgamari

Reviewed By: Phyx, bgamari

Subscribers: thomie, #ghc_windows_task_force

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

GHC Trac Issues: #12958

Summary:
Everytime we upgrade the GCC version this wrapper needed updating.
This is a big fragile and we kept forgetting it.

Instead automate it so we don't have to worry about it.

Test Plan: ./validate

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: thomie, #ghc_windows_task_force

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

GHC Trac Issues: #12871

Tamar Christina authored 8 years ago and Ben Gamari committed 8 years ago

Test Plan: None really, as none of our tests cover this usage. Probably
should add one..

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: thomie, #ghc_windows_task_force

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

GHC Trac Issues: #12871

dobenour authored 8 years ago and Ben Gamari committed 8 years ago

Test Plan: GHC CI

Reviewers: austin, bgamari

Reviewed By: bgamari

Subscribers: snowleopard, thomie

Maniphest Tasks: T74

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

seraphime authored 8 years ago and Thomas Miedema committed 8 years ago

Change help message so it doesn't specify -auto-all.
Make old profiling flags deprecated as they are no longer
documented.
Update Makefile and documentation accordingly.
Update release notes for ghc 8.2

Test Plan:
./verify; `ghc --help` shouldn't specify the -auto-all
flag. Furthermore `ghc -fprof -auto-all` should emit a warning

Reviewed By: thomie, austin

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

GHC Trac Issues: #12084

Update submodule nofib

Reviewers: austin, hvr, bgamari, thomie

Reviewed By: thomie

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

olsner authored 9 years ago and Ben Gamari committed 9 years ago

This adds a flag -split-sections that does similar things to
-split-objs, but using sections in single object files instead of
relying on the Satanic Splitter and other abominations. This is very
similar to the GCC flags -ffunction-sections and -fdata-sections.

The --gc-sections linker flag, which allows unused sections to actually
be removed, is added to all link commands (if the linker supports it) so
that space savings from having base compiled with sections can be
realized.

Supported both in LLVM and the native code-gen, in theory for all
architectures, but really tested on x86 only.

In the GHC build, a new SplitSections variable enables -split-sections
for relevant parts of the build.

Test Plan: validate with both settings of SplitSections

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

Reviewed By: simonmar, thomie, bgamari

Subscribers: hsyl20, erikd, kgardas, thomie

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

GHC Trac Issues: #8405

This will allow fixing #1851 more easily
("make install-strip" should work).

This reverts 57e2a81c:
  "On Cygwin, use a Cygwin-style path for /bin/install's destination"

Update submodule haddock and hsc2hs.

Tamar Christina authored 9 years ago and Ben Gamari committed 9 years ago

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

Summary:
Shorten long lines in DynFlags.
Describe --show-options in ghci usage guide.

Reviewers: jstolarek, austin

Reviewed By: jstolarek, austin

Subscribers: thomie, carter

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

GHC Trac Issues: #9259

This reverts commit 35672072.

Conflicts:
	compiler/main/DriverPipeline.hs

Reviewers: rwbarton, austin

Reviewed By: rwbarton, austin

Subscribers: rwbarton, thomie, carter, ezyang, simonmar

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

Summary:
In preparation for indirecting all references to closures,
we rename _closure to _static_closure to ensure any old code
will get an undefined symbol error.  In order to reference
a closure foobar_closure (which is now undefined), you should instead
use STATIC_CLOSURE(foobar).  For convenience, a number of these
old identifiers are macro'd.

Across C-- and C (Windows and otherwise), there were differing
conventions on whether or not foobar_closure or &foobar_closure
was the address of the closure.  Now, all foobar_closure references
are addresses, and no & is necessary.

CHARLIKE/INTLIKE were not changed, simply alpha-renamed.

Part of remove HEAP_ALLOCED patch set (#8199)

Depends on D265

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

Test Plan: validate

Reviewers: simonmar, austin

Subscribers: simonmar, ezyang, carter, thomie

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

GHC Trac Issues: #8199

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

  * fix links to the User's Guide in ghc and ghci --help messages
  * fix default stack size info in RTS help message

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

It has been deprecated for long and already removed from ghc --help

It's been deprecated for who knows how long, and gives a warning.

Signed-off-by: Austin Seipp <aseipp@pobox.com>

Signed-off-by: Austin Seipp <aseipp@pobox.com>

We need different paths in the wrapper, as teh installed tree is a
different shape to the build tree.

This is particularly important as without it validate fails, as it
tries to pass RTS options to haddock, and with the default RTS config
those options aren't permitted.

Dynamic GHC is now working in-place, but pathologically slow due
to the DLL split.

(GHC assumes that all intra-package calls are in the same DLL, but that
isn't true when we split the GHC package into 2 DLLs. That means that
GHC's startup time is around 22 seconds, as it is doing run-time
linking).

Also, ghci isn't actually working yet:

$ inplace/bin/ghc-stage2 --interactive
GHCi, version 7.7.20130512: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... <command line>: can't load .so/.DLL for:
HSghc-prim-0.3.1.0.dll (addDLL: could not load DLL)
ghc-stage2.exe: HSghc-prim-0.3.1.0: The specified module could not be
found.

Currently they are all set to the same value, but when cross-compiling
they could be set to different values.

We now define _PROGNAME, and _PROG is automatically defined with
$(exeext). This will shortly automatically use the right exeext
depending on what stage it is being compiled with (exeext may be
different for different stages when cross-compiling).