1. 27 May, 2019 1 commit
    • Moritz Angermann's avatar
      Lowercase windows imports · 4b228768
      Moritz Angermann authored
      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.
      4b228768
  2. 25 Mar, 2019 1 commit
    • Takenobu Tani's avatar
      Update Wiki URLs to point to GitLab · 3769e3a8
      Takenobu Tani authored
      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
      3769e3a8
  3. 06 Mar, 2019 1 commit
    • Ben Gamari's avatar
      Rip out object splitting · 37f257af
      Ben Gamari authored
      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
      37f257af
  4. 25 Feb, 2018 1 commit
  5. 26 Oct, 2017 1 commit
  6. 26 Sep, 2017 1 commit
    • Tamar Christina's avatar
      Release console for ghci wrapper · 3ec579d5
      Tamar Christina authored
      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
      3ec579d5
  7. 07 Jul, 2017 1 commit
    • Tamar Christina's avatar
      Implement split-sections support for windows. · bd4fdc6a
      Tamar Christina authored
      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
      bd4fdc6a
  8. 29 Jun, 2017 1 commit
    • Simon Peyton Jones's avatar
      Revert "Remove the Windows GCC driver." · 58c781da
      Simon Peyton Jones authored
      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.
      58c781da
  9. 17 Jun, 2017 1 commit
    • Tamar Christina's avatar
      Remove the Windows GCC driver. · d6cecde5
      Tamar Christina authored
      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
      d6cecde5
  10. 08 Jun, 2017 1 commit
  11. 29 Apr, 2017 1 commit
  12. 23 Apr, 2017 1 commit
  13. 06 Apr, 2017 1 commit
  14. 14 Mar, 2017 1 commit
    • Tamar Christina's avatar
      Fix Windows GCC driver · 4b673e80
      Tamar Christina authored
      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
      4b673e80
  15. 10 Jan, 2017 2 commits
    • dobenour's avatar
      Don't use the splitter on Darwin · 266a9dc4
      dobenour authored
      Test Plan: GHC CI
      
      Reviewers: austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2879
      266a9dc4
    • Ryan Scott's avatar
      Properly detect MinTTY when running GHCi on Windows · 6fe9b057
      Ryan Scott authored
      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
      6fe9b057
  16. 10 Dec, 2016 1 commit
    • Tamar Christina's avatar
      Automate GCC driver wrapper · 490b9429
      Tamar Christina authored
      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
      490b9429
  17. 08 Dec, 2016 1 commit
  18. 29 Nov, 2016 1 commit
  19. 24 May, 2016 1 commit
    • seraphime's avatar
      Fix: #12084 deprecate old profiling flags · 1956cbf1
      seraphime authored
      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
      1956cbf1
  20. 06 Jan, 2016 1 commit
  21. 12 Nov, 2015 1 commit
    • olsner's avatar
      Implement function-sections for Haskell code, #8405 · 4a32bf92
      olsner authored
      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
      4a32bf92
  22. 21 Aug, 2015 1 commit
    • thomie's avatar
      Build system: simplify install.mk.in · 47493e60
      thomie authored
      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.
      47493e60
  23. 12 Aug, 2015 1 commit
    • Tamar Christina's avatar
      Upgrade GCC to 5.2.0 for Windows x86 and x86_64 · 7b211b4e
      Tamar Christina authored
      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
      7b211b4e
  24. 30 Nov, 2014 1 commit
  25. 20 Oct, 2014 1 commit
  26. 07 Oct, 2014 1 commit
  27. 02 Oct, 2014 1 commit
    • Edward Z. Yang's avatar
      Rename _closure to _static_closure, apply naming consistently. · 35672072
      Edward Z. Yang authored
      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's avatarEdward 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
      35672072
  28. 28 Jul, 2014 1 commit
  29. 03 Jul, 2014 1 commit
    • Jan Stolarek's avatar
      Update documentation · 311c55d1
      Jan Stolarek authored
        * fix links to the User's Guide in ghc and ghci --help messages
        * fix default stack size info in RTS help message
      311c55d1
  30. 21 Mar, 2014 1 commit
  31. 01 Oct, 2013 1 commit
  32. 23 Sep, 2013 1 commit
  33. 04 Sep, 2013 2 commits
  34. 16 May, 2013 1 commit
  35. 14 May, 2013 1 commit
  36. 12 May, 2013 1 commit
    • Ian Lynagh's avatar
      More work towards dynamic programs on Windows · b35a6ce0
      Ian Lynagh authored
      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.
      b35a6ce0
  37. 20 Apr, 2013 1 commit
  38. 03 Mar, 2013 1 commit
    • ian@well-typed.com's avatar
      Automatically add the $(exeext) to program names · 2b85372c
      ian@well-typed.com authored
      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).
      2b85372c