February 2017 - ghc-tickets

[GHC] #13336: Improve or remove the glomming warning
by GHC 27 Feb '17

27 Feb '17

#13336: Improve or remove the glomming warning -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In the GHC build log there's lots of warnings about "glomming" but they are not actionable. The first problem is understanding what glomming is, that much is explained in the `Note [Glomming]`, In my own words, in the occurence analyser there are situations where there are out of scope top-level bindings. This usually happens when a rule is fired which drops in a new binding which does not appear anywhere else other than in rules. GHC dutifully warns us about this event but I can't work out why it this is necessary. What is bad about glomming? It seems like normal and expected behaviour for this to happen, further, there isn't really anything you can do about it. If it is a worthwhile warning to investigate, then the debugging output should be improved as the output is currently a list of uniques with occurence information which is difficult to map to source files. It would be much more useful to display the user-level names of the glommed identifiers. For a real world example look in `Data.Maybe`, compiling this module with a debugging compiler will emit a warning about glomming because of `mapMaybeFB` which appears on the RHS of rules but not anywhere else in a module. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13336> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

Re: [GHC] #1600: Optimisation: CPR the results of IO
by GHC 27 Feb '17

27 Feb '17

#1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8598 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by akio): > There are two changes in that commit: Actually the only change is the latter one. The former change is already in HEAD, as of 2be364ac8c. > Making data con wrapper have ug_boring_ok = boringCxtOk. I'm not sure I buy this in full. In Note [Inline data constructor wrappers aggresively] there's a claim that we get better nested-CPR info. I don't think the improvement has anything to do with nested CPR, because I'm testing this change in isolation, without any other changes from the nested CPR branch. The big difference in nofib comes from the `GHC.Integer.Types` module in `integer-gmp`. This module has this definition: {{{#!hs data Integer = S# !Int# -- ^ iff value in @[minBound::'Int', maxBound::'Int']@ range | Jp# {-# UNPACK #-} !BigNat -- ^ iff value in @]maxBound::'Int', +inf[@ range | Jn# {-# UNPACK #-} !BigNat -- ^ iff value in @]-inf, minBound::'Int'[@ range }}} Note the redundant bang in the `S#` constructor. This causes a wrapper for this constructor to be created: {{{#!hs GHC.Integer.Type.$WS# = \ (dt [Occ=Once] :: Int#) -> case dt of dt { __DEFAULT -> GHC.Integer.Type.S# dt } }}} And this wrapper remains un-inlined in various places like: {{{#!hs quotRemInteger = \ (n :: Integer) (ds :: Integer) -> join { fail1 [Dmd=<L,1*C1(U(U,U))>] :: Void# -> (# Integer, Integer #) [LclId[JoinId(1)], Arity=1, Str=<L,A>, Unf=OtherCon []] fail1 _ [Occ=Dead, OS=OneShot] = case n of n1 { __DEFAULT -> join { fail2 [Dmd=<L,1*C1(U(U,U))>] :: Void# -> (# Integer, Integer #) [LclId[JoinId(1)], Arity=1, Str=<L,A>, Unf=OtherCon []] fail2 _ [Occ=Dead, OS=OneShot] = case n1 of wild { S# ds3 -> case ds3 of ds4 { __DEFAULT -> case ds of { S# d# -> case quotRemInt# ds4 d# of { (# ipv, ipv1 #) -> (# GHC.Integer.Type.$WS# ipv, GHC.Integer.Type.$WS# ipv1 #) ... }}} leading to unnecessary allocation of thunks. It should be possible to fix this problem by doing one of the following: 1. Inline constructor wrappers like `$WS#` aggressively, at least when it's fully applied. 2. Do not create a redundant wrapper in a case like this. 3. Remove this particular bang from integer-gmp. I have tried (1) and (3), and they seem to have very similar effects. (3) is definitely the easiest to implement, but I wonder if (2) is more correct. I'd like to hear some suggestions about this. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1600#comment:66> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12459: UnboxedTuple makes overloaded labels fail to parse
by GHC 26 Feb '17

26 Feb '17

#12459: UnboxedTuple makes overloaded labels fail to parse -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Parser) | Keywords: orf | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- [https://gist.githubusercontent.com/PkmX/bfb2c5af4317c96282795f8c588fda1c/ra… This] works (removing spaces) {{{#!hs -- user = ( #login := "themoritz", #id := 3522732 ) user :: User user = (#login := "themoritz", #id := 3522732) }}} but it doesn't when `UnboxedTuples` are enabled: {{{#!hs -- tWKw.hs:63:46: error: parse error on input ‘)’ user = (#login := "themoritz", #id := 3522732) }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12459> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11

[GHC] #13288: Resident set size exceeds +RTS -M limit with large nurseries
by GHC 26 Feb '17

26 Feb '17

