1. 17 Dec, 2015 1 commit
    • Simon Marlow's avatar
      Remote GHCi, -fexternal-interpreter · 4905b83a
      Simon Marlow authored
      Summary:
      (Apologies for the size of this patch, I couldn't make a smaller one
      that was validate-clean and also made sense independently)
      
      (Some of this code is derived from GHCJS.)
      
      This commit adds support for running interpreted code (for GHCi and
      TemplateHaskell) in a separate process.  The functionality is
      experimental, so for now it is off by default and enabled by the flag
      -fexternal-interpreter.
      
      Reaosns we want this:
      
      * compiling Template Haskell code with -prof does not require
        building the code without -prof first
      
      * when GHC itself is profiled, it can interpret unprofiled code, and
        the same applies to dynamic linking.  We would no longer need to
        force -dynamic-too with TemplateHaskell, and we can load ordinary
        objects into a dynamically-linked GHCi (and vice versa).
      
      * An unprofiled GHCi can load and run profiled code, which means it
        can use the stack-trace functionality provided by profiling without
        taking the performance hit on the compiler that profiling would
        entail.
      
      Amongst other things; see
      https://ghc.haskell.org/trac/ghc/wiki/RemoteGHCi for more details.
      
      Notes on the implementation are in Note [Remote GHCi] in the new
      module compiler/ghci/GHCi.hs.  It probably needs more documenting,
      feel free to suggest things I could elaborate on.
      
      Things that are not currently implemented for -fexternal-interpreter:
      
      * The GHCi debugger
      * :set prog, :set args in GHCi
      * `recover` in Template Haskell
      * Redirecting stdin/stdout for the external process
      
      These are all doable, I just wanted to get to a working validate-clean
      patch first.
      
      I also haven't done any benchmarking yet.  I expect there to be slight hit
      to link times for byte code and some penalty due to having to
      serialize/deserialize TH syntax, but I don't expect it to be a serious
      problem.  There's also lots of low-hanging fruit in the byte code
      generator/linker that we could exploit to speed things up.
      
      Test Plan:
      * validate
      * I've run parts of the test suite with
      EXTRA_HC_OPTS=-fexternal-interpreter, notably tests/ghci and tests/th.
      There are a few failures due to the things not currently implemented
      (see above).
      
      Reviewers: simonpj, goldfire, ezyang, austin, alanz, hvr, niteria, bgamari, gibiansky, luite
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1562
      4905b83a
  2. 13 Dec, 2015 1 commit
  3. 21 Nov, 2015 1 commit
    • Herbert Valerio Riedel's avatar
      Suppress conflicting types for builtins warnings · 192dd068
      Herbert Valerio Riedel authored
      GCC 4.0 and later warn about type-conflicting prototypes for built-in
      functions such as `strlen`. This is a problem for the via-c backend as
      it generates code such as
      
        typedef void *(*(*StgFunPtr)(void))(void);
        extern StgFunPtr strlen();
      
      However, by using the `-fno-builtin` flag, GCC is told not to try to
      auto-detect such built-in functions and instead treat them as ordinary
      external functions.  This also suppresses this warning.
      
      This address #7660
      
      Test Plan: IIAM
      
      Reviewers: bgamari, austin
      
      Reviewed By: austin
      
      Subscribers: thomie, erikd
      
      Differential Revision: https://phabricator.haskell.org/D1506
      
      GHC Trac Issues: #7660
      192dd068
  4. 20 Nov, 2015 1 commit
  5. 19 Nov, 2015 2 commits
    • Herbert Valerio Riedel's avatar
      Set AIX specific CFLAGS flags · 75036aac
      Herbert Valerio Riedel authored
      First of all, we need to use -mminimal-toc on IBM AIX
      
      AIX's XCOFF is limited to 16k entries in its TOC for 32bit compilation,
      which quickly overflows with GHC's code generation.
      
      Otoh, the Parser.hs module contains more entries than fit into a
      minimal-toc, so we need to switch back to `-mfull-toc` for that single
      module again.
      
      Then, we also need to set the `THREAD_SAFE` CPP #define in order to
      unlock the thread-safe `errno` which is essential for the threaded
      runtime.
      
      Depends on D1501
      
      Reviewers: austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie, erikd
      
      Differential Revision: https://phabricator.haskell.org/D1502
      75036aac
    • Herbert Valerio Riedel's avatar
      Make GHC aware of OSAIX and AixLD · c5d8162d
      Herbert Valerio Riedel authored
      GHC needs to be aware of targetting AIX because
      AIX requires some special handling for the toolchain
      (similiar to Solaris)
      
      Reviewers: austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie, erikd
      
      Differential Revision: https://phabricator.haskell.org/D1501
      c5d8162d
  6. 17 Nov, 2015 1 commit
    • Herbert Valerio Riedel's avatar
      Make `timer_create(CLOCK_REALTIME)` autoconf test more reliable · 8ad9e74f
      Herbert Valerio Riedel authored
      I've noticed that on a platform with a coarse timer/scheduling
      granularity of 10ms this autoconf tests fails to detect a working
      `timer_create(CLOCK_REALTIME)`.
      
      On AIX, this effectively means that intervals/timers are rounded up to
      multiples of 10ms, so a 13ms delay is effectively a 20ms delay.
      
      By using a 100ms timeout we are on the safe side.
      
      Reviewers: austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie, erikd
      
      Differential Revision: https://phabricator.haskell.org/D1483
      8ad9e74f
  7. 22 Oct, 2015 1 commit
  8. 14 Oct, 2015 1 commit
    • Erik de Castro Lopo's avatar
      Fix GHCi on Arm (#10375). · 933adc0f
      Erik de Castro Lopo authored
      Arm has two instruction sets, Arm and Thumb, and an execution mode for each.
      Executing Arm code in Thumb mode or vice-versa will likely result in an
      Illegal instruction exception.
      
      Furthermore, Haskell code compiled via LLVM was generating Arm instructions
      while C code compiled via GCC was generating Thumb code by default. When
      these two object code types were being linked by the system linker, all was
      fine, because the system linker knows how to jump and call from one
      instruction set to the other.
      
      The first problem was with GHCi's object code loader which did not know
      about Thumb vs Arm. When loading an object file `StgCRun` would jump
      into the loaded object which could change the mode causing a crash after
      it returned. This was fixed by forcing all C code to generate Arm
      instructions by passing `-marm` to GCC.
      
      The second problem was the `mkJumpToAddr` function which was generating
      Thumb instructions. Changing that to generate Arm instructions instead
      results in a working GHCi on Arm.
      
      Test Plan: validate on x86_64 and arm
      
      Reviewers: bgamari, austin, hvr
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1323
      
      GHC Trac Issues: #10375
      933adc0f
  9. 03 Oct, 2015 1 commit
  10. 20 Aug, 2015 1 commit
  11. 04 Jul, 2015 1 commit
    • thomie's avatar
      Replace usages of `-w` by `-fno-warn`s · 69beef56
      thomie authored
      And remove unused imports and language pragmas.
      
      I checked that the minimum Happy and Alex version requirements, as
      listed in aclocal.m4, don't have to change. Before building ghc, I ran:
        - cabal install happy==1.19.4 --with-ghc=ghc-7.8.4
        - cabal install alex==3.1.0 --with-ghc=ghc-7.6.3
      
      Differential Revision: https://phabricator.haskell.org/D1032
      69beef56
  12. 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
  13. 20 Jun, 2015 1 commit
  14. 05 May, 2015 1 commit
  15. 04 May, 2015 1 commit
  16. 21 Apr, 2015 1 commit
  17. 14 Apr, 2015 1 commit
    • Austin Seipp's avatar
      Fix autoconf's check for create_timer() · edc059a4
      Austin Seipp authored
      GHC build system have custom autoconf check for `create_timer()`
      function from librt. Check description says that it checks for
      `CLOCK_REALTIME` timer, but checking code also checks for
      `CLOCK_PROCESS_CPUTIME_ID` timer, which is not commonly present (for
      example, FreeBSD doesn't have it). This makes whole check fail despite
      the fact that FreeBSD have `create_timer()` call and supports
      `CLOCK_REALTIME`. As a consequence, GHC RTS falls back to using SIGALRM
      for its timing machinery. Not only it's very ancient codepath, it also
      break some FFI bindings to C code that isn't prepared for syscall
      interruption caused by SIGALRM delivery.
      
      Grepping through ghc source code reveals that `USE_TIMER_CREATE`
      defininition in the config.h doesn't imply having
      `CLOCK_PROCESS_CPUTIME_ID`. The only place where
      `CLOCK_PROCESS_CPUTIME_ID` is used is rts/posix/GetTime.c and this code
      handles the absence of `CLOCK_PROCESS_CPUTIME_ID` gracefully.
      
      This patch makes autoconf checking code to check only for
      `timer_create(CLOCK_REALTIME, ...)` and fixes check description.
      
      Reviewed By: austin
      
      Differential Revision: https://phabricator.haskell.org/D831
      edc059a4
  18. 10 Apr, 2015 1 commit
  19. 05 Apr, 2015 1 commit
  20. 26 Mar, 2015 1 commit
    • Herbert Valerio Riedel's avatar
      Fix Git-commit-id detection for RELEASE=YES · 5aa57d01
      Herbert Valerio Riedel authored
      By mistake, the Git-commit-id detection was only enabled for
      `RELEASE=NO` (since the date-based GHC version computation is
      only active in that case). With this commit the commit-id
      detection is active regardless of the `RELEASE`-setting.
      
      This is a follow-up to 73e5e2f8
      5aa57d01
  21. 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
  22. 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
  23. 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
  24. 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
  25. 17 Feb, 2015 1 commit
  26. 13 Jan, 2015 1 commit
  27. 01 Dec, 2014 1 commit
  28. 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
  29. 19 Nov, 2014 1 commit
  30. 18 Nov, 2014 1 commit
  31. 05 Oct, 2014 2 commits
    • 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 #8790
      Signed-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
    • Herbert Valerio Riedel's avatar
      Implement `MIN_VERSION_GLASGOW_HASKELL()` macro · 3549c952
      Herbert Valerio Riedel authored
      This exposes the `cProjectPatchLevel{1,2}` value at the CPP level to
      allow it to be used in CPP conditionals. Concretely, GHC 7.10.2.20150623
      would result in
      
        #define __GLASGOW_HASKELL__             710
        #define __GLASGOW_HASKELL_PATCHLEVEL1__ 2
        #define __GLASGOW_HASKELL_PATCHLEVEL2__ 20150623
      
      while GHC 7.10.3 results in
      
        #define __GLASGOW_HASKELL__             710
        #define __GLASGOW_HASKELL_PATCHLEVEL1__ 3
      
      and finally GHC 7.9.20141009 results in
      
        #define __GLASGOW_HASKELL__             709
        #define __GLASGOW_HASKELL_PATCHLEVEL1__ 20141009
      
      As it's error-prone to properly express CPP conditionals for testing GHC
      multi-component versions, a new macro `MIN_VERSION_GLASGOW_HASKELL()` is
      provided (also via the new CPP include file `ghcversion.h`)
      
      Finally, in order to make it easier to define the new CPP macro
      `MIN_VERSION_GLASGOW_HASKELL()`, a new default-included
      `include/ghcversion.h` is used for the new CPP definitions.
      
      Reviewed By: ekmett, austin, #ghc
      
      Differential Revision: https://phabricator.haskell.org/D66
      3549c952
  32. 16 Sep, 2014 1 commit
    • rwbarton's avatar
      Find the target gcc when cross-compiling · cfd8c7dd
      rwbarton authored
      Summary:
      "./configure --target=TARGET" was broken; it would use the host gcc.
      (So you had to explicitly specify "--with-gcc=TARGET-gcc" also,
      as a workaround.)
      
      This was broken by commit fc4856f9
      for #8148. A comment claimed that FP_ARG_WITH_PATH_GNU_PROG_OPTIONAL
      was the same as FP_ARG_WITH_PATH_GNU_PROG except for not raising
      an error when the program isn't found; but that wasn't true --
      the former didn't prepend the target name when cross-compiling.
      
      We actually need three versions of FP_ARG_WITH_PATH_GNU_PROG since
      the LLVM tools are usually not prefixed with the target name even
      when cross-compiling. So I generalized the logic in a single macro.
      
      Test Plan:
      Built with "./configure --target=i386-unknown-linux"
      and BuildFlavour=quick, successfully
      
      Reviewers: ezyang, austin
      
      Reviewed By: ezyang, austin
      
      Subscribers: simonmar, ezyang, carter
      
      Differential Revision: https://phabricator.haskell.org/D204
      cfd8c7dd
  33. 09 Sep, 2014 1 commit
    • Austin Seipp's avatar
      Make Applicative a superclass of Monad · d94de872
      Austin Seipp authored
      
      
      Summary:
      This includes pretty much all the changes needed to make `Applicative`
      a superclass of `Monad` finally. There's mostly reshuffling in the
      interests of avoid orphans and boot files, but luckily we can resolve
      all of them, pretty much. The only catch was that
      Alternative/MonadPlus also had to go into Prelude to avoid this.
      
      As a result, we must update the hsc2hs and haddock submodules.
      Signed-off-by: default avatarAustin Seipp <austin@well-typed.com>
      
      Test Plan: Build things, they might not explode horribly.
      
      Reviewers: hvr, simonmar
      
      Subscribers: simonmar
      
      Differential Revision: https://phabricator.haskell.org/D13
      d94de872
  34. 01 Sep, 2014 1 commit
    • Austin Seipp's avatar
      Set llc and opt commands on all platforms · 918719b9
      Austin Seipp authored
      Summary:
      LLVM llc and opt commands should be set on all platforms, including
      Windows. If they're not, GHC tries to execute an unnamed executable,
      resulting in error messages such as:
      
          Error (figuring out LLVM version): : runInteractiveProcess: invalid argument (Invalid argument)
          <no location info>:
              Warning: Couldn't figure out LLVM version!
                       Make sure you have installed LLVM
      
      This regression was introduced in e6bfc596.
      
      Test Plan: Build GHC and test if --info shows sensible values of "LLVM llc command" and "LLVM opt command"
      
      Reviewers: austin, #ghc
      
      Reviewed By: austin, #ghc
      
      Subscribers: austin
      
      Projects: #ghc
      
      Differential Revision: https://phabricator.haskell.org/D190
      
      GHC Trac Issues: #7143
      918719b9
  35. 22 Aug, 2014 1 commit
    • pali.gabor@gmail.com's avatar
      Fix #9465. · 030549a1
      pali.gabor@gmail.com authored
      It turned out the sed(1) expressions are not fully portable.  So revist my
      earlier attempt for getting GHC_LDFLAGS in the configure script and rewrite
      it in Perl instead.
      030549a1
  36. 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
  37. 15 Aug, 2014 1 commit
  38. 28 Jul, 2014 1 commit