1. 21 Jan, 2017 1 commit
    • niteria's avatar
      Always use -Xlinker for -rpath · f9ccad23
      niteria authored
      Currently we use `-Wl` which takes a list of
      comma-separated options. Unfortunately that
      breaks when you use it with `-rpath` and
      a path that has commas in them.
      Buck, the build system, produces paths with
      commas in them.
      
      `-Xlinker` doesn't have this disadvantage
      and as far as I can tell is supported by
      both `gcc` and `clang`. Anecdotally `nvcc`
      supports `-Xlinker`, but not `-Wl`.
      
      Test Plan: ./validate, harbourmaster
      
      Reviewers: nomeata, simonmar, austin, bgamari, hvr
      
      Reviewed By: simonmar, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2971
      f9ccad23
  2. 15 Jan, 2017 1 commit
    • Tamar Christina's avatar
      Use latin1 code page on Windows for response files. · f63c8ef3
      Tamar Christina authored
      Summary:
      D2917 added a change that will make paths on Windows response files
      use DOS 8.3 shortnames to get around the fact that `libiberty` assumes
      a one byte per character encoding.
      
      This is actually not the problem, the actual problem is that GCC on
      Windows doesn't seem to support Unicode at all.
      
      This comes down to how unicode characters are handled between POSIX and
      Windows. On Windows, Unicode is only supported using a multibyte character
      encoding such as `wchar_t` with calls to the appropriate wide version of
      APIs (name post-fixed with the `W` character). On Posix I believe the standard
      `char` is used and based on the value it is decoded to the correct string.
      
      GCC doesn't seem to make calls to the Wide version of the Windows APIs,
      and even if it did, it's character representation would be wrong. So I
      believe GCC just does not support utf-8 paths on Windows.
      
      So the hack in D2917 is the only way to get Unicode support. The problem is
      however that `GCC` is not the only tool with this issue and we don't use response
      files for every invocation of the tools. Most of the tools probably don't support it.
      
      Furthermore, DOS 8.1 shortnames only exist when the path or file physically exists on
      disk. We pass lots of paths to GCC that don't exist yet, like the output file.
      D2917 works around this by splitting the path from the file and try shortening that.
      
      But this may not always work.
      
      In short, even if we do Unicode correctly (which we don't atm, the GCC driver we build
      uses `char` instead of `wchar_t`) we won't be able to compile using unicode paths that
      need to be passed to `GCC`. So not sure about the point of D2917.
      
      What we can do is support the most common non-ascii characters by writing the response
      files out using the `latin1` code page.
      
      Test Plan: compile + make test TEST=T12971
      
      Reviewers: austin, bgamari, erikd
      
      Reviewed By: bgamari
      
      Subscribers: thomie, #ghc_windows_task_force
      
      Differential Revision: https://phabricator.haskell.org/D2942
      
      GHC Trac Issues: #12971
      f63c8ef3
  3. 11 Nov, 2016 2 commits
    • Ben Gamari's avatar
      Pass -no-pie to GCC · d421a7e2
      Ben Gamari authored
      Certain distributions (e.g. Debian and Ubuntu) have enabled PIE be
      default in their GCC packaging. This breaks our abuse of GCC as a linker
      which requires that we pass -Wl,-r, which is incompatible with
      PIE (since the former implies that we are generating a relocatable
      object file and the latter an executable).
      
      This is a second attempt at D2691. This attempt constrasts with D2691 in that
      it preserves the "does gcc support -no-pie" flag in settings, allowing this to
      be reconfigured by `configure` during installation of a binary distribution.
      Thanks for @rwbarton for drawing attention to this issue.
      
      Test Plan: Validate
      
      Reviewers: austin, hvr, erikd
      
      Reviewed By: erikd
      
      Subscribers: thomie, rwbarton, erikd
      
      Differential Revision: https://phabricator.haskell.org/D2693
      
      GHC Trac Issues: #12759
      d421a7e2
    • Ben Gamari's avatar
      Revert "Pass -no-pie to GCC" · 60bb9d1c
      Ben Gamari authored
      This reverts commit bae4a55b.
      
      This will be superceded by D2693.
      60bb9d1c
  4. 10 Nov, 2016 1 commit
    • Ben Gamari's avatar
      Pass -no-pie to GCC · bae4a55b
      Ben Gamari authored
      Certain distributions (e.g. Debian and Ubuntu) have enabled PIE be
      default in their GCC packaging. This breaks our abuse of GCC as a linker
      which requires that we pass -Wl,-r, which is incompatible with
      PIE (since the former implies that we are generating a relocatable
      object file and the latter an executable).
      
      Test Plan: Validate
      
      Reviewers: hvr, austin
      
      Subscribers: rwbarton, thomie, erikd
      
      Differential Revision: https://phabricator.haskell.org/D2691
      
      GHC Trac Issues: #12759
      bae4a55b
  5. 03 Nov, 2016 1 commit
    • Simon Marlow's avatar
      Omit unnecessary linker flags · a977c965
      Simon Marlow authored
      Summary:
      This omits -L and -l flags from the linker command line that shouldn't
      be necessary because GHC will already add them via the -package-id
      flags we pass.
      
      This also reverts part of 90538d86
      that rearranges the linker command line and causes some knock-on
      problems (see D2618).
      
      Test Plan: validate (need to validate on Windows too)
      
      Reviewers: Phyx, bgamari, niteria, austin, erikd
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2639
      
      GHC Trac Issues: #12738
      a977c965
  6. 22 Oct, 2016 2 commits
    • Erik de Castro Lopo's avatar
      Add -Wcpp-undef warning flag · 3cb32d8b
      Erik de Castro Lopo authored
      When enabled, this new warning flag passes `-Wundef` to the C
      pre-processor which causes the pre-processor to warn on uses of
      the `#if` directive on undefined identifiers.
      
      It is not currently enabled in any of the standard warning groups.
      
      Test Plan: Make sure the two tests pass on all major platforms.
      
      Reviewers: hvr, carter, Phyx, bgamari, austin
      
      Reviewed By: Phyx
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2626
      
      GHC Trac Issues: #12752
      3cb32d8b
    • Duncan Coutts's avatar
      Add and use a new dynamic-library-dirs field in the ghc-pkg info · f41a8a36
      Duncan Coutts authored
      Summary:
      Build systems / package managers want to be able to control the file
      layout of installed libraries. In general they may want/need to be able
      to put the static libraries and dynamic libraries in different places.
      The ghc-pkg library regisrtation needs to be able to handle this.
      
      This is already possible in principle by listing both a static lib dir
      and a dynamic lib dir in the library-dirs field (indeed some previous
      versions of Cabal did this for shared libs on ELF platforms).
      
      The downside of listing both dirs is twofold. There is a lack of
      precision, if we're not careful with naming then we could end up
      picking up the wrong library. The more immediate problem however is
      that if we list both directories then both directories get included
      into the ELF and Mach-O shared object runtime search paths. On ELF this
      merely slows down loading of shared libs (affecting prog startup time).
      On the latest OSX versions this provokes a much more serious problem:
      that there is a rather low limit on the total size of the section
      containing the runtime search path (and lib names and related) and thus
      listing any unnecessary directories wastes the limited space.
      
      So the solution in this patch is fairly straightforward: split the
      static and dynamic library search paths in the ghc-pkg db and its use
      within ghc. This is a traditional solution: pkg-config has the same
      static / dynamic split (though it describes in in terms of private and
      public, but it translates into different behaviour for static and
      dynamic linking).
      
      Indeed it would make perfect sense to also have a static/dynamic split
      for the list of the libraries to use i.e. to have dynamic variants of
      the hs-libraries and extra-libraries fields. These are not immediately
      required so this patch does not add it, but it is a reasonable
      direction to follow.
      
      To handle compatibility, if the new dynamic-library-dirs field is not
      specified then its value is taken from the library-dirs field.
      
      Contains Cabal submodule update.
      
      Test Plan:
      Run ./validate
      
      Get christiaanb and carter to test it on OSX Sierra, in combination
      with Cabal/cabal-install changes to the default file layout for
      libraries.
      
      Reviewers: carter, austin, hvr, christiaanb, bgamari
      
      Reviewed By: christiaanb, bgamari
      
      Subscribers: ezyang, Phyx, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2611
      
      GHC Trac Issues: #12479
      f41a8a36
  7. 08 Oct, 2016 1 commit
  8. 01 Oct, 2016 1 commit
    • Tamar Christina's avatar
      Use check stacking on Windows. · 1e795a00
      Tamar Christina authored
      Summary:
      #8870 added as a temporary work around a much higher initial reserve
      and committed stack space of 2mb. This is causing problems with other windows applications.
      
      The hack was supposed to be temporary untill we could emit `__chkstk` instructions.
      But GCC can emit stack checks automatically for us if `-fstack-check` is passed.
      
      This will then emit calls to `___chkstk_ms` before stack allocations.
      
      ```
        633de0:       48 83 e0 f0             and    $0xfffffffffffffff0,%rax
        633de4:       e8 07 0c 0d 00          callq  7049f0 <___chkstk_ms>
        633de9:       48 29 c4                sub    %rax,%rsp
      ```
      
      The hack is now no longer needed.
      
      Test Plan: ./validate
      
      Reviewers: austin, erikd, awson, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie, #ghc_windows_task_force
      
      Differential Revision: https://phabricator.haskell.org/D2535
      
      GHC Trac Issues: #12186
      1e795a00
  9. 25 Jun, 2016 1 commit
    • Moritz Angermann's avatar
      Allow building static libs. · 8c1ceddd
      Moritz Angermann authored
      Summary:
      Commit 90538d86, seems to have broken static linking.
      The introduction of `argFixup` in `runLink` rearranges libs, and considers
      anything with an `-l` prefix or `.a` suffix a lib, which fails for libs that are
      just being linked together (e.g. `-o lib.a`).
      
      The proposed solution explicitly checks for the existance of the `-o` flag.
      
      Reviewers: rwbarton, erikd, Phyx, bgamari, austin
      
      Reviewed By: Phyx
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2362
      8c1ceddd
  10. 14 Jun, 2016 1 commit
    • thomie's avatar
      Simplify readProcessEnvWithExitCode + set LANGUAGE=C · 753c5b24
      thomie authored
      `readProcessEnvWithExitCode` was added in
      4d4d0770, to start an external process
      after making some modifications to the environment.
      
      Since then, the `process` library has exposed
      `readCreateProcessWithExitCode`, which allows for the refactoring we do
      here.
      
      Also change "en" to "C", as suggested in ticket:8825#comment:11.
      
      Reviewed by: trofi
      
      Differential Revision: https://phabricator.haskell.org/D2332
      
      GHC Trac Issues: #8825
      753c5b24
  11. 17 Apr, 2016 1 commit
    • Tamar Christina's avatar
      Resolve symlinks when attempting to find GHC's lib folder on Windows · a3922083
      Tamar Christina authored
      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
      a3922083
  12. 10 Apr, 2016 1 commit
    • Tamar Christina's avatar
      Change runtime linker to perform lazy loading of symbols/sections · 90538d86
      Tamar Christina authored
      The Runtime Linker is currently eagerly loading all object files on all
      platforms which do not use the system linker for `GHCi`.
      
      The problem with this approach is that it requires all symbols to be
      found.  Even those of functions never used/called. This makes the number
      of libraries required to link things like `mingwex` quite high.
      
      To work around this the `rts` was relying on a trick. It itself was
      compiled with `MingW64-w`'s `GCC`. So it was already linked against
      `mingwex`.  As such, it re-exported the symbols from itself.
      
      While this worked it made it impossible to link against `mingwex` in
      user libraries. And with this means no `C99` code could ever run in
      `GHCi` on Windows without having the required symbols re-exported from
      the rts.
      
      Consequently this rules out a large number of packages on Windows.
      SDL2, HMatrix etc.
      
      After talking with @rwbarton I have taken the approach of loading entire
      object files when a symbol is needed instead of doing the dependency
      tracking on a per symbol basis. This is a lot less fragile and a lot
      less complicated to implement.
      
      The changes come down to the following steps:
      
      1) modify the linker to and introduce a new state for ObjectCode:
         `Needed`.  A Needed object is one that is required for the linking to
         succeed.  The initial set consists of all Object files passed as
         arguments to the link.
      
      2) Change `ObjectCode`'s to be indexed but not initialized or resolved.
         This means we know where we would load the symbols,
         but haven't actually done so.
      
      3) Mark any `ObjectCode` belonging to `.o` passed as argument
         as required: ObjectState `NEEDED`.
      
      4) During `Resolve` object calls, mark all `ObjectCode`
         containing the required symbols as `NEEDED`
      
      5) During `lookupSymbol` lookups, (which is called from `linkExpr`
         and `linkDecl` in `GHCI.hs`) is the symbol is in a not-yet-loaded
         `ObjectCode` then load the `ObjectCode` on demand and return the
         address of the symbol. Otherwise produce an unresolved symbols error
         as expected.
      
      6) On `unloadObj` we then change the state of the object and remove
         it's symbols from the `reqSymHash` table so it can be reloaded.
      
      This change affects all platforms and OSes which use the runtime linker.
      It seems there are no real perf tests for `GHCi`, but performance
      shouldn't be impacted much. We gain a lot of time not loading all `obj`
      files, and we lose some time in `lookupSymbol` when we're finding
      sections that have to be loaded. The actual finding itself is O(1)
      (Assuming the hashtnl is perfect)
      
      It also consumes slighly more memory as instead of storing just the
      address of a symbol I also store some other information, like if the
      symbol is weak or not.
      
      This change will break any packages relying on renamed POSIX functions
      that were re-named and re-exported by the rts. Any packages following
      the proper naming for functions as found on MSDN will work fine.
      
      Test Plan: ./validate on all platforms which use the Runtime linker.
      
      Reviewers: thomie, rwbarton, simonmar, erikd, bgamari, austin, hvr
      
      Reviewed By: erikd
      
      Subscribers: kgardas, gridaphobe, RyanGlScott, simonmar,
                   rwbarton, #ghc_windows_task_force
      
      Differential Revision: https://phabricator.haskell.org/D1805
      
      GHC Trac Issues: #11223
      90538d86
  13. 25 Feb, 2016 1 commit
    • barrucadu's avatar
      Print which warning-flag controls an emitted warning · bb5afd3c
      barrucadu authored
      Both gcc and clang tell which warning flag a reported warning can be
      controlled with, this patch makes ghc do the same. More generally, this
      allows for annotated compiler output, where an optional annotation is
      displayed in brackets after the severity.
      
      This also adds a new flag `-f(no-)show-warning-groups` to control
      whether to show which warning-group (such as `-Wall` or `-Wcompat`)
      a warning belongs to. This flag is on by default.
      
      This implements #10752
      
      Reviewed By: quchen, bgamari, hvr
      
      Differential Revision: https://phabricator.haskell.org/D1943
      bb5afd3c
  14. 18 Jan, 2016 1 commit
    • Jan Stolarek's avatar
      Replace calls to `ptext . sLit` with `text` · b8abd852
      Jan Stolarek authored
      Summary:
      In the past the canonical way for constructing an SDoc string literal was the
      composition `ptext . sLit`.  But for some time now we have function `text` that
      does the same.  Plus it has some rules that optimize its runtime behaviour.
      This patch takes all uses of `ptext . sLit` in the compiler and replaces them
      with calls to `text`.  The main benefits of this patch are clener (shorter) code
      and less dependencies between module, because many modules now do not need to
      import `FastString`.  I don't expect any performance benefits - we mostly use
      SDocs to report errors and it seems there is little to be gained here.
      
      Test Plan: ./validate
      
      Reviewers: bgamari, austin, goldfire, hvr, alanz
      
      Subscribers: goldfire, thomie, mpickering
      
      Differential Revision: https://phabricator.haskell.org/D1784
      b8abd852
  15. 18 Dec, 2015 1 commit
    • Ömer Sinan Ağacan's avatar
      LLVM backend: Show expected LLVM version in warnings/errors · 0e9a331f
      Ömer Sinan Ağacan authored
      Summary:
      Before:
      
          [1 of 1] Compiling Main             ( Main.hs, Main.o )
          You are using a new version of LLVM that hasn't been tested yet!
          We will try though...
      
      After:
      
          [1 of 1] Compiling Main             ( Main.hs, Main.o )
          You are using an unsupported version of LLVM!
          Currently only 3.7 is supported.
          We will try though...
      
      Before:
      
          [1 of 1] Compiling Main             ( Main.hs, Main.o )
      
          <no location info>:
              Warning: Couldn't figure out LLVM version!
                       Make sure you have installed LLVM
          ghc: could not execute: opt
      
      After:
      
          [1 of 1] Compiling Main             ( Main.hs, Main.o )
      
          <no location info>: error:
              Warning: Couldn't figure out LLVM version!
                       Make sure you have installed LLVM 3.7
          ghc-stage1: could not execute: opt
      
      Reviewers: austin, rwbarton, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1658
      0e9a331f
  16. 17 Dec, 2015 1 commit
    • Simon Marlow's avatar
      Remote GHCi, -fexternal-interpreter · 4905b83a
      Simon Marlow authored
      Summary:
      (Apologies for the size of this patch, I couldn't make a smaller one
      that was validate-clean and also made sense independently)
      
      (Some of this code is derived from GHCJS.)
      
      This commit adds support for running interpreted code (for GHCi and
      TemplateHaskell) in a separate process.  The functionality is
      experimental, so for now it is off by default and enabled by the flag
      -fexternal-interpreter.
      
      Reaosns we want this:
      
      * compiling Template Haskell code with -prof does not require
        building the code without -prof first
      
      * when GHC itself is profiled, it can interpret unprofiled code, and
        the same applies to dynamic linking.  We would no longer need to
        force -dynamic-too with TemplateHaskell, and we can load ordinary
        objects into a dynamically-linked GHCi (and vice versa).
      
      * An unprofiled GHCi can load and run profiled code, which means it
        can use the stack-trace functionality provided by profiling without
        taking the performance hit on the compiler that profiling would
        entail.
      
      Amongst other things; see
      https://ghc.haskell.org/trac/ghc/wiki/RemoteGHCi for more details.
      
      Notes on the implementation are in Note [Remote GHCi] in the new
      module compiler/ghci/GHCi.hs.  It probably needs more documenting,
      feel free to suggest things I could elaborate on.
      
      Things that are not currently implemented for -fexternal-interpreter:
      
      * The GHCi debugger
      * :set prog, :set args in GHCi
      * `recover` in Template Haskell
      * Redirecting stdin/stdout for the external process
      
      These are all doable, I just wanted to get to a working validate-clean
      patch first.
      
      I also haven't done any benchmarking yet.  I expect there to be slight hit
      to link times for byte code and some penalty due to having to
      serialize/deserialize TH syntax, but I don't expect it to be a serious
      problem.  There's also lots of low-hanging fruit in the byte code
      generator/linker that we could exploit to speed things up.
      
      Test Plan:
      * validate
      * I've run parts of the test suite with
      EXTRA_HC_OPTS=-fexternal-interpreter, notably tests/ghci and tests/th.
      There are a few failures due to the things not currently implemented
      (see above).
      
      Reviewers: simonpj, goldfire, ezyang, austin, alanz, hvr, niteria, bgamari, gibiansky, luite
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1562
      4905b83a
  17. 15 Dec, 2015 1 commit
    • thomie's avatar
      DynFlags: remove Opt_Static · 6d9c18cb
      thomie authored
      There are currently 2 different ways to test for a static or dynamic
      build:
      
          * Test if WayDyn is in ways
          * Test if Opt_Static is set
      
      The problem is that these can easily go out of sync, especially when
      using the
      GHC API.
      
      This commit replaces all queries of Opt_Static with an equivalent query
      of
      WayDyn. This would have prevented bug #8294 and fixes #11154.
      
      Reviewers: hvr, austin, bgamari
      
      Reviewed By: austin, bgamari
      
      Differential Revision: https://phabricator.haskell.org/D1607
      
      GHC Trac Issues: #10636
      6d9c18cb
  18. 19 Nov, 2015 1 commit
  19. 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
  20. 11 Nov, 2015 1 commit
    • Sylvain HENRY's avatar
      Systools: read ELF section without calling readelf · 109d7ce8
      Sylvain HENRY authored
      This patch tackles two issues:
      
      1) GHC stores a "link info" string into a ELF section. Initially a
      section with type "note" was used but GHC didn't follow the ELF
      specification which specifies a record-based format for these sections.
      With D1375 we switched to a "progbits" section type for which there
      isn't any format constraint. This is an issue for D1242 which use GCC's
      --gc-sections which collects "unused" sections, such as our section
      containing link info... In this patch, we fall back to a section with
      type "note" but we respect the specified format.
      
      2) Reading back the ELF section was done by parsing the result of a
      call to "readelf". Calling readelf is problematic because the program
      may not be available or it may be renamed on some platforms (see
      D1326). Moreover we have no garanty that its output layout will stay
      the same in future releases of readelf. Finally we would need to fix
      the parsing to support  "note" sections because of 1. Instead, this
      patch proposes to use Data.Binary.Get to directly read the "link info"
      note into its section. ELF has a specification, hence it should work on
      every conforming platform.
      
      This patch "reverts" D1375, hence it supersedes D1432. It makes D1326
      not necessary anymore.
      
      Test Plan:
      - recomp011 should pass (test that relinking is avoided when both "link
      info" match)
      - we should add a test for ELF objects with more than 0xff00 sections
      => added test "recomp015"
      - we should check that GAS generates 32-bit words with .int on every
      supported platform using ELF (or find a place where this is
      documented). harbomaster and I (@hsyl20) only tested on x86-64. On
      platforms where it is not true, it should make recomp011 fail. =>
      tested to work on Linux/amd64, Solaris/i386 and OpenBSD/amd64
      
      Reviewers: olsner, ony, thomie, kgardas, austin, bgamari
      
      Reviewed By: thomie, bgamari
      
      Subscribers: kgardas, rwbarton, thomie
      
      Differential Revision: https://phabricator.haskell.org/D1381
      
      GHC Trac Issues: #10974, #11022
      109d7ce8
  21. 04 Nov, 2015 1 commit
  22. 19 Oct, 2015 1 commit
  23. 15 Oct, 2015 1 commit
  24. 13 Oct, 2015 1 commit
    • Erik de Castro Lopo's avatar
      Switch to LLVM version 3.7 · 29310b62
      Erik de Castro Lopo authored
      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
      29310b62
  25. 03 Oct, 2015 2 commits
    • Tamar Christina's avatar
      Fix broken validation Build 6564 and accepting a few other test results · c4d7df04
      Tamar Christina authored
      Test Plan: ./validate
      
      Reviewers: thomie, austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: #ghc_windows_task_force
      
      Differential Revision: https://phabricator.haskell.org/D1304
      c4d7df04
    • Tamar Christina's avatar
      Prevent GHC from silently dying when preprocessor is not found · b6f76b9a
      Tamar Christina authored
      The Windows preprocessor code calls `runInteractiveProcess` but does
      not check if an exception is thrown.
      `runInteractiveProcess` calls `CreateProcess` which when given a format
      the system loader does not know about
      will throw an exception. This is what makes #9399 fail.
      
      Ultimately we should not use any `CreateProcess` based calls but
      instead `ShellExecuteEx` as  this would allow
      us to run applications that the shell knows about instead of just the
      loader. More details on #365.
      
      This patch removes `PhaseFailed` and throws `ProgramError` instead.
      `PhaseFailed` was largely unneeded since it never gave
      very useful information aside from the `errorcode` which was almost
      always `1`. `IOErrors` have also been eliminated and `GhcExceptions`
      thrown in their place wherever possible.
      
      Updates haddock submodule.
      
      Test Plan:
      `./validate` to make sure anything didn't break and
      `make TESTS="T365"` to test that an error is now properly thrown
      
      Reviewers: austin, thomie, bgamari
      
      Reviewed By: thomie, bgamari
      
      Subscribers: #ghc_windows_task_force
      
      Differential Revision: https://phabricator.haskell.org/D1256
      
      GHC Trac Issues: #365
      b6f76b9a
  26. 16 Sep, 2015 1 commit
  27. 02 Sep, 2015 1 commit
    • Michael Snoyman's avatar
      Use a response file for linker command line arguments #10777 · 296bc70b
      Michael Snoyman authored
      On Windows, we're constrained to 32k bytes total for command line
      arguments.  When building large projects, this limit can be exceeded.
      This patch changes GHC to always use response files for linker
      arguments, a feature first used by Microsoft compilers and added to GCC
      (over a decade ago).
      
      Alternatives here include:
      
      * Only use this method on Windows systems
      * Check the length of the command line arguments and use that to decide
        whether to use this method
      
      I did not pursue either of these, as I believe it would make the patch
      more likely to break in less tested situations.
      
      Test Plan:
      Confirm that linking still works in general. Ideally: compile a very
      large project on Windows with this patch. (I am attempting to do that
      myself now, but having trouble getting the Windows build tool chain up
      and running.)
      
      Reviewers: goldfire, hvr, rwbarton, austin, thomie, bgamari, Phyx
      
      Reviewed By: thomie, bgamari, Phyx
      
      Subscribers: erikd, awson, #ghc_windows_task_force, thomie
      
      Differential Revision: https://phabricator.haskell.org/D1158
      
      GHC Trac Issues: #8596, #10777
      296bc70b
  28. 12 Aug, 2015 2 commits
    • Ben Gamari's avatar
      SysTools: Fix whitespace in error message · 8c5b087b
      Ben Gamari authored
      8c5b087b
    • 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
  29. 05 Aug, 2015 1 commit
  30. 02 Jun, 2015 1 commit
    • Joachim Breitner's avatar
      newTempName: Do not include pid in basename · 7a82b776
      Joachim Breitner authored
      The filename of temporary files, especially the basename of C files, can
      end up in the output in some form, e.g. as part of linker debug
      information. In the interest of bit-wise exactly reproducible
      compilation (#4012), the basename of the temporary file no longer
      contains random information (it used to ontain the process id).
      
      This is ok, as the temporary directory used contains the pid (see
      getTempDir).
      
      This patch has been applied to the Debian package (version 7.10.1-5) and
      allowed a fully bit-wise reproducible build:
      https://reproducible.debian.net/rb-pkg/experimental/amd64/ghc.html
      
      Reviewed By: austin, rwbarton
      
      Differential Revision: https://phabricator.haskell.org/D910
      
      GHC Trac Issues: #4012
      7a82b776
  31. 07 Apr, 2015 1 commit
  32. 03 Apr, 2015 1 commit
  33. 14 Mar, 2015 1 commit
    • Peter Trommler's avatar
      Link temporary shared objects with `--no-as-needed` · 1b7f5976
      Peter Trommler authored
      Some ELF link editors default to `--as-needed` and record only
      those libraries in DT_NEEDED tags that are needed to resolve
      undefined symbols in the shared object to be created.
      
      In Template Haskell we rely on all symbols that were defined
      in modules compiled so far to be available in the current
      temporary shared object. To prevent the link editor from
      dropping the DT_NEEDED tag for the previously linked temporary
      shared object we need to override the link editors default and
      specify `--no-as-needed` on the command line. This is for GNU ld
      and GOLD ld.
      
      This addresses #10110
      
      TODO: regression test
      
      Reviewed By: hvr
      
      Differential Revision: https://phabricator.haskell.org/D731
      1b7f5976
  34. 09 Mar, 2015 1 commit
    • thomie's avatar
      Update process submodule · 8b7534b3
      thomie authored
      Summary:
      Rename `SysTools.readCreateProcess`.
      
      Functions `readCreateProcess` and `readCreateProcessWithExitCode` were added
      to `System.Process`, the former of which conflicts with
      `SysTools.readCreateProcess`.
      
      Reviewed by: austin
      
      Differential Revision: https://phabricator.haskell.org/D713
      8b7534b3
  35. 28 Jan, 2015 1 commit
  36. 29 Dec, 2014 1 commit
    • Peter Trommler's avatar
      Fix system linker on Mac OS X · b32c2276
      Peter Trommler authored
      Summary:
      Flag `-l:` is GNU ld specific and not supported by the
      Mac OS X link editor. So we create a temporary file name
      lib<tmpname>.<so_ext> and link with the standard -l<tmpname>
      option on Linux and OS X.
      
      Fixes #9875
      
      Test Plan: validate on Mac OS X
      
      Reviewers: austin, hvr, ezyang
      
      Reviewed By: ezyang
      
      Subscribers: carter, thomie, ezyang
      
      Differential Revision: https://phabricator.haskell.org/D579
      
      GHC Trac Issues: #9875
      b32c2276