1. 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
  2. 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
  3. 16 Sep, 2015 1 commit
  4. 02 Sep, 2015 1 commit
    • snoyberg's avatar
      Use a response file for linker command line arguments #10777 · 296bc70b
      snoyberg 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
  5. 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
  6. 05 Aug, 2015 1 commit
  7. 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
  8. 07 Apr, 2015 1 commit
  9. 03 Apr, 2015 1 commit
  10. 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
  11. 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
  12. 28 Jan, 2015 1 commit
  13. 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
  14. 28 Dec, 2014 1 commit
    • Erik de Castro Lopo's avatar
      LlvmCodeGen cross-compiling fixes (#9895) · 58ac9c8f
      Erik de Castro Lopo authored
      Summary:
      * Throw an error when cross-compiling without a target definition.
        When cross compiling via LLVM, a target 'datalayout' and 'triple' must
        be defined or LLVM will generate code for the compile host instead of
        the compile target.
      
      * Add aarch64-unknown-linux-gnu target.
        The datalayout and triple lines were found by using clang to compile a
        small C program and -emit-llvm to get the LLVM IR output.
      Signed-off-by: Erik de Castro Lopo's avatarErik de Castro Lopo <erikd@mega-nerd.com>
      
      Test Plan: validate
      
      Reviewers: rwbarton, carter, hvr, bgamari, austin
      
      Reviewed By: austin
      
      Subscribers: carter, thomie, garious
      
      Differential Revision: https://phabricator.haskell.org/D585
      
      GHC Trac Issues: #9895
      58ac9c8f
  15. 20 Dec, 2014 1 commit
  16. 03 Dec, 2014 1 commit
  17. 30 Nov, 2014 1 commit
    • Peter Trommler's avatar
      Fix obscure problem with using the system linker (#8935) · 383733b9
      Peter Trommler authored
      Summary:
      In a statically linked GHCi symbol `environ` resolves to NULL when
      called from a Haskell script.
      
      When resolving symbols in a Haskell script we need to search the
      executable program and its dependent (DT_NEEDED) shared libraries
      first and then search the loaded libraries.
      
      We want to be able to override functions in loaded libraries later.
      Libraries must be opened with local scope (RTLD_LOCAL) and not global.
      The latter adds all symbols to the executable program's symbols where
      they are then searched in loading order. We want reverse loading order.
      
      When libraries are loaded with local scope the dynamic linker
      cannot use symbols in that library when resolving the dependencies
      in another shared library. This changes the way files compiled to
      object code must be linked into temporary shared libraries. We link
      with the last temporary shared library created so far if it exists.
      Since each temporary shared library is linked to the previous temporary
      shared library the dynamic linker finds the latest definition of a
      symbol by following the dependency chain.
      
      See also Note [RTLD_LOCAL] for a summary of the problem and solution.
      
      Cherry-picked commit 2f8b4c
      
      Changed linker argument ordering
      
      On some ELF systems GNU ld (and others?) default to
      --as-needed and the order of libraries in the link
      matters.
      
      The last temporary shared library, must appear
      before all other libraries. Switching the position
      of extra_ld_inputs and lib_path_objs does that.
      
      Fixes #8935 and #9186
      
      Reviewers: austin, hvr, rwbarton, simonmar
      
      Reviewed By: simonmar
      
      Subscribers: thomie, carter, simonmar
      
      Differential Revision: https://phabricator.haskell.org/D349
      
      GHC Trac Issues: #8935, #9186, #9480
      383733b9
  18. 18 Nov, 2014 1 commit
  19. 01 Sep, 2014 1 commit
    • Sergei Trofimovich's avatar
      systools: fix gcc version detecton on non-english locale · 4d4d0770
      Sergei Trofimovich authored
      Summary:
      ghc runs 'gcc -v' to check if we run under vanilla gcc
      or disaguised clang by checking for string
      
          "gcc version <something>"
      
      But this check does not always work as gcc has that string
      localized via gettext mechanism:
      
          (some gcc's locale strings)
          be.po-msgstr "версія gcc %s\n"
          da.po-msgstr "GCC version %s\n"
          de.po-msgstr "gcc-Version %s %s\n"
          el.po-msgstr "έκδοση gcc %s\n"
          ...
      
      To ping gcc to English locale we now override environment
      variable with 'LANGUAGE=en' value.
      
      Fixes Issue #8825
      Signed-off-by: default avatarSergei Trofimovich <slyfox@gentoo.org>
      
      Test Plan: validate
      
      Reviewers: austin
      
      Reviewed By: austin
      
      Subscribers: simonmar, ezyang, carter
      
      Differential Revision: https://phabricator.haskell.org/D185
      
      GHC Trac Issues: #8825
      4d4d0770
  20. 10 Aug, 2014 1 commit
  21. 31 Jul, 2014 1 commit
  22. 28 Jul, 2014 1 commit
    • kgardas's avatar
      add Solaris' linker warning messages filtering into link phase · 524f15de
      kgardas authored
      Summary:
      Solaris ld emits harmless warning messages about unresolved
      symbol in case of compiling into shared library when we do not
      link against all the required libs. That is the case of GHC which
      does not link against RTS library explicitly in order to be able to
      chose the library later based on binary application linking
      parameters. The warnings look like:
      
      Undefined                       first referenced
       symbol                             in file
      stg_ap_n_fast                       ./T2386_Lib.o
      stg_upd_frame_info                  ./T2386_Lib.o
      templatezmhaskell_LanguageziHaskellziTHziLib_litE_closure ./T2386_Lib.o
      templatezmhaskell_LanguageziHaskellziTHziLib_appE_closure ./T2386_Lib.o
      templatezmhaskell_LanguageziHaskellziTHziLib_conE_closure ./T2386_Lib.o
      templatezmhaskell_LanguageziHaskellziTHziSyntax_mkNameGzud_closure ./T2386_Lib.o
      newCAF                              ./T2386_Lib.o
      stg_bh_upd_frame_info               ./T2386_Lib.o
      stg_ap_ppp_fast                     ./T2386_Lib.o
      templatezmhaskell_LanguageziHaskellziTHziLib_stringL_closure ./T2386_Lib.o
      stg_ap_p_fast                       ./T2386_Lib.o
      stg_ap_pp_fast                      ./T2386_Lib.o
      ld: warning: symbol referencing errors
      
      this is actually coming from T2386 testcase. The emitting of those
      warnings is also a reason why so many TH testcases fail on Solaris.
      
      The patch provides filter which filters out only linker warnings.
      
      Test Plan: validate
      
      Reviewers: austin
      
      Reviewed By: austin
      
      Subscribers: phaskell, simonmar, relrod, carter
      
      Differential Revision: https://phabricator.haskell.org/D94
      524f15de
  23. 21 Jul, 2014 1 commit
    • Edward Z. Yang's avatar
      Rename PackageId to PackageKey, distinguishing it from Cabal's PackageId. · 4bebab25
      Edward Z. Yang authored
      Summary:
      Previously, both Cabal and GHC defined the type PackageId, and we expected
      them to be roughly equivalent (but represented differently).  This refactoring
      separates these two notions.
      
      A package ID is a user-visible identifier; it's the thing you write in a
      Cabal file, e.g. containers-0.9.  The components of this ID are semantically
      meaningful, and decompose into a package name and a package vrsion.
      
      A package key is an opaque identifier used by GHC to generate linking symbols.
      Presently, it just consists of a package name and a package version, but
      pursuant to #9265 we are planning to extend it to record other information.
      Within a single executable, it uniquely identifies a package.  It is *not* an
      InstalledPackageId, as the choice of a package key affects the ABI of a package
      (whereas an InstalledPackageId is computed after compilation.)  Cabal computes
      a package key for the package and passes it to GHC using -package-name (now
      *extremely* misnamed).
      
      As an added bonus, we don't have to worry about shadowing anymore.
      
      As a follow on, we should introduce -current-package-key having the same role as
      -package-name, and deprecate the old flag.  This commit is just renaming.
      
      The haddock submodule needed to be updated.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: simonpj, simonmar, hvr, austin
      
      Subscribers: simonmar, relrod, carter
      
      Differential Revision: https://phabricator.haskell.org/D79
      
      Conflicts:
      	compiler/main/HscTypes.lhs
      	compiler/main/Packages.lhs
      	utils/haddock
      4bebab25
  24. 02 Jul, 2014 1 commit
  25. 23 Jun, 2014 1 commit
  26. 15 May, 2014 1 commit
    • Herbert Valerio Riedel's avatar
      Add LANGUAGE pragmas to compiler/ source files · 23892440
      Herbert Valerio Riedel authored
      In some cases, the layout of the LANGUAGE/OPTIONS_GHC lines has been
      reorganized, while following the convention, to
      
      - place `{-# LANGUAGE #-}` pragmas at the top of the source file, before
        any `{-# OPTIONS_GHC #-}`-lines.
      
      - Moreover, if the list of language extensions fit into a single
        `{-# LANGUAGE ... -#}`-line (shorter than 80 characters), keep it on one
        line. Otherwise split into `{-# LANGUAGE ... -#}`-lines for each
        individual language extension. In both cases, try to keep the
        enumeration alphabetically ordered.
        (The latter layout is preferable as it's more diff-friendly)
      
      While at it, this also replaces obsolete `{-# OPTIONS ... #-}` pragma
      occurences by `{-# OPTIONS_GHC ... #-}` pragmas.
      23892440
  27. 04 Apr, 2014 1 commit
    • Austin Seipp's avatar
      windows: Fix #8870 · f0af58df
      Austin Seipp authored
      This bumps the amount of default reserved and committed stack for GHC
      executables to 8mb, to work around #8870. A proper fix should happen in
      7.8.2
      
      See note [Windows stack usage] in SysTools for the details.
      Signed-off-by: default avatarAustin Seipp <austin@well-typed.com>
      f0af58df
  28. 28 Jan, 2014 1 commit
  29. 16 Jan, 2014 1 commit
  30. 14 Jan, 2014 2 commits
  31. 07 Jan, 2014 1 commit
  32. 08 Nov, 2013 1 commit
    • parcs's avatar
      SysTools.getTempDir: don't retry after catching a does-not-exist error · 12369d60
      parcs authored
      Previously, a command like
      
      $ ghc -tmpdir blah Foo
      
      where the directory blah/ does not exist, would loop forever: getTempDir
      would repeatedly try to create a temporary subdirectory inside blah/,
      catching the does-not-exist error thrown by createDirectory and
      retrying, in vain, with another suffix.
      
      Now instead the above compiler invocation will fail with an error:
      
      blah/ghc25781_0: createDirectory: does not exist (No such file or directory)
      12369d60
  33. 04 Sep, 2013 1 commit
  34. 28 Aug, 2013 1 commit
    • thoughtpolice's avatar
      Rework how iOS does linking (#8127) · 98b0d05d
      thoughtpolice authored
      iOS has some particular constraints about how applications can be built:
      
       * We must generate a static library (.a) since XCode does the final
         link.
       * We need to carefully give the right set of arguments to libtool in
         the case we're generating an archive.
       * Dynamic linking isn't supported.
       * It can only be done on OS X.
      
      This patch cleans up all of the above. We add a new flag `-staticlib`
      (only supported on Darwin) that allows us to produce archive files using
      libtool, and a -pgmlibtool flag to control which 'libtool' executable to
      use.
      
      This fixes #8127. I believe this is the last piece missing from the iOS
      cross compiler.
      Authored-by: lukexi's avatarLuke Iannini <lukexi@me.com>
      Authored-by: maxs's avatarMaxwell Swadling <maxwellswadling@gmail.com>
      Authored-by: default avatarStephen Blackheath <...@blacksapphire.com>
      Signed-off-by: thoughtpolice's avatarAustin Seipp <aseipp@pobox.com>
      98b0d05d
  35. 27 Aug, 2013 1 commit
  36. 17 Jun, 2013 1 commit
    • thoughtpolice's avatar
      Detect linker information at runtime. Fixes Trac #6063 · 71a194d8
      thoughtpolice authored
      Previously, we did ./configure time checks to see if 'GNU ld' supported
      certain options. If it does, we bake those options into the link step.
      See Trac #5240.
      
      Unfortunately, the linker we use at runtime can change for several
      reasons. One is that the user specifies -pgml 'foo'. The other is if
      /usr/bin/ld or whatnot changes from when GHC was built.  Those options
      mentioned earlier are specific to GNU ld, but many systems support GNU
      gold too. This is Trac #6063.
      
      So we need to check at runtime what linker we're using. This is actually
      a little bit complicated because we normally use the C compiler as our
      linker. Windows and OS X are also special here.
      
      Finally, this patch also unconditionally gives '--hash-size=31' and
      '--reduce-memory-overheads' to the system linker if it's GNU ld. These
      options have been supported for 8+ years from what I can see, and there
      are probably a lot of other reasons why GHC would not work with such an
      ancient binutils, all things considered.
      
      See Note [Run-time linker info] in SysTools for details. There are
      plenty of comments as well in the surrounding code.
      Signed-off-by: thoughtpolice's avatarAustin Seipp <aseipp@pobox.com>
      71a194d8
  37. 21 May, 2013 1 commit