1. 22 Apr, 2014 4 commits
    • Colin Watson's avatar
      Add the powerpc64le architecture · 8586f600
      Colin Watson authored
      This is ArchUnknown for now, as it requires some porting work over and
      above powerpc64 due to such things as the different function calling
      sequence in the ELFv2 ABI.  For now, an unregisterised port is better
      than nothing.
      Signed-off-by: default avatarColin Watson <cjwatson@debian.org>
      Signed-off-by: default avatarAustin Seipp <austin@well-typed.com>
      8586f600
    • Colin Watson's avatar
      Be less untruthful about the prototypes of external functions · 5a31f231
      Colin Watson authored
      GHC's generated C code uses dummy prototypes for foreign imports.  At the
      moment these all claim to be (void), i.e. functions of zero arguments.  On
      most platforms this doesn't matter very much: calls to these functions put
      the parameters in the usual places anyway, and (with the exception of
      varargs) things just work.
      
      However, the ELFv2 ABI on ppc64 optimises stack allocation
      (http://gcc.gnu.org/ml/gcc-patches/2013-11/msg01149.html): a call to a
      function that has a prototype, is not varargs, and receives all parameters
      in registers rather than on the stack does not require the caller to
      allocate an argument save area.  The incorrect prototypes cause GCC to
      believe that all functions declared this way can be called without an
      argument save area, but if the callee has sufficiently many arguments then
      it will expect that area to be present, and will thus corrupt the caller's
      stack.  This happens in particular with calls to runInteractiveProcess in
      libraries/process/cbits/runProcess.c.
      
      The simplest fix appears to be to declare these external functions with an
      unspecified argument list rather than a void argument list.  This is no
      worse for platforms that don't care either way, and allows a successful
      bootstrap of GHC 7.8 on little-endian Linux ppc64 (which uses the ELFv2
      ABI).
      
      Fixes #8965
      Signed-off-by: default avatarColin Watson <cjwatson@debian.org>
      Signed-off-by: default avatarAustin Seipp <austin@well-typed.com>
      5a31f231
    • Colin Watson's avatar
      ghc: initial AArch64 patches · c29bf984
      Colin Watson authored
      Signed-off-by: default avatarAustin Seipp <austin@well-typed.com>
      c29bf984
    • Austin Seipp's avatar
      ghc & docs: kill unused flags · a3831391
      Austin Seipp authored
      This removes the following, now defunct flags, which will not be
      recognized by GHC 7.10:
      
        -fwarn-lazy-unlifted-bindings
        -pgmm and -optm (used for the Mangler, long dead)
        -keep-raw-s-file & -keep-raw-s-files
        -monly[432]-reg-only
      Signed-off-by: default avatarAustin Seipp <austin@well-typed.com>
      a3831391
  2. 21 Apr, 2014 5 commits
  3. 20 Apr, 2014 4 commits
  4. 19 Apr, 2014 18 commits
  5. 18 Apr, 2014 2 commits
  6. 17 Apr, 2014 2 commits
  7. 16 Apr, 2014 1 commit
    • Herbert Valerio Riedel's avatar
      Update Cabal submodule to tip of v1.20 branch · 8992d526
      Herbert Valerio Riedel authored
      This corresponds to the RC of the soon-to-be Cabal 1.20 release
      
      One noteworthy change is the removal of the `--with-ranlib` flag
      requiring a small adaptation in the GHC build system.
      
      Moreover two new licences were added, MPL and BSD2.
      
      Due to https://github.com/haskell/cabal/issues/1622 Cabal-1.20 now
      allows to strip libraries as well, this doesn't work well with
      `ghc-cabal copy` being fed a `":"` strip-command argument which was
      simply ignored in the past. The current code tries to retain this
      semantics as backward compat. However, this needs more investigation as
      I'm not sure if/why the `test_bindist` step doesn't want the libraries
      to be stripped on installation.
      Signed-off-by: Herbert Valerio Riedel's avatarHerbert Valerio Riedel <hvr@gnu.org>
      8992d526
  8. 15 Apr, 2014 1 commit
  9. 14 Apr, 2014 3 commits