Opened 3 years ago

Closed 3 years ago

Last modified 2 years ago

#10158 closed bug (fixed)

Panic compiling singletons: StgCmmEnv: variable not found

Reported by: trommler Owned by:
Priority: highest Milestone: 8.0.1
Component: Compiler (CodeGen) Version: 7.11
Keywords: Cc: simonmar
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: Compile-time crash Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description

cabal install singletons panics like this with HEAD:

ghc: panic! (the 'impossible' happened)
  (GHC version 7.11.20150313 for x86_64-unknown-linux):
        StgCmmEnv: variable not found
  cobox_a1Job
  local binds for:
  sConst
  sAsTypeOf
  sId
  %:++
  sMap
  sFoldr
  %$
  %$!
  $WLet_1627796109GoSym3KindInference
  $WLet_1627796109GoSym2KindInference
  $WLet_1627796109GoSym1KindInference
  $WLet_1627796109GoSym0KindInference
  $WSeqSym1KindInference
  $WSeqSym0KindInference
  $WFlipSym2KindInference
  $WFlipSym1KindInference
  $WFlipSym0KindInference
  $WConstSym1KindInference
  $WConstSym0KindInference
  $WAsTypeOfSym1KindInference
  $WAsTypeOfSym0KindInference
  $WIdSym0KindInference
  $W:++$###
  $W:++$$###
  $WMapSym0KindInference
  $WMapSym1KindInference
  $WFoldrSym2KindInference
  $WFoldrSym1KindInference
  $WFoldrSym0KindInference
  $WLambda_1627796009Sym3KindInference
  $WLambda_1627796009Sym2KindInference
  $WLambda_1627796009Sym1KindInference
  $WLambda_1627796009Sym0KindInference
  $W:.$$$###
  $W:.$$###
  $W:.$###
  %$1
  sAsTypeOf1
  sConst1
  sFlip1
  sId1
  sSeq1
  a_r1JEg
  sF_s1JFN
  sG_s1JFO
  sA_1627796004_s1JFP

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

Change History (8)

comment:1 Changed 3 years ago by goldfire

Priority: normalhighest

Yikes! I hope I'm not overstating the importance of my library to GHC, but this sounds serious.

Is this reproducible on the 7.10 branch? If so, please set the milestone to 7.10.1.

comment:2 Changed 3 years ago by trommler

Milestone: 7.12.1
Type of failure: None/UnknownCompile-time crash

The 7.10 branch is fine! I tried the 7.10 branch at changeset:d6f5b4cf7cf1e3a8946fe6a77ce68ec96baad8fd and singletons compiles. Setting milestone to 7.12.1

comment:3 Changed 3 years ago by simonpj

I nailed this one. This diff fixes it. It was a missing 'runFlatten'. However I propose not to commit a fix, because Richard's D653 refactors all that code and, I'm 99% certain, fixes the bug in a better way.

I would like D653 to land though. Richard is planning to do that on Monday

Simon

	Modified compiler/typecheck/TcInteract.hs
diff --git a/compiler/typecheck/TcInteract.hs b/compiler/typecheck/TcInteract.hs
index e83709c..4d4b31c 100644
--- a/compiler/typecheck/TcInteract.hs
+++ b/compiler/typecheck/TcInteract.hs
@@ -1420,6 +1420,7 @@ shortCutReduction old_ev fsk ax_co fam_tc tc_args
   | otherwise
   = ASSERT( not (isDerived old_ev) )   -- Caller ensures this
     ASSERT( ctEvEqRel old_ev == NomEq )
+    runFlatten $
     do { (xis, cos) <- flattenManyNom old_ev tc_args
                -- ax_co :: F args ~ G tc_args
                -- cos   :: xis ~ tc_args

comment:4 Changed 3 years ago by goldfire

Simon, do you have a test case I could add to the testsuite as I land D653?

comment:5 Changed 3 years ago by simonpj

I do not. I just looked at the -ddump-ds trace from compiling singletons, noted the missing binding of a coercion, and traced it back to the flattener.

With enough thought I might be able to construct a test case (as might you), but there are so many other things to do too

Simon

comment:6 Changed 3 years ago by Richard Eisenberg <eir@…>

In c1edbdfd9148ad9f74bfe41e76c524f3e775aaaa/ghc:

Do proper depth checking in the flattener to avoid looping.

This implements (roughly) the plan put forward in comment:14:ticket:7788,
fixing #7788, #8550, #9554, #10139, and addressing concerns raised in #10079.
There are some regressions w.r.t. GHC 7.8, but only with pathological type
families (like F a = F a). This also (hopefully -- don't have a test case)
fixes #10158. Unsolved problems include #10184 and #10185, which are both
known deficiencies of the approach used here.

As part of this change, the plumbing around detecting infinite loops has
changed. Instead of -fcontext-stack and -ftype-function-depth, we now have
one combined -freduction-depth parameter. Setting it to 0 disbales the
check, which is now the recommended way to get (terminating) code to
typecheck in releases. (The number of reduction steps may well change between
minor GHC releases!)

This commit also introduces a new IntWithInf type in BasicTypes
that represents an integer+infinity. This type is used in a few
places throughout the code.

Tests in
  indexed-types/should_fail/T7788
  indexed-types/should_fail/T8550
  indexed-types/should_fail/T9554
  indexed-types/should_compile/T10079
  indexed-types/should_compile/T10139
  typecheck/should_compile/T10184  (expected broken)
  typecheck/should_compile/T10185  (expected broken)

This commit also changes performance testsuite numbers, for the better.

comment:7 Changed 3 years ago by goldfire

Resolution: fixed
Status: newclosed

This should take care of it.

comment:8 Changed 2 years ago by thoughtpolice

Milestone: 7.12.18.0.1

Milestone renamed

Note: See TracTickets for help on using tickets.