September 2014 - ghc-tickets

[GHC] #9549: deriveConstants fails on OpenBSD
by GHC 25 Oct '14

25 Oct '14

#9549: deriveConstants fails on OpenBSD -------------------------------------+------------------------------------- Reporter: roland | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.9 Keywords: | Operating System: OpenBSD Architecture: Unknown/Multiple | Type of failure: Building Difficulty: Unknown | GHC failed Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- On OpenBSD 5.5 compilation of current HEAD fails with: {{{ inplace/bin/deriveConstants --gen-header -o includes/dist- derivedconstants/header/DerivedConstants.h --tmpdir includes/dist- derivedconstants/header/ --gcc-program "/usr/bin/gcc" --gcc-flag -fno- stack-protector --gcc-flag -Iincludes --gcc-flag -Iincludes/dist --gcc- flag -Iincludes/dist-derivedconstants/header --gcc-flag -Iincludes/dist- ghcconstants/header --gcc-flag -Irts --gcc-flag -fcommon --nm-program "/usr/bin/nm" nm: unknown option -- P usage: nm [-aCegnoprsuw] [file ...] deriveConstants: readProcess: /usr/bin/nm "-P" "includes/dist- derivedconstants/header/tmp.o" (exit 1): failed includes/ghc.mk:167: recipe for target 'includes/dist- derivedconstants/header/DerivedConstants.h' failed gmake[1]: *** [includes/dist-derivedconstants/header/DerivedConstants.h] Error 1 Makefile:71: recipe for target 'all' failed gmake: *** [all] Error 2 }}} This is due to OpenBSD's nm not supporting the -P option. Perhaps it can be fixed by using 'objdump --syms' instead of 'nm -P' (see attached OpenBSD-only patch). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9549> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #9422: EPT caching on --make can make spurious instances visible
by GHC 24 Oct '14

24 Oct '14

#9422: EPT caching on --make can make spurious instances visible -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.9 checker) | Operating System: Keywords: | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: GHC Difficulty: Unknown | accepts invalid program Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- This is perhaps best demonstrated by way of an example. Suppose we have a package a with the following two modules, with A defining a type class and data type, and I defining an orphan instance. {{{#!hs module A where data A = A class C a where cop :: a -> a }}} {{{#!hs module I where import A instance C A where cop = id }}} Then, when compiling this module: {{{#!hs module N where import A x = cop A }}} I might reasonably expect to be told that the instance `C` is not in scope (since I didn't import `I`, nor did any of my dependencies import `I`). However, suppose I have another module: {{{#!hs module M where import I }}} and I use `--make` to compile both of these modules in one go, with `M` being compiled first (`ghc --make N.hs M.hs` does that for me), then `N` will incorrectly type check and compile! This should not happen. The reason for this behavior is that we do not clear the EPT (external package table) between compilations of a file in batch compilation mode; this saves us from having to repeatedly read instances from the external files. Thus, `M`, having loaded the instances into the EPT when type- checking, `N` will automatically pick them up. Note that `I` and `A` have to be in a separate package; otherwise `--make` puts them in the HPT (home package table) and everything works fine. (Note also that one-shot compilation puts home modules in the EPT, but since that gets thrown out everything is fine as well, although perhaps a user of the GHC API could get bitten by this.) As for the fix, it's probably not right to clear the EPT either, since we get quite good time savings from not having to parse interface files repeatedly. Perhaps we could do something clever by partitioning up the EPT, but maybe it's not worth it and we should keep this bug as a known infelicity until the next time this part of the compiler gets rewritten. I'll submit a test-case (marked as failing) anyhoo. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9422> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9537: concatMap does not participate in list fusion
by GHC 22 Oct '14

22 Oct '14

#9537: concatMap does not participate in list fusion -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.4 Component: libraries/base | Version: 7.9 Keywords: fusion | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Runtime Blocked By: | performance bug Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Joachim Breitner raised this issue in an [http://www.haskell.org/pipermail /haskell-cafe/2011-December/097228.html email to haskell-cafe] in 2011, but he never got a response. For some reason, list comprehensions desugar to `concatMap` forms written to fuse, but the actual `concatMap` function is not written so. Unless there is a good reason for this, we should make it fuse. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9537> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9038: Foreign calls don't make their arguments look strict
by GHC 21 Oct '14

21 Oct '14

