#15114: ghc 8.4.1 optimizes True to False -------------------------------------+------------------------------------- Reporter: elaforge | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by adamse: Old description:

Ok, here's a short module:

{{{#!hs import qualified Control.Exception as Exception

main :: IO () main = do unserialize putStrLn "all is well"

unserialize :: IO Char unserialize = if definitelyTrue then do return 'a' else do Exception.evaluate (error "wrong place")

{-# NOINLINE definitelyTrue #-} definitelyTrue :: Bool definitelyTrue = True }}}

When compiled with -O on 8.4.1, this should print "wrong place". Without -O, or with 8.4.2, or if True can be inlined, or without evaluate, all is well. I can reproduce this on OS X 10.13.4.

This could be related to a known bug with Exception.evaluate in 8.4.1: #3930

New description: Ok, here's a short module: {{{#!hs import qualified Control.Exception as Exception main :: IO () main = do unserialize putStrLn "all is well" unserialize :: IO Char unserialize = if definitelyTrue then do return 'a' else do Exception.evaluate (error "wrong place") {-# NOINLINE definitelyTrue #-} definitelyTrue :: Bool definitelyTrue = True }}} When compiled with -O on 8.4.1, this should print "wrong place". Without -O, or with 8.4.2, or if True can be inlined, or without evaluate, all is well. I can reproduce this on OS X 10.13.4. This could be related to a known bug with Exception.evaluate in 8.4.1: #13930 -- -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15114#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#15114: ghc 8.4.1 optimizes True to False -------------------------------------+------------------------------------- Reporter: elaforge | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): The title is misleading IMO: it's not that the `else` branch is taken instead of the `then` branch, but rather that the `evaluate` effect floats/leaks out of the inactive control flow path. I.e. the `a` branch is still taken; it's just that the `error` exception is triggered before we can reach it. Here's a modified example which better shows what I mean: {{{#!hs import qualified Control.Exception as Exception import Debug.Trace main :: IO () main = do c <- unserialize putStrLn "all is well" print c unserialize :: IO Char unserialize = if definitelyTrue then do putStrLn "HEY" return 'a' else do Exception.evaluate (traceShow "wrong place" 'b') {-# NOINLINE definitelyTrue #-} definitelyTrue :: Bool definitelyTrue = True }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15114#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#15114: ghc 8.4.1 optimizes True to False -------------------------------------+------------------------------------- Reporter: elaforge | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I've confirmed that the commit that fixed this was ac1ade1ad25f145ab27219c4fb8366e982658873 (`Fix seq# case of exprOkForSpeculation`). -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15114#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#15114: ghc 8.4.1 lifts errors out of if then else -------------------------------------+------------------------------------- Reporter: elaforge | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Thanks. That makes me sure it relates to #5129. Don't worry, I'll add it as a regression test myself, shortly. Thanks for boiling it down. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15114#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#15114: ghc 8.4.1 lifts errors out of if then else -------------------------------------+------------------------------------- Reporter: elaforge | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | simplCore/should_run/T15114 Blocked By: | Blocking: Related Tickets: #5129 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * testcase: => simplCore/should_run/T15114 * resolution: => fixed * related: => #5129 -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15114#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler