#8892 closed bug (fixed)

Ghc panics (variable not found)

Reported by: jwlato Owned by:
Priority: normal Milestone: 7.8.1
Component: Compiler Version: 7.8.1-rc2
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: Compile-time crash Test Case:
Blocked By: Blocking:
Related Tickets: Differential Revisions:

Description

When attempting to compile a module with ghc-7.8-RC2, using the flags --ghc-options=-j8 -O2 -Werror, I encountered this error:

    ghc: panic! (the 'impossible' happened)
  (GHC version 7.8.0.20140228 for x86_64-unknown-linux):
  StgCmmEnv: variable not found
    foldlM'_loop{v i1iSV} [lid]
    local binds for:

followed by about 1100 bindings (none of are the binding in question). Omitting the -j flag makes no difference. Building -O0 succeeds.

I don't have a standalone test case, and it's not clear to me how to make one as I have no idea what's causing this. I'll try to narrow it down, but if anyone could suggest some flags to twiddle or some other factor to adjust I'd appreciate it. I'm suspecting that it's a function referenced from inlining something vector-related.

Attachments (2)

Broken.hs (345 bytes) - added by jwlato 15 months ago.
Piecewise.hs (2.9 KB) - added by jwlato 15 months ago.

Download all attachments as: .zip

Change History (10)

comment:1 Changed 15 months ago by simonpj

John, the first thing is to add -dcore-lint and compile everything from scratch. I bet that shows something.

I vaguely remember someone reporting a bug to do with ghc -jN but it's hard to search for.

Simon

comment:2 Changed 15 months ago by jwlato

Thanks Simon, with -dcore-lint I see *many* warnings like INLINE binder is (non-rule) loop breaker:, but they seem so common (and some are clearly unrelated) that I don't think it's relevant. In the module that errors, I see only this:

*** Core Lint errors : in result of Simplifier ***
<no location info>: Warning:
    [in body of letrec with binders a125_ajLr3 :: GHC.Prim.State#
                                                    (Control.Monad.Primitive.PrimState
                                                       (GHC.ST.ST s2_ajLm9))
                                                  -> (# GHC.Prim.State#
                                                          (Control.Monad.Primitive.PrimState
                                                             (GHC.ST.ST s2_ajLm9)),
                                                        () #)]
    foldlM'_loop_ajLpg
      :: Data.Vector.Fusion.Stream.Monadic.SPEC
         -> GHC.Types.Int
         -> GHC.Types.Int
         -> GHC.ST.ST s2_ajLm9 GHC.Types.Int
    [LclId, Arity=4, Str=DmdType] is out of scope
<no location info>: Warning:
    [in body of letrec with binders a125_ajLr3 :: GHC.Prim.State#
                                                    (Control.Monad.Primitive.PrimState
                                                       (GHC.ST.ST s2_ajLm9))
                                                  -> (# GHC.Prim.State#
                                                          (Control.Monad.Primitive.PrimState
                                                             (GHC.ST.ST s2_ajLm9)),
                                                        () #)]
    foldlM'_loop_ajLpg
      :: Data.Vector.Fusion.Stream.Monadic.SPEC
         -> GHC.Types.Int
         -> GHC.Types.Int
         -> GHC.ST.ST s2_ajLm9 GHC.Types.Int
    [LclId, Arity=4, Str=DmdType] is out of scope

followed by the simplifier output. And indeed, there is a case foldlM'_loop_ajLpg something of, but no binding for foldlM'_loop_ajLpg6. At least I've found the offending function now, so I may be able to isolate a test case.

comment:3 Changed 15 months ago by simonpj

Yes, I'm sorry about the loop-breaker warnings -- you can safely ignore those.

GHC should never produce an out-of-scope variable, so this is clearly a bug.

Maybe you can try this:

  • Revert to -O not -O2
  • Remove individual optimsations, eg -fno-full-laziness, -fno-spec-constr etc
  • Remove code from the module being compiled so that it is as small as possible.
  • And then compile with -dverbose-core2core -ddump-occur-anal -ddump-inlinings -ddump-rule-rewrites (as well as -dcore-lint and save the output somewhere I can see it.

Best of all would be to get a test case I can reproduce here.

Thanks

Simon

comment:4 Changed 15 months ago by jwlato

I've made a test case that I hope is small enough you can work with. This has dependencies on the vector and vector-space packages. There are two files, Piecewise.hs and Broken.hs. To trigger the bug, you need to first compile Piecewise.hs and install it to ghc's package database, then attempt to compile Broken.hs via ghc -O Broken.hs. Trying to compile Broken.hs when ghc can find Piecewise.hs works properly for me. I've put a repo on github with a minimal cabal file also, https://github.com/JohnLato/ghc-8892

I can trigger the bug with any optimization level except -O0.

Piecewise.hs defines instance (AdditiveGroup (poly a), Ord a) => AdditiveGroup (Piecewise poly a), with {-# SPECIALISE instance AdditiveGroup (Piecewise Scale Double) #-}. That SPECIALIZE instance pragma, and the INLINE negateV pragma, both seem required to trigger this. I haven't attempted to simplify the definition of ^+^ at all, I'll continue with that tomorrow.

Changed 15 months ago by jwlato

Changed 15 months ago by jwlato

comment:5 Changed 15 months ago by simonpj

Excellent! I can reproduce it. Thanks

comment:6 Changed 15 months ago by Simon Peyton Jones <simonpj@…>

In 87bbc69c40d36046492d754c8d7ff02c3be6ce43/ghc:

Make sure we occurrence-analyse unfoldings (fixes Trac #8892)

For DFunUnfoldings we were failing to occurrence-analyse the unfolding,
and that meant that a loop breaker wasn't marked as such, which in turn
meant it was inlined away when it still had occurrence sites.  See
Note [Occurrrence analysis of unfoldings] in CoreUnfold.

This is a pretty long-standing bug, happily nailed by John Lato.

comment:7 Changed 15 months ago by simonpj

  • Status changed from new to merge

Got it. Your test case was terrific, thank you.

It's a very long-standing bug, just hard to provoke. I don't know how to make a test case for it, so I'll just close.

However, Austin, please merge this.

Simon

comment:8 Changed 14 months ago by thoughtpolice

  • Milestone set to 7.8.1
  • Resolution set to fixed
  • Status changed from merge to closed

Merged.

Note: See TracTickets for help on using tickets.