[GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect

GHC ghc-devs at haskell.org
Wed Oct 3 09:37:26 UTC 2018


#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


More information about the ghc-tickets mailing list