#9038: Foreign calls don't make their arguments look strict ------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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: | ------------------------------------+------------------------------------- Here's a function that takes a `Double` which is always passed to a `foreign import` expecting a `Double#`. Since the value is always unpacked, I'd expect `add3` to be strict in the `Double` argument and thereby avoid some allocation. {{{ add3 :: Distribution -> Double -> Int64 -> State# RealWorld -> (# State# RealWorld, () #) add3 = \ (distrib_a1uw :: Distribution) (val_a1ux :: Double) (n_a1uy :: Int64) (eta_X22 :: State# RealWorld) -> case myThreadId# eta_X22 of _ { (# ipv_i229, ipv1_i22a #) -> case threadStatus# ipv1_i22a ipv_i229 of _ { (# ipv2_i22e, _, ipv4_i22g, _ #) -> case modInt# ipv4_i22g 8 of ww1_i1NM { __DEFAULT -> case distrib_a1uw `cast` (<NTCo:Distribution> :: Distribution ~# Array Stripe) of _ { Array ds2_i22q -> case indexArray# ds2_i22q ww1_i1NM of _ { (# ipv6_i1Nz #) -> case ipv6_i1Nz of _ { Stripe ipv7_s22v ipv8_s22w ipv9_s22x ipv10_s22y -> case {__pkg_ccall main hs_lock Addr# -> State# RealWorld -> (# State# RealWorld #)}_i20J ipv9_s22x ipv2_i22e of _ { (# ds4_i20P #) -> case touch# ipv10_s22y ds4_i20P of s'_i20R { __DEFAULT -> case val_a1ux of _ { D# ds6_d1D8 -> case n_a1uy of _ { I64# ds8_d1Da -> case {__pkg_ccall main hs_distrib_add_n Addr# -> Double# -> Int# -> State# RealWorld -> (# State# RealWorld #)}_d1Dd ipv7_s22v ds6_d1D8 ds8_d1Da s'_i20R of _ { (# ds9_d1Db #) -> case {__pkg_ccall main hs_unlock Addr# -> State# RealWorld -> (# State# RealWorld #)}_i20m ipv9_s22x ds9_d1Db of _ { (# ds10_i20s #) -> case touch# ipv10_s22y ds10_i20s of s'1_i20u { __DEFAULT -> case touch# ipv8_s22w s'1_i20u of s'2_i1YT { __DEFAULT -> (# s'2_i1YT, () #) } } } } } } } } } } } } } } }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9038> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #9561: Clean up mergeSATInfo
by GHC 20 Oct '14

20 Oct '14

#9561: Clean up mergeSATInfo -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: new Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.9 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: -------------------------------------+------------------------------------- `mergeSATInfo` in SAT.hs is much longer and harder to read than it needs to be. I am attaching a patch to make it use `zipWith` instead of zipping manually. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9561> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9536: Implement foldr/cons/build
by GHC 20 Oct '14

20 Oct '14

#9536: Implement foldr/cons/build -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: task | Status: new Priority: normal | Milestone: 7.8.4 Component: libraries/base | Version: 7.9 Keywords: fusion | 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: -------------------------------------+------------------------------------- There seem to be various issues with general `fold/cons` and even `cons/build` rules, but it seems pretty clear to me that the simple `fold/cons/build` rule is a good idea. It doesn't do much for nofib allocation, but it seems to improve some other analyses and speed several benchmarks up, including speeding up some things that other fusion changes slowed down. I say "seems to" because I never trust my timings much at all. {{{#!hs {-# RULES "foldr/cons/build" forall c n x (g::forall b. (a->b->b) -> b -> b) . foldr c n (x:build g) = c x (g c n) #-} }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9536> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9529: Clean up cseProgram
by GHC 20 Oct '14

20 Oct '14

#9529: Clean up cseProgram -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.4 Component: Compiler | Version: 7.9 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: -------------------------------------+------------------------------------- I think this should be a no-brainer: Replace {{{#!hs cseProgram :: CoreProgram -> CoreProgram cseProgram binds = cseBinds emptyCSEnv binds cseBinds :: CSEnv -> [CoreBind] -> [CoreBind] cseBinds _ [] = [] cseBinds env (b:bs) = (b':bs') where (env1, b') = cseBind env b bs' = cseBinds env1 bs }}} with {{{#!hs cseProgram :: CoreProgram -> CoreProgram cseProgram = snd . mapAccumL cseBind emptyCSEnv }}} I'll attach a patch. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9529> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9332: Memory blowing up for strict sum/strict foldl in ghci
by GHC 20 Oct '14

20 Oct '14

#9332: Memory blowing up for strict sum/strict foldl in ghci -------------------------------------+------------------------------------- Reporter: artella.coding | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Keywords: ghci, strict, | Differential Revisions: memory | Architecture: x86_64 Operating System: Linux | (amd64) Type of failure: Runtime | Difficulty: Unknown performance bug | Blocked By: Test Case: | Related Tickets: Blocking: | -------------------------------------+------------------------------------- (http://stackoverflow.com/questions/24838982/memory-blowing-up-for-strict- sum-strict-foldl-in-ghci) Suppose we have {{{ --Test.hs import Data.List longList::[Int] longList = [1 .. ] result :: Int result = foldl' (+) 0 $ takeWhile (< 10000000) longList main = do print $ result }}} If one deletes all the ".hi" and ".o" files and then loads into ghci via : {{{ ghci -fobject-code Test.hs }}} then upon running "main" the memory blows up. However if one first compiles via : {{{ ghc Test.hs }}} and then subsequently loads into ghci via : {{{ ghci Test.hs }}} then upon running "main" the memory does not blow up. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9332> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 14

[GHC] #9355: scanr does not participate in stream fusion
by GHC 20 Oct '14

20 Oct '14

#9355: scanr does not participate in stream fusion -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.4 Component: libraries/base | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Moderate (less | Type of failure: Runtime than a day) | performance bug Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- This should be a no-brainer—it's trivial two write `scanr` as a foldr, making it a good consumer. Wrapping it up in `build` makes it a good producer too, but may require back-and-forth RULES. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9355> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #9369: Data.List.unfoldr does not fuse and is not inlined.
by GHC 20 Oct '14

20 Oct '14

#9369: Data.List.unfoldr does not fuse and is not inlined. -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.4 Component: libraries/base | Version: 7.8.3 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: -------------------------------------+------------------------------------- `Data.List.unfoldr` is not a good producer for foldr/build fusion, and it's not wrapped to enable inlining. I don't know how often people explicitly fold over an unfold, but this of course also affects map and filter. The inlining issue is also serious: inlining `unfoldr` can often allow the `Maybe` to be erased altogether. I'm not sure this fix is perfect, but it seems a lot better than the current situation: {{{#!hs import GHC.Exts (build) {-# NOINLINE [1] unfoldr #-} unfoldr :: (b -> Maybe (a, b)) -> b -> [a] unfoldr f b = go b where go b = case f b of Just (a,new_b) -> a : go new_b Nothing -> [] {-# INLINE [0] unfoldrB #-} unfoldrB :: (b -> Maybe (a, b)) -> b -> (a -> c -> c) -> c -> c unfoldrB f b' c n = go b' where go b = case f b of Just (a,new_b) -> a `c` go new_b Nothing -> n {-# RULES "unfoldr" [~1] forall f b . unfoldr f b = build (unfoldrB f b) #-} }}} As a simple example, consider the code {{{#!hs hello :: Double -> Double -> [Double] hello x n = map (* 3) $ L.unfoldr f x where f x | x < n = Just (x, x**1.2) | otherwise = Nothing }}} With `Data.List.unfoldr` and the latest bleeding-edge GHC, this produces {{{#!hs hello1 hello1 = \ ds_d1ZF -> case ds_d1ZF of _ { D# x_a21W -> D# (*## x_a21W 3.0) } $whello $whello = \ w_s266 ww_s26a -> map hello1 (unfoldr (\ x_X1Hx -> case x_X1Hx of wild_a20E { D# x1_a20G -> case tagToEnum# (<## x1_a20G ww_s26a) of _ { False -> Nothing; True -> Just (wild_a20E, D# (**## x1_a20G 1.2)) } }) w_s266) hello hello = \ w_s266 w1_s267 -> case w1_s267 of _ { D# ww1_s26a -> $whello w_s266 ww1_s26a } }}} Using the above implementation (and renaming the function from `hello` to `bye`) yields {{{#!hs $wbye $wbye = \ ww_s25Z ww1_s263 -> letrec { $wgo_s25U $wgo_s25U = \ ww2_s25S -> case tagToEnum# (<## ww2_s25S ww1_s263) of _ { False -> []; True -> : (D# (*## ww2_s25S 3.0)) ($wgo_s25U (**## ww2_s25S 1.2)) }; } in $wgo_s25U ww_s25Z bye bye = \ w_s25V w1_s25W -> case w_s25V of _ { D# ww1_s25Z -> case w1_s25W of _ { D# ww3_s263 -> $wbye ww1_s25Z ww3_s263 } } }}} I don't think there can be any doubt which is better. Yes, some fine tuning may be needed to make the rules apply in all appropriate cases. I don't understand things like the comment on the definition of `map` drawing attention to eta expansion. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9369> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11