#15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): That's terrible! The following all produce the same (wrong) restul {{{ S.fromList (map f [ () | _ <- [1..10] ]) -- T2,T2 S.fromList [f (), f ()] -- T2,T2 S.fromList [f (), f (), f()] -- T2,T2 }}} However this works fine {{{ f () `S.insert` (f () `S.insert` S.empty) }}} The comparison operations generated by `deriving` look ok to me. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15696#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Ah, so it turns out we have a special case in CorePrep (which runs after simplifications) about `dataToTag#`, and we generate a case expression around its argument after all the simplifications. It's explained in `Note [dataToTag magic]` in CorePrep, and I can see in STG that it works as expected: {{{ lvl_r6ru = \u [] f_r6rt (); lvl1_r6rv = CCS_DONT_CARE :! [lvl_r6ru []]; main2 = \u [] case case lvl_r6ru of sat_s6xD { __DEFAULT -> dataToTag# [sat_s6xD]; } of a#_s6xE { __DEFAULT -> case case lvl_r6ru of sat_s6xF { __DEFAULT -> dataToTag# [sat_s6xF]; } of ... }}} So perhaps this is not because we get tag of a thunk. I don't know why not inlining `getTag` fixes this. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15696#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Here's an example which doesn't depend on any code from `containers`. It also makes the derived `Ord` code explicit: {{{#!hs {-# LANGUAGE MagicHash #-} module Main where import qualified Data.Foldable as Foldable import GHC.Exts (dataToTag#, tagToEnum#, (==#), (<#)) main :: IO () main | not_ordered a b = print $ Foldable.foldl' (flip wumbo) (singleton a) b | otherwise = pure () where {-# NOINLINE f #-} f () = T2 {-# NOINLINE a #-} a = f () {-# NOINLINE b #-} b = [f ()] data T = T1 | T2 | T3 | T4 | T5 | T6 | T7 | T8 | T9 deriving (Eq, Show) instance Ord Main.T where compare a b = case dataToTag# a of a' -> case dataToTag# b of b' -> if tagToEnum# (a' <# b') :: Bool then LT else if tagToEnum# (a' ==# b') :: Bool then EQ else GT data Set a = Bin !a !(Set a) !(Set a) | Tip deriving Show not_ordered :: Ord a => a -> [a] -> Bool not_ordered _ [] = False not_ordered x (y : _) = x >= y wumbo :: Ord a => a -> Set a -> Set a wumbo x0 = go x0 x0 where go :: Ord a => a -> a -> Set a -> Set a go orig _ Tip = singleton orig go orig x t@(Bin y l r) = case compare x y of LT -> error "not used here" GT -> Bin y l (go orig x r) EQ -> t {-# INLINE wumbo #-} singleton :: a -> Set a singleton x = Bin x Tip Tip }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15696#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Apologies, I meant to mention in comment:6 what `wumbo` actually is: it's a stripped down version of `insert` intended to highlight that it appears to behave differently between GHC 8.4.3 and 8.6.1. The semantics of `wumbo` differs from that of `insert`, but here is the important bit: {{{ $ /opt/ghc/8.4.3/bin/ghc -O2 -fforce-recomp Bug.hs && ./Bug [1 of 1] Compiling Main ( Bug.hs, Bug.o ) Linking Bug ... Bin T2 Tip Tip $ /opt/ghc/8.6.1/bin/ghc -O2 -fforce-recomp Bug.hs && ./Bug [1 of 1] Compiling Main ( Bug.hs, Bug.o ) Linking Bug ... Bin T2 Tip (Bin T2 Tip Tip) }}} GHC 8.4.3's answer is definitely the correct one, since the only way you'd get 8.6.1's answer is by hitting the `GT` case of `wumbo` (which shouldn't happen if you're comparing `T2` to `T2`). -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15696#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.6.1 => 8.6.2 -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15696#comment:10 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by monoidal): Here's a smaller version. `ghc T15696 && ./T15696` prints `EQ` correctly, `ghc -O T15696 && ./T15696` prints `LT`. {{{ #!hs {-# LANGUAGE MagicHash #-} module Main where import GHC.Exts (dataToTag#, tagToEnum#, (==#), (<#)) main :: IO () main = print $ compare a T2 where {-# NOINLINE f #-} f = T2 {-# NOINLINE a #-} a = f data T = T1 | T2 | T3 | T4 | T5 | T6 | T7 | T8 | T9 deriving (Eq, Show, Ord) {- instance Ord Main.T where compare a b = case dataToTag# a of a' -> case dataToTag# b of b' -> if tagToEnum# (a' <# b') :: Bool then LT else if tagToEnum# (a' ==# b') :: Bool then EQ else GT -} }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15696#comment:12 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Omer, might you look at this. With `-ddump-stg` I see {{{ Main.cmpT :: forall a1 a2. a1 -> a2 -> GHC.Types.Ordering [GblId, Arity=2, Caf=NoCafRefs, Str=, Unf=OtherCon []] = [] \r [a2_s3tf b_s3tg] case case a2_s3tf of sat_s3th [Occ=Once] { __DEFAULT -> dataToTag# [sat_s3th]; } of a'_s3ti { __DEFAULT -> case case b_s3tg of sat_s3tj [Occ=Once] { __DEFAULT -> dataToTag# [sat_s3tj]; } of b'_s3tk { __DEFAULT -> case <# [a'_s3ti b'_s3tk] of { __DEFAULT -> case ==# [a'_s3ti b'_s3tk] of { __DEFAULT -> GHC.Types.GT []; 1# -> GHC.Types.EQ []; }; 1# -> GHC.Types.LT []; }; }; }; }}} which looks right. In another variant (I made `dataToTag#` lazy) I saw {{{ Main.cmpT :: forall a1 a2. a1 -> a2 -> GHC.Types.Ordering [GblId, Arity=2, Caf=NoCafRefs, Str=, Unf=OtherCon []] = [] \r [a2_s3tf b_s3tg] case a2_s3tf of x1_s3th [Occ=Once] { __DEFAULT -> case dataToTag# [x1_s3th] of a'_s3ti { __DEFAULT -> case b_s3tg of x2_s3tj [Occ=Once] { __DEFAULT -> case dataToTag# [x2_s3tj] of b'_s3tk { __DEFAULT -> case <# [a'_s3ti b'_s3tk] of { __DEFAULT -> case ==# [a'_s3ti b'_s3tk] of { __DEFAULT -> GHC.Types.GT []; 1# -> GHC.Types.EQ []; }; 1# -> GHC.Types.LT []; }; }; }; }; }; }}} But both stubbornly return `LT` instead of `EQ`. This must be a code-gen or RTS issue. I have not looked at the Cmm. Might you do so? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15696#comment:14 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): The fact that using `dataToTag#` directly produces incorrect results is perhaps not terribly surprising, giving that it [http://git.haskell.org/ghc.git/blob/21efbc7599e39ec93b8b13b7d7b84811226e6f6f... must always be applied to an evalauted argument] (see `Note [dataToTag#]`). The fact that the version using `getTag` breaks is more worrisome, since `getTag` actually forces its argument (with a bang pattern). -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15696#comment:16 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): It's also worth noting that you can trim `T` down to just two constructors: {{{#!hs {-# LANGUAGE MagicHash #-} module Main where import GHC.Base (getTag) import GHC.Exts (tagToEnum#, (==#), (<#)) main :: IO () main = print $ compare a T2 where {-# NOINLINE f #-} f = T2 {-# NOINLINE a #-} a = f data T = T1 | T2 deriving (Eq, Show) instance Ord Main.T where compare a b = case getTag a of a' -> case getTag b of b' -> if tagToEnum# (a' <# b') :: Bool then LT else if tagToEnum# (a' ==# b') :: Bool then EQ else GT }}} And the bug will still trigger. (If you define `data T = T2`, then the bug will go away.) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15696#comment:18 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

