ghc master (8.1.20161206) panics with assertion failure with devel2 flavor and -O

ghc version: 41ec722d with assertion that fails in #12926 (closed) commented out

{-# LANGUAGE TypeFamilies #-}

module Numeric.Polynomial.Log () where

class AdditiveGroup v where
  (^+^) :: v -> v -> v
  negateV :: v -> v
  (^-^) :: v -> v -> v
  v ^-^ v' = v ^+^ negateV v'
  
class AdditiveGroup v => VectorSpace v where
  type Scalar v :: *
  (*^) :: Scalar v -> v -> v
  
  
data Poly1 a = Poly1 a a

data IntOfLog poly a = IntOfLog !a !(poly a)

instance Num a => AdditiveGroup (Poly1 a) where
    {-# INLINE (^+^) #-}
    {-# INLINE negateV #-}
    Poly1 a b ^+^ Poly1 a' b' = Poly1 (a + a') (b + b')
    negateV (Poly1 a b) = Poly1 (negate a) (negate b)
    
    
instance (AdditiveGroup (poly a), Num a) => AdditiveGroup (IntOfLog poly a) where
    {-# INLINE (^+^) #-}
    {-# INLINE negateV #-}
    IntOfLog k p ^+^ IntOfLog k' p' = IntOfLog (k + k') (p ^+^ p')
    negateV (IntOfLog k p) = IntOfLog (negate k) (negateV p)
    {-# SPECIALISE instance Num a => AdditiveGroup (IntOfLog Poly1 a) #-}
    
instance (VectorSpace (poly a), Scalar (poly a) ~ a, Num a) => VectorSpace (IntOfLog poly a) where
    type Scalar (IntOfLog poly a) = a
    s *^ IntOfLog k p = IntOfLog (s * k) (s *^ p)

ghc: panic! (the 'impossible' happened)
  (GHC version 8.1.20161206 for x86_64-unknown-linux):
        ASSERT failed!
  $dAdditiveGroup_aIU
  Call stack:
      CallStack (from HasCallStack):
        prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1114:58 in ghc:Outputable
        callStackDoc, called at compiler/utils/Outputable.hs:1163:22 in ghc:Outputable
        assertPprPanic, called at compiler/stgSyn/CoreToStg.hs:967:78 in ghc:CoreToStg
  Call stack:
      CallStack (from HasCallStack):
        prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1114:58 in ghc:Outputable
        callStackDoc, called at compiler/utils/Outputable.hs:1118:37 in ghc:Outputable
        pprPanic, called at compiler/utils/Outputable.hs:1161:5 in ghc:Outputable
        assertPprPanic, called at compiler/stgSyn/CoreToStg.hs:967:78 in ghc:CoreToStg

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

Trac metadata

Trac field	Value
Version	8.1
Type	Bug
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture

changed weight to 5

added Tbug Trac import labels

changed milestone to %8.2.1

changed weight to 10

I can also reproduce this with 9bcc4e33,

$ ghc -O ~/hi.hs
[1 of 1] Compiling Numeric.Polynomial.Log ( /home/ben/hi.hs, /home/ben/hi.o )
ghc: panic! (the 'impossible' happened)
  (GHC version 8.1.20161207 for x86_64-unknown-linux):
	StgCmmEnv: variable not found
  $dAdditiveGroup_aIP
  local binds for:
  *^
  ^+^
  negateV
  ^-^
  $p1VectorSpace
  $fAdditiveGroupPoly1
  $WIntOfLog
  $fAdditiveGroupIntOfLog_$cnegateV
  $fAdditiveGroupIntOfLog_$c^+^
  $fAdditiveGroupPoly1_$c^-^
  $fAdditiveGroupPoly1_$cnegateV
  $fAdditiveGroupPoly1_$c^+^
  w_s12P
  ww_s12Q
  ww1_s12R
  ww2_s12S
  ww3_s12T
  dt_s12U
  Call stack:
      CallStack (from HasCallStack):
        prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1116:58 in ghc:Outputable
        callStackDoc, called at compiler/utils/Outputable.hs:1120:37 in ghc:Outputable
        pprPanic, called at compiler/codeGen/StgCmmEnv.hs:137:9 in ghc:StgCmmEnv

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

Trac metadata

Trac field	Value
Priority	normal → highest
Component	Compiler → Compiler (CodeGen)

added code generation label

It looks like the failing assertion is this,

lookupBinding :: IdEnv HowBound -> Id -> HowBound
lookupBinding env v = case lookupVarEnv env v of
                        Just xx -> xx
                        Nothing -> ASSERT2( isGlobalId v, ppr v ) ImportBound

If I comment out this assertion there are other failures on the same code.

It sounds very much like uniques are overflowing. We are working on confirming this.

Here is a patch fixing some of the fragility of the current unique setup.

Trac metadata

Trac field	Value
Differential revisions	- → D2844

#12899 (closed) - related

mentioned in commit 0d213c18

closed

According to pacak the fix in #12944 (closed) has fixed the issue.

Trac metadata

Trac field	Value
Resolution	Unresolved → ResolvedFixed

This ticket is NOT related to unique identifier and it still fails with fix in place.

Oh dear, yes, you are quite right. That patch address #12899 (closed), not this issue. My apologies!

I know exactly what is going on here, thanks to the nice example in the Description. It's a long-standing bug in the implementation of {-# SPECIALISE instance ... #-}. Core Lint nails it instantly.

I'll look at this early next week.

Simon

mentioned in commit 1a4c04b1

mentioned in commit 0a18231b

Also relevant (the commit message should say #12944 (closed) not #12444 (closed)):

revision="c48595eef2bca6d91ec0a649839f8066f269e6a4"
Never apply worker/wrapper to DFuns

While fixing Trac #12444 I found an occasion on which we applied
worker/wrapper to a DFunId.  This is bad: it destroys the magic
DFunUnfolding.

This patch is a minor refactoring that stops this corner case
happening, and tidies up the code a bit too.

Trac metadata

Trac field	Value
Test case	- → deSugar/should_compile/T12944

reopened

changed milestone to %8.0.3

The main patch here, in #12944 (closed), is a candidate for 8.0.3 since it fixes an outright bug.

So I'll switch to merge status. But it may depend (in a trivial and easily-avoidable way) on an earlier commit

05d233e8e18284cb98dc320bf58191ba4d86c754 Move InId/OutId to CoreSyn

added 1 deleted label

changed milestone to %8.2.1

At this point it is rather unlikely that there will be an 8.0.3. Re-milestoning.

closed

removed 1 deleted label

mentioned in issue #13547

added compiler crash label

added Phighest label