Marc van Dongen= writes:
>
> While compiling some happy output with 3.00 I came
> across the following:
>
>
> NOTE: Simplifier still going after 4 iterations; bailing out.
>
> NOTE: Simplifier still going after 4 iterations; bailing out.
>
> panic! (the `impossible' happened):
> fun_result_ty: 6 GHC.Int#{-3e-}
> -> GHC.Int#{-3e-}
> -> b_trKC
> -> PolyParse.HappyState{-rq9-} b_trKC c_trKD
> -> [PolyParse.HappyState{-rq9-} b_trKC c_trKD]
> -> c_trKD
>
Thanks for the report, this looks suspiciously similar to the panic
reported by Sven a couple of days ago (I attach Simon's reply to it.)
Bottom line: try compiling the module with -fno-update-analysis and
see if that side steps it.
--Sigbjorn
Simon L Peyton Jones writes:
> > One can play funny games with GHC-3.00 and the following program
> > (a small fragment of a Happy-generated parser):
> >
> > --------------------------------------------------------------------------
> > module Foo ( happyParse ) where
> >
> > action_0 1 = \j tk _ -> action_1 j j tk (HappyState action_1)
> >
> > action_1 3 = error "Bar"
> > action_1 _ = \i tk st@(HappyState action) sts stk -> action (-1) (-1) tk st sts
>(Just i : stk)
> >
> > happyParse = action_0 2 2 '-' (HappyState action_0) [] [] 2
> >
> > newtype HappyState b c =
> > HappyState (Int -> Int -> b -> HappyState b c -> [HappyState b c] -> c)
> > --------------------------------------------------------------------------
>
> Great program! Thanks for isolating it.
>
> Simon: pls add to regression suite
>
> There are two problems. One is a long-standing bit of grubbiness
> in the code generator; hence fun_result_ty panic. I've fixed that
> (still grubbily, I fear).
>
> GHC goes into a loop in the update analyser. Reason: the
> recursive contravariance of HappyState. Consider:
>
> action_1 j j tk (HappyState action_1) sts stk
> = {unfold action_1}
> action_1 (-1) (-1) tk (HappyState action_1) sts (Just j:stk)
> = {unfold action_1 again}
> ...
>
> Neither action_0 nor action_1 is recursive, but infinite unfolding
> can still occur. This can cause the simplifier to loop, though
> on this occasion it doesn't, but only because action_1 is
> considered too big to unfold. But it does make the update analyser
> loop, for some obscure reason. It wouldn't surprise me if the
> strictness analyser looped too, but it doesn't.
>
> For some reason there's no flag to switch off the update analyser.
> It does very little good anyway, so just switch it off by force
> in ghc/driver/ghc.lprl (look for -fupdate-anal).
>
> I've known about the possibility of looping in the simpifier for some time, but
> never seen it in a real program. I have no idea how to spot it in a clean way,
> and without disabling lots of useful inlining. (I prevent looping mainly by
> treating letrec carefully.) Ideas welcome
>
> Simon
>