Didn't we just recently start using some pointer tagging for types with more than 7 constructors? I'm thinking something could be a drop off in

#15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by heisenbug): Replying to [comment:11 dfeuer]: that code. Nope. That code is not ripe yet. This summer was very busy for me. Another thing: With Peter I discovered last Haskell eXchange (Oct. 2017) that enumerated types with derived `Ord` instances could use `getTag` to derive a constant-time `compare` (and `(==)` too). We were not aware of this optimization already being in the codebase. We'll surely revisit this. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15696#comment:20 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5196 Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): One other thing to note is, as other commenters above already mentioned, this is _not_ a new bug! The bug was there since years. I think something else (maybe changes in simplifier) revealed it. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15696#comment:22 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5196 Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Thinking about this more. I think the only case where we can actually avoid entering the argument of `dataToTag#` is when the argument is a static closure. For anything else (a dynamic closure, a CAF) we need to enter it. I don't know how often people do `dataToTag# C` (for some constructor `C`), perhaps it's fine to always enter it. If it is then we can remove the special case for `dataToTag#` in CorePrep and in the codegen (in Cmm) we can just enter the argument. If we decide to do that then perhaps we should also revisit the `getTag` and remove the bang pattern on its argument. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15696#comment:24 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5196 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Ah... I am not entirely wrong, but I am partly wrong, because types with many constructors get tagged 1 when evaluated. I think we should at least be able to add a rule that recognizes when `dataToTag#` is used with a type with only a few constructors: see the logic in the `cgAlts gc_plan bndr (AlgAlt tycon) alts` case in `compiler/codeGen/StgCmmExpr.hs`. That way we only have to call `getConstrTag` when 1. The type is unknown, 2. The type has too many constructors, or 3. The tag bits are 0. I imagine you can do this quite easily by copying a bit of the `splitTyConApp_maybe` logic from `tagToEnumRule` to `dataToTagRule` in `PrelRules.hs` and adding a `DataToTagUsingTagOp` to supplement `DataToTagOp`. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15696#comment:26 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5196 Wiki Page: | -------------------------------------+------------------------------------- Changes (by sgraf): * cc: sgraf (added) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15696#comment:28 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5196 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Before deciding on a ''solution'', let's record what the ''problem'' is. The original thinking was this. * `dataToTag#` is a primop, so it has no business doing anything as complicated as evaluating its argument; we already have `case` expressions that the code-gen knows how to compile. * So `dataToTag#` expects an evaluated argument; in fact, stronger than that, it expects a pointer ''to the data value itself'', so that it can extract the tag directly from the info table. * But if it so happens that the value in question already ''is'' evaluated, that's a waste. Example {{{ f x = case x of y -> ...(dataToTag# y)... }}} It seems a bit silly for `dataToTag#` to re-evaluate `y`. * Hence, in `CorePrep` (see `Note [dataToTag magic]`) we add a `case` around the argument to `dataToTag#` ''unless'' the argument is already evaluated. * The "already-evaluated" test is `exprIsHNF`. * '''But alas''', while `exprIsHNF` guarantees that the thing will evaluate in O(1) time, it does ''not'' guarantee that we have a pointer to the data value itself. Omer accurately diagnoses this problem in the Note in his draft Phab:D5196: {{{ Note [Always introduce case around dataToTag# arg] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ We used to only generate a case expression around dataToTag# argument when it's not known to be evaluated (checked with `exprIsHNF`), but this is incorrect. Here's an example: data T = T1 | T2 main = print (I# (dataToTag# a)) where {-# NOINLINE f #-} f = T2 {-# NOINLINE a #-} a = f `f` is a static closure f_r1zz :: Main.T [GblId, Caf=NoCafRefs, Unf=OtherCon []] = CCS_DONT_CARE Main.T2! []; but `a` is an _updatable_ CAF! a_r1zA :: Main.T [GblId, Unf=OtherCon []] = [] \u [] f_r1zz; An updatable CAF is not in HNF (entering the closure does the `newCAF()` stuff and updates the closure with an IND_STATIC, the usual CAF evaluation routines), but according to `exprIsHNF` `a` is! }}} * I thought of having a more conservative test in `CorePrep`. But the rot goes further. Consider this, from `Note [dataToTag magic]` {{{ data T = MkT !Bool f v = case v of MkT y -> dataToTag# y }}} We certainly know that `y` will be evaluated, because `MkT` is a strict constructor. But does it guarantee to point directly to the data value? No! The case-to-let transformation in the Simplifier (`Simplify.doCaseToLet`) uses `exprIsHNF` and hence will drop the eval on `MkT`'s argument for things like Omer's `a` binding. And that is right in a way: the argument to `MkT a` certainly isn't bottom! But nor does it point to the data value. So that is a problem. But I think there is another. Look in comment:13 and comment:14. Here we have the extra `case` expressions correctly inserted, but we ''still'' get the wrong answer. '''So I think there may be ''two'' bugs'''. I'd like to understand the second before looking for a fix. Omer: could you investigate why comments 13 and 14 go wrong? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15696#comment:30 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5196 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj):

