#10176: Invalid core generated with GHC 7.10 RC3 -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by hvr): Fyi, I scripted up a test and git-bisected between RC2 and RC3, and the 6f46fe15af397d448438c6b93babcdd68dd78df8 commit is the one where `shake- test oracle test` starts failing -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10176#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#10176: Invalid core generated with GHC 7.10 RC3 -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by NeilMitchell): Running {{{ghc -outputdir obj -O -ddump-simpl Buggy.hs}}} produces the output: {{{ case (\ _ [Occ=Dead] _ [Occ=Dead, OS=OneShot] -> case lvl_r1lh unit_XyJ of wild2_00 { }) `cast` ((<()>_R -> Sym (GHC.Types.NTCo:IO[0] _R)) ; Sym (Buggy.NTCo:ReaderT[0] <()>_R _R) :: (() -> GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, GHC.Prim.Any #)) ~R# ReaderT () GHC.Prim.Any) of _ [Occ=Dead] { } }}} Ignoring the cast (which I don't think is relevant) that is: {{{ case (\_ _ -> ...) of {} }}} I've reduced the bug so the code only depends on {{{Prelude}}}, requiring no external libraries. I have not been able to remove the requirement for two modules. The partial implementation of {{{ReaderT}}} is taken from the {{{transformers}}} library then specialised to {{{IO}}}. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10176#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#10176: Invalid core generated with GHC 7.10 RC3 -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by NeilMitchell): That's quite different since (after inlining a few bits): {{{ $wlvl $wlvl = \ _ -> error "here" m = $wlvl void# }}} So {{{m}}} evaluates to {{{_|_}}} in GHC 7.8 which means a case with no alternatives is correct. However, in 7.10 the scrutinee evaluates to a lambda, not {{{_|_}}}, so no alternatives is wrong. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10176#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#10176: Invalid core generated with GHC 7.10 RC3 -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): Eek. This seems to be my fault: Note the `CallArity=2`. And indeed, with `-fno-call-arity` this passes; same for your test case. :-( -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10176#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#10176: Invalid core generated with GHC 7.10 RC3 -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): Ok, I think here is what happens, at least in my smaller test case: 1. Call Arity determines that `error1Arg` is always called with two arguments. Hence `CallArity=2`. This is correct. 2. The simplifier tries to eta-expand `error1Arg` to take two arguments. This fails in `mkEtaWW` in `CoreArity`, where we have this comment: {{{ -- This *can* legitmately happen: -- e.g. coerce Int (\x. x) Essentially the programmer is -- playing fast and loose with types (Happy does this a lot). -- So we simply decline to eta-expand. Otherwise we'd end up -- with an explicit lambda having a non-function type }}} 3. But still, the `Arity` field is updated. 4. Since it has `Arity=2`, `exprIsHNF (error1Arg @ _ ())` is true, and the simplifier does strange things. So maybe the solution is to ''not'' update `Arity` with the result from Call Arity, but instead let eta-expansion happen and update `Arity` with the manifest arity after eta expansion. I’ll try that. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10176#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#10176: Invalid core generated with GHC 7.10 RC3 -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): Or not quite. I think I did find a bug, but not the only one: With the change in Phab:D747, my small example and your example, when merged into one module, no longer fail. But your original test case still fails with Call Arity, and compiles fine without. There still seems to be some fishiness with Call Arity and `undefined`. /me continues brooding over the Core. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10176#comment:11 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#10176: Invalid core generated with GHC 7.10 RC3 -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): I simplified your code slightly, removing everything about type classes: {{{ module Buggy(buggy) where import Errors newtype ReaderT r a = ReaderT { runReaderT :: r -> IO a } p = liftReaderT (return ()) m >>> k = ReaderT $ \r -> do runReaderT m r; runReaderT k r liftReaderT :: IO a -> ReaderT r a liftReaderT m = ReaderT (const m) {-# NOINLINE buggy #-} buggy :: (() -> Bool) -> () -> Bool -> IO () buggy fun unit bool = runReaderT ( (if bool then liftReaderT $ print () else p) >>> (if fun unit then error2Args unit unit >>> p else p)) () }}} still exhibits the problem. Removing the `newtype`, or turning it into a `data` makes the problem go away. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10176#comment:13 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#10176: Invalid core generated with GHC 7.10 RC3 -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): I think I found it. The problem is a bad interaction between Call Arity and simplification based on the strictness result. Consider this code: {{{ e x = error "foo" x ... case e () () of {} ... }}} The strictness signature for `e` will be `b`. Note the `b`: This means: „If you give me one argument, then I’m going to be ⊥, which is true. The Call Arity for `e` is `2`, which is true: `e` is always called with two arguments. So the simplifier phase following Call Arity will replace with {{{ e x y = error "foo" x y }}} At the same time, the simplifier will replace `e () ()` with `e ()`. After all, both are known to be bottom. The result (after inlining) is the bogus {{{ ... case (\y -> error "foo" x y) of {} ... }}} that we see. The simplifier looks at the `b` flag of the strictness analyzer in `mkArgInfo`, replacing `isBotRes result_info` with `False` makes the problem go away, but that is probably not the solution. Zapping strictness analysis when Call Arity finds something is probably also a bad idea. Maybe the best solution is to limit the number found by call arity to the number of arguments in the strictness signature, if the strictness signature ends in a `b`. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10176#comment:15 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#10176: Invalid core generated with GHC 7.10 RC3 -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by NeilMitchell): To assess what does happen in this error case, I augmented the code to be: {{{ buggy fun unit bool = runReaderT (do if bool then liftReaderT $ print () else pure () if fun unit then do error2Args unit unit; liftReaderT $ print "here2" else pure () ) () :: IO () }}} Running {{{do print "here1"; buggy (const True) () True; print "here3"}}} gives {{{here1; here3}}}. GHC has used the presence of error to remove the {{{here2}}}, but since the code just falls out of the end of the function it returns back and still prints {{{here3}}}. That's a nasty result, and pretty much describes what happens in the full test case (I'm in the middle of compiling, and then suddenly I stop and do the thing that comes after compiling). -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10176#comment:17 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#10176: Invalid core generated with GHC 7.10 RC3 -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by hvr): I can confirm that 1cc46b1fd5ce794d3a1519c65dcf4aded317598b + phab:D747 allows `shake-test oracle test` to succeed! -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10176#comment:19 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#10176: Invalid core generated with GHC 7.10 RC3 -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: nomeata Type: bug | Status: patch Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"5119e097b5cc08d1e6e94529d8c6d7c654a28829/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="5119e097b5cc08d1e6e94529d8c6d7c654a28829" Test case for #10176 originally provided by Neil Mitchell. Despite what he observed, I can observe the bug even with all in one module. }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10176#comment:21 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#10176: Invalid core generated with GHC 7.10 RC3 -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: nomeata Type: bug | Status: merge Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by nomeata): * status: patch => merge Comment: Pushed. hvr, you said you wanted this to be in 7.10, so marking it as merge. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10176#comment:23 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#10176: Invalid core generated with GHC 7.10 RC3 -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: nomeata Type: bug | Status: closed Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): Thanks. Note that the test case is quite useless without the lint (but doesn’t hurt either so just leave it like it is). -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10176#comment:25 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler