Opened 3 years ago

Closed 3 years ago

#12746 closed bug (fixed)

Assertion failed with BuildFlavour = devel2 (one more)

Reported by: pacak Owned by: mpickering
Priority: high Milestone: 8.0.2
Component: Compiler Version: 8.0.1
Keywords: PatternSynonyms Cc: akio
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: Compile-time crash or panic Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s): Phab:D2624
Wiki Page:


Affected versions: ghc 8.0.1 and ghc git master as of 21 Oct 2016 (c23dc61)

It compiles fine on first time but fails to compile on second attempt. Using -fforce-recomp recompiles both files and bug is not triggered.

% ls
A.hs  B.hs

% cat A.hs
module A where

import B

foo a = case a of
        Foo -> True
        _ -> False
% cat B.hs
{-# LANGUAGE PatternSynonyms, ScopedTypeVariables #-}

module B where

pattern Foo = 0x00000001 :: Int
% ghc -O2 A.hs ; touch A.hs ; ghc -O2 A.hs
[1 of 2] Compiling B                ( B.hs, B.o )
[2 of 2] Compiling A                ( A.hs, A.o )
[2 of 2] Compiling A                ( A.hs, A.o )
ghc: panic! (the 'impossible' happened)
  (GHC version 8.0.1 for x86_64-unknown-linux):
        ASSERT failed!
  CallStack (from HasCallStack):
  assertPprPanic, called at compiler/iface/BuildTyCl.hs:195:404 in ghc:BuildTyCl
  [] ~ []
  [] ~ []
  Int ~ Int
  [] ~ []
  [] ~ []
  [] ~ [Void#]

Please report this as a GHC bug:

Change History (10)

comment:1 Changed 3 years ago by rwbarton

I couldn't reproduce this with the released GHC 8.0.1. Do you think it only happens with devel2 builds? Any idea why?

comment:2 Changed 3 years ago by pacak

I suspect that some assertions are not enabled outside of devel2 builds. I'm trying to make a devel2 build because there is a random compilation failure in our codebase which I can't reliably reproduce at the moment but when compiling one of the prerequisites I'm getting this assert failure.

edit: reliably reproduce, it fails with almost 100% probability, but it takes 10 minutes.

Last edited 3 years ago by pacak (previous) (diff)

comment:3 Changed 3 years ago by rwbarton

Priority: normalhigh

Aha, that makes sense. This seems mildly alarming...

comment:4 Changed 3 years ago by akio

Cc: akio added

comment:5 Changed 3 years ago by mpickering

Keywords: PatternSynonyms added

comment:6 Changed 3 years ago by mpickering

Owner: set to mpickering

I can see where the problem is here.

comment:7 Changed 3 years ago by mpickering

Differential Rev(s): Phab:D2624
Status: newpatch

The ASSERT was slightly wrong as there is a special case where a Void# argument is added to the matching continuation to ensure laziness for a nullary pattern synonym. The fix is to check whether the number of arguments is 0 and if so check wether the only argument to the matcher is Void#.

comment:8 Changed 3 years ago by Ben Gamari <ben@…>

In 23143f6/ghc:

Refine ASSERT in buildPatSyn for the nullary case.

For a nullary pattern synonym we add an extra void argument to the
matcher in order to preserve laziness. The check in buildPatSyn
wasn't aware of this special case which was causing the assertion to

Reviewers: austin, simonpj, bgamari

Reviewed By: simonpj, bgamari

Subscribers: simonpj, thomie

Differential Revision:

GHC Trac Issues: #12746

comment:9 Changed 3 years ago by bgamari

Milestone: 8.0.2
Status: patchmerge

comment:10 Changed 3 years ago by bgamari

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