May 2018 - ghc-tickets

Re: [GHC] #7411: Exceptions are optimized away in certain situations
by GHC 09 May '18

09 May '18

#7411: Exceptions are optimized away in certain situations -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: seq, deepseq, | evaluate, exceptions Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | simplCore/should_fail/T7411 Blocked By: | Blocking: Related Tickets: #5129 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Replying to [comment:30 simonpj]: > > I think we should at least give the other options a fair try. > > Do you have other options in mind? This has bugged us for a decade -- it's why it's called the "state hack". > > Getting perf numbers for compiling everything (incl libraries) with `-fno-state-hack` would give us a bit of data to go on. I'm thinking in two directions here. The first one would be to just throw out the state hack altogether, as you suggested, or at least make `-fno-state-hack` the default and pepper the `fstate-hack` flag with dire warnings. Timing things with and without the state hack shouldn't be a very difficult task, so I suggest I put a bit of time into this. For the second one, let me summarize what I think the core of the problem is: The equational reasoning strategies behind this eta expansion and `seq` are at odds. The eta expansion assumes that floating bottoms around will not make an effective difference (as per fast-and-loose reasoning), but this assumption doesn't hold when `seq` is involved, because `seq` is like this magical backdoor to bottoms. Eta expansion says that `case x of { _ -> f }` is equivalent to `\eta -> case x of { _ -> f eta }`, even if there are bottoms involved. But this breaks when `seq` is involved, because the eta expansion allows the argument to slip past `seq`. So what we would need to fix this "properly" would be a way to mark the relevant code sections as "here be dragons", and make the state hack skip over those. But I suspect this would be a rather invasive change (extending Core with such markers), and detecting such sections correctly could be tricky. Or maybe not, I really don't know. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7411#comment:31> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7411: Exceptions are optimized away in certain situations
by GHC 09 May '18

09 May '18

#7411: Exceptions are optimized away in certain situations -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: seq, deepseq, | evaluate, exceptions Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | simplCore/should_fail/T7411 Blocked By: | Blocking: Related Tickets: #5129 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > I think we should at least give the other options a fair try. Do you have other options in mind? This has bugged us for a decade -- it's why it's called the "state hack". Getting perf numbers for compiling everything (incl libraries) with `-fno- state-hack` would give us a bit of data to go on. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7411#comment:30> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7411: Exceptions are optimized away in certain situations
by GHC 09 May '18

09 May '18

#7411: Exceptions are optimized away in certain situations -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: seq, deepseq, | evaluate, exceptions Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | simplCore/should_fail/T7411 Blocked By: | Blocking: Related Tickets: #5129 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Replying to [comment:26 simonpj]: > I'm not sure it's worth fixing this. It doesn't seem to be harming anyone, an it's not clear how to fix it. OK, so here's what I think. Right now, the simplifier will change the behavior of programs. This is completely unexpected and undocumented, and it's subtle enough to make it all-night debugging session material. I'm a bit uncomfortable with just shrugging this off. Last resort would be to just document the problem (where?) and move on; but I think we should at least give the other options a fair try. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7411#comment:29> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14684: combineIdenticalAlts is only partially implemented
by GHC 09 May '18

09 May '18

#14684: combineIdenticalAlts is only partially implemented -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 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: -------------------------------------+------------------------------------- combineIdenticalAlts commons up branches of case expressions which have the same RHS. However, it is not fully implemented so opportunities to common up branches are missed. For very big case expressions in might impact compilation time but it could be something which is enabled by `-O2`. For example, the `C` and `D` case for `foo` are not commened up but the `A` and `B` case in `foo2` are. {{{ module Foo where data T = A | B | C | D foo x = case x of A -> 0 B -> 1 C -> 2 D -> 2 foo2 x = case x of A -> 2 B -> 2 C -> 0 D -> 1 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14684> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

Re: [GHC] #7411: Exceptions are optimized away in certain situations
by GHC 09 May '18

09 May '18

#7411: Exceptions are optimized away in certain situations -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: seq, deepseq, | evaluate, exceptions Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | simplCore/should_fail/T7411 Blocked By: | Blocking: Related Tickets: #5129 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > I don't see anything problematic about the floating If we eta-expand `lvl_s2Yo` its value goes from possibly-bottom (if there are bottoms in the list, which there are) to definitely non-bottom. As a result `seq# lvl_s2yo e` is optimised to `e`; which is incorrect here (that is precisely the bug reported), but absolutely fine for definite non-values in the first argument. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7411#comment:28> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #7411: Exceptions are optimized away in certain situations
by GHC 09 May '18

