1. 17 May, 2022 1 commit
    • Ben Gamari's avatar
      driver: Introduce pgmcxx · fb579e15
      Ben Gamari authored and Marge Bot's avatar Marge Bot committed
      Here we introduce proper support for compilation of C++ objects. This
      includes:
      
       * logic in `configure` to detect the C++ toolchain and propagating this
         information into the `settings` file
       * logic in the driver to use the C++ toolchain when compiling C++
         sources
      fb579e15
  2. 27 Apr, 2022 1 commit
    • Ben Gamari's avatar
      Enable eventlog support in all ways by default · ee11d043
      Ben Gamari authored and Marge Bot's avatar Marge Bot committed
      Here we deprecate the eventlogging RTS ways and instead enable eventlog
      support in the remaining ways. This simplifies packaging and reduces GHC
      compilation times (as we can eliminate two whole compilations of the RTS)
      while simplifying the end-user story. The trade-off is a small increase
      in binary sizes in the case that the user does not want eventlogging
      support, but we think that this is a fine trade-off.
      
      This also revealed a latent RTS bug: some files which included `Cmm.h`
      also assumed that it defined various macros which were in fact defined
      by `Config.h`, which `Cmm.h` did not include. Fixing this in turn
      revealed that `StgMiscClosures.cmm` failed to import various spinlock
      statistics counters, as evidenced by the failed unregisterised build.
      
      Closes #18948.
      ee11d043
  3. 25 Apr, 2022 1 commit
    • Ben Gamari's avatar
      Drop remaining vestiges of libtool · 41cf758b
      Ben Gamari authored and Marge Bot's avatar Marge Bot committed
      Drop libtool logic from gen-dll, allowing us to drop the remaining logic
      from the `configure` script.
      
      Strangely, this appears to reliably reduce compiler allocations of
      T16875 on Windows.
      
      Closes #18826.
      
      Metric Decrease:
          T16875
      41cf758b
  4. 06 Apr, 2022 2 commits
    • Ben Gamari's avatar
      Windows/Clang: Build system adaptation · 6be2c5a7
      Ben Gamari authored
      * Bump win32-tarballs to 0.7
      * Move Windows toolchain autoconf logic into separate file
      * Use clang and LLVM utilities as described in #21019
      * Disable object merging as lld doesn't support -r
      * Drop --oformat=pe-bigobj-x86-64 arguments from ld flags as LLD detects
        that the output is large on its own.
      * Drop gcc wrapper since Clang finds its root fine on its own.
      6be2c5a7
    • Ben Gamari's avatar
      Build ar archives with -L when "joining" objects · d2ae0a3a
      Ben Gamari authored and Marge Bot's avatar Marge Bot committed
      Since there may be .o files which are in fact archives.
      d2ae0a3a
  5. 08 Feb, 2022 1 commit
  6. 01 Feb, 2022 1 commit
  7. 29 Jan, 2022 1 commit
  8. 27 Nov, 2021 1 commit
  9. 22 Sep, 2021 1 commit
  10. 09 Aug, 2021 1 commit
    • John Ericson's avatar
      Move `/includes` to `/rts/include`, sort per package better · d5de970d
      John Ericson authored and Marge Bot's avatar Marge Bot committed
      In order to make the packages in this repo "reinstallable", we need to
      associate source code with a specific packages. Having a top level
      `/includes` dir that mixes concerns (which packages' includes?) gets in
      the way of this.
      
      To start, I have moved everything to `rts/`, which is mostly correct.
      There are a few things however that really don't belong in the rts (like
      the generated constants haskell type, `CodeGen.Platform.h`). Those
      needed to be manually adjusted.
      
      Things of note:
      
       - No symlinking for sake of windows, so we hard-link at configure time.
      
       - `CodeGen.Platform.h` no longer as `.hs` extension (in addition to
         being moved to `compiler/`) so as not to confuse anyone, since it is
         next to Haskell files.
      
       - Blanket `-Iincludes` is gone in both build systems, include paths now
         more strictly respect per-package dependencies.
      
       - `deriveConstants` has been taught to not require a `--target-os` flag
         when generating the platform-...
      d5de970d
  11. 27 Jul, 2021 1 commit
  12. 07 Apr, 2021 1 commit
    • Sylvain Henry's avatar
      Remove dynamic-by-default (#16782) · d014ab0d
      Sylvain Henry authored and Marge Bot's avatar Marge Bot committed
      Dynamic-by-default was a mechanism to automatically select the -dynamic
      way for some targets.
      
      It was implemented in a convoluted way: it was defined as a flavour
      option, hence it couldn't be passed as a global settings (which are
      produced by `configure` before considering flavours), so a build system
      rule was used to pass -DDYNAMIC_BY_DEFAULT to the C compiler so that
      deriveConstants could infer it.
      
      * Make build system has it disabled for 8 years (951e28c0)
      * It has never been implemented in Hadrian
      * Last time someone tried to enable it 1 year ago it didn't work (!2436)
      * Having this as a global constant impedes making GHC multi-target (see !5427)
      
      This commit fully removes support for dynamic-by-default. If someone
      wants to reimplement something like this, it would probably need to move
      the logic in the compiler.
      
      (Doing this would probably need some refactoring of the way the compiler
      handles DynFlags: DynFlags are used to store and to pass enabled ways to
      many parts of the compiler. It can be set by command-line flags, GHC
      API, global settings. In multi-target GHC, we will use DynFlags to load
      the target platform and its constants: but at this point with the
      current DynFlags implementation we can't easily update the existing
      DynFlags with target-specific options such as dynamic-by-default without
      overriding ways previously set by the user.)
      d014ab0d
  13. 05 Mar, 2021 1 commit
  14. 08 Sep, 2020 1 commit
    • Moritz Angermann's avatar
      [macOS] improved runpath handling · 4ff93292
      Moritz Angermann authored and Marge Bot's avatar Marge Bot committed
      In b592bd98 we started using
      -dead_strip_dylib on macOS when lining dynamic libraries and binaries.
      The underlying reason being the Load Command Size Limit in macOS
      Sierra (10.14) and later.
      
      GHC will produce @rpath/libHS... dependency entries together with a
      corresponding RPATH entry pointing to the location of the libHS...
      library. Thus for every library we produce two Load Commands.  One to
      specify the dependent library, and one with the path where to find it.
      This makes relocating libraries and binaries easier, as we just need to
      update the RPATH entry with the install_name_tool. The dynamic linker
      will then subsitute each @rpath with the RPATH entries it finds in the
      libraries load commands or the environement, when looking up @rpath
      relative libraries.
      
      -dead_strip_dylibs intructs the linker to drop unused libraries. This in
      turn help us reduce the number of referenced libraries, and subsequently
      the size of the load commands.  This however does not remove the RPATH
      entries.  Subsequently we can end up (in extreme cases) with only a
      single @rpath/libHS... entry, but 100s or more RPATH entries in the Load
      Commands.
      
      This patch rectifies this (slighly unorthodox) by passing *no* -rpath
      arguments to the linker at link time, but -headerpad 8000.  The
      headerpad argument is in hexadecimal and the maxium 32k of the load
      command size.  This tells the linker to pad the load command section
      enough for us to inject the RPATHs later.  We then proceed to link the
      library or binary with -dead_strip_dylibs, and *after* the linking
      inspect the library to find the left over (non-dead-stripped)
      dependencies (using otool).  We find the corresponding RPATHs for each
      @rpath relative dependency, and inject them into the library or binary
      using the install_name_tool.  Thus achieving a deadstripped dylib (and
      rpaths) build product.
      
      We can not do this in GHC, without starting to reimplement a dynamic
      linker as we do not know which symbols and subsequently libraries are
      necessary.
      
      Commissioned-by: Mercury Technologies, Inc. (mercury.com)
      4ff93292
  15. 05 Sep, 2020 1 commit
  16. 28 Aug, 2020 1 commit
  17. 05 Aug, 2020 1 commit
    • Ben Gamari's avatar
      Refactor handling of object merging · 53ce0db5
      Ben Gamari authored and Marge Bot's avatar Marge Bot committed
      Previously to merge a set of object files we would invoke the linker as
      usual, adding -r to the command-line. However, this can result in
      non-sensical command-lines which causes lld to balk (#17962).
      
      To avoid this we introduce a new tool setting into GHC, -pgmlm, which is
      the linker which we use to merge object files.
      53ce0db5
  18. 23 Jul, 2020 1 commit
    • Sylvain Henry's avatar
      Replace ghcWithNativeCodeGen with a proper Backend datatype · 735f9d6b
      Sylvain Henry authored and Marge Bot's avatar Marge Bot committed
      * Represent backends with a `Backend` datatype in GHC.Driver.Backend
      
      * Don't detect the default backend to use for the target platform at
        compile time in Hadrian/make but at runtime. It makes "Settings"
        simpler and it is a step toward making GHC multi-target.
      
      * The latter change also fixes hadrian which has not been updated to
        take into account that the NCG now supports AIX and PPC64 (cf
        df26b955 and
        d3c1dda6)
      
      * Also we don't treat iOS specifically anymore (cf
        cb4878ff)
      735f9d6b
  19. 25 Jun, 2020 1 commit
    • Ben Gamari's avatar
      hadrian/make: Detect makeindex · 4acc2934
      Ben Gamari authored and Marge Bot's avatar Marge Bot committed
      Previously we would simply assume that makeindex was available.
      Now we correctly detect it in `configure` and respect this conclusion in
      hadrian and make.
      4acc2934
  20. 17 Jun, 2020 1 commit
  21. 01 Jun, 2020 1 commit
  22. 29 May, 2020 1 commit
  23. 01 Apr, 2020 1 commit
  24. 22 Feb, 2020 1 commit
  25. 13 Jan, 2020 1 commit
  26. 19 Nov, 2019 1 commit
  27. 06 Nov, 2019 1 commit
  28. 30 Oct, 2019 1 commit
  29. 29 Oct, 2019 1 commit
  30. 25 Oct, 2019 1 commit
    • Ben Gamari's avatar
      configure: Drop GccLT46 · 519f5162
      Ben Gamari authored and Marge Bot's avatar Marge Bot committed
      GCC 4.6 was released 7 years ago. I think we can finally assume that
      it's available. This is a simplification prompted by #15742.
      519f5162
  31. 22 Oct, 2019 1 commit
    • Stefan Schulze Frielinghaus's avatar
      Implement s390x LLVM backend. · fd8b666a
      Stefan Schulze Frielinghaus authored and Marge Bot's avatar Marge Bot committed
      This patch adds support for the s390x architecture for the LLVM code
      generator. The patch includes a register mapping of STG registers onto
      s390x machine registers which enables a registerised build.
      fd8b666a
  32. 12 Oct, 2019 1 commit
    • John Ericson's avatar
      Simplify Configure in a few ways · c2290596
      John Ericson authored and Marge Bot's avatar Marge Bot committed
       - No need to distinguish between gcc-llvm and clang. First of all,
         gcc-llvm is quite old and surely unmaintained by now. Second of all,
         none of the code actually care about that distinction!
      
         Now, it does make sense to consider C multiple frontends for LLVMs in
         the form of clang vs clang-cl (same clang, yes, but tweaked
         interface). But this is better handled in terms of "gccish vs
         mvscish" and "is LLVM", yielding 4 combinations. Therefore, I don't
         think it is useful saving the existing code for that.
      
       - Get the remaining CC_LLVM_BACKEND, and also TABLES_NEXT_TO_CODE in
         mk/config.h the normal way, rather than hacking it post-hoc. No point
         keeping these special cases around for now reason.
      
       - Get rid of hand-rolled `die` function and just use `AC_MSG_ERROR`.
      
       - Abstract check + flag override for unregisterised and tables next to
         code.
      
      Oh, and as part of the above I also renamed/combined some variables
      where it felt appropriate.
      
       - GccIsClang -> CcLlvmBackend. This is for `AC_SUBST`, like the other
       Camal case ones. It was never about gcc-llvm, or Apple's renamed clang,
       to be clear.
      
       - llvm_CC_FLAVOR -> CC_LLVM_BACKEND. This is for `AC_DEFINE`, like the
       other all-caps snake case ones. llvm_CC_FLAVOR was just silly
       indirection *and* an odd name to boot.
      c2290596
  33. 07 Oct, 2019 2 commits
  34. 05 Oct, 2019 1 commit
  35. 05 Sep, 2019 1 commit
  36. 10 Aug, 2019 1 commit
    • Joachim Breitner's avatar
      Consolidate `TablesNextToCode` and `GhcUnreigsterised` in configure (#15548) · 81860281
      Joachim Breitner authored and Marge Bot's avatar Marge Bot committed
      `TablesNextToCode` is now a substituted by configure, where it has the
      correct defaults and error handling. Nowhere else needs to duplicate
      that, though we may want the compiler to to guard against bogus settings
      files.
      
      I renamed it from `GhcEnableTablesNextToCode` to `TablesNextToCode` to:
      
       - Help me guard against any unfixed usages
      
       - Remove any lingering connotation that this flag needs to be combined
         with `GhcUnreigsterised`.
      
      Original reviewers:
      
      Original subscribers: TerrorJack, rwbarton, carter
      
      Original Differential Revision: https://phabricator.haskell.org/D5082
      81860281
  37. 14 Jun, 2019 1 commit
    • Ben Gamari's avatar
      Maintain separate flags for C++ compiler invocations · 7bc5d6c6
      Ben Gamari authored and Marge Bot's avatar Marge Bot committed
      Previously we would pass flags intended for the C compiler to the C++
      compiler (see #16738). This would cause, for instance, `-std=gnu99` to
      be passed to the C++ compiler, causing spurious test failures. Fix this
      by maintaining a separate set of flags for C++ compilation invocations.
      7bc5d6c6
  38. 14 May, 2019 1 commit