[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