GHC panic! when unpacking a GADT in GHC >=9.6

changed the description

*** Core Lint errors : in result of Desugar (before optimization) ***
T25672.hs:13:22: warning:
    Application error in type ‘(# isInt_axF ~# 'True, Int# #)’
      Function type = forall (k0 :: RuntimeRep) (k1 :: RuntimeRep).
                      TYPE k0 -> TYPE k1 -> TYPE ('TupleRep '[k0, k1])
      Args = [ZeroBitRep, 'IntRep, isInt_axF ~# 'True, Int#]
    Fun: TYPE k0_10 -> TYPE k1_11 -> TYPE ('TupleRep '[k0_10, k1_11])
      exp_arg_ty: TYPE k0_10
      arg: isInt_axF ~# 'True :: CONSTRAINT ZeroBitRep
    In the RHS of lit :: forall (isInt :: Bool).
                         WrapIntOrWord isInt -> IntOrWord isInt
    In the body of lambda with binder isInt_axF :: Bool
    In the body of lambda with binder ds_dy3 :: WrapIntOrWord isInt_axF
    In a case alternative: (WrapIntOrWord bx_dy5 :: (# (# isInt_axF
                                                          ~# 'True,
                                                          Int# #)
                                                       | (# isInt_axF ~# 'False, Word# #) #))
    In the type of a binder: bx_dy5
    In the type ‘(# (# isInt_axF ~# 'True, Int# #) |
                    (# isInt_axF ~# 'False, Word# #) #)’
    Substitution: <InScope = {isInt_axF}
                   IdSubst   = []
                   TvSubst   = []
                   CvSubst   = []>
*** Offending Program ***
Rec {
boom :: WrapIntOrWord 'True
[LclIdX]
boom
  = (\ (@(isInt_awH :: Bool)) (ds_dy2 :: IntOrWord isInt_awH) ->
       $WWrapIntOrWord @isInt_awH ds_dy2)
      @'True ((\ (ds_dy1 :: Int) -> $WInt ds_dy1) (I# 1#))

lit
  :: forall (isInt :: Bool). WrapIntOrWord isInt -> IntOrWord isInt
[LclIdX[[RecSel]]]
lit
  = \ (@(isInt_axF :: Bool)) (ds_dy3 :: WrapIntOrWord isInt_axF) ->
      case ds_dy3 of wild_00 { WrapIntOrWord bx_dy5 ->
      let {
        ds_dy4 :: IntOrWord isInt_axF
        [LclId]
        ds_dy4
          = case bx_dy5 of bx_dy5 {
              (# _| #) bx_dy6 ->
                case bx_dy6 of bx_dy6 { (# bx_dy8, bx_dy9 #) ->
                Int @isInt_axF @~(bx_dy8 :: isInt_axF ~# 'True) bx_dy9
                };
              (# |_ #) bx_dy7 ->
                case bx_dy7 of bx_dy7 { (# bx_dya, bx_dyb #) ->
                Word @isInt_axF @~(bx_dya :: isInt_axF ~# 'False) bx_dyb
                }
            } } in
      let {
        lit_B1 :: IntOrWord isInt_axF
        [LclId]
        lit_B1 = ds_dy4 } in
      lit_B1
      }
end Rec }

I think the difficulty is that are trying to unpack a sum type that binds constraints, something like:

data WrapIntOrWord i = WrapIntOrWord ( ((i ~# True), Int)  |  ((i ~# False), Word) )

That unboxed sum type has a mixture of TYPE and CONSTRAINT fields and we don't have a good way do that yet.

I'm not quite sure what to do about this. Crashing is bad. Simply declining to unpack might not be great but would be better than crashing.

Any thoughts anyone?

Simply declining to unpack might not be great but would be better than crashing.

Correct me if I'm wrong, but isn't the point of this issue that GHC was already declining to unpack in 9.4.8? (That is what I took away from the Ignoring unusable UNPACK pragma warning reported in the original issue description.) As such, making GHC decline to unpack would be returning to the status quo, which I think would be fine.

I agree that simply refusing constructs like this would be quite reasonable.

Bug is here

-- Given a type already assumed to have been normalized by topNormaliseType,
-- unpackable_type_datacons ty = Just datacons
-- iff ty is of the form
--     T ty1 .. tyn
-- and T is an algebraic data type (not newtype), in which no data
-- constructors have existentials, and datacons is the list of data
-- constructors of T.
unpackable_type_datacons :: Type -> Maybe [DataCon]
unpackable_type_datacons ty
  | Just (tc, _) <- splitTyConApp_maybe ty
  , not (isNewTyCon tc)  -- Even though `ty` has been normalised, it could still
                         -- be a /recursive/ newtype, so we must check for that
  , Just cons <- tyConDataCons_maybe tc
  , not (null cons)      -- Don't upack nullary sums; no need.
                         -- They already take zero bits
  , all (null . dataConExTyCoVars) cons
  = Just cons -- See Note [Unpacking GADTs and existentials]
  | otherwise
  = Nothing

When there is one datacon we can allow equalities, but not if there are more than one. I will make a fix.

removed needs triage label

added Tbug label

added compiler crash label

added Pnormal label

changed milestone to %9.14.1

mentioned in commit 6107f529

mentioned in merge request !13935 (closed)

mentioned in commit 8a91d786

mentioned in commit 9fd364a5

closed with commit b6d5b091

mentioned in commit b6d5b091

Fixed by

commit b6d5b09103dea97351774c5ab34082165504b997
Author: Simon Peyton Jones <simon.peytonjones@gmail.com>
Date:   Thu Feb 13 12:18:31 2025 +0000

    We can't UNPACK multi-constructor GADTs
    
    This MR fixes #25672
    
    See Note [Unpacking GADTs and existentials] in GHC.Types.Id.Make

 compiler/GHC/Core/DataCon.hs                        |  3 +++
 compiler/GHC/Tc/TyCl.hs                             |  2 ++
 compiler/GHC/Types/Id/Make.hs                       | 92 ++++++++++++++++++++++++++++++++++++++++++++++++++----------------
 testsuite/tests/simplCore/should_fail/T25672.hs     | 15 +++++++++++
 testsuite/tests/simplCore/should_fail/T25672.stderr |  6 +++++
 testsuite/tests/simplCore/should_fail/all.T         |  3 +++
 6 files changed, 99 insertions(+), 22 deletions(-)

GHC panic! when unpacking a GADT in GHC >=9.6

Summary

Steps to reproduce

Expected behavior

Environment

Child items ...

Activity