June 2014 - ghc-tickets

Re: [GHC] #3032: would be nice if -fno-code and --make worked together
by GHC 26 Jun '14

26 Jun '14

#3032: would be nice if -fno-code and --make worked together -------------------------------------+------------------------------------ Reporter: duncan | Owner: Type: feature request | Status: closed Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by ezyang): * status: new => closed * failure: => None/Unknown * resolution: => fixed Comment: I think this works now, modulo Cabal support: {{{ ezyang@sabre:~/Dev/labs$ cabal unpack parsec cd Unpacking to parsec-3.1.5/ ezyang@sabre:~/Dev/labs$ cd parsec-3.1.5/ ezyang@sabre:~/Dev/labs/parsec-3.1.5$ cabal configure --ghc-option=-fno- code Resolving dependencies... Configuring parsec-3.1.5... ezyang@sabre:~/Dev/labs/parsec-3.1.5$ time cabal build Building parsec-3.1.5... Preprocessing library parsec-3.1.5... [ 1 of 25] Compiling Text.Parsec.Pos ( Text/Parsec/Pos.hs, nothing ) [ 2 of 25] Compiling Text.Parsec.Error ( Text/Parsec/Error.hs, nothing ) [ 3 of 25] Compiling Text.ParserCombinators.Parsec.Error ( Text/ParserCombinators/Parsec/Error.hs, nothing ) [ 4 of 25] Compiling Text.ParserCombinators.Parsec.Pos ( Text/ParserCombinators/Parsec/Pos.hs, nothing ) [ 5 of 25] Compiling Text.Parsec.Prim ( Text/Parsec/Prim.hs, nothing ) [ 6 of 25] Compiling Text.Parsec.Char ( Text/Parsec/Char.hs, nothing ) [ 7 of 25] Compiling Text.Parsec.Combinator ( Text/Parsec/Combinator.hs, nothing ) [ 8 of 25] Compiling Text.ParserCombinators.Parsec.Combinator ( Text/ParserCombinators/Parsec/Combinator.hs, nothing ) [ 9 of 25] Compiling Text.Parsec.String ( Text/Parsec/String.hs, nothing ) [10 of 25] Compiling Text.ParserCombinators.Parsec.Char ( Text/ParserCombinators/Parsec/Char.hs, nothing ) [11 of 25] Compiling Text.Parsec.ByteString ( Text/Parsec/ByteString.hs, nothing ) [12 of 25] Compiling Text.Parsec.ByteString.Lazy ( Text/Parsec/ByteString/Lazy.hs, nothing ) [13 of 25] Compiling Text.Parsec.Text ( Text/Parsec/Text.hs, nothing ) [14 of 25] Compiling Text.Parsec.Text.Lazy ( Text/Parsec/Text/Lazy.hs, nothing ) [15 of 25] Compiling Text.Parsec.Token ( Text/Parsec/Token.hs, nothing ) [16 of 25] Compiling Text.ParserCombinators.Parsec.Token ( Text/ParserCombinators/Parsec/Token.hs, nothing ) [17 of 25] Compiling Text.Parsec.Expr ( Text/Parsec/Expr.hs, nothing ) [18 of 25] Compiling Text.ParserCombinators.Parsec.Prim ( Text/ParserCombinators/Parsec/Prim.hs, nothing ) [19 of 25] Compiling Text.ParserCombinators.Parsec ( Text/ParserCombinators/Parsec.hs, nothing ) [20 of 25] Compiling Text.ParserCombinators.Parsec.Expr ( Text/ParserCombinators/Parsec/Expr.hs, nothing ) [21 of 25] Compiling Text.Parsec ( Text/Parsec.hs, nothing ) [22 of 25] Compiling Text.Parsec.Language ( Text/Parsec/Language.hs, nothing ) [23 of 25] Compiling Text.ParserCombinators.Parsec.Language ( Text/ParserCombinators/Parsec/Language.hs, nothing ) [24 of 25] Compiling Text.Parsec.Perm ( Text/Parsec/Perm.hs, nothing ) [25 of 25] Compiling Text.ParserCombinators.Parsec.Perm ( Text/ParserCombinators/Parsec/Perm.hs, nothing ) /usr/bin/ar: dist/build/Text/Parsec.o: No such file or directory real 0m2.110s user 0m1.682s sys 0m0.281s }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3032#comment:9> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9231: 7.8 regression in Read instance of Data.Fixed.Pico
by GHC 26 Jun '14

