GHC issues
https://gitlab.haskell.org/ghc/ghc/-/issues
2023-01-12T16:27:32Z
https://gitlab.haskell.org/ghc/ghc/-/issues/15025
Lingering @since TODO Haddock annotations
2023-01-12T16:27:32Z
Ryan Scott
Lingering @since TODO Haddock annotations
There are currently a handful of `@since TODO` annotations in Haddocks throughout the core libraries that were probably intended to be replaced with a real version at some point, but managed to slip through the cracks into the GHC 8.4.1 ...
There are currently a handful of `@since TODO` annotations in Haddocks throughout the core libraries that were probably intended to be replaced with a real version at some point, but managed to slip through the cracks into the GHC 8.4.1 release:
- `FixIOException` in `base`: http://git.haskell.org/ghc.git/blob/270e3e9bbaabad3d9a1348cea9e46a9ecf1e5ec2:/libraries/base/GHC/IO/Exception.hs\#l276
- `powModSecInteger` in `integer-gmp`: http://git.haskell.org/ghc.git/blob/270e3e9bbaabad3d9a1348cea9e46a9ecf1e5ec2:/libraries/integer-gmp/src/GHC/Integer/Type.hs\#l1454
We should fix these before GHC 8.4.2.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 8.4.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | libraries (other) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Lingering @since TODO Haddock annotations","status":"New","operating_system":"","component":"libraries (other)","related":[],"milestone":"8.4.2","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"There are currently a handful of `@since TODO` annotations in Haddocks throughout the core libraries that were probably intended to be replaced with a real version at some point, but managed to slip through the cracks into the GHC 8.4.1 release:\r\n\r\n* `FixIOException` in `base`: http://git.haskell.org/ghc.git/blob/270e3e9bbaabad3d9a1348cea9e46a9ecf1e5ec2:/libraries/base/GHC/IO/Exception.hs#l276\r\n* `powModSecInteger` in `integer-gmp`: http://git.haskell.org/ghc.git/blob/270e3e9bbaabad3d9a1348cea9e46a9ecf1e5ec2:/libraries/integer-gmp/src/GHC/Integer/Type.hs#l1454\r\n\r\nWe should fix these before GHC 8.4.2.","type_of_failure":"OtherFailure","blocking":[]} -->
8.4.2
https://gitlab.haskell.org/ghc/ghc/-/issues/15023
GHC 8.4.1 bundles w/ phony `mtl-2.2.2` release
2019-07-07T18:14:39Z
Herbert Valerio Riedel
hvr@gnu.org
GHC 8.4.1 bundles w/ phony `mtl-2.2.2` release
Despite
#14699\##15023
it appears that GHC 8.4.1 shipped with
bf4af114ba3d35b2937fc74926aa49e128dd6c1f
(which doesn't correspond to any released version) instead of the expected `v2.2.2` tagged
c7d396732bd45e409478bd4df1d0ca95d6f393...
Despite
#14699\##15023
it appears that GHC 8.4.1 shipped with
bf4af114ba3d35b2937fc74926aa49e128dd6c1f
(which doesn't correspond to any released version) instead of the expected `v2.2.2` tagged
c7d396732bd45e409478bd4df1d0ca95d6f39356
commit.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 8.4.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | libraries (other) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC 8.4.1 bundles w/ phony `mtl-2.2.2` release","status":"New","operating_system":"","component":"libraries (other)","related":[],"milestone":"8.4.2","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Despite \r\n\r\nhttps://ghc.haskell.org/trac/ghc/ticket/14699#comment:25\r\n\r\nit appears that GHC 8.4.1 shipped with \r\n\r\nbf4af114ba3d35b2937fc74926aa49e128dd6c1f\r\n\r\n(which doesn't correspond to any released version) instead of the expected `v2.2.2` tagged\r\n\r\nc7d396732bd45e409478bd4df1d0ca95d6f39356\r\n\r\ncommit.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->
8.4.2
https://gitlab.haskell.org/ghc/ghc/-/issues/15005
GHC fails with “StgCmmEnv: variable not found” when trying to compile order-m...
2019-07-07T18:14:43Z
Wolfgang Jeltsch
GHC fails with “StgCmmEnv: variable not found” when trying to compile order-maintenance-0.2.1.0
When trying to build `order-maintenance-0.2.1.0`, GHC 8.4.2-rc1 panics. Its output is as follows:
```
[ 1 of 21] Compiling Data.Order.Algorithm.Raw ( src/library/Data/Order/Algorithm/Raw.hs, /home/wolfgang/Entwicklung/Haskell/order-main...
When trying to build `order-maintenance-0.2.1.0`, GHC 8.4.2-rc1 panics. Its output is as follows:
```
[ 1 of 21] Compiling Data.Order.Algorithm.Raw ( src/library/Data/Order/Algorithm/Raw.hs, /home/wolfgang/Entwicklung/Haskell/order-maintenance-0.2.1.0/dist-newstyle/build/x86_64-linux/ghc-8.4.1.20180329/order-maintenance-0.2.1.0/build/Data/Order/Algorithm/Raw.o )
[ 2 of 21] Compiling Data.Order.Algorithm.Raw.DietzSleatorAmortizedLog ( src/library/Data/Order/Algorithm/Raw/DietzSleatorAmortizedLog.hs, /home/wolfgang/Entwicklung/Haskell/order-maintenance-0.2.1.0/dist-newstyle/build/x86_64-linux/ghc-8.4.1.20180329/order-maintenance-0.2.1.0/build/Data/Order/Algorithm/Raw/DietzSleatorAmortizedLog.o )
ghc: panic! (the 'impossible' happened)
(GHC version 8.4.1.20180329 for x86_64-unknown-linux):
StgCmmEnv: variable not found
x_a46z
local binds for:
$tc'Label
$tcLabel
$tc'Cell
$tcCell
$trModule
$tc'Cell1
$tc'Cell2
$tc'Cell3
$trModule1
$trModule2
$trModule3
$trModule4
$tc'Label1
$tc'Label2
$tc'Label3
$tcCell1
$tcCell2
$tcLabel1
$tcLabel2
lvl_r4UD
lvl1_r4UE
lvl2_r4UF
lvl3_r4UG
lvl4_r4UH
lvl5_r4UI
lvl6_r4UJ
lvl7_r4UK
lvl8_r4UL
lvl9_r4UM
lvl10_r4UN
lvl11_r4UO
lvl12_r4UP
lvl13_r4UQ
lvl14_r4UR
lvl15_r4US
lvl16_r4UT
lvl17_r4UU
$krep_r4UV
$krep1_r4UW
$krep2_r4UX
lvl18_r4UY
$krep3_r4UZ
$krep4_r4V0
$krep5_r4V1
$krep6_r4V2
$krep7_r4V3
$krep8_r4V4
$krep9_r4V5
lvl19_r4V6
lvl20_r4V7
lvl21_r4V8
lvl22_r4V9
lvl23_r4Va
lvl24_r4Vb
lvl25_r4Vc
ww_s4W2
lwild_s4W3
lwild1_s4W4
noOfLabels_s4W5
noOfLabels1_s4W6
labelMask_s4W7
$wnewAfterCell_s4Wa
ww1_s4Wb
ipv1_s4Wf
wild_s4Wg
ds_s4Wh
ds2_s4Wi
ww2_s4Wk
ww3_s4Wl
ww4_s4Wn
ww5_s4Wo
wild1_s4Wq
smallGap_s4Wr
wild2_s4Ws
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable
pprPanic, called at compiler/codeGen/StgCmmEnv.hs:149:9 in ghc:StgCmmEnv
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
The same problem exists with GHC 8.4.1.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.2-rc1 |
| 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 fails with “StgCmmEnv: variable not found” when trying to compile order-maintenance-0.2.1.0","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.4.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.2-rc1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When trying to build `order-maintenance-0.2.1.0`, GHC 8.4.2-rc1 panics. Its output is as follows:\r\n\r\n{{{\r\n[ 1 of 21] Compiling Data.Order.Algorithm.Raw ( src/library/Data/Order/Algorithm/Raw.hs, /home/wolfgang/Entwicklung/Haskell/order-maintenance-0.2.1.0/dist-newstyle/build/x86_64-linux/ghc-8.4.1.20180329/order-maintenance-0.2.1.0/build/Data/Order/Algorithm/Raw.o )\r\n[ 2 of 21] Compiling Data.Order.Algorithm.Raw.DietzSleatorAmortizedLog ( src/library/Data/Order/Algorithm/Raw/DietzSleatorAmortizedLog.hs, /home/wolfgang/Entwicklung/Haskell/order-maintenance-0.2.1.0/dist-newstyle/build/x86_64-linux/ghc-8.4.1.20180329/order-maintenance-0.2.1.0/build/Data/Order/Algorithm/Raw/DietzSleatorAmortizedLog.o )\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 8.4.1.20180329 for x86_64-unknown-linux):\r\n\tStgCmmEnv: variable not found\r\n x_a46z\r\n local binds for:\r\n $tc'Label\r\n $tcLabel\r\n $tc'Cell\r\n $tcCell\r\n $trModule\r\n $tc'Cell1\r\n $tc'Cell2\r\n $tc'Cell3\r\n $trModule1\r\n $trModule2\r\n $trModule3\r\n $trModule4\r\n $tc'Label1\r\n $tc'Label2\r\n $tc'Label3\r\n $tcCell1\r\n $tcCell2\r\n $tcLabel1\r\n $tcLabel2\r\n lvl_r4UD\r\n lvl1_r4UE\r\n lvl2_r4UF\r\n lvl3_r4UG\r\n lvl4_r4UH\r\n lvl5_r4UI\r\n lvl6_r4UJ\r\n lvl7_r4UK\r\n lvl8_r4UL\r\n lvl9_r4UM\r\n lvl10_r4UN\r\n lvl11_r4UO\r\n lvl12_r4UP\r\n lvl13_r4UQ\r\n lvl14_r4UR\r\n lvl15_r4US\r\n lvl16_r4UT\r\n lvl17_r4UU\r\n $krep_r4UV\r\n $krep1_r4UW\r\n $krep2_r4UX\r\n lvl18_r4UY\r\n $krep3_r4UZ\r\n $krep4_r4V0\r\n $krep5_r4V1\r\n $krep6_r4V2\r\n $krep7_r4V3\r\n $krep8_r4V4\r\n $krep9_r4V5\r\n lvl19_r4V6\r\n lvl20_r4V7\r\n lvl21_r4V8\r\n lvl22_r4V9\r\n lvl23_r4Va\r\n lvl24_r4Vb\r\n lvl25_r4Vc\r\n ww_s4W2\r\n lwild_s4W3\r\n lwild1_s4W4\r\n noOfLabels_s4W5\r\n noOfLabels1_s4W6\r\n labelMask_s4W7\r\n $wnewAfterCell_s4Wa\r\n ww1_s4Wb\r\n ipv1_s4Wf\r\n wild_s4Wg\r\n ds_s4Wh\r\n ds2_s4Wi\r\n ww2_s4Wk\r\n ww3_s4Wl\r\n ww4_s4Wn\r\n ww5_s4Wo\r\n wild1_s4Wq\r\n smallGap_s4Wr\r\n wild2_s4Ws\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/codeGen/StgCmmEnv.hs:149:9 in ghc:StgCmmEnv\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\nThe same problem exists with GHC 8.4.1.","type_of_failure":"OtherFailure","blocking":[]} -->
8.4.2
https://gitlab.haskell.org/ghc/ghc/-/issues/15002
Panic: collectNBinders
2023-09-01T12:15:47Z
Eric Crockett
Panic: collectNBinders
Steps to reproduce:
Download concurrent-extra-0.7.0.12 and add the following stack.yaml file:
```
resolver: nightly-2018-04-04
system-ghc: true
compiler-check: newer-minor
```
Then run:
```
> ghc --version
The Glorious Glasgow Haskel...
Steps to reproduce:
Download concurrent-extra-0.7.0.12 and add the following stack.yaml file:
```
resolver: nightly-2018-04-04
system-ghc: true
compiler-check: newer-minor
```
Then run:
```
> ghc --version
The Glorious Glasgow Haskell Compilation System, version 8.4.1.20180329
> stack build --library-profiling
concurrent-extra-0.7.0.12: build (lib)
Preprocessing library for concurrent-extra-0.7.0.12..
Building library for concurrent-extra-0.7.0.12..
[7 of 8] Compiling Control.Concurrent.Broadcast ( Control/Concurrent/Broadcast.hs, .stack-work/dist/x86_64-linux/Cabal-2.2.0.1/build/Control/Concurrent/Broadcast.p_o )
ghc: panic! (the 'impossible' happened)
(GHC version 8.4.1.20180329 for x86_64-unknown-linux):
collectNBinders
1
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable
pprPanic, called at compiler/coreSyn/CoreSyn.hs:2189:39 in ghc:CoreSyn
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
-- While building custom Setup.hs for package concurrent-extra-0.7.0.12 using:
/home/local/ANT/ericcro/.stack/setup-exe-cache/x86_64-linux/Cabal-simple_mPHDZzAJ_2.2.0.1_ghc-8.4.1.20180329 --builddir=.stack-work/dist/x86_64-linux/Cabal-2.2.0.1 build lib:concurrent-extra --ghc-options " -ddump-hi -ddump-to-file -fdiagnostics-color=always"
Process exited with code: ExitFailure 1
```
8.4.2
Joachim Breitner
mail@joachim-breitner.de
Joachim Breitner
mail@joachim-breitner.de
https://gitlab.haskell.org/ghc/ghc/-/issues/14982
LLVM default -mcpu setting inhibits customization
2019-07-07T18:14:48Z
Thomas Main DuBuisson
LLVM default -mcpu setting inhibits customization
With GHC 8.4.1 we are now passing a default `-mcpu` selection to llvm. This default is passed regardless of any explicit command line option such as `-optlc=-mcpu=native`. If/when the user explicitly specifies the architecture we now get...
With GHC 8.4.1 we are now passing a default `-mcpu` selection to llvm. This default is passed regardless of any explicit command line option such as `-optlc=-mcpu=native`. If/when the user explicitly specifies the architecture we now get a failed build. The error message from LLVM is:
```
llc: for the -mcpu option: may only occur zero or one times!
`llc' failed in phase `LLVM Compiler'. (Exit code: 1)
```
This is when compiling with GHC 8.4.1 as such:
{{{
ghc-8.4.1 -fforce-recomp -fllvm -optlc=-mcpu=native -O2 tt.hs
}}
I suggest we either check for a user option of `mcpu` before adding the default or revert this behavior and allow llvm to take it's (optimistic and less portable) default.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | --------------- |
| Version | 8.4.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (LLVM) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"LLVM default -mcpu setting inhibits customization","status":"New","operating_system":"","component":"Compiler (LLVM)","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"With GHC 8.4.1 we are now passing a default `-mcpu` selection to llvm. This default is passed regardless of any explicit command line option such as `-optlc=-mcpu=native`. If/when the user explicitly specifies the architecture we now get a failed build. The error message from LLVM is:\r\n\r\n{{{\r\nllc: for the -mcpu option: may only occur zero or one times!\r\n`llc' failed in phase `LLVM Compiler'. (Exit code: 1)\r\n}}}\r\n\r\nThis is when compiling with GHC 8.4.1 as such:\r\n\r\n{{{\r\nghc-8.4.1 -fforce-recomp -fllvm -optlc=-mcpu=native -O2 tt.hs\r\n}}\r\n\r\nI suggest we either check for a user option of `mcpu` before adding the default or revert this behavior and allow llvm to take it's (optimistic and less portable) default.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->
8.4.2
https://gitlab.haskell.org/ghc/ghc/-/issues/14972
MacOS panic on TH
2019-07-07T18:14:50Z
Alec Theriault
MacOS panic on TH
I recently did a clean build of master (affdea82bb70e5a912b679a169c6e9a230e4c93e) and, while everything successfully finished, I'm getting panics every time I try to use this GHC for something that involves TH.
For example:
```hs
{-# l...
I recently did a clean build of master (affdea82bb70e5a912b679a169c6e9a230e4c93e) and, while everything successfully finished, I'm getting panics every time I try to use this GHC for something that involves TH.
For example:
```hs
{-# language TemplateHaskell #-}
pure []
main = pure []
```
Crashes with
```
$ ./inplace/bin/ghc-stage2 th.hs
[1 of 1] Compiling Main ( th.hs, th.o )
ghc-stage2: loadArchive: Failed reading header from `/Users/atheriault/Documents/code/ghc/libraries/integer-gmp/dist-install/build/gmp'
ghc-stage2: panic! (the 'impossible' happened)
(GHC version 8.5.20180325 for x86_64-apple-darwin):
loadArchive "/Users/atheriault/Documents/code/ghc/libraries/integer-gmp/dist-install/build/gmp": failed
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
Normally I'd assume I haven't correctly configured something, yet I had no problem building and running GHC on this machine a month or so ago...
<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":"MacOS panic on TH","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":"I recently did a clean build of master (affdea82bb70e5a912b679a169c6e9a230e4c93e) and, while everything successfully finished, I'm getting panics every time I try to use this GHC for something that involves TH.\r\n\r\nFor example:\r\n\r\n{{{#!hs\r\n{-# language TemplateHaskell #-}\r\n\r\npure []\r\nmain = pure []\r\n}}}\r\n\r\nCrashes with\r\n\r\n{{{\r\n$ ./inplace/bin/ghc-stage2 th.hs\r\n[1 of 1] Compiling Main ( th.hs, th.o )\r\nghc-stage2: loadArchive: Failed reading header from `/Users/atheriault/Documents/code/ghc/libraries/integer-gmp/dist-install/build/gmp'\r\nghc-stage2: panic! (the 'impossible' happened)\r\n (GHC version 8.5.20180325 for x86_64-apple-darwin):\r\n loadArchive \"/Users/atheriault/Documents/code/ghc/libraries/integer-gmp/dist-install/build/gmp\": failed\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\nNormally I'd assume I haven't correctly configured something, yet I had no problem building and running GHC on this machine a month or so ago...","type_of_failure":"OtherFailure","blocking":[]} -->
8.4.2
https://gitlab.haskell.org/ghc/ghc/-/issues/14965
GHC 8.4.1 bug: -O + separate compilation + three list fields + concatenation;...
2019-07-07T18:14:52Z
blynn
GHC 8.4.1 bug: -O + separate compilation + three list fields + concatenation; core-lint fails
A simple program that works in 8.2.1 fails in 8.4.1 when compiled with -O. (Sorry, haven't tested 8.2.2.) GHC with -dcore-lint reports an error.
See attached files. In one file I declared:
```hs
module Sep where
data Sep = Sep
{ bug...
A simple program that works in 8.2.1 fails in 8.4.1 when compiled with -O. (Sorry, haven't tested 8.2.2.) GHC with -dcore-lint reports an error.
See attached files. In one file I declared:
```hs
module Sep where
data Sep = Sep
{ bugVanishesWithoutThis :: [()]
, middle :: [String]
, orThis :: [()]
}
catSep :: Sep -> Sep -> Sep
catSep (Sep a b c) (Sep x y z) = Sep (a ++ x) (b ++ y) (c ++ z)
cc :: Sep -> Bool
cc boost = elem "foo" $ middle boost
```
and in a second file, simple code fails when compiled with -O:
```hs
module Main (main) where
import Sep
main :: IO ()
main = print $ cc bb
bb :: Sep
bb = catSep b1 b2
b1 :: Sep
b1 = Sep [] ["foo"] []
b2 :: Sep
b2 = Sep [] ["bar"] []
```
This should print "True", and does so for GHC 8.2.1, and GHC 8.4.1 without -O, but prints "False" for GHC 8.4.1 with -O.
I was unable to reproduce the bug with a single file.
<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 | ben@dfinity.org |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC 8.4.1 bug: -O + separate compilation + three list fields + concatenation; core-lint fails","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ben@dfinity.org"],"type":"Bug","description":"A simple program that works in 8.2.1 fails in 8.4.1 when compiled with -O. (Sorry, haven't tested 8.2.2.) GHC with -dcore-lint reports an error.\r\n\r\nSee attached files. In one file I declared:\r\n\r\n{{{#!hs\r\nmodule Sep where\r\n\r\ndata Sep = Sep\r\n { bugVanishesWithoutThis :: [()]\r\n , middle :: [String]\r\n , orThis :: [()]\r\n }\r\n\r\ncatSep :: Sep -> Sep -> Sep\r\ncatSep (Sep a b c) (Sep x y z) = Sep (a ++ x) (b ++ y) (c ++ z)\r\n\r\ncc :: Sep -> Bool\r\ncc boost = elem \"foo\" $ middle boost\r\n}}}\r\n\r\nand in a second file, simple code fails when compiled with -O:\r\n\r\n{{{#!hs\r\nmodule Main (main) where\r\n\r\nimport Sep\r\n\r\nmain :: IO ()\r\nmain = print $ cc bb\r\n\r\nbb :: Sep\r\nbb = catSep b1 b2\r\n\r\nb1 :: Sep\r\nb1 = Sep [] [\"foo\"] []\r\n\r\nb2 :: Sep\r\nb2 = Sep [] [\"bar\"] []\r\n}}}\r\n\r\nThis should print \"True\", and does so for GHC 8.2.1, and GHC 8.4.1 without -O, but prints \"False\" for GHC 8.4.1 with -O.\r\n\r\nI was unable to reproduce the bug with a single file.","type_of_failure":"OtherFailure","blocking":[]} -->
8.4.2
https://gitlab.haskell.org/ghc/ghc/-/issues/14963
ghci -fdefer-type-errors can't run IO action from another module
2024-02-06T15:36:16Z
elaforge
ghci -fdefer-type-errors can't run IO action from another module
This is enough to trigger a crash on OS X and Linux:
Bug1.hs:
```
module Bug1.hs where
import qualified Bug2
test :: IO Bool
test = Bug2.failure
```
Bug2.hs:
```
module Bug2 where
failure :: IO Bool
failure = return False
```
Shel...
This is enough to trigger a crash on OS X and Linux:
Bug1.hs:
```
module Bug1.hs where
import qualified Bug2
test :: IO Bool
test = Bug2.failure
```
Bug2.hs:
```
module Bug2 where
failure :: IO Bool
failure = return False
```
Shell:
```
% ghci -fdefer-type-errors -ignore-dot-ghci
GHCi, version 8.4.1: http://www.haskell.org/ghc/ :? for help
Prelude> :load Bug
[1 of 2] Compiling Bug2 ( Bug2.hs, interpreted )
[2 of 2] Compiling Bug ( Bug.hs, interpreted )
Ok, two modules loaded.
*Bug> test
ghc: panic! (the 'impossible' happened)
(GHC version 8.4.1 for x86_64-apple-darwin):
nameModule
system $dShow_a1LX
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable
pprPanic, called at compiler/basicTypes/Name.hs:241:3 in ghc:Name
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
This is specific to 8.4.1, in 8.0.2 I get "False" as expected. If I leave off -fdefer-type-errors, it works. It also seems to be ghci only, compiling with -fdefer-type-errors doesn't have the problem.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.1 |
| 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":"ghci -fdefer-type-errors can't run IO action from another module","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This is enough to trigger a crash on OS X and Linux:\r\n\r\nBug1.hs:\r\n{{{\r\nmodule Bug1.hs where\r\nimport qualified Bug2\r\n\r\ntest :: IO Bool\r\ntest = Bug2.failure\r\n}}}\r\n\r\nBug2.hs:\r\n{{{\r\nmodule Bug2 where\r\n\r\nfailure :: IO Bool\r\nfailure = return False\r\n}}}\r\n\r\nShell:\r\n{{{\r\n% ghci -fdefer-type-errors -ignore-dot-ghci\r\nGHCi, version 8.4.1: http://www.haskell.org/ghc/ :? for help\r\nPrelude> :load Bug\r\n[1 of 2] Compiling Bug2 ( Bug2.hs, interpreted )\r\n[2 of 2] Compiling Bug ( Bug.hs, interpreted )\r\nOk, two modules loaded.\r\n*Bug> test\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 8.4.1 for x86_64-apple-darwin):\r\n\tnameModule\r\n system $dShow_a1LX\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/basicTypes/Name.hs:241:3 in ghc:Name\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\nThis is specific to 8.4.1, in 8.0.2 I get \"False\" as expected. If I leave off -fdefer-type-errors, it works. It also seems to be ghci only, compiling with -fdefer-type-errors doesn't have the problem.","type_of_failure":"OtherFailure","blocking":[]} -->
8.4.2
https://gitlab.haskell.org/ghc/ghc/-/issues/14959
Heap overflow in optimizer
2019-07-07T18:14:53Z
darchon
Heap overflow in optimizer
Compiling the following with optimisations:
```
module Test where
import Data.Bits (setBit)
f = foldl setBit 0 [x | (x,_) <- zip [0..] [1]] :: Integer
```
fails with:
```
$ ghc -O0 -fforce-recomp Test.hs
[1 of 1] Compiling Test ...
Compiling the following with optimisations:
```
module Test where
import Data.Bits (setBit)
f = foldl setBit 0 [x | (x,_) <- zip [0..] [1]] :: Integer
```
fails with:
```
$ ghc -O0 -fforce-recomp Test.hs
[1 of 1] Compiling Test ( Test.hs, Test.o )
$ ghc -O -fforce-recomp Test.hs
[1 of 1] Compiling Test ( Test.hs, Test.o )
ghc: panic! (the 'impossible' happened)
(GHC version 8.4.1 for x86_64-unknown-linux):
heap overflow
```
Fails on 8.0.2, 8.2.2, and 8.4.1
<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":"Heep overflow in optimizer","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":"Compiling the following with optimisations:\r\n\r\n{{{\r\nmodule Test where\r\n\r\nimport Data.Bits (setBit)\r\n\r\nf = foldl setBit 0 [x | (x,_) <- zip [0..] [1]] :: Integer\r\n}}}\r\n\r\nfails with:\r\n\r\n{{{\r\n$ ghc -O0 -fforce-recomp Test.hs\r\n[1 of 1] Compiling Test ( Test.hs, Test.o )\r\n$ ghc -O -fforce-recomp Test.hs\r\n[1 of 1] Compiling Test ( Test.hs, Test.o )\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 8.4.1 for x86_64-unknown-linux):\r\n\theap overflow\r\n}}}\r\n\r\nFails on 8.0.2, 8.2.2, and 8.4.1","type_of_failure":"OtherFailure","blocking":[]} -->
8.4.2
https://gitlab.haskell.org/ghc/ghc/-/issues/14947
internal error: Invalid object *c in push()
2019-07-07T18:14:56Z
varosi
internal error: Invalid object *c in push()
Steps to reproduce on Windows 10 x64:
```
stack --version
Version 1.6.5, Git revision 24ab0d6ff07f28276e082c3ce74dfdeb1a2ca9e9 (5514 commits) x86_64 hpack-0.20.0
git clone https://github.com/varosi/cgraytrace.git
cd cgraytrace
git chec...
Steps to reproduce on Windows 10 x64:
```
stack --version
Version 1.6.5, Git revision 24ab0d6ff07f28276e082c3ce74dfdeb1a2ca9e9 (5514 commits) x86_64 hpack-0.20.0
git clone https://github.com/varosi/cgraytrace.git
cd cgraytrace
git checkout 8c9499e4f3b1ba18b71e499667e865bb6db61856
stack build --profile
stack exec --rts-options="-hr" -- cgraytrace-exe
Rendering to sample.png...
cgraytrace-exe.EXE: internal error: Invalid object *c in push()
(GHC version 8.4.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.
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 8.4.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Profiling |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown/Multiple |
| Architecture | x86_64 (amd64) |
</details>
<!-- {"blocked_by":[],"summary":"internal error: Invalid object *c in push()","status":"New","operating_system":"Unknown/Multiple","component":"Profiling","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"x86_64 (amd64)","cc":[""],"type":"Bug","description":"Steps to reproduce on Windows 10 x64:\r\n\r\n\r\n{{{\r\nstack --version\r\nVersion 1.6.5, Git revision 24ab0d6ff07f28276e082c3ce74dfdeb1a2ca9e9 (5514 commits) x86_64 hpack-0.20.0\r\n\r\ngit clone https://github.com/varosi/cgraytrace.git\r\ncd cgraytrace\r\ngit checkout 8c9499e4f3b1ba18b71e499667e865bb6db61856\r\nstack build --profile\r\nstack exec --rts-options=\"-hr\" -- cgraytrace-exe\r\n\r\nRendering to sample.png...\r\ncgraytrace-exe.EXE: internal error: Invalid object *c in push()\r\n (GHC version 8.4.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","type_of_failure":"OtherFailure","blocking":[]} -->
8.4.2
https://gitlab.haskell.org/ghc/ghc/-/issues/14936
GHC 8.4 performance regressions when using newtypes
2019-07-07T18:14:58Z
danilo2
GHC 8.4 performance regressions when using newtypes
Here is some serious performance regression in the following code:
```hs
{-# LANGUAGE BangPatterns #-}
{-# LANGUAGE ScopedTypeVariables #-}
{-# LANGUAGE FlexibleContexts #-}
module Main where
import Prelude
import qualified Foreign.St...
Here is some serious performance regression in the following code:
```hs
{-# LANGUAGE BangPatterns #-}
{-# LANGUAGE ScopedTypeVariables #-}
{-# LANGUAGE FlexibleContexts #-}
module Main where
import Prelude
import qualified Foreign.Storable as Storable
import qualified Control.Monad.State.Strict as S
import Control.Monad.IO.Class
import Foreign.Marshal.Alloc (mallocBytes)
import Criterion.Main
newtype Foo a = Foo a
intSize :: Int
intSize = Storable.sizeOf (undefined :: Int)
slow :: Int -> IO ()
slow i = do
ptr <- mallocBytes $ 2 * intSize
Storable.pokeByteOff ptr intSize (0 :: Int)
let go 0 = pure ()
go j = do
Foo (!_, !off) <- S.get
!(x :: Int) <- liftIO $ Storable.peekByteOff ptr off
liftIO $ Storable.pokeByteOff ptr off $! (x + 1)
go (j - 1)
S.evalStateT (go i) (Foo ((0::Int),(intSize::Int)))
fast :: Int -> IO ()
fast i = do
ptr <- mallocBytes $ 2 * intSize
Storable.pokeByteOff ptr intSize (0 :: Int)
let go 0 = pure ()
go j = do
(!_, !off) <- S.get
!(x :: Int) <- liftIO $ Storable.peekByteOff ptr off
liftIO $ Storable.pokeByteOff ptr off $! (x + 1)
go (j - 1)
S.evalStateT (go i) ((0::Int),(intSize::Int))
main :: IO ()
main = defaultMain
[ bgroup "slow"
$ (\(i :: Int) -> bench ("10e" <> show i)
$ perRunEnv (return ())
$ \v -> slow (10 ^ i)) <$> [7..8]
, bgroup "fast"
$ (\(i :: Int) -> bench ("10e" <> show i)
$ perRunEnv (return ())
$ \v -> fast (10 ^ i)) <$> [7..8]
]
```
Compiled with flags:
`-threaded -funbox-strict-fields -O2 -fconstraint-solver-iterations=100 -fexcess-precision -fexpose-all-unfoldings -flate-dmd-anal -fspec-constr-keen -fspecialise-aggressively -fstatic-argument-transformation -fmax-worker-args=200`
The `slow` function executes 2 times slower than the `fast` one. The only difference is that the state is wrapped in a newtype. It was working properly in GHC 8.2 (both functions were equally fast - as fast as the current `fast` function).
8.4.2
https://gitlab.haskell.org/ghc/ghc/-/issues/14934
Repeated "impossible" go_axiom_rule error.
2021-04-08T13:45:22Z
Galen Huntington
Repeated "impossible" go_axiom_rule error.
I am getting the following error repeatedly:
```
ghc: panic! (the 'impossible' happened)
(GHC version 8.4.1 for x86_64-unknown-linux):
go_axiom_rule
Sub0R
Call stack:
CallStack (from HasCallStack):
callStackDoc, cal...
I am getting the following error repeatedly:
```
ghc: panic! (the 'impossible' happened)
(GHC version 8.4.1 for x86_64-unknown-linux):
go_axiom_rule
Sub0R
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable
pprPanic, called at compiler/iface/TcIface.hs:1371:15 in ghc:TcIface
```
I got it on 8.2.1, and tried upgrading to 8.4.1 to see if it went away, but it did not.
It occurs frequently when I do a `--make` and recompile a subset of modules. I can avoid it by force-recompiling all modules, although of course this is inefficient.
Since I'm working with a codebase of thousands of lines and don't understand ghc's innards, I'm not sure where to start looking for the cause, to produce a minimal failing example. But it did start happening around the time I expanded my use of this module:
https://github.com/agrafix/superrecord
Since there are unsafe operations in there, it is possible it is doing something illicit, but it is hard to see how it would cause this.
<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":"Repeated \"impossible\" go_axiom_rule error.","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":"I am getting the following error repeatedly:\r\n\r\n{{{\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 8.4.1 for x86_64-unknown-linux):\r\n\tgo_axiom_rule\r\n Sub0R\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/iface/TcIface.hs:1371:15 in ghc:TcIface\r\n}}}\r\n\r\nI got it on 8.2.1, and tried upgrading to 8.4.1 to see if it went away, but it did not.\r\n\r\nIt occurs frequently when I do a `--make` and recompile a subset of modules. I can avoid it by force-recompiling all modules, although of course this is inefficient.\r\n\r\nSince I'm working with a codebase of thousands of lines and don't understand ghc's innards, I'm not sure where to start looking for the cause, to produce a minimal failing example. But it did start happening around the time I expanded my use of this module:\r\n\r\nhttps://github.com/agrafix/superrecord\r\n\r\nSince there are unsafe operations in there, it is possible it is doing something illicit, but it is hard to see how it would cause this.","type_of_failure":"OtherFailure","blocking":[]} -->
8.4.2
https://gitlab.haskell.org/ghc/ghc/-/issues/14933
DeriveAnyClass can cause "No skolem info" GHC panic
2019-07-07T18:14:59Z
Ryan Scott
DeriveAnyClass can cause "No skolem info" GHC panic
This program panics:
```hs
{-# LANGUAGE DefaultSignatures #-}
{-# LANGUAGE DeriveAnyClass #-}
{-# LANGUAGE DeriveGeneric #-}
{-# LANGUAGE DerivingStrategies #-}
{-# LANGUAGE FlexibleContexts ...
This program panics:
```hs
{-# LANGUAGE DefaultSignatures #-}
{-# LANGUAGE DeriveAnyClass #-}
{-# LANGUAGE DeriveGeneric #-}
{-# LANGUAGE DerivingStrategies #-}
{-# LANGUAGE FlexibleContexts #-}
{-# LANGUAGE GeneralizedNewtypeDeriving #-}
{-# LANGUAGE RankNTypes #-}
{-# LANGUAGE ScopedTypeVariables #-}
{-# LANGUAGE TypeFamilies #-}
module Bug where
import Control.Concurrent (ThreadId)
import Control.Monad.Reader
class Wrapped s where
type Unwrapped s :: *
_Wrapped' :: Iso' s (Unwrapped s)
type Iso' s a = forall f. Functor f => (a -> f a) -> s -> f s
class Fork m where
fork :: x -> m () -> m ThreadId
default fork :: ( Wrapped (m ())
, Unwrapped (m ()) ~ t ()
, Fork t
, Wrapped (m ThreadId)
, Unwrapped (m ThreadId) ~ t ThreadId
) => x -> m () -> m ThreadId
fork = undefined -- view _Unwrapped' . fork . view _Wrapped'
instance Fork m => Fork (ReaderT e m) where
fork x action = ReaderT $ \env -> fork x (runReaderT action env)
data Env
newtype MyThing m a = MyThing { unMyThing :: ReaderT Env m a }
deriving newtype (Functor, Applicative, Monad)
deriving anyclass (Fork)
instance Wrapped (MyThing m a) where
type Unwrapped (MyThing m a) = ReaderT Env m a
_Wrapped' = undefined -- iso unMyThing MyThing
```
```
[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
Bug.hs:39:24: error:ghc: panic! (the 'impossible' happened)
(GHC version 8.2.2 for x86_64-unknown-linux):
No skolem info:
m_a1Hs[sk:2]
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
```
(Program adapted from [here](https://github.com/ekmett/lens/issues/793#issuecomment-369597846).)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.2.2 |
| Type | Bug |
| 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":"DeriveAnyClass can cause \"No skolem info\" GHC panic","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":["deriving"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This program panics:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE DefaultSignatures #-}\r\n{-# LANGUAGE DeriveAnyClass #-}\r\n{-# LANGUAGE DeriveGeneric #-}\r\n{-# LANGUAGE DerivingStrategies #-}\r\n{-# LANGUAGE FlexibleContexts #-}\r\n{-# LANGUAGE GeneralizedNewtypeDeriving #-}\r\n{-# LANGUAGE RankNTypes #-}\r\n{-# LANGUAGE ScopedTypeVariables #-}\r\n{-# LANGUAGE TypeFamilies #-}\r\nmodule Bug where\r\n\r\nimport Control.Concurrent (ThreadId)\r\nimport Control.Monad.Reader\r\n\r\nclass Wrapped s where\r\n type Unwrapped s :: *\r\n _Wrapped' :: Iso' s (Unwrapped s)\r\n\r\ntype Iso' s a = forall f. Functor f => (a -> f a) -> s -> f s\r\n\r\nclass Fork m where\r\n fork :: x -> m () -> m ThreadId\r\n\r\n default fork :: ( Wrapped (m ())\r\n , Unwrapped (m ()) ~ t ()\r\n , Fork t\r\n , Wrapped (m ThreadId)\r\n , Unwrapped (m ThreadId) ~ t ThreadId\r\n ) => x -> m () -> m ThreadId\r\n fork = undefined -- view _Unwrapped' . fork . view _Wrapped'\r\n\r\ninstance Fork m => Fork (ReaderT e m) where\r\n fork x action = ReaderT $ \\env -> fork x (runReaderT action env)\r\n\r\ndata Env\r\n\r\nnewtype MyThing m a = MyThing { unMyThing :: ReaderT Env m a }\r\n deriving newtype (Functor, Applicative, Monad)\r\n deriving anyclass (Fork)\r\n\r\ninstance Wrapped (MyThing m a) where\r\n type Unwrapped (MyThing m a) = ReaderT Env m a\r\n _Wrapped' = undefined -- iso unMyThing MyThing\r\n}}}\r\n\r\n{{{\r\n[1 of 1] Compiling Bug ( Bug.hs, Bug.o )\r\n\r\nBug.hs:39:24: error:ghc: panic! (the 'impossible' happened)\r\n (GHC version 8.2.2 for x86_64-unknown-linux):\r\n No skolem info:\r\n m_a1Hs[sk:2]\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\n\r\n(Program adapted from [https://github.com/ekmett/lens/issues/793#issuecomment-369597846 here].)","type_of_failure":"OtherFailure","blocking":[]} -->
8.4.2
https://gitlab.haskell.org/ghc/ghc/-/issues/14932
DeriveAnyClass produces unjustifiably untouchable unification variables
2021-12-14T14:30:30Z
Ryan Scott
DeriveAnyClass produces unjustifiably untouchable unification variables
The following code (courtesy of kosmikus) should typecheck, but does not:
```hs
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE DeriveAnyClass #-}
{-# LANGUAGE DefaultSignatures #-}
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE TypeOperators #-}
m...
The following code (courtesy of kosmikus) should typecheck, but does not:
```hs
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE DeriveAnyClass #-}
{-# LANGUAGE DefaultSignatures #-}
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE TypeOperators #-}
module Zero where
import GHC.Exts
class Zero a where
zero :: a
default zero :: (Code a ~ '[xs], All Zero xs) => a
zero = undefined
type family All c xs :: Constraint where
All c '[] = ()
All c (x : xs) = (c x, All c xs)
type family Code (a :: *) :: [[*]]
type instance Code B1 = '[ '[ ] ]
data B1 = B1
deriving Zero
```
This produces the following error:
```
GHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /nfs/nfs7/home/rgscott/.ghci
[1 of 1] Compiling Zero ( Bug.hs, interpreted )
Bug.hs:23:11: error:
• Couldn't match type ‘xs0’ with ‘'[]’
arising from the 'deriving' clause of a data type declaration
‘xs0’ is untouchable
inside the constraints: All Zero xs0
bound by the deriving clause for ‘Zero B1’
at Bug.hs:23:11-14
• When deriving the instance for (Zero B1)
|
23 | deriving Zero
| ^^^^
```
This error is baffling, however, because `xs0` should be a unification variable that readily unifies with `'[]`! As evidence, this typechecks:
```
instance Zero B1
```
But the equivalent `deriving` clause does not.
I know what is going on here after some sleuthing: `DeriveAnyClass` (specifically, `inferConstraintsDAC`) is producing unification variables whose TcLevel is always bumped to three. However, in the program above, we will not form an implication constraints around those unification variables, since `zero` has no locally quantified type variables or given constraints. Thus, `simplifyDeriv` will try to simplify unification variables with TcLevel 3 at the top level, which results in them being untouchable. Blegh.
This was partially noticed in #13272, when we were failing to bump unification variables that //did// appear inside implication constraints. However, we overlooked this one corner case, which kosmikus happened to stumble upon in a `generics-sop` [example](https://stackoverflow.com/a/49335338/1482749).
Patch incoming.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.4.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | #13272 |
| Blocking | |
| CC | kosmikus |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"DeriveAnyClass produces unjustifiably untouchable unification variables","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[13272],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.1","keywords":["deriving"],"differentials":[],"test_case":"","architecture":"","cc":["kosmikus"],"type":"Bug","description":"The following code (courtesy of kosmikus) should typecheck, but does not:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE DataKinds #-}\r\n{-# LANGUAGE DeriveAnyClass #-}\r\n{-# LANGUAGE DefaultSignatures #-}\r\n{-# LANGUAGE TypeFamilies #-}\r\n{-# LANGUAGE TypeOperators #-}\r\nmodule Zero where\r\n\r\nimport GHC.Exts\r\n\r\nclass Zero a where\r\n zero :: a\r\n default zero :: (Code a ~ '[xs], All Zero xs) => a\r\n zero = undefined\r\n\r\ntype family All c xs :: Constraint where\r\n All c '[] = ()\r\n All c (x : xs) = (c x, All c xs)\r\n\r\ntype family Code (a :: *) :: [[*]]\r\ntype instance Code B1 = '[ '[ ] ]\r\n\r\ndata B1 = B1\r\n deriving Zero\r\n}}}\r\n\r\nThis produces the following error:\r\n\r\n{{{\r\nGHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help\r\nLoaded GHCi configuration from /nfs/nfs7/home/rgscott/.ghci\r\n[1 of 1] Compiling Zero ( Bug.hs, interpreted )\r\n\r\nBug.hs:23:11: error:\r\n • Couldn't match type ‘xs0’ with ‘'[]’\r\n arising from the 'deriving' clause of a data type declaration\r\n ‘xs0’ is untouchable\r\n inside the constraints: All Zero xs0\r\n bound by the deriving clause for ‘Zero B1’\r\n at Bug.hs:23:11-14\r\n • When deriving the instance for (Zero B1)\r\n |\r\n23 | deriving Zero\r\n | ^^^^\r\n}}}\r\n\r\nThis error is baffling, however, because `xs0` should be a unification variable that readily unifies with `'[]`! As evidence, this typechecks:\r\n\r\n{{{\r\ninstance Zero B1\r\n}}}\r\n\r\nBut the equivalent `deriving` clause does not.\r\n\r\nI know what is going on here after some sleuthing: `DeriveAnyClass` (specifically, `inferConstraintsDAC`) is producing unification variables whose TcLevel is always bumped to three. However, in the program above, we will not form an implication constraints around those unification variables, since `zero` has no locally quantified type variables or given constraints. Thus, `simplifyDeriv` will try to simplify unification variables with TcLevel 3 at the top level, which results in them being untouchable. Blegh.\r\n\r\nThis was partially noticed in #13272, when we were failing to bump unification variables that //did// appear inside implication constraints. However, we overlooked this one corner case, which kosmikus happened to stumble upon in a `generics-sop` [https://stackoverflow.com/a/49335338/1482749 example].\r\n\r\nPatch incoming.","type_of_failure":"OtherFailure","blocking":[]} -->
8.4.2
https://gitlab.haskell.org/ghc/ghc/-/issues/14931
Segfault compiling file that uses Template Haskell with -prof
2019-07-07T18:14:59Z
Ryan Scott
Segfault compiling file that uses Template Haskell with -prof
Originally noticed [here](https://github.com/llvm-hs/llvm-hs/issues/86#issuecomment-373710312). Take the following two files:
```hs
{-# LANGUAGE FlexibleInstances #-}
{-# LANGUAGE ...
Originally noticed [here](https://github.com/llvm-hs/llvm-hs/issues/86#issuecomment-373710312). Take the following two files:
```hs
{-# LANGUAGE FlexibleInstances #-}
{-# LANGUAGE FunctionalDependencies #-}
{-# LANGUAGE MultiParamTypeClasses #-}
{-# LANGUAGE UndecidableInstances #-}
module State (MonadState(..), Lazy.evalState) where
import qualified Control.Monad.Trans.State.Lazy as Lazy (StateT, get, put, evalState)
class Monad m => MonadState s m | m -> s where
get :: m s
put :: s -> m ()
instance Monad m => MonadState s (Lazy.StateT s m) where
get = Lazy.get
put = Lazy.put
```
```hs
{-# LANGUAGE FlexibleContexts #-}
{-# LANGUAGE TemplateHaskell #-}
module Bug where
import Prelude (Int, IO, Bool(..), Num(..), Monad(..), not, print)
import qualified Language.Haskell.TH.Syntax as TH
import State
wat :: IO ()
wat = print $(let playGame [] = do
(_, score) <- get
return score
playGame (x:xs) = do
(on, score) <- get
case x of
'a' | on -> put (on, score + 1)
'b' | on -> put (on, score - 1)
'c' -> put (not on, score)
_ -> put (on, score)
playGame xs
startState :: (Bool, Int)
startState = (False, 0)
in TH.lift (evalState (playGame "abcaaacbbcabbab") startState) )
```
Compiling them like so leads to a segfault:
```
$ ~/Software/ghc-8.4.1/bin/ghc -c -O -static -dynamic-too -dynosuf dyn_o -dynhisuf dyn_hi State.hs
$ ~/Software/ghc-8.4.1/bin/ghc -c -O -prof -osuf p_o -hisuf p_hi State.hs -fprof-auto
$ ~/Software/ghc-8.4.1/bin/ghc -c -O -prof -osuf p_o -hisuf p_hi Bug.hs
Segmentation fault (core dumped)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Profiling |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Segfault compiling files with -fprof-all","status":"New","operating_system":"","component":"Profiling","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Originally noticed [https://github.com/llvm-hs/llvm-hs/issues/86#issuecomment-373710312 here]. Take the following two files:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE FlexibleInstances #-} \r\n{-# LANGUAGE FunctionalDependencies #-}\r\n{-# LANGUAGE MultiParamTypeClasses #-}\r\n{-# LANGUAGE UndecidableInstances #-}\r\nmodule State (MonadState(..), Lazy.evalState) where\r\n\r\nimport qualified Control.Monad.Trans.State.Lazy as Lazy (StateT, get, put, evalState)\r\n\r\nclass Monad m => MonadState s m | m -> s where\r\n get :: m s\r\n put :: s -> m ()\r\n\r\ninstance Monad m => MonadState s (Lazy.StateT s m) where\r\n get = Lazy.get\r\n put = Lazy.put\r\n}}}\r\n{{{#!hs\r\n{-# LANGUAGE FlexibleContexts #-}\r\n{-# LANGUAGE TemplateHaskell #-}\r\nmodule Bug where\r\n\r\nimport Prelude (Int, IO, Bool(..), Num(..), Monad(..), not, print)\r\nimport qualified Language.Haskell.TH.Syntax as TH\r\nimport State\r\n\r\nwat :: IO ()\r\nwat = print $(let playGame [] = do\r\n (_, score) <- get\r\n return score\r\n playGame (x:xs) = do\r\n (on, score) <- get\r\n case x of\r\n 'a' | on -> put (on, score + 1)\r\n 'b' | on -> put (on, score - 1)\r\n 'c' -> put (not on, score)\r\n _ -> put (on, score)\r\n playGame xs\r\n\r\n startState :: (Bool, Int)\r\n startState = (False, 0)\r\n in TH.lift (evalState (playGame \"abcaaacbbcabbab\") startState) )\r\n}}}\r\n\r\nCompiling them like so leads to a segfault:\r\n\r\n{{{\r\n$ ~/Software/ghc-8.4.1/bin/ghc -c -O -static -dynamic-too -dynosuf dyn_o -dynhisuf dyn_hi State.hs\r\n$ ~/Software/ghc-8.4.1/bin/ghc -c -O -prof -osuf p_o -hisuf p_hi State.hs -fprof-auto\r\n$ ~/Software/ghc-8.4.1/bin/ghc -c -O -prof -osuf p_o -hisuf p_hi Bug.hs\r\nSegmentation fault (core dumped)\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->
8.4.2
https://gitlab.haskell.org/ghc/ghc/-/issues/14925
Non-ASCII type names get garbled when their `TypeRep` is shown
2019-07-07T18:15:01Z
leftaroundabout
Non-ASCII type names get garbled when their `TypeRep` is shown
[Typeable](http://hackage.haskell.org/package/base-4.10.1.0/docs/Data-Typeable.html) allows easily showing the name of a type by, well, using `show` on it. However, this does not work right for types with Unicode symbols in their name:
...
[Typeable](http://hackage.haskell.org/package/base-4.10.1.0/docs/Data-Typeable.html) allows easily showing the name of a type by, well, using `show` on it. However, this does not work right for types with Unicode symbols in their name:
```
GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help
Prelude> :m +Data.Typeable
Prelude Data.Typeable> data W = W
Prelude Data.Typeable> typeOf W
W
Prelude Data.Typeable> data Ω = Ω
Prelude Data.Typeable> typeOf Ω
Ω
```
This did not yet happen in GHC-7:
```
GHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help
Prelude> :m +Data.Typeable
Prelude Data.Typeable> data W = W
Prelude Data.Typeable> typeOf W
W
Prelude Data.Typeable> data Ω = Ω
Prelude Data.Typeable> typeOf Ω
Ω
```
N.b.:
```
Prelude> import Data.ByteString.Char8 as BC8
Prelude BC8> BC8.putStrLn $ pack "Ω"
Ω
```
So, this appears to be a UTF-8 problem – something interprets bytestring-stored type-representation names as a different character encoding.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.2.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Non-ASCII type names get garbled when their `TypeRep` is shown","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1","keywords":["ASCII","TypeRep","Typeable","UTF-8","Unicode"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"[http://hackage.haskell.org/package/base-4.10.1.0/docs/Data-Typeable.html Typeable] allows easily showing the name of a type by, well, using `show` on it. However, this does not work right for types with Unicode symbols in their name:\r\n{{{\r\nGHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help\r\nPrelude> :m +Data.Typeable\r\nPrelude Data.Typeable> data W = W\r\nPrelude Data.Typeable> typeOf W\r\nW\r\nPrelude Data.Typeable> data Ω = Ω\r\nPrelude Data.Typeable> typeOf Ω\r\nΩ\r\n}}}\r\nThis did not yet happen in GHC-7:\r\n{{{\r\nGHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help\r\nPrelude> :m +Data.Typeable\r\nPrelude Data.Typeable> data W = W\r\nPrelude Data.Typeable> typeOf W\r\nW\r\nPrelude Data.Typeable> data Ω = Ω\r\nPrelude Data.Typeable> typeOf Ω\r\nΩ\r\n}}}\r\nN.b.:\r\n{{{\r\nPrelude> import Data.ByteString.Char8 as BC8\r\nPrelude BC8> BC8.putStrLn $ pack \"Ω\"\r\nΩ\r\n}}}\r\nSo, this appears to be a UTF-8 problem – something interprets bytestring-stored type-representation names as a different character encoding.","type_of_failure":"OtherFailure","blocking":[]} -->
8.4.2
https://gitlab.haskell.org/ghc/ghc/-/issues/14918
GHC 8.4.1 regression: derived Read instances with field names containing # no...
2019-07-07T18:15:03Z
Ryan Scott
GHC 8.4.1 regression: derived Read instances with field names containing # no longer parse
(Originally noticed [here](https://github.com/ekmett/transformers-compat/issues/32).)
Consider the following program:
```hs
{-# LANGUAGE MagicHash #-}
module Bug where
data T a = MkT { runT# :: a }
deriving (Read, Show)
t1, t2 :: T...
(Originally noticed [here](https://github.com/ekmett/transformers-compat/issues/32).)
Consider the following program:
```hs
{-# LANGUAGE MagicHash #-}
module Bug where
data T a = MkT { runT# :: a }
deriving (Read, Show)
t1, t2 :: T Int
t1 = MkT 1
t2 = read $ show t1
main :: IO ()
main = print t2
```
In GHC 8.2.1, this runs without issue:
```
$ /opt/ghc/8.2.2/bin/runghc Bug.hs
MkT {runT# = 1}
```
In GHC 8.4.1, however, this produces a runtime error:
```
$ ~/Software/ghc-8.4.1/bin/runghc Bug.hs
Bug.hs: Prelude.read: no parse
```
8.4.2
https://gitlab.haskell.org/ghc/ghc/-/issues/14916
Missing checks when deriving special classes
2022-02-16T12:06:47Z
Andres Löh
Missing checks when deriving special classes
For the following program
```hs
{-# LANGUAGE DeriveAnyClass #-}
module T where
import Data.Coerce
import Data.Typeable
data A = MkA deriving ((~) A)
data B = MkB deriving (Coercible B)
```
the deriving clause for `A` is accepted with...
For the following program
```hs
{-# LANGUAGE DeriveAnyClass #-}
module T where
import Data.Coerce
import Data.Typeable
data A = MkA deriving ((~) A)
data B = MkB deriving (Coercible B)
```
the deriving clause for `A` is accepted without complaints, and the
deriving clause for `B` fails with the following error:
```
T.hs:8:24: error:
Top-level bindings for unlifted types aren't allowed:
|
8 | data B = MkB deriving (Coercible B)
| ^^^^^^^^^^^
```
Corresponding standalone deriving instances trigger errors
saying "Manual instances of this class are not permitted".
Probably similar error messages should be triggered here.
8.4.2
https://gitlab.haskell.org/ghc/ghc/-/issues/14906
Release notes have wrong version of base package
2019-07-07T18:15:06Z
Ben Gamari
Release notes have wrong version of base package
The library version table introduced in the release notes in e4dc2cd51902a8cd83476f861cf52996e5adf157 claims that GHC 8.4.1 includes `base-2.1`. See https://downloads.haskell.org/\~ghc/8.4.1/docs/html/users_guide/8.4.1-notes.html\#includ...
The library version table introduced in the release notes in e4dc2cd51902a8cd83476f861cf52996e5adf157 claims that GHC 8.4.1 includes `base-2.1`. See https://downloads.haskell.org/\~ghc/8.4.1/docs/html/users_guide/8.4.1-notes.html\#included-libraries.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 8.4.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Documentation |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Release notes have wrong version of base package","status":"New","operating_system":"","component":"Documentation","related":[],"milestone":"8.4.2","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The library version table introduced in the release notes in e4dc2cd51902a8cd83476f861cf52996e5adf157 claims that GHC 8.4.1 includes `base-2.1`. See https://downloads.haskell.org/~ghc/8.4.1/docs/html/users_guide/8.4.1-notes.html#included-libraries.","type_of_failure":"OtherFailure","blocking":[]} -->
8.4.2
https://gitlab.haskell.org/ghc/ghc/-/issues/14905
GHCi segfaults with +RTS -Di after hitting a breakpoint
2019-07-07T18:15:06Z
Ömer Sinan Ağacan
GHCi segfaults with +RTS -Di after hitting a breakpoint
Steps to reproduce:
- Compile stage2 with `-debug`
- Run GHCi with `+RTS -Di`
- Load an interpreted module with a definition, set a breakpoint on the definition
- Evaluate the definition
GHCi crashes with a segfault. Backtrace:
```
#0...
Steps to reproduce:
- Compile stage2 with `-debug`
- Run GHCi with `+RTS -Di`
- Load an interpreted module with a definition, set a breakpoint on the definition
- Evaluate the definition
GHCi crashes with a segfault. Backtrace:
```
#0 0x00007ffff18bcaa9 in disInstr (bco=0x4200013f30, pc=1) at rts/Disassembler.c:71
#1 0x00007ffff18c89e9 in interpretBCO (cap=0x7ffff19431c0 <MainCapability>) at rts/Interpreter.c:986
#2 0x00007ffff18d19fe in schedule (initialCapability=0x7ffff19431c0 <MainCapability>, task=0x7fffe0000910) at rts/Schedule.c:471
#3 0x00007ffff18d4ee2 in scheduleWorker (cap=0x7ffff19431c0 <MainCapability>, task=0x7fffe0000910) at rts/Schedule.c:2553
#4 0x00007ffff18ccab8 in workerStart (task=0x7fffe0000910) at rts/Task.c:444
#5 0x00007ffff0c3c6ba in start_thread (arg=0x7fffee9aa700) at pthread_create.c:333
#6 0x00007ffff06f241d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
```
in this line:
```
71 debugBelch(" %s\n", ((CostCentre*)(literals[instrs[pc+3]]))->label);
```
`literals[instrs[pc+3]]` is null.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.5 |
| 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":"GHCi segfaults with +RTS -Di after hitting a breakpoint","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.5","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Steps to reproduce:\r\n\r\n- Compile stage2 with `-debug`\r\n- Run GHCi with `+RTS -Di`\r\n- Load an interpreted module with a definition, set a breakpoint on the definition\r\n- Evaluate the definition\r\n\r\nGHCi crashes with a segfault. Backtrace:\r\n\r\n{{{\r\n#0 0x00007ffff18bcaa9 in disInstr (bco=0x4200013f30, pc=1) at rts/Disassembler.c:71\r\n#1 0x00007ffff18c89e9 in interpretBCO (cap=0x7ffff19431c0 <MainCapability>) at rts/Interpreter.c:986\r\n#2 0x00007ffff18d19fe in schedule (initialCapability=0x7ffff19431c0 <MainCapability>, task=0x7fffe0000910) at rts/Schedule.c:471\r\n#3 0x00007ffff18d4ee2 in scheduleWorker (cap=0x7ffff19431c0 <MainCapability>, task=0x7fffe0000910) at rts/Schedule.c:2553\r\n#4 0x00007ffff18ccab8 in workerStart (task=0x7fffe0000910) at rts/Task.c:444\r\n#5 0x00007ffff0c3c6ba in start_thread (arg=0x7fffee9aa700) at pthread_create.c:333\r\n#6 0x00007ffff06f241d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109\r\n}}}\r\n\r\nin this line:\r\n\r\n{{{\r\n71 debugBelch(\" %s\\n\", ((CostCentre*)(literals[instrs[pc+3]]))->label);\r\n}}}\r\n\r\n`literals[instrs[pc+3]]` is null.","type_of_failure":"OtherFailure","blocking":[]} -->
8.4.2