GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2023-03-06T14:03:11Zhttps://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.https://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/23138GHC Panic: loadArchive trying to load Nix's clang++ wrapper (darwin-aarch64)2024-03-10T11:39:42ZTravis Whitakerpi.boy.travis@gmail.comGHC Panic: loadArchive trying to load Nix's clang++ wrapper (darwin-aarch64)It seems something has changed about archive loading in the 9.x series (at least 9.2.7 and 9.4.4) that makes GHC not like the shell environment that Nix provides on darwin-aarch64. As is the case strangely often for me, accelerate is the...It seems something has changed about archive loading in the 9.x series (at least 9.2.7 and 9.4.4) that makes GHC not like the shell environment that Nix provides on darwin-aarch64. As is the case strangely often for me, accelerate is the only package I've found that reproduces this. Please forgive the annoying repro, I'm still searching for a smaller one.
First, clone the `loadarchive-bug` branch of my fork of accelerate [here](https://github.com/TravisWhitaker/accelerate/tree/loadarchive-bug). All I've done here is bump `base` in `accelerate.cabal`, and provided two minimal `shell.nix` files that give GHC 9.2.7 or GHC 9.4.4, plus Nixpkgs' current stdenv for darwin-aarch64. Then, all you have to do (with either the 927-shell.nix or 944-shell.nix) is:
```
$ cat shell.nix
let pkgsrc = builtins.fetchGit
{
url = "https://github.com/nixos/nixpkgs";
ref = "master";
rev = "38637c5c8fddf9c5b454918acf309c55e3809af1";
};
in with import pkgsrc {};
let thisghc = haskell.packages.ghc927.ghcWithPackages (p: [p.cabal-install]);
in mkShell
{
packages = [thisghc];
}
$ nix-shell --pure
[nix-shell:~/sources/accelerate]$ cabal clean
[nix-shell:~/sources/accelerate]$ cabal build
Resolving dependencies...
Build profile: -w ghc-9.2.7 -O1
In order, the following will be built (use -v for more details):
- accelerate-1.3.0.0 (lib:accelerate) (first run)
[1 of 1] Compiling Main ( /Users/twhitaker/sources/accelerate/dist-newstyle/build/aarch64-osx/ghc-9.2.7/accelerate-1.3.0.0/setup/setup.hs, /Users/twhitaker/sources/accelerate/dist-newstyle/build/aarch64-osx/ghc-9.2.7/accelerate-1.3.0.0/setup/Main.o )
Linking /Users/twhitaker/sources/accelerate/dist-newstyle/build/aarch64-osx/ghc-9.2.7/accelerate-1.3.0.0/setup/setup ...
Configuring accelerate-1.3.0.0...
Preprocessing library for accelerate-1.3.0.0..
Building library for accelerate-1.3.0.0..
[ 1 of 109] Compiling Crypto.Hash.XKCP ( src/Crypto/Hash/XKCP.hs, /Users/twhitaker/sources/accelerate/dist-newstyle/build/aarch64-osx/ghc-9.2.7/accelerate-1.3.0.0/build/Crypto/Hash/XKCP.o, /Users/twhitaker/sources/accelerate/dist-newstyle/build/aarch64-osx/ghc-9.2.7/accelerate-1.3.0.0/build/Crypto/Hash/XKCP.dyn_o )
ghc: loadArchive: Neither an archive, nor a fat archive: `/nix/store/wqjp99m9d4dzi4ydwj87xr0z2dfygv9b-clang-wrapper-11.1.0/bin/clang++'
ghc: panic! (the 'impossible' happened)
(GHC version 9.2.7:
loadArchive "/nix/store/wqjp99m9d4dzi4ydwj87xr0z2dfygv9b-clang-wrapper-11.1.0/bin/clang++": failed
Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug
```
Initially I was surprised that compiling modules needs to load archives in the first place, but then I realized it's because of the Template Haskell in `src/Crypto/Hash/XKCP.hs`. I'm not sure why it's picking on `clang++` in particular. I think it might have something to do with the fact that accelerate depends on double-conversion, which in turn depends on some C++ something or other.
Both https://gitlab.haskell.org/ghc/ghc/-/issues/16590#note_195984 and https://gitlab.haskell.org/ghc/ghc/-/issues/16063 seem related, but not exactly the same (and at least partially solved on the 9.x series).9.8.2Ben GamariBen Gamarihttps://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/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/23322Backpack: Import standalone modules from indefinite packages in instancing mo...2023-07-02T23:06:56ZRodrigo MesquitaBackpack: Import standalone modules from indefinite packages in instancing modules failsSay I have the following modules and signatures in a cabal project
```haskell
module A where
data SomeUsefulThing = SomeUsefulThing
```
```haskell
signature B where
import A
someUsefulFun :: SomeUsefulThing -> ()
```
```haskell
module...Say I have the following modules and signatures in a cabal project
```haskell
module A where
data SomeUsefulThing = SomeUsefulThing
```
```haskell
signature B where
import A
someUsefulFun :: SomeUsefulThing -> ()
```
```haskell
module B.Instance where
import A
someUsefulFun :: SomeUsefulThing -> ()
someUsefulFun SomeUsefulThing = ()
```
Note that in B's signature and instance, `someUsefulFun` share the same type `SomeUsefulThing` imported from `A`.
```haskell
import A
import B
main = pure (someUsefulFun SomeUsefulThing)
```
```cabal
cabal-version: 3.4
name: ex2
version: 0.1.0.0
build-type: Simple
library pa
build-depends: base
exposed-modules: A
signatures: B
hs-source-dirs: pa
library pb
build-depends: base, ex2:pa
exposed-modules: B.Instance
hs-source-dirs: pb
library
exposed-modules: Main
build-depends: base, ex2:pa, ex2:pb
mixins: ex2:pa requires (B as B.Instance),
hs-source-dirs: main
```
When compiling this project, it fails with
```
<no location info>: error:
• Identifier ‘someUsefulFun’ has conflicting definitions in the module
and its hsig file
Main module: someUsefulFun ::
ex2-0.1.0.0:pa[B=<B>]:A.SomeUsefulThing -> ()
Hsig file: someUsefulFun :: A.SomeUsefulThing -> ()
The two types are different
• while checking that B.Instance implements signature B in ex2-0.1.0.0:pa[B=B.Instance]
```
The cause is `SomeUsefulThing`, in the context of `pa` is imported from `A`, but in the context of `pb`, is imported from `ex2:pa[B=<B>]:A`.
I think it should be possible to use the shared definition of `SomeUsefulThing`, since `A` is a completely standalone module (doesn't depend on any indefinite signatures). Even if it did, it is reasonable to think it should also work.
Is this a fundamental limitation or something we can overcome?
Many thanks.sheafsam.derbyshire@gmail.comsheafsam.derbyshire@gmail.comhttps://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/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/23375RTS error: scavenge_one: strange object 23 while using byte-code linking in c...2023-10-18T17:02:42ZIan-Woo KimRTS error: scavenge_one: strange object 23 while using byte-code linking in compilationOn x86_64 linux system, we turn on byte-code linking (`-fprefer-byte-code -fbyte-code-and-object-code`) and we increasingly get this error in GC during compiling a project (the following is an excerpt from CI message)
```
> ghc-9....On x86_64 linux system, we turn on byte-code linking (`-fprefer-byte-code -fbyte-code-and-object-code`) and we increasingly get this error in GC during compiling a project (the following is an excerpt from CI message)
```
> ghc-9.6.1: internal error: scavenge_one: strange object 23
> Stack trace:
> 0x7fffef186bc0 set_initial_registers (/nix/store/59ng7169ncp4g0xcyxdmd5bf5gd9yilm-ghc-9.6.1/lib/ghc-9.6.1/lib/x86_64-linux-ghc-9.6.1/libHSrts-1.0.2_thr-ghc9.6.1.so)
> 0x7fffeeddd5c8 dwfl_thread_getframes (/nix/store/sd6nsyj6v8qmdr07g5hl5rp8mpkbzasp-elfutils-0.189/lib/libdw-0.189.so)
> 0x7fffeeddd11b get_one_thread_cb (/nix/store/sd6nsyj6v8qmdr07g5hl5rp8mpkbzasp-elfutils-0.189/lib/libdw-0.189.so)
> 0x7fffeeddd42a dwfl_getthreads (/nix/store/sd6nsyj6v8qmdr07g5hl5rp8mpkbzasp-elfutils-0.189/lib/libdw-0.189.so)
> 0x7fffeeddd957 dwfl_getthread_frames (/nix/store/sd6nsyj6v8qmdr07g5hl5rp8mpkbzasp-elfutils-0.189/lib/libdw-0.189.so)
> 0x7fffef187297 libdwGetBacktrace (/nix/store/59ng7169ncp4g0xcyxdmd5bf5gd9yilm-ghc-9.6.1/lib/ghc-9.6.1/lib/x86_64-linux-ghc-9.6.1/libHSrts-1.0.2_thr-ghc9.6.1.so)
> 0x7fffef18fb27 rtsFatalInternalErrorFn (/nix/store/59ng7169ncp4g0xcyxdmd5bf5gd9yilm-ghc-9.6.1/lib/ghc-9.6.1/lib/x86_64-linux-ghc-9.6.1/libHSrts-1.0.2_thr-ghc9.6.1.so)
> 0x7fffef18fd1d barf (/nix/store/59ng7169ncp4g0xcyxdmd5bf5gd9yilm-ghc-9.6.1/lib/ghc-9.6.1/lib/x86_64-linux-ghc-9.6.1/libHSrts-1.0.2_thr-ghc9.6.1.so)
> 0x7fffef1bccb4 scavenge_one (/nix/store/59ng7169ncp4g0xcyxdmd5bf5gd9yilm-ghc-9.6.1/lib/ghc-9.6.1/lib/x86_64-linux-ghc-9.6.1/libHSrts-1.0.2_thr-ghc9.6.1.so)
> 0x7fffef1bd1ef scavenge_mutable_list (/nix/store/59ng7169ncp4g0xcyxdmd5bf5gd9yilm-ghc-9.6.1/lib/ghc-9.6.1/lib/x86_64-linux-ghc-9.6.1/libHSrts-1.0.2_thr-ghc9.6.1.so)
> 0x7fffef1bd420 scavenge_capability_mut_lists (/nix/store/59ng7169ncp4g0xcyxdmd5bf5gd9yilm-ghc-9.6.1/lib/ghc-9.6.1/lib/x86_64-linux-ghc-9.6.1/libHSrts-1.0.2_thr-ghc9.6.1.so)
> 0x7fffef1b322a GarbageCollect (/nix/store/59ng7169ncp4g0xcyxdmd5bf5gd9yilm-ghc-9.6.1/lib/ghc-9.6.1/lib/x86_64-linux-ghc-9.6.1/libHSrts-1.0.2_thr-ghc9.6.1.so)
> 0x7fffef193fdd scheduleDoGC (/nix/store/59ng7169ncp4g0xcyxdmd5bf5gd9yilm-ghc-9.6.1/lib/ghc-9.6.1/lib/x86_64-linux-ghc-9.6.1/libHSrts-1.0.2_thr-ghc9.6.1.so)
> 0x7fffef194c02 schedule (/nix/store/59ng7169ncp4g0xcyxdmd5bf5gd9yilm-ghc-9.6.1/lib/ghc-9.6.1/lib/x86_64-linux-ghc-9.6.1/libHSrts-1.0.2_thr-ghc9.6.1.so)
> 0x7fffef19585c scheduleWorker (/nix/store/59ng7169ncp4g0xcyxdmd5bf5gd9yilm-ghc-9.6.1/lib/ghc-9.6.1/lib/x86_64-linux-ghc-9.6.1/libHSrts-1.0.2_thr-ghc9.6.1.so)
> 0x7fffef199edd workerStart (/nix/store/59ng7169ncp4g0xcyxdmd5bf5gd9yilm-ghc-9.6.1/lib/ghc-9.6.1/lib/x86_64-linux-ghc-9.6.1/libHSrts-1.0.2_thr-ghc9.6.1.so)
> 0x7fffeeed2e24 start_thread (/nix/store/1n2l5law9g3b77hcfyp50vrhhssbrj5g-glibc-2.37-8/lib/libc.so.6)
> 0x7fffeef549b0 __clone3 (/nix/store/1n2l5law9g3b77hcfyp50vrhhssbrj5g-glibc-2.37-8/lib/libc.so.6)
>
> (GHC version 9.6.1 for x86_64_unknown_linux)
> Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug
> /nix/store/5s1yg5l36wzgy1dj0vv1ibarc4g7vrdr-stdenv-linux/setup: line 1595: 103601 Aborted (core dumped) ./Setup build
```9.6.2Ben GamariBen Gamarihttps://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/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/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/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/23537Panic iselExpr64(i386)2023-06-30T09:52:54ZJaro ReindersPanic iselExpr64(i386)## Summary
While implementing !10568 I came across a GHC panic.
## Steps to reproduce
To reproduce we need two files:
```haskell
-- Repro.hs
module Repro (repro) where
import Unique
mkPreludeTyConUnique i = mkUnique '3' (2*i)
intT...## Summary
While implementing !10568 I came across a GHC panic.
## Steps to reproduce
To reproduce we need two files:
```haskell
-- Repro.hs
module Repro (repro) where
import Unique
mkPreludeTyConUnique i = mkUnique '3' (2*i)
intTyConKey = mkPreludeTyConUnique 15
int8TyConKey = mkPreludeTyConUnique 17
int16TyConKey = mkPreludeTyConUnique 19
int32TyConKey = mkPreludeTyConUnique 21
int64TyConKey = mkPreludeTyConUnique 23
repro :: Unique -> Bool
repro x = x `elem` [ intTyConKey, int8TyConKey, int16TyConKey
, int32TyConKey, int64TyConKey
, mkUnique '3' 24
]
```
```haskell
-- Unique.hs
module Unique where
import Data.Word
import Data.Bits
import Data.Char
newtype Unique = MkUnique Word64 deriving Eq
mkUnique :: Char -> Word64 -> Unique
mkUnique c i
= MkUnique (tag .|. bits)
where
tag = fromIntegral (ord c) `shiftL` 60
bits = fromIntegral i .&. ((1 `shiftL` 60) - 1)
```
Compile with `ghc -O2 Repro.hs` and observe:
```
[2 of 2] Compiling Repro ( Repro.hs, Repro.o ) [Source file changed]
<no location info>: error:
panic! (the 'impossible' happened)
GHC version 9.4.3:
iselExpr64(i386)
_s1mO::I64 - 24 :: W64
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/CmmToAsm/X86/CodeGen.hs:615:7 in ghc:GHC.CmmToAsm.X86.CodeGen
Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug
```
To get a 32 bit compiler on a 64 bit system I use this script from [`ghc-utils`](https://gitlab.haskell.org/bgamari/ghc-utils/-/tree/master):
```
./ghc-docker-jobs.sh i386-linux-deb9-validate master
```
## Expected behavior
Compile without issues, like GHC 9.2.8 does.
## Environment
* GHC version used: 9.4.1, 9.4.3, 9.6.2
Optional:
* System Architecture: i386Jaro ReindersJaro Reindershttps://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/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/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/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/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/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/6986