May 2014 - ghc-tickets

[GHC] #8647: Reduce allocations in `integer-gmp`
by GHC 17 Nov '14

17 Nov '14

#8647: Reduce allocations in `integer-gmp` ------------------------------+-------------------------------------------- Reporter: hvr | Owner: Type: task | Status: new Priority: normal | Milestone: 7.8.1 Component: libraries | Version: 7.6.3 (other) | Operating System: Unknown/Multiple Keywords: | Type of failure: Runtime performance bug Architecture: x86_64 | Test Case: (amd64) | Blocking: Difficulty: Unknown | Blocked By: | Related Tickets: #8638 | ------------------------------+-------------------------------------------- I've added `printf(3)`s to `integer-gmp`s GMP allocation/reallocation functions, and noticed there to a significant amount of allocations going on. This is due to the fact that the CMM wrappers call `gmpz_init()` to initialize the result, and this already allocates a 1-limb `StgArray`. But the actual GMP operations perform a reallocate-call (which by contract also needs `memcpy` the untouched limb over to the newly allocated structure) based on the type of operation and the involved operands, causing the optimistically allocated 1-limb structure to become garbage right away w/o even being written to. I've been able to get rid of most such superfluous allocations by replacing {{{#!c ccall __gmpz_init(mp_result1 "ptr"); }}} by {{{#!c MP_INT__mp_alloc(mp_result1) = 0; MP_INT__mp_size(mp_result1) = 0; MP_INT__mp_d(mp_result1) = 0; // (1) }}} which is handled properly by all GMP operations we make use of currently. This elegantly lets the very first allocation be performed within the GMP operation (which has better knowledge with respect to how many limbs the result will require) I've got working proof-of-concept code, which reduces the allocations the big-num heavy `nofib` programs (I've omitted the benchmarks which had a 0% allocation change): {{{ -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- ... bernouilli -0.1% -5.2% 0.12 0.12 +0.0% kahan -0.1% -10.5% 0.17 0.17 +0.0% primetest -0.1% -12.8% 0.07 0.07 +0.0% rsa -0.1% -13.8% 0.02 0.02 +0.0% symalg -0.1% -2.3% 0.01 0.01 +0.0% ... -------------------------------------------------------------------------------- Min -0.1% -13.8% -3.1% -3.1% -6.5% Max -0.0% +0.4% +4.0% +4.0% +1.5% Geometric Mean -0.1% -0.5% +0.5% +0.4% -0.1% }}} `(1)` This should actually point to a proper static closure I didn't need this for the proof-of-concept ---- Another place which helps avoiding temporarily allocating 1-limb `StgArrays` which live only for the duration of GMP FFI calls are those caused by the `toBig`-casts, which I'm also experimenting by making use of GMP's big-int/small-int add/sub/mul primitives (the deltas shown above are actually measured on top of this optimization), here's what to expect from such an optimization by itself (i.e. w/o the realloc-optimization from above): {{{ bernouilli +0.1% -4.2% 0.12 0.12 +0.0% kahan +0.1% -12.6% 0.17 0.17 +0.0% power +0.1% -2.7% +2.2% +2.2% +0.0% rsa +0.1% -4.1% 0.02 0.02 +0.0% scs +0.1% -2.6% -1.6% -1.6% +0.0% }}} Thus, the `kahan` benchmark benefits from this optimization by -12.6%, and on top of that another -10.5% by also avoiding the GMP-reallocations. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8647> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 20

[GHC] #8664: libffi does not recognize AArch64 (ARM64)
by GHC 17 Nov '14

17 Nov '14

#8664: libffi does not recognize AArch64 (ARM64) -------------------------------------+------------------------------------- Reporter: kgardas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 7.7 Keywords: | Operating System: Linux Architecture: arm | Type of failure: Building GHC Difficulty: Easy (less than 1 | failed hour) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- Hello, bundled libffi-3.0.11's configure does not recognize aarch64/arm64 platform. This is easily solvable by replacing it with newer release. I tested 3.0.13 and it went well. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8664> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8671: Rebindable syntax creates bogus warning
by GHC 17 Nov '14

17 Nov '14

