September 2014 - ghc-tickets

[GHC] #8980: ghc-7.8.1 -O2 eats excessive amounts of RAM, highlighting-kate and pandoc-citeproc
by GHC 07 Oct '14

07 Oct '14

#8980: ghc-7.8.1 -O2 eats excessive amounts of RAM, highlighting-kate and pandoc- citeproc ------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- It's mostly a http://www.haskell.org/pipermail/ghc- devs/2014-March/004363.html rechecked on ghc-7.8.1: I attempted to leave original packages as-is. Steps to reproduce: {{{ $ cd /tmp/ $ wget -c http://code.haskell.org/~slyfox/selfcontained-eater- ghc-7.8-rc2.tar.gz $ tar -xzf selfcontained-eater-ghc-7.8-rc2.tar.gz $ cd selfcontained-eater-ghc-7.8-rc2 $ ./mk.sh ... [279 of 452] Compiling Text.Highlighting.Kate.Syntax.Asp ( highlighting- kate-0.5.6.1/Text/Highlighting/Kate/Syntax/Asp.hs, highlighting- kate-0.5.6.1/Text/Highlighting/Kate/Syntax/Asp.o ) stack overflow: use +RTS -K<size> to increase it }}} I did prepare this testcase for ghc-7.6.3 where it failed only on last 452 module. '''./mk.sh''' is a dumb script calling '''ghc -O2''' + cabal-generated bits. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8980> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #8852: 7.8.1 uses a lot of memory when compiling attoparsec programs using <|>
by GHC 07 Oct '14

07 Oct '14

#8852: 7.8.1 uses a lot of memory when compiling attoparsec programs using <|> -------------------------+------------------------------------------------- Reporter: | Owner: joelteon | Status: new Type: bug | Milestone: Priority: | Version: 7.8.1-rc2 normal | Operating System: Unknown/Multiple Component: | Type of failure: Compile-time performance bug Compiler | Test Case: Keywords: | Blocking: Architecture: | Unknown/Multiple | Difficulty: | Unknown | Blocked By: | Related Tickets: | -------------------------+------------------------------------------------- To reproduce, install a pre-`0.11.2.1` version of attoparsec. This bug was worked around in 0.11.2.1 by removing the `INLINE` on `plus` in attoparsec. With this test program: {{{#!haskell {-# LANGUAGE OverloadedStrings #-} import Control.Applicative import Data.Attoparsec.Text import Data.Text (Text) parser :: Parser Text parser = string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" <|> string "a" main :: IO () main = parseTest parser "a" }}} and using GHC 7.8.1.rc2: Compiling using `-O2`, GHC tops out at ~1GB of RAM and takes 25s. Using `-O0`, GHC takes 0.47s and uses <150MB of RAM. Compare this with GHC 7.6.3: Compiling using `-O2`, GHC uses <150MB and takes 3.7s. Memory usage is similar with `-O0` although compile time goes down to 0.36s. An extreme version of this bug can be found in the `thyme` package here: https://github.com/liyang/thyme/blob/master/src/Data/Thyme/Format.hs#L589-L…. Compiling that module with an unfixed attoparsec makes GHC use all available memory and stall out, forcing kill -9. Replacing the function body with `undefined` makes the package compile as expected. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8852> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #8790: rts: unrust 'libbfd' debug symbols parser
by GHC 05 Oct '14

05 Oct '14

#8790: rts: unrust 'libbfd' debug symbols parser ------------------------------------+------------------------------------- Reporter: slyfox | 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: | ------------------------------------+------------------------------------- For quite a long while you might have seen such ./configure output: {{{ checking bfd.h usability... yes checking bfd.h presence... yes checking for bfd.h... yes ... checking for bfd_uncompress_section_contents in -lbfd... no }}} which means very interesting debug bit in rts (+RTS -Di) is disabled. It's because most of functions in bfd.h are actually macros, thus test fails: config.log: {{{ configure:9545: checking for bfd_uncompress_section_contents in -lbfd configure:9570: x86_64-pc-linux-gnu-gcc -o conftest -march=corei7-avx -mtune=corei7-avx -O2 -pipe -fdiagnostics-show-option -frecord-gcc- switches -ggdb3 -march=corei7-avx -march=corei7-avx -m tune=corei7-avx -mtune=corei7-avx -ggdb3 -fno-stack-protector -Wa,-- noexecstack -Wa,--noexecstack -fno-stack-protector -Wl,-O1 -Wl,--as- needed -Wl,--hash-style=gnu -Wl,--hash-size=31 -Wl,--r educe-memory-overheads conftest.c -lbfd -liberty >&5 /tmp/portage/dev-lang/ghc-7.6.3-r1/temp/ccCEvDZ7.o: In function `main': /tmp/portage/dev-lang/ghc-7.6.3-r1/work/ghc-7.6.3/conftest.c:99: undefined reference to `bfd_uncompress_section_contents' }}} We don't use that function anyways, thus i've picked '''bfd_init'''. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8790> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #9623: Use Data.List.dropWhileEnd
by GHC 03 Oct '14

