February 2017 - ghc-tickets

[GHC] #13247: hPutBufNonBlocking can block
by GHC 09 Feb '17

09 Feb '17

#13247: hPutBufNonBlocking can block -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #13246, #13245 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This simply escalates an existing TODO in the code base to a ticket. The function `System.IO.hPutBufNonBlocking` [1] calls `hPutBuf'` with `can_block = False`, which is commented as `Bool -- allow blocking?` ([https://github.com/ghc/ghc/blame/876b00ba25a615423f48b0cf9d443a9fd5dbd6f4/l… relevant lines]) However, `hPutBuf'` calls `bufWrite`, inside which there's the comment ([https://github.com/ghc/ghc/blame/876b00ba25a615423f48b0cf9d443a9fd5dbd6f4/l… relevant line]): {{{ if (...) -- There's enough room in the buffer: -- just copy the data in and update bufR. then do ... -- else, we have to flush else do ... old_buf' <- Buffered.flushWriteBuffer haDevice old_buf -- TODO: we should do a non-blocking flush here }}} so it turns out that if there's not enough room in the `Handle` buffer, then `hPutBufNonBlocking` will block. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13247> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #13077: Worker/wrapper can break the let-app invariant
by GHC 08 Feb '17

08 Feb '17

#13077: Worker/wrapper can break the let-app invariant -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | 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: -------------------------------------+------------------------------------- Consider this {{{ {-# LANGUAGE MagicHash #-} module Bar where import GHC.Exts data X = A | B | C data T = MkT !X Int# Int# f (MkT x 0# _) = True f (MkT x n _) = let v = case x of A -> 1# B -> 2# C -> n in f (MkT x v v) }}} Compile with -O and (with GHC 8) you'll get {{{ *** Core Lint errors : in result of Simplifier *** Bar.hs:10:23: Warning: [RHS of v_s1IX :: Int#] The type of this binder is primitive: v_s1IX Binder's type: Int# *** Offending Program *** Rec { f [InlPrag=INLINE[0]] :: T -> Bool [LclIdX, Arity=1, Str=DmdType <S(SSL),1*U(U,1*U,A)>, Unf=Unf{Src=InlineStable, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=1,unsat_ok=True,boring_ok=False) Tmpl= \ (w_s1Jq [Occ=Once!] :: T) -> case w_s1Jq of _ [Occ=Dead] { MkT ww_s1Jt [Occ=Once] ww_s1Ju [Occ=Once] _ [Occ=Dead] -> $wf_s1Jx ww_s1Jt ww_s1Ju }}] f = \ (w_s1Jq :: T) -> case w_s1Jq of _ [Occ=Dead] { MkT ww_s1Jt ww_s1Ju ww_s1Jv -> $wf_s1Jx ww_s1Jt ww_s1Ju } $wf_s1Jx [InlPrag=[0], Occ=LoopBreaker] :: X -> Int# -> Bool [LclId, Arity=2, Str=DmdType <S,U><S,1*U>, Unf=Unf{Src=<vanilla>, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [40 30] 80 10}] $wf_s1Jx = \ (ww_s1Jt :: X) (ww_s1Ju :: Int#) -> case ww_s1Ju of ds_X1IO [Dmd=<L,1*U>] { __DEFAULT -> let { v_s1IX [Dmd=<S,U>] :: Int# [LclId, Str=DmdType, Unf=Unf{Src=<vanilla>, TopLvl=False, Value=False, ConLike=False, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 30 0}] v_s1IX = case ww_s1Jt of _ [Occ=Dead, Dmd=<L,A>] { A -> 1; B -> 2; C -> ds_X1IO } } in $wf_s1Jx ww_s1Jt v_s1IX; 0 -> True } end Rec } }}} Reason: in the worker, the lambda-bound arguments don't say they are evaluated, so the previously ok-for-speculation RHS of the 'let' is no longer so. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13077> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8155: Defaulting bug or unfortunate error message with closed type families
by GHC 08 Feb '17

08 Feb '17

