GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:01:58Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/16028tyThingCoAxiom panics while building Agda2019-07-07T18:01:58ZIlias TsitsimpistyThingCoAxiom panics while building Agdaghc-8.4.4 panics while building Agda on armhf (https://buildd.debian.org/status/fetch.php?pkg=agda&arch=armhf&ver=2.5.4.1-3%2Bb1&stamp=1544132023&raw=0):
```
ghc: panic! (the 'impossible' happened)
(GHC version 8.4.4 for arm-unknown-l...ghc-8.4.4 panics while building Agda on armhf (https://buildd.debian.org/status/fetch.php?pkg=agda&arch=armhf&ver=2.5.4.1-3%2Bb1&stamp=1544132023&raw=0):
```
ghc: panic! (the 'impossible' happened)
(GHC version 8.4.4 for arm-unknown-linux):
tyThingCoAxiom
Identifier ‘fromDescListWithKey’
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable
pprPanic, called at compiler/main/HscTypes.hs:2153:32 in ghc:HscTypes
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
The same version of Agda builds fine with ghc-8.4.3 on armhf (https://buildd.debian.org/status/fetch.php?pkg=agda&arch=armhf&ver=2.5.4.1-3&stamp=1540145469&raw=0).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"tyThingCoAxiom panics while building Agda","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.4","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"ghc-8.4.4 panics while building Agda on armhf (https://buildd.debian.org/status/fetch.php?pkg=agda&arch=armhf&ver=2.5.4.1-3%2Bb1&stamp=1544132023&raw=0):\r\n{{{\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 8.4.4 for arm-unknown-linux):\r\n\ttyThingCoAxiom\r\n Identifier ‘fromDescListWithKey’\r\n Call stack:\r\n CallStack (from HasCallStack):\r\n callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable\r\n pprPanic, called at compiler/main/HscTypes.hs:2153:32 in ghc:HscTypes\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\nThe same version of Agda builds fine with ghc-8.4.3 on armhf (https://buildd.debian.org/status/fetch.php?pkg=agda&arch=armhf&ver=2.5.4.1-3&stamp=1540145469&raw=0).","type_of_failure":"OtherFailure","blocking":[]} -->8.6.4https://gitlab.haskell.org/ghc/ghc/-/issues/15984Backpack accepts ill-kinded instantiations. Can cause GHC panic2019-07-07T18:02:09ZaaronvargoBackpack accepts ill-kinded instantiations. Can cause GHC panicGiven the following:
```hs
{-# language KindSignatures #-}
signature A where
data A :: *
```
```hs
module Foo where
import A
foo :: A -> A
foo = id
```
```hs
module IllKindedA where
type A = Maybe
```
GHC allows the signature `A`...Given the following:
```hs
{-# language KindSignatures #-}
signature A where
data A :: *
```
```hs
module Foo where
import A
foo :: A -> A
foo = id
```
```hs
module IllKindedA where
type A = Maybe
```
GHC allows the signature `A` to be instantiated with `IllKindedA`:
```
mixins: foo (Foo as Bug) requires (A as IllKindedA)
```
Using the resulting module can cause odd errors or a panic. E.g. the following causes a panic:
```hs
module Bar where
import Bug
bar = foo
```
```
ghc: panic! (the 'impossible' happened)
(GHC version 8.6.2 for x86_64-unknown-linux):
getRuntimeRep
A :: * -> *
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable
pprPanic, called at compiler/types/Type.hs:2049:18 in ghc:Type
```8.6.3https://gitlab.haskell.org/ghc/ghc/-/issues/15979Core Lint error with LiberalTypeSynonyms2022-12-08T17:36:30ZRyan ScottCore Lint error with LiberalTypeSynonymsSee main ticket #22063
```hs
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE LiberalTypeSynonyms #-}
{-# LANGUAGE PolyKinds #-}
{-# OPTIONS_GHC -dcore-lint #-}
module Bug where
import Data.Kind
type KindOf (a :: k) = k
wat :: KindOf (forall...See main ticket #22063
```hs
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE LiberalTypeSynonyms #-}
{-# LANGUAGE PolyKinds #-}
{-# OPTIONS_GHC -dcore-lint #-}
module Bug where
import Data.Kind
type KindOf (a :: k) = k
wat :: KindOf (forall (a :: ()). a)
wat = ()
```
```
$ /opt/ghc/8.6.2/bin/ghc Bug.hs
[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
*** Core Lint errors : in result of Desugar (before optimization) ***
<no location info>: warning:
In the type ‘KindOf (forall (a :: ()). a)’
Non-*-like kind when *-like expected: ()
when checking the body of forall: forall (a :: ()). a
*** Offending Program ***
Rec {
$trModule :: Module
[LclIdX]
$trModule = Module (TrNameS "main"#) (TrNameS "Bug"#)
wat :: KindOf (forall (a :: ()). a)
[LclIdX]
wat = ()
end Rec }
*** End of Offense ***
<no location info>: error:
Compilation had errors
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Core Lint error with LiberalTypeSynonyms","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{#!hs\r\n{-# LANGUAGE DataKinds #-}\r\n{-# LANGUAGE LiberalTypeSynonyms #-}\r\n{-# LANGUAGE PolyKinds #-}\r\n{-# OPTIONS_GHC -dcore-lint #-}\r\nmodule Bug where\r\n\r\nimport Data.Kind\r\n\r\ntype KindOf (a :: k) = k\r\n\r\nwat :: KindOf (forall (a :: ()). a)\r\nwat = ()\r\n}}}\r\n{{{\r\n$ /opt/ghc/8.6.2/bin/ghc Bug.hs\r\n[1 of 1] Compiling Bug ( Bug.hs, Bug.o )\r\n*** Core Lint errors : in result of Desugar (before optimization) ***\r\n<no location info>: warning:\r\n In the type ‘KindOf (forall (a :: ()). a)’\r\n Non-*-like kind when *-like expected: ()\r\n when checking the body of forall: forall (a :: ()). a\r\n*** Offending Program ***\r\nRec {\r\n$trModule :: Module\r\n[LclIdX]\r\n$trModule = Module (TrNameS \"main\"#) (TrNameS \"Bug\"#)\r\n\r\nwat :: KindOf (forall (a :: ()). a)\r\n[LclIdX]\r\nwat = ()\r\nend Rec }\r\n\r\n*** End of Offense ***\r\n\r\n\r\n<no location info>: error: \r\nCompilation had errors\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/15928Improve error message: Reduction stack overflow when using "coerce"2024-01-21T16:25:19ZharendraImprove error message: Reduction stack overflow when using "coerce"EDIT: Executive summary: The error messages below are confusing and not perspicuous to users. We should fix. [ticket:15928\#comment:163956](https://gitlab.haskell.org//ghc/ghc/issues/15928#note_163956) has a concrete suggestion to use as...EDIT: Executive summary: The error messages below are confusing and not perspicuous to users. We should fix. [ticket:15928\#comment:163956](https://gitlab.haskell.org//ghc/ghc/issues/15928#note_163956) has a concrete suggestion to use as a starting point, and [ticket:15928\#comment:163991](https://gitlab.haskell.org//ghc/ghc/issues/15928#note_163991) suggests we print out the role signature of any tycons involved.
Compiling the following snippet results in a "Reduction stack overflow" error message:
```hs
{-# Language ScopedTypeVariables #-}
{-# Language RankNTypes #-}
import Data.Functor.Identity
import Data.Coerce
newtype Stream m a =
Stream {
unStream :: forall r. (Stream m a -> m r) -> m r
}
newtype SerialT m a = SerialT (Stream m a)
g :: SerialT Identity a -> Identity Bool
g m = undefined
idSerial :: SerialT Identity a -> SerialT Identity a
idSerial = id
f :: SerialT Identity a -> Identity Bool
f = g . idSerial . coerce
main = undefined
```
The following error message is produced on compiling this with ghc-8.6.2:
```
xy.hs:26:20: error:
• Reduction stack overflow; size = 201
When simplifying the following type:
Coercible
((Stream Identity a -> Identity r) -> Identity r)
((Stream Identity a0 -> Identity r) -> Identity r)
Use -freduction-depth=0 to disable this check
(any upper bound you could choose might fail unpredictably with
minor updates to GHC, so disabling the check is recommended if
you're sure that type checking should terminate)
• In the second argument of ‘(.)’, namely ‘coerce’
In the second argument of ‘(.)’, namely ‘idSerial . coerce’
In the expression: g . idSerial . coerce
|
26 | f = g . idSerial . coerce
| ^^^^^^
```
When I use an inline signature like this:
```hs
f :: SerialT Identity a -> Identity Bool
f = g . (id :: SerialT Identity a -> SerialT Identity a) . coerce
main = undefined
```
It again results in the same error:
```
xy.hs:18:60: error:
• Reduction stack overflow; size = 201
When simplifying the following type:
Coercible
((Stream Identity a -> Identity r) -> Identity r)
((Stream Identity a0 -> Identity r) -> Identity r)
Use -freduction-depth=0 to disable this check
(any upper bound you could choose might fail unpredictably with
minor updates to GHC, so disabling the check is recommended if
you're sure that type checking should terminate)
• In the second argument of ‘(.)’, namely ‘coerce’
In the second argument of ‘(.)’, namely
‘(id :: SerialT Identity a -> SerialT Identity a) . coerce’
In the expression:
g . (id :: SerialT Identity a -> SerialT Identity a) . coerce
|
18 | f = g . (id :: SerialT Identity a -> SerialT Identity a) . coerce
| ^^^^^^
```
Everything works fine is I use an inline signature with a `forall` keyword like this:
```hs
f :: forall a. SerialT Identity a -> Identity Bool
f = g . (id :: SerialT Identity a -> SerialT Identity a) . coerce
```
I have following questions:
1) Why the first version results in a panic? Is that a bug?
2) The second version might possibly be incorrect code because the types do not unify, but still it should not result in a panic, because of the panic I could not figure out what the problem is. It took a long time to isolate the code and then do some trial and error on it.8.6.3https://gitlab.haskell.org/ghc/ghc/-/issues/15745Panicking typechecker plugins2019-07-07T18:03:09ZPhil de JouxPanicking typechecker pluginsIf I use a typechecker plugin that fails then ghc panics and I'm asked to report a bug with GHC;
```
ghc: panic! (the 'impossible' happened)
(GHC version 8.2.2 for x86_64-apple-darwin):
Prelude.undefined
CallStack (from H...If I use a typechecker plugin that fails then ghc panics and I'm asked to report a bug with GHC;
```
ghc: panic! (the 'impossible' happened)
(GHC version 8.2.2 for x86_64-apple-darwin):
Prelude.undefined
CallStack (from HasCallStack):
error, called at libraries/base/GHC/Err.hs:79:14 in base:GHC.Err
undefined, called at plugin/Undefined/Solve/Plugin.hs:14:39 in
undefined-solve-plugin-1.0.0.0-56evBabJYBHHTUlrE3HO5m:Undefined.Solve.Plugin
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
Could we please say that it is the typechecker plugin that is panicking and ask for a bug report for the faulty typechecker, giving the issues URL for the plugin if we know it?
The following [undefined plugins](https://github.com/BlockScope/undefined-plugin) fail for init, solve and stop functions.
```haskell
module Undefined.Init.Plugin (plugin) where
import Plugins (Plugin(..), tcPlugin, defaultPlugin)
import TcRnTypes (TcPluginM, TcPluginResult(..), Ct, TcPlugin(..))
import GHC.TcPluginM.Extra (tracePlugin)
plugin :: Plugin
plugin = defaultPlugin { tcPlugin = const $ Just undefinedPlugin }
undefinedPlugin :: TcPlugin
undefinedPlugin = tracePlugin "undefined-init-plugin" $
TcPlugin
{ tcPluginInit = undefined
, tcPluginSolve = \_ _ _ _ -> return $ TcPluginOk [] []
, tcPluginStop = const $ return ()
}
```
```haskell
module Undefined.Solve.Plugin (plugin) where
import Plugins (Plugin(..), tcPlugin, defaultPlugin)
import TcRnTypes (TcPluginM, TcPluginResult, Ct, TcPlugin(..))
import GHC.TcPluginM.Extra (tracePlugin)
plugin :: Plugin
plugin = defaultPlugin { tcPlugin = const $ Just undefinedPlugin }
undefinedPlugin :: TcPlugin
undefinedPlugin = tracePlugin "undefined-solve-plugin" $
TcPlugin
{ tcPluginInit = return ()
, tcPluginSolve = \_ _ _ _ -> undefined
, tcPluginStop = const $ return ()
}
```
```haskell
module Undefined.Stop.Plugin (plugin) where
import Plugins (Plugin(..), tcPlugin, defaultPlugin)
import TcRnTypes (TcPluginM, TcPluginResult(..), Ct, TcPlugin(..))
import GHC.TcPluginM.Extra (tracePlugin)
plugin :: Plugin
plugin = defaultPlugin { tcPlugin = const $ Just undefinedPlugin }
undefinedPlugin :: TcPlugin
undefinedPlugin = tracePlugin "undefined-stop-plugin" $
TcPlugin
{ tcPluginInit = return ()
, tcPluginSolve = \_ _ _ _ -> return $ TcPluginOk [] []
, tcPluginStop = const $ undefined
}
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.2.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Panicking typechecker plugins","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"If I use a typechecker plugin that fails then ghc panics and I'm asked to report a bug with GHC;\r\n\r\n{{{\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 8.2.2 for x86_64-apple-darwin):\r\n \tPrelude.undefined\r\n CallStack (from HasCallStack):\r\n error, called at libraries/base/GHC/Err.hs:79:14 in base:GHC.Err\r\n undefined, called at plugin/Undefined/Solve/Plugin.hs:14:39 in\r\n undefined-solve-plugin-1.0.0.0-56evBabJYBHHTUlrE3HO5m:Undefined.Solve.Plugin\r\n\r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\nCould we please say that it is the typechecker plugin that is panicking and ask for a bug report for the faulty typechecker, giving the issues URL for the plugin if we know it?\r\n\r\nThe following [https://github.com/BlockScope/undefined-plugin undefined plugins] fail for init, solve and stop functions.\r\n\r\n{{{\r\n#!haskell\r\nmodule Undefined.Init.Plugin (plugin) where\r\n\r\nimport Plugins (Plugin(..), tcPlugin, defaultPlugin)\r\nimport TcRnTypes (TcPluginM, TcPluginResult(..), Ct, TcPlugin(..))\r\nimport GHC.TcPluginM.Extra (tracePlugin)\r\n\r\nplugin :: Plugin\r\nplugin = defaultPlugin { tcPlugin = const $ Just undefinedPlugin }\r\n\r\nundefinedPlugin :: TcPlugin\r\nundefinedPlugin = tracePlugin \"undefined-init-plugin\" $\r\n TcPlugin\r\n { tcPluginInit = undefined\r\n , tcPluginSolve = \\_ _ _ _ -> return $ TcPluginOk [] []\r\n , tcPluginStop = const $ return ()\r\n }\r\n}}}\r\n\r\n\r\n{{{\r\n#!haskell\r\nmodule Undefined.Solve.Plugin (plugin) where\r\n\r\nimport Plugins (Plugin(..), tcPlugin, defaultPlugin)\r\nimport TcRnTypes (TcPluginM, TcPluginResult, Ct, TcPlugin(..))\r\nimport GHC.TcPluginM.Extra (tracePlugin)\r\n\r\nplugin :: Plugin\r\nplugin = defaultPlugin { tcPlugin = const $ Just undefinedPlugin }\r\n\r\nundefinedPlugin :: TcPlugin\r\nundefinedPlugin = tracePlugin \"undefined-solve-plugin\" $\r\n TcPlugin\r\n { tcPluginInit = return ()\r\n , tcPluginSolve = \\_ _ _ _ -> undefined\r\n , tcPluginStop = const $ return ()\r\n }\r\n}}}\r\n\r\n{{{\r\n#!haskell\r\nmodule Undefined.Stop.Plugin (plugin) where\r\n\r\nimport Plugins (Plugin(..), tcPlugin, defaultPlugin)\r\nimport TcRnTypes (TcPluginM, TcPluginResult(..), Ct, TcPlugin(..))\r\nimport GHC.TcPluginM.Extra (tracePlugin)\r\n\r\nplugin :: Plugin\r\nplugin = defaultPlugin { tcPlugin = const $ Just undefinedPlugin }\r\n\r\nundefinedPlugin :: TcPlugin\r\nundefinedPlugin = tracePlugin \"undefined-stop-plugin\" $\r\n TcPlugin\r\n { tcPluginInit = return ()\r\n , tcPluginSolve = \\_ _ _ _ -> return $ TcPluginOk [] []\r\n , tcPluginStop = const $ undefined\r\n }\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/15516ghci: dynamic linking fails on osx2022-05-15T03:33:26Zkfizghci: dynamic linking fails on osx```
ghc: panic! (the 'impossible' happened)
(GHC version 8.4.3 for x86_64-apple-darwin):
Loading temp shared object failed: dlopen(/var/folders/vj/cm0c8jrs739_t411zdcx72240000gp/T/ghc24522_0/libghc_9.dylib, 5): Symbol not found: _Data...```
ghc: panic! (the 'impossible' happened)
(GHC version 8.4.3 for x86_64-apple-darwin):
Loading temp shared object failed: dlopen(/var/folders/vj/cm0c8jrs739_t411zdcx72240000gp/T/ghc24522_0/libghc_9.dylib, 5): Symbol not found: _DataziCsvUtils_rowBy_closure
Referenced from: /var/folders/vj/cm0c8jrs739_t411zdcx72240000gp/T/ghc24522_0/libghc_9.dylib
Expected in: flat namespace
in /var/folders/vj/cm0c8jrs739_t411zdcx72240000gp/T/ghc24522_0/libghc_9.dylib
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/14987Memory usage exploding for complex pattern matching2020-05-02T22:45:07ZvmiraldoMemory usage exploding for complex pattern matchingIt seems like complex pattern matching is consuming a prohibitive amount of memory. From a discussion in ghc-devs, [https://mail.haskell.org/pipermail/ghc-devs/2018-March/015538.html](https://mail.haskell.org/pipermail/ghc-devs/2018-Marc...It seems like complex pattern matching is consuming a prohibitive amount of memory. From a discussion in ghc-devs, [https://mail.haskell.org/pipermail/ghc-devs/2018-March/015538.html](https://mail.haskell.org/pipermail/ghc-devs/2018-March/015538.html), the exhaustiveness checker could be the culprit.
We have tried with 7.10.3, 8.0.2, 8.4.1 and ghc-HEAD. They show similar results.
The "-fmax-pmchecker-iterations=0" option seems to help slightly. Bigger cases
will run out of memory even with the option enabled.
I'm attaching a "minimal" example to help diagnosing. The majority of the
code has been generated by Template Haskell.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Memory usage exploding for complex pattern matching","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"It seems like complex pattern matching is consuming a prohibitive amount of memory. From a discussion in ghc-devs, [https://mail.haskell.org/pipermail/ghc-devs/2018-March/015538.html], the exhaustiveness checker could be the culprit. \r\n\r\nWe have tried with 7.10.3, 8.0.2, 8.4.1 and ghc-HEAD. They show similar results.\r\n\r\nThe \"-fmax-pmchecker-iterations=0\" option seems to help slightly. Bigger cases\r\nwill run out of memory even with the option enabled.\r\n\r\nI'm attaching a \"minimal\" example to help diagnosing. The majority of the\r\ncode has been generated by Template Haskell.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14908Compiling using O1 works but panic using O2 or O32019-07-07T18:15:05ZjosejuanCompiling using O1 works but panic using O2 or O3<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.2 |
| Type | Bug |
| TypeOfFailure |...<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Compiling using O1 works but panic using O2 or O3","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14679The interpreter showed panic! (the 'impossible' happened)2019-07-07T18:16:02Zcrick_The interpreter showed panic! (the 'impossible' happened)My code -
```hs
{-
Example run:
Enter initial state:
12356 784
Enter final state:
123586 74
1 2 3
5 8 6
7 4
1 2 3
5 8 6
7 4
1 2 3
5 6
7 8 4
1 2 3
5 6
7 8 4
Minimum path length: 3
-}
import Data.List
import Data.List.Split
...My code -
```hs
{-
Example run:
Enter initial state:
12356 784
Enter final state:
123586 74
1 2 3
5 8 6
7 4
1 2 3
5 8 6
7 4
1 2 3
5 6
7 8 4
1 2 3
5 6
7 8 4
Minimum path length: 3
-}
import Data.List
import Data.List.Split
import Data.Map as Map hiding (map, filter)
swap :: Int -> Int -> State -> State
swap i j (State xs depth) = let (i', j') = if i > j then (j ,i) else (i, j)
left = take i' xs
middle = drop (i'+1) $ take j' xs
i_elem = xs !! i'
right = drop (j'+1) xs
j_elem = xs !! j'
xs' = left ++ [j_elem] ++ middle ++ [i_elem] ++ right
in (State xs' depth)
printGrid :: State -> IO()
printGrid (State xs depth) = let [x,y,z] = chunksOf 6 $ intersperse ' ' xs
in do putStrLn x
putStrLn y
putStrLn z
putStrLn ""
data State = State {
state :: [Char],
depth :: Int
} deriving (Eq, Show, Ord)
getMoves :: State -> [Char]
getMoves (State xs depth) = case ' ' `elemIndex` xs of
Nothing -> error "Empty block not found"
Just n -> let l = n `elem` [1,4,7,2,5,8]
r = n `elem` [0,3,6,1,4,7]
d = n `elem` [0..5]
u = n `elem` [3..8]
pairs = zip [l,r,d,u] ['L','R','D','U']
filtered = filter (\x -> fst x) pairs
in map snd filtered
next :: State -> [Char] -> [State]
next (State state depth) cs = case ' ' `elemIndex` state of
Nothing -> error "Empty block not found"
Just n -> do c <- cs
return $ case c of
'L' -> swap n (n-1) (State state (depth + 1))
'R' -> swap n (n+1) (State state (depth + 1))
'U' -> swap n (n-3) (State state (depth + 1))
'D' -> swap n (n+3) (State state (depth + 1))
test :: State -> State -> Bool
test state1 state2 = (state state1) == (state state2)
-- loop :: finalState -> open -> closed -> accmulated parentMap -> parentMap
loop :: State -> [State] -> [State] -> Map State State -> Maybe (State, Map State State)
loop final [] _ _ = Nothing
loop final open@(x:xs) closed parentMap = if test final x
then Just (x, parentMap)
else let moves = getMoves x
nextStates = next x moves
filter_fn = \x -> not (x `elem` open || x `elem` closed)
filtered = filter filter_fn nextStates
newMap = insertIntoMap filtered x parentMap
in loop final (xs ++ filtered) (x:closed) newMap
insertIntoMap :: [State] -> State -> Map State State -> Map State State
insertIntoMap [] _ parentMap = parentMap
insertIntoMap (x:xs) parent parentMap =
insertIntoMap xs parent (Map.insert x parent parentMap)
printAns :: State -> Map State State -> Int -> IO ()
printAns state parentMap count =
case Map.lookup state parentMap of
Just parent -> do printGrid parent
printAns parent parentMap (count + 1)
Nothing -> do putStrLn $ "Minimum path length: " ++ show count
return ()
ans :: Maybe (State, Map State State) -> IO ()
ans (Just (final, parentMap)) = do
printGrid final
printAns final parentMap 0
ans _ = putStrLn "No answer found."
main :: IO ()
main = do putStrLn "Enter initial state: "
start <- getLine
putStrLn "Enter final state: "
final <- getLine
ans $ loop (State final 0) [(State start 0)] [] Map.empty
```
Test Cases I entered in the order:
- Main\> main
Enter initial state:
123456 784
Enter final state:
1234567 8mianrrupted.
- Main\>
- Main\> main
Enter initial state:
12356 784
Enter final state:
123586 74
1 2 3
5 8 6
> 7 4
1 2 3
5 8 6
7 4
1 2 3
5 6
7 8 4
1 2 3
5 6
7 8 4
Minimum path length: 3
- Main\>
\<interactive\>: panic! (the 'impossible' happened)
(GHC version 8.0.1 for x86_64-unknown-mingw32):
> thread blocked indefinitely in an MVar operation
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Windows |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"The interpreter showed panic! (the 'impossible' happened)","status":"New","operating_system":"Windows","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":["panic"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"My code - \r\n\r\n{{{#!hs\r\n{-\r\nExample run:\r\n\r\nEnter initial state:\r\n12356 784\r\nEnter final state:\r\n\r\n123586 74\r\n1 2 3\r\n5 8 6\r\n 7 4\r\n\r\n1 2 3\r\n5 8 6\r\n7 4\r\n\r\n1 2 3\r\n5 6\r\n7 8 4\r\n\r\n1 2 3\r\n5 6\r\n7 8 4\r\n\r\nMinimum path length: 3\r\n\r\n-}\r\n\r\nimport Data.List\r\nimport Data.List.Split\r\nimport Data.Map as Map hiding (map, filter)\r\n\r\nswap :: Int -> Int -> State -> State\r\nswap i j (State xs depth) = let (i', j') = if i > j then (j ,i) else (i, j)\r\n left = take i' xs\r\n middle = drop (i'+1) $ take j' xs\r\n i_elem = xs !! i'\r\n right = drop (j'+1) xs\r\n j_elem = xs !! j'\r\n xs' = left ++ [j_elem] ++ middle ++ [i_elem] ++ right\r\n in (State xs' depth)\r\n\r\nprintGrid :: State -> IO()\r\nprintGrid (State xs depth) = let [x,y,z] = chunksOf 6 $ intersperse ' ' xs\r\n in do putStrLn x\r\n putStrLn y\r\n putStrLn z\r\n putStrLn \"\"\r\n\r\ndata State = State {\r\n state :: [Char],\r\n depth :: Int\r\n} deriving (Eq, Show, Ord)\r\n\r\ngetMoves :: State -> [Char]\r\ngetMoves (State xs depth) = case ' ' `elemIndex` xs of\r\n Nothing -> error \"Empty block not found\"\r\n Just n -> let l = n `elem` [1,4,7,2,5,8]\r\n r = n `elem` [0,3,6,1,4,7]\r\n d = n `elem` [0..5]\r\n u = n `elem` [3..8]\r\n pairs = zip [l,r,d,u] ['L','R','D','U']\r\n filtered = filter (\\x -> fst x) pairs\r\n in map snd filtered\r\n\r\nnext :: State -> [Char] -> [State]\r\nnext (State state depth) cs = case ' ' `elemIndex` state of\r\n Nothing -> error \"Empty block not found\"\r\n Just n -> do c <- cs\r\n return $ case c of\r\n 'L' -> swap n (n-1) (State state (depth + 1))\r\n 'R' -> swap n (n+1) (State state (depth + 1))\r\n 'U' -> swap n (n-3) (State state (depth + 1))\r\n 'D' -> swap n (n+3) (State state (depth + 1))\r\n\r\ntest :: State -> State -> Bool\r\ntest state1 state2 = (state state1) == (state state2)\r\n\r\n-- loop :: finalState -> open -> closed -> accmulated parentMap -> parentMap\r\nloop :: State -> [State] -> [State] -> Map State State -> Maybe (State, Map State State)\r\nloop final [] _ _ = Nothing\r\nloop final open@(x:xs) closed parentMap = if test final x\r\n then Just (x, parentMap)\r\n else let moves = getMoves x\r\n nextStates = next x moves\r\n filter_fn = \\x -> not (x `elem` open || x `elem` closed)\r\n filtered = filter filter_fn nextStates\r\n newMap = insertIntoMap filtered x parentMap\r\n in loop final (xs ++ filtered) (x:closed) newMap\r\n\r\ninsertIntoMap :: [State] -> State -> Map State State -> Map State State\r\ninsertIntoMap [] _ parentMap = parentMap\r\ninsertIntoMap (x:xs) parent parentMap =\r\n insertIntoMap xs parent (Map.insert x parent parentMap)\r\n\r\nprintAns :: State -> Map State State -> Int -> IO ()\r\nprintAns state parentMap count =\r\n case Map.lookup state parentMap of\r\n Just parent -> do printGrid parent\r\n printAns parent parentMap (count + 1)\r\n Nothing -> do putStrLn $ \"Minimum path length: \" ++ show count\r\n return ()\r\n\r\nans :: Maybe (State, Map State State) -> IO ()\r\nans (Just (final, parentMap)) = do\r\n printGrid final\r\n printAns final parentMap 0\r\nans _ = putStrLn \"No answer found.\"\r\n\r\nmain :: IO ()\r\nmain = do putStrLn \"Enter initial state: \"\r\n start <- getLine\r\n putStrLn \"Enter final state: \"\r\n final <- getLine\r\n ans $ loop (State final 0) [(State start 0)] [] Map.empty\r\n\r\n}}}\r\n\r\nTest Cases I entered in the order:\r\n\r\n*Main> main\r\n\r\nEnter initial state:\r\n123456 784\r\n\r\nEnter final state:\r\n1234567 8mianrrupted.\r\n\r\n*Main>\r\n\r\n*Main> main\r\n\r\nEnter initial state:\r\n12356 784\r\n\r\nEnter final state:\r\n123586 74\r\n\r\n1 2 3\r\n5 8 6\r\n 7 4\r\n\r\n1 2 3\r\n5 8 6\r\n7 4\r\n\r\n\r\n1 2 3\r\n5 6\r\n7 8 4\r\n\r\n1 2 3\r\n5 6\r\n7 8 4\r\n\r\n\r\nMinimum path length: 3\r\n*Main>\r\n<interactive>: panic! (the 'impossible' happened)\r\n (GHC version 8.0.1 for x86_64-unknown-mingw32):\r\n thread blocked indefinitely in an MVar operation\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14649ghc panic: mergeSATInfo2021-03-26T18:16:22Ztianxiaogughc panic: mergeSATInfoghc panic with option `-O` and `-fstatic-argument-transformation`.
Affected versions include 8.2.2 and HEAD (8.5.20180108)
```hs
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE PartialTypeSignatures #-}
{-# LANGUAGE PolyKinds ...ghc panic with option `-O` and `-fstatic-argument-transformation`.
Affected versions include 8.2.2 and HEAD (8.5.20180108)
```hs
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE PartialTypeSignatures #-}
{-# LANGUAGE PolyKinds #-}
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE TypeOperators #-}
module T12844 where
barWraper :: ('(r,r') ~ Head rngs, Foo rngs) => FooData rngs
barWraper = bar
bar :: (_) => FooData rngs
bar = barWraper
data FooData rngs
class Foo xs where foo :: (Head xs ~ '(r,r')) => FooData xs
type family Head (xs :: [k]) where Head (x ': xs) = x
```
Log:
```
ghc: panic! (the 'impossible' happened)
(GHC version 8.5.20180108 for x86_64-unknown-linux):
mergeSATInfo
Left:STSTSTSTSTSVSV, Right:STSTSTSTSTSVSC
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable
pprPanic, called at compiler/simplCore/SAT.hs:152:20 in ghc:SAT
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ghc panic: mergeSATInfo","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"ghc panic with option `-O` and `-fstatic-argument-transformation`.\r\nAffected versions include 8.2.2 and HEAD (8.5.20180108)\r\n\r\n{{{#!hs\r\n{-# LANGUAGE DataKinds #-}\r\n{-# LANGUAGE PartialTypeSignatures #-}\r\n{-# LANGUAGE PolyKinds #-}\r\n{-# LANGUAGE TypeFamilies #-}\r\n{-# LANGUAGE TypeOperators #-}\r\n\r\nmodule T12844 where\r\n\r\nbarWraper :: ('(r,r') ~ Head rngs, Foo rngs) => FooData rngs\r\nbarWraper = bar\r\n\r\nbar :: (_) => FooData rngs\r\nbar = barWraper\r\n\r\ndata FooData rngs\r\n\r\nclass Foo xs where foo :: (Head xs ~ '(r,r')) => FooData xs\r\n\r\ntype family Head (xs :: [k]) where Head (x ': xs) = x\r\n}}}\r\n\r\nLog:\r\n\r\n{{{\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 8.5.20180108 for x86_64-unknown-linux):\r\n\tmergeSATInfo\r\n Left:STSTSTSTSTSVSV, Right:STSTSTSTSTSVSC\r\n Call stack:\r\n CallStack (from HasCallStack):\r\n callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable\r\n pprPanic, called at compiler/simplCore/SAT.hs:152:20 in ghc:SAT\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14637Simplifier Ticks Exhausted when compiling with profiling2022-03-08T21:02:41ZcfhammillSimplifier Ticks Exhausted when compiling with profilingHi GHC devs,
I've run into a problem with the Frames library, I can compile a simple example using stack without executable profiling enabled, but when I enable profiling I get the simplifier ticks exhausted error. I've tried using -fsi...Hi GHC devs,
I've run into a problem with the Frames library, I can compile a simple example using stack without executable profiling enabled, but when I enable profiling I get the simplifier ticks exhausted error. I've tried using -fsimpl-tick-factor=1000 to no avail. I've attached the stack config, cabal file, haskell code, two csv files, and the simplifier dump. Any help would be appreciated.
Chris
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Simplifier Ticks Exhausted when compiling with profiling","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Hi GHC devs,\r\n\r\nI've run into a problem with the Frames library, I can compile a simple example using stack without executable profiling enabled, but when I enable profiling I get the simplifier ticks exhausted error. I've tried using -fsimpl-tick-factor=1000 to no avail. I've attached the stack config, cabal file, haskell code, two csv files, and the simplifier dump. Any help would be appreciated.\r\n\r\nChris","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14628Panic (No skolem Info) in GHCi2023-11-02T14:36:37ZAndreas KlebingerPanic (No skolem Info) in GHCiLoading the following code in GHCi causes a panic.
Versions affected at least 8.2.2 and 8.0.2
```
module Main where
import System.IO
import Control.Monad.IO.Class
import Control.Monad.Trans.State
import Text.Printf
putArrayBytes :: H...Loading the following code in GHCi causes a panic.
Versions affected at least 8.2.2 and 8.0.2
```
module Main where
import System.IO
import Control.Monad.IO.Class
import Control.Monad.Trans.State
import Text.Printf
putArrayBytes :: Handle -- ^ output file handle
-> [String] -- ^ byte-strings
-> IO Int -- ^ total number of bytes written
putArrayBytes outfile xs = do
let writeCount x = modify' (+ length x) >> liftIO (putLine x) :: MonadIO m => StateT Int m ()
execStateT (mapM_ writeCount xs) 0
where putLine = hPutStrLn outfile . (" "++) . concatMap (printf "0x%02X,")
{-
ghci:
:break 12 46
:trace putArrayBytes stdout [['1'..'9'],['2'..'8'],['3'..'7']]
snd $ runStateT _result 0
-}
main = undefined
```
```
Configuring GHCi with the following packages:
GHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help
[1 of 1] Compiling Main ( C:\test\test.hs, interpreted )
Ok, one module loaded.
Loaded GHCi configuration from C:\Users\Andi\AppData\Local\Temp\ghci34988\ghci-script
*Main> :break 12 46
Breakpoint 0 activated at C:\test\test.hs:12:46-63
*Main> :trace putArrayBytes stdout [['1'..'9'],['2'..'8'],['3'..'7']]
Stopped in Main.putArrayBytes.writeCount, C:\test\test.hs:12:46-63
_result :: StateT Int m () = _
putLine :: [Char] -> IO () = _
x :: [Char] = "123456789"
[C:\test\test.hs:12:46-63] [C:\test\test.hs:12:46-63] *Main> snd $ runStateT _result 0
<interactive>:3:7: error:<interactive>: panic! (the 'impossible' happened)
(GHC version 8.2.2 for x86_64-unknown-mingw32):
No skolem info:
m_I5Cm[rt]
Call stack:
CallStack (from HasCallStack):
prettyCurrentCallStack, called at compiler\utils\Outputable.hs:1133:58 in ghc:Outputable
callStackDoc, called at compiler\utils\Outputable.hs:1137:37 in ghc:Outputable
pprPanic, called at compiler\typecheck\TcErrors.hs:2653:5 in ghc:TcErrors
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
[C:\test\test.hs:12:46-63] [C:\test\test.hs:12:46-63] *Main> :r
[1 of 1] Compiling Main ( C:\test\test.hs, interpreted )
Ok, one module loaded.
*Main> :break 12 46
Breakpoint 1 activated at C:\test\test.hs:12:46-63
*Main> :trace putArrayBytes stdout [['1'..'9'],['2'..'8'],['3'..'7']]
Stopped in Main.putArrayBytes.writeCount, C:\test\test.hs:12:46-63
_result :: StateT Int m () = _
putLine :: [Char] -> IO () = _
x :: [Char] = "123456789"
[C:\test\test.hs:12:46-63] [C:\test\test.hs:12:46-63] *Main> snd $ runStateT _result 0
<interactive>:7:7: error:<interactive>: panic! (the 'impossible' happened)
(GHC version 8.2.2 for x86_64-unknown-mingw32):
No skolem info:
m_I5Nz[rt]
Call stack:
CallStack (from HasCallStack):
prettyCurrentCallStack, called at compiler\utils\Outputable.hs:1133:58 in ghc:Outputable
callStackDoc, called at compiler\utils\Outputable.hs:1137:37 in ghc:Outputable
pprPanic, called at compiler\typecheck\TcErrors.hs:2653:5 in ghc:TcErrors
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
[C:\test\test.hs:12:46-63] [C:\test\test.hs:12:46-63] *Main>
```
Maybe related to #13393.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Panic (No skolem Info) in GHCi","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Loading the following code in GHCi causes a panic.\r\n\r\nVersions affected at least 8.2.2 and 8.0.2\r\n\r\n{{{\r\nmodule Main where\r\n\r\nimport System.IO\r\nimport Control.Monad.IO.Class\r\nimport Control.Monad.Trans.State\r\nimport Text.Printf\r\n\r\nputArrayBytes :: Handle -- ^ output file handle\r\n -> [String] -- ^ byte-strings\r\n -> IO Int -- ^ total number of bytes written\r\nputArrayBytes outfile xs = do\r\n let writeCount x = modify' (+ length x) >> liftIO (putLine x) :: MonadIO m => StateT Int m ()\r\n execStateT (mapM_ writeCount xs) 0\r\n where putLine = hPutStrLn outfile . (\" \"++) . concatMap (printf \"0x%02X,\")\r\n\r\n{-\r\nghci:\r\n:break 12 46\r\n:trace putArrayBytes stdout [['1'..'9'],['2'..'8'],['3'..'7']]\r\nsnd $ runStateT _result 0\r\n-}\r\n\r\nmain = undefined\r\n}}}\r\n\r\n\r\n\r\n{{{\r\nConfiguring GHCi with the following packages:\r\nGHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help\r\n[1 of 1] Compiling Main ( C:\\test\\test.hs, interpreted )\r\nOk, one module loaded.\r\nLoaded GHCi configuration from C:\\Users\\Andi\\AppData\\Local\\Temp\\ghci34988\\ghci-script\r\n*Main> :break 12 46\r\nBreakpoint 0 activated at C:\\test\\test.hs:12:46-63\r\n*Main> :trace putArrayBytes stdout [['1'..'9'],['2'..'8'],['3'..'7']]\r\nStopped in Main.putArrayBytes.writeCount, C:\\test\\test.hs:12:46-63\r\n_result :: StateT Int m () = _\r\nputLine :: [Char] -> IO () = _\r\nx :: [Char] = \"123456789\"\r\n[C:\\test\\test.hs:12:46-63] [C:\\test\\test.hs:12:46-63] *Main> snd $ runStateT _result 0\r\n\r\n<interactive>:3:7: error:<interactive>: panic! (the 'impossible' happened)\r\n (GHC version 8.2.2 for x86_64-unknown-mingw32):\r\n No skolem info:\r\n m_I5Cm[rt]\r\n Call stack:\r\n CallStack (from HasCallStack):\r\n prettyCurrentCallStack, called at compiler\\utils\\Outputable.hs:1133:58 in ghc:Outputable\r\n callStackDoc, called at compiler\\utils\\Outputable.hs:1137:37 in ghc:Outputable\r\n pprPanic, called at compiler\\typecheck\\TcErrors.hs:2653:5 in ghc:TcErrors\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\n[C:\\test\\test.hs:12:46-63] [C:\\test\\test.hs:12:46-63] *Main> :r\r\n[1 of 1] Compiling Main ( C:\\test\\test.hs, interpreted )\r\nOk, one module loaded.\r\n*Main> :break 12 46\r\nBreakpoint 1 activated at C:\\test\\test.hs:12:46-63\r\n*Main> :trace putArrayBytes stdout [['1'..'9'],['2'..'8'],['3'..'7']]\r\nStopped in Main.putArrayBytes.writeCount, C:\\test\\test.hs:12:46-63\r\n_result :: StateT Int m () = _\r\nputLine :: [Char] -> IO () = _\r\nx :: [Char] = \"123456789\"\r\n[C:\\test\\test.hs:12:46-63] [C:\\test\\test.hs:12:46-63] *Main> snd $ runStateT _result 0\r\n\r\n<interactive>:7:7: error:<interactive>: panic! (the 'impossible' happened)\r\n (GHC version 8.2.2 for x86_64-unknown-mingw32):\r\n No skolem info:\r\n m_I5Nz[rt]\r\n Call stack:\r\n CallStack (from HasCallStack):\r\n prettyCurrentCallStack, called at compiler\\utils\\Outputable.hs:1133:58 in ghc:Outputable\r\n callStackDoc, called at compiler\\utils\\Outputable.hs:1137:37 in ghc:Outputable\r\n pprPanic, called at compiler\\typecheck\\TcErrors.hs:2653:5 in ghc:TcErrors\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\n[C:\\test\\test.hs:12:46-63] [C:\\test\\test.hs:12:46-63] *Main>\r\n}}}\r\n\r\nMaybe related to #13393.\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14577Internal error when linker is initialized with -fexternal-interpreter set whe...2019-07-07T18:16:27ZlazacInternal error when linker is initialized with -fexternal-interpreter set when compiling TH code with profilingWhen using the GHC API with this minimal example, using the -fexternal-interpreter option, compiled with profiling enabled:
```hs
import GHC
import Control.Monad.IO.Class
import GHC.Paths ( libdir )
import DynFlags
import Linker
main =...When using the GHC API with this minimal example, using the -fexternal-interpreter option, compiled with profiling enabled:
```hs
import GHC
import Control.Monad.IO.Class
import GHC.Paths ( libdir )
import DynFlags
import Linker
main = runGhc (Just libdir) $ do
env <- getSession
dflags <- getSessionDynFlags
liftIO $ initDynLinker env
setSessionDynFlags (setGeneralFlag' Opt_ExternalInterpreter dflags)
target <- guessTarget "A.hs" Nothing
setTargets [target]
load LoadAllTargets
```
Invoking the main executable:
```
testprof
```
While A.hs contains a TH splice:
```hs
{-# LANGUAGE TemplateHaskell #-}
module A where
$(return [])
```
The compiler crashes:
```
Access violation in generated code when writing 0000000000000024
```
Probably I'm misusing the API in this example, but the way it crashes is suspicious.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHC API |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Internal error when linker is initialized with -fexternal-interpreter set when compiling TH code with profiling","status":"New","operating_system":"","component":"GHC API","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When using the GHC API with this minimal example, using the -fexternal-interpreter option, compiled with profiling enabled:\r\n\r\n{{{#!hs\r\nimport GHC\r\nimport Control.Monad.IO.Class\r\nimport GHC.Paths ( libdir )\r\nimport DynFlags\r\nimport Linker\r\n\r\nmain = runGhc (Just libdir) $ do\r\n env <- getSession\r\n dflags <- getSessionDynFlags\r\n liftIO $ initDynLinker env\r\n setSessionDynFlags (setGeneralFlag' Opt_ExternalInterpreter dflags) \r\n target <- guessTarget \"A.hs\" Nothing\r\n setTargets [target]\r\n load LoadAllTargets\r\n}}}\r\n\r\nInvoking the main executable:\r\n{{{\r\ntestprof\r\n}}}\r\n\r\nWhile A.hs contains a TH splice:\r\n{{{#!hs\r\n{-# LANGUAGE TemplateHaskell #-}\r\nmodule A where\r\n\r\n$(return [])\r\n}}}\r\n\r\nThe compiler crashes:\r\n{{{\r\nAccess violation in generated code when writing 0000000000000024\r\n}}}\r\n\r\nProbably I'm misusing the API in this example, but the way it crashes is suspicious.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14576Internal error when compiling TH code with profiling on Windows2019-07-07T18:16:27ZlazacInternal error when compiling TH code with profiling on WindowsWhen using the GHC API with this minimal example, compiled with profiling enabled:
```hs
module Main where
import GHC
import GHC.Paths ( libdir )
main = runGhc (Just libdir) $ do
env <- getSession
dflags <- getSessionD...When using the GHC API with this minimal example, compiled with profiling enabled:
```hs
module Main where
import GHC
import GHC.Paths ( libdir )
main = runGhc (Just libdir) $ do
env <- getSession
dflags <- getSessionDynFlags
setSessionDynFlags dflags
target <- guessTarget "A.hs" Nothing
setTargets [target]
load LoadAllTargets
```
Invoking the main executable:
```
testprof
```
While A.hs contains a TH splice:
```hs
{-# LANGUAGE TemplateHaskell #-}
module A where
$(return [])
```
The compiler crashes:
```
testprof.exe: internal error: IMAGE_REL_AMD64_ADDR32[NB]: High bits are set in 10e6109d0 for .text
(GHC version 8.2.1 for x86_64_unknown_mingw32)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
```
The walkaround is to use -fexternal-interpreter, in that case, the crash does not happen.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 8.2.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHC API |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown/Multiple |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Internal error when compiling TH code with profiling on Windows","status":"New","operating_system":"Unknown/Multiple","component":"GHC API","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When using the GHC API with this minimal example, compiled with profiling enabled:\r\n\r\n{{{#!hs\r\nmodule Main where\r\n\r\nimport GHC\r\nimport GHC.Paths ( libdir )\r\n\r\nmain = runGhc (Just libdir) $ do\r\n env <- getSession\r\n dflags <- getSessionDynFlags\r\n setSessionDynFlags dflags\r\n target <- guessTarget \"A.hs\" Nothing\r\n setTargets [target]\r\n load LoadAllTargets\r\n}}}\r\n\r\nInvoking the main executable:\r\n{{{\r\ntestprof\r\n}}}\r\n\r\nWhile A.hs contains a TH splice:\r\n{{{#!hs\r\n{-# LANGUAGE TemplateHaskell #-}\r\nmodule A where\r\n\r\n$(return [])\r\n}}}\r\n\r\nThe compiler crashes:\r\n{{{\r\ntestprof.exe: internal error: IMAGE_REL_AMD64_ADDR32[NB]: High bits are set in 10e6109d0 for .text\r\n (GHC version 8.2.1 for x86_64_unknown_mingw32)\r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\nThis application has requested the Runtime to terminate it in an unusual way.\r\nPlease contact the application's support team for more information.\r\n}}}\r\n\r\nThe walkaround is to use -fexternal-interpreter, in that case, the crash does not happen.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14558Unable to parse integer-gmp's Cabal file2019-07-07T18:16:31ZtaylorfausakUnable to parse integer-gmp's Cabal fileinteger-gmp version 1.0.1.0 has this line in [its Cabal file](https://hackage.haskell.org/package/integer-gmp-1.0.1.0/revision/0.cabal): ` build-depends: ghc-prim ^>= 0.5.1.0 `
That uses the new caret constraint syntax. That syntax was ...integer-gmp version 1.0.1.0 has this line in [its Cabal file](https://hackage.haskell.org/package/integer-gmp-1.0.1.0/revision/0.cabal): ` build-depends: ghc-prim ^>= 0.5.1.0 `
That uses the new caret constraint syntax. That syntax was introduced by Cabal 2 a few months ago in July/August. Attempting to build integer-gmp with a slightly older version of Cabal, like 1.24.2.0, or with the latest released version of Stack (1.5.1) fails with this error:
` Unable to parse cabal file for integer-gmp-1.0.1.0: NoParse "build-depends" 58 `
This was reported on Stack's issue tracker and on Reddit:
- https://github.com/commercialhaskell/stack/issues/3624
- https://www.reddit.com/r/haskell/comments/7hs20y/how_to_fix_stack_unable_to_parse_cabal_file/
I was not able to find an issue tracker for integer-gmp. Someone suggested that I open an issue here instead.
I can see how this isn't a bug per se because integer-gmp's Cabal file specifies ` cabal-version: 2.0`. Nevertheless, it's frustrating that a core library is using a bleeding edge feature for basically no reason. It would be nice if integer-gmp used the more typical ` cabal-version: >= 1.10` and specified its dependency as ` build-depends: ghc-prim >= 0.5.1 && <0.6`, without the caret operator.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 8.2.2 |
| Type | Bug |
| TypeOfFailure | CompileTimeCrash |
| Priority | normal |
| Resolution | Unresolved |
| Component | Core Libraries |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Unable to parse integer-gmp's Cabal file","status":"New","operating_system":"","component":"Core Libraries","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"integer-gmp version 1.0.1.0 has this line in [https://hackage.haskell.org/package/integer-gmp-1.0.1.0/revision/0.cabal its Cabal file]: {{{ build-depends: ghc-prim ^>= 0.5.1.0 }}}\r\n\r\nThat uses the new caret constraint syntax. That syntax was introduced by Cabal 2 a few months ago in July/August. Attempting to build integer-gmp with a slightly older version of Cabal, like 1.24.2.0, or with the latest released version of Stack (1.5.1) fails with this error:\r\n\r\n{{{ Unable to parse cabal file for integer-gmp-1.0.1.0: NoParse \"build-depends\" 58 }}}\r\n\r\nThis was reported on Stack's issue tracker and on Reddit:\r\n\r\n- https://github.com/commercialhaskell/stack/issues/3624\r\n- https://www.reddit.com/r/haskell/comments/7hs20y/how_to_fix_stack_unable_to_parse_cabal_file/\r\n\r\nI was not able to find an issue tracker for integer-gmp. Someone suggested that I open an issue here instead. \r\n\r\nI can see how this isn't a bug per se because integer-gmp's Cabal file specifies {{{ cabal-version: 2.0}}}. Nevertheless, it's frustrating that a core library is using a bleeding edge feature for basically no reason. It would be nice if integer-gmp used the more typical {{{ cabal-version: >= 1.10}}} and specified its dependency as {{{ build-depends: ghc-prim >= 0.5.1 && <0.6}}}, without the caret operator. ","type_of_failure":"CompileTimeCrash","blocking":[]} -->Herbert Valerio Riedelhvr@gnu.orgHerbert Valerio Riedelhvr@gnu.orghttps://gitlab.haskell.org/ghc/ghc/-/issues/14533Make GHC more robust against PC crashes by using atomic writes2021-03-02T16:58:07ZNiklas Hambüchenmail@nh2.meMake GHC more robust against PC crashes by using atomic writesYesterday my Windows machine crashed when ghc was building, left me with a lot of corrupted .hi files (and probably .o files as well).
That made me think if we should change ghc to write its output with atomic moves.
Discussion on `#gh...Yesterday my Windows machine crashed when ghc was building, left me with a lot of corrupted .hi files (and probably .o files as well).
That made me think if we should change ghc to write its output with atomic moves.
Discussion on `#ghc`:
```
bgamari:
nh2: well, perhaps
I'm not sure it's terribly common for compilers to take such precautions though
and if we were to do it for interface files then presumably we would also want to do it for object files
siarheit_:
that would be very nice
geekosaur:
compilers in general are happy to write out incomplete/garbage object files
bgamari:
it seems that way
nh2:
bgamari: right, if we wanted to do it we should do it for all files ghc writes.
Possible that other compilers can also write garbage, but maybe ghc can do better -- one less thing the developer has to think about
Phyx-:
most compilers also don't do the aggressive recompilation avoidance things we do either..
corrupt hi files wouldn't be an issue if the next time it would override them :)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | nh2 |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Make GHC more robust against PC crashes by using atomic writes","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["nh2"],"type":"Bug","description":"Yesterday my Windows machine crashed when ghc was building, left me with a lot of corrupted .hi files (and probably .o files as well).\r\n\r\nThat made me think if we should change ghc to write its output with atomic moves.\r\n\r\nDiscussion on `#ghc`:\r\n\r\n{{{\r\nbgamari:\r\nnh2: well, perhaps\r\nI'm not sure it's terribly common for compilers to take such precautions though\r\nand if we were to do it for interface files then presumably we would also want to do it for object files\r\n\r\nsiarheit_:\r\nthat would be very nice\r\n\r\ngeekosaur:\r\ncompilers in general are happy to write out incomplete/garbage object files\r\n\r\nbgamari:\r\nit seems that way\r\n\r\nnh2:\r\nbgamari: right, if we wanted to do it we should do it for all files ghc writes.\r\nPossible that other compilers can also write garbage, but maybe ghc can do better -- one less thing the developer has to think about\r\n\r\nPhyx-:\r\nmost compilers also don't do the aggressive recompilation avoidance things we do either..\r\ncorrupt hi files wouldn't be an issue if the next time it would override them :)\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14512System-wide installed profile build cannot load libHSghc-prim.0.5.2.0.so2020-01-23T19:27:39ZTobias Dammerstdammers@gmail.comSystem-wide installed profile build cannot load libHSghc-prim.0.5.2.0.soSteps to reproduce:
1. Make a pristine git checkout
1. Follow the steps outlined in https://ghc.haskell.org/trac/ghc/wiki/Building/QuickStart, uncommenting the `BuildFlavour = prof` line in `build.mk`, to build and install ghc.
1. Check...Steps to reproduce:
1. Make a pristine git checkout
1. Follow the steps outlined in https://ghc.haskell.org/trac/ghc/wiki/Building/QuickStart, uncommenting the `BuildFlavour = prof` line in `build.mk`, to build and install ghc.
1. Check ghc version to verify that this ghc build is the one in `/usr/local/bin`
1. Try to compile the following `hello.hs`:
```hs
{-# LANGUAGE TemplateHaskell #-}
import Language.Haskell.TH
main = putStrLn $(litE (stringL "Hello"))
```
It should fail with an error message similar to:
```
<no location info>: error:
ghc: panic! (the 'impossible' happened)
(GHC version 8.3.20171120 for x86_64-unknown-linux):
Dynamic linker not initialised
CallStack (from -prof):
Linker.CAF (<entire-module>)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
and:
```
<no location info>: error:
<command line>: can't load .so/.DLL for: libHSghc-prim-0.5.2.0.so (libHSghc-prim-0.5.2.0.so: cannot open shared object file: No such file or directory)
```
By contrast, the following do \*not\* trigger the error:
- Building GHC without uncommenting the `BuildFlavour` line in `build.mk`
- Compiling with the `inplace/bin/ghc-stage2` in the GHC source tree
- Compiling a `hello.hs` that does not use TemplateHaskell
Further system info:
- Debian 9
- Cabal version 1.24
- GHC 8.0.1
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"System-wide installed profile build cannot load libHSghc-prim.0.5.2.0.so","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Steps to reproduce:\r\n\r\n1. Make a pristine git checkout\r\n2. Follow the steps outlined in https://ghc.haskell.org/trac/ghc/wiki/Building/QuickStart, uncommenting the `BuildFlavour = prof` line in `build.mk`, to build and install ghc.\r\n3. Check ghc version to verify that this ghc build is the one in `/usr/local/bin`\r\n4. Try to compile the following `hello.hs`:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE TemplateHaskell #-}\r\n\r\nimport Language.Haskell.TH\r\n\r\nmain = putStrLn $(litE (stringL \"Hello\"))\r\n}}}\r\n\r\nIt should fail with an error message similar to:\r\n\r\n{{{\r\n<no location info>: error:\r\n ghc: panic! (the 'impossible' happened)\r\n (GHC version 8.3.20171120 for x86_64-unknown-linux):\r\n\tDynamic linker not initialised\r\nCallStack (from -prof):\r\n Linker.CAF (<entire-module>)\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\nand:\r\n\r\n{{{\r\n<no location info>: error:\r\n <command line>: can't load .so/.DLL for: libHSghc-prim-0.5.2.0.so (libHSghc-prim-0.5.2.0.so: cannot open shared object file: No such file or directory)\r\n}}}\r\n\r\nBy contrast, the following do *not* trigger the error:\r\n\r\n- Building GHC without uncommenting the `BuildFlavour` line in `build.mk`\r\n- Compiling with the `inplace/bin/ghc-stage2` in the GHC source tree\r\n- Compiling a `hello.hs` that does not use TemplateHaskell\r\n\r\nFurther system info:\r\n\r\n- Debian 9\r\n- Cabal version 1.24\r\n- GHC 8.0.1\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/14063Compiling with --backpack with undefined dependency results in "the 'impossib...2023-05-05T12:59:10ZrcookCompiling with --backpack with undefined dependency results in "the 'impossible' happened"Using GHC 8.2.1:
```
> ghc --version
The Glorious Glasgow Haskell Compilation System, version 8.2.1
```
And compiling with `--backpack` as follows:
```
> ghc --backpack foo.bkp
[1 of 4] Processing foo-indef
[1 of 2] Compiling Str[si...Using GHC 8.2.1:
```
> ghc --version
The Glorious Glasgow Haskell Compilation System, version 8.2.1
```
And compiling with `--backpack` as follows:
```
> ghc --backpack foo.bkp
[1 of 4] Processing foo-indef
[1 of 2] Compiling Str[sig] ( foo-indef\Str.hsig, nothing )
[2 of 2] Compiling Foo ( foo-indef\Foo.hs, nothing )
[2 of 4] Processing foo-string
Instantiating foo-string
[1 of 1] Compiling Str ( foo-string\Str.hs, foo-string\Str.o )
[3 of 4] Processing foo-int
Instantiating foo-int
[1 of 1] Compiling Str ( foo-int\Str.hs, foo-int\Str.o )
[4 of 4] Processing main
ghc.EXE: panic! (the 'impossible' happened)
(GHC version 8.2.1 for x86_64-unknown-mingw32):
no package name
CallStack (from HasCallStack):
error, called at compiler\backpack\DriverBkp.hs:573:32 in ghc:DriverBkp
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
make: *** [foo-indef/Foo.hi] Error 1
```
See attached `foo.bkp` file. While the Backpack file *is* invalid, in that the `main` unit mentions the `foo` dependency, which does not exist, this shouldn't lead to a GHC panic.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Compiling with --backpack with undefined dependency results in \"the 'impossible' happened\"","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1","keywords":["Backpack"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Using GHC 8.2.1:\r\n\r\n{{{\r\n> ghc --version\r\nThe Glorious Glasgow Haskell Compilation System, version 8.2.1\r\n}}}\r\n\r\nAnd compiling with `--backpack` as follows:\r\n\r\n{{{\r\n> ghc --backpack foo.bkp\r\n[1 of 4] Processing foo-indef\r\n [1 of 2] Compiling Str[sig] ( foo-indef\\Str.hsig, nothing )\r\n [2 of 2] Compiling Foo ( foo-indef\\Foo.hs, nothing )\r\n[2 of 4] Processing foo-string\r\n Instantiating foo-string\r\n [1 of 1] Compiling Str ( foo-string\\Str.hs, foo-string\\Str.o )\r\n[3 of 4] Processing foo-int\r\n Instantiating foo-int\r\n [1 of 1] Compiling Str ( foo-int\\Str.hs, foo-int\\Str.o )\r\n[4 of 4] Processing main\r\nghc.EXE: panic! (the 'impossible' happened)\r\n (GHC version 8.2.1 for x86_64-unknown-mingw32):\r\n no package name\r\nCallStack (from HasCallStack):\r\n error, called at compiler\\backpack\\DriverBkp.hs:573:32 in ghc:DriverBkp\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\nmake: *** [foo-indef/Foo.hi] Error 1\r\n}}}\r\n\r\nSee attached `foo.bkp` file. While the Backpack file ''is'' invalid, in that the `main` unit mentions the `foo` dependency, which does not exist, this shouldn't lead to a GHC panic.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->Edward Z. YangEdward Z. Yanghttps://gitlab.haskell.org/ghc/ghc/-/issues/13723Recover gracefully from simplifier tick exhaustion2020-01-23T19:31:02ZDavid FeuerRecover gracefully from simplifier tick exhaustionCurrently, we have just one tick limit. If the simplifier runs out of ticks, GHC simply gives up and exits. But that shouldn't *really* be necessary. In a more ideal world, we'd have two or even three tick limits for different kinds of t...Currently, we have just one tick limit. If the simplifier runs out of ticks, GHC simply gives up and exits. But that shouldn't *really* be necessary. In a more ideal world, we'd have two or even three tick limits for different kinds of transformations. For example, there are
### Transformations that must be performed before `CorePrep`
I hope that we can give a hard upper bound on how many ticks we need to perform these for a given program size. If that limit is exceeded, then we should report a bug.
### Transformations that always reduce program size
If a transformation always reduces program size, we can always perform it, even if we're otherwise out of ticks. This includes, at least, beta reduction without duplication. While `RULES` are generally wild, it should be safe to apply rules that reduce code size *immediately*. For example,
```hs
foldr c n (build f) ==> f c n
```
is always fine. These transformations can share a tick limit with the mandatory transformations mentioned above.
### Transformations that never increase program size
We can be generous with these, but need some limit.
### Transformations that may increase program size
These need the harshest limit, of course, but probably not (much?) harsher than what we currently have.
----
The idea is that even if one tick limit is exceeded, the "higher priority" transformations can be allowed to continue anyway. Exceeding tick limits for most transformations would lead to a warning, rather than an error.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.2.1-rc2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Recover gracefully from simplifier tick exhaustion","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.4.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1-rc2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Currently, we have just one tick limit. If the simplifier runs out of ticks, GHC simply gives up and exits. But that shouldn't ''really'' be necessary. In a more ideal world, we'd have two or even three tick limits for different kinds of transformations. For example, there are\r\n\r\n=== Transformations that must be performed before `CorePrep` ===\r\n\r\nI hope that we can give a hard upper bound on how many ticks we need to perform these for a given program size. If that limit is exceeded, then we should report a bug.\r\n\r\n=== Transformations that always reduce program size ===\r\n\r\nIf a transformation always reduces program size, we can always perform it, even if we're otherwise out of ticks. This includes, at least, beta reduction without duplication. While `RULES` are generally wild, it should be safe to apply rules that reduce code size ''immediately''. For example,\r\n\r\n{{{#!hs\r\nfoldr c n (build f) ==> f c n\r\n}}}\r\n\r\nis always fine. These transformations can share a tick limit with the mandatory transformations mentioned above.\r\n\r\n=== Transformations that never increase program size ===\r\n\r\nWe can be generous with these, but need some limit.\r\n\r\n=== Transformations that may increase program size ===\r\n\r\nThese need the harshest limit, of course, but probably not (much?) harsher than what we currently have.\r\n\r\n----\r\n\r\nThe idea is that even if one tick limit is exceeded, the \"higher priority\" transformations can be allowed to continue anyway. Exceeding tick limits for most transformations would lead to a warning, rather than an error.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/13715test dynamic-paper for way profasm fails with Simplifier ticks exhausted2019-07-07T18:20:28Zgeorge.colpittstest dynamic-paper for way profasm fails with Simplifier ticks exhaustedon ghc 8.2.1-rc2 on a mac running the latest Xcode and os
{{{
make TEST=dynamic-paper WAY=profasm
fails with
ghc-stage2: panic! (the 'impossible' happened)
(GHC version 8.2.0.20170507 for x86_64-apple-darwin):
Simplifier ticks exhaust...on ghc 8.2.1-rc2 on a mac running the latest Xcode and os
{{{
make TEST=dynamic-paper WAY=profasm
fails with
ghc-stage2: panic! (the 'impossible' happened)
(GHC version 8.2.0.20170507 for x86_64-apple-darwin):
Simplifier ticks exhausted
When trying UnfoldingDone delta
1. ..
Call stack:
CallStack (from HasCallStack):
prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1134:58 in ghc:Outputable
callStackDoc, called at compiler/utils/Outputable.hs:1138:37 in ghc:Outputable
pprPanic, called at compiler/simplCore/SimplMonad.hs:199:31 in ghc:SimplMonad
it also fails with 1000 ticks
make TEST=dynamic-paper WAY=profasm EXTRA_HC_OPTS='-fsimpl-tick-factor=1000'
so there may be an infinite loop
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.1-rc2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"test dynamic-paper for way profasm fails with Simplifier ticks exhausted","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1-rc2","keywords":["simplifier","ticks"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"on ghc 8.2.1-rc2 on a mac running the latest Xcode and os\r\n{{{\r\nmake TEST=dynamic-paper WAY=profasm \r\nfails with \r\nghc-stage2: panic! (the 'impossible' happened)\r\n\t (GHC version 8.2.0.20170507 for x86_64-apple-darwin):\r\n\t\tSimplifier ticks exhausted\r\n\t When trying UnfoldingDone delta\r\n...\r\nCall stack:\r\n\t CallStack (from HasCallStack):\r\n\t\tprettyCurrentCallStack, called at compiler/utils/Outputable.hs:1134:58 in ghc:Outputable\r\n\t\tcallStackDoc, called at compiler/utils/Outputable.hs:1138:37 in ghc:Outputable\r\n\t\tpprPanic, called at compiler/simplCore/SimplMonad.hs:199:31 in ghc:SimplMonad\r\n\r\nit also fails with 1000 ticks\r\nmake TEST=dynamic-paper WAY=profasm EXTRA_HC_OPTS='-fsimpl-tick-factor=1000'\r\nso there may be an infinite loop","type_of_failure":"OtherFailure","blocking":[]} -->Research needed