03 Oct '14

#9623: Use Data.List.dropWhileEnd -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: hour) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The GHC tree has many instances of `reverse . dropWhile ... . reverse`. As well as being harder to read and work with (searching for those forms led me to discover #9616) this approach is less efficient than `dropWhileEnd`. I think I've found all the places this is used, and I'll submit a patch to fix all the instances except for tests and nofib. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9623> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

[GHC] #9616: Incorrect numbers from HpcMarkup.markup_plugin
by GHC 02 Oct '14

02 Oct '14

#9616: Incorrect numbers from HpcMarkup.markup_plugin -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Code Coverage | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: Incorrect hour) | result at runtime Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- `showBigNum` in the `openTick` function accidentally puts 0s in the wrong place when formatting large numbers. 12345 will be formatted as 120,345 instead of 012,345. The correct answer is probably to add some locale- specific numeric formatting stuff somewhere, but until then, I'll just fix this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9616> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9546: filterM is not a good consumer for list fusion
by GHC 01 Oct '14

01 Oct '14

#9546: filterM is not a good consumer for list fusion -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Runtime Blocked By: | performance bug Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- This one shouldn't cause any wonkiness; it just updates `filterM` to fuse is much the same way `mapM` does. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9546> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #9502: mapAccumL does not participate in foldr/build fusion
by GHC 01 Oct '14

01 Oct '14

#9502: mapAccumL does not participate in foldr/build fusion -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Runtime Blocked By: | performance bug Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- This can probably be fixed in much the same way as `scanl`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9502> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9434: GHC.List.reverse does not fuse
by GHC 01 Oct '14

01 Oct '14

#9434: GHC.List.reverse does not fuse -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: Runtime hour) | performance bug Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- As Edward Kmett speculated could be the case a couple months ago, Joachim Breitner's call arity analysis makes the Prelude version of `reverse` better than GHC's version. It's less clear to me whether it's beneficial to wrap it in `build`, but I think the answer is ''probably'' yes, based on the fact that doing so turns `foldr c n $ reverse xs` into `foldl (flip c) n xs`. {{{#!hs {-# INLINE reverse #-} reverse :: [a] -> [a] reverse xs = build $ \c n -> foldl (\a x -> x `c` a) n xs }}} This simplifies to {{{#!hs Rec { poly_go_r2uL poly_go_r2uL = \ @ a_a2nn ds_a2xO eta_Xh -> case ds_a2xO of _ { [] -> eta_Xh; : y_a2xT ys_a2xU -> poly_go_r2uL ys_a2xU (: y_a2xT eta_Xh) } end Rec } reverse reverse = \ @ a_a2nn eta_B1 -> poly_go_r2uL eta_B1 ([]) }}} which looks about the same as the current version in GHC.List. Behold the beauty when it is applied to an unfold (with a fusion-friendly version of `unfoldr`): {{{#!hs testReverseUnfoldr f q0 = reverse (unfoldr f q0) }}} simplifies to {{{#!hs testReverseUnfoldr testReverseUnfoldr = \ @ a_a2w3 @ b_a2w4 f_a2mn q0_a2mo -> letrec { go_a1QX go_a1QX = \ b1_a1Hy eta_B1 -> case f_a2mn b1_a1Hy of _ { Nothing -> eta_B1; Just ds_d2d8 -> case ds_d2d8 of _ { (a1_a1Hz, new_b_a1HA) -> go_a1QX new_b_a1HA (: a1_a1Hz eta_B1) } }; } in go_a1QX q0_a2mo ([]) }}} This looks exactly like a hand-written `unfoldl`! -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9434> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #9653: globalRegMaybe not defined for qnx-nto-arm
by GHC 30 Sep '14

30 Sep '14

#9653: globalRegMaybe not defined for qnx-nto-arm -------------------------------------+------------------------------------- Reporter: singpolyma | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: QNX Architecture: arm | Type of failure: Building Difficulty: Unknown | GHC failed Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I'm having trouble figuring out what I do to add support. I'm getting this when building my qnx-nto-arm cross-compiler on head: ghc-stage1: panic! (the 'impossible' happened) (GHC version 7.9.20140929 for arm-unknown-nto-qnx): globalRegMaybe not defined for this platform -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9653> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

Re: [GHC] #781: GHCi on x86_64, cannot link to static data in shared libs
by GHC 30 Sep '14

30 Sep '14

#781: GHCi on x86_64, cannot link to static data in shared libs -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 6.5 Resolution: | Keywords: getEnvironment Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Difficulty: Unknown Test Case: | Blocked By: getEnvironment01 | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by simonmar): * status: closed => new * resolution: fixed => Comment: Works in 7.8.3 because we're using dynamic linking. The bug still remains in the RTS linker. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/781#comment:30> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0