GHC panic with parallel make

Consider the following modules:

-- F.hs

module F () where

-- F.hs-boot

module F where

import O (O)

newtype F = F ()
instance O F where

-- O.hs

module O (O) where

class O a where

-- V.hs

module V () where

import {-# SOURCE #-} F ()

-- V.hs-boot
module V where

If I try to compile this with

ghc -j2 F O V

I get

[1 of 4] Compiling O                ( O.hs, O.o )
[2 of 4] Compiling F[boot]          ( F.hs-boot, F.o-boot )
[3 of 4] Compiling F                ( F.hs, F.o )

<no location info>: error:
    ghc-stage2: panic! (the 'impossible' happened)
  (GHC version 8.2.0.20170720 for x86_64-unknown-linux):
	tcIfaceGlobal (local): not found
  You are in a maze of twisty little passages, all alike.
  While forcing the thunk for TyThing F
  which was lazily initialized by initIfaceCheck typecheckLoop,
  I tried to tie the knot, but I couldn't find F
  in the current type environment.
  If you are developing GHC, please read Note [Tying the knot]
  and Note [Type-checking inside the knot].
  Consider rebuilding GHC with profiling for a better stack trace.
  Contents of current type environment:
    [r1hL :-> Identifier ‘$trModule’]
  Call stack:
      CallStack (from HasCallStack):
        prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable
        callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable
        pprPanic, called at compiler/iface/TcIface.hs:1696:23 in ghc:TcIface

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

On the other hand

ghc -j1 F O V

works just fine, and gives the expected

[2 of 5] Compiling O                ( O.hs, O.o )
[3 of 5] Compiling F[boot]          ( F.hs-boot, F.o-boot )
[4 of 5] Compiling F                ( F.hs, F.o )

F.hs-boot:7:1: error:
    ‘F.F’ is exported by the hs-boot file, but not exported by the module
  |
7 | newtype F = F ()
  | ^^^^^^^^^^^^^^^^

F.hs:1:1: error:
    instance O.O F.F -- Defined at F.hs-boot:8:10
      is defined in the hs-boot file, but not in the module itself
  |
1 | -- F.hs
  | ^

The example is a little bit sick, in that the original code is not expected to compile. I run into this by accident when trying to construct a minimal example of the issue reported in #13803 (closed) (note that that bug is marked as closed, but the original issue reported there remains unfixed, I am trying to construct a minimal testcase for the original issue there).

Trac metadata

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