GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2024-03-26T14:59:59Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/24592Off by one error in seekBinNoExpand2024-03-26T14:59:59ZMatthew PickeringOff by one error in seekBinNoExpandIf `seekBinNoExpand` is called with an offset equal to the buffer size then the function panics.
However, `putPrim` only expands the buffer in the case that the offset plus the size is strictly greater than the buffer size.
Therefore i...If `seekBinNoExpand` is called with an offset equal to the buffer size then the function panics.
However, `putPrim` only expands the buffer in the case that the offset plus the size is strictly greater than the buffer size.
Therefore if you end up writing exactly up to the buffer size and then moving to the end you will get a panic.
I imagine the following program exhibits the failure more directly.
```
bh <- openBinMem 0
bp <- tellBin @() bh
seekBinNoExpand bh bp
```
In general `seekBinNoExpand` with the result of `tellBin` should always succeed.
It might seem surprising this hasn't been discovered before but
* The initial buffer when writing an interface is 1mb, almost all interfaces are smaller than this.
* lazyPut/lazyGet and other functions which call seekBinNoExpand are not used very often.
The fix is simple, replace `>=` with `>` in `seekBin` and `seekBinNoExpand`.Hannes SiebenhandlHannes Siebenhandlhttps://gitlab.haskell.org/ghc/ghc/-/issues/24582Infinite simplifier iteration2024-03-26T15:13:09ZSimon Peyton JonesInfinite simplifier iterationConsider this little program:
```
module Foo(woo) where
foo :: String -> Int -> a
{-# NOINLINE foo #-}
foo s _ = error s
f :: (Int->Int) -> Int
{-# NOINLINE f #-}
f g = g 3
x :: Int -> a
x = foo "urk"
woo = f x
```
When compiling wi...Consider this little program:
```
module Foo(woo) where
foo :: String -> Int -> a
{-# NOINLINE foo #-}
foo s _ = error s
f :: (Int->Int) -> Int
{-# NOINLINE f #-}
f g = g 3
x :: Int -> a
x = foo "urk"
woo = f x
```
When compiling with HEAD we get
```
bash$ ~/code/HEAD/$s1 -c -O -fmax-simplifier-iterations=10 Foo.hs
WARNING:
Simplifier bailing out
Foo, after 10 iterations [12, 2, 2, 2, 2, 2, 2, 2, 2, 2]
Size = {terms: 85, types: 55, coercions: 4, joins: 0/0}
Call stack:
CallStack (from HasCallStack):
warnPprTrace, called at compiler/GHC/Core/Opt/Simplify.hs:191:9 in ghc:GHC.Core.Opt.Simplify
WARNING:
Simplifier bailing out
Foo, after 10 iterations [46, 3, 3, 3, 3, 3, 3, 3, 3, 3]
Size = {terms: 85, types: 45, coercions: 4, joins: 0/0}
Call stack:
CallStack (from HasCallStack):
warnPprTrace, called at compiler/GHC/Core/Opt/Simplify.hs:191:9 in ghc:GHC.Core.Opt.Simplify
WARNING:
Simplifier bailing out
Foo, after 10 iterations [3, 3, 3, 3, 3, 3, 3, 3, 3, 3]
Size = {terms: 85, types: 45, coercions: 4, joins: 0/0}
Call stack:
CallStack (from HasCallStack):
warnPprTrace, called at compiler/GHC/Core/Opt/Simplify.hs:191:9 in ghc:GHC.Core.Opt.Simplify
```
Clearly the Simplifier is not reaching a fixed point.
This is true in HEAD, and goes back to at least GHC 9.6 probably earlier.
## Diagnosis
We end up with
```
s1 = "urk#"
s2 = unpackSString# s1
x = foo s2 -- A partial application, since foo has arity 2
-- but x is bottoming so we don't inline it
```
The Simplifier is
* doing `preInlineUnconditionally` to inline `s1` into `s2`, and `s2` into `x`
* and then ANF-ising the RHS `foo (unpackCString# "urk"#)` to get back what we started with.
The (long-standing) bug is that the `certainly_inline` predicate in `GHC.Core.Opt.OccurAnal.mkNonRecRhsCtxt` is not tracking `preInlineUnconditionally` correctly; see Note [Cascading inlines] in that module. (In this case it is not accounting for the fact that `x` a top-level is bottoming binding.
## Solution
Update `certainly_inline`. It's not very satisfactory that this out-of-sync-ness can
happen but I don't see an easy solution.Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/24470Implicit RHS quantification in type synonyms crashes GHC2024-03-25T19:13:15ZVladislav ZavialovImplicit RHS quantification in type synonyms crashes GHCThis example is accepted by GHC 9.8 but crashes GHC HEAD:
```haskell
type SynBad :: forall k. k -> Type
type SynBad = Proxy :: j -> Type
```
```
Test.hs:7:24: error: [GHC-76329]
• GHC internal error: ‘j’ is not in scope during type...This example is accepted by GHC 9.8 but crashes GHC HEAD:
```haskell
type SynBad :: forall k. k -> Type
type SynBad = Proxy :: j -> Type
```
```
Test.hs:7:24: error: [GHC-76329]
• GHC internal error: ‘j’ is not in scope during type checking, but it passed the renamer
tcl_env of environment: [rDP :-> ATcTyCon SynBad :: forall k.
k -> *]
• In the kind ‘j -> Type’
In the type ‘Proxy :: j -> Type’
In the type declaration for ‘SynBad’
|
7 | type SynBad = Proxy :: j -> Type
|
```
While this one is accepted by both compilers:
```haskell
type SynOK :: forall k. k -> Type
type SynOK @t = Proxy :: j -> Type
```
The difference between `SynBad` and `SynOK` is the arity. Adding the `@t` binder changes the arity of `SynOK` so that it includes `j` (in fact, `j=t=k`.)
This is an example of rather exotic interaction between SAKS, arity, and implicit RHS quantification in type synonyms.
Long-term, both examples should be rejected, as implicit RHS quantification in type synonyms is deprecated anyway
```
Test.hs:8:24: warning: [GHC-16382] [-Wimplicit-rhs-quantification]
The variable ‘j’ occurs free on the RHS of the type declaration
In the future GHC will no longer implicitly quantify over such variables
Suggested fix: Bind ‘j’ on the LHS of the type declaration
|
8 | type SynBad = Proxy :: j -> Type
| ^
Test.hs:11:26: warning: [GHC-16382] [-Wimplicit-rhs-quantification]
The variable ‘j’ occurs free on the RHS of the type declaration
In the future GHC will no longer implicitly quantify over such variables
Suggested fix: Bind ‘j’ on the LHS of the type declaration
|
11 | type SynOK @t = Proxy :: j -> Type
| ^
Ok, one module loaded.
```
Short-term (for the next few releases while we still supported implicit RHS quantification in type synonyms), we probably want a proper error message for `SynBad`. Arity inference has been removed in e89aa0721ca5c594f6811f2108d49cd051488ce1, so that rules out accepting `SynBad`. And if we reject it, it's much better to do so with a proper error message rather than a compiler panic.Andrei BorzenkovAndrei Borzenkovhttps://gitlab.haskell.org/ghc/ghc/-/issues/24242GHC 9.8.1 panic on poly library2024-02-12T17:40:45ZDaniel FirthGHC 9.8.1 panic on poly libraryGHC 9.8.1 is panicking when trying to build the `poly` library. Seems to be fine with older compilers.
Trace here:
https://gitlab.horizon-haskell.net/package-sets/horizon-advance/-/jobs/695569
```
poly> [20 of 21] Compiling Data.Poly...GHC 9.8.1 is panicking when trying to build the `poly` library. Seems to be fine with older compilers.
Trace here:
https://gitlab.horizon-haskell.net/package-sets/horizon-advance/-/jobs/695569
```
poly> [20 of 21] Compiling Data.Poly.Sparse.Laurent ( src/Data/Poly/Sparse/Laurent.hs, dist/build/Data/Poly/Sparse/Laurent.p_o )
poly> <no location info>: error:
poly> panic! (the 'impossible' happened)
poly> GHC version 9.8.1:
poly> lookupIdSubst
poly> step1_Xh
poly> InScope {eta_B0 n1_X2 ipv_X3 ipv_X6 ipv1_X7 ipv2_X8 n1_Xf ipv_Xg
poly> v2_adj0 n1_adj1 ipv_adj3 x_aeYl wild_ag11 ds_ag12 ds1_ag13 ds2_ag14
poly> ds3_ag15 wild1_ag17 s_ag19 step1_ag1d t_ag1e ds5_ag1g wild2_ag1j
poly> x_ag1k s'_ag1l wild2_ag2F a_a1Mnj v_a1Mnk w_a1Mnl $dEq_a1Mnm
poly> $dSemiring_a1Mnn $dVector_a1Mno $dVector_a1Mnp nt_i1abe ipv_i1abf
poly> ipv1_i1abg ipv2_i1abh wild_i1Mtc ps_i1Mtd c_i1Mte ww_i1MJw
poly> ww1_i1MJx wild1_i1MJz ww2_i1MJA ww3_i1MJB monomial scale ^- eval
poly> subst deriv $mX $bX $trModule $trModule_s1Myo $trModule_s1Myp
poly> $trModule_s1Myq $trModule_s1Myr $dKnownNat_s1Myz $dKnownNat_s1MyD
poly> $dKnownNat_s1MyF $dKnownNat_s1MyV $dSemiring1_s1MyX xs_s1Mz1
poly> v1_s1Mzf v2_s1Mzh off_s1Mzt v1_s1Mzv v2_s1Mzx $j_s1MzF
poly> $dKnownNat_s1MzJ $szipWithM_s1MAz $sunstream_s1MB4 $sunstream_s1MBz
poly> $snew_s1MBB $snew_s1MBD $smapM_s1MBJ $snull_s1MBP $sfoldlM'_s1MBU
poly> $sunsafeIndex_s1MBY $sunsafeIndex_s1MC2 $sclone_s1MC9 lvl_s1MCd
poly> lvl_s1MCe lvl_s1MCx lvl_s1MCQ lvl_s1MCU lvl_s1MCV lvl_s1MD4
poly> lvl_s1MD7 lvl_s1MDa lvl_s1MDd lvl_s1MDe lvl_s1MDf lvl_s1MDg
poly> lvl_s1MDh lvl_s1MDi lvl_s1MDl lvl_s1MDo lvl_s1MDr lvl_s1MDu
poly> lvl_s1MDv lvl_s1MDw lvl_s1MDx lvl_s1MDy lvl_s1MDz lvl_s1MDC
poly> lvl_s1MDF lvl_s1MDI lvl_s1MDL lvl_s1MDM lvl_s1MDN lvl_s1MDO
poly> lvl_s1MDP lvl_s1MDQ lvl_s1MDT lvl_s1MDW lvl_s1MDZ lvl_s1ME2
poly> lvl_s1ME3 lvl_s1ME4 lvl_s1ME5 lvl_s1ME6 lvl_s1ME7 lvl_s1ME8
poly> lvl_s1ME9 lvl_s1MEa lvl_s1MEb lvl_s1MEc lvl_s1MEd lvl_s1MEf
poly> lvl_s1MEg lvl_s1MEh lvl_s1MEi lvl_s1MEl lvl_s1MEv f_s1MEx lvl_s1MEy
poly> eta1_s1MEA lvl_s1MEB eta_s1MED lvl_s1MEE lvl_s1MEG lvl_s1MEH
poly> lvl_s1MEJ lvl_s1MEK lvl_s1MEM lvl_s1MEN lvl_s1MEP lvl_s1MEQ
poly> lvl_s1MER lvl_s1MES lvl_s1MET lvl_s1MEU lvl_s1MEV lvl_s1MEW
poly> eta3_s1MF1 lvl_s1MF2 lvl_s1MF3 lvl_s1MF4 lvl_s1MF5 lvl_s1MF6
poly> lvl_s1MF7 lvl_s1MF9 lvl_s1MFc lvl_s1MFj lvl_s1MFk lvl_s1MFm
poly> lvl_s1MFo lvl_s1MFp lvl_s1MFq lvl_s1MFr lvl_s1MFt lvl_s1MFv
poly> lvl_s1MFx lvl_s1MFA lvl_s1MFH lvl_s1MFI lvl_s1MFK lvl_s1MFL
poly> lvl_s1MFM lvl_s1MFO lvl_s1MFP lvl_s1MFQ eta_s1MFS lvl_s1MFU
poly> lvl_s1MFV lvl_s1MG1 lvl_s1MG4 lvl_s1MG8 loc22_s1MGb lvl_s1MGc
poly> loc11_s1MGf lvl_s1MGg loc12_s1MGj loc1_s1MGl loc2_s1MGn loc17_s1MGp
poly> loc3_s1MGr lvl_s1MGs $dIP2_s1MGv $dIP3_s1MGx lvl_s1MHq lvl_s1MHs
poly> lvl_s1MHt lvl_s1MHv lvl_s1MHw lvl_s1MHy lvl_s1MHz lvl_s1MHB
poly> lvl_s1MHC lvl_s1MHD lvl_s1MHE lvl_s1MHF lvl_s1MHG lvl_s1MHH
poly> lvl_s1MHI lvl_s1MHL lvl_s1MHP lvl_s1MHQ lvl_s1MLp lvl_s1MLq
poly> lvl_s1MLr lvl_s1MLs lvl_s1MLt lvl_s1MLu lvl_s1MLv lvl_s1MLw
poly> lvl_s1MLx lvl_s1MLy lvl_s1MLz lvl_s1MLA lvl_s1MLB lvl_s1MLC
poly> lvl_s1MLD lvl_s1MLE $j_s1MTI lvl_s1N0f lvl_s1N0h lvl_s1N0j
poly> lvl_s1N0l lvl_s1N2v lvl_s1N2x ds4_s1NeX ww_s1Nf2 ww_s1Nf3 ww_s1Nf4
poly> ww_s1Nf6 s1_s1Nf8 $wfoldlM'_loop_s1Nfa nt_s1Njn}
poly> Call stack:
poly> CallStack (from HasCallStack):
poly> callStackDoc, called at compiler/GHC/Utils/Panic.hs:191:37 in ghc-9.8.1-inplace:GHC.Utils.Panic
poly> pprPanic, called at compiler/GHC/Core/Subst.hs:197:17 in ghc-9.8.1-inplace:GHC.Core.Subst
poly> CallStack (from HasCallStack):
poly> panic, called at compiler/GHC/Utils/Error.hs:503:29 in ghc-9.8.1-inplace:GHC.Utils.Error
poly> Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug
poly>
poly> [21 of 21] Compiling Data.Poly.Sparse.Semiring ( src/Data/Poly/Sparse/Semiring.hs, dist/build/Data/Poly/Sparse/Semiring.p_o )
error: builder for '/nix/store/43v57lzxyb57jk8jlfmq3fmak418phq6-poly-0.5.1.0.drv' failed with exit code 1;
last 10 log lines:
> CallStack (from HasCallStack):
> callStackDoc, called at compiler/GHC/Utils/Panic.hs:191:37 in ghc-9.8.1-inplace:GHC.Utils.Panic
> pprPanic, called at compiler/GHC/Core/Subst.hs:197:17 in ghc-9.8.1-inplace:GHC.Core.Subst
> CallStack (from HasCallStack):
> panic, called at compiler/GHC/Utils/Error.hs:503:29 in ghc-9.8.1-inplace:GHC.Utils.Error
>
>
> Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug
>
> [21 of 21] Compiling Data.Poly.Sparse.Semiring ( src/Data/Poly/Sparse/Semiring.hs, dist/build/Data/Poly/Sparse/Semiring.p_o )
```
Reproduce with:
```
git clone https://gitlab.horizon-haskell.net/package-sets/horizon-advance
cd horizon-advance
git checkout poly-failure
nix build .#poly
```9.8.2https://gitlab.haskell.org/ghc/ghc/-/issues/24181Regression: GHC 9.4.7 still produced statically linked binaries on ubuntu-20....2023-11-15T10:07:25ZAndreas AbelRegression: GHC 9.4.7 still produced statically linked binaries on ubuntu-20.04, GHC 9.4.8 doesn'tBumping CI from GHC 9.4.7 and 9.4.8 revealed that statically linked binaries cannot be produced on Ubuntu-20.04 anymore.
[The error is](https://github.com/agda/agda/actions/runs/6842325612/job/18603683537#step:13:33):
```
/usr/lib/x86_64...Bumping CI from GHC 9.4.7 and 9.4.8 revealed that statically linked binaries cannot be produced on Ubuntu-20.04 anymore.
[The error is](https://github.com/agda/agda/actions/runs/6842325612/job/18603683537#step:13:33):
```
/usr/lib/x86_64-linux-gnu/libm-2.31.a(s_atan.o)(.note.stapsdt+0x14): error: relocation refers to local symbol "" [1], which is defined in a discarded section
...
(etc.)
```
In contrast, [it still works with GHC 9.4.7](https://github.com/agda/agda/actions/runs/6836130825/job/18590703386#step:13:505) (with some linker warnings).
I know that static linking on Ubuntu is on the way out (does not work with any of Ubuntu-22 or GHC >= 9.6).
But maybe a GHC minor release should maintain backwards-compatibility.
Our workaround is to stay on GHC 9.4.7.
- https://github.com/agda/agda/pull/6986https://gitlab.haskell.org/ghc/ghc/-/issues/24090GHC internal error on HEAD with ill-scoped type synonym2023-10-24T14:53:37ZRyan ScottGHC internal error on HEAD with ill-scoped type synonym## Summary
Using GHC HEAD (commit dafc47091c9107dcf81e1e80a105f59211927c89), GHC produces an internal error when compiling a type synonym with an out-of-scope kind variable.
## Steps to reproduce
Compile the following program with GHC...## Summary
Using GHC HEAD (commit dafc47091c9107dcf81e1e80a105f59211927c89), GHC produces an internal error when compiling a type synonym with an out-of-scope kind variable.
## Steps to reproduce
Compile the following program with GHC HEAD:
```hs
module Bug where
import GHC.Exts (Any)
type Foo :: a
type Foo = Any :: a
```
```
$ ~/Software/ghc-9.9.20231012/bin/ghc Bug.hs
[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
Bug.hs:6:19: error: [GHC-76329]
• GHC internal error: ‘a’ is not in scope during type checking, but it passed the renamer
tcl_env of environment: [riQ :-> ATcTyCon Foo :: forall a. a]
• In the kind ‘a’
In the type ‘Any :: a’
In the type declaration for ‘Foo’
|
6 | type Foo = Any :: a
| ^
```
Note that this program will compile with GHC 9.8 and earlier, but that is only because GHC HEAD has implemented !10660, which removes arity inference in type synonym declarations. Therefore, this bug only makes sense in the context of HEAD.
## Expected behavior
I would expect GHC to produce an ordinary error message stating that `a` is out of scope, similar to the error message that you get when compiling a similar program with a type family instead of a type synonym:
```hs
{-# LANGUAGE TypeAbstractions #-}
{-# LANGUAGE TypeFamilies #-}
module Bug where
import GHC.Exts (Any)
type Bar :: a
type family Bar @a where
Bar = Any :: a
```
```
$ ~/Software/ghc-9.9.20231012/bin/ghc Bug.hs
[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
Bug.hs:9:16: error: [GHC-76037]
Not in scope: type variable ‘a’
|
9 | Bar = Any :: a
| ^
```
## Environment
* GHC version used: HEAD (commit dafc47091c9107dcf81e1e80a105f59211927c89)
Optional:
* Operating System: Ubuntu 22.04
* System Architecture: x86_649.10.1sheafsam.derbyshire@gmail.comsheafsam.derbyshire@gmail.comhttps://gitlab.haskell.org/ghc/ghc/-/issues/24083Type checker crash2024-02-08T17:32:02ZSimon Peyton JonesType checker crashThis program
```haskell
{-# LANGUAGE StandaloneKindSignatures #-}
{-# LANGUAGE TypeFamilies #-}
module Main where
import Data.Kind (Constraint, Type)
data family Pi t :: Type
type FunctionSymbol :: Type -> Type
type FunctionSymbol t =...This program
```haskell
{-# LANGUAGE StandaloneKindSignatures #-}
{-# LANGUAGE TypeFamilies #-}
module Main where
import Data.Kind (Constraint, Type)
data family Pi t :: Type
type FunctionSymbol :: Type -> Type
type FunctionSymbol t = Type
type IsSum :: forall s. FunctionSymbol s -> Constraint
class IsSum (sumf :: FunctionSymbol t) where
sumConNames :: Pi t
```
crashes GHC like this:
```
generic-bug.hs:15:23: error: [�]8;;https://errors.haskell.org/messages/GHC-76329�\GHC-76329�]8;;�\]
• GHC internal error: ‘t’ is not in scope during type checking, but it passed the renamer
tcl_env of environment: [ahc :-> Type variable ‘sumf’ = sumf :: FunctionSymbol
s,
awz :-> Type variable ‘s’ = s :: *,
rh7 :-> ATcTyCon IsSum :: forall s. FunctionSymbol s -> Constraint]
• In the first argument of ‘Pi’, namely ‘t’
In the type signature: sumConNames :: Pi t
In the class declaration for ‘IsSum’
|
15 | sumConNames :: Pi t
| ^
```
HEAD, 9.8, 9.6, all of them!9.8.2https://gitlab.haskell.org/ghc/ghc/-/issues/23972GHC-9.4 panics due to failing lookupIdSubst for KnownNat2023-09-19T19:09:46ZLars KuhtzGHC-9.4 panics due to failing lookupIdSubst for KnownNat## Summary
GHC panics when compiling the module that is shown below.
The issue happens with GHC-9.4 (tested with GHC 9.4.6 and 9.4.7) and optimization enabled (`-O1` and `-O2`) on all tested operating systems and platforms.
GHC-8.10.7...## Summary
GHC panics when compiling the module that is shown below.
The issue happens with GHC-9.4 (tested with GHC 9.4.6 and 9.4.7) and optimization enabled (`-O1` and `-O2`) on all tested operating systems and platforms.
GHC-8.10.7, GHC-9.2 and GHC-9.6 are not affected.
## Steps to reproduce
```hs
{-# LANGUAGE DataKinds #-}
module Bug where
import Numeric.Natural (Natural)
import GHC.TypeNats (KnownNat, natVal)
import Data.Proxy (Proxy(..))
newtype M (n :: Natural) = M Natural
-- Using a smaller value for `PC` makes the issue go away.
type PC :: Natural
type PC = 0x1_0000_0000_0000_0000
-- remove (or simplifying) one case makes the issue go away.
f :: forall n . KnownNat n => M n -> M n
f (M 0) = M 0
f (M x) = M (natVal @n Proxy + x)
-- removing one invocation of `f` makes the issue go away.
g :: KnownNat n => M n -> M n
g x = f (f x)
-- removing the let binding or one invocation of `g` makes the issue go away.
h :: M PC -> M PC
h x = let a = g (g x) in a
```
Compiling this module with GHC-9.4.7 and `-O1` or `-O2` as follows
```sh
ghc -O1 Bug.hs
```
Results in the output
```
[1 of 1] Compiling Bug ( Bug.hs, Bug.o ) [Source file changed]
<no location info>: error:
panic! (the 'impossible' happened)
GHC version 9.4.7:
lookupIdSubst
$dKnownNat_sUW
InScope {wild_X2 z_anJ $krep_aQG $krep_aQH $krep_aQI $krep_aQJ
$krep_aQK h $tc'M $trModule $tcM f g $trModule_sUK $trModule_sUL
$trModule_sUM $trModule_sUN $krep_sUO $tcM_sUP $tcM_sUQ $krep_sUR
$tc'M_sUS $tc'M_sUT $sg_sV3}
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/GHC/Utils/Panic.hs:182:37 in ghc:GHC.Utils.Panic
pprPanic, called at compiler/GHC/Core/Subst.hs:260:17 in ghc:GHC.Core.Subst
Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug
```
## Expected behavior
GHC compiles the module.
## Environment
The issue was reproduced with
* GHC-9.4.6 and GHC-9.6.7
* ubuntu/linux (amd64) and macOS (amd64 as well as aarch64).https://gitlab.haskell.org/ghc/ghc/-/issues/23891heap overflow panic with 9.2 (but not 9.0 or 9.4)2023-08-29T14:50:04Zquarkheap overflow panic with 9.2 (but not 9.0 or 9.4)## Summary
We observed a failure when compiling code in [the BSC project](https://github.com/B-Lang-org/bsc) with GHC 9.2.8, that does not occur when compiling with earlier GHC 9.0.2 or later GHC 9.4.6 and 9.6.2. We have boiled it down...## Summary
We observed a failure when compiling code in [the BSC project](https://github.com/B-Lang-org/bsc) with GHC 9.2.8, that does not occur when compiling with earlier GHC 9.0.2 or later GHC 9.4.6 and 9.6.2. We have boiled it down to a small two-file example, in case you wanted to investigate -- in case the issue still exists in 9.4+ and is just being masked. The error we see is:
```
[1 of 2] Compiling Util ( Util.hs, Util.o )
[2 of 2] Compiling GenABin ( GenABin.hs, GenABin.o )
ghc-9.2.8: panic! (the 'impossible' happened)
(GHC version 9.2.8:
heap overflow
```
## Steps to reproduce
Place the following three files in a directory and run `make`:
[Util.hs](/uploads/fbe6a7b5611a7f17e6fbac1a69527654/Util.hs) (20 lines),
[GenABin.hs](/uploads/0e2cdd7e19878e41e0648d05c6c23724/GenABin.hs) (365 lines),
[Makefile](/uploads/478a658aaea2289c9dbfddceb886e736/Makefile). That will run the following command:
```
ghc \
-O2 \
-hide-all-packages \
-Wall \
-fno-warn-unused-binds \
-package base \
-package bytestring \
-package containers \
-package text \
+RTS -M4G -A128m -RTS \
GenABin.hs
```
The file `Util.hs` contains two small definitions that are imported by the top file `GenABin.hs`. If those definitions are merged into the top file, then it compiles without error. So the separation into two files is necessary. If the numbers of fields of the `Flags` datatype is reduced (from 125 to a dozen or so), then it compiles fine; so many fields is necessary (though we haven't experimented with other amounts). Without the RTS flags, I think that GHC starts to use up all the memory and swaps, so the RTS flags may be necessary to get it to fail early.
I can't determine if this is a duplicate of existing issues. For example, #20683.
## Expected behavior
If I try with GHC 9.4.6, it compiles without an error:
```
[1 of 2] Compiling Util ( Util.hs, Util.o )
[2 of 2] Compiling GenABin ( GenABin.hs, GenABin.o )
```
## Environment
I observe these behaviors on both macOS 11.7.8 (x86_64) and Debian 11.7 (x86_64).Matthew PickeringMatthew Pickeringhttps://gitlab.haskell.org/ghc/ghc/-/issues/23883typeOrConstraint panic with out of scope function, default method and represe...2023-09-22T10:08:42Zsheafsam.derbyshire@gmail.comtypeOrConstraint panic with out of scope function, default method and representation-polymorphism```haskell
module T23883 where
import Data.Kind
import GHC.Exts
type SetField :: forall {a_rep}. Type -> TYPE a_rep -> Constraint
class SetField r a where
setField :: a -> r -> r
setField x = nonsense (\ _ -> x)
```
```
<no locati...```haskell
module T23883 where
import Data.Kind
import GHC.Exts
type SetField :: forall {a_rep}. Type -> TYPE a_rep -> Constraint
class SetField r a where
setField :: a -> r -> r
setField x = nonsense (\ _ -> x)
```
```
<no location info>: error:
panic! (the 'impossible' happened)
GHC version 9.9.20230817:
typeOrConstraint
(a_a1rM[ssk:1] |> {co_a1se}) :: cx_a1sd[conc:1]
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler\GHC\Utils\Panic.hs:191:37 in ghc-9.9-inplace:GHC.Utils.Panic
pprPanic, called at compiler\GHC\Core\Type.hs:2708:14 in ghc-9.9-inplace:GHC.Core.Type
typeTypeOrConstraint, called at compiler\GHC\Core\TyCo\Rep.hs:778:18 in ghc-9.9-inplace:GHC.Core.TyCo.Rep
mkScaledFunTys, called at compiler\GHC\Tc\Utils\Unify.hs:473:32 in ghc-9.9-inplace:GHC.Tc.Utils.Unify
CallStack (from HasCallStack):
panic, called at compiler\GHC\Utils\Error.hs:512:29 in ghc-9.9-inplace:GHC.Utils.Error
```
I get this error starting from GHC 9.6 (including 9.8 and HEAD).
On GHC 9.4 I instead get the following panic:
```
panic! (the 'impossible' happened)
GHC version 9.4.5:
getRuntimeRep
(a_aBi[ssk:1] |> Sym {co_aCl}) :: c_aC1[conc:1]
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler\GHC\Utils\Panic.hs:182:37 in ghc:GHC.Utils.Panic
pprPanic, called at compiler\GHC\Core\Type.hs:2534:18 in ghc:GHC.Core.Type
```
On GHC 9.2 I correctly get the out of scope error:
```
Variable not in scope: nonsense :: (p0 -> a) -> r -> r
```sheafsam.derbyshire@gmail.comsheafsam.derbyshire@gmail.comhttps://gitlab.haskell.org/ghc/ghc/-/issues/23533Windows, GHC 9.6.2, munmapForLinker: m32_release_page: Failed to unmap ... At...2023-09-16T12:01:43ZMike PilgremWindows, GHC 9.6.2, munmapForLinker: m32_release_page: Failed to unmap ... Attempt to access invalid address.## Summary
The [CI for a pull request in the Hpack project](https://github.com/sol/hpack/pull/518) for Windows only, using the 'system' GHC 9.6.2 supplied by the GitHub hosted runner and `cabal-3.10.1.0` dies with complaints about unkno...## Summary
The [CI for a pull request in the Hpack project](https://github.com/sol/hpack/pull/518) for Windows only, using the 'system' GHC 9.6.2 supplied by the GitHub hosted runner and `cabal-3.10.1.0` dies with complaints about unknown symbols:
~~~text
ghc-9.6.2.exe: | C:\cabal\store\ghc-9.6.2\tls-1.7.0-8d58f20e9eccc9f7873d67e5a2bfbab4adac37aa\lib\libHStls-1.7.0-8d58f20e9eccc9f7873d67e5a2bfbab4adac37aa.a: unknown symbol `gettimeofday'
ghc-9.6.2.exe: | C:\cabal\store\ghc-9.6.2\tls-1.7.0-8d58f20e9eccc9f7873d67e5a2bfbab4adac37aa\lib\libHStls-1.7.0-8d58f20e9eccc9f7873d67e5a2bfbab4adac37aa.a: unknown symbol `tlszm1zi7zi0zm8d58f20e9eccc9f7873d67e5a2bfbab4adac37aa_NetworkziTLSziHandshakeziCommon13_zdwmakeCipherChoice_info'
ghc-9.6.2.exe: | C:\cabal\store\ghc-9.6.2\crypton-conne_-0.3.1-8964bf584322945dcb53418157c8e69109bc0668\lib\libHScrypton-conne_-0.3.1-8964bf584322945dcb53418157c8e69109bc0668.a: unknown symbol `tlszm1zi7zi0zm8d58f20e9eccc9f7873d67e5a2bfbab4adac37aa_NetworkziTLSziCore_bye1_closure'
ghc-9.6.2.exe: | C:\cabal\store\ghc-9.6.2\http-client-t_-0.3.6.2-887fc88ddae31b1bedf678cc8338c500c876074d\lib\libHShttp-client-t_-0.3.6.2-887fc88ddae31b1bedf678cc8338c500c876074d.a: unknown symbol `cryptonzmconnezuzm0zi3zi1zm8964bf584322945dcb53418157c8e69109bc0668_NetworkziConnection_zdfExceptionLineTooLong3_closure'
ghc-9.6.2.exe: | D:\a\hpack\hpack\dist-newstyle\build\x86_64-windows\ghc-9.6.2\hpack-0.35.2\t\spec\build\spec\spec-tmp\Hpack\Defaults.o: unknown symbol `httpzmclientzmtzuzm0zi3zi6zi2zm887fc88ddae31b1bedf678cc8338c500c876074d_NetworkziHTTPziClientziTLS_tlsManagerSettings_closure'
ghc-9.6.2.exe: Could not load Object Code D:\a\hpack\hpack\dist-newstyle\build\x86_64-windows\ghc-9.6.2\hpack-0.35.2\t\spec\build\spec\spec-tmp\Hpack\Defaults.o.
<no location info>: error:
~~~
then a series of 33 of the following messages at different memory addresses:
~~~text
ghc-9.6.2.exe: munmapForLinker: m32_release_page: Failed to unmap 4096 bytes at 00007ff7e06e6000: Attempt to access invalid address.
~~~
and then
~~~text
Access violation in generated code when reading 0x20
Attempting to reconstruct a stack trace...
Frame Code address
* 0x8f3c7fd840 0x7ff7d2d06636 C:\ghcup\ghc\9.6.2\bin\ghc-9.6.2.exe+0x4286636
* 0x8f3c7fd8c0 0x7ff7d19de05f C:\ghcup\ghc\9.6.2\bin\ghc-9.6.2.exe+0x2f5e05f
* 0x8f3c7fd8f0 0x7ff7d19deaf8 C:\ghcup\ghc\9.6.2\bin\ghc-9.6.2.exe+0x2f5eaf8
* 0x8f3c7fd8f8 0x7ff7d24818af C:\ghcup\ghc\9.6.2\bin\ghc-9.6.2.exe+0x3a018af
* 0x8f3c7fd900 0x7ef4f69385d0
* 0x8f3c7fd908 0x1ba0652d860
* 0x8f3c7fd910 0x4ee39
* 0x8f3c7fd918 0x7ef4f2ae7c40
Error: cabal-3.10.1.0.exe: Failed to build test:spec from hpack-0.35.2. The
build process terminated with exit code 11
~~~
At the [Haskell Community](https://discourse.haskell.org/t/cabals-foreign-library-stanza/6516/8?u=mpilgrem), it has been speculated that perhaps the fix of https://gitlab.haskell.org/ghc/ghc/-/issues/19421 has introduced a bug.
This may be Windows-specific, as the ubuntu-latest/GHC 9.6 and macos-latest/'system' GHC CI both pass. The ubuntu-latest/GHC 8.2 to GHC 9.4 also all pass. However, the CI does not test Windows pre-GHC 9.6.2.
## Steps to reproduce
I don't yet have a reproducer outside of the Hpack project CI script. Also, I can build and test the Hpack project at the commit in the PR using Stack and GHC 9.6.2, without a problem.
## Environment
* GHC version used: GHC 9.6.2
Optional:
* Operating System: Windows Server 2022
* System Architecture: x86_64Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/23531Panic with bad representation polymorphism + hs-boot2023-06-20T15:04:24ZKrzysztof GogolewskiPanic with bad representation polymorphism + hs-bootGiven
X.hs-boot
```haskell
{-# LANGUAGE TypeFamilies #-}
module X where
import GHC.Exts
type family T :: RuntimeRep
f :: forall (a :: TYPE T). a
```
X.hs
```haskell
module X where
import Y
```
Y.hs
```haskell
module Y where
import ...Given
X.hs-boot
```haskell
{-# LANGUAGE TypeFamilies #-}
module X where
import GHC.Exts
type family T :: RuntimeRep
f :: forall (a :: TYPE T). a
```
X.hs
```haskell
module X where
import Y
```
Y.hs
```haskell
module Y where
import {-# SOURCE #-} X
g () = f
```
compiling `ghc X` crashes:
```
[2 of 3] Compiling Y ( Y.hs, Y.o )
<no location info>: error:
panic! (the 'impossible' happened)
GHC version 9.7.20230615:
isUnliftedType
forall (a :: TYPE T). a :: TYPE T
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/GHC/Utils/Panic.hs:191:37 in ghc-9.7-inplace:GHC.Utils.Panic
pprPanic, called at compiler/GHC/Core/Type.hs:2295:22 in ghc-9.7-inplace:GHC.Core.Type
isUnliftedType, called at compiler/GHC/StgToCmm/Closure.hs:211:5 in ghc-9.7-inplace:GHC.StgToCmm.Closure
```
I suspect this will be fixed by #22109, when we check that top-level binds are lifted in the typechecker rather than the desugarer.https://gitlab.haskell.org/ghc/ghc/-/issues/23527Panic with a bad hs-boot file2023-06-15T14:53:31ZKrzysztof GogolewskiPanic with a bad hs-boot fileGiven two files:
M.hs-boot
```haskell
{-# LANGUAGE TypeFamilies #-}
module M where
import Data.Kind
type family T :: Type
f :: forall (x :: T). Maybe x
```
M.hs
```haskell
module M where
```
attempting to compile `ghc M.hs` crashes in...Given two files:
M.hs-boot
```haskell
{-# LANGUAGE TypeFamilies #-}
module M where
import Data.Kind
type family T :: Type
f :: forall (x :: T). Maybe x
```
M.hs
```haskell
module M where
```
attempting to compile `ghc M.hs` crashes in 9.4 and above:
```
[1 of 2] Compiling M[boot] ( M.hs-boot, M.o-boot )
<no location info>: error:
panic! (the 'impossible' happened)
GHC version 9.7.20230606:
Can't serialise IfaceHoleCo
```https://gitlab.haskell.org/ghc/ghc/-/issues/23451Build error: fixup value out of range when ipe flavour transformer turned on2023-09-07T09:12:05ZIan-Woo KimBuild error: fixup value out of range when ipe flavour transformer turned onWhen I try to build GHC with `ipe` flavour transformer, the build failed here: (when compiling GHC.Parser)
```
$ hadrian/build -j --flavour=Quick+ipe
...
| Run Ghc CompileHs Stage1: compiler/GHC/Tc/Solver.hs => _build/stage1/compiler/bui...When I try to build GHC with `ipe` flavour transformer, the build failed here: (when compiling GHC.Parser)
```
$ hadrian/build -j --flavour=Quick+ipe
...
| Run Ghc CompileHs Stage1: compiler/GHC/Tc/Solver.hs => _build/stage1/compiler/build/GHC/Tc/Solver.o
Command line: _build/stage0/bin/ghc -Wall -Wcompat -dynamic-too -hisuf hi -osuf o -hcsuf hc -static -hide-all-packages -no-user-package-db '-package-env -' '-package-db _build/stage1/inplace/package.conf.d' '-this-unit-id ghc-9.7-inplace' '-package-id array-0.5.5.0-inplace' '-package-id base-4.18.0.0-inplace' '-package-id binary-0.8.9.1-inplace' '-package-id bytestring-0.11.4.0-inplace' '-package-id containers-0.6.7-inplace' '-package-id deepseq-1.4.8.1-inplace' '-package-id directory-1.3.8.1-inplace' '-package-id exceptions-0.10.7-inplace' '-package-id filepath-1.4.100.1-inplace' '-package-id ghc-boot-9.7-inplace' '-package-id ghc-heap-9.7-inplace' '-package-id ghci-9.7-inplace' '-package-id hpc-0.6.2.0-inplace' '-package-id process-1.6.17.0-inplace' '-package-id semaphore-compat-1.0.0-inplace' '-package-id stm-2.5.1.0-inplace' '-package-id template-haskell-2.20.0.0-inplace' '-package-id time-1.12.2-inplace' '-package-id transformers-0.6.1.0-inplace' '-package-id unix-2.8.1.0-inplace' -i -i/Users/ianwookim/repo/srcc/ghcHEAD/_build/stage1/compiler/build -i/Users/ianwookim/repo/srcc/ghcHEAD/_build/stage1/compiler/build/autogen -i/Users/ianwookim/repo/srcc/ghcHEAD/compiler -Irts/include -I_build/stage1/compiler/build -I_build/stage1/compiler/build/. -Icompiler/. -I/Users/ianwookim/repo/srcc/ghcHEAD/libraries/process/include -I/Users/ianwookim/repo/srcc/ghcHEAD/_build/stage1/libraries/process/build/include -I/Users/ianwookim/repo/srcc/ghcHEAD/libraries/directory -I/Users/ianwookim/repo/srcc/ghcHEAD/_build/stage1/libraries/directory/build -I/Users/ianwookim/repo/srcc/ghcHEAD/libraries/unix/include -I/Users/ianwookim/repo/srcc/ghcHEAD/_build/stage1/libraries/unix/build/include -I/Users/ianwookim/repo/srcc/ghcHEAD/libraries/time/lib/include -I/Users/ianwookim/repo/srcc/ghcHEAD/_build/stage1/libraries/time/build/lib/include -I/Users/ianwookim/repo/srcc/ghcHEAD/libraries/containers/containers/include -I/Users/ianwookim/repo/srcc/ghcHEAD/_build/stage1/libraries/containers/containers/build/include -I/Users/ianwookim/repo/srcc/ghcHEAD/libraries/bytestring/include -I/Users/ianwookim/repo/srcc/ghcHEAD/_build/stage1/libraries/bytestring/build/include -I/Users/ianwookim/repo/srcc/ghcHEAD/libraries/base/include -I/Users/ianwookim/repo/srcc/ghcHEAD/_build/stage1/libraries/base/build/include -I/Users/ianwookim/repo/srcc/ghcHEAD/libraries/ghc-bignum/include/ -I/Users/ianwookim/repo/srcc/ghcHEAD/_build/stage1/libraries/ghc-bignum/build/include/ -I/Users/ianwookim/repo/srcc/ghcHEAD/rts/include -I/Users/ianwookim/repo/srcc/ghcHEAD/_build/stage1/rts/build/include -optP-include -optP_build/stage1/compiler/build/autogen/cabal_macros.h -optc--target=arm64-apple-darwin -optP-DHAVE_INTERNAL_INTERPRETER -optP-DCAN_LOAD_DLL -outputdir _build/stage1/compiler/build -fdiagnostics-color=always -Wall -Wno-name-shadowing -Wnoncanonical-monad-instances -Wnoncanonical-monoid-instances -XHaskell2010 -XNoImplicitPrelude -XBangPatterns -XScopedTypeVariables -XMonoLocalBinds -XTypeOperators -no-global-package-db -package-db=/Users/ianwookim/repo/srcc/ghcHEAD/_build/stage1/inplace/package.conf.d -ghcversion-file=rts/include/ghcversion.h -ghcversion-file=rts/include/ghcversion.h -Wnoncanonical-monad-instances -optc-Wno-unknown-pragmas -optP-Wno-nonportable-include-path -c _build/stage1/compiler/build/GHC/Parser.hs -o _build/stage1/compiler/build/GHC/Parser.o -O0 -H64m -finfo-table-map -fdistinct-constructor-tables -fno-ignore-interface-pragmas -fcmm-sink -haddock -Winvalid-haddock -Wno-deprecated-flags -Wcpp-undef
===> Command failed with error code: 1
/tmp/nix-shell.eNdd3H/ghc58850_0/ghc_3.s:36865:2: error:
error: fixup value out of range
b.hi LcHST
^
|
36865 | b.hi LcHST
| ^
/tmp/nix-shell.eNdd3H/ghc58850_0/ghc_3.s:36883:2: error:
error: fixup value out of range
b.hi LcHSW
^
|
36883 | b.hi LcHSW
| ^
...
```
building GHC 9.7.20230522
on Aarch64 macbook m1, macOS 13.2.19.8.2Andreas KlebingerAndreas Klebingerhttps://gitlab.haskell.org/ghc/ghc/-/issues/23350Backpack panic: Duplicate nodes keys in backpack file2023-05-05T13:01:10Zsheafsam.derbyshire@gmail.comBackpack panic: Duplicate nodes keys in backpack fileConsider this `.bkp` file:
```haskell
unit p where
signature H where
unit q where
module H where
unit r where
dependency p
dependency q[H=p:H]
```
There's a mistake: we mixed up `p` and `q` in the unit `r`.
This causes the f...Consider this `.bkp` file:
```haskell
unit p where
signature H where
unit q where
module H where
unit r where
dependency p
dependency q[H=p:H]
```
There's a mistake: we mixed up `p` and `q` in the unit `r`.
This causes the following panic:
```
ghc: panic! (the 'impossible' happened)
GHC version 9.7.20230504:
Duplicate nodes keys in backpack file
[q+q-9dU7VXZcSfk3MwGleJHyst:H, q+q-9dU7VXZcSfk3MwGleJHyst:H]
```
I am inclined to believe this is a bkpism (affects only the `.bkp` format and not `cabal` projects that use Backpack), but I haven't checked.https://gitlab.haskell.org/ghc/ghc/-/issues/23329"Iface type variable out of scope" with poly-kinded associated type and newty...2023-08-04T00:08:51Zgelisam"Iface type variable out of scope" with poly-kinded associated type and newtype-deriving## Summary
When a newtype-derived instance involving a kind-polymorphic associated type is called and optimized, ghc-9.4.2 prints the following error:
```
typecheckIface
Declaration for $fMyClassTYPEMyMaybe
Unfolding of $fMyClassTYPEMy...## Summary
When a newtype-derived instance involving a kind-polymorphic associated type is called and optimized, ghc-9.4.2 prints the following error:
```
typecheckIface
Declaration for $fMyClassTYPEMyMaybe
Unfolding of $fMyClassTYPEMyMaybe:
Iface type variable out of scope: k
<no location info>: error:
Cannot continue after interface file error
```
There are two parts to this error message: the `Iface type variable out of scope` part is a regression introduced in ghc-9.0, while the `Cannot continue after interface file error` part is a regression introduced in ghc-9.4.
I found several issues from years ago featuring this error message, triggered by increasingly-obscure circumstances. This is yet another obscure circumstance. #9263 is the most closely related, as it also involves associated types and polykinds, but not newtype-deriving. #2018 is also related in that it also requires optimizations to be turned on.
Note that some of those tickets say that the error only occurs the _second_ time the code is built. This is not the case here, the error occurs the first time.
## Steps to reproduce
The easiest way to reproduce the problem is to clone https://github.com/gelisam/ghc-9.4-bug and to run `./build.sh`. Alternatively, create those two modules:
```haskell
{-# LANGUAGE GeneralizedNewtypeDeriving #-}
{-# LANGUAGE PolyKinds #-}
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE UndecidableInstances #-}
module MyModule where
import Data.Kind (Type)
import Data.Proxy (Proxy)
class MyClass (f :: k -> Type) where
type MyTypeFamily f (i :: k) :: Type
myMethod :: MyTypeFamily f i -> Proxy f -> Proxy i -> ()
instance MyClass Maybe where
type MyTypeFamily Maybe i = ()
myMethod = undefined
newtype MyMaybe a = MyMaybe (Maybe a)
deriving MyClass
```
and
```haskell
{-# LANGUAGE TypeApplications #-}
module Foo where
import Data.Kind (Type)
import Data.Proxy (Proxy(Proxy))
import MyModule
foo :: ()
foo = myMethod @Type @MyMaybe @() () Proxy Proxy
```
Then compile those two modules, with optimizations turned on:
```bash
$ ghc -O MyModule.hs Foo.hs
[2 of 2] Compiling Foo ( Foo.hs, Foo.o )
typecheckIface
Declaration for $fMyClassTYPEMyMaybe
Unfolding of $fMyClassTYPEMyMaybe:
Iface type variable out of scope: k
<no location info>: error:
Cannot continue after interface file error
```
## Expected behavior
I expect the two modules to compile successfully.
## Environment
* GHC version used: ghc-9.4.2, ghc-9.2.4, ghc-9.0.2
Of these, only ghc-9.4 fails to compile.
With ghc-9.2 and ghc-9.0, the `Iface type variable out of scope` message is printed but not `Cannot continue after interface file error`, and the module still compiles successfully.
I have also tried with ghc-8.10.7, which does not print either message.
Optional:
* Operating System: macOS Ventura 13.3
* System Architecture: arm649.6.2Ryan ScottRyan Scotthttps://gitlab.haskell.org/ghc/ghc/-/issues/23217Test of atomic fetches fails on i386 with allocateRegsAndSpill panic2023-04-05T16:12:10ZBodigrimTest of atomic fetches fails on i386 with allocateRegsAndSpill panicAn i386 job for !10228 (https://gitlab.haskell.org/ghc/ghc/-/jobs/1435453#L4752) fails with:
```
Compile failed (exit code 1) errors were:
ghc-9.7.20230402: panic! (the 'impossible' happened)
GHC version 9.7.20230402:
allocateRegsAndS...An i386 job for !10228 (https://gitlab.haskell.org/ghc/ghc/-/jobs/1435453#L4752) fails with:
```
Compile failed (exit code 1) errors were:
ghc-9.7.20230402: panic! (the 'impossible' happened)
GHC version 9.7.20230402:
allocateRegsAndSpill: Cannot read from uninitialized register
%vHi_H3
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/GHC/Utils/Panic.hs:189:37 in ghc:GHC.Utils.Panic
pprPanic, called at compiler/GHC/CmmToAsm/Reg/Linear.hs:837:20 in ghc:GHC.CmmToAsm.Reg.Linear
CallStack (from HasCallStack):
panic, called at compiler/GHC/Utils/Error.hs:480:29 in ghc:GHC.Utils.Error
```
`GHC.CmmToAsm.Reg.Linear` says
```haskell
pprPanic "allocateRegsAndSpill: Cannot read from uninitialized register" (ppr r)
-- NOTE: if the input to the NCG contains some
-- unreachable blocks with junk code, this panic
-- might be triggered. Make sure you only feed
-- sensible code into the NCG. In GHC.Cmm.Pipeline we
-- call removeUnreachableBlocks at the end for this
-- reason.
```
This might be very well the case: !10228 adds a test case with hand-written CMM. However, while the code in question is silly, up to my (very limited) understanding all blocks should be reachable. And all 64-bit jobs succeed.
This is not a blocker for !10228 (#23206) which is concerned only with adding `%fetch_fooXX` primops to CMM parser. I'm going to disable i386 job there.Andreas KlebingerAndreas Klebingerhttps://gitlab.haskell.org/ghc/ghc/-/issues/23210GHCi 9.4.4 segfault when loading asl-translator2024-03-12T12:05:20ZRyan ScottGHCi 9.4.4 segfault when loading asl-translatorGHCi (as invoked through `cabal repl`) can segfault with GHC 9.4.4 when invoked on the [`asl-translator`](https://github.com/GaloisInc/asl-translator/) library. To reproduce:
```
$ git clone https://github.com/GaloisInc/asl-translator &...GHCi (as invoked through `cabal repl`) can segfault with GHC 9.4.4 when invoked on the [`asl-translator`](https://github.com/GaloisInc/asl-translator/) library. To reproduce:
```
$ git clone https://github.com/GaloisInc/asl-translator && cd asl-translator/
$ git checkout cabal-repl-segfault
$ git submodule update --init
$ ln -s cabal.project.newbuild cabal.project
$ cabal repl -w ghc-9.4.4
```
This will eventually segfault:
```
$ cabal repl -w ghc-9.4.4
Build profile: -w ghc-9.4.4 -O1
In order, the following will be built (use -v for more details):
- asl-translator-0.1.0.0 (lib) (first run)
Preprocessing library for asl-translator-0.1.0.0..
GHCi, version 9.4.4: https://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /home/ryanglscott/.ghci
[ 1 of 26] Compiling Data.Parameterized.CtxFuns ( lib/Data/Parameterized/CtxFuns.hs, interpreted )
[ 2 of 26] Compiling Data.Parameterized.AssignTree ( lib/Data/Parameterized/AssignTree.hs, interpreted )
[ 3 of 26] Compiling Data.Parameterized.SomeSome ( lib/Data/Parameterized/SomeSome.hs, interpreted )
[ 4 of 26] Compiling Language.ASL.Crucible.Exceptions ( lib/Language/ASL/Crucible/Exceptions.hs, interpreted )
[ 5 of 26] Compiling Language.ASL.Formulas.Attach ( lib/Language/ASL/Formulas/Attach.hs, interpreted )
[ 6 of 26] Compiling Language.ASL.Formulas.Serialize ( lib/Language/ASL/Formulas/Serialize.hs, interpreted )
[ 7 of 26] Compiling Language.ASL.Types ( lib/Language/ASL/Types.hs, interpreted )
[ 8 of 26] Compiling Language.ASL.Globals.Types ( lib/Language/ASL/Globals/Types.hs, interpreted )
[ 9 of 26] Compiling Paths_asl_translator ( /home/ryanglscott/Documents/Hacking/Haskell/asl-translator/dist-newstyle/build/x86_64-linux/ghc-9.4.4/asl-translator-0.1.0.0/build/autogen/Paths_asl_translator.hs, interpreted )
[10 of 26] Compiling Language.ASL.Formulas ( lib/Language/ASL/Formulas.hs, interpreted )
[11 of 26] Compiling Util.Log ( lib/Util/Log.hs, interpreted )
[12 of 26] Compiling Language.ASL.SyntaxTraverse ( lib/Language/ASL/SyntaxTraverse.hs, interpreted )
[13 of 26] Compiling Language.ASL.StaticExpr ( lib/Language/ASL/StaticExpr.hs, interpreted )
[14 of 26] Compiling Language.ASL.Signature ( lib/Language/ASL/Signature.hs, interpreted )
[15 of 26] Compiling Language.ASL.Translation.Exceptions ( lib/Language/ASL/Translation/Exceptions.hs, interpreted )
[16 of 26] Compiling Language.ASL.Crucible.Extension ( lib/Language/ASL/Crucible/Extension.hs, interpreted )
[17 of 26] Compiling Language.ASL.Globals.Definitions ( lib/Language/ASL/Globals/Definitions.hs, interpreted )
[18 of 26] Compiling Language.ASL.Globals ( lib/Language/ASL/Globals.hs, interpreted )
[19 of 26] Compiling Language.ASL.Translation.Preprocess ( lib/Language/ASL/Translation/Preprocess.hs, interpreted )
[20 of 26] Compiling Language.ASL.Translation ( lib/Language/ASL/Translation.hs, interpreted )
[21 of 26] Compiling Language.ASL.Globals.ConsistencyCheck ( lib/Language/ASL/Globals/ConsistencyCheck.hs, interpreted )
Globals consistency check passed.
[22 of 26] Compiling Language.ASL.Crucible ( lib/Language/ASL/Crucible.hs, interpreted )
[23 of 26] Compiling Language.ASL ( lib/Language/ASL.hs, interpreted )
[24 of 26] Compiling What4.Expr.ExprTree ( lib/What4/Expr/ExprTree.hs, interpreted )
[25 of 26] Compiling Language.ASL.Formulas.Normalize ( lib/Language/ASL/Formulas/Normalize.hs, interpreted )
Error: cabal: repl failed for asl-translator-0.1.0.0. The build process
segfaulted (i.e. SIGSEGV).
```
The exact location of the segfault is somewhat nondeterministic, but it does segfault fairly reliably. If I load the GHCi command that `cabal repl` uses into `gdb`, here is the backtrace that I get:
```
(gdb) r
Starting program: /home/ryanglscott/.ghcup/ghc/9.4.4/lib/ghc-9.4.4/bin/ghc-9.4.4 -B/home/ryanglscott/.ghcup/ghc/9.4.4/lib/ghc-9.4.4/lib --interactive -fbuilding-cabal-package -O0 -outputdir /home/ryanglscott/Documents/Hacking/Haskell/asl-translator/dist-newstyle/build/x86_64-linux/ghc-9.4.4/asl-translator-0.1.0.0/build -odir /home/ryanglscott/Documents/Hacking/Haskell/asl-translator/dist-newstyle/build/x86_64-linux/ghc-9.4.4/asl-translator-0.1.0.0/build -hidir /home/ryanglscott/Documents/Hacking/Haskell/asl-translator/dist-newstyle/build/x86_64-linux/ghc-9.4.4/asl-translator-0.1.0.0/build -stubdir /home/ryanglscott/Documents/Hacking/Haskell/asl-translator/dist-newstyle/build/x86_64-linux/ghc-9.4.4/asl-translator-0.1.0.0/build -i -i/home/ryanglscott/Documents/Hacking/Haskell/asl-translator/dist-newstyle/build/x86_64-linux/ghc-9.4.4/asl-translator-0.1.0.0/build -ilib -i/home/ryanglscott/Documents/Hacking/Haskell/asl-translator/dist-newstyle/build/x86_64-linux/ghc-9.4.4/asl-translator-0.1.0.0/build/autogen -i/home/ryanglscott/Documents/Hacking/Haskell/asl-translator/dist-newstyle/build/x86_64-linux/ghc-9.4.4/asl-translator-0.1.0.0/build/global-autogen -I/home/ryanglscott/Documents/Hacking/Haskell/asl-translator/dist-newstyle/build/x86_64-linux/ghc-9.4.4/asl-translator-0.1.0.0/build/autogen -I/home/ryanglscott/Documents/Hacking/Haskell/asl-translator/dist-newstyle/build/x86_64-linux/ghc-9.4.4/asl-translator-0.1.0.0/build/global-autogen -I/home/ryanglscott/Documents/Hacking/Haskell/asl-translator/dist-newstyle/build/x86_64-linux/ghc-9.4.4/asl-translator-0.1.0.0/build -optP-DUNSAFE_OPS -optP-include -optP/home/ryanglscott/Documents/Hacking/Haskell/asl-translator/dist-newstyle/build/x86_64-linux/ghc-9.4.4/asl-translator-0.1.0.0/build/autogen/cabal_macros.h -this-unit-id asl-translator-0.1.0.0-inplace -hide-all-packages -Wmissing-home-modules -no-user-package-db -package-db /home/ryanglscott/.cabal/store/ghc-9.4.4/package.db -package-db /home/ryanglscott/Documents/Hacking/Haskell/asl-translator/dist-newstyle/packagedb/ghc-9.4.4 -package-db /home/ryanglscott/Documents/Hacking/Haskell/asl-translator/dist-newstyle/build/x86_64-linux/ghc-9.4.4/asl-translator-0.1.0.0/package.conf.inplace -package-id asl-parser-0.1.0.0-inplace -package-id base-4.17.0.0 -package-id bimap-0.5.0-3b15adda40d4922b46c85076cf11369c03274438eb0359027a2434a2d2edd653 -package-id bv-sized-1.0.5-f17825e2874d236830abebde418f7b72a4774e505cf78248e8a7e9b41d2e1064 -package-id bytestring-0.11.3.1 -package-id constraints-0.13.4-a9b8de62844560532ee38a46973dea5a26f2efbb61364fc5c2ddb27322cfff52 -package-id containers-0.6.6 -package-id crucible-0.6-inplace -package-id directory-1.3.7.1 -package-id dismantle-arm-xml-0.1.0.0-inplace -package-id dismantle-tablegen-0.1.0.0-inplace -package-id filepath-1.4.2.2 -package-id hashtables-1.3.1-8d533a8bc96c226c6a43cedc70a9b4ef1b643180fe18e6e04332f9b5a5f5e996 -package-id ilist-0.3.1.0-6f42c3f1b3d731eaabf90f776f807ea8e2a540d287a5a1bca2b8450e1c6b214d -package-id integer-logarithms-1.0.3.1-618ebf7c0d76b1ec7b0b074924d94de36f135e3b7d3a4e6c9eb71462855ccfe9 -package-id lens-5.2.2-80e4922b0bee2814d2ab07afae5c9faa4f804b8e9686f68ed37a3ea2b97259f0 -package-id mtl-2.2.2 -package-id ordered-containers-0.2.3-8c94e06e333e9bd5ee07233242fb14e0875c0eacd2632294b3e4df6ae1b37252 -package-id panic-0.4.0.1-521f633e3a59ef27711a5e6dbc97cfe583471f760788a62531cabac0cd06db6d -package-id parameterized-utils-2.1.6.0-3a943e5a6f1741aec74c0ee5270e433827b1d7930ceca347eb6e4475848fcbe0 -package-id pretty-1.1.3.6 -package-id prettyprinter-1.7.1-8966f7b39b126d3e6f23d7914649ea33b634b07705b4f7f4e0ca6c0273a7b1e1 -package-id s-cargot-0.1.5.0-05c503815f8a951225a70859c03ab6d507830db8de509e1fc134849051c41740 -package-id split-0.2.3.5-664cbef9d9510ef46c911401b98fe75ad86fdb2be72b13d114d0f7b35fa4f858 -package-id template-haskell-2.19.0.0 -package-id text-2.0.1 -package-id th-compat-0.1.4-92fbb1b1d68867a00b991509e9f99b4c2cdb11c25483de43688b2a4817292aba -package-id time-1.12.2 -package-id transformers-0.5.6.2 -package-id unliftio-core-0.2.1.0-6de77af027be946d76cd07c9970717ae828984b83829a82f3ba640e41f191b02 -package-id vector-0.13.0.0-4b8db3c68269623013c3dfb3c43bc2f75bae6ebf6f4324d50e35712f9995c0d1 -package-id what4-1.4.0.0.99-inplace -package-id zlib-0.6.3.0-7ea06883421c776c2de6a75fab769898002985f65fddb96d9caa7a11f23158a6 -XHaskell2010 Language.ASL Language.ASL.Crucible Language.ASL.Crucible.Extension Language.ASL.Crucible.Exceptions Language.ASL.Signature Language.ASL.Translation Language.ASL.Translation.Preprocess Language.ASL.Translation.Driver Language.ASL.Translation.Exceptions Language.ASL.SyntaxTraverse Language.ASL.Types Language.ASL.Formulas.Serialize Language.ASL.Formulas.Normalize Language.ASL.StaticExpr Language.ASL.Globals Language.ASL.Globals.Types Language.ASL.Globals.Definitions Language.ASL.Globals.ConsistencyCheck Data.Parameterized.CtxFuns Data.Parameterized.AssignTree Data.Parameterized.SomeSome Language.ASL.Formulas.Attach Language.ASL.Formulas Util.Log What4.Expr.ExprTree Paths_asl_translator -Wcompat -Wall -hide-all-packages
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffef107700 (LWP 684162)]
[New Thread 0x7fffee906700 (LWP 684163)]
[New Thread 0x7fffee105700 (LWP 684164)]
[New Thread 0x7fffed904700 (LWP 684165)]
GHCi, version 9.4.4: https://www.haskell.org/ghc/ :? for help
[Detaching after vfork from child process 684166]
[Detaching after vfork from child process 684167]
[Detaching after vfork from child process 684168]
[Detaching after vfork from child process 684169]
[Detaching after vfork from child process 684170]
[Detaching after vfork from child process 684171]
[Detaching after vfork from child process 684172]
[Detaching after vfork from child process 684173]
Loaded GHCi configuration from /home/ryanglscott/.ghci
[Detaching after vfork from child process 684174]
[Detaching after vfork from child process 684176]
[Detaching after vfork from child process 684178]
[Detaching after vfork from child process 684180]
[Detaching after vfork from child process 684182]
[Detaching after vfork from child process 684184]
[Detaching after vfork from child process 684186]
[New Thread 0x7fffd9660700 (LWP 684188)]
[ 1 of 26] Compiling Data.Parameterized.CtxFuns ( lib/Data/Parameterized/CtxFuns.hs, interpreted )
[ 2 of 26] Compiling Data.Parameterized.AssignTree ( lib/Data/Parameterized/AssignTree.hs, interpreted )
[ 3 of 26] Compiling Data.Parameterized.SomeSome ( lib/Data/Parameterized/SomeSome.hs, interpreted )
[ 4 of 26] Compiling Language.ASL.Crucible.Exceptions ( lib/Language/ASL/Crucible/Exceptions.hs, interpreted )
[ 5 of 26] Compiling Language.ASL.Formulas.Attach ( lib/Language/ASL/Formulas/Attach.hs, interpreted )
[ 6 of 26] Compiling Language.ASL.Formulas.Serialize ( lib/Language/ASL/Formulas/Serialize.hs, interpreted )
[ 7 of 26] Compiling Language.ASL.Types ( lib/Language/ASL/Types.hs, interpreted )
[ 8 of 26] Compiling Language.ASL.Globals.Types ( lib/Language/ASL/Globals/Types.hs, interpreted )
[ 9 of 26] Compiling Paths_asl_translator ( /home/ryanglscott/Documents/Hacking/Haskell/asl-translator/dist-newstyle/build/x86_64-linux/ghc-9.4.4/asl-translator-0.1.0.0/build/autogen/Paths_asl_translator.hs, interpreted )
[10 of 26] Compiling Language.ASL.Formulas ( lib/Language/ASL/Formulas.hs, interpreted )
[11 of 26] Compiling Util.Log ( lib/Util/Log.hs, interpreted )
[12 of 26] Compiling Language.ASL.SyntaxTraverse ( lib/Language/ASL/SyntaxTraverse.hs, interpreted )
[13 of 26] Compiling Language.ASL.StaticExpr ( lib/Language/ASL/StaticExpr.hs, interpreted )
[14 of 26] Compiling Language.ASL.Signature ( lib/Language/ASL/Signature.hs, interpreted )
[15 of 26] Compiling Language.ASL.Translation.Exceptions ( lib/Language/ASL/Translation/Exceptions.hs, interpreted )
[16 of 26] Compiling Language.ASL.Crucible.Extension ( lib/Language/ASL/Crucible/Extension.hs, interpreted )
[17 of 26] Compiling Language.ASL.Globals.Definitions ( lib/Language/ASL/Globals/Definitions.hs, interpreted )
[18 of 26] Compiling Language.ASL.Globals ( lib/Language/ASL/Globals.hs, interpreted )
[19 of 26] Compiling Language.ASL.Translation.Preprocess ( lib/Language/ASL/Translation/Preprocess.hs, interpreted )
[20 of 26] Compiling Language.ASL.Translation ( lib/Language/ASL/Translation.hs, interpreted )
[21 of 26] Compiling Language.ASL.Globals.ConsistencyCheck ( lib/Language/ASL/Globals/ConsistencyCheck.hs, interpreted )
Globals consistency check passed.
[22 of 26] Compiling Language.ASL.Crucible ( lib/Language/ASL/Crucible.hs, interpreted )
[23 of 26] Compiling Language.ASL ( lib/Language/ASL.hs, interpreted )
[24 of 26] Compiling What4.Expr.ExprTree ( lib/What4/Expr/ExprTree.hs, interpreted )
[25 of 26] Compiling Language.ASL.Formulas.Normalize ( lib/Language/ASL/Formulas/Normalize.hs, interpreted )
Thread 5 "ghc-9.4.4:w" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffed904700 (LWP 684165)]
evacuate1 (p=p@entry=0x425a2d6e00) at rts/sm/Evac.c:704
704 rts/sm/Evac.c: No such file or directory.
(gdb) bt
#0 evacuate1 (p=p@entry=0x425a2d6e00) at rts/sm/Evac.c:704
#1 0x00007fffefd95ef4 in scavenge_block1 (bd=0x425a203580) at rts/sm/Scav.c:601
#2 0x00007fffefdda291 in scavenge_find_work () at rts/sm/Scav.c:2131
#3 scavenge_loop1 () at rts/sm/Scav.c:2178
#4 0x00007fffefdd052a in scavenge_until_all_done () at rts/sm/GC.c:1317
#5 0x00007fffefdd1e32 in GarbageCollect (collect_gen=<optimized out>, collect_gen@entry=1,
do_heap_census=do_heap_census@entry=false, is_overflow_gc=is_overflow_gc@entry=true,
deadlock_detect=deadlock_detect@entry=false, gc_type=gc_type@entry=2, cap=cap@entry=0x5e2050, idle_cap=<optimized out>)
at rts/sm/GC.c:552
#6 0x00007fffefdb56f9 in scheduleDoGC (pcap=pcap@entry=0x7fffed903e70, task=task@entry=0x5fa060,
force_major=force_major@entry=false, is_overflow_gc=<optimized out>, deadlock_detect=deadlock_detect@entry=false)
at rts/Schedule.c:1859
#7 0x00007fffefdb64c5 in schedule (initialCapability=initialCapability@entry=0x7fffefe181c0 <MainCapability>,
task=task@entry=0x5fa060) at rts/Schedule.c:580
#8 0x00007fffefdb7b4c in scheduleWorker (cap=cap@entry=0x7fffefe181c0 <MainCapability>, task=task@entry=0x5fa060)
at rts/Schedule.c:2644
#9 0x00007fffefdbc707 in workerStart (task=0x5fa060) at rts/Task.c:444
#10 0x00007fffefcfe609 in start_thread (arg=<optimized out>) at pthread_create.c:477
#11 0x00007fffefb9d133 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
```
(I apologize for the very non-minimal reproducer, as I haven't found a way to minimize this.)
I am using 64-bit Ubuntu 20.04, in case that is important.9.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/23111Core Lint error with -fdefer-type-errors and kind error2023-03-14T15:16:29ZKrzysztof GogolewskiCore Lint error with -fdefer-type-errors and kind errorThe following program fails `ghc -dcore-lint -fdefer-type-errors`
```haskell
{-# LANGUAGE TypeFamilies #-}
module M where
import Data.Kind
type F :: Type
type family F
type G :: F
type family G
x :: G
x = ()
```
<details>
```haske...The following program fails `ghc -dcore-lint -fdefer-type-errors`
```haskell
{-# LANGUAGE TypeFamilies #-}
module M where
import Data.Kind
type F :: Type
type family F
type G :: F
type family G
x :: G
x = ()
```
<details>
```haskell
*** Core Lint errors : in result of Desugar (before optimization) ***
<no location info>: warning:
Non-CoVar has coercion type co_awK :: F ~# *
Substitution: <InScope = {}
IdSubst = []
TvSubst = []
CvSubst = []>
*** Offending Program ***
Rec {
co_awK :: F ~# *
[LclId[CoVarId]]
co_awK
= case typeError
@LiftedRep
@()
"M.hs:12:6: error: [GHC-83865]\n\
\ \\226\\128\\162 Expected a type, but \\226\\128\\152G\\226\\128\\153 has kind \\226\\128\\152F\\226\\128\\153\n\
\ \\226\\128\\162 In the type signature: x :: G\n\
\(deferred type error)"#
of wild_00 {
}
$trModule :: Module
[LclIdX]
$trModule = Module (TrNameS "main"#) (TrNameS "M"#)
x :: (G |> co_awK)
[LclIdX]
x = case case typeError
@LiftedRep
@()
"M.hs:13:5: error: [GHC-18872]\n\
\ \\226\\128\\162 Couldn't match kind \\226\\128\\152F\\226\\128\\153 with \\226\\128\\152*\\226\\128\\153\n\
\ When matching types\n\
\ G :: F\n\
\ () :: *\n\
\ \\226\\128\\162 In the expression: ()\n\
\ In an equation for \\226\\128\\152x\\226\\128\\153: x = ()\n\
\(deferred type error)"#
of wild_00 {
}
of co_ayG
{ __DEFAULT ->
case case typeError
@LiftedRep
@()
"M.hs:13:5: error: [GHC-18872]\n\
\ \\226\\128\\162 Couldn't match kind \\226\\128\\152F\\226\\128\\153 with \\226\\128\\152*\\226\\128\\153\n\
\ When matching types\n\
\ G :: F\n\
\ () :: *\n\
\ \\226\\128\\162 In the expression: ()\n\
\ In an equation for \\226\\128\\152x\\226\\128\\153: x = ()\n\
\(deferred type error)"#
of wild_00 {
}
of co_ayH
{ __DEFAULT ->
()
`cast` (Sub (Sym (co_ayH
; Sym (GRefl nominal () (Sym co_ayG)))
; GRefl nominal G co_awK)
:: () ~R# (G |> co_awK))
}
}
end Rec }
```
</details>https://gitlab.haskell.org/ghc/ghc/-/issues/23080Backpack nameModule panic2023-03-06T14:03:11Zsheafsam.derbyshire@gmail.comBackpack nameModule panicThe following variation on the `bkpreex01` test causes a panic:
```haskell
unit t23080-unit1 where
signature H1 where
data T
unit t23080-unit2 where
dependency t23080-unit1[H1=<H2>]
module B where
data T = MkT
signature ...The following variation on the `bkpreex01` test causes a panic:
```haskell
unit t23080-unit1 where
signature H1 where
data T
unit t23080-unit2 where
dependency t23080-unit1[H1=<H2>]
module B where
data T = MkT
signature H2(T(MkT)) where
import B
```
```
λ ghc --backpack T23080.bkp
[1 of 2] Processing t23080-unit1
[1 of 1] Compiling H1[sig] ( t23080-unit1\H1.hsig, nothing )
[2 of 2] Processing t23080-unit2
[1 of 3] Compiling B ( t23080-unit2\B.hs, nothing )
[2 of 3] Compiling H2[sig] ( t23080-unit2\H2.hsig, nothing )
<no location info>: error:
panic! (the 'impossible' happened)
GHC version 9.4.4:
nameModule
internal MkT_02y
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler\GHC\Utils\Panic.hs:182:37 in ghc:GHC.Utils.Panic
pprPanic, called at compiler\GHC\Types\Name.hs:325:3 in ghc:GHC.Types.Name
Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug
```
The issue has to do with the export of the data constructor `MkT` from `H2`... changing the export to `T(..)` makes the panic go away.