#13288: Resident set size exceeds +RTS -M limit with large nurseries -------------------------------------+------------------------------------- Reporter: j6carey | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.0.2 System | Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Runtime (amd64) | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- We observed high resident set size well in excess of the `+RTS -M` limit in a long-running, high data-volume Haskell application that Awake Networks is deploying on a network appliance. We think that the current `GC.c` code has two bugs that, at least in combination with each other, become significant when high `+RTS -N` and very high `+RTS -A` values are used. 1. As we approach the `-M` limit, the computation of the new size for generation 1 appears to be based on an incorrect figure for the total size of the nursery. The `-A` value is used instead of the product of that value with `-N`. This problem could lead to the total heap size exceeding the `-M` limit. 2. Memory allocated from the operating system is freed only if the RTS thinks that it would not be reallocated soon. The estimate for what will be needed soon is based on fewer inputs than the actual resizing logic, and in particular it is not affected by `-M`. Thus it might keep free mblocks in excess of the `-M` limit, based on an expected heap growth that would be forbidden by `-M`. We are preparing a patch to address these issues; it will point out the particular lines of code. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13288> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #12223: Get rid of extra_files.py
by GHC 26 Feb '17

26 Feb '17

#12223: Get rid of extra_files.py -------------------------------------+------------------------------------- Reporter: ezyang | Owner: thomie Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hello thomie! When you refactored the test suite you added `testsuite/driver/extra_files.py` to record what extra files need to get copied. In it, there is a comment "Maybe move this information to .T files at some point." This ticket is to remind you so you don't forget. This file is *extremely* un-discoverable. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12223> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #13171: panic on negative literal in case on Word
by GHC 26 Feb '17

26 Feb '17

#13171: panic on negative literal in case on Word -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs module Case where f :: Word -> Word f n = case n of -1 -> 2 _ -> 3 }}} {{{ ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20170119 for x86_64-unknown-linux): ASSERT failed! -1 Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1182:22 in ghc:Outputable assertPprPanic, called at compiler/basicTypes/Literal.hs:223:75 in ghc:Literal Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/utils/Outputable.hs:1180:5 in ghc:Outputable assertPprPanic, called at compiler/basicTypes/Literal.hs:223:75 in ghc:Literal Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Doesn't happen in 8.0.1. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13171> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #10246: Literal Pattern match loses order
by GHC 26 Feb '17

26 Feb '17

#10246: Literal Pattern match loses order -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I found this long-standing bug while investigating #10245: Consider this code: {{{ f1 :: Int -> String f1 n = case n of 0 -> "bar" 0x10000000000000000 -> "foo" _ -> "c" {-# NOINLINE f1 #-} g1 :: Int -> String g1 n = if n == 0 then "bar" else if n == 0x10000000000000000 then "foo" else "c" {-# NOINLINE g1 #-} f2 :: Int -> String f2 n = case n of 0x10000000000000000 -> "foo" 0 -> "bar" _ -> "c" {-# NOINLINE f2 #-} g2 :: Int -> String g2 n = if n == 0x10000000000000000 then "foo" else if n == 0 then "bar" else "c" {-# NOINLINE g2 #-} main = do let i = read "0" :: Int print (f1 i) print (g1 i) print (f2 i) print (g2 i) }}} According to the report, `f1` should behave like `g1` and `f2` should behave like `g2`. But that is not the case: I get {{{ "foo" "bar" "foo" "foo" }}} The reason is that the branches are sorted, to create fancy code for it, but this does not take into account that `0x10000000000000000 = 0`, at least for `Int`. This bug is present also in 7.8.4, and not (directly) related to my CmmSwitch code: It can also be observed with interpreted code, so the fix must happen earlier. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10246> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #9533: Signed/unsigned integer difference between compiled and interpreted code
by GHC 26 Feb '17

26 Feb '17

#9533: Signed/unsigned integer difference between compiled and interpreted code -------------------------------------+------------------------------------- Reporter: MichaelBurge | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: Incorrect Difficulty: Unknown | result at runtime Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- The following code outputs "A". {{{#!hs import Data.Word x :: Word x = 10 y :: Word y = 11 test = case x - y of -1 -> "A" _ -> "B" main = putStrLn $ show test }}} However, adding a new case that isn't matched causes the output to change: {{{#!hs import Data.Word x :: Word x = 10 y :: Word y = 11 test = case x - y of 5 -> "C" -1 -> "A" _ -> "B" main = putStrLn $ show test }}} With the extra '5 -> "C"' line in the case, the output is "B". It gets weirder - interpreted code actually continues to match the -1 case. With the second example in a file 'T.hs', here is a GHCi session: {{{ Prelude Main> :l *T.hs [1 of 1] Compiling Main ( T.hs, interpreted ) Ok, modules loaded: Main. *Main> main "A" *Main> :l T.hs Ok, modules loaded: Main. Prelude Main> main "B" Prelude Main> }}} These examples suggest to me at least 3 improvements: * Issue a warning when a negative number is used in a case statement in unsigned context * Interpreted code should give the same result as compiled code * Adding a case that isn't matched shouldn't change which other patterns get matched -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9533> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

Re: [GHC] #1: Implicit parameters cause strange behavi
by GHC 26 Feb '17

26 Feb '17