#8155: Defaulting bug or unfortunate error message with closed type families ------------------------------------+------------------------------------- Reporter: nh2 | 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: | ------------------------------------+------------------------------------- https://github.com/nh2/infinite-type-families/blob/master/Test2.hs Some code extracted from hmatrix: {{{ {-# LANGUAGE CPP #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE FlexibleInstances #-} module Test where data Vector a = Vector a data Matrix a = Matrix a class Build f where build' :: BoundsOf f -> f -> ContainerOf f #if __GLASGOW_HASKELL__ <= 706 -- Normal type families with GHC 7.6, works well. type family BoundsOf x type instance BoundsOf (a->a) = Int type instance BoundsOf (a->a->a) = (Int,Int) type family ContainerOf x type instance ContainerOf (a->a) = Vector a type instance ContainerOf (a->a->a) = Matrix a #else -- Closed type families for GHC 7.8 type family BoundsOf x where BoundsOf (a->a->a) = (Int,Int) BoundsOf (a->a) = Int type family ContainerOf x where ContainerOf (a->a) = Vector a ContainerOf (a->a->a) = Matrix a #endif instance (Num a) => Build (a->a) where build' = buildV buildV :: (Integral a, Num b) => a -> (b -> c) -> Vector c buildV _ _ = undefined }}} This is probably related to #8154. With GHC 7.7, we get the following error: {{{ Test2.hs:59:14: Could not deduce (BoundsOf (a -> a) ~ Integer) from the context (Num a) bound by the instance declaration at Test2.hs:58:10-32 Expected type: BoundsOf (a -> a) -> (a -> a) -> ContainerOf (a -> a) Actual type: Integer -> (a -> a) -> Vector a Relevant bindings include build' :: BoundsOf (a -> a) -> (a -> a) -> ContainerOf (a -> a) (bound at Test2.hs:59:5) In the expression: buildV In an equation for ‛build'’: build' = buildV }}} 1) Where does this Integer come from? 2) Change {{{ BoundsOf (a->a) = Int }}} into {{{ BoundsOf (a->a) = Integer }}} You get the same error message, although clearly {{{BoundsOf (a -> a) ~ Integer}}} (you just wrote that down).[[BR]] Even if the order matters in closed type families, is this not the wrong error message? 3) If you flip the order so that the (a->a) case comes first, it works (with both it Int or Integer). I don't quite understand why. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8155> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #12957: In a record-update construct:ghc-stage2: panic! (the 'impossible' happened)
by GHC 08 Feb '17

08 Feb '17

#12957: In a record-update construct:ghc-stage2: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 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: -------------------------------------+------------------------------------- While compiling `Repro.hs` with `HEAD` I get this: {{{ $ ~/local/ghc-inaccessible-right-side/inplace/bin/ghc-stage2 Repro.hs [1 of 1] Compiling Repro ( Repro.hs, Repro.o ) Repro.hs:22:35: warning: [-Woverlapping-patterns] Pattern match has inaccessible right hand side In a record-update construct:ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20161209 for x86_64-unknown-linux): unused Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} It doesn't reproduce on 7.10.2. I'm 90% sure it reproduces on 8.0.2 (I have a branch with some unrelated patches). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12957> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #13144: FoatOut is not floating bottoming expressions properly
by GHC 08 Feb '17

08 Feb '17

#13144: FoatOut is not floating bottoming expressions properly -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | 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: -------------------------------------+------------------------------------- Consider part of Eric's program in #13143, and pretty much exactly what is in `GHC.Arr`. {{{ {-# INLINE index #-} index :: (Int, Int) -> Int -> Int index b@(l,h) i | l <= i && i < h = 0 | otherwise = indexError b i 0 {-# NOINLINE indexError #-} indexError :: (Int, Int) -> Int -> Int -> b indexError rng i tp = error (show rng) }}} Before float-out we have {{{ index = \ (b_ay8 :: (Int, Int)) (i_ayb :: Int) -> case b_ay8 of wild_Xe { (l_ay9, h_aya) -> case && (leInt l_ay9 i_ayb) (ltInt i_ayb h_aya) of { False -> indexError @ Int wild_Xe i_ayb (I# 0#); True -> GHC.Types.I# 0# } } }}} and after float-out we see {{{ index = \ (b_ay8 :: (Int, Int)) (i_ayb :: Int) -> case b_ay8 of wild_Xe { (l_ay9, h_aya) -> case && (leInt l_ay9 i_ayb) (ltInt i_ayb h_aya) of { False -> indexError @ Int b_ay8 i_ayb lvl_s2cd; True -> GHC.Types.I# 0# } } }}} We've floated the `(I# 0#)`. ''But we should have floated the entire call to `indexError` thus'': {{{ False -> lvl_xxx b_ay8 i_ayb }}} with {{{ lvl_xxx b i = indexError @Int b i (I# 0#) }}} Why? Because it makes the expression smaller and moves the error handling code out of the way. Float-out makes some attempt to to this, but it's not right yet. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13144> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #13241: Compile-time flag causing GC to zero evacuated memory
by GHC 08 Feb '17

08 Feb '17

#13241: Compile-time flag causing GC to zero evacuated memory -------------------------------------+------------------------------------- Reporter: tommd | Owner: Type: feature | Status: new request | 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: -------------------------------------+------------------------------------- The `memory` package includes a `ScrubbedBytes` type that scrubs (zeros) the bytestring upon free via a finalizer. The intent with this type is to achieve a common requirement in the cryptographic world that key material is zeroed once it is no longer needed. Sadly, this technique is not useful for many reasons: * Consumers often take bytestrings * Key material often exists as other types such as bytestring, Text in case of passwords>>=KDF, or Integer in the case of home-grown RSA operations. * Scrubbing via a finalizer is clumsy, verbose, and error prone. `memory`'s scrubbing appears to be related to or even have caused a bug with a related library a while back. Note I am rather keen on _not_ arguing about the suitability of Haskell for cryptographic purposes. That's an orthogonal topic to the value of zeroing freed memory. I would like GHC to include a flag (`--zero-evacuated`?) that will cause evacuated memory to be zeroed by the GC. This functionality already exists as a debugging feature to help recognize unused (or misused) memory so I anticipate the actual RTS code change to be minimal. The main question is if GHCHQ agrees this feature is valuable enough to include another flag. Thoughts? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13241> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10635: -fwarn-redundant-constraints should not be part of -Wall
by GHC 07 Feb '17

