1. 20 Sep, 2017 1 commit
    • Sergei Trofimovich's avatar
      aclocal.m4: call cygpath on mingw32 only · d7705f2f
      Sergei Trofimovich authored
      The only reason I noticed is warning these lines on linux:
      
      ```
      $ ./configure --target=sparc-unknown-linux-gnu
      ...
      ./configure: line 9708: cygpath: command not found
      ./configure: line 9708: ArCmd: command not found
      ```
      
      POSIX shell syntax requires no spaces in assignments.
      Fixed guarding condition while at it.
      Signed-off-by: default avatarSergei Trofimovich <slyfox@gentoo.org>
      d7705f2f
  2. 13 Sep, 2017 1 commit
  3. 08 Sep, 2017 1 commit
  4. 06 Sep, 2017 1 commit
    • Moritz Angermann's avatar
      Clean up opt and llc · 22733532
      Moritz Angermann authored
      The LLVM backend shells out to LLVMs `opt` and `llc` tools. This clean
      up introduces a shared data structure to carry the arguments we pass to
      each tool so that corresponding flags are next to each other. It drops
      the hard coded data layouts in favor of using `-mtriple` and have LLVM
      infer them. Furthermore we add `clang` as a proper tool, so we don't
      rely on assuming that `clang` is called `clang` on the `PATH` when using
      `clang` as the assembler.  Finally this diff also changes the type of
      `optLevel` from `Int` to `Word`, as we do not have negative optimization
      levels.
      
      Reviewers: erikd, hvr, austin, rwbarton, bgamari, kavon
      
      Reviewed By: kavon
      
      Subscribers: michalt, Ericson2314, ryantrinkle, dfeuer, carter, simonpj,
      kavon, simonmar, thomie, erikd, snowleopard
      
      Differential Revision: https://phabricator.haskell.org/D3352
      22733532
  5. 29 Aug, 2017 1 commit
    • Tamar Christina's avatar
      Add gen-dll as replacement for dll-split · 5f6a8204
      Tamar Christina authored
      Summary:
      This tool can be used to generate dll's for any list of object files
      given to it. It will then repartition them automatically to fit within
      a dll and generates as many dll's as needed to do this. Cyclic dependencies
      between these generated dlls are handle automatically so there is no need
      to tell it how to partition.
      
      It is also a lot more general than `dll-split` as it is able to split any
      package not just `libGHC`. It also uses a trick using GNU style import libraries
      to hide the splitting from the rest of the pipeline. Which means come linking time
      you don't need to know which dll contains what symbol or how many split dlls were
      created.
      
      The import libraries are by default created with libtool. However since libtool is BFD
      based it is very slow. So if present and detected by configure the `genlib` tool
      from the msys2 project is used. This makes a difference of about ~45 minutes when compiling.
      
      To install `genlib` run `pacman -Sy mingw-w64-$(uname -m)-tools-git`.
      
      More detailed explaination of the process can be found here
      https://ghc.haskell.org/trac/ghc/wiki/WindowsDynamicLinking
      
      Test Plan: ./validate
      
      Reviewers: austin, hvr, bgamari, erikd, simonmar
      
      Reviewed By: bgamari
      
      Subscribers: snowleopard, rwbarton, thomie, erikd, #ghc_windows_task_force
      
      GHC Trac Issues: #5987
      
      Differential Revision: https://phabricator.haskell.org/D3883
      5f6a8204
  6. 28 Jul, 2017 2 commits
    • Ben Gamari's avatar
      configure: Ensure that user's LD setting is respected · d08b9ccd
      Ben Gamari authored
      This broke in the fix for #13541.
      d08b9ccd
    • Ben Gamari's avatar
      Fix lld detection if both gold and lld are found · 2974f81f
      Ben Gamari authored
      If you have ld.gold and ld.lld, then ld.gold will be selected by the
      detection logic. This patch prioritizes lld by changing the order. The
      rationale for checking lld first is that it's (right now) not part of,
      say, a default Linux distro installation and if it's available, it's
      very likely that it was installed explicitly and should be seen as a
      sign of preference. On FreeBSD LLVM is the (default) base toolchain and
      the changed order makes sense there as well, since ld.gold can be
      available in /usr/local via ports/pkg. I don't have access to macOS and
      can't say anything about their LLVM toolchain.
      
      At some point we could add a check for LD=ld.lld or LD=ld.gold as an
      optional override to explicitly select a linker.
      
      Since I cannot really remove gcc on Linux, this was the only way to
      configure GHC to use ld.lld.
      
      Reviewers: austin, hvr, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, erikd
      
      Tags: PHID-PROJ-5azim3sqhsf7wzvlvaag
      
      Differential Revision: https://phabricator.haskell.org/D3790
      2974f81f
  7. 19 Jul, 2017 1 commit
  8. 11 Jul, 2017 2 commits
    • Ben Gamari's avatar
      Use correct section types syntax for architecture · 9b9f978f
      Ben Gamari authored
      Previously GHC would always assume that section types began with `@` while
      producing assembly, which is not true. For instance, in ARM assembly syntax
      section types begin with `%`. This abstracts out section type pretty-printing
      and adjusts it to correctly account for the target architectures assembly
      flavor.
      
      Reviewers: austin, hvr, Phyx
      
      Reviewed By: Phyx
      
      Subscribers: Phyx, rwbarton, thomie, erikd
      
      GHC Trac Issues: #13937
      
      Differential Revision: https://phabricator.haskell.org/D3712
      9b9f978f
    • Ben Gamari's avatar
      configure: Ensure that we don't set LD to unusable linker · fcd2db14
      Ben Gamari authored
      Previously if we found an unusable linker in PATH (e.g. ld.lld on OS X)
      we would notice the -fuse-ld=... was broken, but neglected to reset LD
      to a usable linker. This resulted in brokenness on OS X when lld is in
      PATH.
      
      Test Plan: Validate on OS X with lld in PATH
      
      Reviewers: austin, hvr, angerman
      
      Reviewed By: angerman
      
      Subscribers: rwbarton, thomie, erikd, angerman
      
      GHC Trac Issues: #13541
      
      Differential Revision: https://phabricator.haskell.org/D3713
      fcd2db14
  9. 08 Jul, 2017 1 commit
    • Sergei Trofimovich's avatar
      aclocal.m4: allow arbitrary <vendor> string in toolchain triplets · c2303dff
      Sergei Trofimovich authored
      Canonical triplets have a form of
          <arch>-<vendor>-<os>[-<abi>]
      
      Checking for vendor is almost never correct as it's an
      arbitrary string.
      
      It's useful to have multiple "vendors" to denote
      otherwise the same (WRT <arch>, <os>, <abi>) target:
          --target=x86_64-pc-linux-gnu
          --target=x86_64-unknown-linux-gnu
          --target=x86_64-ghc80-linux-gnu
          --target=x86_64-ghchead-linux-gnu
      
      Do not fail unknown vendors. Only emit a warning.
      Ideally configure checks should never use "vendor".
      Signed-off-by: default avatarSergei Trofimovich <slyfox@gentoo.org>
      c2303dff
  10. 03 Jul, 2017 1 commit
  11. 29 Jun, 2017 3 commits
    • Ben Gamari's avatar
      configure: Coerce gcc to use $LD instead of system default · 625143f4
      Ben Gamari authored
      The configure script will now try to coerce gcc to use the linker
      pointed to by $LD instead of the system default (typically bfd ld).
      Moreover, we now check for `ld.gold` and `ld.lld` before trying `ld`.
      
      The previous behavior can be reverted to by using the new
      --disable-ld-override flag.
      
      On my machine gold seems to trigger an apparent infelicity in
      constructor behavior, causing T5435_asm to fail. I've opened #13883 to
      record this issue and have accepted the questionable constructor
      ordering for the time being.
      
      Test Plan: Validate with `config_args='--enable-ld-override'`
      
      Reviewers: austin, hvr, simonmar
      
      Subscribers: duog, nh2, rwbarton, thomie, erikd, snowleopard
      
      GHC Trac Issues: #13541, #13810, #13883
      
      Differential Revision: https://phabricator.haskell.org/D3449
      625143f4
    • Ben Gamari's avatar
      configure: Check for binutils #17166 · 6171b0b3
      Ben Gamari authored
      This bug affects bfd ld on ARMv7, causing ld to incorrectly emit
      R_REL_COPY relocations, breaking tables-next-to-code. We've known about
      it for several years now and there is not yet a fix upstream. Previously
      we would simply force use of ld.gold on ARM. However, given the rework
      of linking configuration, I thought a more principled solution was in
      order.
      
      Test Plan: Validate on armv7
      
      Reviewers: austin, hvr
      
      Subscribers: angerman, rwbarton, thomie, erikd
      
      GHC Trac Issues: #4210
      
      Differential Revision: https://phabricator.haskell.org/D3676
      6171b0b3
    • 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
  12. 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
  13. 16 Jun, 2017 1 commit
    • Tamar Christina's avatar
      Provide way to build using existing C compiler on Windows. · fda094d0
      Tamar Christina authored
      Summary:
      There are various distros that build GHC using their own C compilers
      such as MSYS2. Currently they have to patch the build scripts everytime.
      
      This patch provides the configure argument `--enable-distro-toolchain`
      which allows one to build using any C compiler on the path.
      
      This is also useful for testing new versions of GCC.
      
      Test Plan:
      ./configure --enable-distro-toolchain && make - && make THREADS=9 test
      ./validate
      
      Reviewers: austin, hvr, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, erikd, #ghc_windows_task_force
      
      GHC Trac Issues: #13792
      
      Differential Revision: https://phabricator.haskell.org/D3637
      fda094d0
  14. 08 Jun, 2017 1 commit
    • Moritz Angermann's avatar
      Check target libtool · cd8f4b99
      Moritz Angermann authored
      This will qualify the libtool with the target, e.g.
      arch-vendor-os-libtool, instead of simply using libtool.
      
      Reviewers: austin, hvr, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: Ericson2314, ryantrinkle, rwbarton, thomie, erikd
      
      Differential Revision: https://phabricator.haskell.org/D3617
      cd8f4b99
  15. 02 Jun, 2017 1 commit
  16. 01 Jun, 2017 1 commit
  17. 23 May, 2017 1 commit
  18. 12 May, 2017 1 commit
  19. 11 May, 2017 3 commits
    • Moritz Angermann's avatar
      Pass LLVMTarget (identical to --target) · 1345c7cc
      Moritz Angermann authored
      Sometimes it might be of interest to
      have access to the raw target value when calling
      subcommands (e.g. llvm tools with --target), as
      such we forward the specified (or inferred)
      --target for later consumption.
      
      Reviewers: austin, hvr, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, erikd
      
      Differential Revision: https://phabricator.haskell.org/D3559
      1345c7cc
    • Moritz Angermann's avatar
      Drop custom apple handling · 6ef6e7c6
      Moritz Angermann authored
      We know that *-apple-* is leading_underscores, and .dylib.
      It is also better to test for TargetVendor being apple, rather than
      relying on targetOS, which could be macOS, iOS, tvOS, watchOS,
      or any other glorious name apple could come up with.
      
      Reviewers: austin, hvr, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, erikd
      
      Differential Revision: https://phabricator.haskell.org/D3557
      6ef6e7c6
    • Moritz Angermann's avatar
      Do not hardcode the specific linker to use · 5ddb307e
      Moritz Angermann authored
      This should be handled appropriately by a wrapper script around the compiler,
      if one wants to insist on the specific linker to be used.  Otherwise this
      breaks if the used compiler fails to understand this directive.
      
      I believe that using a specific linker should be part of the compilers
      toolchain, we delegate to and not hardcoded here in ghc.
      
      Reviewers: dfeuer, erikd, hvr, austin, rwbarton, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: snowleopard, davean, dfeuer, thomie, erikd
      
      Differential Revision: https://phabricator.haskell.org/D3351
      5ddb307e
  20. 08 May, 2017 1 commit
    • Moritz Angermann's avatar
      Fix Raspberry Pi · dc3b4af6
      Moritz Angermann authored
      This is two fold:
      
      - We did not catch all ARM_ARCH_6 defines. Specifically not `6K` and
        `6KZ`, which is what llvm seems to use these days for
        `arm-none-linux-gnueabihf` (e.g. the triple that's used for raspbian
        as well). Without it, ghc assums we want to compile against some armv7
        system, which raspbian is not (it is armv6 for maximum compatibility
        across the pi family, compromising on using armv7 and up features).
      
      - We stop forcing the -m and -arch flags on macOS. This is troublesome,
        as compiling for a 32bit system (e.g. raspberry pi, on a x86_64 macOS
        system results in the `-m64` flag being passed to to clang as well,
        which in turn figures out that you likely want 64bit, and rewrites
        your taret from `arm-none-linux-gnueabihf` to
        `aarch64-none-linux-gnueabihf`, which is definetly not what you want.
      
      Reviewers: austin, hvr, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, erikd
      
      Differential Revision: https://phabricator.haskell.org/D3546
      dc3b4af6
  21. 25 Apr, 2017 2 commits
  22. 23 Apr, 2017 1 commit
  23. 17 Apr, 2017 1 commit
    • Sergei Trofimovich's avatar
      aclocal.m4: respect user's --with-ar= choice · 79848f18
      Sergei Trofimovich authored
      'FP_PROG_AR' macro has a minor bug: it ignores
      already existing value stored in '$fp_prog_ar'.
      
      I've noticed it when tried to built UNREG ghc using thin LTO:
      
        $ ./configure --enable-unregisterised \
                      --with-nm=gcc-nm \
                      --with-ar=gcc-ar \
                      --with-ranlib=gcc-ranlib \
      
      ./configure refused to use 'gcc-ar' (LTO-aware variant of 'ar')
      and kept using 'ar'.
      
      '$fp_prog_ar' is initialized (in a complex manner) in 'configure.ac' as:
      
          FP_ARG_WITH_PATH_GNU_PROG([AR], [ar], [ar])
          ArCmd="$AR"
          fp_prog_ar="$AR"
          AC_SUBST([ArCmd])
      
      The change keeps that value.
      Signed-off-by: default avatarSergei Trofimovich <slyfox@gentoo.org>
      79848f18
  24. 29 Mar, 2017 2 commits
  25. 23 Jan, 2017 1 commit
  26. 20 Jan, 2017 1 commit
  27. 17 Dec, 2016 1 commit
  28. 14 Nov, 2016 1 commit
  29. 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
  30. 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
  31. 22 Aug, 2016 1 commit
    • kgardas's avatar
      pass -z wxneeded or -Wl,-zwxneeded for linking on OpenBSD · f9aa996f
      kgardas authored
      Summary:
      This patch fixes issue with abort in GHCi on OpenBSD current
      as of Aug 12 2016. The OpenBSD is more and more strict about usage
      of writable and executable memory. Programs/applications which
      requires such functionality need to be linked with -z wxneeded linker
      flag and need to be run from the file-system mounted with wxallowed
      mount option. If either of those options in not met, then problematic
      program/application usually fail on some mmap/mprotect call which fail.
      
      Reviewers: bgamari, austin, hvr
      
      Subscribers: thomie, erikd
      
      Differential Revision: https://phabricator.haskell.org/D2454
      f9aa996f