#1: Implicit parameters cause strange behavi --------------------------------+-------------------- Reporter: nobody | Owner: nobody Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 5.0 Resolution: Fixed | Keywords: Type of failure: None/Unknown | --------------------------------+-------------------- Changes (by Ben Gamari <ben@…>): * failure: => None/Unknown Comment: In [changeset:"5c95e6b7c2790c192720ba5a533d6d11fad570f8/ghc" 5c95e6b7/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5c95e6b7c2790c192720ba5a533d6d11fad570f8" Remove outdated information about main() in HSrts (#1) The main method is not contained in HSrts so the removed section is no longer valid. }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1#comment:3> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13331: Worker/wrapper can lead to sharing failure
by GHC 26 Feb '17

26 Feb '17

#13331: Worker/wrapper can lead to sharing failure -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `nofib` turned up a serious performance bug in the implementation of `insert` in `containers-0.5.10.1`. The function was defined thus: {{{#!hs origInsert :: Ord k => k -> a -> Map k a -> Map k a origInsert = go where go :: Ord k => k -> a -> Map k a -> Map k a go !kx x Tip = singleton kx x go !kx x t@(Bin sz ky y l r) = case compare kx ky of LT | l' `ptrEq` l -> t | otherwise -> balanceL ky y l' r where !l' = go kx x l GT | r' `ptrEq` r -> t | otherwise -> balanceR ky y l r' where !r' = go kx x r EQ | kx `ptrEq` ky && x `ptrEq` y -> t | otherwise -> Bin sz kx x l r {-# INLINABLE origInsert #-} }}} When this specializes to `Int` keys (or any other "unboxable" ones, including tuples), worker/wrapper botches the job: {{{ Rec { -- RHS size: {terms: 102, types: 65, coercions: 0} $w$sgo :: forall a_a7M6. Int# -> a_a7M6 -> Map Int a_a7M6 -> Map Int a_a7M6 $w$sgo = \ (@ a_a7M6) (ww_s8oI :: Int#) (w_s8oE :: a_a7M6) (w1_s8oF :: Map Int a_a7M6) -> let { kx_X7KQ :: Int kx_X7KQ = I# ww_s8oI } in case w1_s8oF of wild_Xg { [...] origInsertInt_$sgo :: forall a_a7M6. Int -> a_a7M6 -> Map Int a_a7M6 -> Map Int a_a7M6 origInsertInt_$sgo = \ (@ a_a7M6) (w_s8oD :: Int) (w1_s8oE :: a_a7M6) (w2_s8oF :: Map Int a_a7M6) -> case w_s8oD of _ { I# ww1_s8oI -> $w$sgo ww1_s8oI w1_s8oE w2_s8oF } }}} The wrapper opens the box, throws it away, and passes the contents to the worker, which immediately builds a ''new'' box with exactly the same contents. This prevents the pointer equality tests from succeeding for these types, and it also turns out to cause quite a lot of extra allocation for some types (leading to the severe nofib regression). One could reasonably argue that the code above is a bit complicated, and that GHC could be forgiven for failing to realize that the box should be saved. Unfortunately, a straightforward change that would seem to make this clear does not in fact convince GHC: {{{#!hs myInsert :: Ord k => k -> a -> Map k a -> Map k a myInsert kx0 = go kx0 where go !kx x Tip = singleton kx0 x go !kx x t@(Bin sz ky y l r) = case compare kx ky of LT | l' `ptrEq` l -> t | otherwise -> balanceL ky y l' r where !l' = go kx x l GT | r' `ptrEq` r -> t | otherwise -> balanceR ky y l r' where !r' = go kx x r EQ | kx0 `ptrEq` ky && x `ptrEq` y -> t | otherwise -> Bin sz kx0 x l r {-# INLINABLE myInsert #-} }}} does exactly the same thing. The only ''simple'' way I found to avoid that is to remove the bang patterns, which really ''shouldn't'' work, but does. This, however, is prohibited by the required semantics—we must be strict in the key even if comparison is not. The only fix I've found thus far is truly disgusting, and seems to work at least partly by mistake: {{{#!hs insert :: Ord k => k -> a -> Map k a -> Map k a insert kx0 = go kx0 kx0 where go :: Ord k => k -> k -> a -> Map k a -> Map k a go orig !kx x Tip = singleton (lazy orig) x go orig !kx x t@(Bin sz ky y l r) = case compare kx ky of LT | l' `ptrEq` l -> t | otherwise -> balanceL ky y l' r where !l' = go orig kx x l GT | r' `ptrEq` r -> t | otherwise -> balanceR ky y l r' where !r' = go orig kx x r EQ | x `ptrEq` y && (lazy orig `seq` (orig `ptrEq` ky)) -> t | otherwise -> Bin sz (lazy orig) x l r {-# INLINABLE insert #-} }}} We would also like to be able to experiment with an implementation that uses CPS (recursive join points today!) rather than pointer equality tests for the internal nodes, leaving pointer equality to the leaves. But I have not found any way whatsoever to avoid this W/W problem in that version. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13331> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9