1. 05 Oct, 2014 1 commit
    • 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
      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
  2. 16 Sep, 2014 1 commit
    • rwbarton's avatar
      Find the target gcc when cross-compiling · cfd8c7dd
      rwbarton authored
      "./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
  3. 09 Sep, 2014 1 commit
    • Austin Seipp's avatar
      Make Applicative a superclass of Monad · d94de872
      Austin Seipp authored
      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
  4. 01 Sep, 2014 1 commit
    • Austin Seipp's avatar
      Set llc and opt commands on all platforms · 918719b9
      Austin Seipp authored
      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
  5. 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.
  6. 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
      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
  7. 15 Aug, 2014 1 commit
  8. 28 Jul, 2014 1 commit
  9. 21 Jul, 2014 1 commit
  10. 18 Jul, 2014 1 commit
  11. 14 Jul, 2014 1 commit
    • kgardas's avatar
      add support for x86_64-solaris2 platform · 6da60321
      kgardas authored
      this set of patches adds support for x86_64-solaris2 platform
      Solaris is multi-lib platform which means it provides 32bit user-land together
      with 32bit and 64bit libraries. The 32bit libraries are located in <somewhere>/lib
      directories while 64bit libraries are located in <somewhere>/lib/64 directories.
      This is why GHCi required the fix since otherwise it'll attempt to load
      /usr/lib/libgmp.so which is 32bit library into 64bit binary process space (GHCi).
      This of course fails with wrong ELFCLASS32 error message.
      Another issue was that by default GNU C distributed with Solaris compiles
      into 32bit binary. We need to enforce compilation to 64bit binary
      by adding appropriate -m64 option.
      Test Plan: already built on x86_64-solaris2
      Reviewers: austin
      Reviewed By: austin
      Subscribers: phaskell, simonmar, relrod, carter
      Differential Revision: https://phabricator.haskell.org/D68
  12. 04 Jul, 2014 1 commit
  13. 02 Jul, 2014 1 commit
  14. 03 May, 2014 1 commit
  15. 22 Apr, 2014 2 commits
  16. 28 Mar, 2014 1 commit
  17. 27 Mar, 2014 2 commits
  18. 19 Feb, 2014 1 commit
  19. 17 Jan, 2014 2 commits
  20. 15 Oct, 2013 1 commit
  21. 18 Sep, 2013 2 commits
    • Jan Stolarek's avatar
      Restore old names of comparison primops · 53948f91
      Jan Stolarek authored
      In 6579a6c7 we removed existing comparison primops and introduced new ones
      returning Int# instead of Bool. This commit (and associated commits in
      array, base, dph, ghc-prim, integer-gmp, integer-simple, primitive, testsuite and
      template-haskell) restores old names of primops. This allows us to keep
      our API cleaner at the price of not having backwards compatibility.
      This patch also temporalily disables fix for #8317 (optimization of
      tagToEnum# at Core level). We need to fix #8326 first, otherwise
      our primops code will be very slow.
    • Jan Stolarek's avatar
      Limit upper versions of Alex and Happy · b6bc3263
      Jan Stolarek authored
      This is temporary until new bool primops have been pushed.
  22. 04 Sep, 2013 1 commit
  23. 28 Aug, 2013 1 commit
  24. 24 Aug, 2013 2 commits
  25. 14 Aug, 2013 1 commit
  26. 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.
  27. 20 Jun, 2013 1 commit
  28. 17 Jun, 2013 1 commit
    • thoughtpolice's avatar
      Detect linker information at runtime. Fixes Trac #6063 · 71a194d8
      thoughtpolice authored
      Previously, we did ./configure time checks to see if 'GNU ld' supported
      certain options. If it does, we bake those options into the link step.
      See Trac #5240.
      Unfortunately, the linker we use at runtime can change for several
      reasons. One is that the user specifies -pgml 'foo'. The other is if
      /usr/bin/ld or whatnot changes from when GHC was built.  Those options
      mentioned earlier are specific to GNU ld, but many systems support GNU
      gold too. This is Trac #6063.
      So we need to check at runtime what linker we're using. This is actually
      a little bit complicated because we normally use the C compiler as our
      linker. Windows and OS X are also special here.
      Finally, this patch also unconditionally gives '--hash-size=31' and
      '--reduce-memory-overheads' to the system linker if it's GNU ld. These
      options have been supported for 8+ years from what I can see, and there
      are probably a lot of other reasons why GHC would not work with such an
      ancient binutils, all things considered.
      See Note [Run-time linker info] in SysTools for details. There are
      plenty of comments as well in the surrounding code.
      Signed-off-by: thoughtpolice's avatarAustin Seipp <aseipp@pobox.com>
  29. 11 Jun, 2013 1 commit
  30. 07 Jun, 2013 1 commit
  31. 30 May, 2013 1 commit
  32. 20 May, 2013 1 commit
  33. 19 May, 2013 1 commit
  34. 24 Mar, 2013 1 commit
  35. 18 Mar, 2013 1 commit