09 May '18

#7411: Exceptions are optimized away in certain situations -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: seq, deepseq, | evaluate, exceptions Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | simplCore/should_fail/T7411 Blocked By: | Blocking: Related Tickets: #5129 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Simon, I don't see anything problematic about the floating. It looks to me as though the eta expansion past the `case` is where meaning shifts, but maybe I'm missing something? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7411#comment:27> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #15116: GHC internal error when GADT return type mentions its own constructor name
by GHC 09 May '18

09 May '18

#15116: GHC internal error when GADT return type mentions its own constructor name -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 (Type checker) | Keywords: GADTs, | Operating System: Unknown/Multiple TypeInType | Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Take the following program: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE TypeInType #-} module Bug where data A (a :: k) where MkA :: A MkA }}} On GHC 8.4.2, this is rejected with a sensible error message: {{{ $ /opt/ghc/8.4.2/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:6:12: error: • Data constructor ‘MkA’ cannot be used here (it is defined and used in the same recursive group) • In the first argument of ‘A’, namely ‘MkA’ In the type ‘A MkA’ In the definition of data constructor ‘MkA’ | 6 | MkA :: A MkA | ^^^ }}} On GHC HEAD, however, this causes a GHC internal error: {{{ $ ghc2/inplace/bin/ghc-stage2 Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:6:12: error: • GHC internal error: ‘MkA’ is not in scope during type checking, but it passed the renamer tcl_env of environment: [asv :-> Type variable ‘k’ = k :: *, asw :-> Type variable ‘a’ = a :: k, rqs :-> ATcTyCon A :: forall k. k -> *] • In the first argument of ‘A’, namely ‘MkA’ In the type ‘A MkA’ In the definition of data constructor ‘MkA’ | 6 | MkA :: A MkA | ^^^ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15116> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

Re: [GHC] #7411: Exceptions are optimized away in certain situations
by GHC 09 May '18

09 May '18

#7411: Exceptions are optimized away in certain situations -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: seq, deepseq, | evaluate, exceptions Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | simplCore/should_fail/T7411 Blocked By: | Blocking: Related Tickets: #5129 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Here's what is going on: * After a late float-out pass we get this {{{ lvl_s2Yn [Occ=Once] -- Comes from 'return ()' :: GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, () #) [LclId] lvl_s2Yn = \ (s_a2z6 [Occ=Once, Dmd=<S,U>] :: GHC.Prim.State# GHC.Prim.RealWorld) -> (# s_a2z6, GHC.Tuple.() #) lvl_s2Yo [Occ=Once] :: GHC.Types.IO () [LclId] -- Comes from (('a':undefined) `dslist` return ()) lvl_s2Yo = case go_s2WQ lvl_s2Ym of { __DEFAULT -> lvl_s2Yn `cast` (Sym (GHC.Types.N:IO[0] <()>_R) :: (GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, () #) :: *) ~R# (GHC.Types.IO () :: *)) } main_s2z7 = \ (s_a2yI [Occ=Once, Dmd=<S,U>] :: GHC.Prim.State# GHC.Prim.RealWorld) -> GHC.Prim.seq# @ (GHC.Types.IO ()) @ GHC.Prim.RealWorld lvl_s2Yo s_a2yI }}} So far so good. * But then we see that `lvl_s2Yn` has arity 1 (which it does). And then we eta-expand `lvl_s2Yo`, moving the lambda outside the `case go lvl_s2Ym`, to get {{{ lvl_s2Yo = (\ (eta_B1 [Occ=Once] :: GHC.Prim.State# GHC.Prim.RealWorld) -> case go_s2WQ lvl_s2Ym of { () -> (lvl_s2Yn `cast` ...) eta_B1 }) `cast` ... }}} * Aargh! Now `lvl_s2Yo` is a HNF, not bottom as it should be. And so `seq# lvl_s2Y# x` is (correctly) reduced to `x`. How to avoid this? It's the notorious "state hack" that "justifies" floating the lambda out. The motivation is functions like this: {{{ f :: [Int] -> IO () f xs = print ys >> print xs where ys = reverse xs }}} Without the state hack we get an arity-1 function thus {{{ f = \xs. let ys = reverse xs in \s. case print ys s of (# s' ,_ #) -> print xs s' }}} That's signficantly less efficient than an arity-2 function; but that penalty may be worth paying if the application `(f xs)` is shared. For example: {{{ let fxs = f [1..100] in fxs >> fxs >> fxs }}} In the arity-1 case we'd reverse `[1..100]` once; in the arity-2 case we'd reverse it three times. In practice this doesn't seem to come up much. ------------ I'm not sure it's worth fixing this. It doesn't seem to be harming anyone, an it's not clear how to fix it. The only fix I can think of (apart from abandoning the state hack) would be to restrict the state hack a bit more so that it doesn't apply to an arity-zero binding like `lvl_s2Yo` -- but still does apply to `f` above. But if we did that, then this minor variant of #7411 would still misbehave: {{{ {-# NOINLINE f #-} f2 :: Int -> IO () f2 x = ('a':undefined) `dslist` return () main = evaluate (f2 3) }}} Here I've just given `f` an argument; like `f`above it'll be eta-expanded. Morally, it's the same problem as before, but perhaps it just occurs less often. I'm inclined to focus on other tickets that are causing users actual pain. But it's a long time since I tried measuring the perf cost of simply switching the state hack off altogether. Would anyone like to to just try that? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7411#comment:26> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #14547: Wrong warning by -Wincomplete-patterns
by GHC 09 May '18

