Ah yes. This is a long-standing wart:
1.
The CoreTidy pass predicts what will be CAFFY (see https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Storage/GC/CAFs). It predicts that info because the output of CoreTidy
is what goes into interface files.
2.
The CorePrep pass messes the code a bit
3.
The CoreToStg pass coverts to STG, and at that point we know for sure what will be CAFFY and what will not
The assert trips when the predication in (1) doesn’t agree with reality in (3).
It would be Much Much better if we took the info from (3) and used that to drive the Core-to-IfaceSyn conversion that creates the interface file content.
The only reason not to do this is that it’d mean delaying Core-to-IfaceSyn until pass (3) had happened.. possibly bad for space. But maybe it’s a non-issue in practice.
See
https://ghc.haskell.org/trac/ghc/ticket/9718
Windows interacts with this because with DLLs some pointers that would be static closures turn into thunks (I think).
See StgSyn.isDllConApp, and
TidyPgm.hasCafRefs
Simon
From: ghc-devs [mailto:ghc-devs-bounces@haskell.org]
On Behalf Of lonetiger@gmail.com
Sent: 15 June 2016 00:26
To: Ömer Sinan Ağacan <omeragacan@gmail.com>
Cc: ghc-devs@haskell.org
Subject: RE: CoreToStg Asserts
Hi Ömer,
Thanks for the pointers, should help me find out more.
It’s not a stock GHC as I’m working on getting Dynamic linking back on Windows.
This assert is triggered on the dyn version of the libs. So something’s bit rotted here.
Cheers,
Tamar
From: Ömer Sinan Ağacan
Sent: Tuesday, June 14, 2016 18:46
To: Phyx
Cc: ghc-devs@haskell.org
Subject: Re: CoreToStg Asserts
Hi Tamar,
Have a look at Note [Disgusting computation of CafRefs] in TidyPgm.hs. The
assertion triggered here is the one that checks `hasCafRefs` mentioned in that
note matches with actual CAF-ness.
Are you using stock GHC? Which version? Do you have a minimal program that
reproduces this?
2016-06-13 7:01 GMT-04:00 Phyx <lonetiger@gmail.com>:
> Hi *,
>
> I'm hoping someone could help me understand what the asserts in CoreToStg on
> line 240 and 216 are trying to tell me.
>
> I hit both of them while trying to compile libraries as dyn.
>
> WARNING: file compiler\stgSyn\CoreToStg.hs, line 250
> $trModule2 False True
> ghc-stage1.exe: panic! (the 'impossible' happened)
> (GHC version 8.1.20160612 for x86_64-unknown-mingw32):
> ASSERT failed!
> file compiler\stgSyn\CoreToStg.hs line 216 $trModule2
>
> Please report this as a GHC bug:
http://www.haskell.org/ghc/reportabug
>
> WARNING: file compiler\simplCore\SimplCore.hs, line 633
> Simplifier bailing out after 4 iterations [6737, 736, 51, 9]
> Size = {terms: 12,990, types: 9,998, coercions: 443}
> WARNING: file compiler\stgSyn\CoreToStg.hs, line 250
> $fEqBigNat_$c/= False True
> ghc-stage1.exe: panic! (the 'impossible' happened)
> (GHC version 8.1.20160612 for x86_64-unknown-mingw32):
> ASSERT failed!
> file compiler\stgSyn\CoreToStg.hs line 240
> [$fEqBigNat_$c/=, $fEqBigNat]
>
> Please report this as a GHC bug:
http://www.haskell.org/ghc/reportabug
>
> Kind Regards,
> Tamar
>
> _______________________________________________
> ghc-devs mailing list
>
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>