1. 26 Oct, 2017 1 commit
  2. 16 Oct, 2017 1 commit
    • Ben Gamari's avatar
      configure: Fix CC version check on Apple compilers · 71a42356
      Ben Gamari authored
      It seems that some Apple LLVM wrappers emit multiple messages containing
      the string "version", which we previously used to find the version
      number.  For instance,
      
          Configured with: --prefix=/Applications/Xcode.app/Contents/...
          Apple LLVM version 9.0.0 (clang-900.0.37)
          Target: x86_64-apple-darwin16.7.0
          Thread model: posix
          InstalledDir: /Applications/Xcode.app/Contents/Developer/...
          Found CUDA installation: /usr/local/cuda, version 8.0
      
      We now take care to only look at the first occurrence of this string.
      
      New `sed` command due to @merijn.
      
      Test Plan: Validate on all the compilers
      
      Reviewers: austin, hvr
      
      Subscribers: rwbarton, thomie, merijn, erikd
      
      Differential Revision: https://phabricator.haskell.org/D4069
      71a42356
  3. 04 Oct, 2017 1 commit
  4. 29 Sep, 2017 1 commit
  5. 27 Sep, 2017 2 commits
    • Ben Gamari's avatar
      configure: Make sure we try all possible linkers · a10729f0
      Ben Gamari authored
      Previously if we had both ld.lld and ld.gold installed but a gcc which
      didn't support -fuse-ld=lld we would fail when trying ld.lld and fall
      immediately back to plain ld. Now we will try ld.gold as well. This was
      brought to light by #14280, where using ld.bfd resulted in a broken
      stage2 compiler.
      
      Test Plan: Configure
      
      Reviewers: angerman, hvr, austin
      
      Reviewed By: angerman
      
      Subscribers: rwbarton, thomie, erikd
      
      GHC Trac Issues: #14280
      
      Differential Revision: https://phabricator.haskell.org/D4038
      a10729f0
    • Moritz Angermann's avatar
      GHC_LLVM_TARGET: Keep android OS · 07ddeaf7
      Moritz Angermann authored
      Summary:
      Our usual GHC_CONVERT_OS macro, will turn any andoird* into android.
      This however drops the essential androideabi part. As such for the
      GHC_LLVM_TARGET we only convert the VENDOR, not the OS.
      
      Reviewers: bgamari, austin, hvr
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, erikd
      
      Differential Revision: https://phabricator.haskell.org/D4031
      07ddeaf7
  6. 26 Sep, 2017 1 commit
  7. 25 Sep, 2017 2 commits
  8. 23 Sep, 2017 1 commit
  9. 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
  10. 13 Sep, 2017 1 commit
  11. 08 Sep, 2017 1 commit
  12. 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
  13. 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
  14. 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
  15. 19 Jul, 2017 1 commit
  16. 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
  17. 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
  18. 03 Jul, 2017 1 commit
  19. 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
  20. 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
  21. 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
  22. 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
  23. 02 Jun, 2017 1 commit
  24. 01 Jun, 2017 1 commit
  25. 23 May, 2017 1 commit
  26. 12 May, 2017 1 commit
  27. 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
  28. 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
  29. 25 Apr, 2017 2 commits
  30. 23 Apr, 2017 1 commit
  31. 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