Opened 5 years ago

Closed 5 years ago

#9102 closed bug (fixed)

Assertion failure in CoreUtils.lhs

Reported by: tmcdonell Owned by:
Priority: normal Milestone: 7.8.3
Component: Compiler Version: 7.8.2
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:


I happened to be using a debug build of ghc-7.8.2, and got this assertion failure compiling fclabels.

[ 7 of 10] Compiling Data.Label.Total ( src/Data/Label/Total.hs, dist/build/Data/Label/Total.o )

<no location info>:
    ghc: panic! (the 'impossible' happened)
  (GHC version for x86_64-unknown-linux):
	ASSERT failed!
    file compiler/coreSyn/CoreUtils.lhs line 194
    coercion Nth:0
               dt{v d7gF} [lid] passed to mkCast{v rkl} [gid[ClassOp]]
                                                   @ ghc-prim:GHC.Prim.*{(w) tc 34d}
                                                   @ fclabels-2.0.1:Data.Label.Point.Total{tc r1Pm}
                                                   (base:Control.Arrow.$p1Arrow{v r1s} [gid[ClassOp]]
                                                      @ fclabels-2.0.1:Data.Label.Point.Total{tc r1Pm}
                                                      (base:Control.Arrow.$p1ArrowApply{v rp} [gid[ClassOp]]
                                                         @ fclabels-2.0.1:Data.Label.Point.Total{tc r1Pm}
                                                         $dArrowApply{v a72o} [lid]))
                                                   @ f{tv a8m6} [tv]
                                                   f{v a8hw} [lid] has wrong role nominal

Problem does not appear with -O0.

I couldn't test with HEAD because fclabels isn't compatible with the changes to Template Haskell yet.

Change History (7)

comment:1 Changed 5 years ago by tmcdonell

Sorry, forgot to mention:

$ ghc --version
The Glorious Glasgow Haskell Compilation System, version

Test system is Ubuntu 12.04, x86_64.

comment:2 Changed 5 years ago by Simon Peyton Jones <simonpj@…>

In 4cfc1fae11ec9a5c4b34ac747f0ce50f52423eba/ghc:

Lint should check that TyConAppCo doesn't have a synonym in the tycon position

That is why Lint didn't nail Trac #9102

comment:3 Changed 5 years ago by simonpj

This is the actual fix for #9102:

commit 21f17d06aa5c33e639f1b0d37b4bf888b494c441
Author: Simon Peyton Jones <>
Date:   Tue May 13 13:17:19 2014 +0100

    Fix invariant in mkAppCoFlexible
    mkAppCoFlexible was breaking the invariant that the head of a TyConAppCo cannot
    be a type synonym.  This small patch fixes it.

 compiler/types/Coercion.lhs |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

I forgot to mention the ticket in the commit message.


comment:4 Changed 5 years ago by simonpj

Status: newmerge

Merge to 7.8.2.

I didn't get to a small test case, so no regression test for now.


comment:5 Changed 5 years ago by Simon Peyton Jones <simonpj@…>

In 022f8750edf6f413fba31293435dcc62600eab77/ghc:

Refactoring around TyCon.isSynTyCon

* Document isSynTyCon better
* Add isTypeSyonymTyCon for regular H98 type synonyms
* Use isTypeSynonymTyCon rather than isSynTyCon where
  the former is really intended

All arose as part of a bug I introduced when fixing Trac #9102,
thinking that isSynTyCon meant H98 type syononyms.

comment:6 Changed 5 years ago by thoughtpolice

Milestone: 7.8.3

comment:7 Changed 5 years ago by thoughtpolice

Resolution: fixed
Status: mergeclosed
Note: See TracTickets for help on using tickets.