#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): Sure. The problem in comment:13 is exactly what I explained in my patch (and you also copied it here in comment:30). I get this STG with GHC HEAD, -O0: {{{ f_r1C3 :: Main.T [GblId, Caf=NoCafRefs, Unf=OtherCon []] = CCS_DONT_CARE Main.T2! []; a_r1C4 :: Main.T [GblId, Unf=OtherCon []] = [] \u [] f_r1C3; sat_s1OH :: GHC.Types.Ordering [LclId] = [] \u [] case dataToTag# [a_r1C4] of a'_s1OD { __DEFAULT -> case <# [a'_s1OD 1#] of sat_s1OE [Occ=Once] { __DEFAULT -> case tagToEnum# [sat_s1OE] of { GHC.Types.False -> case a'_s1OD of { __DEFAULT -> GHC.Types.GT []; 1# -> GHC.Types.EQ []; }; GHC.Types.True -> GHC.Types.LT []; }; }; }; }}} Notice that we do `dataToTag# [a_r1C4]` and `a_r1C4` is an updatable CAF. The result is I get `LT` instead of `EQ`. (this is one of the regression tests I added) I get very similar STG (with the same bug) and same results with these configurations: GHC HEAD, GHC 8.2.2, GHC 8.0.2. All tried with -O0, -O1, -O2. I'm guessing that you added a NOINLINE for `cmpT` in comment:14. When I do that I get the right answer with all optimisation settings (GHC HEAD), and that makes sense becuase the arguments are now known to be evaluated and `exprIsHNF` correctly returns `False` for the arguments, so we do case on the args. I don't know how you get incorrect result in the STG shown in comment:14. Could it be that you used an older binary of the test program or something like that? If you give more detailed instructions to reproduce I can take a look. I agree that if the STG in comment:14 is producing wrong result then there's at least one more bug. However I get identical STG when I add NOINLINE aroung `cmpT` (with GHC HEAD, with -O2) and it works as expected. You said you also made `dataToTag#` lazier, but because I get identical STG as you I haven't tried to change the primop laziness (it shouldn't matter in STG). -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15696#comment:31 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler