1. 25 Sep, 2017 2 commits
  2. 23 Sep, 2017 1 commit
  3. 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>
  4. 13 Sep, 2017 1 commit
  5. 08 Sep, 2017 1 commit
  6. 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
      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
  7. 29 Aug, 2017 1 commit
    • Tamar Christina's avatar
      Add gen-dll as replacement for dll-split · 5f6a8204
      Tamar Christina authored
      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
      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
      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
  8. 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.
    • 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
  9. 19 Jul, 2017 1 commit
  10. 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
      Reviewers: austin, hvr, Phyx
      Reviewed By: Phyx
      Subscribers: Phyx, rwbarton, thomie, erikd
      GHC Trac Issues: #13937
      Differential Revision: https://phabricator.haskell.org/D3712
    • 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
      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
  11. 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
      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:
      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>
  12. 03 Jul, 2017 1 commit
  13. 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
    • 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
      Test Plan: Validate on armv7
      Reviewers: austin, hvr
      Subscribers: angerman, rwbarton, thomie, erikd
      GHC Trac Issues: #4210
      Differential Revision: https://phabricator.haskell.org/D3676
    • 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.
  14. 17 Jun, 2017 1 commit
    • Tamar Christina's avatar
      Remove the Windows GCC driver. · d6cecde5
      Tamar Christina authored
      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
  15. 16 Jun, 2017 1 commit
    • Tamar Christina's avatar
      Provide way to build using existing C compiler on Windows. · fda094d0
      Tamar Christina authored
      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
      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
  16. 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
  17. 02 Jun, 2017 1 commit
  18. 01 Jun, 2017 1 commit
  19. 23 May, 2017 1 commit
  20. 12 May, 2017 1 commit
  21. 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
    • 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
    • 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
  22. 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
  23. 25 Apr, 2017 2 commits
  24. 23 Apr, 2017 1 commit
  25. 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])
      The change keeps that value.
      Signed-off-by: default avatarSergei Trofimovich <slyfox@gentoo.org>
  26. 29 Mar, 2017 2 commits
  27. 23 Jan, 2017 1 commit
  28. 20 Jan, 2017 1 commit
  29. 17 Dec, 2016 1 commit
  30. 14 Nov, 2016 1 commit
  31. 11 Nov, 2016 1 commit
    • 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