1. 03 Feb, 2018 1 commit
    • Ben Gamari's avatar
      ghc-prim: Emulate C11 atomics when not available · 217e4170
      Ben Gamari authored
      GCC's __sync primitives apparently "usually" imply a full barrier,
      meaning they can be used to emulate the more precise C11 atomics albeit
      with a loss of efficiency. This restores compatibility with GCC 4.4.
      
      This partially reverts commit 59de2909.
      
      Test Plan: Validate on Centos
      
      Reviewers: hvr, simonmar, trommler
      
      Subscribers: rwbarton, thomie, erikd, carter
      
      GHC Trac Issues: #14244
      
      Differential Revision: https://phabricator.haskell.org/D4364
      217e4170
  2. 15 Jan, 2018 1 commit
    • John Ericson's avatar
      configure: Various cleanups · 8de89305
      John Ericson authored
      Substitute RanlibCmd for consistency, and other configure cleanups that
      should have no effect
      
      The other commands are so substituted. Maybe we don't need ranlib at
      all, and the configure snippet can be removed all together, but that
      can always be done later.
      
      Reviewers: bgamari, hvr, angerman
      
      Reviewed By: bgamari, angerman
      
      Subscribers: rwbarton, thomie, erikd, carter
      
      Differential Revision: https://phabricator.haskell.org/D4286
      8de89305
  3. 04 Dec, 2017 1 commit
  4. 16 Nov, 2017 1 commit
  5. 15 Nov, 2017 1 commit
    • Moritz Angermann's avatar
      Adds rts/rts.cabal.in file · 5dea62fb
      Moritz Angermann authored
      This is in preparation for cabalification of the `rts`. To be actually
      able to parse this file, a rather recent Cabal is required. One after
      commit 357d49d of haskell/cabal. The relevant PR to support the new
      `asm-sources` and `cmm-sources` is haskell/cabal/pull/4857.
      
      Not that this does *not* allow cabal to build the RTS. It does however
      provide enough information such that cabal can `copy` and `register`
      the package properly in the package database, if all the build
      artifacts have been build properly.
      
      As such it does not require any custom handling of the `rts` package.
      As the rts as well as all the other packages built by the GHC built
      system are built outside of cabal anyway.
      
      Reviewers: bgamari, hvr, erikd, simonmar
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, erikd
      
      Differential Revision: https://phabricator.haskell.org/D4174
      5dea62fb
  6. 16 Oct, 2017 1 commit
  7. 02 Oct, 2017 1 commit
    • Ben Gamari's avatar
      Rewrite boot in Python · c0e6c734
      Ben Gamari authored
      One step closer to being able to drop the Windows Perl tarball. We
      previously attempted to do this in D3567 but were forced to revert due
      to Windows problems.
      
      Acknowledgements:
       * @Phyx kindly contributed the codepath allowing this to work on
      Windows.
      
      Test Plan: Validate
      
      Reviewers: hvr, austin, Phyx
      
      Subscribers: erikd, thomie, rwbarton
      
      Differential Revision: https://phabricator.haskell.org/D3918
      c0e6c734
  8. 26 Sep, 2017 1 commit
    • Ben Gamari's avatar
      configure: Don't hard-code strip tool · 65f7d87a
      Ben Gamari authored
      For reasons that I don't entirely understand we didn't previously detect
      `strip` using autoconf. This naturally broke during cross-compilation.
      How did this ever work? I have no idea.
      
      Test Plan: Try cross-compiling
      
      Reviewers: austin, hvr, angerman
      
      Subscribers: rwbarton, thomie, erikd
      
      Differential Revision: https://phabricator.haskell.org/D4008
      65f7d87a
  9. 25 Sep, 2017 1 commit
    • Tamar Christina's avatar
      Fix the searching of target AR tool · c839c57e
      Tamar Christina authored
      Summary:
      Ar was being checked twice prior to D3883 where I removed one of the checks
      because the converted path was being overridden after the check because of
      the second check for Ar. However the one in configure.ac was a target check
      so I'm changing the path check to a target check now.
      
      Test Plan: ./configure
      
      Reviewers: angerman, austin, hvr, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, erikd
      
      GHC Trac Issues: #14274
      
      Differential Revision: https://phabricator.haskell.org/D4020
      c839c57e
  10. 19 Sep, 2017 1 commit
  11. 09 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. 25 Aug, 2017 1 commit
  15. 01 Aug, 2017 1 commit
    • Herbert Valerio Riedel's avatar
      Enable building Cabal with parsec · 36fe21aa
      Herbert Valerio Riedel authored
      Cabal's parser has been rewritten in terms of Parsec (which is not
      enabled yet in Cabal-2.0 by default, but can be enabled by a cabal
      flag). The plan for Cabal is to drop support for the non-parsec parser,
      so we need to prepare GHC to cope with new situation.
      
      However, this means that lib:Cabal requires three new library
      dependency submodules,
      
       - parsec
       - text
       - mtl
      
      What complicates matters is that we need to build `ghc-cabal` early on
      during the bootstrap phase which currently needs to invoke `ghc --make`
      directly. So these additional dependencies need to be integrated into
      the monolithic `ghc --make` invocation which produces the `ghc-cabal`
      executable.
      
      Test Plan: `./validate --fast` passed
      
      Reviewers: austin, bgamari
      
      Subscribers: erikd, phadej, rwbarton, thomie
      
      Differential Revision: https://phabricator.haskell.org/D3757
      36fe21aa
  16. 22 Jul, 2017 1 commit
  17. 12 Jul, 2017 1 commit
    • Ben Gamari's avatar
      distrib/configure: Fail if we can't detect machine's word size · 60ec8f74
      Ben Gamari authored
      This is a sure sign that something is terribly wrong.
      
      We also now verify that the word size that the binary distribution
      expects matches the word size produced by the local target toolchain.
      
      Finally we rename WordSize to TargetWordSize, since non-host/target
      qualified quantities are terribly confusing.
      
      Reviewers: austin, hvr, Phyx
      
      Reviewed By: Phyx
      
      Subscribers: Phyx, rwbarton, thomie, erikd
      
      Differential Revision: https://phabricator.haskell.org/D3711
      60ec8f74
  18. 03 Jul, 2017 1 commit
    • Ben Gamari's avatar
      Add -fuse-ld flag to CFLAGS during configure · 960918bd
      Ben Gamari authored
      The decisions made by configure later in the script may depend upon the
      linker used. Consequently, it is important that configure uses the same
      linker as GHC will eventually use.
      
      For instance, on Nix I found that a program requiring `libpthread` would
      link fine with only `-lrt` when linked with BFD ld. However, with gold
      we needed to explicitly provide the `-lpthread` dependency. Presumably
      the former would happily loaded any `NEEDED` libraries whereas the
      latter wants them explicitly given. Regardless, since `configure`'s
      `NEED_PTHREAD_LIB` check didn't use the `-fuse-ld` flag that GHC would
      eventually use, we inferred the wrong value, resulting in link errors
      later in the build.
      
      Test Plan: Validate
      
      Reviewers: austin, hvr
      
      Subscribers: rwbarton, thomie, erikd
      
      GHC Trac Issues: #13541
      
      Differential Revision: https://phabricator.haskell.org/D3694
      960918bd
  19. 29 Jun, 2017 2 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
    • 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. 19 Jun, 2017 1 commit
  21. 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
  22. 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
  23. 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
  24. 26 May, 2017 1 commit
  25. 22 May, 2017 1 commit
  26. 20 May, 2017 1 commit
    • Moritz Angermann's avatar
      Bump to LLVM 4.0 · 82eab628
      Moritz Angermann authored
      The llvm textual ir seems to have stayed sufficiently similar from llvm
      3.9 to llvm 4.0, such that a simple bump is possible.
      
      Reviewers: austin, hvr, bgamari, erikd
      
      Reviewed By: bgamari, erikd
      
      Subscribers: rwbarton, thomie, erikd
      
      Differential Revision: https://phabricator.haskell.org/D3591
      82eab628
  27. 11 May, 2017 1 commit
    • 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. 01 May, 2017 1 commit
  29. 25 Apr, 2017 2 commits
  30. 23 Apr, 2017 1 commit
  31. 17 Apr, 2017 1 commit
  32. 06 Apr, 2017 1 commit
    • Sergei Trofimovich's avatar
      Use non-canocalized triple as cross-compiler prefix · 844704b4
      Sergei Trofimovich authored
      I've noticed the problem when tried to install
      cross-compiler using following configuration:
      
          $ ./configure --target=s390x-unknown-linux-gnu
          make install Stage1Only=YES
      
      Instead of expected tool prefix
          's390x-unknown-linux-gnu-'
      Result was:
          's390x-ibm-linux-gnu-'
      
      It's problematic as installed binaries appear in
      unpredictable location.
      
      The problem is caused by use of ${target} autoconf variable.
      ${target} contains a canocalized triplet.
      
      Luckily we already have non-canonucalized target triplet
      in ${TargetPlatformFull} variable. The change uses that
      instead.
      Signed-off-by: default avatarSergei Trofimovich <slyfox@gentoo.org>
      844704b4
  33. 02 Apr, 2017 2 commits
  34. 29 Mar, 2017 1 commit
  35. 27 Mar, 2017 1 commit
    • Moritz Angermann's avatar
      Adds aarch64 linker for mach-o files. · e8a27410
      Moritz Angermann authored
      This is the final commit that ties them all together. Here we
      add the aarch64 linker for macho files.
      
      - In D3238 we started allowing preloading object code with mmap
        in iOS, where we can't have r+w+x.
      - In D3239 we introduced a richer extension of the object code
        data type to make working with mach-o files easier.
      - In D3240 we set the stage to allow loading archives (.a) on iOS
      - In D3251 we added init and deinit functions to populate and
        depopulate the enriched object code data structure for mach-o
        files.
      - In D3252 we refactored most of the MachO.c file to use the
        new types and datastructure.
      
      This commit will than finally add the aarch64 (arm64) linker
      for mach-o files to ghc, using the improved foundation we
      have constructed above.
      
      The dependency structure therefore is as follows
      
      ```
        .- D3240
        v
      This <- D3252 <- D3251 <- D3239
        ^
        '- D3238
      ```
      
      Depends: D3252, D3240, D3238
      
      Test Plan:
      To test this with iOS, we also need the remote-iserv
      diff D3233. With all that in place, proceed as follows:
      
      - Build ghc for the host
      
      ```
        ghc $ ./configure --prefix=/test/opt \
          --disable-large-address-space \
          --with-llc=/path/to/llvm-3.9/bin/llc \
          --with-opt=/path/to/llvm-3.9/bin/opt
        # edit mk/build.mk to specify quick
        ghc $ make && make install
      ```
      
      - Build ghc for ios
      
      ```
        ghc $ ./configure --target=aarch64-apple-darwin14 \
          --prefix=/test/opt \
          --disable-large-address-space \
          --with-llc=/path/to/llvm-3.9/bin/llc \
          --with-opt=/path/to/llvm-3.9/bin/opt \
          --with-ghc=/test/bin/ghc \
          --enable-bootstrap-with-devel-snapshot
        # edit mk/build.mk to specify quick-cross
        ghc $ make && make install
      
      ```
      - Obtain the iOS wrapper scripts from
      https://github.com/angerman/ghc-ios-scripts
        and place them in PATH.
      
      - Build iserv-proxy for the host
      
      ```
        ghc/iserv $ cabal install -fproxy -flibrary
      
      ```
      - Build iserv-library for the target
      
      ```
        # build cryptonite without integer-gmp
        ghc/iserv $ aarch64-apple-darwin14-cabal install cryptonite
      -f-integer-gmp
        ghc/iserv $ aarch64-apple-darwin14-cabal install -flibrary
      ```
      
      - Create an iOS application with the following `main.m`:
      ```
        #import <UIKit/UIKit.h>
        #include "HsFFI.h"
        extern void startSlave(bool, int, const char *);
      
        int main(int argc, char * argv[]) {
          const char * documents_path = [[[NSFileManager defaultManager]
      URLsForDirectory:NSDocumentDirectory inDomains:NSUserDomainMask]
      firstObject].path.UTF8String;
      
          hs_init(NULL, NULL);
      
          startSlave(false, 5000, documents_path);
      
          @autoreleasepool {
              return UIApplicationMain(argc, argv, nil, nil);
          }
        }
      ```
      
        and link it with: the iserv archive from
      `~/.cabal/lib/aarch64-ios-ghc`
        as well as all dependent archives.
      
      - Build, Install and Launch the iserv-slave application on your iphone
      
      - Compile some Template Haskell code with the
      `aarch64-apple-darwin14-ghc`,
        through the `iserv-proxy`
      
      ```
        app $ aarch64-apple-darwin14-ghc Module.hs \
         -threaded -staticlib \
         -outputdir build/aarch64 -pgmlibtool libtool-quiet -stubdir . \
         -fexternal-interpreter \
         -pgmi=$HOME/.cabal/bin/iserv-proxy \
         -opti10.0.0.1 \
         -opti5000
      ```
        where 10.0.0.1 is the ip of your iserv-slave.
      
        magic.
      
      Reviewers: rwbarton, bgamari, austin, hvr, erikd, simonmar
      
      Subscribers: thomie, erikd, ryantrinkle
      
      Differential Revision: https://phabricator.haskell.org/D3255
      e8a27410
  36. 24 Mar, 2017 1 commit
  37. 10 Mar, 2017 1 commit