09 May '18

#14547: Wrong warning by -Wincomplete-patterns -------------------------------------+------------------------------------- Reporter: YoshikuniJujo | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.2.1 Keywords: incomplete- | Operating System: Linux patterns OverloadedLists | TypeFamilies | Type of failure: Incorrect Architecture: x86 | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Wrong warning occur where I use -Wincomplete-patterns with OverloadedLists and TypeFamilies. {{{#!hs {-# LANGUAGE OverloadedLists #-} {-# LANGUAGE TypeFamilies #-} {-# OPTIONS_GHC -Wall -fno-warn-tabs #-} class Foo f where type It f foo :: [It f] -> f data List a = Empty | a :! List a deriving Show instance Foo (List a) where type It (List a) = a foo [] = Empty foo (x : xs) = x :! foo xs }}} Pattern match(es) are non-exhaustive In an equation for `foo': Patterns not matched: [] -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14547> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

Re: [GHC] #7411: Exceptions are optimized away in certain situations
by GHC 09 May '18

09 May '18

#7411: Exceptions are optimized away in certain situations -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: seq, deepseq, | evaluate, exceptions Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | simplCore/should_fail/T7411 Blocked By: | Blocking: Related Tickets: #5129 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): I think the `-fno-state-hack` is almost certainly a clue, although I'm not exactly sure how it ends up relating in that specific example. What I ''suspect'' is happening (without actually tracing simplification) is roughly this: {{{#!hs evaluate (undefined `seq` return ()) -- ===> inline IO $ \s -> seq# (undefined `seq` IO (\s' -> (# s', () #))) s -- ===> simplify the coercions for my sanity IO $ \s -> seq# (IO $ undefined `seq` \s' -> (# s', () #)) s -- ===> This is where I suspect things go sideways. I believe we generally -- assume that it's okay to eta-expand IO things. IO $ \s -> seq# (IO $ \s'' -> (undefined `seq` (\s' -> (# s', () #))) s'') s }}} We've effectively turned a bottom with an `IO` type into a non-bottom `IO` value that only ''returns'' a bottom. Then the `seq#` ends up going away: {{{#!hs -- ===> beta reduce past seq IO $ \s -> seq# (IO $ \s'' -> undefined `seq` (# s'', () #)) s -- ===> PrelRules.seqRule says we can eliminate seq# for WHNF things IO $ \s -> (# s, IO $ \s'' -> undefined `seq` (# s'', () #)) }}} I imagine the behavior is a bit fragile because it depends on GHC not recognizing that the undefined value is in fact undefined, or at least not recognizing it too early. I suspect the solution is likely to make `-fpedantic-bottoms` go a little further than it currently does, although I don't know enough to say just what. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7411#comment:25> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0