I get this STG with GHC HEAD, -O0:

That's what you get for monoidal's code in comment:18. Note the missing eval before the `dataToTag#`. But it is ''not'' what you get for the code in comment:13. The evals are there, as comment:14 shows. And yet we get the wrong answer. But why? That is the second bug. Can you see why that happens? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15696#comment:32 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5196 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Oops sorry. I'd modified the code slightly! Try this {{{ {-# LANGUAGE MagicHash #-} module Main where import GHC.Exts (dataToTag#, tagToEnum#, (==#), (<#)) import GHC.Base ( getTag ) main :: IO () main = print $ cmpT a T2 where {-# NOINLINE f #-} f = T2 {-# NOINLINE a #-} a = f data T = T1 | T2 | T3 | T4 | T5 | T6 | T7 | T8 | T9 -- deriving (Eq, Show, Ord) cmpT a b = case getTag a of a' -> case getTag b of b' -> if tagToEnum# (a' <# b') :: Bool then LT else if tagToEnum# (a' ==# b') :: Bool then EQ else GT }}} Compile with -O and run. It prints `LT` when it should print `EQ`. But the evals are there! -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15696#comment:34 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5196 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj):

Are you maybe confused because in the STG dump you also see the STG for cmpT? It's actually inlined in main so the top-level for cmpT is not used.