26 Jun '14

#9231: 7.8 regression in Read instance of Data.Fixed.Pico ------------------------------------+------------------------------------- Reporter: leonbaum2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- If I run the following with ghc-7.8.2, the runtime system eats up all of my memory and doesn't produce a result: read "1" :: Data.Fixed.Pico -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9231> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 12

[GHC] #9239: Program loops in syscall retries cancelled by rt_sigreturn signal
by GHC 25 Jun '14

25 Jun '14

#9239: Program loops in syscall retries cancelled by rt_sigreturn signal --------------------------+------------------------------------------------ Reporter: k-bx | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.8.2 Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: Incorrect result at runtime Architecture: | Test Case: Unknown/Multiple | Blocking: Difficulty: | Unknown | Blocked By: | Related Tickets: | --------------------------+------------------------------------------------ Sorry if this bug is not related to ghc, but it seems to me that it might be. Originally I reported it against hedis package, you can find description in it's bug tracker https://github.com/informatikr/hedis/issues/15 Short recap: one specific operation against redis database (zrangebyscoreLimit against big ZSET), program behaves differently. For me, most of the time it would hang, sometimes it succeeds, sometimes outputs "ConnectionLost" twice and dies. My environments are: Ubuntu 12.04/14.04, redis versions tested are 2.2 through 2.8 (latest in each even branch). Under GHC 7.6 and profiling enabled, strace would end up showing an infinite loop of these operations: {{{ --- SIGVTALRM {si_signo=SIGVTALRM, si_code=SI_TIMER, si_pid=0, si_uid=0, si_value=0} --- rt_sigreturn() = -1 EINTR (Interrupted system call) select(4, [3], [], NULL, NULL) = ? ERESTARTNOHAND (To be restarted if no handler) }}} Under 7.8.2 profiling enabled, it would also loop, but in few seconds it would hang, produring these last lines of output (plus result of Ctrl+C): {{{ select(4, [3], [], NULL, NULL) = ? ERESTARTNOHAND (To be restarted if no handler) --- SIGVTALRM {si_signo=SIGVTALRM, si_code=SI_TIMER, si_pid=0, si_uid=0, si_value=0} --- timer_settime(0, 0, {it_interval={0, 0}, it_value={0, 0}}, NULL) = 0 rt_sigreturn() = -1 EINTR (Interrupted system call) select(4, [3], [], NULL, NULL^CProcess 16483 detached <detached ...> }}} With profiling disabled on 7.8.2 it would sometimes hang same way as with profiling, but sometimes it would finish with outputting "ConnectionLost" errors (you can find links to full strace output in github hedis issue page linked above). Sorry again if it's not related to GHC, meanwhile I'll try to investigate further. Thank you. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9239> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8972: Investigate adding fast compare-and-swap Int type/primops
by GHC 24 Jun '14

24 Jun '14

#8972: Investigate adding fast compare-and-swap Int type/primops ------------------------------------+------------------------------------- Reporter: tibbe | Owner: tibbe Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I've received reports that using `IORef Int` and `atomicModifyIORef` to implement an atomic counter in the ekg package has become a bottleneck for some of its users. These users update the counter thousands of times per second, using multiple threads. I will investigate whether adding a dedicated atomic `Int` reference type will offer significant speed improvements. Such a type can also be used to implement cheaper locks (by using bits in the int to represent different lock states, such as reader/write locks.) Lets call this new type `AtomicIntRef` for now. This new type needs to support at least these functions: {{{#!haskell add :: AtomicIntRef -> Int -> IO Int set :: AtomicIntRef -> Int -> IO () get :: AtomicIntRef -> IO Int }}} `add` would be implemented using the `lock` and `xaddq` instructions. `set` and `get` are just simple loads and stores on x86, as these are atomic. We might also want to consider having other functions, such as a `cas`. Furthermore, there are subtleties with memory barriers that might motivate having barrier/barrier-less versions of some functions. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8972> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

Re: [GHC] #7200: template-haskell-2.7.0.0 fails to build with GHC 7.0.4 due to missing pragma
by GHC 24 Jun '14

24 Jun '14

#7200: template-haskell-2.7.0.0 fails to build with GHC 7.0.4 due to missing pragma -------------------------------------+------------------------------------ Reporter: tibbe | Owner: duncan Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Template Haskell | Version: 7.0.4 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by tibbe): * status: new => closed * resolution: => wontfix Comment: 7.0.4 is quite old now and we have a way to make sure template-haskell doesn't get upgraded by cabal. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7200#comment:12> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9232: Stats file has wrong numbers
by GHC 24 Jun '14

24 Jun '14

#9232: Stats file has wrong numbers ------------------------------------+----------------------------- Reporter: augustss | Owner: simonmar Type: bug | Status: new Priority: low | Milestone: Component: Runtime System | Version: 7.8.2 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: Other Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+----------------------------- The summary numbers in the file generated with the -S flag cannot be right. Here's an example: {{{ 1,943,795,468 bytes allocated in the heap 17,587,189,232 bytes copied during GC }}} The corresponding numbers with ghc 7.2 are {{{ 193,859,474,520 bytes allocated in the heap 17,766,908,288 bytes copied during GC }}} While it's theoretically possible that allocation has improved that much, I don't believe it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9232> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #7483: Broken Read instance for Data.Fixed ("no parse" in legitimate cases).
by GHC 24 Jun '14

24 Jun '14

#7483: Broken Read instance for Data.Fixed ("no parse" in legitimate cases). ------------------------------------------------+-------------------------- Reporter: navaati | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 7.6.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result at runtime | Unknown/Multiple Test Case: readFixed001 | Difficulty: Blocking: | Unknown | Blocked By: | Related Tickets: #4502 ------------------------------------------------+-------------------------- Comment (by Herbert Valerio Riedel <hvr@…>): In [changeset:"c1035d51edaac2f388a0630e2ad25391e7e3c1ab/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="c1035d51edaac2f388a0630e2ad25391e7e3c1ab" Fix regression in Data.Fixed Read instance (re #9231) `convertFixed` operates under the wrong assumption that `Data.Fixed.resolution` returns a base-10 exponent `e`, whereas it actually returns the power-of-10 value `10^e`. So while the code (that was introduced in 5f19f951d8 / #7483) happens to compute a correct result by coincidence, it allocates huge integer values in the process (i.e. `10^(10^e)`) which cause long computations which eventually result in out-of-memory conditions for `e`-values beyond `Data.Fixed.Milli`. A proper long-term fix would probably be to extend the `HasResolution` type-class to have a 2nd method providing the `e` value. Signed-off-by: Herbert Valerio Riedel <hvr(a)gnu.org> Differential Revision: https://phabricator.haskell.org/D25 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7483#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #1721: Make GHCi print the entire result of an interactive 'bind' statement
by GHC 24 Jun '14

24 Jun '14

#1721: Make GHCi print the entire result of an interactive 'bind' statement -------------------------------------+------------------------------------ Reporter: simonpj | Owner: Type: feature request | Status: closed Priority: lowest | Milestone: 7.6.2 Component: Compiler | Version: 6.6.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by Artyom.Kazak): * status: new => closed * resolution: => fixed Comment: The current choice (GHCi 7.8.2) is to print nothing even when there's only one bound variable, which is consistent and avoids unpleasant surprises (as the one Ryan Ingram stumbled upon – see 1st comment). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1721#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9047: Testsuite fails on OS X Mavericks
by GHC 23 Jun '14

23 Jun '14

#9047: Testsuite fails on OS X Mavericks ------------------------------------+--------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.8.2 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+--------------------------------- Perhaps this is already well-known, but the testsuite utterly fails on Mavericks. Most tests fail because of extra output from clang. Here is a representative: {{{ Actual stderr output differs from expected: --- ./tcfail188.stderr 2014-02-07 15:28:16.000000000 -0500 +++ ./tcfail188.comp.stderr 2014-04-28 14:37:03.000000000 -0400 @@ -0,0 +1,3 @@ +clang: warning: argument unused during compilation: '-fno-stack- protector' +clang: warning: argument unused during compilation: '-D TABLES_NEXT_TO_CODE' +clang: warning: argument unused during compilation: '-I .' *** unexpected failure for tcfail188(normal) }}} Is this a local setting problem? Or is this something that can be fixed centrally? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9047> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9203: Perf regression in 7.8.2 relative to 7.6.3, possibly related to Typeable
by GHC 23 Jun '14

23 Jun '14

#9203: Perf regression in 7.8.2 relative to 7.6.3, possibly related to Typeable ------------------------------+-------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime performance bug Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ------------------------------+-------------------------------------------- {{{ $ git clone http://github.com/facebook/Haxl.git Cloning into 'Haxl'... remote: Counting objects: 77, done. remote: Compressing objects: 100% (65/65), done. remote: Total 77 (delta 17), reused 69 (delta 9) Unpacking objects: 100% (77/77), done. $ cd Haxl $ ghc-7.6.3 -O2 tests/Bench.hs -main-is Bench -o tests/Bench-76 [1 of 6] Compiling Haxl.Core.StateStore ( Haxl/Core/StateStore.hs, Haxl/Core/StateStore.o ) [2 of 6] Compiling Haxl.Core.Show1 ( Haxl/Core/Show1.hs, Haxl/Core/Show1.o ) [3 of 6] Compiling Haxl.Core.Util ( Haxl/Core/Util.hs, Haxl/Core/Util.o ) [4 of 6] Compiling Haxl.Core.Types ( Haxl/Core/Types.hs, Haxl/Core/Types.o ) [5 of 6] Compiling Haxl.Core.DataCache ( Haxl/Core/DataCache.hs, Haxl/Core/DataCache.o ) [6 of 6] Compiling Bench ( tests/Bench.hs, tests/Bench.o ) Linking tests/Bench-76 ... $ ./tests/Bench-76 500000 Just (Right 0) insert: 0.87s 500000 lookup: 0.24s $ ./tests/Bench-76 500000 Just (Right 0) insert: 0.87s 500000 lookup: 0.26s $ ghc-7.8.2 -O2 tests/Bench.hs -main-is Bench -o tests/Bench-78 [1 of 5] Compiling Haxl.Core.StateStore ( Haxl/Core/StateStore.hs, Haxl/Core/StateStore.o ) [2 of 5] Compiling Haxl.Core.Show1 ( Haxl/Core/Show1.hs, Haxl/Core/Show1.o ) [3 of 5] Compiling Haxl.Core.Types ( Haxl/Core/Types.hs, Haxl/Core/Types.o ) [4 of 5] Compiling Haxl.Core.DataCache ( Haxl/Core/DataCache.hs, Haxl/Core/DataCache.o ) [5 of 5] Compiling Bench ( tests/Bench.hs, tests/Bench.o ) Linking tests/Bench-78 ... $ ./tests/Bench-78 500000 Just (Right 0) insert: 1.09s 500000 lookup: 0.44s $ ./tests/Bench-78 500000 Just (Right 0) insert: 1.08s 500000 lookup: 0.44s }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9203> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13