1. 30 Jul, 2015 1 commit
    • Tamar Christina's avatar
      Make configure error out on missing ghc-tarballs on Windows · 9f7cdfee
      Tamar Christina authored
      Currently checking out the source on windows requires two git
      checkouts. One for the GHC sources and one for the GHC-tarballs.
      
      This patch will make configure issue an error if compiling under
      windows and the GHC-tarballs folder is missing.
      
      On failure the user is told which command they need to run to get the
      tarballs or if they want configure to handle it for them configure
      provide the `--enable-tarballs-autodownload` flag.
      
      Test Plan:
      1. make sure ghc-tarballs folder is not present
      2. run ./configure which should fail giving an error that tarballs is
      missing and how to get it
      3. run ./configure --enable-tarballs-autodownload and the tarballs
      should be downloaded and configure finishes
      4. rerun the command in 3, no new download should be done.
      5. run configure without --enable-tarballs-autodownload, configure
      should finish correctly.
      
      Reviewers: bgamari, austin, thomie
      
      Reviewed By: thomie
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1108
      
      GHC Trac Issues: #10705
      9f7cdfee
  2. 22 Jul, 2015 1 commit
    • gcampax's avatar
      Two step allocator for 64-bit systems · 0d1a8d09
      gcampax authored
      Summary:
      The current OS memory allocator conflates the concepts of allocating
      address space and allocating memory, which makes the HEAP_ALLOCED()
      implementation excessively complicated (as the only thing it cares
      about is address space layout) and slow. Instead, what we want
      is to allocate a single insanely large contiguous block of address
      space (to make HEAP_ALLOCED() checks fast), and then commit subportions
      of that in 1MB blocks as we did before.
      This is currently behind a flag, USE_LARGE_ADDRESS_SPACE, that is only enabled for
      certain OSes.
      
      Test Plan: validate
      
      Reviewers: simonmar, ezyang, austin
      
      Subscribers: thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D524
      
      GHC Trac Issues: #9706
      0d1a8d09
  3. 21 Jul, 2015 1 commit
  4. 03 Jul, 2015 1 commit
    • Peter Trommler's avatar
      Implement PowerPC 64-bit native code backend for Linux · d3c1dda6
      Peter Trommler authored
      Extend the PowerPC 32-bit native code generator for "64-bit
      PowerPC ELF Application Binary Interface Supplement 1.9" by
      Ian Lance Taylor and "Power Architecture 64-Bit ELF V2 ABI Specification --
      OpenPOWER ABI for Linux Supplement" by IBM.
      The latter ABI is mainly used on POWER7/7+ and POWER8
      Linux systems running in little-endian mode. The code generator
      supports both static and dynamic linking. PowerPC 64-bit
      code for ELF ABI 1.9 and 2 is mostly position independent
      anyway, and thus so is all the code emitted by the code
      generator. In other words, -fPIC does not make a difference.
      
      rts/stg/SMP.h support is implemented.
      
      Following the spirit of the introductory comment in
      PPC/CodeGen.hs, the rest of the code is a straightforward
      extension of the 32-bit implementation.
      
      Limitations:
      * Code is generated only in the medium code model, which
        is also gcc's default
      * Local symbols are not accessed directly, which seems to
        also be the case for 32-bit
      * LLVM does not work, but this does not work on 32-bit either
      * Must use the system runtime linker in GHCi, because the
        GHC linker for "static" object files (rts/Linker.c) for
        PPC 64-bit is not implemented. The system runtime
        (dynamic) linker works.
      * The handling of the system stack (register 1) is not ELF-
        compliant so stack traces break. Instead of allocating a new
        stack frame, spill code should use the "official" spill area
        in the current stack frame and deallocation code should restore
        the back chain
      * DWARF support is missing
      
      Fixes #9863
      
      Test Plan: validate (on powerpc, too)
      
      Reviewers: simonmar, trofi, erikd, austin
      
      Reviewed By: trofi
      
      Subscribers: bgamari, arnons1, kgardas, thomie
      
      Differential Revision: https://phabricator.haskell.org/D629
      
      GHC Trac Issues: #9863
      d3c1dda6
  5. 10 Apr, 2015 1 commit
  6. 23 Mar, 2015 1 commit
    • Erik de Castro Lopo's avatar
      Do version specific detection of LLVM tools (#10170). · 42448e37
      Erik de Castro Lopo authored
      The LLVM developers seem to make breaking changes in the LLVM IR
      language between major releases. As a consumer of the LLVM tools
      GHC now needs to be locked more tightly to a single version of
      the LLVM tools.
      
      GHC HEAD currently only supports LLVM version 3.6. This commit
      changes the configure script to look for `llc-3.6` and `opt-3.6`
      before looking for `llc` and `opt`. If the former are not found,
      but the later are, check that they actually are version 3.6.
      
      At the same time, when detecting known problems with the LLVM
      tools (ie #9439) test for it using the versions of the LLVM tools
      retrieved from the bootstrap compiler's settings file.
      
      Test Plan: Manual testing.
      
      Reviewers: thomie, rwbarton, nomeata, austin
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D745
      
      GHC Trac Issues: #10170
      42448e37
  7. 12 Mar, 2015 1 commit
    • Erik de Castro Lopo's avatar
      Use the gold linker for linux/ARM and android/ARM targets. · 71fcc4c0
      Erik de Castro Lopo authored
      Fixes #8976 and #9873 by making use of the Binutils ld.gold
      linker explicit whenever the target is linux/ARM or android/ARM.
      This does not affect iOS where Apple provides its own linker.
      
      In order to achieve this, we need to add `-fuse-ld=gold` to
      the SettingsCCompilerLinkFlags setting and set
      SettingsLdCommand to `ld.gold` (or `${target}-ld.gold` when
      cross-compiling). In addition, simplifying the use of
      `$(CONF_GCC_LINKER_OPTS_STAGEn)`.
      
      This patch was tested by ensuring that the following worked
      as expected:
      
        * Native builds on linux/x86_64 (nothing changed).
        * Native builds on linux/arm (and uses the gold linker).
        * Linux to linux/arm cross compiles (and uses the cross
          gold linker).
      
      Contributions by Ben Gamari, Joachim Breitner and Reid Barton.
      
      Reviewers: nomeata, bgamari, austin, rwbarton
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D715
      
      GHC Trac Issues: #8976 #9873
      71fcc4c0
  8. 02 Mar, 2015 1 commit
    • thomie's avatar
      Fix detection of llvm-x.x · 1dfab7a8
      thomie authored
      Summary:
      Four bug fixes and a little refactoring.
      * `find -perm \mode` should be `find -perm /mode` (#9697)
      
      * `find -regex '$3' should be `find -regex "$3"` (#7661)
      
      From `man sh` on my system (Ubuntu 14.04):
      "Enclosing characters in single quotes preserves the literal meaning of all
      the characters ..."
      
      * LlcCmd and OptCmd should be passed to ghc, using `-pgmlo` and `-pgmlc`, for
        detection of #9439.
      
      * -pgmlo and -pgmlc were undocumented because of an xml tag misplacement.
      
      Test Plan:
      The aclocal.m4 macro has seen about 10 iterations since its inception. Without a
      testsuite, I can't guarantee this version is bug free either. It's all pretty
      frustrating.
      
      Reviewers: bgamari, austin
      
      Reviewed By: austin
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D683
      
      GHC Trac Issues: #9697, #7661, #9439
      1dfab7a8
  9. 23 Feb, 2015 1 commit
    • PHO's avatar
      Make top-level "configure" accept and propagate --with-curses-{includes,libraries} to libraries · bbb57a6b
      PHO authored
      Summary:
      If curses is installed into some non-standard path, we currently have
      to say something like the following in mk/build.mk:
      
        libraries/terminfo_CONFIGURE_OPTS += \
            --configure-option=--with-curses-includes=/somewhere/include \
            --configure-option=--with-curses-libraries=/somewhere/lib
      
      This is because the top-level configure does not accept nor propagate
      --with-curses-{includes,libraries} to libraries while it does so for
      iconv, gmp and libffi. It would be nice if curses were handled in the
      same manner.
      
      Test Plan: Install curses into some non-standard path. Then run the top-level "configure" script with options "--with-curses-includes=/path/to/curses/include" and "--with-curses-libraries=/path/to/curses/lib".
      
      Reviewers: austin
      
      Reviewed By: austin
      
      Subscribers: thomie, PHO
      
      Differential Revision: https://phabricator.haskell.org/D665
      
      GHC Trac Issues: #10096
      bbb57a6b
  10. 17 Feb, 2015 1 commit
  11. 12 Jan, 2015 1 commit
    • rwbarton's avatar
      Move libffi configuration after basic toolchain setup · a5bc2579
      rwbarton authored
      Summary:
      The relevant aspect is that the libffi configuration's AC_CHECK_LIB
      and AC_CHECK_HEADERS are moved after FIND_GCC. There are two reasons
      to do this:
      
      1. We should detect the presence of libffi using the C compiler
      that we are eventually going to use to build GHC.
      
      2. Running AC_CHECK_HEADERS before FIND_GCC pollutes the CPP variable
      with "gcc -E" (wrong when cross-compiling), and CPP is not reset
      by FIND_GCC. Thus this patch fixes x86_64 -> i386 cross-compilation
      of integer-gmp2.
      
      Test Plan: Local x86_64 -> i386 cross-compiling validate; Harbormaster
      
      Reviewers: austin
      
      Reviewed By: austin
      
      Subscribers: erikd, carter, thomie
      
      Differential Revision: https://phabricator.haskell.org/D597
      a5bc2579
  12. 22 Dec, 2014 3 commits
  13. 27 Nov, 2014 1 commit
    • Herbert Valerio Riedel's avatar
      Embed Git commit id into `ghc --info` output · 73e5e2f8
      Herbert Valerio Riedel authored
      Since we switched to a Git submodule based GHC Git repo, `ghc.git`'s
      commit id uniquely identifies the state of the GHC source-tree. So
      having that information embedded into the `ghc` executable provides
      valuable information to track accurately (especially when created by
      buildbots) from which source-tree-state a given `ghc` snapshot
      (distribution) was generated.
      
      So this commit adds a new field `"Project Git commit id"` to the
      `ghc --info` meta-data containing the `./configure`-time Git commit id
      as reported by `git rev-parse HEAD`.
      
      This field can also be queried with `ghc --print-project-git-commit-id`.
      
      For source distributions, the file `GIT_COMMIT_ID` is created (with some
      sanity checking to detect stale commit ids, as that would render this
      information rather useless)
      
      Reviewed By: austin
      
      Differential Revision: https://phabricator.haskell.org/D528
      73e5e2f8
  14. 26 Nov, 2014 1 commit
  15. 19 Nov, 2014 1 commit
  16. 14 Oct, 2014 1 commit
  17. 07 Oct, 2014 1 commit
    • Yuras's avatar
      Fix configure check for 9439 bug · 1ec91133
      Yuras authored
      Summary: We should escape path to ghc.On wondows usually ghc comes from HP, which is installed somewhere in "...\Haskell Platform\..." Note space in the middle.
      
      Test Plan: not necessary
      
      Reviewers: rwbarton, hvr, austin
      
      Reviewed By: rwbarton, hvr, austin
      
      Subscribers: rwbarton, simonmar, ezyang, carter, thomie
      
      Projects: #ghc
      
      Differential Revision: https://phabricator.haskell.org/D304
      1ec91133
  18. 05 Oct, 2014 1 commit
    • Sergei Trofimovich's avatar
      rts: unrust 'libbfd' debug symbols parser · cb0a503a
      Sergei Trofimovich authored
      Summary:
      Patch does the following:
      - fixes detection of working libbfd on modern linux
        platforms (where bfd_uncompress_section_contents is a macro)
      - disables 'bfd' by default and adds '--enable-bfd-debug'
        configure option. As bfd's ABI is unstable
        the feature is primarily useful by ghc hackers.
      
      Not done (subject for another patch):
      - one-time bfd object memory leak in DEBUG_LoadSymbols
      - in '-dynamic' mode debugging symbols are loaded only for
        current executable, not all libraries it is linked against.
      
      Fixes Issue #8790Signed-off-by: default avatarSergei Trofimovich <slyfox@gentoo.org>
      
      Test Plan: built unregisterised ghc on amd64 and ran './hello +RTS -Di' there
      
      Reviewers: simonmar, austin
      
      Reviewed By: simonmar, austin
      
      Subscribers: thomie, simonmar, ezyang, carter
      
      Differential Revision: https://phabricator.haskell.org/D193
      
      GHC Trac Issues: #8790
      cb0a503a
  19. 02 Sep, 2014 1 commit
  20. 19 Aug, 2014 2 commits
  21. 17 Aug, 2014 1 commit
    • kgardas's avatar
      workaround Solaris 11 GNU C CPP issue by using GNU C 3.4 as CPP · 2d42564a
      kgardas authored
      Summary:
      Solaris 11 distributed GNU C 4.5.x is configured in a way that its
      CPP is not working well while invoked from GHC. GHC runs it with
      -x assembler-with-cpp and in this particular configuration GNU C CPP
      does not provide any line-markers so GHC's output of errors or warnings
      is confusing since it points to preprocessed file in /tmp and not
      to the original Haskell file. Fortunately old GNU C 3.4.x is still
      provided by the OS and when installed it'll be used automatically
      as GHC CPP which is whole logic of this patch. So although we use modern
      GCC as a C compiler and assembler we use old GCC as a C preprocessor.
      
      Test Plan: validate
      
      Reviewers: austin
      
      Reviewed By: austin
      
      Subscribers: phaskell, simonmar, relrod, ezyang, carter
      
      Differential Revision: https://phabricator.haskell.org/D151
      2d42564a
  22. 13 Aug, 2014 1 commit
  23. 09 Aug, 2014 1 commit
  24. 05 Aug, 2014 1 commit
  25. 04 Jul, 2014 1 commit
  26. 02 Jul, 2014 1 commit
  27. 27 Mar, 2014 2 commits
  28. 23 Mar, 2014 2 commits
  29. 07 Feb, 2014 1 commit
  30. 29 Jan, 2014 1 commit
  31. 28 Jan, 2014 1 commit
  32. 01 Oct, 2013 1 commit
  33. 29 Sep, 2013 1 commit
  34. 04 Sep, 2013 1 commit
    • thoughtpolice's avatar
      Make sure -fcmm-sink is passed to Parser properly · 9e133b9d
      thoughtpolice authored
      Parser.hs needs to be compiled with -fcmm-sink on x86 platforms, so the
      register allocator doesn't run out of stack slots. Previously, we had to
      do some CPP hacks in order to emit an #ifdef into the file - this is
      because we preprocess it once up front, and run the preprocessor again
      when we compile it.
      
      There's two cases: the boostrap compiler is > 7.8, and the stage1 parser
      needs the flag, or the stage1 compiler is compiling the stage2
      Parser.hs, and needs the flag..
      
      The previous approach was super fragile with Clang. The more principled
      fix is to instead do this through the build system.
      
      This fixes #8182.
      Signed-off-by: thoughtpolice's avatarAustin Seipp <aseipp@pobox.com>
      9e133b9d
  35. 03 Jul, 2013 1 commit
    • ian@well-typed.com's avatar
      Change the ranlib detection · c548fec4
      ian@well-typed.com authored
      On Windows, the ranlib in the path may not be the right ranlib (it may
      be the 32bit ranlib when we are making a Win64 compiler, or vice-versa).
      Therefore we can't leave it up to libffi to detect the right ranlib, but
      need to tell it which ranlib to use. This means that we need to find
      ranlib even if we don't actually need it ourselves.
      c548fec4