1. 17 Aug, 2014 3 commits
    • 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
    • Herbert Valerio Riedel's avatar
      Remove obsolete `digitsTyConKey :: Unique` · 96d04186
      Herbert Valerio Riedel authored
      This became dead with 1e87c0a6
      and was probably just missed.
      
      I plan to re-use the freed up `mkPreludeTyConUnique 23` slot soon
      for a new `bigNatTyConKey` (as part of the #9281 effort)
      96d04186
    • Herbert Valerio Riedel's avatar
      Workaround GCC `__ctzdi2` intrinsic linker errors · 6375934b
      Herbert Valerio Riedel authored
      On Linux/i386 the 64bit `__builtin_ctzll()` instrinsic doesn't get
      inlined by GCC but rather a short `__ctzdi2` runtime function is
      inserted when needed into compiled object files.
      
      This causes failures for the four test-cases
      
        TEST="T8639_api T8628 dynCompileExpr T5313"
      
      with error messages of the kind
      
        dynCompileExpr: .../libraries/ghc-prim/dist-install/build/libHSghcpr_BE58KUgBe9ELCsPXiJ1Q2r.a: unknown symbol `__ctzdi2'
        dynCompileExpr: dynCompileExpr: unable to load package `ghc-prim'
      
      This workaround forces GCC on 32bit x86 to to express `hs_ctz64` in
      terms of the 32bit `__builtin_ctz()` (this is no loss, as there's no
      64bit BSF instruction on i686 anyway) and thus avoid the problematic
      out-of-line runtime function.
      
      Note: `__builtin_ctzll()` is used since
            e0c1767d (re #9340)
      6375934b
  2. 16 Aug, 2014 3 commits
    • Gabor Greif's avatar
      Revert "Fix typos 'resizze'" · 53cc943a
      Gabor Greif authored
      this is z-encoding (as hvr tells me)
      
      This reverts commit 425d5178.
      53cc943a
    • Gabor Greif's avatar
      Fix typos 'resizze' · 425d5178
      Gabor Greif authored
      425d5178
    • Herbert Valerio Riedel's avatar
      Implement {resize,shrink}MutableByteArray# primops · 246436f1
      Herbert Valerio Riedel authored
      The two new primops with the type-signatures
      
        resizeMutableByteArray# :: MutableByteArray# s -> Int#
                                -> State# s -> (# State# s, MutableByteArray# s #)
      
        shrinkMutableByteArray# :: MutableByteArray# s -> Int#
                                -> State# s -> State# s
      
      allow to resize MutableByteArray#s in-place (when possible), and are useful
      for algorithms where memory is temporarily over-allocated. The motivating
      use-case is for implementing integer backends, where the final target size of
      the result is either N or N+1, and only known after the operation has been
      performed.
      
      A future commit will implement a stateful variant of the
      `sizeofMutableByteArray#` operation (see #9447 for details), since now the
      size of a `MutableByteArray#` may change over its lifetime (i.e before
      it gets frozen or GCed).
      
      Test Plan: ./validate --slow
      
      Reviewers: ezyang, austin, simonmar
      
      Reviewed By: austin, simonmar
      
      Differential Revision: https://phabricator.haskell.org/D133
      246436f1
  3. 15 Aug, 2014 2 commits
    • pali.gabor@gmail.com's avatar
    • Ben Gamari's avatar
      LlvmMangler: Be more selective when mangling object types · 5895f2b8
      Ben Gamari authored
      Summary:
      We previously did a wholesale replace of `%function` to `%object` to
      mangle object `.type` annotations. This is bad as it can end up
      replacing appearances of `"%function"` in the user's code. We now look
      for a proper `.type` keyword before performing the replacement.
      
      Thanks to @rwbarton for pointing out the bug.
      
      Test Plan:
      Previously,
      
          $ echo 'main = putStrLn "@function"' > test.hs
          $ ghc -fllvm test.hs
          $ ./test
          @object
      
      Now,
          $ echo 'main = putStrLn "@function"' > test.hs
          $ ghc -fllvm test.hs
          $ ./test
          @function
      
      Reviewers: rwbarton, austin
      
      Reviewed By: rwbarton, austin
      
      Subscribers: phaskell, simonmar, relrod, ezyang, carter
      
      Differential Revision: https://phabricator.haskell.org/D150
      
      GHC Trac Issues: #9439
      5895f2b8
  4. 14 Aug, 2014 2 commits
    • Herbert Valerio Riedel's avatar
      Declare `ghc-head` to be haddock's upstream branch · 03a8003e
      Herbert Valerio Riedel authored
      This will affect commands such as
      
         git submodule update --remote utils/haddock
      
      to use `ghc-head` instead of the default `master` branch
      03a8003e
    • Herbert Valerio Riedel's avatar
      Implement new CLZ and CTZ primops (re #9340) · e0c1767d
      Herbert Valerio Riedel authored
      This implements the new primops
      
        clz#, clz32#, clz64#,
        ctz#, ctz32#, ctz64#
      
      which provide efficient implementations of the popular
      count-leading-zero and count-trailing-zero respectively
      (see testcase for a pure Haskell reference implementation).
      
      On x86, NCG as well as LLVM generates code based on the BSF/BSR
      instructions (which need extra logic to make the 0-case well-defined).
      
      Test Plan: validate and succesful tests on i686 and amd64
      
      Reviewers: rwbarton, simonmar, ezyang, austin
      
      Subscribers: simonmar, relrod, ezyang, carter
      
      Differential Revision: https://phabricator.haskell.org/D144
      
      GHC Trac Issues: #9340
      e0c1767d
  5. 13 Aug, 2014 3 commits
  6. 12 Aug, 2014 18 commits
  7. 11 Aug, 2014 4 commits
  8. 10 Aug, 2014 5 commits