GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:47:56Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/7824problem with vector in arm2019-07-07T18:47:56Zchemistmailproblem with vector in armHello, i try compile my shoutcast server in raspberrypy and have next problem with dependence:
```
cabal install aeson snap-coreResolving dependencies...
Configuring vector-0.10.0.1...
Building vector-0.10.0.1...
Preprocessing library v...Hello, i try compile my shoutcast server in raspberrypy and have next problem with dependence:
```
cabal install aeson snap-coreResolving dependencies...
Configuring vector-0.10.0.1...
Building vector-0.10.0.1...
Preprocessing library vector-0.10.0.1...
[ 1 of 19] Compiling Data.Vector.Storable.Internal ( Data/Vector/Storable/Internal.hs, dist/build/Data/Vector/Storable/Internal.o )
[ 2 of 19] Compiling Data.Vector.Fusion.Util ( Data/Vector/Fusion/Util.hs, dist/build/Data/Vector/Fusion/Util.o )
[ 3 of 19] Compiling Data.Vector.Fusion.Stream.Size ( Data/Vector/Fusion/Stream/Size.hs, dist/build/Data/Vector/Fusion/Stream/Size.o )
Data/Vector/Fusion/Stream/Size.hs:25:10:
Warning: No explicit method nor default method for `*'
In the instance declaration for `Num Size'
Data/Vector/Fusion/Stream/Size.hs:25:10:
Warning: No explicit method nor default method for `abs'
In the instance declaration for `Num Size'
Data/Vector/Fusion/Stream/Size.hs:25:10:
Warning: No explicit method nor default method for `signum'
In the instance declaration for `Num Size'
[ 4 of 19] Compiling Data.Vector.Internal.Check ( Data/Vector/Internal/Check.hs, dist/build/Data/Vector/Internal/Check.o )
[ 5 of 19] Compiling Data.Vector.Fusion.Stream.Monadic ( Data/Vector/Fusion/Stream/Monadic.hs, dist/build/Data/Vector/Fusion/Stream/Monadic.o )
ghc: panic! (the 'impossible' happened)
(GHC version 7.4.1 for arm-unknown-linux):
Cant do annotations without GHCi
{Data/Vector/Fusion/Stream/Monadic.hs:104:19-33}
base:GHC.Exts.ForceSpecConstr{d ra42}
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
cabal: Error: some packages failed to install:
aeson-0.6.1.0 depends on vector-0.10.0.1 which failed to install.
snap-core-0.9.3.1 depends on vector-0.10.0.1 which failed to install.
vector-0.10.0.1 failed during the building phase. The exception was:
ExitFailure 1
```
what to do?
I can make account in my server, and give access for people who can help with my problem.7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/7805Panic: promoteType with higher-rank datatype2019-07-07T18:48:02ZRichard Eisenbergrae@richarde.devPanic: promoteType with higher-rank datatypeThe following code causes the panic in HEAD:
```
{-# LANGUAGE DataKinds, RankNTypes, TypeFamilies #-}
data HigherRank = HR (forall a. a -> a)
type family F (x :: HigherRank)
type instance F (HR x) = Bool
```
Here is the panic text:
...The following code causes the panic in HEAD:
```
{-# LANGUAGE DataKinds, RankNTypes, TypeFamilies #-}
data HigherRank = HR (forall a. a -> a)
type family F (x :: HigherRank)
type instance F (HR x) = Bool
```
Here is the panic text:
```
ghc-stage2: panic! (the 'impossible' happened)
(GHC version 7.7.20130329 for x86_64-apple-darwin):
promoteType
```
This panic does not happen with GHC 7.6.1.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.7 |
| 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":"Panic: promoteType with higher-rank datatype","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.7","keywords":["DataKinds"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The following code causes the panic in HEAD:\r\n\r\n{{{\r\n{-# LANGUAGE DataKinds, RankNTypes, TypeFamilies #-}\r\n\r\ndata HigherRank = HR (forall a. a -> a)\r\n\r\ntype family F (x :: HigherRank)\r\ntype instance F (HR x) = Bool\r\n}}}\r\n\r\nHere is the panic text:\r\n\r\n{{{\r\nghc-stage2: panic! (the 'impossible' happened)\r\n (GHC version 7.7.20130329 for x86_64-apple-darwin):\r\n\tpromoteType\r\n}}}\r\n\r\nThis panic does not happen with GHC 7.6.1.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/7802kindFunResult in monad transformer2019-07-07T18:48:05ZtobsankindFunResult in monad transformerThis is probably related to the existing (fixed?) bug(s) about kindFunResult, but better safe than sorry.
I was writing a brainfuck interpreter, and tried changing this code:
```
getptrval = gets mem >>= \a -> gets ptr >>= lift . readA...This is probably related to the existing (fixed?) bug(s) about kindFunResult, but better safe than sorry.
I was writing a brainfuck interpreter, and tried changing this code:
```
getptrval = gets mem >>= \a -> gets ptr >>= lift . readArray a
```
to this (which probably wouldn't even work):
```
getptrval = liftM2 (lift . readArray) (gets ptr) (gets mem)
```
which gives this error message from GHC:
```
Brainfuck.hs:53:21:ghc: panic! (the 'impossible' happened)
(GHC version 7.6.1 for x86_64-unknown-linux):
kindFunResult
<<details unavailable>>
```
Related type information:
```
type BFMonad a = StateT BFState IO a
data BFState = BF {
pc, ptr :: Int,
mem :: IOUArray Int Int,
program :: UArray Int Char
}
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.6.1 |
| 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":"kindFunResult in monad transformer","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This is probably related to the existing (fixed?) bug(s) about kindFunResult, but better safe than sorry.\r\n\r\nI was writing a brainfuck interpreter, and tried changing this code: \r\n\r\n{{{\r\ngetptrval = gets mem >>= \\a -> gets ptr >>= lift . readArray a\r\n}}}\r\n\r\nto this (which probably wouldn't even work):\r\n\r\n{{{\r\ngetptrval = liftM2 (lift . readArray) (gets ptr) (gets mem)\r\n}}}\r\n\r\n\r\nwhich gives this error message from GHC: \r\n\r\n{{{\r\nBrainfuck.hs:53:21:ghc: panic! (the 'impossible' happened)\r\n (GHC version 7.6.1 for x86_64-unknown-linux):\r\n\tkindFunResult\r\n<<details unavailable>>\r\n}}}\r\n\r\n\r\nRelated type information:\r\n\r\n\r\n{{{\r\ntype BFMonad a = StateT BFState IO a\r\ndata BFState = BF {\r\n pc, ptr :: Int,\r\n mem :: IOUArray Int Int,\r\n program :: UArray Int Char\r\n}\r\n}}}\r\n\r\n\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/7777ghc panic: varargs + sets2019-07-07T18:48:12Zlitherumghc panic: varargs + setsThis program:
{-\# LANGUAGE MultiParamTypeClasses \#-}
{-\# LANGUAGE FunctionalDependencies \#-}
{-\# LANGUAGE FlexibleInstances \#-}
{-\# LANGUAGE UndecidableInstances \#-}
import qualified Data.Set as S
class BuildSet a b \| b -\> a...This program:
{-\# LANGUAGE MultiParamTypeClasses \#-}
{-\# LANGUAGE FunctionalDependencies \#-}
{-\# LANGUAGE FlexibleInstances \#-}
{-\# LANGUAGE UndecidableInstances \#-}
import qualified Data.Set as S
class BuildSet a b \| b -\> a
> where buildset' :: S.Set a -\> a -\> b
instance Ord a =\> BuildSet a (S.Set a)
> where buildset' s i = S.insert i s
instance Ord a =\> BuildSet a b =\> BuildSet a (a -\> b)
> where buildset' s i = \\ i2 -\> buildset' (S.insert i s) i2
buildset :: BuildSet a b =\> a -\> b
buildset = buildset' S.empty
s1 :: S.Set Integer
s1 = buildset 3
s2 :: S.Set Integer
s2 = buildset 1 2 3
s3 :: S.Set Integer
s3 = buildset 8 4 2 1 2 4 8 18
main = do
> putStrLn $ show l1
> putStrLn $ show l2
> putStrLn $ show l3
produces this output when compiled:
$ ghc --make test.hs
\[1 of 1\] Compiling Main ( test.hs, test.o )
ghc: panic! (the 'impossible' happened)
> (GHC version 7.4.1 for x86_64-unknown-linux):
compiler/rename/RnSource.lhs:429:14-81: Irrefutable pattern failed for pattern Data.Maybe.Just (inst_tyvars,
_,
SrcLoc.L _ cls,
> _)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.4.1
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.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":"ghc panic: varargs + sets","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.4.1","keywords":["FlexibleInstances","FunctionalDependencies","MultiParamTypeClasses","UndecidableInstances"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This program:\r\n\r\n{-# LANGUAGE MultiParamTypeClasses #-}\r\n{-# LANGUAGE FunctionalDependencies #-}\r\n{-# LANGUAGE FlexibleInstances #-}\r\n{-# LANGUAGE UndecidableInstances #-}\r\n\r\nimport qualified Data.Set as S\r\n\r\nclass BuildSet a b | b -> a\r\n where buildset' :: S.Set a -> a -> b\r\n\r\ninstance Ord a => BuildSet a (S.Set a)\r\n where buildset' s i = S.insert i s \r\n\r\ninstance Ord a => BuildSet a b => BuildSet a (a -> b)\r\n where buildset' s i = \\ i2 -> buildset' (S.insert i s) i2\r\n\r\nbuildset :: BuildSet a b => a -> b\r\nbuildset = buildset' S.empty\r\n\r\ns1 :: S.Set Integer\r\ns1 = buildset 3\r\n\r\ns2 :: S.Set Integer\r\ns2 = buildset 1 2 3 \r\n\r\ns3 :: S.Set Integer\r\ns3 = buildset 8 4 2 1 2 4 8 18\r\n\r\nmain = do\r\n putStrLn $ show l1\r\n putStrLn $ show l2\r\n putStrLn $ show l3\r\n\r\nproduces this output when compiled:\r\n\r\n$ ghc --make test.hs\r\n[1 of 1] Compiling Main ( test.hs, test.o )\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 7.4.1 for x86_64-unknown-linux):\r\n\tcompiler/rename/RnSource.lhs:429:14-81: Irrefutable pattern failed for pattern Data.Maybe.Just (inst_tyvars,\r\n _,\r\n SrcLoc.L _ cls,\r\n _)\r\n\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\n$ ghc --version\r\nThe Glorious Glasgow Haskell Compilation System, version 7.4.1","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/7744Can't install conduit via cabal-install2019-07-07T18:48:19ZguestCan't install conduit via cabal-installWhen I did `cabal install hoogle` it failed on one of the dependencies, called conduit. Here is the output:
```
Downloading conduit-1.0.2...
Configuring conduit-1.0.2...
Building conduit-1.0.2...
Preprocessing library conduit-1.0.2...
[...When I did `cabal install hoogle` it failed on one of the dependencies, called conduit. Here is the output:
```
Downloading conduit-1.0.2...
Configuring conduit-1.0.2...
Building conduit-1.0.2...
Preprocessing library conduit-1.0.2...
[1 of 7] Compiling Data.Conduit.Internal ( Data/Conduit/Internal.hs, dist/build/Data/Conduit/Internal.o )
[2 of 7] Compiling Data.Conduit.Util ( Data/Conduit/Util.hs, dist/build/Data/Conduit/Util.o )
[3 of 7] Compiling Data.Conduit ( Data/Conduit.hs, dist/build/Data/Conduit.o )
[4 of 7] Compiling Data.Conduit.List ( Data/Conduit/List.hs, dist/build/Data/Conduit/List.o )
[5 of 7] Compiling Data.Conduit.Binary ( Data/Conduit/Binary.hs, dist/build/Data/Conduit/Binary.o )
ghc: internal error: evacuate: strange closure type 8
(GHC version 7.6.2 for x86_64_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Failed to install conduit-1.0.2
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.6.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Linux |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Can't install conduit via cabal-install","status":"New","operating_system":"Linux","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When I did {{{cabal install hoogle}}} it failed on one of the dependencies, called conduit. Here is the output:\r\n\r\n{{{\r\nDownloading conduit-1.0.2...\r\nConfiguring conduit-1.0.2...\r\nBuilding conduit-1.0.2...\r\nPreprocessing library conduit-1.0.2...\r\n[1 of 7] Compiling Data.Conduit.Internal ( Data/Conduit/Internal.hs, dist/build/Data/Conduit/Internal.o )\r\n[2 of 7] Compiling Data.Conduit.Util ( Data/Conduit/Util.hs, dist/build/Data/Conduit/Util.o )\r\n[3 of 7] Compiling Data.Conduit ( Data/Conduit.hs, dist/build/Data/Conduit.o )\r\n[4 of 7] Compiling Data.Conduit.List ( Data/Conduit/List.hs, dist/build/Data/Conduit/List.o )\r\n[5 of 7] Compiling Data.Conduit.Binary ( Data/Conduit/Binary.hs, dist/build/Data/Conduit/Binary.o )\r\nghc: internal error: evacuate: strange closure type 8\r\n (GHC version 7.6.2 for x86_64_unknown_linux)\r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\nFailed to install conduit-1.0.2\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/7736Parallel array enumeration causes compiler panic (enumFromToP)2019-07-07T18:48:21ZamosrobinsonParallel array enumeration causes compiler panic (enumFromToP)Enumeration doesn't work in parallel array comprehensions:
```
nums = [: 0 .. 100 :]
```
causes a compiler panic. Interestingly, the panic seems to happen before typechecking because if we add some nonsense:
```
other = 5 / "bad"
nums...Enumeration doesn't work in parallel array comprehensions:
```
nums = [: 0 .. 100 :]
```
causes a compiler panic. Interestingly, the panic seems to happen before typechecking because if we add some nonsense:
```
other = 5 / "bad"
nums = [: 0 .. 100 :]
```
it still panics.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.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":"Parallel array enumeration causes compiler panic (enumFromToP)","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Enumeration doesn't work in parallel array comprehensions:\r\n\r\n{{{\r\nnums = [: 0 .. 100 :]\r\n}}}\r\n\r\ncauses a compiler panic. Interestingly, the panic seems to happen before typechecking because if we add some nonsense:\r\n\r\n{{{\r\nother = 5 / \"bad\"\r\nnums = [: 0 .. 100 :]\r\n}}}\r\n\r\nit still panics.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1Manuel M T ChakravartyManuel M T Chakravartyhttps://gitlab.haskell.org/ghc/ghc/-/issues/7713Panic! make_exp (App _ (Coercion _)) when compiled with -fext-core2019-07-07T18:48:27ZEduardSergeevPanic! make_exp (App _ (Coercion _)) when compiled with -fext-coreAn attempt to compile the attached file with 7.6.2 (and 7.4.2) with "-O2 -fext-core" leads to:
```
ghc: panic! (the 'impossible' happened)
(GHC version 7.6.2 for x86_64-unknown-linux):
make_exp (App _ (Coercion _))
```An attempt to compile the attached file with 7.6.2 (and 7.4.2) with "-O2 -fext-core" leads to:
```
ghc: panic! (the 'impossible' happened)
(GHC version 7.6.2 for x86_64-unknown-linux):
make_exp (App _ (Coercion _))
```7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/7701compiler exception when -> is used instead of => in instance definition2019-07-07T18:48:31Zerantapaacompiler exception when -> is used instead of => in instance definitionWhen running ghci on the attached file, the following exception is raised:
```
*** Exception: compiler/rename/RnSource.lhs:430:14-81: Irrefutable pattern failed for pattern Data.Maybe.Just (inst_tyvars,
...When running ghci on the attached file, the following exception is raised:
```
*** Exception: compiler/rename/RnSource.lhs:430:14-81: Irrefutable pattern failed for pattern Data.Maybe.Just (inst_tyvars,
_,
SrcLoc.L _ cls,
_)
```
It seems to stem from accidentally using -\> instead of =\> in the following instance definition:
```
instance (ListConcat xs ys zs) -> ListConcat (x ::: xs) ys (x ::: zs)
where listConcat = undefined
```
<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":"compiler exception when -> is used instead of => in instance definition","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":"When running ghci on the attached file, the following exception is raised:\r\n\r\n{{{\r\n*** Exception: compiler/rename/RnSource.lhs:430:14-81: Irrefutable pattern failed for pattern Data.Maybe.Just (inst_tyvars,\r\n _,\r\n SrcLoc.L _ cls,\r\n _)\r\n}}}\r\n\r\nIt seems to stem from accidentally using -> instead of => in the following instance definition:\r\n\r\n{{{\r\ninstance (ListConcat xs ys zs) -> ListConcat (x ::: xs) ys (x ::: zs)\r\n where listConcat = undefined\r\n}}}\r\n\r\n \r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/7691ghc.exe: internal error: evacuate: strange closure type 488802019-07-07T18:48:35ZHenk-Janghc.exe: internal error: evacuate: strange closure type 48880While trying to install haskell-src-exts-1.13.5, the following message was displayed:
ghc.exe: internal error: evacuate: strange closure type 48880
(GHC version 7.4.2 for i386_unknown_mingw32)
> Please report this as a GHC bug: http:...While trying to install haskell-src-exts-1.13.5, the following message was displayed:
ghc.exe: internal error: evacuate: strange closure type 48880
(GHC version 7.4.2 for i386_unknown_mingw32)
> Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
See the attached file for all messages.
I issued command
> cabal install haskell-src-exts-1.13.5
after this; the command was successful.
<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":"ghc.exe: internal error: evacuate: strange closure type 48880","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":"While trying to install haskell-src-exts-1.13.5, the following message was displayed:\r\nghc.exe: internal error: evacuate: strange closure type 48880\r\n (GHC version 7.4.2 for i386_unknown_mingw32)\r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\nSee the attached file for all messages. \r\nI issued command\r\n cabal install haskell-src-exts-1.13.5\r\nafter this; the command was successful.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/7687ghc panic on TH and deriveJSON2019-07-07T18:48:37Zguestghc panic on TH and deriveJSON```
{-# LANGUAGE CPP,TemplateHaskell #-}
module Main (main) where
import Data.Aeson.TH
data Test = Test Int deriving Show
deriveJSON id ''Test
main = return ()
```
will give
```
Building aeson-test-0.0.1...
Preprocessing test suit...```
{-# LANGUAGE CPP,TemplateHaskell #-}
module Main (main) where
import Data.Aeson.TH
data Test = Test Int deriving Show
deriveJSON id ''Test
main = return ()
```
will give
```
Building aeson-test-0.0.1...
Preprocessing test suite 'test-aeson-test' for aeson-test-0.0.1...
[1 of 1] Compiling Main ( src\Main.hs, dist\build\test-aeson-test\test-aeson-test-tmp\Main.o )
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package array-0.4.0.0 ... linking ... done.
Loading package bytestring-0.9.2.1 ... linking ... done.
Loading package deepseq-1.3.0.0 ... linking ... done.
Loading package containers-0.4.2.1 ... linking ... done.
ghc.exe: panic! (the 'impossible' happened)
Loading package text-0.11.2.3 ... linking ... done.
(GHC version 7.4.2 for i386-unknown-mingw32):
Loading package attoparsec-0.10.4.0 ... linking ... done.
loadObj "C:\\Users\\User\\AppData\\Roaming\\cabal\\hashable-1.2.0.5\\ghc-7.4.2\\HShashable-1.2.0.5.o": failed
Loading package blaze-builder-0.3.1.0 ... linking ... done.
Loading package dlist-0.5 ... linking ... done.
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Loading package hashable-1.2.0.5 ...
ghc.exe: Unknown PEi386 section name `.text.startup' (while processing: C:\Users\User\AppData\Roaming\cabal\hashable-1.2.0.5\ghc-7.4.2\HShashable-1.2.0.5.o)
```8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/7623GHC Arm support2019-07-07T18:48:57ZdtereiGHC Arm supportTop level to track some important fixes for proper ARM support of GHC.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.7 ...Top level to track some important fixes for proper ARM support of GHC.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.7 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC Arm support","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"Top level to track some important fixes for proper ARM support of GHC.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/7617LLVM backend broken on 32bit OS X (when 64bit host)2019-07-07T18:48:58ZdtereiLLVM backend broken on 32bit OS X (when 64bit host)OSX 32bit GHC is broken when running on a 64bit host. This is as we aren't passing the correct flags through to clang (the assembler used) to indicate it should compile as 32bit instead of 64bit...
<details><summary>Trac metadata</summa...OSX 32bit GHC is broken when running on a 64bit host. This is as we aren't passing the correct flags through to clang (the assembler used) to indicate it should compile as 32bit instead of 64bit...
<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":"LLVM backend broken on 32bit OS X (when 64bit host)","status":"New","operating_system":"","component":"Compiler (LLVM)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"dterei"},"version":"","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"OSX 32bit GHC is broken when running on a 64bit host. This is as we aren't passing the correct flags through to clang (the assembler used) to indicate it should compile as 32bit instead of 64bit...","type_of_failure":"OtherFailure","blocking":[]} -->dtereidtereihttps://gitlab.haskell.org/ghc/ghc/-/issues/7614tc_hs_type: bang : The impossible happened2019-07-07T18:48:59Zerikdtc_hs_type: bang : The impossible happenedA simple data structure with bang patterns like the following:
```
data MyType
= MyType
{ a :: !Int
, b :: !Maybe Int
}
```
results in:
```
ghc: panic! (the 'impossible' happened)
(GHC version 7.6.1 for x...A simple data structure with bang patterns like the following:
```
data MyType
= MyType
{ a :: !Int
, b :: !Maybe Int
}
```
results in:
```
ghc: panic! (the 'impossible' happened)
(GHC version 7.6.1 for x86_64-unknown-linux):
tc_hs_type: bang
```
Adding parentheses around the "Maybe Int" like this:
```
data MyType
= MyType
{ a :: !Int
, b :: !(Maybe Int)
}
```
is accepted, but it would be nice if the former example printed a syntax error or some sort of other warning rather than just a panic.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.6.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":"tc_hs_type: bang : The impossible happened","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"A simple data structure with bang patterns like the following:\r\n\r\n{{{\r\ndata MyType\r\n = MyType\r\n { a :: !Int\r\n , b :: !Maybe Int\r\n }\r\n}}}\r\n\r\nresults in:\r\n\r\n{{{\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 7.6.1 for x86_64-unknown-linux):\r\n tc_hs_type: bang\r\n}}}\r\n\r\nAdding parentheses around the \"Maybe Int\" like this:\r\n\r\n{{{\r\ndata MyType\r\n = MyType\r\n { a :: !Int\r\n , b :: !(Maybe Int)\r\n }\r\n}}}\r\n\r\nis accepted, but it would be nice if the former example printed a syntax error or some sort of other warning rather than just a panic.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/7603Bad magic in static (FFI) object (7.6.1 for x86_64-apple-darwin)2019-07-07T18:49:02ZmorabbinBad magic in static (FFI) object (7.6.1 for x86_64-apple-darwin)When spraying [HOC](http://code.google.com/p/hoc/) (Haskell to Objective-C) for bitrot, I encountered a GHC panic during the loading of some FFI.
Judging by the log below, it looks like this is during a TH execution, so the problem may ...When spraying [HOC](http://code.google.com/p/hoc/) (Haskell to Objective-C) for bitrot, I encountered a GHC panic during the loading of some FFI.
Judging by the log below, it looks like this is during a TH execution, so the problem may be bitrot in this code wrt TH. Quite happy to dig further myself if pointed in the right direction.
```
Orac:~/work/hoc-read-only/hoc $ cabal build
Compiling HOC_cbits...
Building HOC-1.0...
Preprocessing library HOC-1.0...
[16 of 31] Compiling HOC.Invocation ( HOC/HOC/Invocation.hs, dist/build/HOC/Invocation.o )
HOC/HOC/Invocation.hs:14:1:
Unacceptable argument type in foreign declaration: FFICif
When checking declaration:
foreign import ccall safe "static Invocation.h callWithExceptions" c_callWithExceptions
:: FFICif
-> FunPtr a -> Ptr b -> Ptr (Ptr ()) -> IO (Ptr ObjCObject)
Orac:~/work/hoc-read-only/hoc $ cabal build
Compiling HOC_cbits...
Building HOC-1.0...
Preprocessing library HOC-1.0...
[ 7 of 31] Compiling HOC.FFICallInterface ( HOC/HOC/FFICallInterface.hs, dist/build/HOC/FFICallInterface.o )
[ 8 of 31] Compiling HOC.Arguments ( HOC/HOC/Arguments.hs, dist/build/HOC/Arguments.o ) [HOC.FFICallInterface changed]
[11 of 31] Compiling HOC.CStruct ( HOC/HOC/CStruct.hs, dist/build/HOC/CStruct.o ) [HOC.FFICallInterface changed]
[13 of 31] Compiling HOC.ID ( HOC/HOC/ID.hs, dist/build/HOC/ID.o ) [HOC.FFICallInterface changed]
[16 of 31] Compiling HOC.Invocation ( HOC/HOC/Invocation.hs, dist/build/HOC/Invocation.o )
[17 of 31] Compiling HOC.ExternFunctions ( HOC/HOC/ExternFunctions.hs, dist/build/HOC/ExternFunctions.o )
HOC/HOC/ExternFunctions.hs:77:34:
Ambiguous occurrence `unsafePerformIO'
It could refer to either `Foreign.unsafePerformIO',
imported from `Foreign' at HOC/HOC/ExternFunctions.hs:10:1-14
or `System.IO.Unsafe.unsafePerformIO',
imported from `System.IO.Unsafe' at HOC/HOC/ExternFunctions.hs:11:1-23
(and originally defined in `GHC.IO')
Orac:~/work/hoc-read-only/hoc $ cabal build
Compiling HOC_cbits...
Building HOC-1.0...
Preprocessing library HOC-1.0...
[17 of 31] Compiling HOC.ExternFunctions ( HOC/HOC/ExternFunctions.hs, dist/build/HOC/ExternFunctions.o )
[18 of 31] Compiling HOC.StdArgumentTypes ( HOC/HOC/StdArgumentTypes.hs, dist/build/HOC/StdArgumentTypes.o )
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package array-0.4.0.1 ... linking ... done.
Loading package deepseq-1.3.0.1 ... linking ... done.
Loading package containers-0.5.0.0 ... linking ... done.
Loading package pretty-1.1.1.0 ... linking ... done.
Loading package template-haskell ... linking ... done.
Loading package syb-0.3.7 ... linking ... done.
Loading package bytestring-0.10.0.0 ... linking ... done.
Loading package transformers-0.3.0.0 ... linking ... done.
Loading package mtl-2.1.2 ... linking ... done.
Loading package text-0.11.2.3 ... linking ... done.
Loading package parsec-3.1.3 ... linking ... done.
Loading package old-locale-1.0.0.5 ... linking ... done.
Loading package old-time-1.1.0.1 ... linking ... done.
Loading package fgl-5.4.2.4 ... linking ... done.
Loading package filepath-1.3.0.1 ... linking ... done.
Loading package time-1.4.0.1 ... linking ... done.
Loading package unix-2.6.0.0 ... linking ... done.
Loading package directory-1.2.0.0 ... linking ... done.
Loading package binary-0.5.1.1 ... linking ... done.
Loading package HUnit-1.2.5.1 ... linking ... done.
Loading object (static) dist/build/HOC_cbits.o ... ghc: dist/build/HOC_cbits.o: Bad magic. Expected: feedfacf, got: feedface.
ghc: panic! (the 'impossible' happened)
(GHC version 7.6.1 for x86_64-apple-darwin):
loadObj "dist/build/HOC_cbits.o": failed
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.6.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":"Bad magic in static (FFI) object (7.6.1 for x86_64-apple-darwin)","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When spraying [http://code.google.com/p/hoc/ HOC] (Haskell to Objective-C) for bitrot, I encountered a GHC panic during the loading of some FFI.\r\n\r\nJudging by the log below, it looks like this is during a TH execution, so the problem may be bitrot in this code wrt TH. Quite happy to dig further myself if pointed in the right direction.\r\n\r\n{{{\r\nOrac:~/work/hoc-read-only/hoc $ cabal build\r\nCompiling HOC_cbits...\r\nBuilding HOC-1.0...\r\nPreprocessing library HOC-1.0...\r\n[16 of 31] Compiling HOC.Invocation ( HOC/HOC/Invocation.hs, dist/build/HOC/Invocation.o )\r\n\r\nHOC/HOC/Invocation.hs:14:1:\r\n Unacceptable argument type in foreign declaration: FFICif\r\n When checking declaration:\r\n foreign import ccall safe \"static Invocation.h callWithExceptions\" c_callWithExceptions\r\n :: FFICif\r\n -> FunPtr a -> Ptr b -> Ptr (Ptr ()) -> IO (Ptr ObjCObject)\r\nOrac:~/work/hoc-read-only/hoc $ cabal build\r\nCompiling HOC_cbits...\r\nBuilding HOC-1.0...\r\nPreprocessing library HOC-1.0...\r\n[ 7 of 31] Compiling HOC.FFICallInterface ( HOC/HOC/FFICallInterface.hs, dist/build/HOC/FFICallInterface.o )\r\n[ 8 of 31] Compiling HOC.Arguments ( HOC/HOC/Arguments.hs, dist/build/HOC/Arguments.o ) [HOC.FFICallInterface changed]\r\n[11 of 31] Compiling HOC.CStruct ( HOC/HOC/CStruct.hs, dist/build/HOC/CStruct.o ) [HOC.FFICallInterface changed]\r\n[13 of 31] Compiling HOC.ID ( HOC/HOC/ID.hs, dist/build/HOC/ID.o ) [HOC.FFICallInterface changed]\r\n[16 of 31] Compiling HOC.Invocation ( HOC/HOC/Invocation.hs, dist/build/HOC/Invocation.o )\r\n[17 of 31] Compiling HOC.ExternFunctions ( HOC/HOC/ExternFunctions.hs, dist/build/HOC/ExternFunctions.o )\r\n\r\nHOC/HOC/ExternFunctions.hs:77:34:\r\n Ambiguous occurrence `unsafePerformIO'\r\n It could refer to either `Foreign.unsafePerformIO',\r\n imported from `Foreign' at HOC/HOC/ExternFunctions.hs:10:1-14\r\n or `System.IO.Unsafe.unsafePerformIO',\r\n imported from `System.IO.Unsafe' at HOC/HOC/ExternFunctions.hs:11:1-23\r\n (and originally defined in `GHC.IO')\r\nOrac:~/work/hoc-read-only/hoc $ cabal build\r\nCompiling HOC_cbits...\r\nBuilding HOC-1.0...\r\nPreprocessing library HOC-1.0...\r\n[17 of 31] Compiling HOC.ExternFunctions ( HOC/HOC/ExternFunctions.hs, dist/build/HOC/ExternFunctions.o )\r\n[18 of 31] Compiling HOC.StdArgumentTypes ( HOC/HOC/StdArgumentTypes.hs, dist/build/HOC/StdArgumentTypes.o )\r\nLoading package ghc-prim ... linking ... done.\r\nLoading package integer-gmp ... linking ... done.\r\nLoading package base ... linking ... done.\r\nLoading package array-0.4.0.1 ... linking ... done.\r\nLoading package deepseq-1.3.0.1 ... linking ... done.\r\nLoading package containers-0.5.0.0 ... linking ... done.\r\nLoading package pretty-1.1.1.0 ... linking ... done.\r\nLoading package template-haskell ... linking ... done.\r\nLoading package syb-0.3.7 ... linking ... done.\r\nLoading package bytestring-0.10.0.0 ... linking ... done.\r\nLoading package transformers-0.3.0.0 ... linking ... done.\r\nLoading package mtl-2.1.2 ... linking ... done.\r\nLoading package text-0.11.2.3 ... linking ... done.\r\nLoading package parsec-3.1.3 ... linking ... done.\r\nLoading package old-locale-1.0.0.5 ... linking ... done.\r\nLoading package old-time-1.1.0.1 ... linking ... done.\r\nLoading package fgl-5.4.2.4 ... linking ... done.\r\nLoading package filepath-1.3.0.1 ... linking ... done.\r\nLoading package time-1.4.0.1 ... linking ... done.\r\nLoading package unix-2.6.0.0 ... linking ... done.\r\nLoading package directory-1.2.0.0 ... linking ... done.\r\nLoading package binary-0.5.1.1 ... linking ... done.\r\nLoading package HUnit-1.2.5.1 ... linking ... done.\r\nLoading object (static) dist/build/HOC_cbits.o ... ghc: dist/build/HOC_cbits.o: Bad magic. Expected: feedfacf, got: feedface.\r\n\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 7.6.1 for x86_64-apple-darwin):\r\n\tloadObj \"dist/build/HOC_cbits.o\": failed\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/7600cgrun044 failing with LLVM backend2019-07-07T18:49:02Zdtereicgrun044 failing with LLVM backendtest case cgrun044 fails currently with the LLVM backend. I believe this started with the switch to the new-code-generator.
LLVM fails to compile the file due to an invalid floating point constant:
```
/Users/davidt/bin/opt: Bug31.ll:2...test case cgrun044 fails currently with the LLVM backend. I believe this started with the switch to the new-code-generator.
LLVM fails to compile the file due to an invalid floating point constant:
```
/Users/davidt/bin/opt: Bug31.ll:23:155: error: floating point constant invalid for type
@Bug31_floatzunumber_closure = global %Bug31_floatzunumber_closure_struct<{i64 ptrtoint ([0 x i64]* @ghczmprim_GHCziTypes_Fzh_static_info to i64), float 0x7F800000, i32 0}>
```
This is an old, annoying bug needing to be fixed for about the third time. Basically, LLVM requires all floating points (float, doubles...) be printed in IEEE 754 Double format, even single precision numbers (float). However, it expects types labeled float to be representable in IEEE 754 Single precision format...
So what we do is store all floating point numbers as Double and then narrow those that are Float by trying to do 'Double -\> Float -\> Double'. Then we can use the same machinery to produce the output for LLVM.
Annoying, GHC seems to like to optimize away these narrowing operations. If it should or shouldn't do that is questionable. I'd argue it shouldn't, but oh well.
The new-code-generator seems to have defeated existing techniques for stopping the optimizer firing.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | --------------- |
| Version | 7.7 |
| 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":"cgrun044 failing with LLVM backend","status":"New","operating_system":"","component":"Compiler (LLVM)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"dterei"},"version":"7.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"test case cgrun044 fails currently with the LLVM backend. I believe this started with the switch to the new-code-generator.\r\n\r\nLLVM fails to compile the file due to an invalid floating point constant:\r\n\r\n{{{\r\n/Users/davidt/bin/opt: Bug31.ll:23:155: error: floating point constant invalid for type\r\n@Bug31_floatzunumber_closure = global %Bug31_floatzunumber_closure_struct<{i64 ptrtoint ([0 x i64]* @ghczmprim_GHCziTypes_Fzh_static_info to i64), float 0x7F800000, i32 0}>\r\n}}}\r\n\r\nThis is an old, annoying bug needing to be fixed for about the third time. Basically, LLVM requires all floating points (float, doubles...) be printed in IEEE 754 Double format, even single precision numbers (float). However, it expects types labeled float to be representable in IEEE 754 Single precision format...\r\n\r\nSo what we do is store all floating point numbers as Double and then narrow those that are Float by trying to do 'Double -> Float -> Double'. Then we can use the same machinery to produce the output for LLVM.\r\n\r\nAnnoying, GHC seems to like to optimize away these narrowing operations. If it should or shouldn't do that is questionable. I'd argue it shouldn't, but oh well.\r\n\r\nThe new-code-generator seems to have defeated existing techniques for stopping the optimizer firing.","type_of_failure":"OtherFailure","blocking":[]} -->dtereidtereihttps://gitlab.haskell.org/ghc/ghc/-/issues/7585Core lint failure when optimizing coercions in branched axioms2019-07-07T18:49:07ZRichard Eisenbergrae@richarde.devCore lint failure when optimizing coercions in branched axiomsThe attached code causes the failure.
Core Lint correctly checks branched axioms for internal consistency -- when using branch *n* of an axiom, we must ensure that no branch *m \< n* can possibly apply, no matter what the instantiation ...The attached code causes the failure.
Core Lint correctly checks branched axioms for internal consistency -- when using branch *n* of an axiom, we must ensure that no branch *m \< n* can possibly apply, no matter what the instantiation for any type variables in the branch may be. However, the coercion optimizer does not respect this property. It will replace coercions used in axioms with equivalent coercions that do not respect this internal consistency property. Everything works out OK in the end (without `-dcore-lint`, the file compiles and runs correctly), but we go through an invalid state on the way.
In particular, the `TrPushAx` rules are to blame.
I'm not sure what the best fix for this is, but it seems to be my job to find it.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.7 |
| 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 failure when optimizing coercions in branched axioms","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"goldfire"},"version":"7.7","keywords":["TypeFamilies"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The attached code causes the failure.\r\n\r\nCore Lint correctly checks branched axioms for internal consistency -- when using branch ''n'' of an axiom, we must ensure that no branch ''m < n'' can possibly apply, no matter what the instantiation for any type variables in the branch may be. However, the coercion optimizer does not respect this property. It will replace coercions used in axioms with equivalent coercions that do not respect this internal consistency property. Everything works out OK in the end (without {{{-dcore-lint}}}, the file compiles and runs correctly), but we go through an invalid state on the way.\r\n\r\nIn particular, the {{{TrPushAx}}} rules are to blame.\r\n\r\nI'm not sure what the best fix for this is, but it seems to be my job to find it.","type_of_failure":"OtherFailure","blocking":[]} -->Richard Eisenbergrae@richarde.devRichard Eisenbergrae@richarde.devhttps://gitlab.haskell.org/ghc/ghc/-/issues/7581ghc crashed on trying compiling a file generated by Alex2019-07-07T18:49:08Zguestghc crashed on trying compiling a file generated by AlexC:\\Documents and Settings\\bcyrille\\My Documents\\Hskl\>ghc M90.hs
\[1 of 1\] Compiling Main ( M90.hs, M90.o )
ghc: panic! (the 'impossible' happened)
(GHC version 7.4.2 for i386-unknown-mingw32):
> nameModule show{tv aqY}
Please ...C:\\Documents and Settings\\bcyrille\\My Documents\\Hskl\>ghc M90.hs
\[1 of 1\] Compiling Main ( M90.hs, M90.o )
ghc: panic! (the 'impossible' happened)
(GHC version 7.4.2 for i386-unknown-mingw32):
> nameModule show{tv aqY}
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Alex version is 3.0.2
ghc version is 7.4.2
(haskell platform 2012.4.0.0)
Can't give much details, first time using Alex... attaching the files
<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":"ghc crashed on trying compiling a file generated by Alex","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":"C:\\Documents and Settings\\bcyrille\\My Documents\\Hskl>ghc M90.hs\r\n[1 of 1] Compiling Main ( M90.hs, M90.o )\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 7.4.2 for i386-unknown-mingw32):\r\n nameModule show{tv aqY}\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\nAlex version is 3.0.2\r\nghc version is 7.4.2\r\n(haskell platform 2012.4.0.0)\r\n\r\nCan't give much details, first time using Alex... attaching the files\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/7574Register allocator chokes on certain branches with literals2019-07-07T18:49:10ZthoughtpoliceRegister allocator chokes on certain branches with literalsWhile running the test for #7571 (test is in #7573,) under **WAY=normal** instead of **WAY=llvm**, I encountered this bug in the native backend:
```
=====> T7571(normal) 6 of 6 [0, 0, 0]
cd . && '/Users/a/code/haskell/ghc/inplace/bin/gh...While running the test for #7571 (test is in #7573,) under **WAY=normal** instead of **WAY=llvm**, I encountered this bug in the native backend:
```
=====> T7571(normal) 6 of 6 [0, 0, 0]
cd . && '/Users/a/code/haskell/ghc/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T7571.cmm -no-hs-main >T7571.comp.stderr 2>&1
Compile failed (status 256) errors were:
ghc-stage2: panic! (the 'impossible' happened)
(GHC version 7.7.20130113 for x86_64-apple-darwin):
allocateRegsAndSpill: Cannot read from uninitialized register
%vI_c7
```
The test in question is:
```
#include "Cmm.h"
testLiteralBranch (W_ dst, W_ src)
{
if (1) {
prim %memcpy(dst, src, 1024, 4);
} else {
prim %memcpy(dst, src, 512, 8);
}
return ();
}
```
If you comment out the branch conditionals, the test passes, so clearly something fishy is going on here. The test also fails if you change the condition to ```if (1 == 1)```
I have absolutely no idea how this did not trip the profiling-based build in StgStdThunks.cmm, like in the LLVM build c.f. #75717.8.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/7564GHC fails without an error when building text-0.11.2.32019-07-07T18:49:12ZguestGHC fails without an error when building text-0.11.2.3I wanted to install GHC-7.6.1 on my server system. It is a CentOS 6. I have downloaded the ghc binary for linux x86_64, installed via "make install"
Then I wanted to install cabal-install from the hackage. I executed bootstrap.sh, and a...I wanted to install GHC-7.6.1 on my server system. It is a CentOS 6. I have downloaded the ghc binary for linux x86_64, installed via "make install"
Then I wanted to install cabal-install from the hackage. I executed bootstrap.sh, and all went ok until it arrived at the text package. GHC stopped there without any error or message.
So I downloaded text manually and executed "./Setup compile -v3". I have attached the resulting logs.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.6.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":"GHC fails without an error when building text-0.11.2.3","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I wanted to install GHC-7.6.1 on my server system. It is a CentOS 6. I have downloaded the ghc binary for linux x86_64, installed via \"make install\"\r\n\r\nThen I wanted to install cabal-install from the hackage. I executed bootstrap.sh, and all went ok until it arrived at the text package. GHC stopped there without any error or message.\r\n\r\nSo I downloaded text manually and executed \"./Setup compile -v3\". I have attached the resulting logs.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/7560Panic in conflictInstErr when branched type family instances conflict2019-07-07T18:49:13ZRichard Eisenbergrae@richarde.devPanic in conflictInstErr when branched type family instances conflictThis code causes the panic:
```
{-# LANGUAGE TypeFamilies #-}
type family F a
type instance where
F Int = Int
F Bool = Bool
type instance where
F Int = Char
F Double = Double
```
Here is the output:
```
ghc: panic! (the 'im...This code causes the panic:
```
{-# LANGUAGE TypeFamilies #-}
type family F a
type instance where
F Int = Int
F Bool = Bool
type instance where
F Int = Char
F Double = Double
```
Here is the output:
```
ghc: panic! (the 'impossible' happened)
(GHC version 7.7.20121221 for x86_64-apple-darwin):
conflictInstErr
<<details unavailable>>
```
Fix on the way...
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.7 |
| 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":"Panic in conflictInstErr when branched type family instances conflict","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"goldfire"},"version":"7.7","keywords":["TypeFamilies"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This code causes the panic:\r\n\r\n{{{\r\n{-# LANGUAGE TypeFamilies #-}\r\n\r\ntype family F a\r\n\r\ntype instance where\r\n F Int = Int\r\n F Bool = Bool\r\n\r\ntype instance where\r\n F Int = Char\r\n F Double = Double\r\n}}}\r\n\r\nHere is the output:\r\n{{{\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 7.7.20121221 for x86_64-apple-darwin):\r\n\tconflictInstErr\r\n<<details unavailable>>\r\n}}}\r\n\r\nFix on the way...","type_of_failure":"OtherFailure","blocking":[]} -->Richard Eisenbergrae@richarde.devRichard Eisenbergrae@richarde.dev