GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:37:40Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/10072Panic: generalised wildcards in RULES2019-07-07T18:37:40ZthomaswPanic: generalised wildcards in RULESGeneralised wildcards (PartialTypeSignatures) in the binder type annotation of a RULE cause panics.
Minimal example:
```hs
module WildcardInRuleBndrSig where
{-# RULES
"map/empty" forall (f :: a -> _). map f [] = []
#-}
```
Output:
...Generalised wildcards (PartialTypeSignatures) in the binder type annotation of a RULE cause panics.
Minimal example:
```hs
module WildcardInRuleBndrSig where
{-# RULES
"map/empty" forall (f :: a -> _). map f [] = []
#-}
```
Output:
```
WildcardInRuleBndrSig.hs:3:31:ghc-stage1: panic! (the 'impossible' happened)
(GHC version 7.11.20150209 for x86_64-unknown-linux):
No skolem info: w__alY[sk]
```
When a wildcard is generalised over, the error message reporting the inferred type gives some extra info about the type variables occurring in the inferred type. This extra information is retrieved by looking up the skolem information (`getSkolemInfo`) for the type variables in the enclosing implications (`cec_encl`). The problem is that there are no enclosing implications in this case, hence the panic.
Note that with the flags `-XPartialTypeSignatures` and `-fno-warn-partial-type-signatures` enabled, there is no panic, as no error/warning message is constructed.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.10.1-rc2 |
| 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":"Panic: generalised wildcards in RULES","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"thomasw"},"version":"7.10.1-rc2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Generalised wildcards (PartialTypeSignatures) in the binder type annotation of a RULE cause panics.\r\n\r\nMinimal example:\r\n{{{#!hs\r\nmodule WildcardInRuleBndrSig where\r\n{-# RULES\r\n\"map/empty\" forall (f :: a -> _). map f [] = []\r\n #-}\r\n}}}\r\n\r\nOutput:\r\n{{{\r\nWildcardInRuleBndrSig.hs:3:31:ghc-stage1: panic! (the 'impossible' happened)\r\n (GHC version 7.11.20150209 for x86_64-unknown-linux):\r\n\tNo skolem info: w__alY[sk]\r\n}}}\r\n\r\n\r\nWhen a wildcard is generalised over, the error message reporting the inferred type gives some extra info about the type variables occurring in the inferred type. This extra information is retrieved by looking up the skolem information (`getSkolemInfo`) for the type variables in the enclosing implications (`cec_encl`). The problem is that there are no enclosing implications in this case, hence the panic.\r\n\r\nNote that with the flags `-XPartialTypeSignatures` and `-fno-warn-partial-type-signatures` enabled, there is no panic, as no error/warning message is constructed.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1thomaswthomaswhttps://gitlab.haskell.org/ghc/ghc/-/issues/10031coerce can cause compiler to loop2019-07-07T18:37:51Zglguycoerce can cause compiler to loopThis program causes GHC to loop at compile time
```
{-# LANGUAGE ScopedTypeVariables #-}
import Data.Coerce
coerce' :: Coercible b a => a -> b
coerce' = coerce (\x -> x :: b) :: forall a b. Coercible b a => a -> b
```
I encountered thi...This program causes GHC to loop at compile time
```
{-# LANGUAGE ScopedTypeVariables #-}
import Data.Coerce
coerce' :: Coercible b a => a -> b
coerce' = coerce (\x -> x :: b) :: forall a b. Coercible b a => a -> b
```
I encountered this trying to use a similar construction in
https://github.com/glguy/profunctors/blob/coerce/src/Data/Profunctor/Unsafe.hs
I'm not absolutely certain about what aspect of this snippet is looping the compiler, but it's pretty small.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.1-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":"coerce can cause compiler to loop","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.1-rc1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This program causes GHC to loop at compile time\r\n\r\n{{{\r\n{-# LANGUAGE ScopedTypeVariables #-}\r\nimport Data.Coerce\r\ncoerce' :: Coercible b a => a -> b\r\ncoerce' = coerce (\\x -> x :: b) :: forall a b. Coercible b a => a -> b\r\n}}}\r\n\r\nI encountered this trying to use a similar construction in\r\n\r\nhttps://github.com/glguy/profunctors/blob/coerce/src/Data/Profunctor/Unsafe.hs\r\n\r\nI'm not absolutely certain about what aspect of this snippet is looping the compiler, but it's pretty small.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1Richard Eisenbergrae@richarde.devRichard Eisenbergrae@richarde.devhttps://gitlab.haskell.org/ghc/ghc/-/issues/9975RecordWildcards and PatternSynonyms cause impossible bug2021-05-17T16:05:16ZgamegoblinRecordWildcards and PatternSynonyms cause impossible bugWhen using RecordWildcards with PatternSynonyms, I have found a way to cause this bug:
```
$ /usr/local/bin/ghc-7.10.0.20141222 test.hs
[1 of 1] Compiling Main ( test.hs, test.o )
ghc: panic! (the 'impossible' happened)
(...When using RecordWildcards with PatternSynonyms, I have found a way to cause this bug:
```
$ /usr/local/bin/ghc-7.10.0.20141222 test.hs
[1 of 1] Compiling Main ( test.hs, test.o )
ghc: panic! (the 'impossible' happened)
(GHC version 7.10.0.20141222 for x86_64-apple-darwin):
find_tycon
Test
[Test defined at test.hs:6:9,
Test parent:Test defined at test.hs:4:13]
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
Here is the full code that causes it:
```hs
{-# LANGUAGE RecordWildCards #-}
{-# LANGUAGE PatternSynonyms #-}
data Test = Test { x :: Int }
pattern Test wat = Test { x = wat }
```
If you remove `RecordWildCards`, the bug does not happen.7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/9971GHC 7.10 dies with "out of memory"2019-07-07T18:38:09ZalbertovGHC 7.10 dies with "out of memory"I'm trying to build my [library](https://github.com/meteogrid/sigym4-geometry) with `cabal 1.22` and `ghc-7.10.0.20141222` but it ultimately crashes with `ghc: out of memory (requested 2097152 bytes)`. The VM I've used to build it has 8g...I'm trying to build my [library](https://github.com/meteogrid/sigym4-geometry) with `cabal 1.22` and `ghc-7.10.0.20141222` but it ultimately crashes with `ghc: out of memory (requested 2097152 bytes)`. The VM I've used to build it has 8gb of RAM. The same library compiles fine with `ghc 7.8.3` so I guess it is a GHC bug.
Unfortunately I'm not able to reduce it to a simple case or relate it to a previous bug. The build log can be seen at [travis-ci](https://travis-ci.org/meteogrid/sigym4-geometry/builds/46370766) and the source code is freely available so it should be easy to reproduce
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.1-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 7.10 dies with \"out of memory\"","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.1-rc1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I'm trying to build my [https://github.com/meteogrid/sigym4-geometry library] with `cabal 1.22` and `ghc-7.10.0.20141222` but it ultimately crashes with `ghc: out of memory (requested 2097152 bytes)`. The VM I've used to build it has 8gb of RAM. The same library compiles fine with `ghc 7.8.3` so I guess it is a GHC bug.\r\n\r\nUnfortunately I'm not able to reduce it to a simple case or relate it to a previous bug. The build log can be seen at [https://travis-ci.org/meteogrid/sigym4-geometry/builds/46370766 travis-ci] and the source code is freely available so it should be easy to reproduce","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/9922Partial type signatures + extensions panic2019-07-07T18:38:26ZKrzysztof GogolewskiPartial type signatures + extensions panicPartial type signatures combined with the following GHC extensions cause a panic:
```hs
class C a where default f :: _ -- DefaultSignatures
instance Num Bool where negate :: _ -- InstanceSigs
deriving instance _ ...Partial type signatures combined with the following GHC extensions cause a panic:
```hs
class C a where default f :: _ -- DefaultSignatures
instance Num Bool where negate :: _ -- InstanceSigs
deriving instance _ -- StandaloneDeriving
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.9 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | thomasw |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Partial type signatures + extensions panic","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.9","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["thomasw"],"type":"Bug","description":"Partial type signatures combined with the following GHC extensions cause a panic:\r\n\r\n{{{#!hs\r\nclass C a where default f :: _ -- DefaultSignatures\r\n\r\ninstance Num Bool where negate :: _ -- InstanceSigs\r\n\r\nderiving instance _ -- StandaloneDeriving\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1thomaswthomaswhttps://gitlab.haskell.org/ghc/ghc/-/issues/9857GHC 7.9 panics (simplifier ticks exhausted) on `half-0.2`2019-07-07T18:38:44ZHerbert Valerio Riedelhvr@gnu.orgGHC 7.9 panics (simplifier ticks exhausted) on `half-0.2`Compiling hackage:half-0.2 results in a GHC Panic:
```
$ ghc --version && ghc --print-project-git-commit-id
The Glorious Glasgow Haskell Compilation System, version 7.9.20141202
bf2d75417b5be7e8a79a26ee57a81e00682dabd4
$ cabal get half...Compiling hackage:half-0.2 results in a GHC Panic:
```
$ ghc --version && ghc --print-project-git-commit-id
The Glorious Glasgow Haskell Compilation System, version 7.9.20141202
bf2d75417b5be7e8a79a26ee57a81e00682dabd4
$ cabal get half-0.2 && cd half-0.2/src/Numeric/
Unpacking to half-0.2/
$ ghc -Wall -O -fforce-recomp -c Half.hs
ghc: panic! (the 'impossible' happened)
(GHC version 7.9.20141202 for x86_64-unknown-linux):
Simplifier ticks exhausted
When trying UnfoldingDone lvl_s5yo
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: 125160
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.9 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ekmett |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC 7.9 panics (simplifier ticks exhausted) on `half-0.2`","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"simonpj"},"version":"7.9","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ekmett"],"type":"Bug","description":"Compiling hackage:half-0.2 results in a GHC Panic:\r\n\r\n{{{\r\n$ ghc --version && ghc --print-project-git-commit-id\r\nThe Glorious Glasgow Haskell Compilation System, version 7.9.20141202\r\nbf2d75417b5be7e8a79a26ee57a81e00682dabd4\r\n\r\n$ cabal get half-0.2 && cd half-0.2/src/Numeric/\r\nUnpacking to half-0.2/\r\n\r\n$ ghc -Wall -O -fforce-recomp -c Half.hs \r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 7.9.20141202 for x86_64-unknown-linux):\r\n\tSimplifier ticks exhausted\r\n When trying UnfoldingDone lvl_s5yo\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: 125160\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":[]} -->7.10.1Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/9732Pattern synonyms and unboxed values2019-07-07T18:39:17ZKrzysztof GogolewskiPattern synonyms and unboxed valuesIt's possible to declare a toplevel unboxed value with a pattern synonym, which causes a panic:
```
{-# LANGUAGE PatternSynonyms, MagicHash #-}
pattern P = 0#
```
(compare with error on `x = 0#`). `pattern P <- 0#` seems to work fine.It's possible to declare a toplevel unboxed value with a pattern synonym, which causes a panic:
```
{-# LANGUAGE PatternSynonyms, MagicHash #-}
pattern P = 0#
```
(compare with error on `x = 0#`). `pattern P <- 0#` seems to work fine.7.10.1Gergő ÉrdiGergő Érdihttps://gitlab.haskell.org/ghc/ghc/-/issues/9662stack overflow in type checker2019-07-07T18:39:36ZLemmingstack overflow in type checkerThe attached program causes a stack overflow when loading into ghci-7.8.3 or ghci-7.9.20140929:
```
$ ghci-7.8.3 -Wall BackpermuteTypeLoop.hs
GHCi, version 7.8.3: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... lin...The attached program causes a stack overflow when loading into ghci-7.8.3 or ghci-7.9.20140929:
```
$ ghci-7.8.3 -Wall BackpermuteTypeLoop.hs
GHCi, version 7.8.3: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
[1 of 1] Compiling BackpermuteTypeLoop ( BackpermuteTypeLoop.hs, interpreted )
*** Exception: stack overflow
```
I have no idea, what's going on. The problem may be even not critical, because the program is not type-correct anyway. If you replace the `id` argument by the out-commented `modify` argument, you will get a nice type error message.
The problem arised when using the Accelerate framework and it involves the `modify` function which helps tupling function arguments and untupling function results.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.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":"stack overflow in type checker","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The attached program causes a stack overflow when loading into ghci-7.8.3 or ghci-7.9.20140929:\r\n\r\n{{{\r\n$ ghci-7.8.3 -Wall BackpermuteTypeLoop.hs\r\nGHCi, version 7.8.3: http://www.haskell.org/ghc/ :? for help\r\nLoading package ghc-prim ... linking ... done.\r\nLoading package integer-gmp ... linking ... done.\r\nLoading package base ... linking ... done.\r\n[1 of 1] Compiling BackpermuteTypeLoop ( BackpermuteTypeLoop.hs, interpreted )\r\n*** Exception: stack overflow\r\n}}}\r\n\r\nI have no idea, what's going on. The problem may be even not critical, because the program is not type-correct anyway. If you replace the `id` argument by the out-commented `modify` argument, you will get a nice type error message.\r\n\r\nThe problem arised when using the Accelerate framework and it involves the `modify` function which helps tupling function arguments and untupling function results.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/9189Linking fails on OSX when -staticlib and -threaded are enabled2019-07-07T18:41:28ZfrodeLinking fails on OSX when -staticlib and -threaded are enabledI'm trying to build a library with ffi exported functions to be called from ObjectiveC in an Xcode project on OSX. With just -staticlib it works, but when I add -threaded as well I get a linker error saying that it cannot find pthread. T...I'm trying to build a library with ffi exported functions to be called from ObjectiveC in an Xcode project on OSX. With just -staticlib it works, but when I add -threaded as well I get a linker error saying that it cannot find pthread. This happens even with a trivial program:
```
Test.hs:
module Test where
main :: IO ()
main = putStrLn "Hello"
```
```
$ ghc Test.hs -staticlib -threaded
[1 of 1] Compiling Test ( Test.hs, Test.o )
Linking liba.a ...
error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool: can't locate file for: -lpthread
error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool: file: -lpthread is not an object file (not allowed in a library)
```
The linker command that fails:
```
*** Linker:
libtool -static -o liba.a Test.o -L/usr/local/lib/ghc-7.8.2/base-4.7.0.0 -L/usr/local/lib/ghc-7.8.2/integer-gmp-0.5.1.0 -L/usr/local/lib/ghc-7.8.2/ghc-prim-0.3.1.0 -L/usr/local/lib/ghc-7.8.2/rts-1.0 /var/folders/jc/3pqglx_x3z9dk3gnxgh56tv80000gp/T/ghc26454_0/ghc26454_3.o -lHSbase-4.7.0.0 -lHSinteger-gmp-0.5.1.0 -lHSghc-prim-0.3.1.0 -lHSrts_thr -lCffi -lpthread
```
If I make a script that removes the -lpthread argument, it links ok and the project works with multiple threads calling my ffi-functions simultaneously.
It was suggested by Bob on Haskell Cafe that it should not link against libpthread on OSX since it is included in libSystem (like IOS): https://groups.google.com/d/msg/haskell-cafe/GGEkifs_-uY/uzHeV-Z2E2YJ
https://github.com/ghc/ghc/blob/master/compiler/main/DriverPipeline.hs\#L1869-L1873
OSX version 10.9.3
Verbose output:
```
$ ghc Test.hs -staticlib -threaded -v
Glasgow Haskell Compiler, Version 7.8.2, stage 2 booted by GHC version 7.6.3
Using binary package database: /usr/local/lib/ghc-7.8.2/package.conf.d/package.cache
Using binary package database: /Users/frode/.ghc/x86_64-darwin-7.8.2/package.conf.d/package.cache
hiding package Cabal-1.18.1.3 to avoid conflict with later version Cabal-1.20.0.0
hiding package hoauth2-0.3.6.2 to avoid conflict with later version hoauth2-0.3.7
hiding package hoauth2-0.3.6.1 to avoid conflict with later version hoauth2-0.3.7
wired-in package ghc-prim mapped to ghc-prim-0.3.1.0-948744e1f99cc8bcc7c7d3ba60c7c2d8
wired-in package integer-gmp mapped to integer-gmp-0.5.1.0-dc47f6b546fc171f67a7f7d311684a99
wired-in package base mapped to base-4.7.0.0-a333addb6892f3cc2e6baa5ec782bd04
wired-in package rts mapped to builtin_rts
wired-in package template-haskell mapped to template-haskell-2.9.0.0-ed6ecfb467e6936688bb20f968f702e1
wired-in package dph-seq not found.
wired-in package dph-par not found.
Hsc static flags:
hiding package Cabal-1.18.1.3 to avoid conflict with later version Cabal-1.20.0.0
hiding package hoauth2-0.3.6.2 to avoid conflict with later version hoauth2-0.3.7
hiding package hoauth2-0.3.6.1 to avoid conflict with later version hoauth2-0.3.7
wired-in package ghc-prim mapped to ghc-prim-0.3.1.0-948744e1f99cc8bcc7c7d3ba60c7c2d8
wired-in package integer-gmp mapped to integer-gmp-0.5.1.0-dc47f6b546fc171f67a7f7d311684a99
wired-in package base mapped to base-4.7.0.0-a333addb6892f3cc2e6baa5ec782bd04
wired-in package rts mapped to builtin_rts
wired-in package template-haskell mapped to template-haskell-2.9.0.0-ed6ecfb467e6936688bb20f968f702e1
wired-in package dph-seq not found.
wired-in package dph-par not found.
*** Chasing dependencies:
Chasing modules from: *Test.hs
Stable obj: [Test]
Stable BCO: []
Ready for upsweep
[NONREC
ModSummary {
ms_hs_date = 2014-06-10 10:02:41 UTC
ms_mod = main:Test,
ms_textual_imps = [import (implicit) Prelude]
ms_srcimps = []
}]
*** Deleting temp files:
Deleting:
compile: input file Test.hs
Created temporary directory: /var/folders/jc/3pqglx_x3z9dk3gnxgh56tv80000gp/T/ghc26454_0
*** Checking old interface for main:Test:
[1 of 1] Skipping Test ( Test.hs, Test.o )
Upsweep completely successful.
*** Deleting temp files:
Deleting: /var/folders/jc/3pqglx_x3z9dk3gnxgh56tv80000gp/T/ghc26454_0/ghc26454_1.s
Warning: deleting non-existent /var/folders/jc/3pqglx_x3z9dk3gnxgh56tv80000gp/T/ghc26454_0/ghc26454_1.s
link: linkables are ...
LinkableM (2014-06-10 10:02:55 UTC) main:Test
[DotO Test.o]
Linking liba.a ...
*** C Compiler:
/usr/bin/gcc -m64 -fno-stack-protector -DTABLES_NEXT_TO_CODE -c /var/folders/jc/3pqglx_x3z9dk3gnxgh56tv80000gp/T/ghc26454_0/ghc26454_2.c -o /var/folders/jc/3pqglx_x3z9dk3gnxgh56tv80000gp/T/ghc26454_0/ghc26454_3.o -I/usr/local/lib/ghc-7.8.2/include
*** Linker:
libtool -static -o liba.a Test.o -L/usr/local/lib/ghc-7.8.2/base-4.7.0.0 -L/usr/local/lib/ghc-7.8.2/integer-gmp-0.5.1.0 -L/usr/local/lib/ghc-7.8.2/ghc-prim-0.3.1.0 -L/usr/local/lib/ghc-7.8.2/rts-1.0 /var/folders/jc/3pqglx_x3z9dk3gnxgh56tv80000gp/T/ghc26454_0/ghc26454_3.o -lHSbase-4.7.0.0 -lHSinteger-gmp-0.5.1.0 -lHSghc-prim-0.3.1.0 -lHSrts_thr -lCffi -lpthread
error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool: can't locate file for: -lpthread
error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool: file: -lpthread is not an object file (not allowed in a library)
*** Deleting temp files:
Deleting: /var/folders/jc/3pqglx_x3z9dk3gnxgh56tv80000gp/T/ghc26454_0/ghc26454_3.o /var/folders/jc/3pqglx_x3z9dk3gnxgh56tv80000gp/T/ghc26454_0/ghc26454_2.c
*** Deleting temp dirs:
Deleting: /var/folders/jc/3pqglx_x3z9dk3gnxgh56tv80000gp/T/ghc26454_0
```
<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":"Linking fails on OSX when -staticlib and -threaded are enabled","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.2","keywords":["pthread","staticlib","threaded"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I'm trying to build a library with ffi exported functions to be called from ObjectiveC in an Xcode project on OSX. With just -staticlib it works, but when I add -threaded as well I get a linker error saying that it cannot find pthread. This happens even with a trivial program:\r\n\r\n\r\n{{{\r\nTest.hs:\r\nmodule Test where\r\nmain :: IO ()\r\nmain = putStrLn \"Hello\"\r\n}}}\r\n\r\n\r\n{{{\r\n$ ghc Test.hs -staticlib -threaded\r\n[1 of 1] Compiling Test ( Test.hs, Test.o )\r\nLinking liba.a ...\r\nerror: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool: can't locate file for: -lpthread\r\nerror: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool: file: -lpthread is not an object file (not allowed in a library)\r\n}}}\r\n\r\nThe linker command that fails:\r\n\r\n{{{\r\n*** Linker:\r\nlibtool -static -o liba.a Test.o -L/usr/local/lib/ghc-7.8.2/base-4.7.0.0 -L/usr/local/lib/ghc-7.8.2/integer-gmp-0.5.1.0 -L/usr/local/lib/ghc-7.8.2/ghc-prim-0.3.1.0 -L/usr/local/lib/ghc-7.8.2/rts-1.0 /var/folders/jc/3pqglx_x3z9dk3gnxgh56tv80000gp/T/ghc26454_0/ghc26454_3.o -lHSbase-4.7.0.0 -lHSinteger-gmp-0.5.1.0 -lHSghc-prim-0.3.1.0 -lHSrts_thr -lCffi -lpthread\r\n}}}\r\n\r\nIf I make a script that removes the -lpthread argument, it links ok and the project works with multiple threads calling my ffi-functions simultaneously.\r\n\r\nIt was suggested by Bob on Haskell Cafe that it should not link against libpthread on OSX since it is included in libSystem (like IOS): https://groups.google.com/d/msg/haskell-cafe/GGEkifs_-uY/uzHeV-Z2E2YJ \r\n\r\nhttps://github.com/ghc/ghc/blob/master/compiler/main/DriverPipeline.hs#L1869-L1873\r\n\r\n\r\nOSX version 10.9.3\r\nVerbose output:\r\n\r\n{{{\r\n$ ghc Test.hs -staticlib -threaded -v\r\nGlasgow Haskell Compiler, Version 7.8.2, stage 2 booted by GHC version 7.6.3\r\nUsing binary package database: /usr/local/lib/ghc-7.8.2/package.conf.d/package.cache\r\nUsing binary package database: /Users/frode/.ghc/x86_64-darwin-7.8.2/package.conf.d/package.cache\r\nhiding package Cabal-1.18.1.3 to avoid conflict with later version Cabal-1.20.0.0\r\nhiding package hoauth2-0.3.6.2 to avoid conflict with later version hoauth2-0.3.7\r\nhiding package hoauth2-0.3.6.1 to avoid conflict with later version hoauth2-0.3.7\r\nwired-in package ghc-prim mapped to ghc-prim-0.3.1.0-948744e1f99cc8bcc7c7d3ba60c7c2d8\r\nwired-in package integer-gmp mapped to integer-gmp-0.5.1.0-dc47f6b546fc171f67a7f7d311684a99\r\nwired-in package base mapped to base-4.7.0.0-a333addb6892f3cc2e6baa5ec782bd04\r\nwired-in package rts mapped to builtin_rts\r\nwired-in package template-haskell mapped to template-haskell-2.9.0.0-ed6ecfb467e6936688bb20f968f702e1\r\nwired-in package dph-seq not found.\r\nwired-in package dph-par not found.\r\nHsc static flags:\r\nhiding package Cabal-1.18.1.3 to avoid conflict with later version Cabal-1.20.0.0\r\nhiding package hoauth2-0.3.6.2 to avoid conflict with later version hoauth2-0.3.7\r\nhiding package hoauth2-0.3.6.1 to avoid conflict with later version hoauth2-0.3.7\r\nwired-in package ghc-prim mapped to ghc-prim-0.3.1.0-948744e1f99cc8bcc7c7d3ba60c7c2d8\r\nwired-in package integer-gmp mapped to integer-gmp-0.5.1.0-dc47f6b546fc171f67a7f7d311684a99\r\nwired-in package base mapped to base-4.7.0.0-a333addb6892f3cc2e6baa5ec782bd04\r\nwired-in package rts mapped to builtin_rts\r\nwired-in package template-haskell mapped to template-haskell-2.9.0.0-ed6ecfb467e6936688bb20f968f702e1\r\nwired-in package dph-seq not found.\r\nwired-in package dph-par not found.\r\n*** Chasing dependencies:\r\nChasing modules from: *Test.hs\r\nStable obj: [Test]\r\nStable BCO: []\r\nReady for upsweep\r\n [NONREC\r\n ModSummary {\r\n ms_hs_date = 2014-06-10 10:02:41 UTC\r\n ms_mod = main:Test,\r\n ms_textual_imps = [import (implicit) Prelude]\r\n ms_srcimps = []\r\n }]\r\n*** Deleting temp files:\r\nDeleting:\r\ncompile: input file Test.hs\r\nCreated temporary directory: /var/folders/jc/3pqglx_x3z9dk3gnxgh56tv80000gp/T/ghc26454_0\r\n*** Checking old interface for main:Test:\r\n[1 of 1] Skipping Test ( Test.hs, Test.o )\r\nUpsweep completely successful.\r\n*** Deleting temp files:\r\nDeleting: /var/folders/jc/3pqglx_x3z9dk3gnxgh56tv80000gp/T/ghc26454_0/ghc26454_1.s\r\nWarning: deleting non-existent /var/folders/jc/3pqglx_x3z9dk3gnxgh56tv80000gp/T/ghc26454_0/ghc26454_1.s\r\nlink: linkables are ...\r\nLinkableM (2014-06-10 10:02:55 UTC) main:Test\r\n [DotO Test.o]\r\nLinking liba.a ...\r\n*** C Compiler:\r\n/usr/bin/gcc -m64 -fno-stack-protector -DTABLES_NEXT_TO_CODE -c /var/folders/jc/3pqglx_x3z9dk3gnxgh56tv80000gp/T/ghc26454_0/ghc26454_2.c -o /var/folders/jc/3pqglx_x3z9dk3gnxgh56tv80000gp/T/ghc26454_0/ghc26454_3.o -I/usr/local/lib/ghc-7.8.2/include\r\n*** Linker:\r\nlibtool -static -o liba.a Test.o -L/usr/local/lib/ghc-7.8.2/base-4.7.0.0 -L/usr/local/lib/ghc-7.8.2/integer-gmp-0.5.1.0 -L/usr/local/lib/ghc-7.8.2/ghc-prim-0.3.1.0 -L/usr/local/lib/ghc-7.8.2/rts-1.0 /var/folders/jc/3pqglx_x3z9dk3gnxgh56tv80000gp/T/ghc26454_0/ghc26454_3.o -lHSbase-4.7.0.0 -lHSinteger-gmp-0.5.1.0 -lHSghc-prim-0.3.1.0 -lHSrts_thr -lCffi -lpthread\r\nerror: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool: can't locate file for: -lpthread\r\nerror: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool: file: -lpthread is not an object file (not allowed in a library)\r\n*** Deleting temp files:\r\nDeleting: /var/folders/jc/3pqglx_x3z9dk3gnxgh56tv80000gp/T/ghc26454_0/ghc26454_3.o /var/folders/jc/3pqglx_x3z9dk3gnxgh56tv80000gp/T/ghc26454_0/ghc26454_2.c\r\n*** Deleting temp dirs:\r\nDeleting: /var/folders/jc/3pqglx_x3z9dk3gnxgh56tv80000gp/T/ghc26454_0\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/9100Cannot build crypto-pubkey with GHC 7.8.2 and profiling2019-07-07T18:41:55ZJohnWiegleyCannot build crypto-pubkey with GHC 7.8.2 and profilingI configure crypto-pubkey with:
```
configure flags: --disable-split-objs --enable-library-profiling --enable-shared --enable-library-vanilla --enable-executable-dynamic --enable-tests
```
And on building get:
```
Building crypto-pubk...I configure crypto-pubkey with:
```
configure flags: --disable-split-objs --enable-library-profiling --enable-shared --enable-library-vanilla --enable-executable-dynamic --enable-tests
```
And on building get:
```
Building crypto-pubkey-0.2.4...
Preprocessing library crypto-pubkey-0.2.4...
[ 1 of 15] Compiling Crypto.PubKey.ECC.Prim ( Crypto/PubKey/ECC/Prim.hs, dist/build/Crypto/PubKey/ECC/Prim.o )
ghc: panic! (the 'impossible' happened)
(GHC version 7.8.2 for x86_64-apple-darwin):
Ix{Int}.index: Index (75497475) out of range ((0,1333))
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Running Haddock for crypto-pubkey-0.2.4...
Preprocessing library crypto-pubkey-0.2.4...
Haddock coverage:
haddock: internal error: Ix{Int}.index: Index (75497475) out of range ((0,1333))
```
If I disable library profiling, it builds cleanly:
```
Building crypto-pubkey-0.2.4...
Preprocessing library crypto-pubkey-0.2.4...
[ 1 of 15] Compiling Crypto.PubKey.ECC.Prim ( Crypto/PubKey/ECC/Prim.hs, dist/build/Crypto/PubKey/ECC/Prim.o )
[ 2 of 15] Compiling Crypto.PubKey.ECC.Generate ( Crypto/PubKey/ECC/Generate.hs, dist/build/Crypto/PubKey/ECC/Generate.o )
[ 3 of 15] Compiling Crypto.PubKey.DH ( Crypto/PubKey/DH.hs, dist/build/Crypto/PubKey/DH.o )
[ 4 of 15] Compiling Crypto.PubKey.HashDescr ( Crypto/PubKey/HashDescr.hs, dist/build/Crypto/PubKey/HashDescr.o )
[ 5 of 15] Compiling Crypto.PubKey.MaskGenFunction ( Crypto/PubKey/MaskGenFunction.hs, dist/build/Crypto/PubKey/MaskGenFunction.o )
[ 6 of 15] Compiling Crypto.PubKey.DSA ( Crypto/PubKey/DSA.hs, dist/build/Crypto/PubKey/DSA.o )
[ 7 of 15] Compiling Crypto.PubKey.ECC.ECDSA ( Crypto/PubKey/ECC/ECDSA.hs, dist/build/Crypto/PubKey/ECC/ECDSA.o )
[ 8 of 15] Compiling Crypto.PubKey.ElGamal ( Crypto/PubKey/ElGamal.hs, dist/build/Crypto/PubKey/ElGamal.o )
[ 9 of 15] Compiling Crypto.PubKey.Internal ( Crypto/PubKey/Internal.hs, dist/build/Crypto/PubKey/Internal.o )
[10 of 15] Compiling Crypto.PubKey.RSA.Types ( Crypto/PubKey/RSA/Types.hs, dist/build/Crypto/PubKey/RSA/Types.o )
[11 of 15] Compiling Crypto.PubKey.RSA.Prim ( Crypto/PubKey/RSA/Prim.hs, dist/build/Crypto/PubKey/RSA/Prim.o )
[12 of 15] Compiling Crypto.PubKey.RSA ( Crypto/PubKey/RSA.hs, dist/build/Crypto/PubKey/RSA.o )
[13 of 15] Compiling Crypto.PubKey.RSA.PKCS15 ( Crypto/PubKey/RSA/PKCS15.hs, dist/build/Crypto/PubKey/RSA/PKCS15.o )
[14 of 15] Compiling Crypto.PubKey.RSA.OAEP ( Crypto/PubKey/RSA/OAEP.hs, dist/build/Crypto/PubKey/RSA/OAEP.o )
[15 of 15] Compiling Crypto.PubKey.RSA.PSS ( Crypto/PubKey/RSA/PSS.hs, dist/build/Crypto/PubKey/RSA/PSS.o )
In-place registering crypto-pubkey-0.2.4...
```
<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":"Cannot build crypto-pubkey with GHC 7.8.2 and profiling","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"7.8.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I configure crypto-pubkey with:\r\n\r\n{{{\r\nconfigure flags: --disable-split-objs --enable-library-profiling --enable-shared --enable-library-vanilla --enable-executable-dynamic --enable-tests\r\n}}}\r\n\r\nAnd on building get:\r\n\r\n{{{\r\nBuilding crypto-pubkey-0.2.4...\r\nPreprocessing library crypto-pubkey-0.2.4...\r\n[ 1 of 15] Compiling Crypto.PubKey.ECC.Prim ( Crypto/PubKey/ECC/Prim.hs, dist/build/Crypto/PubKey/ECC/Prim.o )\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 7.8.2 for x86_64-apple-darwin):\r\n\tIx{Int}.index: Index (75497475) out of range ((0,1333))\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\nRunning Haddock for crypto-pubkey-0.2.4...\r\nPreprocessing library crypto-pubkey-0.2.4...\r\nHaddock coverage:\r\nhaddock: internal error: Ix{Int}.index: Index (75497475) out of range ((0,1333))\r\n}}}\r\n\r\nIf I disable library profiling, it builds cleanly:\r\n\r\n{{{\r\nBuilding crypto-pubkey-0.2.4...\r\nPreprocessing library crypto-pubkey-0.2.4...\r\n[ 1 of 15] Compiling Crypto.PubKey.ECC.Prim ( Crypto/PubKey/ECC/Prim.hs, dist/build/Crypto/PubKey/ECC/Prim.o )\r\n[ 2 of 15] Compiling Crypto.PubKey.ECC.Generate ( Crypto/PubKey/ECC/Generate.hs, dist/build/Crypto/PubKey/ECC/Generate.o )\r\n[ 3 of 15] Compiling Crypto.PubKey.DH ( Crypto/PubKey/DH.hs, dist/build/Crypto/PubKey/DH.o )\r\n[ 4 of 15] Compiling Crypto.PubKey.HashDescr ( Crypto/PubKey/HashDescr.hs, dist/build/Crypto/PubKey/HashDescr.o )\r\n[ 5 of 15] Compiling Crypto.PubKey.MaskGenFunction ( Crypto/PubKey/MaskGenFunction.hs, dist/build/Crypto/PubKey/MaskGenFunction.o )\r\n[ 6 of 15] Compiling Crypto.PubKey.DSA ( Crypto/PubKey/DSA.hs, dist/build/Crypto/PubKey/DSA.o )\r\n[ 7 of 15] Compiling Crypto.PubKey.ECC.ECDSA ( Crypto/PubKey/ECC/ECDSA.hs, dist/build/Crypto/PubKey/ECC/ECDSA.o )\r\n[ 8 of 15] Compiling Crypto.PubKey.ElGamal ( Crypto/PubKey/ElGamal.hs, dist/build/Crypto/PubKey/ElGamal.o )\r\n[ 9 of 15] Compiling Crypto.PubKey.Internal ( Crypto/PubKey/Internal.hs, dist/build/Crypto/PubKey/Internal.o )\r\n[10 of 15] Compiling Crypto.PubKey.RSA.Types ( Crypto/PubKey/RSA/Types.hs, dist/build/Crypto/PubKey/RSA/Types.o )\r\n[11 of 15] Compiling Crypto.PubKey.RSA.Prim ( Crypto/PubKey/RSA/Prim.hs, dist/build/Crypto/PubKey/RSA/Prim.o )\r\n[12 of 15] Compiling Crypto.PubKey.RSA ( Crypto/PubKey/RSA.hs, dist/build/Crypto/PubKey/RSA.o )\r\n[13 of 15] Compiling Crypto.PubKey.RSA.PKCS15 ( Crypto/PubKey/RSA/PKCS15.hs, dist/build/Crypto/PubKey/RSA/PKCS15.o )\r\n[14 of 15] Compiling Crypto.PubKey.RSA.OAEP ( Crypto/PubKey/RSA/OAEP.hs, dist/build/Crypto/PubKey/RSA/OAEP.o )\r\n[15 of 15] Compiling Crypto.PubKey.RSA.PSS ( Crypto/PubKey/RSA/PSS.hs, dist/build/Crypto/PubKey/RSA/PSS.o )\r\nIn-place registering crypto-pubkey-0.2.4...\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/9092ghc: panic! (the 'impossible' happened)2019-07-07T18:41:57ZSacha Sokoloskighc: panic! (the 'impossible' happened)I'm not sure \*why\* this is happening, but I know where. The code for this library is available here: http://hub.darcs.net/alex404/hsl-random
So as is, I can run the script called multivariate and get the expected results, but when I t...I'm not sure \*why\* this is happening, but I know where. The code for this library is available here: http://hub.darcs.net/alex404/hsl-random
So as is, I can run the script called multivariate and get the expected results, but when I try to compile I get
ghc: panic! (the 'impossible' happened)
> (GHC version 7.8.2 for x86_64-unknown-linux):
attempt to prod-split usage call demand C(C1(U(U,U,U,U,U,U)))
If at line 317 in Scientific.Random.Distributions.hs, I replace the statement sgma = ... with sgma = undefined, the code will compile, though obviously it cannot be used. If I transform the code in other ways which are meant to preserve the results, I can get it to compile, but then the script hangs.
<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":"ghc: panic! (the 'impossible' happened)","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.2","keywords":["impossible","panic"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I'm not sure *why* this is happening, but I know where. The code for this library is available here: http://hub.darcs.net/alex404/hsl-random\r\n\r\nSo as is, I can run the script called multivariate and get the expected results, but when I try to compile I get \r\n\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 7.8.2 for x86_64-unknown-linux):\r\n\tattempt to prod-split usage call demand C(C1(U(U,U,U,U,U,U)))\r\n\r\nIf at line 317 in Scientific.Random.Distributions.hs, I replace the statement sgma = ... with sgma = undefined, the code will compile, though obviously it cannot be used. If I transform the code in other ways which are meant to preserve the results, I can get it to compile, but then the script hangs.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/9055unregisterised build fails with: globalRegMaybe not defined for this platform2019-07-07T18:42:07ZPeter Trommlerptrommler@acm.orgunregisterised build fails with: globalRegMaybe not defined for this platformBuilding HEAD fails with:
```
make[1]: *** [rts/dist/build/Updates.o] Error 1
ghc-stage1: panic! (the 'impossible' happened)
(GHC version 7.9.20140429 for powerpc64-unknown-linux):
globalRegMaybe not defined for this platform
...Building HEAD fails with:
```
make[1]: *** [rts/dist/build/Updates.o] Error 1
ghc-stage1: panic! (the 'impossible' happened)
(GHC version 7.9.20140429 for powerpc64-unknown-linux):
globalRegMaybe not defined for this platform
```
on Linux powerpc64 and x86_64 (unregisterised).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.9 |
| 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":"unregisterised build fails with: globalRegMaybe not defined for this platform","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.9","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Building HEAD fails with:\r\n{{{\r\nmake[1]: *** [rts/dist/build/Updates.o] Error 1\r\nghc-stage1: panic! (the 'impossible' happened)\r\n (GHC version 7.9.20140429 for powerpc64-unknown-linux):\r\n globalRegMaybe not defined for this platform\r\n}}}\r\non Linux powerpc64 and x86_64 (unregisterised).\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/9032Panic with self-import2019-07-07T18:42:13ZJan Stolarekjan.stolarek@ed.ac.ukPanic with self-importA test in the `singletons` package leads to a panic when run:
```
ghc: panic! (the 'impossible' happened)
(GHC version 7.8.2 for x86_64-unknown-linux):
tcIfaceGlobal (local): not found:
singletons-1.0:Singletons.Star.TFCo:...A test in the `singletons` package leads to a panic when run:
```
ghc: panic! (the 'impossible' happened)
(GHC version 7.8.2 for x86_64-unknown-linux):
tcIfaceGlobal (local): not found:
singletons-1.0:Singletons.Star.TFCo:R:DemoteRep*KProxy{tc r0}
[]
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
Edit: see [ticket:9032\#comment:83149](https://gitlab.haskell.org//ghc/ghc/issues/9032#note_83149) for a testcase.7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/8546Panic during cabal build with profiling enabled.2019-07-07T18:44:34ZMokoshaPanic during cabal build with profiling enabled.I had been recently using cabal-dev for my development work. Someone suggested I switch over to the new cabal 1.18 on \#haskell. After doing so, some projects do not seem to build anymore. I'm not an experienced Haskell developer, so I'm...I had been recently using cabal-dev for my development work. Someone suggested I switch over to the new cabal 1.18 on \#haskell. After doing so, some projects do not seem to build anymore. I'm not an experienced Haskell developer, so I'm not sure how to go about debugging such a problem. I've included the output of the install command.
```
Pavel@ZOMBIE-POWER ~/Projects/Lambency/src
$ cabal install -p
Resolving dependencies...
Configuring bindings-GLFW-3.0.3.1...
Building bindings-GLFW-3.0.3.1...
Preprocessing library bindings-GLFW-3.0.3.1...
[1 of 1] Compiling Bindings.GLFW ( dist\dist-sandbox-2b66993e\build\Bindings\GLFW.hs, dist\dist-sandbox-2b66993e\build\Bindings\GLFW.o )
[1 of 1] Compiling Bindings.GLFW ( dist\dist-sandbox-2b66993e\build\Bindings\GLFW.hs, dist\dist-sandbox-2b66993e\build\Bindings\GLFW.p_o )
In-place registering bindings-GLFW-3.0.3.1...
Installing library in
D:\MinGW\msys\1.0\home\Pavel\Projects\Lambency\build\i386-windows-ghc-7.6.3\bindings-GLFW-3.0.3.1
Registering bindings-GLFW-3.0.3.1...
Installed bindings-GLFW-3.0.3.1
Configuring GLFW-b-1.4.1...
Building GLFW-b-1.4.1...
Preprocessing library GLFW-b-1.4.1...
[1 of 3] Compiling Graphics.UI.GLFW.Types ( Graphics\UI\GLFW\Types.hs, dist\dist-sandbox-2b66993e\build\Graphics\UI\GLFW\Types.o )
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package bindings-DSL-1.0.20 ... linking ... done.
Loading package bindings-GLFW-3.0.3.1 ... ghc.exe: Unknown PEi386 section name `.drectve' (while processing: D:\MinGW\msys\1.0\home\Pavel\Projects\Lambency\build\i386-windows-ghc-7.6.3\bindings-GLFW-3
.0.3.1\libHSbindings-GLFW-3.0.3.1.a)
ghc.exe: panic! (the 'impossible' happened)
(GHC version 7.6.3 for i386-unknown-mingw32):
loadArchive "D:\\MinGW\\msys\\1.0\\home\\Pavel\\Projects\\Lambency\\build\\i386-windows-ghc-7.6.3\\bindings-GLFW-3.0.3.1\\libHSbindings-GLFW-3.0.3.1.a": failed
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Failed to install GLFW-b-1.4.1
cabal.exe: Error: some packages failed to install:
GLFW-b-1.4.1 failed during the building phase. The exception was:
ExitFailure 1
```
<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":"Panic during cabal build with profiling enabled.","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.3","keywords":["cabal","sandbox"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I had been recently using cabal-dev for my development work. Someone suggested I switch over to the new cabal 1.18 on #haskell. After doing so, some projects do not seem to build anymore. I'm not an experienced Haskell developer, so I'm not sure how to go about debugging such a problem. I've included the output of the install command.\r\n\r\n{{{\r\nPavel@ZOMBIE-POWER ~/Projects/Lambency/src\r\n$ cabal install -p\r\nResolving dependencies...\r\nConfiguring bindings-GLFW-3.0.3.1...\r\nBuilding bindings-GLFW-3.0.3.1...\r\nPreprocessing library bindings-GLFW-3.0.3.1...\r\n[1 of 1] Compiling Bindings.GLFW ( dist\\dist-sandbox-2b66993e\\build\\Bindings\\GLFW.hs, dist\\dist-sandbox-2b66993e\\build\\Bindings\\GLFW.o )\r\n[1 of 1] Compiling Bindings.GLFW ( dist\\dist-sandbox-2b66993e\\build\\Bindings\\GLFW.hs, dist\\dist-sandbox-2b66993e\\build\\Bindings\\GLFW.p_o )\r\nIn-place registering bindings-GLFW-3.0.3.1...\r\nInstalling library in\r\nD:\\MinGW\\msys\\1.0\\home\\Pavel\\Projects\\Lambency\\build\\i386-windows-ghc-7.6.3\\bindings-GLFW-3.0.3.1\r\nRegistering bindings-GLFW-3.0.3.1...\r\nInstalled bindings-GLFW-3.0.3.1\r\nConfiguring GLFW-b-1.4.1...\r\nBuilding GLFW-b-1.4.1...\r\nPreprocessing library GLFW-b-1.4.1...\r\n[1 of 3] Compiling Graphics.UI.GLFW.Types ( Graphics\\UI\\GLFW\\Types.hs, dist\\dist-sandbox-2b66993e\\build\\Graphics\\UI\\GLFW\\Types.o )\r\nLoading package ghc-prim ... linking ... done.\r\nLoading package integer-gmp ... linking ... done.\r\nLoading package base ... linking ... done.\r\nLoading package bindings-DSL-1.0.20 ... linking ... done.\r\nLoading package bindings-GLFW-3.0.3.1 ... ghc.exe: Unknown PEi386 section name `.drectve' (while processing: D:\\MinGW\\msys\\1.0\\home\\Pavel\\Projects\\Lambency\\build\\i386-windows-ghc-7.6.3\\bindings-GLFW-3\r\n.0.3.1\\libHSbindings-GLFW-3.0.3.1.a)\r\nghc.exe: panic! (the 'impossible' happened)\r\n (GHC version 7.6.3 for i386-unknown-mingw32):\r\n loadArchive \"D:\\\\MinGW\\\\msys\\\\1.0\\\\home\\\\Pavel\\\\Projects\\\\Lambency\\\\build\\\\i386-windows-ghc-7.6.3\\\\bindings-GLFW-3.0.3.1\\\\libHSbindings-GLFW-3.0.3.1.a\": failed\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\nFailed to install GLFW-b-1.4.1\r\ncabal.exe: Error: some packages failed to install:\r\nGLFW-b-1.4.1 failed during the building phase. The exception was:\r\nExitFailure 1\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/8013Strange closure type error building hs-kqueue on FreeBSD2019-07-07T18:46:50ZahktenzeroStrange closure type error building hs-kqueue on FreeBSDTrying to compile hs-kqueue on FreeBSD 9.1 from the port fails with the following error:
```
c2hs: internal error: evacuate(static): strange closure type -385875968
(GHC version 7.6.3 for x86_64_portbld_freebsd)
Please report th...Trying to compile hs-kqueue on FreeBSD 9.1 from the port fails with the following error:
```
c2hs: internal error: evacuate(static): strange closure type -385875968
(GHC version 7.6.3 for x86_64_portbld_freebsd)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
I've attached the full log from the build in case it's useful.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | --------------- |
| Version | 7.6.3 |
| 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":"Strange closure type error building hs-kqueue on FreeBSD","status":"New","operating_system":"","component":"Compiler (LLVM)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Trying to compile hs-kqueue on FreeBSD 9.1 from the port fails with the following error:\r\n\r\n{{{\r\nc2hs: internal error: evacuate(static): strange closure type -385875968\r\n (GHC version 7.6.3 for x86_64_portbld_freebsd)\r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\n\r\nI've attached the full log from the build in case it's useful.\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.10.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/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/5844Panic on generating Core code2019-07-07T18:53:21ZJamesFisherPanic on generating Core codeSTEPS TO REPRODUCE
1. Create the file "Panic.hs" with the contents:
```
module Main where
main = print 1
```
1. Compile with "ghc -fext-core Panic.hs"
EXPECTED BEHAVIOR
Generation of the Core file "Panic.hcr".
ACTUAL BEHAVIOR
```
...STEPS TO REPRODUCE
1. Create the file "Panic.hs" with the contents:
```
module Main where
main = print 1
```
1. Compile with "ghc -fext-core Panic.hs"
EXPECTED BEHAVIOR
Generation of the Core file "Panic.hcr".
ACTUAL BEHAVIOR
```
$ ghc -fext-core Panic.hs
[1 of 1] Compiling Main ( Panic.hs, Panic.o )
ghc: panic! (the 'impossible' happened)
(GHC version 7.4.1 for x86_64-unknown-linux):
MkExternalCore died: make_lit
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
$
```
As it states, I am using GHC version 7.4.1 for x86_64 Linux, on an x86-64 Linux box running Ubuntu 11.10 an Linux kernel 3.0.0-14-generic.
<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 | Linux |
| Architecture | x86_64 (amd64) |
</details>
<!-- {"blocked_by":[],"summary":"Panic on generating Core code","status":"New","operating_system":"Linux","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"x86_64 (amd64)","cc":[""],"type":"Bug","description":"STEPS TO REPRODUCE\r\n\r\n1. Create the file \"Panic.hs\" with the contents:\r\n\r\n{{{\r\nmodule Main where\r\nmain = print 1\r\n}}}\r\n\r\n2. Compile with \"ghc -fext-core Panic.hs\"\r\n\r\n\r\nEXPECTED BEHAVIOR\r\n\r\nGeneration of the Core file \"Panic.hcr\".\r\n\r\n\r\nACTUAL BEHAVIOR\r\n\r\n{{{\r\n$ ghc -fext-core Panic.hs\r\n[1 of 1] Compiling Main ( Panic.hs, Panic.o )\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 7.4.1 for x86_64-unknown-linux):\r\n\tMkExternalCore died: make_lit\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\n$\r\n}}}\r\n\r\nAs it states, I am using GHC version 7.4.1 for x86_64 Linux, on an x86-64 Linux box running Ubuntu 11.10 an Linux kernel 3.0.0-14-generic.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1