#8671: Rebindable syntax creates bogus warning -------------------------+------------------------------------------------- Reporter: | Owner: thomaseding | Status: new Type: bug | Milestone: Priority: | Version: 7.6.3 normal | Operating System: Windows Component: | Type of failure: Incorrect warning at Compiler | compile-time Keywords: | Test Case: Architecture: | Blocking: Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- {{{ {-# LANGUAGE RebindableSyntax #-} import Data.Void import Prelude ((.), ($), Int, id, Num(..)) (>>) :: (b -> c) -> (a -> b) -> (a -> c) (>>) = (.) return :: Void -> Void return = absurd run :: a -> (a -> b) -> b run x f = f x result :: Int result = run 8 $ do \n -> n * n id (+ 7) (* 2) }}} Compile with -Wall issues incorrect warnings. In fact the suggested fixes cause compile errors if implemented. {{{ Test.hs:22:5: Warning: A do-notation statement discarded a result of type Int. Suppress this warning by saying "_ <- \ n -> (*) n n", or by using the flag -fno-warn-unused-do-bind Test.hs:23:5: Warning: A do-notation statement discarded a result of type Int. Suppress this warning by saying "_ <- id", or by using the flag -fno-warn-unused-do-bind Test.hs:24:5: Warning: A do-notation statement discarded a result of type Int. Suppress this warning by saying "_ <- (( \ x_ -> (+) x_ 7))", or by using the flag -fno-warn-unused-do-bind }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8671> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8680: In STM: Variables only in left branch of orElse can invalidate the right branch transaction
by GHC 17 Nov '14

17 Nov '14

#8680: In STM: Variables only in left branch of orElse can invalidate the right branch transaction ------------------------------+-------------------------------------------- Reporter: jberryman | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime performance bug Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- I'm sorry if this is expected behavior; I'm still trying to wrap my head around this. I was surprised to learn that the right branch of an `orElse` can be invalidated by changes to the world only visible by the left branch. This might lead to starvation or performance issues for the use- case I was envisioning it for (e.g. several threads trying to take from one of a large set of TMVars in a randomized round-robin fashion). Here is a really bad example demonstrating current behavior: {{{ import Control.Concurrent import Control.Concurrent.STM import Control.Concurrent.STM.TSem import Control.Monad import System.IO import Debug.Trace main = do hSetBuffering stdout NoBuffering noMansLand <- replicateM 998 $ newTVarIO 0 t0 <- newTVarIO (1::Int) t999 <- newTVarIO (-1) let ts = t0:noMansLand++[t999] done <- atomically $ newTSem 0 forkIO $ atomically $ nestedOrElseMap done ts -- need enough time here for nestedOrElseMap thread above to move past t0 -- in this version, the modifications to t0 force nestedOrElseMap to be restarted forkIO (trace "starting vexing!" $ forever $ atomically $ (modifyTVar' t0 (+1) >> trace "vex" (return ()))) -- in this version nestedOrElseMap causes this transaction to be restarted and never makes progress: --forkIO (atomically (trace "starting vexing!" $ forever $ (modifyTVar' t0 (+1) >> trace "vex" (return ())))) atomically $ waitTSem done putStrLn "No livelock! Did the t0 counter get incremented?: " atomically (readTVar t0) >>= print -- another thread begins modifying head ts after we've moved to the right branch nestedOrElseMap :: TSem -> [TVar Int] -> STM () nestedOrElseMap done ts = trace "nestedOrElseMap starting" $ foldl1 orElse $ map transaction $ zip [(1::Int)..] ts where transaction (cnt,v) = do n <- traceShow cnt $ readTVar v if n < 0 then trace "@" (modifyTVar' v (subtract 1)) >> signalTSem done else retry }}} I can see it possibly being useful that both branches of an `orElse` see the same view of the variables they ''share'', but current behavior seems overzealous in restarting the whole transaction. Maybe this is an artifact of changes related to #7493? Or maybe it's obvious why this behavior has to be the way it is and its just not clicking for me. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8680> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8688: internal error: stg_ap_p_ret
by GHC 17 Nov '14

17 Nov '14

#8688: internal error: stg_ap_p_ret ------------------------------------+------------------------------------- Reporter: massysett | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- When in GHCi I get: <interactive>: internal error: stg_ap_p_ret (GHC version 7.6.3 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug There is probably something wrong with the FFI binding I am testing; under other circumstances I get a segfault. But since I was asked to report this, here I am. Let me know if I can provide anything else. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8688> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8716: improve AMP join warning
by GHC 17 Nov '14

