Panic with -fbyte-code-and-object-code when scrutinising Word8# literals
The following module causes a panic when compiled with -fbyte-code-and-object-code
:
{-# LANGUAGE MagicHash #-}
module M where
import GHC.Prim
blah :: Word8# -> Bool
blah x = case eqWord8# x (wordToWord8# 124##) of
1# -> True
_ -> False
ghc: panic! (the 'impossible' happened)
GHC version 9.5.20221019:
schemeE(StgCase).my_discr
124##8
The panic occurs here in StgToByteCode
:
my_discr alt = case alt_con alt of
DEFAULT -> NoDiscr {-shouldn't really happen-}
DataAlt dc
| isUnboxedTupleDataCon dc || isUnboxedSumDataCon dc
-> NoDiscr
| otherwise
-> DiscrP (fromIntegral (dataConTag dc - fIRST_TAG))
LitAlt l -> case l of
LitNumber LitNumInt i -> DiscrI (fromInteger i)
LitNumber LitNumWord w -> DiscrW (fromInteger w)
LitFloat r -> DiscrF (fromRational r)
LitDouble r -> DiscrD (fromRational r)
LitChar i -> DiscrI (ord i)
_ -> pprPanic "schemeE(StgCase).my_discr" (ppr l)
The issue is that builtin constant folding rules rewrite blah
to
blah :: Word8# -> Bool
blah = \ (x_aub :: Word8#) ->
case x_aub of {
__DEFAULT -> GHC.Types.False;
124##8 -> GHC.Types.True
}
which includes a literal 124##8
alternative that StgToByteCode
does not support.
I haven’t been able to provoke this issue when running GHCi, but I think this is mostly because GHCi adds Breakpoint
ticks that prevent this optimization from occurring. However, once !8307 (closed) lands, it will be possible to write the optimized program directly, in which case GHCi will need to be able to handle these types of case alternatives, anyway.
It looks like !8822 (merged) fixes this, though it is currently marked as a draft.