07 Feb '17

#10635: -fwarn-redundant-constraints should not be part of -Wall -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.11 Component: Compiler | Operating System: Unknown/Multiple (Type checker) | Type of failure: Incorrect Keywords: | warning at compile-time Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- When I compile existing code with GHC-7.11.20150707 I get lot of "redundant constraints" warnings. Generally I think that this warning can be very useful for minimizing constraints, nonetheless there are good reasons not choose minimal constraints for a type signature. E.g. if I have to implement `Data.Map.singleton` I do not need the `Ord k` constraint for the key type. However, I might add it anyway in order to be able to change the implementation in future such that it uses `Ord k` dictionary. Thus I suggest to exclude `-fwarn-redundant-constraints` from `-Wall`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10635> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 38

[GHC] #13143: NOINLINE and worker/wrapper
by GHC 07 Feb '17

07 Feb '17

#13143: NOINLINE and worker/wrapper -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | 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: -------------------------------------+------------------------------------- Currently we do no worker/wrapper on a NOINLINE thing. In `WorkWrap`: {{{ tryWW dflags fam_envs is_rec fn_id rhs | isNeverActive inline_act -- No point in worker/wrappering if the thing is never inlined! -- Because the no-inline prag will prevent the wrapper ever -- being inlined at a call site. }}} But if we have, say, {{{ {-# NOINLINE f #-} f (x,y) = error (show x) g True p = f p g False p = snd p + 1 }}} then strictness analysis will discover `f` is strict, and `g`, but ''because `f` has no wrapper'', the worker for `g` will rebox the thing. So we get {{{ f (x,y) = error (show x) $wg b x y = let p = (x,y) -- Yikes! Reboxing! in case b of True -> f p False -> y + 1 g b p = case p of (x,y) -> $wg b x y }}} Now, in this case the reboxing will float into the `True` branch, an so the allocation will only happen on the error path. But it won't float inwards if there are multiple branches that call `(f p)`, so the reboxing will happen on every call of `g`. Disaster. Solution: do worker/wrapper even on NOINLINE things; but move the NOINLINE pragma to the worker. --------------------------- This actually happens! In `GHC.Arr` we have {{{ {-# NOINLINE indexError #-} indexError :: Show a => (a,a) -> a -> String -> b indexError rng i tp = error (...) index b i | inRange b i = unsafeIndex b i | otherwise = indexError b i "Char" }}} The `inRange` generates multiple alternatives, which the `indexError` is duplicated into, and exactly this phenomenon takes place. Eric (gridaphobe) offered this standalone example {{{ module Err where tabulate :: (Int -> a) -> (Int, Int) -> [Int] tabulate f (l,u) = array (l,u) [l..u] {-# INLINE array #-} array :: (Int, Int) -> [Int] -> [Int] array (l,u) is = [index (l,u) i | i <- is] {-# INLINE index #-} index :: (Int, Int) -> Int -> Int index b@(l,h) i | l <= i && i < h = 0 | otherwise = indexError b i 0 {-# NOINLINE indexError #-} indexError :: (Int, Int) -> Int -> Int -> b indexError rng i tp = error (show rng) }}} Compile this with GHC 8, and shudder at the terrible code we get for `$wtabulate`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13143> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

[GHC] #13216: internal error: stg_ap_pppppp_ret
by GHC 07 Feb '17

07 Feb '17

#13216: internal error: stg_ap_pppppp_ret -------------------------------------+------------------------------------- Reporter: lerkok | Owner: Type: bug | Status: new Priority: normal | 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: -------------------------------------+------------------------------------- We started getting the following from our app; though it's not reliably reproducible: {{{ internal error: stg_ap_pppppp_ret (GHC version 8.0.1 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Abort }}} Unfortunately I cannot share code, nor I can upgrade to GHC 8.0.2 due to work environment restrictions. My apologies for the worst bug report. Neither google nor Trac searches produced anything related. I'm wondering if anybody has seen this, or have any ideas where to look at. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/13216> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

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

07 Feb '17

#1600: Optimisation: CPR the results of IO -------------------------------------+------------------------------------- Reporter: simonmar | Owner: 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 simonpj): Indeed. Start with one or two poster-child examples to show what the goal is; and check they work as expected. Only then go in with nofib. Also this is a long ticket. It would be good to write a decription somewhere (on the wiki page?) of what exactly the patch does. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/1600#comment:59> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0