That is exactly what I was doing. Thanks! I backed up some more to look at comment:6, which does not have a top- level no-inline CAF. I see this: {{{ $sgo_r5Tk :: Main.T -> Main.T -> Main.Set Main.T -> Main.Set Main.T [GblId, Arity=3, Str=, Unf=OtherCon []] = sat-only [] \r [orig_s5Wj ds_s5Wk ds1_s5Wl] case ds1_s5Wl of wild_s5Wm [Occ=Once] { Main.Bin y_s5Wn l_s5Wo [Occ=Once] r_s5Wp [Occ=Once] -> case case ds_s5Wk of sat_s5Wq [Occ=Once] { __DEFAULT -> dataToTag# [sat_s5Wq]; } of a'_s5Wr { __DEFAULT -> case dataToTag# [y_s5Wn] of b'_s5Ws { __DEFAULT -> case <# [a'_s5Wr b'_s5Ws] of { __DEFAULT -> ... }}} Here we take apart a `Bin`, and call `dataToTag#` on the contents; and because of the `exprIsHNF` stuff there is no guarantee that the argument to `Bin` points directly to the data value. But in looking at this I found something else! In coment:6 there is no top-level CAF with a NOINLINE, so how do things go wrong. Here's how. * We start with {{{ thk = f () g x = ...(case thk of v -> Bin v Tip Tip)... }}} So far so good; the argument to `Bin` (which is strict) is evaluated. * Now we do float-out. And in doing so we do a reverse binder-swap (see `Note [Binder-swap during float-out]` in `SetLevels`) thus {{{ g x = ...(case thk of v -> Bin thk Nil Nil)... }}} The goal of the reverse binder-swap is to allow more floating -- and it does! We float the `Bin` to top level: {{{ lvl = Bin thk Tip Tip g x = ...(case thk of v -> lvl))... }}} * Now you can see that the argument of `Bin`, namely `thk`, points to the thunk, not to the value as it did before; and that gives rise to the bug. Is this wrong? Not really. We are still guaranteed that the argument to `Bin` in `lvl` will be evaluated (by that `case thk`) before `lvl` is used. But we are no longer guaranteed that the argument to `Bin` points directly to the evaluated value. So now I understand. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15696#comment:36 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5196 Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Right, fixing this in Cmm is also what I suggested in comment:24. I think two key questions are: - Can we optimise this? That is, can we know for certain that the argument of a `dataToTag#` points directly to a value (without going through blackholes or other indirections like IND_STATIC)? - Is this worth optimising? Unless the answer to both of those is yes, then I think it makes sense to do this in Cmm (when compiling the primop). Then we can remove a bunch of notes about `getTag` and hacks in CorePrep, and simplify `getTag` to `getTag = dataToTag#`. I think we can also update the primop as `can_fail = False`. It seems to me that Core is not the right place to answer (1). Even in STG I don't know if we can answer that question with certainty. I think it's doable in Cmm where we know about "lambda form" of ids (`LambdaFormInfo`) which tells us about how to enter an object. If "lambda form" of an argument is `LFCon` then we optimise, otherwise we enter. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15696#comment:38 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5196 Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Right, agreed that looking at tag bits would work for small types. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15696#comment:40 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5196 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Ah, I see what you're saying. The 0 tag is handled by the `case` wrapper (or C-- equivalent). So for small types, we don't need any extra test; we can just use the tag bits directly. I suppose also that my attempt to use tag bits for unknown types is more trouble than it's worth; we should just assume that those have too many constructors. As for the type-driven rewriting, I think we basically have two options: 1. Do it in PrelRules. I think this requires something like the `dataToTagWith#` primop I mentioned earlier. 2. Do it sometime later (tidy core, core prep, or lowering to STG). This lets us stick with `dataToTag#` throughout core2core, which is nice, but I don't know enough to know if any of those make sense or where/how to slot in the rule. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15696#comment:42 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5196, Wiki Page: | Phab:D5201 -------------------------------------+------------------------------------- Comment (by osa1): So we mention this "optimisation" without describing what it is, and I realized that that may cause some confusion so let's define it. By "optimisation" I mean that in some cases when compiling `dataToTag#` we can avoid entering the argument, because we already know enough about it. - In compile time we sometimes know that the argument is definitely some constructor `C`. For example, in the example in comment:43, we know that `f` is `T2`, so we should be able to compile `dataToTag# f` to `1#`. Another example is `case foo of X -> ... dataToTag# foo ...`. Note that we currently (with GHC 8.6 and HEAD) don't do this for `f` in comment:43, even with -O2. However with Phab:D5201 `f` in comment:43 is optimised to `1#` in Cmm level. The case expression is optimised in all versions. (both diffs preserve Core transformations and rules, so anything optimised at Core level by GHC HEAD will still be optimised) (I don't know why `dataToTag# f` in comment:43 is not optimised in Core level, but perhaps that can be tracked in another ticket) - In compile time we sometimes know that a value is already evaluated, but we don't know specifics (i.e. which constructor it is). For example, in a pattern match, a variable binding a strict field should be evaluated. Another example is `let !foo = f x in ... dataToTag# foo ...`. In these cases we should be able to avoid entering the argument. There are a few problems with this: First, as #14677 demonstrates, we sometimes fail to tag values properly. So for example if a strict field's type is small, we still can't look at tag bits, we need to read the info table. Second, the analysis for this should be more strict than the current `exprIsHNF` or `isEvaldUnfolding` (see Note [Always introduce case around dataToTag# arg] in comment:30 for what goes wrong otherwise). However, we currently don't have an analysis for this, and I don't know how easy it'd be to implement in Core (remember that we don't know about CAFs in Core until CorePrep, and this information is necessary for this analysis). I don't know if going into the trouble of implementing a new analysis in Core just for this purpose is worth it. - For all other cases we need to enter the argument in runtime. If the argument is a small type then we can look at the tag bits, otherwise we read the info table. In other words, case (1) is when we know the constructor of the argument in compile time, case (2) is when we don't know the constructor, but we know that the argument is already evaluated, case (3) is when we don't know anything about the argument. Looking at the tag bits in (3) is currently only done by Phab:D5201, but it could be easily added to other implementations. (2) is currently only done by GHC 8.6 (and HEAD), but it's done incorrectly (thus this ticket). I think we should avoid this at least for now. (1) Is done best in Phab:D5201, because we check lambda form of the argument in Cmm, which optimises some code that escapes Core optimisations. However, I think we should be able to improve simplifier somehow to optimise `dataToTag# f` in comment:43. We can track this in another ticket. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15696#comment:44 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5196, Wiki Page: | Phab:D5201 -------------------------------------+------------------------------------- Comment (by simonpj): Comments about Phab:D5201. I'm not looking at the details yet (it's just a draft), but * I think this is the Right Place to deal with `dataToTag#`. Bravo. * The known-constructor case surely will be handled in the simplifier; if not now then soon. Handling it here is not wrong, but probably unnecesssary. * The thing that we CAN ONLY handle here is {{{ ...(case x of y { A -> blah DEFAULT -> ....(dataToTag# y)... }}} Here we know that `y` really points to the value, so `dastaToTag#` does not need to do a redundant eval. However I have just realised that this optimisation is available for '''any''' case expression, not just `dataToTag#`. Consider {{{ ...(case x of y { A -> blah DEFAULT -> ....(case y of B -> blah2 C -> blah3 )... }}} Here we know that `y` is fully evaluated and points to the final value; that's the promise of the outer case expression. So we can directly test y's tag bits without worrying that it might be unevaluated, need to build a return point and info table etc. Ha! I'm not sure how common this is. But perhaps it is worth a separate ticket. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15696#comment:46 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5196, Wiki Page: | Phab:D5201 -------------------------------------+------------------------------------- Comment (by osa1): Great, I think we're on the same page. I'm finalizing Phab:D5201. Currently stuck on a let/app invariant invalidation (Core lint error) when I mark `dataToTag#` as can't fail (`can_fail = False`). -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15696#comment:48 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5196, Wiki Page: | Phab:D5201 -------------------------------------+------------------------------------- Comment (by simonpj):

Simon, what do you think about marking dataToTag# as can't fail?

It makes sense to me to do so -- but it's an unforced change. It's not so marked today, primops.txt.pp even says why {{{ {- Note [dataToTag#] ~~~~~~~~~~~~~~~~~~~~ The dataToTag# primop should always be applied to an evaluated argument. The way to ensure this is to invoke it via the 'getTag' wrapper in GHC.Base: getTag :: a -> Int# getTag !x = dataToTag# x But now consider \z. case x of y -> let v = dataToTag# y in ... To improve floating, the FloatOut pass (deliberately) does a binder-swap on the case, to give \z. case x of y -> let v = dataToTag# x in ... Now FloatOut might float that v-binding outside the \z. But that is bad because that might mean x gets evaluated much too early! (CorePrep adds an eval to a dataToTag# call, to ensure that the argument really is evaluated; see CorePrep Note [dataToTag magic].) Solution: make DataToTag into a can_fail primop. That will stop it floating (see Note [PrimOp can_fail and has_side_effects] in PrimOp). It's a bit of a hack but never mind. }}} Are we good to go if you don't make this change? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15696#comment:50 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5196, Wiki Page: | Phab:D5201 -------------------------------------+------------------------------------- Comment (by osa1): I understand why it's currently marked as `can_fail`, but if my understanding is correct we should be able to mark it as `can_fail = False` now. I'm curious why that's causing problems. Also, as shown in comment:48, the code is actually better with `can_fail = False`.

Are we good to go if you don't make this change?

I tried to validate now without `can_fail = False`. I'm getting a segfault in haddock (when building docs during validate), then in the test suite haddock perf tests are failing. Other tests are passing. I'll debug. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15696#comment:52 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5196, Wiki Page: | Phab:D5201 -------------------------------------+------------------------------------- Comment (by osa1): Well because this transformation \z. case x of y -> let v = dataToTag# y in ... ==> \z. case x of y -> let v = dataToTag# x in ... is not a problem anymore. Although I now realize that floating `v` outsize of `\z` is still a problem, because that'd mean evaluating `x` more eagerly. So I think first part of the note isn't relevant anymore, but second part (floating out) is. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15696#comment:54 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5196, Wiki Page: | Phab:D5201 -------------------------------------+------------------------------------- Comment (by osa1): Interestingly, if I revert the Cmm bits and always introduce a case on dataToTag# args in CorePrep I can validate. Patch is [https://github.com/osa1/ghc/commit/1b9bd4769c2c70b23ef8739aba116f9d18628b00 here]. I'll compare the differences in generated code in this branch and Phab:D5201. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15696#comment:56 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5196, Wiki Page: | Phab:D5201 -------------------------------------+------------------------------------- Comment (by simonpj): I'm confused. You report a set-fault in comment:55; but now you say it's ready for review. How did you fix it? What is the new design? It's hard to review the patch without understanding the thinking. Thanks! -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15696#comment:58 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5196, Wiki Page: | Phab:D5201 -------------------------------------+------------------------------------- Comment (by simonpj): The `dataToTag#` saga has revealed several things, which I'd like to summarise here. * We have been guilty of mixing up two things: * A ''semantic'' property, namely that an expression, or variable, is guaranteed to be non-bottom. For example, given {{{ data T = MkT !Int f (MkT y) = ...y... }}} in the body of `f`, we know that `y` is non-bottom. * A ''representational'' propery, that a variable is bound to a heap pointer that (a) points directly to an evaluated heap-allocated value (e.g. a cons cell), and (b) is properly tagged, for data constructors with small enough tags. The representational property implies the semantic property, ''but not vice versa''. For example, in the above code, are we guaranteed that `y` (being the strict field of `MkT` is bound to a properly-tagged pointer to an `Int`? I used to think yes, but [https://ghc.haskell.org/trac/ghc/ticket/15696#comment:36 this example] (look at the bullets in that comment) shows that the answer is NO. My conclusion: we should keep the two properties separate. The Simplifier can maintain the first; but the second is much more fragile, and is the business of the code generator alone. * We have never implemented #14626, but it's pretty easy to do so provided we focus our attention on the code generator. The example there is {{{ f x = case x of y Red -> Green DEFAULT -> y }}} The resturn contract of `case` specifies that `y` is bound to a properly-tagged pointer directly to the value; The code generator can remember this fact, in its environment; and simply ''return'' `y` in the DEFAULT branch rather than ''entering'' it. * `exprOkForSpeculation` finishes with this case (in `app_ok`) {{{ _other -> isUnliftedType (idType fun) -- c.f. the Var case of exprIsHNF || idArity fun > n_val_args -- Partial apps || (n_val_args == 0 && isEvaldUnfolding (idUnfolding fun)) -- Let-bound values }}} I think the final disjunct is wrong, becuase it is fragile. Consider {{{ case x of y { DEFAULT -> ...y.... } }}} In that branch, is `y` ok-for-speculation? It looks so, because it has an evald unfolding (`OtherCon`). But the binder-swap transformation performed by FloatOut transforms it to {{{ case x of y { DEFAULT -> ...x.... } }}} and `x` is NOT ok-for-spec. So the binder-swap transformation might invalidate invariants. This is pretty obscure in practice, but I think we can make the compiler simpler and more correct by deleting those two lines. I think it will have zero effect because `exprOkForSpecuation` is seldom if ever called on expressions of lifted type. * Only two primops (currently) evaluate a lifted-type argument: `SeqOp` and `DataToTagOp`. The former has a special case in `app_ok` (in `exprOkForSpeculation` and the latter should too. * Once all this is done, the hack of making `DataToTagOp` have `can_fail=True` can be dispensed with. * We have related loose ends in #14677 and #15155. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15696#comment:60 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #14677, #15155 | Differential Rev(s): Phab:D5196, Wiki Page: | Phab:D5201 -------------------------------------+------------------------------------- Changes (by osa1): * related: => #14677, #15155 -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15696#comment:62 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: osa1 Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #14677, #15155 | Differential Rev(s): Phab:D5196, Wiki Page: | Phab:D5201 -------------------------------------+------------------------------------- Changes (by bgamari): * owner: (none) => osa1 Comment: Omer will investigate. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15696#comment:64 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: osa1 Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #14677, #15155 | Differential Rev(s): Phab:D5196, Wiki Page: | Phab:D5201 -------------------------------------+------------------------------------- Comment (by Ömer Sinan Ağacan ): In [changeset:"ac977688523e5d77eb6f041f043552410b0c21da/ghc" ac977688/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ac977688523e5d77eb6f041f043552410b0c21da" Fix dataToTag# argument evaluation See #15696 for more details. We now always enter dataToTag# argument (done in generated Cmm, in StgCmmExpr). Any high-level optimisations on dataToTag# applications are done by the simplifier. Looking at tag bits (instead of reading the info table) for small types is left to another diff. Incorrect test T14626 is removed. We no longer do this optimisation (see comment:44, comment:45, comment:60). Comments and notes about special cases around dataToTag# are removed. We no longer have any special cases around it in Core. Other changes related to evaluating primops (seq# and dataToTag#) will be pursued in follow-up diffs. Test Plan: Validates with three regression tests Reviewers: simonpj, simonmar, hvr, bgamari, dfeuer Reviewed By: simonmar Subscribers: rwbarton, carter GHC Trac Issues: #15696 Differential Revision: https://phabricator.haskell.org/D5201 }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15696#comment:66 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: osa1 Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #14677, #15155 | Differential Rev(s): Phab:D5196, Wiki Page: | Phab:D5201 -------------------------------------+------------------------------------- Comment (by osa1): Simon, you said that we can remove `can_fail=True` for `dataToTag#` after removing various hacks (in comment:60), and I also used to think that this should be the case, but thinking about this more I think `dataToTag#` should stay as `can_fail=True`. The reason is because `dataToTag#` evaluates the argument and returns an unboxed value, so I think these two expressions calls should have the same value: {{{ exprOkForSpeculation `dataToTag# foo` exprOkForSpeculation `case foo of x -> 1#` -- note: foo is lifted }}} Looking at the code I see that the latter returns `False` (because the scrutinee is lifted), so for the former to return false we need to mark `dataToTag#` as `can_fail = True`. Does this make sense? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15696#comment:68 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: osa1 Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #14677, #15155 | Differential Rev(s): Phab:D5196, Wiki Page: | Phab:D5201 -------------------------------------+------------------------------------- Comment (by osa1): OK, that makes sense, thanks. Moving on, I'm now trying to understand an assertion in `FloatIn` which is triggered when I make the `can_fail` change and update `ok_app` so that `dataToTag#` is never OK for speculation. The assertion that fails is this: (in FloatIn.hs) {{{ fiExpr _ to_drop (_, AnnLit lit) = ASSERT( null to_drop ) Lit lit }}} The definition that triggers it: {{{ $wclosureTypeHeaderSize_s75y [InlPrag=NOUSERINLINE[2]] :: ClosureType -> Int# [LclId, Arity=1, Str=] $wclosureTypeHeaderSize_s75y = \ (w_s75u :: ClosureType) -> case dataToTag# @ ClosureType w_s75u of a#_a4k2 [Dmd=] { __DEFAULT -> join { $j_s6vr [Dmd=] :: Int# [LclId[JoinId(0)], Str=m] $j_s6vr = case w_s75u of lwild_s6yB { __DEFAULT -> case a#_a4k2 of a#_a4jU [Dmd=] { __DEFAULT -> case w_s75u of lwild_s6yA { __DEFAULT -> case a#_a4k2 of a#_X4Ml [Dmd=] { __DEFAULT -> case w_s75u of lwild_s6vm { __DEFAULT -> case a#_a4k2 of a#_X4Mq [Dmd=] { __DEFAULT -> 1# }; AP_STACK -> 2# } }; AP -> 2# } }; THUNK_SELECTOR -> 2# } } in case <# a#_a4k2 15# of lwild_s6vx { __DEFAULT -> case a#_a4k2 of b#_a4k3 [Dmd=] { __DEFAULT -> case <# 20# a#_a4k2 of lwild_s6vu { __DEFAULT -> 2#; 1# -> jump $j_s6vr } }; 1# -> jump $j_s6vr } } }}} At one point `fiExpr` comes across this expression: {{{ case a#_a4k2 :: Int# of a#_X4Mq [Dmd=] { __DEFAULT -> 1# } }}} with an empty "to drop" list. At this point we try to float the case inside the alternative (happens in first `AnnCase` alternative of `fiExpr`), but body of the alternative is a literal so the assertion is triggered. Questions: - What's wrong with seeing a literal when floating stuff inwards? Why not just introduce case/let around it? - There should be some code somewhere that's supposed to ensure that this assertion is not triggered, but I can't find it. - Why did simplifier not remove this case expression? It does no work (the scrutinee is unlifted and binder is not used) but it's somehow not eliminated by the simplifier pass right before FloatIn. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15696#comment:70 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: osa1 Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #14677, #15155 | Differential Rev(s): Phab:D5196, Wiki Page: | Phab:D5201 -------------------------------------+------------------------------------- Comment (by osa1):

That is indeed a mystery. Is the code you are showing the output of the simplifier?

The code I showed is the input of `FloatIn` when a file is compiled with `-O`. The full command to reproduce (after building stage 1): {{{ "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O0 -H64m -Wall -this-unit-id ghc-heap-8.7 -hide-all-packages -i -ilibraries /ghc-heap/. -ilibraries/ghc-heap/dist-install/build -Ilibraries/ghc-heap /dist-install/build -ilibraries/ghc-heap/dist-install/build/./autogen -Ilibraries/ghc-heap/dist-install/build/./autogen -Ilibraries/ghc-heap/. -optP-include -optPlibraries/ghc-heap/dist- install/build/./autogen/cabal_macros.h -package-id base-4.12.0.0 -package- id ghc-prim-0.5.3 -package-id rts -Wall -XHaskell2010 -XNoImplicitPrelude -O -no-user-package-db -rtsopts -Wno-deprecated-flags -Wnoncanonical-monad-instances -odir libraries/ghc-heap/dist- install/build -hidir libraries/ghc-heap/dist-install/build -stubdir libraries/ghc-heap/dist-install/build -dynamic-too -c libraries/ghc- heap/./GHC/Exts/Heap/ClosureTypes.hs -o libraries/ghc-heap/dist- install/build/GHC/Exts/Heap/ClosureTypes.o -dyno libraries/ghc-heap/dist- install/build/GHC/Exts/Heap/ClosureTypes.dyn_o }}}

Can you give instructions to reproduce (maybe make a wip/ branch)?

Committed code to `wip/T15696`. Note that -ddump-simpl-iterations is not printing Core right before `FloatIn` so you need some extra prints to be able to trace this. I'm currently using [https://gist.githubusercontent.com/osa1/9755f7d7238a3757cfee0b37a183a6d8/raw... this] patch for that. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15696#comment:72 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: osa1 Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #14677, #15155 | Differential Rev(s): Phab:D5196, Wiki Page: | Phab:D5201 -------------------------------------+------------------------------------- Comment (by osa1): Thanks Simon, Re 1, the primop is already marked as strict: {{{ strictness = { \ _arity -> mkClosedStrictSig [evalDmd] topRes } }}} Re 2, I already removed the bang pattern in Phab:D5201. I think you need a git pull. Re 3, both (1) and (2) are already done so this should've worked? I'll implement 4 and update. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15696#comment:74 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: osa1 Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #14677, #15155 | Differential Rev(s): Phab:D5196, Wiki Page: | Phab:D5201 -------------------------------------+------------------------------------- Comment (by osa1): I did (4) and tried to validate. There are 4 regressions. 2 of them are perf, the other 2 are tests with checks on -ddump-simpl output. They're all basically the same problem: worker/wrapper results change slightly after the patch, and worker functions take more boxed params. Here's an example (T10482). Original program is this: {{{ {-# LANGUAGE BangPatterns #-} {-# LANGUAGE TypeFamilies #-} module T10482 where data family Foo a data instance Foo (a, b) = FooPair !(Foo a) !(Foo b) newtype instance Foo Int = Foo Int foo :: Foo ((Int, Int), Int) -> Int -> Int foo !f k = if k == 0 then 0 else if even k then foo f (k-1) else case f of FooPair (FooPair (Foo n) _) _ -> n }}} `$wfoo` originally: {{{ Rec { -- RHS size: {terms: 19, types: 4, coercions: 0, joins: 0/0} T10482.$wfoo [InlPrag=NOUSERINLINE[2], Occ=LoopBreaker] :: GHC.Prim.Int# -> GHC.Prim.Int# -> GHC.Prim.Int# [GblId, Arity=2, Caf=NoCafRefs, Str=, Unf=OtherCon []] T10482.$wfoo = \ (ww_s2Qy :: GHC.Prim.Int#) (ww1_s2QG :: GHC.Prim.Int#) -> case ww1_s2QG of wild_X1v { __DEFAULT -> case GHC.Prim.remInt# wild_X1v 2# of { __DEFAULT -> ww_s2Qy; 0# -> T10482.$wfoo ww_s2Qy (GHC.Prim.-# wild_X1v 1#) }; 0# -> 0# } end Rec } }}} after the patch (`wip/T15696`): {{{ Rec { -- RHS size: {terms: 22, types: 7, coercions: 3, joins: 0/0} T10482.$wfoo [InlPrag=NOUSERINLINE[2], Occ=LoopBreaker] :: Foo Int -> GHC.Prim.Int# -> GHC.Prim.Int# [GblId, Arity=2, Caf=NoCafRefs, Str=, Unf=OtherCon []] T10482.$wfoo = \ (ww_s2Qs :: Foo Int Unf=OtherCon []) (ww1_s2Qz :: GHC.Prim.Int#) -> case ww1_s2Qz of wild_X1l { __DEFAULT -> case GHC.Prim.remInt# wild_X1l 2# of { __DEFAULT -> case ww_s2Qs `cast` (T10482.D:R:FooInt0[0] ; T10482.N:R:FooInt[0] :: Foo Int ~R# Int) of { GHC.Types.I# ww3_s2QD -> ww3_s2QD }; 0# -> T10482.$wfoo ww_s2Qs (GHC.Prim.-# wild_X1l 1#) }; 0# -> 0# } end Rec } }}} The difference is that the first argument is now boxed `Int` instead of `Int#` as before. I think the reason for this change is this: originally evaluation of `ww_s2Qs` happens after `remInt# wild_X1l 2#`, but if we pass `ww_s2Qs` unboxed that'd mean evaluating it before `remInt#`. This is possible if at least one of those expressions are OK-for-speculation. `remInt#` is not OK-for-speculation because it can fail. `ww_s2Qs` was previously (without `wip/T15696`) OK-for- speculation, but we just made `app_ok` more strict by removing a disjunct which was actually holding for this expression: - `n_val_args == 0` holds because it has no args - `isEvaldUnfolding (idUnfolding fun)` apparently also somehow holds. I don't know how exactly, but I'm guessing that because of the strictness annotation on the data con field we give this id `evaldUnfolding`. Other 3 regressions are also of similar nature (worker function with less unboxing). What to do? I think it's correct to consider the data con field as strict here and pass an unboxed value to the worker. While we may not actually have a tagged value there (or even an evaluated one! e.g. #14677, #15155), the programmer indicated that it's fine to evaluate the field eagerly. As long as we don't expect (in the generated code) evaluated or tagged value it's fine. So perhaps we should not do the change in `ok_app`. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15696#comment:76 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: osa1 Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #14677, #15155 | Differential Rev(s): Phab:D5196, Wiki Page: | Phab:D5201 -------------------------------------+------------------------------------- Comment (by osa1): I'm probably missing the big picture, but I think it makes sense to give evaluated things `evaldUnfolding` and if that breaks something else then we should fix that something else. In (3) of comment:60, perhaps the thing to fix is the binder-swapping transform rather than the id unfolding, so that it avoids swapping binders with different evaluated-ness (or maybe only avoid it if doing so will break the let/app invariant -- not sure how hard would it be to check this though). I don't know enough about demand analysis to comment on Secondly. I'll try it. Re Thirdly, the demand type does not make too much sense to me (how can an id have strict demand but unused cardinality? Sounds like a hack to make some transformations possible) but I can see how the current code changes cardinality incorrectly. I'll update. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15696#comment:78 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: osa1 Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #14677, #15155 | Differential Rev(s): Phab:D5196, Wiki Page: | Phab:D5201, Phab:D5226 -------------------------------------+------------------------------------- Changes (by bgamari): * differential: Phab:D5196, Phab:D5201 => Phab:D5196, Phab:D5201, Phab:D5226 Comment: I gave Secondly from comment:77 a try while waiting for GHC 8.4.4 builds. The result is Phab:D5226. However, the approach presented does seem a bit odd since the demand resulting from demand analysis is still conservative; we merely make up for this conservatism in worker-wrapper. However, this doesn't help other (hypothetical) consumers of demand analysis. Perhaps it would be good to open a ticket to ensure we don't forget about this limitation. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15696#comment:80 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: osa1 Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #14677, #15155 | Differential Rev(s): Phab:D5196, Wiki Page: | Phab:D5201, Phab:D5226 -------------------------------------+------------------------------------- Comment (by osa1): Just an update before I forget where I had left: the performance regression in `wip/T15696` is fixed by any of these: - Revert change in `app_ok` general case, don't give case binders `evaldUnfolding` in `simplAlts` (first suggestion in comment:77) - Revert change in `app_ok` general case, disable binder swapping of case bidners and scrutinee. Both validate, but I don't have nofib results yet. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15696#comment:82 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: osa1 Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #14677, #15155 | Differential Rev(s): Phab:D5196, Wiki Page: | Phab:D5201, Phab:D5226 -------------------------------------+------------------------------------- Changes (by asr): * cc: asr (added) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15696#comment:86 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: osa1 Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #14677, #15155 | Differential Rev(s): Phab:D5196, Wiki Page: | Phab:D5201, Phab:D5226 -------------------------------------+------------------------------------- Comment (by simonpj): Simon will look at the lint error on `wip/T15696` -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15696#comment:88 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: osa1 Type: bug | Status: closed Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect result | Test Case: at runtime | codeGen/should_run/T15696_1, | T15696_2, T15696_3 Blocked By: | Blocking: Related Tickets: #14677, #15155 | Differential Rev(s): Phab:D5196, Wiki Page: | Phab:D5201, Phab:D5226 -------------------------------------+------------------------------------- Changes (by simonpj): * status: patch => closed * testcase: => codeGen/should_run/T15696_1, T15696_2, T15696_3 * resolution: => fixed Comment: Ben, Omer: I believe I have finally finished this ticket, as promised. Do check my work! But, optimistically, I'm going to close it. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15696#comment:90 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: osa1 Type: bug | Status: closed Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect result | Test Case: at runtime | codeGen/should_run/T15696_1, | T15696_2, T15696_3 Blocked By: | Blocking: Related Tickets: #14677, #15155 | Differential Rev(s): Phab:D5196, Wiki Page: | Phab:D5201, Phab:D5226 -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"d77501cd5b9060e38acd50e11e0c5aae89d75b65/ghc" d77501cd/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d77501cd5b9060e38acd50e11e0c5aae89d75b65" Improvements to demand analysis This patch collects a few improvements triggered by Trac #15696, and fixing Trac #16029 * Stop making toCleanDmd behave specially for unlifted types. This special case was the cause of stupid behaviour in Trac #16029. And to my joy I discovered the let/app invariant rendered it unnecessary. (Maybe the special case pre-dated the let/app invariant.) Result: less special-case handling in the compiler, and better perf for the compiled code. * In WwLib.mkWWstr_one, treat seqDmd like U(AAA). It was not being so treated before, which again led to stupid code. * Update and improve Notes There are .stderr test wibbles because we get slightly different strictness signatures for an argumment of unlifted type: rather than for Int# rather than for Int }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15696#comment:92 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: osa1 Type: bug | Status: closed Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: fixed | Keywords: | DemandAnalysis Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect result | Test Case: at runtime | codeGen/should_run/T15696_1, | T15696_2, T15696_3 Blocked By: | Blocking: Related Tickets: #14677, #15155 | Differential Rev(s): Phab:D5196, Wiki Page: | Phab:D5201, Phab:D5226 -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => DemandAnalysis -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15696#comment:94 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler