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

[GHC]

#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