- ghc-tickets - Haskell.org

[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

[GHC] #9398: Data.List.cycle is not a good producer
by GHC 20 Oct '14

20 Oct '14

#9398: Data.List.cycle is not a good producer -------------------------------------+------------------------------------- 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.cycle is not a good producer. I'm not at all sure this solution is the best, but it allocates much less when mapped over and then folded. If we could make it a good consumer cheaply that would be nice too, but I imagine it's probably mostly applied to short lists, so that is probably not a priority. {{{#!hs {-# INLINE cycle #-} cycle :: [a] -> [a] cycle [] = error "Prelude.cycle: empty list" cycle xs = concat $ repeat xs }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9398> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 22

Re: [GHC] #3658: Dynamically link GHCi (and use system linker) on platforms that support it
by GHC 20 Oct '14

20 Oct '14

#3658: Dynamically link GHCi (and use system linker) on platforms that support it -------------------------------------+------------------------------------- Reporter: simonmar | Owner: thoughtpolice Type: task | Status: closed Priority: normal | Milestone: 7.10.1 Component: GHCi | Version: 6.10.4 Resolution: fixed | Keywords: dynamic link Operating System: | Architecture: Unknown/Multiple Unknown/Multiple | Difficulty: Unknown Type of failure: | Blocked By: None/Unknown | Related Tickets: Test Case: | Blocking: 1883, | 3242, 3372, 3654, 4244, 5062, | 5197, 6107, 7072, 7103, 7316, | 7389, 7475, 7687 | Differential Revisions: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * milestone: 7.8.4 => 7.10.1 Comment: Moving out of 7.8.4 milestone, since it's not really appropriately 'fixed' here. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3658#comment:56> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9684: Broken build on OS X (incompatible pthread_setname_np API)
by GHC 20 Oct '14

20 Oct '14

#9684: Broken build on OS X (incompatible pthread_setname_np API) -------------------------------------+------------------------------------- Reporter: mlen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: MacOS X pthread_setname_np | Type of failure: Building Architecture: Unknown/Multiple | GHC failed Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: | 674c631ea111233daa929ef63500d75ba0db8858 -------------------------------------+------------------------------------- Build is broken on OS X because it is only possible to set thread name for the current thread and `pthread_setname_np` accepts a single argument. This function appeared in 10.6. If that OS version needs to be supported, the best thing that can be done is conditional compilation. A short summary of inconsistencies between different *nix systems can be found here: http://stackoverflow.com/questions/2369738/can-i-set-the-name-of-a -thread-in-pthreads-linux/7989973#7989973 The error log: {{{ rts/posix/OSThreads.c:138:30: error: too many arguments to function call, expected 1, have 2 pthread_setname_np(*pId, name); ~~~~~~~~~~~~~~~~~~ ^~~~ /usr/include/pthread.h:471:1: note: 'pthread_setname_np' declared here __OSX_AVAILABLE_STARTING(__MAC_10_6, __IPHONE_3_2) ^ /usr/include/Availability.h:159:50: note: expanded from macro '__OSX_AVAILABLE_STARTING' #define __OSX_AVAILABLE_STARTING(_osx, _ios) __AVAILABILITY_INTERNAL##_osx ^ <scratch space>:65:1: note: expanded from here __AVAILABILITY_INTERNAL__MAC_10_6 ^ /usr/include/AvailabilityInternal.h:3912:72: note: expanded from macro '__AVAILABILITY_INTERNAL__MAC_10_6' #define __AVAILABILITY_INTERNAL__MAC_10_6 __attribute__((availability(macosx,introduced=10.6))) ^ 1 error generated. }}} I can see two possible solutions for OS X: 1. disable setting thread name by conditional compilation. 2. write some trampoline code to work around the fact that it is only possible to set thread name for the current thread. The latter would look like this: {{{ struct wrapper { char *name; void *param; void *(*cont)(void *); }; void *trampoline(void *ctx) { struct wrapper *params = (struct wrapper *)ctx; void *param = params->param; void *(*cont)(void *) = params->cont; #ifdef MACOSX pthread_setname_np(params->name); #elif pthread_setname_np(pthread_self(), params->name); #endif free(params); return cont(param); } int createOSThread (OSThreadId* pId, char *name, OSThreadProc *startProc, void *param) { struct wrapper *ctx = malloc(sizeof(struct wrapper)); ctx->name = name; ctx->cont = startProc; ctx->param = param; int result = pthread_create(pId, NULL, (void *(*)(void *))trampoline, &ctx); if (!result) { pthread_detach(*pId); } else { free(ctx); } return result; } }}} It looks very hackish and I think it'd be better to go with (1), since the original change was made for debugging purposes. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9684> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #9639: Remove OldTypeable
by GHC 20 Oct '14

20 Oct '14

#9639: Remove OldTypeable -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: task | Status: new Priority: normal | Milestone: 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 it's safe to remove `Data.OldTypeable` now. It's been deprecated in 7.8, and we said that we'd remove it for 7.10. This ticket is to record that task, and to check that there are no objections to removing it. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9639> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 18