GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:14:41Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/15013Building nofib using llvm and HEAD fails2019-07-07T18:14:41ZAndreas KlebingerBuilding nofib using llvm and HEAD fails```
== make all ;
in /home/Andi/ghc_head/nofib/shootout/pidigits
------------------------------------------------------------------------
HC = /home/Andi/ghc_head/inplace/bin/ghc-stage2
HC_OPTS = -O2 -Rghc-timing -H32m -hisuf hi -fllvm ...```
== make all ;
in /home/Andi/ghc_head/nofib/shootout/pidigits
------------------------------------------------------------------------
HC = /home/Andi/ghc_head/inplace/bin/ghc-stage2
HC_OPTS = -O2 -Rghc-timing -H32m -hisuf hi -fllvm -rtsopts -O2
RUNTEST_OPTS = -ghc-timing
==nofib== pidigits: time to compile Main follows...
/home/Andi/ghc_head/inplace/bin/ghc-stage2 -O2 -Rghc-timing -H32m -hisuf hi -fllvm -rtsopts -O2 -c Main.hs -o Main.o
ghc-stage2.exe: panic! (the 'impossible' happened)
(GHC version 8.5.20180401 for x86_64-unknown-mingw32):
Each block should be reachable from only one ProcPoint
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
<<ghc: 506688344 bytes, 156 GCs, 7738569/16639872 avg/max bytes residency (5 samples), 37M in use, 0.000 INIT (0.000 elapsed), 0.344 MUT (0.333 elapsed), 0.062 GC (0.112 elapsed) :ghc>>
make[1]: *** [../../mk/suffix.mk:23: Main.o] Error 1
Failed making all in pidigits: 1
make: *** [../mk/ghc-recurse.mk:69: all] Error 1
$ opt --version
LLVM (http://llvm.org/):
LLVM version 5.0.1
Optimized build.
Default target: x86_64-w64-windows-gnu
Host CPU: skylake
```
This is on commit 8b823f270e53627ddca1a993c05f1ab556742d96
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | --------------- |
| Version | |
| 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":"Building nofib using llvm and HEAD fails","status":"New","operating_system":"","component":"Compiler (LLVM)","related":[],"milestone":"8.4.2","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"\r\n{{{\r\n== make all ;\r\n in /home/Andi/ghc_head/nofib/shootout/pidigits\r\n------------------------------------------------------------------------\r\nHC = /home/Andi/ghc_head/inplace/bin/ghc-stage2\r\nHC_OPTS = -O2 -Rghc-timing -H32m -hisuf hi -fllvm -rtsopts -O2\r\nRUNTEST_OPTS = -ghc-timing\r\n==nofib== pidigits: time to compile Main follows...\r\n/home/Andi/ghc_head/inplace/bin/ghc-stage2 -O2 -Rghc-timing -H32m -hisuf hi -fllvm -rtsopts -O2 -c Main.hs -o Main.o\r\nghc-stage2.exe: panic! (the 'impossible' happened)\r\n (GHC version 8.5.20180401 for x86_64-unknown-mingw32):\r\n Each block should be reachable from only one ProcPoint\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\n<<ghc: 506688344 bytes, 156 GCs, 7738569/16639872 avg/max bytes residency (5 samples), 37M in use, 0.000 INIT (0.000 elapsed), 0.344 MUT (0.333 elapsed), 0.062 GC (0.112 elapsed) :ghc>>\r\nmake[1]: *** [../../mk/suffix.mk:23: Main.o] Error 1\r\nFailed making all in pidigits: 1\r\nmake: *** [../mk/ghc-recurse.mk:69: all] Error 1\r\n\r\n$ opt --version\r\nLLVM (http://llvm.org/):\r\n LLVM version 5.0.1\r\n Optimized build.\r\n Default target: x86_64-w64-windows-gnu\r\n Host CPU: skylake\r\n\r\n}}}\r\n\r\nThis is on commit 8b823f270e53627ddca1a993c05f1ab556742d96\r\n","type_of_failure":"OtherFailure","blocking":[]} -->⊥https://gitlab.haskell.org/ghc/ghc/-/issues/13233typePrimRep panic while compiling GHC with profiling2021-10-06T08:42:31ZBen GamaritypePrimRep panic while compiling GHC with profilingI am seeing this panic while compiling GHC stage2,
```
ghc-stage1: panic! (the 'impossible' happened)
(GHC version 8.1.20170124 for x86_64-unknown-linux):
runtimeRepPrimRep
typePrimRep (a :: TYPE k0)
k0
Call stack:
?callS...I am seeing this panic while compiling GHC stage2,
```
ghc-stage1: panic! (the 'impossible' happened)
(GHC version 8.1.20170124 for x86_64-unknown-linux):
runtimeRepPrimRep
typePrimRep (a :: TYPE k0)
k0
Call stack:
?callStack, called at compiler/utils/Util.hs:1352:50 in ghc:Util
prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1166:58 in ghc:Outputable
callStackDoc, called at compiler/utils/Outputable.hs:1170:37 in ghc:Outputable
pprPanic, called at compiler/simplStg/RepType.hs:360:5 in ghc:RepType
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
<<ghc: 1038844096 bytes, 158 GCs, 21564561/73278928 avg/max bytes residency (8 samples), 148M in use, 0.000 INIT (0.000 elapsed), 1.113 MUT (1.125 elapsed), 0.935 GC (0.940 elapsed) :ghc>>
compiler/ghc.mk:582: recipe for target 'compiler/stage2/build/StgCmmMonad.p_o' failed
```
This appears to be due to my enabling of profiling. `build.mk` contains,
```
BuildFlavour=prof
ifneq "$(BuildFlavour)" ""
include mk/flavours/$(BuildFlavour).mk
endif
HADDOCK_DOCS=YES
compiler_HC_OPTS += -fprof-auto-exported
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | goldfire |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"typePrimRep panic while compiling GHC with profiling","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.2.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["goldfire"],"type":"Bug","description":"I am seeing this panic while compiling GHC stage2,\r\n{{{\r\nghc-stage1: panic! (the 'impossible' happened)\r\n (GHC version 8.1.20170124 for x86_64-unknown-linux):\r\n\truntimeRepPrimRep\r\n typePrimRep (a :: TYPE k0)\r\n k0\r\n Call stack:\r\n ?callStack, called at compiler/utils/Util.hs:1352:50 in ghc:Util\r\n prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1166:58 in ghc:Outputable\r\n callStackDoc, called at compiler/utils/Outputable.hs:1170:37 in ghc:Outputable\r\n pprPanic, called at compiler/simplStg/RepType.hs:360:5 in ghc:RepType\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\n<<ghc: 1038844096 bytes, 158 GCs, 21564561/73278928 avg/max bytes residency (8 samples), 148M in use, 0.000 INIT (0.000 elapsed), 1.113 MUT (1.125 elapsed), 0.935 GC (0.940 elapsed) :ghc>>\r\ncompiler/ghc.mk:582: recipe for target 'compiler/stage2/build/StgCmmMonad.p_o' failed\r\n}}}\r\n\r\nThis appears to be due to my enabling of profiling. `build.mk` contains,\r\n{{{\r\nBuildFlavour=prof\r\nifneq \"$(BuildFlavour)\" \"\"\r\ninclude mk/flavours/$(BuildFlavour).mk\r\nendif\r\nHADDOCK_DOCS=YES\r\ncompiler_HC_OPTS += -fprof-auto-exported\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->⊥sheafsam.derbyshire@gmail.comsheafsam.derbyshire@gmail.comhttps://gitlab.haskell.org/ghc/ghc/-/issues/9235Simplifier ticks exhausted on recursive class method2023-09-18T10:01:18ZklaoSimplifier ticks exhausted on recursive class methodGHC 7.8 and HEAD panic on the following code:
```haskell
module C where
class C a where
c :: C a => a -> Int
c a = c a
{-# INLINE c #-}
instance C ()
x :: Int
x = c ()
```
Note that it's the coincidence of the 3 conditions tha...GHC 7.8 and HEAD panic on the following code:
```haskell
module C where
class C a where
c :: C a => a -> Int
c a = c a
{-# INLINE c #-}
instance C ()
x :: Int
x = c ()
```
Note that it's the coincidence of the 3 conditions that triggers this bug:
1. the `c` method has to be inlined (explicity or implicitly)
1. it has to be recursive (but, it doesn't have to be as dumbly recursive as in the example)
1. it has to have this weird, slightly mistaken type signature: `C a => a -> Int` instead of simply `a -> Int`.
But, when this incidentally happens (in my case, both 2. *and* 3. were unintentional), the user gets a very hard to debug issue. They don't even get an indication which module is responsible if `c` is used from a different module than the one with the class definition.
Also note that this happens even with a non-optimized build. And in this example `c` has to be explicitly marked NOINLINE to prevent it. (In the instance that I caught in the wild simply removing the INLINE annotation was enough.)
Finally, on a side note: shouldn't 3. by itself be an error? Or a warning at least?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.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 on recursive class method","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"GHC 7.8 and HEAD panic on the following code:\r\n\r\n{{{#!haskell\r\nmodule C where\r\n\r\nclass C a where\r\n c :: C a => a -> Int\r\n c a = c a\r\n {-# INLINE c #-}\r\n\r\ninstance C ()\r\n\r\nx :: Int\r\nx = c ()\r\n}}}\r\n\r\nNote that it's the coincidence of the 3 conditions that triggers this bug:\r\n1. the `c` method has to be inlined (explicity or implicitly)\r\n2. it has to be recursive (but, it doesn't have to be as dumbly recursive as in the example)\r\n3. it has to have this weird, slightly mistaken type signature: `C a => a -> Int` instead of simply `a -> Int`.\r\n\r\nBut, when this incidentally happens (in my case, both 2. ''and'' 3. were unintentional), the user gets a very hard to debug issue. They don't even get an indication which module is responsible if `c` is used from a different module than the one with the class definition.\r\n\r\nAlso note that this happens even with a non-optimized build. And in this example `c` has to be explicitly marked NOINLINE to prevent it. (In the instance that I caught in the wild simply removing the INLINE annotation was enough.)\r\n\r\nFinally, on a side note: shouldn't 3. by itself be an error? Or a warning at least?","type_of_failure":"OtherFailure","blocking":[]} -->⊥https://gitlab.haskell.org/ghc/ghc/-/issues/8833GHC (compilation mode) crashes2023-09-18T10:01:18ZguestGHC (compilation mode) crashes```
module Main where {
newtype Rec a b = Rec {deRec :: Rec a b -> a};
infixl 1 >|>;
infixl 1 <|<;
(>|>) = Rec;
(<|<) (Rec x) = x;
fix f = (\x -> f (x <|< x)) (Rec (\x -> f (x <|< x)));
factorial = fix (\f x -> if x<=1 then 1 else x*...```
module Main where {
newtype Rec a b = Rec {deRec :: Rec a b -> a};
infixl 1 >|>;
infixl 1 <|<;
(>|>) = Rec;
(<|<) (Rec x) = x;
fix f = (\x -> f (x <|< x)) (Rec (\x -> f (x <|< x)));
factorial = fix (\f x -> if x<=1 then 1 else x*f(x-1));
main = do {
x <- getLine;
putStrLn (show (factorial (read x)))
}
}
```
GHC crashes with this error:
```
[1 of 1] Compiling Main ( /Users/iOne/Documents/Test.hs, /Users/iOne/Documents/Test.o )
ghc: panic! (the 'impossible' happened)
(GHC version 7.6.3 for x86_64-apple-darwin):
Simplifier ticks exhausted
When trying UnfoldingDone a_sMx{v} [lid]
To increase the limit, use -fsimpl-tick-factor=N (default 100)
If you need to do this, let GHC HQ know, and what factor you needed
To see detailed counts use -ddump-simpl-stats
Total ticks: 7121
```
(This works fine in GHCi).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.6.3 |
| 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 (compilation mode) crashes","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"7.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"\r\n{{{\r\nmodule Main where {\r\n\r\nnewtype Rec a b = Rec {deRec :: Rec a b -> a};\r\n\r\ninfixl 1 >|>;\r\ninfixl 1 <|<;\r\n(>|>) = Rec;\r\n(<|<) (Rec x) = x;\r\n\r\nfix f = (\\x -> f (x <|< x)) (Rec (\\x -> f (x <|< x)));\r\n\r\nfactorial = fix (\\f x -> if x<=1 then 1 else x*f(x-1));\r\n\r\nmain = do {\r\n x <- getLine;\r\n putStrLn (show (factorial (read x)))\r\n }\r\n\r\n}\r\n}}}\r\n\r\nGHC crashes with this error:\r\n\r\n{{{\r\n[1 of 1] Compiling Main ( /Users/iOne/Documents/Test.hs, /Users/iOne/Documents/Test.o )\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 7.6.3 for x86_64-apple-darwin):\r\n\tSimplifier ticks exhausted\r\n When trying UnfoldingDone a_sMx{v} [lid]\r\n To increase the limit, use -fsimpl-tick-factor=N (default 100)\r\n If you need to do this, let GHC HQ know, and what factor you needed\r\n To see detailed counts use -ddump-simpl-stats\r\n Total ticks: 7121\r\n}}}\r\n(This works fine in GHCi).\r\n","type_of_failure":"OtherFailure","blocking":[]} -->⊥https://gitlab.haskell.org/ghc/ghc/-/issues/7057Simplifier infinite loop regression2023-09-18T10:01:18ZronwalfSimplifier infinite loop regressionGHC gets stuck in the simplifier when compiling the attached file, eventually exhausting all ram.
Compiling gives:
```
$ ghc -v3 -O --make ghcloop.hs
Glasgow Haskell Compiler, Version 7.4.2, stage 2 booted by GHC version 7.0.3
...
*** ...GHC gets stuck in the simplifier when compiling the attached file, eventually exhausting all ram.
Compiling gives:
```
$ ghc -v3 -O --make ghcloop.hs
Glasgow Haskell Compiler, Version 7.4.2, stage 2 booted by GHC version 7.0.3
...
*** Simplifier:
^C*** Deleting temp files:
...
```
Running with with all the dump flags suggests the fault is pddlDocExpr's. I'm finding it hard to create a smaller example, as even silly things like removing the container (or not using Data.Generics) restore termination.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.4.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 infinite loop regression","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.4.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"GHC gets stuck in the simplifier when compiling the attached file, eventually exhausting all ram.\r\nCompiling gives:\r\n{{{\r\n$ ghc -v3 -O --make ghcloop.hs \r\nGlasgow Haskell Compiler, Version 7.4.2, stage 2 booted by GHC version 7.0.3\r\n...\r\n*** Simplifier:\r\n^C*** Deleting temp files:\r\n...\r\n}}}\r\n\r\nRunning with with all the dump flags suggests the fault is pddlDocExpr's. I'm finding it hard to create a smaller example, as even silly things like removing the container (or not using Data.Generics) restore termination.","type_of_failure":"OtherFailure","blocking":[]} -->⊥Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/5470The DPH library needs to support PData and PRepr instances for more than 15-t...2023-12-01T14:06:24ZManuel M T ChakravartyThe DPH library needs to support PData and PRepr instances for more than 15-tuplesCurrently, `Data.Array.Parallel.PArray.PDataInstances` only generates tuple instances up to 6-tuple. This is not sufficient as these instances are used for environments of closures by the vectoriser — i.e., once a closures has more than ...Currently, `Data.Array.Parallel.PArray.PDataInstances` only generates tuple instances up to 6-tuple. This is not sufficient as these instances are used for environments of closures by the vectoriser — i.e., once a closures has more than 15 free variables, the compiler fails with `VectMonad.lookupFamInst: not found`.⊥Manuel M T ChakravartyManuel M T Chakravartyhttps://gitlab.haskell.org/ghc/ghc/-/issues/3960ghc panic when attempting to compile DPH code2023-12-01T14:04:42Zjwlatoghc panic when attempting to compile DPH codethe function "tmpfn" in the attached code causes ghc to panic (the 'impossible' happened). This bug is present in ghc 6.12.1 and 6.13.20100226
```
ghc: panic! (the 'impossible' happened)
(GHC version 6.12.1 for i386-apple-darwin):
Ve...the function "tmpfn" in the attached code causes ghc to panic (the 'impossible' happened). This bug is present in ghc 6.12.1 and 6.13.20100226
```
ghc: panic! (the 'impossible' happened)
(GHC version 6.12.1 for i386-apple-darwin):
VectMonad.lookupFamInst: not found:
dph-seq:Data.Array.Parallel.Lifted.PArray.PData{tc rq5}
(dph-seq:Data.Array.Parallel.Lifted.PArray.PArray{tc r35}
ghc-prim:GHC.Types.Double{(w) tc 3u},
dph-seq:Data.Array.Parallel.Lifted.PArray.PArray{tc r35}
ghc-prim:GHC.Types.Double{(w) tc 3u},
dph-seq:Data.Array.Parallel.Lifted.PArray.PArray{tc r35}
(dph-seq:Data.Array.Parallel.Lifted.PArray.PArray{tc r35}
(ghc-prim:GHC.Types.Int{(w) tc 3J},
ghc-prim:GHC.Types.Double{(w) tc 3u})),
dph-seq:Data.Array.Parallel.Lifted.PArray.PArray{tc r35}
ghc-prim:GHC.Types.Double{(w) tc 3u},
dph-seq:Data.Array.Parallel.Lifted.PArray.PArray{tc r35}
(dph-seq:Data.Array.Parallel.Lifted.PArray.PArray{tc r35}
(ghc-prim:GHC.Types.Int{(w) tc 3J},
ghc-prim:GHC.Types.Double{(w) tc 3u})),
dph-seq:Data.Array.Parallel.Lifted.PArray.PArray{tc r35}
ghc-prim:GHC.Types.Double{(w) tc 3u})
```⊥rl@cse.unsw.edu.aurl@cse.unsw.edu.auhttps://gitlab.haskell.org/ghc/ghc/-/issues/3903DPH bad sliceP causes RTS panic "allocGroup: requested zero blocks"2023-12-01T14:10:51ZbenlDPH bad sliceP causes RTS panic "allocGroup: requested zero blocks"```
$ ghci -XPArr
...
Prelude> :m GHC.PArr
Prelude GHC.PArr> sliceP 10 10 [::]
<interactive>: internal error: allocGroup: requested zero blocks
(GHC version 6.12.1 for i386_apple_darwin)
Please report this as a GHC bug: http://w...```
$ ghci -XPArr
...
Prelude> :m GHC.PArr
Prelude GHC.PArr> sliceP 10 10 [::]
<interactive>: internal error: allocGroup: requested zero blocks
(GHC version 6.12.1 for i386_apple_darwin)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Abort trap
```
`sliceP 10 10 [::]` is bogus. This should have been picked up in the libraries before hitting the RTS assertion.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | --------------------- |
| Version | 6.13 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Data Parallel Haskell |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"DPH bad sliceP causes RTS panic \"allocGroup: requested zero blocks\"","status":"New","operating_system":"","component":"Data Parallel Haskell","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"benl"},"version":"6.13","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\n$ ghci -XPArr\r\n...\r\nPrelude> :m GHC.PArr\r\nPrelude GHC.PArr> sliceP 10 10 [::]\r\n<interactive>: internal error: allocGroup: requested zero blocks\r\n (GHC version 6.12.1 for i386_apple_darwin)\r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\nAbort trap\r\n}}}\r\n\r\n`sliceP 10 10 [::]` is bogus. This should have been picked up in the libraries before hitting the RTS assertion.\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->⊥benlbenl