17 Nov '14

#8716: improve AMP join warning ------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Any module that defines a top-level join gets this error: {{{ Local definition of ‛join’ clashes with a future Prelude name - this will become an error in GHC 7.10, under the Applicative-Monad Proposal. }}} This file triggers the warning, but it will keep on working when Prelude exports join: {{{ module M1 (M.join) where join x = x }}} This file will break when Prelude exports join, but there is no warning currently given. {{{ module M2 where import M1 (join) f x = join }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8716> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8730: Invalid Unicode Codepoints in Char
by GHC 16 Nov '14

16 Nov '14

#8730: Invalid Unicode Codepoints in Char ------------------------------------+------------------------------------- Reporter: mdmenzel | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.6.3 Keywords: unicode | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- The surrogate range in Unicode is supposed to (as of Unicode 2.0, 1996) be a range of invalid code points yet, Data.Char allows the use of values in this range (in fact, it even gives them their own GeneralCategory). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8730> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8756: Test case concurrent/should_run/T5611 fails on Mac
by GHC 16 Nov '14

16 Nov '14

#8756: Test case concurrent/should_run/T5611 fails on Mac ------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- On a fresh check out, test case concurrent/should_run/T5611 fails: {{{ Actual stderr output differs from expected: --- ./T5611.stderr 2014-02-06 22:27:48.000000000 -0500 +++ ./T5611.run.stderr 2014-02-08 22:00:06.000000000 -0500 @@ -1 +0,0 @@ -T5611: user error (Exception delivered successfully) Actual stdout output differs from expected: --- ./T5611.stdout 2014-02-06 22:27:48.000000000 -0500 +++ ./T5611.run.stdout 2014-02-08 22:00:06.000000000 -0500 @@ -1,2 +1,3 @@ child: Sleeping +child: Done waiting parent: Done throwing exception *** unexpected failure for T5611(normal) }}} I'm on Mac OS 10.8.5 with Xcode 4.6.1 (4H512). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8756> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #8798: Missing symbols with -fprof-auto-calls
by GHC 16 Nov '14

16 Nov '14

#8798: Missing symbols with -fprof-auto-calls ------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- To reproduce: in an empty environment (no packages installed), run {{{ cabal install --only-dependencies --enable-library-profiling --ghc-option =-fprof-auto-calls }}} for the attached test case. This will seem to work okay (no errors), but if you then do {{{ cabal configure --enable-executable-profiling --enable-library-profiling --ghc-option=-fprof-auto-calls }}} then {{{ cabal build }}} will fail with {{{ Building autocallsbug-0.1.0.0... Preprocessing executable 'autocallsbug' for autocallsbug-0.1.0.0... [1 of 1] Compiling Main ( Main.hs, dist/build/autocallsbug /autocallsbug-tmp/Main.p_o ) Linking dist/build/autocallsbug/autocallsbug ... Undefined symbols for architecture x86_64: "_attoparseczm0zi11zi1zi0_DataziAttoparsecziInternalziTypes_manyzimanyzuv_Cb_cc", referenced from: _sR1Q_info in libHSxml-conduit-1.1.0.9_p.a(Parse.p_o) _sR5p_info in libHSxml-conduit-1.1.0.9_p.a(Parse.p_o) ld: symbol(s) not found for architecture x86_64 collect2: ld returned 1 exit status }}} (Haven't yet confirmed with 7.8RC1 because that failed to build on my system; reported separately.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8798> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8701: Update libffi-tarballs to latest libffi
by GHC 14 Nov '14

14 Nov '14

#8701: Update libffi-tarballs to latest libffi -------------------------------------+------------------------------------- Reporter: lukexi | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler (FFI) | Version: 7.8.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Building GHC Difficulty: Easy (less than 1 | failed hour) | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+------------------------------------- libffi 3.0.14 contains fixes necessary for successful iOS (and probably ARM in general) cross-compilation. I've created a new archive that can be dropped in to replace the current libffi-tarballs archive here: https://github.com/ghc-ios/libffi- tarballs/blob/master/libffi-3.0.14.tar.gz?raw=true -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8701> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6