GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:24:58Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/12835ghc: panic! (the 'impossible' happened) - find_tycon2019-07-07T18:24:58Zmrijkeboerghc: panic! (the 'impossible' happened) - find_tycon```
$ stack build
server-0.0.0.1: build
-- While building package server-0.0.0.1 using:
/home/martijn/.stack/setup-exe-cache/x86_64-linux/setup-Simple-Cabal-1.24.0.0-ghc-8.0.1 --builddir=.stack-work/dist/x86_64-linux/Cabal-1.24.0...```
$ stack build
server-0.0.0.1: build
-- While building package server-0.0.0.1 using:
/home/martijn/.stack/setup-exe-cache/x86_64-linux/setup-Simple-Cabal-1.24.0.0-ghc-8.0.1 --builddir=.stack-work/dist/x86_64-linux/Cabal-1.24.0.0 build lib:server exe:server --ghc-options " -ddump-hi -ddump-to-file"
Process exited with code: ExitFailure 1
Logs have been written to: /home/martijn/server/.stack-work/logs/server-0.0.0.1.log
Preprocessing library server-0.0.0.1...
[20 of 20] Compiling Application ( src/Application.hs, .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/Application.o )
ghc: panic! (the 'impossible' happened)
(GHC version 8.0.1 for x86_64-unknown-linux):
find_tycon
YesodSubRunnerEnv
[]
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ghc: panic! (the 'impossible' happened) - find_tycon","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\n$ stack build\r\nserver-0.0.0.1: build\r\n\r\n-- While building package server-0.0.0.1 using:\r\n /home/martijn/.stack/setup-exe-cache/x86_64-linux/setup-Simple-Cabal-1.24.0.0-ghc-8.0.1 --builddir=.stack-work/dist/x86_64-linux/Cabal-1.24.0.0 build lib:server exe:server --ghc-options \" -ddump-hi -ddump-to-file\"\r\n Process exited with code: ExitFailure 1\r\n Logs have been written to: /home/martijn/server/.stack-work/logs/server-0.0.0.1.log\r\n\r\n Preprocessing library server-0.0.0.1...\r\n [20 of 20] Compiling Application ( src/Application.hs, .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/Application.o )\r\n ghc: panic! (the 'impossible' happened)\r\n (GHC version 8.0.1 for x86_64-unknown-linux):\r\n \tfind_tycon\r\n YesodSubRunnerEnv\r\n []\r\n \r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/12834GHC panic: while printing Non type-variable argument2019-07-07T18:24:58ZOleg GrenrusGHC panic: while printing Non type-variable argument```
{-# LANGUAGE GADTs, TypeFamilies, DataKinds, TypeOperators, MultiParamTypeClasses, UndecidableInstances, UndecidableSuperClasses, FlexibleInstances, PolyKinds, KindSignatures #-}
import GHC.Exts (Constraint)
newtype I a = I a
data...```
{-# LANGUAGE GADTs, TypeFamilies, DataKinds, TypeOperators, MultiParamTypeClasses, UndecidableInstances, UndecidableSuperClasses, FlexibleInstances, PolyKinds, KindSignatures #-}
import GHC.Exts (Constraint)
newtype I a = I a
data NP :: (k -> *) -> [k] -> * where
Nil :: NP f '[]
(:*) :: f x -> NP f xs -> NP f (x ': xs)
infixr 5 :*
class (AllF f xs, SListI xs) => All (f :: k -> Constraint) (xs :: [k])
instance (AllF f xs, SListI xs) => All f xs
data SList :: [k] -> * where
SNil :: SList '[]
SCons :: SListI xs => SList (x ': xs)
class SListI (xs :: [k]) where
-- | Get hold of the explicit singleton (that one can then
-- pattern match on).
sList :: SList xs
instance SListI '[] where
sList = SNil
instance SListI xs => SListI (x ': xs) where
sList = SCons
-- | Type family used to implement 'All'.
--
type family AllF (c :: k -> Constraint) (xs :: [k]) :: Constraint
type instance AllF _c '[] = ()
type instance AllF c (x ': xs) = (c x, All c xs)
semigroup :: All ((~) (Maybe Int)) xs => NP I xs -> NP I xs -> NP I xs
semigroup = undefined
```
Causes
```
ghc-failure-all.hs:37:14: error:
• Non type-variable argumentghc: panic! (the 'impossible' happened)
(GHC version 8.0.1 for x86_64-apple-darwin):
print_equality ~
```
If `AllF` is used directly in the definition of `sappend`, there is no error whatsoever.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC panic: while printing Non type-variable argument","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\n{-# LANGUAGE GADTs, TypeFamilies, DataKinds, TypeOperators, MultiParamTypeClasses, UndecidableInstances, UndecidableSuperClasses, FlexibleInstances, PolyKinds, KindSignatures #-}\r\n\r\nimport GHC.Exts (Constraint)\r\n\r\nnewtype I a = I a\r\n\r\ndata NP :: (k -> *) -> [k] -> * where\r\n Nil :: NP f '[]\r\n (:*) :: f x -> NP f xs -> NP f (x ': xs)\r\n\r\ninfixr 5 :*\r\n\r\nclass (AllF f xs, SListI xs) => All (f :: k -> Constraint) (xs :: [k])\r\ninstance (AllF f xs, SListI xs) => All f xs\r\n\r\ndata SList :: [k] -> * where\r\n SNil :: SList '[]\r\n SCons :: SListI xs => SList (x ': xs)\r\n\r\nclass SListI (xs :: [k]) where\r\n -- | Get hold of the explicit singleton (that one can then\r\n -- pattern match on).\r\n sList :: SList xs\r\n\r\ninstance SListI '[] where\r\n sList = SNil\r\n\r\ninstance SListI xs => SListI (x ': xs) where\r\n sList = SCons\r\n\r\n-- | Type family used to implement 'All'.\r\n--\r\ntype family AllF (c :: k -> Constraint) (xs :: [k]) :: Constraint\r\ntype instance AllF _c '[] = ()\r\ntype instance AllF c (x ': xs) = (c x, All c xs)\r\n\r\nsemigroup :: All ((~) (Maybe Int)) xs => NP I xs -> NP I xs -> NP I xs\r\nsemigroup = undefined\r\n}}}\r\n\r\nCauses\r\n\r\n{{{\r\nghc-failure-all.hs:37:14: error:\r\n • Non type-variable argumentghc: panic! (the 'impossible' happened)\r\n (GHC version 8.0.1 for x86_64-apple-darwin):\r\n\tprint_equality ~\r\n}}}\r\n\r\nIf `AllF` is used directly in the definition of `sappend`, there is no error whatsoever. ","type_of_failure":"OtherFailure","blocking":[]} -->8.0.2https://gitlab.haskell.org/ghc/ghc/-/issues/12833GHCi2019-07-07T18:24:58ZIcelandjackGHCiIn multiline mode you can define a multi-line Haskell function:
```
Prelude> :set +m
Prelude> let
Prelude| f :: Int -> Int
Prelude| f 0 = 0
Prelude| f n = n - 1
Prelude|
Prelude>
```
Is there a reason why it couldn't work with other th...In multiline mode you can define a multi-line Haskell function:
```
Prelude> :set +m
Prelude> let
Prelude| f :: Int -> Int
Prelude| f 0 = 0
Prelude| f n = n - 1
Prelude|
Prelude>
```
Is there a reason why it couldn't work with other things like
```
Prelude> :set -XPatternSynonyms
Prelude> let
Prelude| pattern A = 'A'
Prelude|
<interactive>:27:1: error:
Illegal pattern synonym declaration for ‘A’
Pattern synonym declarations are only valid at top level
```
```
Prelude> let
Prelude| data A
Prelude| = B
Prelude| | C Int
Prelude|
<interactive>:30:1: error:
parse error (possibly incorrect indentation or mismatched brackets)
```
```
Prelude> let
Prelude| type A = Int
Prelude|
<interactive>:48:1: error:
parse error (possibly incorrect indentation or mismatched brackets)
```
couldn't work, similar to how they work with `:{` and `:}`:
```
Prelude> :{
Prelude| data A
Prelude| = B
Prelude| | C Int
Prelude| :}
Prelude>
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.0.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHCi","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"In multiline mode you can define a multi-line Haskell function:\r\n\r\n{{{\r\nPrelude> :set +m\r\nPrelude> let\r\nPrelude| f :: Int -> Int\r\nPrelude| f 0 = 0\r\nPrelude| f n = n - 1\r\nPrelude|\r\nPrelude>\r\n}}}\r\n\r\nIs there a reason why it couldn't work with other things like\r\n\r\n{{{\r\nPrelude> :set -XPatternSynonyms\r\nPrelude> let\r\nPrelude| pattern A = 'A'\r\nPrelude| \r\n\r\n<interactive>:27:1: error:\r\n Illegal pattern synonym declaration for ‘A’\r\n Pattern synonym declarations are only valid at top level\r\n}}}\r\n\r\n{{{\r\nPrelude> let\r\nPrelude| data A\r\nPrelude| = B\r\nPrelude| | C Int\r\nPrelude| \r\n\r\n<interactive>:30:1: error:\r\n parse error (possibly incorrect indentation or mismatched brackets)\r\n}}}\r\n\r\n{{{\r\nPrelude> let\r\nPrelude| type A = Int\r\nPrelude| \r\n\r\n<interactive>:48:1: error:\r\n parse error (possibly incorrect indentation or mismatched brackets)\r\n}}}\r\n\r\ncouldn't work, similar to how they work with `:{` and `:}`:\r\n\r\n{{{\r\nPrelude> :{\r\nPrelude| data A\r\nPrelude| = B\r\nPrelude| | C Int\r\nPrelude| :}\r\nPrelude> \r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/12831Fulltext search SQL error in Trac2019-07-07T18:24:59ZskovalevFulltext search SQL error in TracI have faced with `Trac` errors while searching next queries:
- `ghc: panic!`
- `the 'impossible' happened`
- `Report execution failed`
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ------------...I have faced with `Trac` errors while searching next queries:
- `ghc: panic!`
- `the 'impossible' happened`
- `Report execution failed`
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Trac & Git |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Fulltext search SQL error in Trac","status":"New","operating_system":"","component":"Trac & Git","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"hvr"},"version":"","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I have faced with `Trac` errors while searching next queries:\r\n* `ghc: panic!`\r\n* `the 'impossible' happened`\r\n* `Report execution failed`","type_of_failure":"OtherFailure","blocking":[]} -->Herbert Valerio Riedelhvr@gnu.orgHerbert Valerio Riedelhvr@gnu.orghttps://gitlab.haskell.org/ghc/ghc/-/issues/12830ARM crosscompile panic2019-07-07T18:24:59ZskovalevARM crosscompile panicWhile building yesod-based project for ARM architecture I have faced with error:
```
ghc: panic! (the 'impossibel' happened)
(GHC version 8.0.1 for arm-unknown-linux):
fint_tycon
Block
[]
```
My yesod packages (inside cabal-s...While building yesod-based project for ARM architecture I have faced with error:
```
ghc: panic! (the 'impossibel' happened)
(GHC version 8.0.1 for arm-unknown-linux):
fint_tycon
Block
[]
```
My yesod packages (inside cabal-sandbox on path `.cabal-sandbox/lib/arm-linux-ghc-8.0.1`):
- yesod-1.4.3
- yesod-auth-1.4.13.5
- yesod-core-1.4.25
- yesod-form-1.4.8
- yesod-newsfeed-1.6.4
- yesod-persistent-1.4.0.6
- yesod-static-1.5.0.5
My building machine is `Debian 4.7.8-1`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown/Multiple |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ARM crosscompile panic","status":"New","operating_system":"Unknown/Multiple","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":["arm,","crosscompile,","panic"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"While building yesod-based project for ARM architecture I have faced with error:\r\n{{{\r\nghc: panic! (the 'impossibel' happened)\r\n (GHC version 8.0.1 for arm-unknown-linux):\r\n fint_tycon\r\n Block\r\n []\r\n}}}\r\n\r\nMy yesod packages (inside cabal-sandbox on path `.cabal-sandbox/lib/arm-linux-ghc-8.0.1`):\r\n* yesod-1.4.3\r\n* yesod-auth-1.4.13.5\r\n* yesod-core-1.4.25\r\n* yesod-form-1.4.8\r\n* yesod-newsfeed-1.6.4\r\n* yesod-persistent-1.4.0.6\r\n* yesod-static-1.5.0.5\r\n\r\nMy building machine is `Debian 4.7.8-1`.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/12828Generalize functions from Data.Maybe (‘catMaybes’, ‘mapMaybe’)2019-07-07T18:24:59ZIcelandjackGeneralize functions from Data.Maybe (‘catMaybes’, ‘mapMaybe’)Opening a ticket for discussion. As mentioned in [this comment](https://www.reddit.com/r/haskell/comments/2y2pe5/shouldnt_ftp_propagate_changes_over_the_entire/cp6vpb4/), more functions can be generalized to `Foldable`
```hs
catMaybes ...Opening a ticket for discussion. As mentioned in [this comment](https://www.reddit.com/r/haskell/comments/2y2pe5/shouldnt_ftp_propagate_changes_over_the_entire/cp6vpb4/), more functions can be generalized to `Foldable`
```hs
catMaybes :: Foldable f => f (Maybe a) -> [a]
mapMaybe :: Foldable f => (a -> Maybe b) -> (f a -> [b])
listToMaybe :: Foldable f => f a -> Maybe a
```
I think `catMaybes` and `mapMaybe` are fine candidates. The comment offers more extreme changes,
```hs
catMaybes :: (Foldable f, Foldable g) => f (g a) -> [a]
mapMaybe :: (Foldable f, Foldable g) => (a -> f b) -> (f a -> [b])
```https://gitlab.haskell.org/ghc/ghc/-/issues/12827RTS linker: handle 64-bit symbol table in archives2019-07-07T18:24:59ZSylvain HenryRTS linker: handle 64-bit symbol table in archivesThe RTS linker should skip 64-bit symbol table entries in archives just like it skips 32-bit ones.
See the original report thread on ghc-devs: https://mail.haskell.org/pipermail/ghc-devs/2016-November/013210.html
<details><summary>Trac...The RTS linker should skip 64-bit symbol table entries in archives just like it skips 32-bit ones.
See the original report thread on ghc-devs: https://mail.haskell.org/pipermail/ghc-devs/2016-November/013210.html
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Runtime System (Linker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"RTS linker: handle 64-bit symbol table in archives","status":"New","operating_system":"","component":"Runtime System (Linker)","related":[],"milestone":"8.0.2","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"hsyl20"},"version":"8.0.1","keywords":["linker"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The RTS linker should skip 64-bit symbol table entries in archives just like it skips 32-bit ones.\r\n\r\nSee the original report thread on ghc-devs: https://mail.haskell.org/pipermail/ghc-devs/2016-November/013210.html","type_of_failure":"OtherFailure","blocking":[]} -->8.0.2Sylvain HenrySylvain Henryhttps://gitlab.haskell.org/ghc/ghc/-/issues/12826TyVar ASSERT failure in type family checking: T120412019-07-07T18:24:59ZSimon Peyton JonesTyVar ASSERT failure in type family checking: T12041In HEAD, if you build the compiler with -DDEBUG, test `indexed-types/should_fail/T12041` fails thus
```
+ghc: panic! (the 'impossible' happened)
+ (GHC version 8.1.20161109 for x86_64-unknown-linux):
+ ASSERT failed!
+ i_axb
+ Call s...In HEAD, if you build the compiler with -DDEBUG, test `indexed-types/should_fail/T12041` fails thus
```
+ghc: panic! (the 'impossible' happened)
+ (GHC version 8.1.20161109 for x86_64-unknown-linux):
+ ASSERT failed!
+ i_axb
+ Call stack:
+ CallStack (from HasCallStack):
+ prettyCurrentCallStack, called at compiler/utils/Outputable.hs:<line>:<column> in <package-id>:Outputable
+ callStackDoc, called at compiler/utils/Outputable.hs:<line>:<column> in <package-id>:Outputable
+ assertPprPanic, called at compiler/typecheck/TcType.hs:<line>:<column> in <package-id>:TcType
+ Call stack:
+ CallStack (from HasCallStack):
+ prettyCurrentCallStack, called at compiler/utils/Outputable.hs:<line>:<column> in <package-id>:Outputable
+ callStackDoc, called at compiler/utils/Outputable.hs:<line>:<column> in <package-id>:Outputable
+ pprPanic, called at compiler/utils/Outputable.hs:<line>:<column> in <package-id>:Outputable
+ assertPprPanic, called at compiler/typecheck/TcType.hs:<line>:<column> in <package-id>:TcType
```
A `TyVar` is showing up where a `TcTyVar` is expected.
I'm pretty certain this is harmless in a production compiler, but reflects an infelicity somewhere.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"TyVar ASSERT failure in type family checking: T12041","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"In HEAD, if you build the compiler with -DDEBUG, test `indexed-types/should_fail/T12041` fails thus\r\n{{{\r\n+ghc: panic! (the 'impossible' happened)\r\n+ (GHC version 8.1.20161109 for x86_64-unknown-linux):\r\n+\tASSERT failed!\r\n+ i_axb\r\n+ Call stack:\r\n+ CallStack (from HasCallStack):\r\n+ prettyCurrentCallStack, called at compiler/utils/Outputable.hs:<line>:<column> in <package-id>:Outputable\r\n+ callStackDoc, called at compiler/utils/Outputable.hs:<line>:<column> in <package-id>:Outputable\r\n+ assertPprPanic, called at compiler/typecheck/TcType.hs:<line>:<column> in <package-id>:TcType\r\n+ Call stack:\r\n+ CallStack (from HasCallStack):\r\n+ prettyCurrentCallStack, called at compiler/utils/Outputable.hs:<line>:<column> in <package-id>:Outputable\r\n+ callStackDoc, called at compiler/utils/Outputable.hs:<line>:<column> in <package-id>:Outputable\r\n+ pprPanic, called at compiler/utils/Outputable.hs:<line>:<column> in <package-id>:Outputable\r\n+ assertPprPanic, called at compiler/typecheck/TcType.hs:<line>:<column> in <package-id>:TcType\r\n}}}\r\nA `TyVar` is showing up where a `TcTyVar` is expected.\r\n\r\nI'm pretty certain this is harmless in a production compiler, but reflects an infelicity somewhere.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/12825ghc panic on ppc64le, ghc 8.0.1, agda 2.5.1.1 patched for newer EdisonAPI2019-07-07T18:25:00Zclintghc panic on ppc64le, ghc 8.0.1, agda 2.5.1.1 patched for newer EdisonAPI```
[331 of 332] Compiling Agda.Interaction.EmacsTop ( src/full/Agda/Interaction/EmacsTop.hs, dist-ghc/build/Agda/Interaction/EmacsTop.o )
ghc: panic! (the 'impossible' happened)
(GHC version 8.0.1 for powerpc64le-unknown-linux):
appl...```
[331 of 332] Compiling Agda.Interaction.EmacsTop ( src/full/Agda/Interaction/EmacsTop.hs, dist-ghc/build/Agda/Interaction/EmacsTop.o )
ghc: panic! (the 'impossible' happened)
(GHC version 8.0.1 for powerpc64le-unknown-linux):
applyTypeToArgs
Expression: $w$cgmapQl2 stdin LineBuffering s_aJ4
Type: forall r_a2gyr r'_a2gys.
(r_a2gyr -> r'_a2gys -> r_a2gyr)
-> r_a2gyr
-> (forall d_a2gyt. Data d_a2gyt => d_a2gyt -> r'_a2gys)
-> [ModulePragma]
-> ModuleName
-> r_a2gyr
Args: [stdin, LineBuffering, s_aJ4]
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ghc panic on ppc64el, ghc 8.0.1, agda 2.5.1.1 patched for newer EdisonAPI","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\n[331 of 332] Compiling Agda.Interaction.EmacsTop ( src/full/Agda/Interaction/EmacsTop.hs, dist-ghc/build/Agda/Interaction/EmacsTop.o )\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 8.0.1 for powerpc64le-unknown-linux):\r\n\tapplyTypeToArgs\r\n Expression: $w$cgmapQl2 stdin LineBuffering s_aJ4\r\n Type: forall r_a2gyr r'_a2gys.\r\n (r_a2gyr -> r'_a2gys -> r_a2gyr)\r\n -> r_a2gyr\r\n -> (forall d_a2gyt. Data d_a2gyt => d_a2gyt -> r'_a2gys)\r\n -> [ModulePragma]\r\n -> ModuleName\r\n -> r_a2gyr\r\n Args: [stdin, LineBuffering, s_aJ4]\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/12824crashed when install debian on ubuntu 16.06 in Hyper-V VM2019-07-07T18:25:00ZQinka95crashed when install debian on ubuntu 16.06 in Hyper-V VMWhen installing the package (debian-3.91.1), ghc(8.0.1) crashed.
And output these:
```
ghc: panic! (the 'impossible' happened)
(GHC version 8.0.1 for x86_64-unknown-linux):
find_tycon
Loc
[]
Please report this as a GHC bug: ht...When installing the package (debian-3.91.1), ghc(8.0.1) crashed.
And output these:
```
ghc: panic! (the 'impossible' happened)
(GHC version 8.0.1 for x86_64-unknown-linux):
find_tycon
Loc
[]
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
And the full output when installing debian are here:
```
$ cabal install debian
Resolving dependencies...
cabal: Entering directory '/tmp/cabal-tmp-31302/debian-3.91.1'
Configuring debian-3.91.1...
Building debian-3.91.1...
Preprocessing library debian-3.91.1...
[ 1 of 37] Compiling Debian.UTF8 ( Debian/UTF8.hs, dist/build/Debian/UTF8.o )
[ 2 of 37] Compiling Debian.Version.Internal ( Debian/Version/Internal.hs, dist/build/Debian/Version/Internal.o )
[ 3 of 37] Compiling Debian.Extra.Files ( Debian/Extra/Files.hs, dist/build/Debian/Extra/Files.o )
[ 4 of 37] Compiling Debian.Loc ( Debian/Loc.hs, dist/build/Debian/Loc.o )
[ 5 of 37] Compiling Debian.Pretty ( Debian/Pretty.hs, dist/build/Debian/Pretty.o )
[ 6 of 37] Compiling Debian.Version.Common ( Debian/Version/Common.hs, dist/build/Debian/Version/Common.o )
[ 7 of 37] Compiling Debian.Version.String ( Debian/Version/String.hs, dist/build/Debian/Version/String.o )
[ 8 of 37] Compiling Debian.Version.Text ( Debian/Version/Text.hs, dist/build/Debian/Version/Text.o )
[ 9 of 37] Compiling Debian.Arch ( Debian/Arch.hs, dist/build/Debian/Arch.o )
[10 of 37] Compiling Debian.Time ( Debian/Time.hs, dist/build/Debian/Time.o )
Debian/Time.hs:23:19: warning: [-Wdeprecations]
In the use of ‘parseTime’
(imported from Data.Time, but defined in time-1.6.0.1:Data.Time.Format.Parse):
Deprecated: "use "parseTimeM True" instead"
[11 of 37] Compiling Debian.URI ( Debian/URI.hs, dist/build/Debian/URI.o )
[12 of 37] Compiling Debian.Release ( Debian/Release.hs, dist/build/Debian/Release.o )
[13 of 37] Compiling Debian.Sources ( Debian/Sources.hs, dist/build/Debian/Sources.o )
[14 of 37] Compiling Debian.Control.Common ( Debian/Control/Common.hs, dist/build/Debian/Control/Common.o )
Debian/Control/Common.hs:75:1: warning: [-Wredundant-constraints]
• Redundant constraint: ControlFunctions a
• In the type signature for:
protectFieldText' :: (StringLike a, ListLike a Char,
ControlFunctions a) =>
a -> a
Debian/Control/Common.hs:158:1: warning: [-Wredundant-constraints]
• Redundant constraint: Eq a
• In the type signature for:
raiseFields :: Eq a => (a -> Bool) -> Paragraph' a -> Paragraph' a
[15 of 37] Compiling Debian.Control.String ( Debian/Control/String.hs, dist/build/Debian/Control/String.o )
[16 of 37] Compiling Debian.Deb ( Debian/Deb.hs, dist/build/Debian/Deb.o )
[17 of 37] Compiling Debian.Apt.Methods ( Debian/Apt/Methods.hs, dist/build/Debian/Apt/Methods.o )
Debian/Apt/Methods.hs:28:1: warning: [-Wdeprecations]
Module ‘Control.Monad.Error’ is deprecated:
Use Control.Monad.Except instead
[18 of 37] Compiling Debian.Version.ByteString ( Debian/Version/ByteString.hs, dist/build/Debian/Version/ByteString.o )
[19 of 37] Compiling Debian.Version ( Debian/Version.hs, dist/build/Debian/Version.o )
[20 of 37] Compiling Debian.Changes ( Debian/Changes.hs, dist/build/Debian/Changes.o )
[21 of 37] Compiling Debian.Relation.Common ( Debian/Relation/Common.hs, dist/build/Debian/Relation/Common.o )
[22 of 37] Compiling Debian.Relation.String ( Debian/Relation/String.hs, dist/build/Debian/Relation/String.o )
[23 of 37] Compiling Debian.Relation.Text ( Debian/Relation/Text.hs, dist/build/Debian/Relation/Text.o )
[24 of 37] Compiling Debian.Relation.ByteString ( Debian/Relation/ByteString.hs, dist/build/Debian/Relation/ByteString.o )
[25 of 37] Compiling Debian.Relation ( Debian/Relation.hs, dist/build/Debian/Relation.o )
[26 of 37] Compiling Debian.Control.ByteString ( Debian/Control/ByteString.hs, dist/build/Debian/Control/ByteString.o )
Debian/Control/ByteString.hs:132:1: warning: [-Wredundant-constraints]
• Redundant constraint: ControlFunctions a
• In the type signature for:
protectFieldText' :: (LL.StringLike a, LL.ListLike a Word8,
ControlFunctions a) =>
a -> a
Debian/Control/ByteString.hs:138:7: warning: [-Wredundant-constraints]
• Redundant constraint: LL.StringLike a
• In the type signature for:
dropWhileEnd :: (LL.StringLike a1, LL.ListLike a1 Word8) =>
(Word8 -> Bool) -> a1 -> a1
In an equation for ‘protectFieldText'’:
protectFieldText' s
= case LL.lines s of {
[] -> LL.empty
(l : ls)
-> dropWhileEnd (isSpace . chr . fromIntegral)
$ LL.unlines $ l : map protect ls }
where
dropWhileEnd ::
(LL.StringLike a, LL.ListLike a Word8) => (Word8 -> Bool) -> a -> a
dropWhileEnd func = LL.reverse . LL.dropWhile func . LL.reverse
protect :: (LL.StringLike a, LL.ListLike a Word8) => a -> a
protect l
= maybe
LL.empty
(\ c
-> if isHorizSpace c then l else LL.cons (ord' ' ' :: Word8) l)
(LL.find (const True :: Word8 -> Bool) l)
....
Debian/Control/ByteString.hs:140:7: warning: [-Wredundant-constraints]
• Redundant constraint: LL.StringLike a
• In the type signature for:
protect :: (LL.StringLike a1, LL.ListLike a1 Word8) => a1 -> a1
In an equation for ‘protectFieldText'’:
protectFieldText' s
= case LL.lines s of {
[] -> LL.empty
(l : ls)
-> dropWhileEnd (isSpace . chr . fromIntegral)
$ LL.unlines $ l : map protect ls }
where
dropWhileEnd ::
(LL.StringLike a, LL.ListLike a Word8) => (Word8 -> Bool) -> a -> a
dropWhileEnd func = LL.reverse . LL.dropWhile func . LL.reverse
protect :: (LL.StringLike a, LL.ListLike a Word8) => a -> a
protect l
= maybe
LL.empty
(\ c
-> if isHorizSpace c then l else LL.cons (ord' ' ' :: Word8) l)
(LL.find (const True :: Word8 -> Bool) l)
....
[27 of 37] Compiling Debian.Control.Text ( Debian/Control/Text.hs, dist/build/Debian/Control/Text.o )
Debian/Control/Text.hs:32:1: warning: [-Wunused-imports]
The qualified import of ‘T.reverse’
from module ‘Data.Text’ is redundant
[28 of 37] Compiling Debian.Control.Policy ( Debian/Control/Policy.hs, dist/build/Debian/Control/Policy.o )
Debian/Control/Policy.hs:87:5: warning: [-Wunused-top-binds]
Defined but not used: ‘control’
[29 of 37] Compiling Debian.Control.Builder ( Debian/Control/Builder.hs, dist/build/Debian/Control/Builder.o )
Debian/Control/Builder.hs:34:1: warning: [-Wunused-imports]
The qualified import of ‘Data.Text’ is redundant
except perhaps to import instances from ‘Data.Text’
To import instances alone, use: import Data.Text()
Debian/Control/Builder.hs:36:1: warning: [-Wunused-imports]
The import of ‘fromLazyText’
from module ‘Data.Text.Lazy.Builder’ is redundant
Debian/Control/Builder.hs:104:1: warning: [-Wmissing-signatures]
Top-level binding with no type signature:
dropAround :: forall c item.
LL.ListLike c item =>
(item -> Bool) -> c -> c
[30 of 37] Compiling Debian.Control.TextLazy ( Debian/Control/TextLazy.hs, dist/build/Debian/Control/TextLazy.o )
Debian/Control/TextLazy.hs:32:1: warning: [-Wunused-imports]
The qualified import of ‘T.reverse’
from module ‘Data.Text.Lazy’ is redundant
[31 of 37] Compiling Debian.Control ( Debian/Control.hs, dist/build/Debian/Control.o )
Debian/Control.hs:56:1: warning: [-Wunused-imports]
The qualified import of ‘Debian.Control.TextLazy’ is redundant
except perhaps to import instances from ‘Debian.Control.TextLazy’
To import instances alone, use: import Debian.Control.TextLazy()
[32 of 37] Compiling Debian.Apt.Index ( Debian/Apt/Index.hs, dist/build/Debian/Apt/Index.o )
[33 of 37] Compiling Debian.Report ( Debian/Report.hs, dist/build/Debian/Report.o )
[34 of 37] Compiling Debian.GenBuildDeps ( Debian/GenBuildDeps.hs, dist/build/Debian/GenBuildDeps.o )
ghc: panic! (the 'impossible' happened)
(GHC version 8.0.1 for x86_64-unknown-linux):
find_tycon
Loc
[]
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
cabal: Leaving directory '/tmp/cabal-tmp-31302/debian-3.91.1'
Failed to install debian-3.91.1
cabal: Error: some packages failed to install:
debian-3.91.1 failed during the building phase. The exception was:
ExitFailure 1
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"crashed when install debian on ubuntu 16.06 in Hyper-V VM","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When installing the package (debian-3.91.1), ghc(8.0.1) crashed.\r\n\r\nAnd output these:\r\n\r\n{{{\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 8.0.1 for x86_64-unknown-linux):\r\n\tfind_tycon\r\n Loc\r\n []\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug \r\n}}}\r\n\r\nAnd the full output when installing debian are here:\r\n{{{\r\n\r\n$ cabal install debian\r\nResolving dependencies...\r\ncabal: Entering directory '/tmp/cabal-tmp-31302/debian-3.91.1'\r\nConfiguring debian-3.91.1...\r\nBuilding debian-3.91.1...\r\nPreprocessing library debian-3.91.1...\r\n[ 1 of 37] Compiling Debian.UTF8 ( Debian/UTF8.hs, dist/build/Debian/UTF8.o )\r\n[ 2 of 37] Compiling Debian.Version.Internal ( Debian/Version/Internal.hs, dist/build/Debian/Version/Internal.o )\r\n[ 3 of 37] Compiling Debian.Extra.Files ( Debian/Extra/Files.hs, dist/build/Debian/Extra/Files.o )\r\n[ 4 of 37] Compiling Debian.Loc ( Debian/Loc.hs, dist/build/Debian/Loc.o )\r\n[ 5 of 37] Compiling Debian.Pretty ( Debian/Pretty.hs, dist/build/Debian/Pretty.o )\r\n[ 6 of 37] Compiling Debian.Version.Common ( Debian/Version/Common.hs, dist/build/Debian/Version/Common.o )\r\n[ 7 of 37] Compiling Debian.Version.String ( Debian/Version/String.hs, dist/build/Debian/Version/String.o )\r\n[ 8 of 37] Compiling Debian.Version.Text ( Debian/Version/Text.hs, dist/build/Debian/Version/Text.o )\r\n[ 9 of 37] Compiling Debian.Arch ( Debian/Arch.hs, dist/build/Debian/Arch.o )\r\n[10 of 37] Compiling Debian.Time ( Debian/Time.hs, dist/build/Debian/Time.o )\r\n\r\nDebian/Time.hs:23:19: warning: [-Wdeprecations]\r\n In the use of ‘parseTime’\r\n (imported from Data.Time, but defined in time-1.6.0.1:Data.Time.Format.Parse):\r\n Deprecated: \"use \"parseTimeM True\" instead\"\r\n[11 of 37] Compiling Debian.URI ( Debian/URI.hs, dist/build/Debian/URI.o )\r\n[12 of 37] Compiling Debian.Release ( Debian/Release.hs, dist/build/Debian/Release.o )\r\n[13 of 37] Compiling Debian.Sources ( Debian/Sources.hs, dist/build/Debian/Sources.o )\r\n[14 of 37] Compiling Debian.Control.Common ( Debian/Control/Common.hs, dist/build/Debian/Control/Common.o )\r\n\r\nDebian/Control/Common.hs:75:1: warning: [-Wredundant-constraints]\r\n • Redundant constraint: ControlFunctions a\r\n • In the type signature for:\r\n protectFieldText' :: (StringLike a, ListLike a Char,\r\n ControlFunctions a) =>\r\n a -> a\r\n\r\nDebian/Control/Common.hs:158:1: warning: [-Wredundant-constraints]\r\n • Redundant constraint: Eq a\r\n • In the type signature for:\r\n raiseFields :: Eq a => (a -> Bool) -> Paragraph' a -> Paragraph' a\r\n[15 of 37] Compiling Debian.Control.String ( Debian/Control/String.hs, dist/build/Debian/Control/String.o )\r\n[16 of 37] Compiling Debian.Deb ( Debian/Deb.hs, dist/build/Debian/Deb.o )\r\n[17 of 37] Compiling Debian.Apt.Methods ( Debian/Apt/Methods.hs, dist/build/Debian/Apt/Methods.o )\r\n\r\nDebian/Apt/Methods.hs:28:1: warning: [-Wdeprecations]\r\n Module ‘Control.Monad.Error’ is deprecated:\r\n Use Control.Monad.Except instead\r\n[18 of 37] Compiling Debian.Version.ByteString ( Debian/Version/ByteString.hs, dist/build/Debian/Version/ByteString.o )\r\n[19 of 37] Compiling Debian.Version ( Debian/Version.hs, dist/build/Debian/Version.o )\r\n[20 of 37] Compiling Debian.Changes ( Debian/Changes.hs, dist/build/Debian/Changes.o )\r\n[21 of 37] Compiling Debian.Relation.Common ( Debian/Relation/Common.hs, dist/build/Debian/Relation/Common.o )\r\n[22 of 37] Compiling Debian.Relation.String ( Debian/Relation/String.hs, dist/build/Debian/Relation/String.o )\r\n[23 of 37] Compiling Debian.Relation.Text ( Debian/Relation/Text.hs, dist/build/Debian/Relation/Text.o )\r\n[24 of 37] Compiling Debian.Relation.ByteString ( Debian/Relation/ByteString.hs, dist/build/Debian/Relation/ByteString.o )\r\n[25 of 37] Compiling Debian.Relation ( Debian/Relation.hs, dist/build/Debian/Relation.o )\r\n[26 of 37] Compiling Debian.Control.ByteString ( Debian/Control/ByteString.hs, dist/build/Debian/Control/ByteString.o )\r\n\r\nDebian/Control/ByteString.hs:132:1: warning: [-Wredundant-constraints]\r\n • Redundant constraint: ControlFunctions a\r\n • In the type signature for:\r\n protectFieldText' :: (LL.StringLike a, LL.ListLike a Word8,\r\n ControlFunctions a) =>\r\n a -> a\r\n\r\nDebian/Control/ByteString.hs:138:7: warning: [-Wredundant-constraints]\r\n • Redundant constraint: LL.StringLike a\r\n • In the type signature for:\r\n dropWhileEnd :: (LL.StringLike a1, LL.ListLike a1 Word8) =>\r\n (Word8 -> Bool) -> a1 -> a1\r\n In an equation for ‘protectFieldText'’:\r\n protectFieldText' s\r\n = case LL.lines s of {\r\n [] -> LL.empty\r\n (l : ls)\r\n -> dropWhileEnd (isSpace . chr . fromIntegral)\r\n $ LL.unlines $ l : map protect ls }\r\n where\r\n dropWhileEnd ::\r\n (LL.StringLike a, LL.ListLike a Word8) => (Word8 -> Bool) -> a -> a\r\n dropWhileEnd func = LL.reverse . LL.dropWhile func . LL.reverse\r\n protect :: (LL.StringLike a, LL.ListLike a Word8) => a -> a\r\n protect l\r\n = maybe\r\n LL.empty\r\n (\\ c\r\n -> if isHorizSpace c then l else LL.cons (ord' ' ' :: Word8) l)\r\n (LL.find (const True :: Word8 -> Bool) l)\r\n ....\r\n\r\nDebian/Control/ByteString.hs:140:7: warning: [-Wredundant-constraints]\r\n • Redundant constraint: LL.StringLike a\r\n • In the type signature for:\r\n protect :: (LL.StringLike a1, LL.ListLike a1 Word8) => a1 -> a1\r\n In an equation for ‘protectFieldText'’:\r\n protectFieldText' s\r\n = case LL.lines s of {\r\n [] -> LL.empty\r\n (l : ls)\r\n -> dropWhileEnd (isSpace . chr . fromIntegral)\r\n $ LL.unlines $ l : map protect ls }\r\n where\r\n dropWhileEnd ::\r\n (LL.StringLike a, LL.ListLike a Word8) => (Word8 -> Bool) -> a -> a\r\n dropWhileEnd func = LL.reverse . LL.dropWhile func . LL.reverse\r\n protect :: (LL.StringLike a, LL.ListLike a Word8) => a -> a\r\n protect l\r\n = maybe\r\n LL.empty\r\n (\\ c\r\n -> if isHorizSpace c then l else LL.cons (ord' ' ' :: Word8) l)\r\n (LL.find (const True :: Word8 -> Bool) l)\r\n ....\r\n[27 of 37] Compiling Debian.Control.Text ( Debian/Control/Text.hs, dist/build/Debian/Control/Text.o )\r\n\r\nDebian/Control/Text.hs:32:1: warning: [-Wunused-imports]\r\n The qualified import of ‘T.reverse’\r\n from module ‘Data.Text’ is redundant\r\n[28 of 37] Compiling Debian.Control.Policy ( Debian/Control/Policy.hs, dist/build/Debian/Control/Policy.o )\r\n\r\nDebian/Control/Policy.hs:87:5: warning: [-Wunused-top-binds]\r\n Defined but not used: ‘control’\r\n[29 of 37] Compiling Debian.Control.Builder ( Debian/Control/Builder.hs, dist/build/Debian/Control/Builder.o )\r\n\r\nDebian/Control/Builder.hs:34:1: warning: [-Wunused-imports]\r\n The qualified import of ‘Data.Text’ is redundant\r\n except perhaps to import instances from ‘Data.Text’\r\n To import instances alone, use: import Data.Text()\r\n\r\nDebian/Control/Builder.hs:36:1: warning: [-Wunused-imports]\r\n The import of ‘fromLazyText’\r\n from module ‘Data.Text.Lazy.Builder’ is redundant\r\n\r\nDebian/Control/Builder.hs:104:1: warning: [-Wmissing-signatures]\r\n Top-level binding with no type signature:\r\n dropAround :: forall c item.\r\n LL.ListLike c item =>\r\n (item -> Bool) -> c -> c\r\n[30 of 37] Compiling Debian.Control.TextLazy ( Debian/Control/TextLazy.hs, dist/build/Debian/Control/TextLazy.o )\r\n\r\nDebian/Control/TextLazy.hs:32:1: warning: [-Wunused-imports]\r\n The qualified import of ‘T.reverse’\r\n from module ‘Data.Text.Lazy’ is redundant\r\n[31 of 37] Compiling Debian.Control ( Debian/Control.hs, dist/build/Debian/Control.o )\r\n\r\nDebian/Control.hs:56:1: warning: [-Wunused-imports]\r\n The qualified import of ‘Debian.Control.TextLazy’ is redundant\r\n except perhaps to import instances from ‘Debian.Control.TextLazy’\r\n To import instances alone, use: import Debian.Control.TextLazy()\r\n[32 of 37] Compiling Debian.Apt.Index ( Debian/Apt/Index.hs, dist/build/Debian/Apt/Index.o )\r\n[33 of 37] Compiling Debian.Report ( Debian/Report.hs, dist/build/Debian/Report.o )\r\n[34 of 37] Compiling Debian.GenBuildDeps ( Debian/GenBuildDeps.hs, dist/build/Debian/GenBuildDeps.o )\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 8.0.1 for x86_64-unknown-linux):\r\n\tfind_tycon\r\n Loc\r\n []\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\ncabal: Leaving directory '/tmp/cabal-tmp-31302/debian-3.91.1'\r\nFailed to install debian-3.91.1\r\ncabal: Error: some packages failed to install:\r\ndebian-3.91.1 failed during the building phase. The exception was:\r\nExitFailure 1\r\n\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/12821Find the incredible vanishing [The improvement story]2019-07-07T18:25:01ZBen GamariFind the incredible vanishing [The improvement story]Somehow we lost Note \[The improvement story\] in `TcInteract`. There are references to it in `TcInteract` and `TcRnTypes` but the note itself is nowhere to be found. Someone must find it before it reaches the county border!
<details><s...Somehow we lost Note \[The improvement story\] in `TcInteract`. There are references to it in `TcInteract` and `TcRnTypes` but the note itself is nowhere to be found. Someone must find it before it reaches the county border!
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.0.1 |
| Type | Task |
| 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":"Find the incredible vanishing [The improvement story]","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"Somehow we lost Note [The improvement story] in `TcInteract`. There are references to it in `TcInteract` and `TcRnTypes` but the note itself is nowhere to be found. Someone must find it before it reaches the county border!","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/12819Pattern synonym signatures are not validity-checked2019-07-07T18:25:01ZRichard Eisenbergrae@richarde.devPattern synonym signatures are not validity-checkedPonder this garbage:
```hs
{-# LANGUAGE PatternSynonyms, ViewPatterns,
TypeFamilies, KindSignatures #-}
module Bug where
type family F a -- F :: * -> *
data T :: (* -> *) -> *
pattern Q :: T F -> String
pattern Q x <- (...Ponder this garbage:
```hs
{-# LANGUAGE PatternSynonyms, ViewPatterns,
TypeFamilies, KindSignatures #-}
module Bug where
type family F a -- F :: * -> *
data T :: (* -> *) -> *
pattern Q :: T F -> String
pattern Q x <- (undefined -> x)
```
This is accepted by GHC 8.0.1 and HEAD. But it has an unsaturated type family! Urk!
The problem is that `TcSigs.tcPatSynSig` never does validity checking.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.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":"Pattern synonym signatures are not validity-checked","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Ponder this garbage:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE PatternSynonyms, ViewPatterns,\r\n TypeFamilies, KindSignatures #-}\r\n\r\nmodule Bug where\r\n\r\ntype family F a -- F :: * -> *\r\ndata T :: (* -> *) -> *\r\n\r\npattern Q :: T F -> String\r\npattern Q x <- (undefined -> x)\r\n}}}\r\n\r\nThis is accepted by GHC 8.0.1 and HEAD. But it has an unsaturated type family! Urk!\r\n\r\nThe problem is that `TcSigs.tcPatSynSig` never does validity checking.","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/12816Link error with GOLD linker2019-07-07T18:25:02ZSylvain HenryLink error with GOLD linker1. I think we should add "pthread" to the list of extra-libs in "rts/package.conf.in" for the threaded RTS on UNIX-like host OSes.
1. we should include MachDeps.h in "rts/package.conf.in"
Current master branch (2e8463b232054b788b73e6551...1. I think we should add "pthread" to the list of extra-libs in "rts/package.conf.in" for the threaded RTS on UNIX-like host OSes.
1. we should include MachDeps.h in "rts/package.conf.in"
Current master branch (2e8463b232054b788b73e6551947a9434aa76009) build is broken on my system\[0\]. When ghc-stage1 tries to produce ghc-stage2, I get:
```
/home/hsyl20/repo/ghc/rts/dist/build/libHSrts_thr-ghc8.1.20161107.so: error: undefined reference to 'pthread_create'
/home/hsyl20/repo/ghc/rts/dist/build/libHSrts_thr-ghc8.1.20161107.so: error: undefined reference to 'pthread_detach
```
(logs: http://pastebin.com/EbqEx6Gg )
I have tracked down the regression to the following recent commit: a977c96537bb7077c6445f02db98636b150e6e14
If I revert this commit, it builds. However I think this commit has only revealed the bug: if I add "pthread" to the list of extra-libs in "rts/package.conf.in", it builds too. We already add it on freebsd and openbsd but not on Linux.
I think I have finally found out why other devs on \#ghc haven't noticed this bug: my system uses the GOLD linker (because of #12748), but if I switch back to the BFD linker, it builds without error.
While investigating this bug, I have noticed that linker flags for 64-bit atomic ops introduced by https://git.haskell.org/ghc.git/commitdiff/c06e3f46d24ef69f3a3d794f5f604cb8c2a40cbc aren't set while they should: WORD_SIZE_IN_BITS isn't defined because we don't include MachDeps.h
\[0\] x86-64, ArchLinux (Linux 4.8.6),
GNU gold (GNU Binutils 2.27) 1.12,
gcc (GCC) 6.2.1 20160830
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------ |
| Version | 8.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Compiler (Linking) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Link error with GOLD linker","status":"New","operating_system":"","component":"Compiler (Linking)","related":[],"milestone":"8.0.2","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"1. I think we should add \"pthread\" to the list of extra-libs in \"rts/package.conf.in\" for the threaded RTS on UNIX-like host OSes.\r\n2. we should include MachDeps.h in \"rts/package.conf.in\"\r\n\r\nCurrent master branch (2e8463b232054b788b73e6551947a9434aa76009) build is broken on my system[0]. When ghc-stage1 tries to produce ghc-stage2, I get:\r\n{{{\r\n/home/hsyl20/repo/ghc/rts/dist/build/libHSrts_thr-ghc8.1.20161107.so: error: undefined reference to 'pthread_create'\r\n/home/hsyl20/repo/ghc/rts/dist/build/libHSrts_thr-ghc8.1.20161107.so: error: undefined reference to 'pthread_detach\r\n}}}\r\n(logs: http://pastebin.com/EbqEx6Gg )\r\n\r\nI have tracked down the regression to the following recent commit: a977c96537bb7077c6445f02db98636b150e6e14\r\nIf I revert this commit, it builds. However I think this commit has only revealed the bug: if I add \"pthread\" to the list of extra-libs in \"rts/package.conf.in\", it builds too. We already add it on freebsd and openbsd but not on Linux.\r\n\r\nI think I have finally found out why other devs on #ghc haven't noticed this bug: my system uses the GOLD linker (because of #12748), but if I switch back to the BFD linker, it builds without error.\r\n\r\nWhile investigating this bug, I have noticed that linker flags for 64-bit atomic ops introduced by https://git.haskell.org/ghc.git/commitdiff/c06e3f46d24ef69f3a3d794f5f604cb8c2a40cbc aren't set while they should: WORD_SIZE_IN_BITS isn't defined because we don't include MachDeps.h\r\n\r\n[0] x86-64, ArchLinux (Linux 4.8.6), \r\nGNU gold (GNU Binutils 2.27) 1.12, \r\ngcc (GCC) 6.2.1 20160830","type_of_failure":"OtherFailure","blocking":[]} -->8.0.2https://gitlab.haskell.org/ghc/ghc/-/issues/12815ghc: panic Loading temp shared object failed2019-07-07T18:25:02Zbrodybergghc: panic Loading temp shared object failedI ran 'stack upgrade' and after downloading, configuring, building and registering all 178 required packages I got this:
```
[1 of 1] Compiling Main ( /private/var/folders/23/f9jzgvns2378jgmdt5v42sj00000gn/T/stack-upgrade115...I ran 'stack upgrade' and after downloading, configuring, building and registering all 178 required packages I got this:
```
[1 of 1] Compiling Main ( /private/var/folders/23/f9jzgvns2378jgmdt5v42sj00000gn/T/stack-upgrade11535/stack-1.2.0/Setup.hs, /private/var/folders/23/f9jzgvns2378jgmdt5v42sj00000gn/T/stack-upgrade11535/stack-1.2.0/.stack-work/dist/x86_64-osx/Cabal-1.22.5.0/setup/Main.o )
Linking /private/var/folders/23/f9jzgvns2378jgmdt5v42sj00000gn/T/stack-upgrade11535/stack-1.2.0/.stack-work/dist/x86_64-osx/Cabal-1.22.5.0/setup/setup ...
Configuring stack-1.2.0...
stack-1.2.0: build
Preprocessing library stack-1.2.0...
[ 1 of 96] Compiling Text.PrettyPrint.Leijen.Extended ( src/Text/PrettyPrint/Leijen/Extended.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Text/PrettyPrint/Leijen/Extended.o )
[ 2 of 96] Compiling Stack.Ghci.Script ( src/Stack/Ghci/Script.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Stack/Ghci/Script.o )
[ 3 of 96] Compiling Stack.FileWatch ( src/Stack/FileWatch.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Stack/FileWatch.o )
[ 4 of 96] Compiling System.Process.PagerEditor ( src/System/Process/PagerEditor.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/System/Process/PagerEditor.o )
[ 5 of 96] Compiling System.Process.Log ( src/System/Process/Log.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/System/Process/Log.o )
[ 6 of 96] Compiling Paths_stack ( .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/autogen/Paths_stack.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Paths_stack.o )
[ 7 of 96] Compiling Path.Find ( src/Path/Find.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Path/Find.o )
[ 8 of 96] Compiling Path.Extra ( src/Path/Extra.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Path/Extra.o )
[ 9 of 96] Compiling System.Process.Read ( src/System/Process/Read.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/System/Process/Read.o )
ghc: panic! (the 'impossible' happened)
(GHC version 7.10.3 for x86_64-apple-darwin):
Loading temp shared object failed: dlopen(/var/folders/23/f9jzgvns2378jgmdt5v42sj00000gn/T/ghc29794_0/libghc_55.dylib, 5): no suitable image found. Did find:
/var/folders/23/f9jzgvns2378jgmdt5v42sj00000gn/T/ghc29794_0/libghc_55.dylib: malformed mach-o: load commands size (47248) > 32768
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Completed 178 action(s).
-- While building package stack-1.2.0 using:
/private/var/folders/23/f9jzgvns2378jgmdt5v42sj00000gn/T/stack-upgrade11535/stack-1.2.0/.stack-work/dist/x86_64-osx/Cabal-1.22.5.0/setup/setup --builddir=.stack-work/dist/x86_64-osx/Cabal-1.22.5.0 build lib:stack exe:stack --ghc-options " -ddump-hi -ddump-to-file"
Process exited with code: ExitFailure 1
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ghc: panic Loading temp shared object failed","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":["osx"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I ran 'stack upgrade' and after downloading, configuring, building and registering all 178 required packages I got this: \r\n\r\n\r\n{{{\r\n[1 of 1] Compiling Main ( /private/var/folders/23/f9jzgvns2378jgmdt5v42sj00000gn/T/stack-upgrade11535/stack-1.2.0/Setup.hs, /private/var/folders/23/f9jzgvns2378jgmdt5v42sj00000gn/T/stack-upgrade11535/stack-1.2.0/.stack-work/dist/x86_64-osx/Cabal-1.22.5.0/setup/Main.o )\r\nLinking /private/var/folders/23/f9jzgvns2378jgmdt5v42sj00000gn/T/stack-upgrade11535/stack-1.2.0/.stack-work/dist/x86_64-osx/Cabal-1.22.5.0/setup/setup ...\r\nConfiguring stack-1.2.0...\r\nstack-1.2.0: build\r\nPreprocessing library stack-1.2.0...\r\n[ 1 of 96] Compiling Text.PrettyPrint.Leijen.Extended ( src/Text/PrettyPrint/Leijen/Extended.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Text/PrettyPrint/Leijen/Extended.o )\r\n[ 2 of 96] Compiling Stack.Ghci.Script ( src/Stack/Ghci/Script.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Stack/Ghci/Script.o )\r\n[ 3 of 96] Compiling Stack.FileWatch ( src/Stack/FileWatch.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Stack/FileWatch.o )\r\n[ 4 of 96] Compiling System.Process.PagerEditor ( src/System/Process/PagerEditor.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/System/Process/PagerEditor.o )\r\n[ 5 of 96] Compiling System.Process.Log ( src/System/Process/Log.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/System/Process/Log.o )\r\n[ 6 of 96] Compiling Paths_stack ( .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/autogen/Paths_stack.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Paths_stack.o )\r\n[ 7 of 96] Compiling Path.Find ( src/Path/Find.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Path/Find.o )\r\n[ 8 of 96] Compiling Path.Extra ( src/Path/Extra.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Path/Extra.o )\r\n[ 9 of 96] Compiling System.Process.Read ( src/System/Process/Read.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/System/Process/Read.o )\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 7.10.3 for x86_64-apple-darwin):\r\n Loading temp shared object failed: dlopen(/var/folders/23/f9jzgvns2378jgmdt5v42sj00000gn/T/ghc29794_0/libghc_55.dylib, 5): no suitable image found. Did find:\r\n /var/folders/23/f9jzgvns2378jgmdt5v42sj00000gn/T/ghc29794_0/libghc_55.dylib: malformed mach-o: load commands size (47248) > 32768\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n \r\nCompleted 178 action(s).\r\n\r\n-- While building package stack-1.2.0 using:\r\n /private/var/folders/23/f9jzgvns2378jgmdt5v42sj00000gn/T/stack-upgrade11535/stack-1.2.0/.stack-work/dist/x86_64-osx/Cabal-1.22.5.0/setup/setup --builddir=.stack-work/dist/x86_64-osx/Cabal-1.22.5.0 build lib:stack exe:stack --ghc-options \" -ddump-hi -ddump-to-file\"\r\n Process exited with code: ExitFailure 1\r\n\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/12814Should GND infer an instance context when deriving method-free classes?2020-05-27T22:53:11ZRyan ScottShould GND infer an instance context when deriving method-free classes?This is a design question that emerged from code that I originally discovered [here](https://ghc.haskell.org/trac/ghc/ticket/11369#comment:17) and [here](https://ghc.haskell.org/trac/ghc/ticket/12810#comment:3). To recap, it's now possib...This is a design question that emerged from code that I originally discovered [here](https://ghc.haskell.org/trac/ghc/ticket/11369#comment:17) and [here](https://ghc.haskell.org/trac/ghc/ticket/12810#comment:3). To recap, it's now possible to have code like this:
```hs
{-# LANGUAGE GeneralizedNewtypeDeriving, TypeFamilies #-}
class C a where
type T a
newtype Identity a = Identity a deriving C
```
Compiling this (with `-Wredundant-constraints`) generates this code:
```hs
instance C a => C (Identity a) where
type T (Identity a) = T a
```
But now GHC will complain:
```
• Redundant constraint: C a
• In the instance declaration for ‘C (Identity a)’
```
This warning makes sense from the perspective that the `C a` constraint isn't ever used by the associated type family instance. So the question arises: should GND avoid generating an instance context for the representation type in the event it's deriving a class with no methods?
Fortunately, patching GHC to do this is trivial:
```diff
diff --git a/compiler/typecheck/TcDeriv.hs b/compiler/typecheck/TcDeriv.hs
index 4722f16..df2d3d5 100644
--- a/compiler/typecheck/TcDeriv.hs
+++ b/compiler/typecheck/TcDeriv.hs
@@ -1272,7 +1272,8 @@ mkNewTypeEqn dflags overlap_mode tvs
[ let (Pair t1 t2) = mkCoerceClassMethEqn cls dfun_tvs inst_tys rep_inst_ty m
in mkPredOrigin (DerivOriginCoerce meth t1 t2) TypeLevel
(mkReprPrimEqPred t1 t2)
- | meth <- classMethods cls ]
+ | meth <- meths ]
+ meths = classMethods cls
-- If there are no tyvars, there's no need
-- to abstract over the dictionaries we need
@@ -1281,7 +1282,11 @@ mkNewTypeEqn dflags overlap_mode tvs
-- instance C T
-- rather than
-- instance C Int => C T
- all_preds = rep_pred_o : coercible_constraints ++ sc_theta -- NB: rep_pred comes
+ all_preds = if null meths then [] else [rep_pred_o]
+ -- See Note [GND and method-free classes]
+ ++ coercible_constraints
+ ++ sc_theta
+ -- NB: rep_pred_o comes first
-------------------------------------------------------------------
-- Figuring out whether we can only do this newtype-deriving thing
```
After implementing this patch, I ran the testsuite, and there were some surprising results. One thing that shocked me was that the program reported in #6088, which had previously failed due to a patch resulting from #8984, was now passing!
```hs
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE GeneralizedNewtypeDeriving #-}
{-# LANGUAGE EmptyDataDecls #-}
module T6088 where
class C a
newtype A n = A Int
type family Pos n
data True
instance (Pos n ~ True) => C (A n)
newtype B n = B (A n) deriving (C)
```
That is because previously, GHC was trying to generate an instance like this:
```hs
instance (Pos n ~ True) => C (B n)
```
And this was rejected, since we don't infer exotic equality constraints when deriving. But with this patch, it now generates:
```hs
instance {- Empty context => -} C (B n)
```
Which is certainly valid. But is it what a user would expect? I'm not so sure.
As hvr notes in #11369, sometimes empty classes are used to enforce invariants, like in the following case:
```hs
class Throws e
readFoo :: Throws IOError => FilePath -> IO Foo
readFoo fn = {- ... -}
```
What if you wanted to have a `Throws` instance for a newtype? You'd probably want something like this:
```hs
newtype Id a = MkId a
instance Throws a => Throws (Id a)
```
Which feels like something GND should be able to take care of with ease. But to your surprise, you try this:
```hs
newtype Id a = MkId a
deriving Throws
```
And now GHC generates not the instance above, but rather just:
```hs
instance Throws (Identity a)
```
So it's possible that we would lose some of the expressiveness of GND by implementing this change. Is that acceptable? I'm not sure, so I though I'd solicit feedback here.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.0.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":"Should GND infer an instance context when deriving method-free classes?","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"8.2.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This is a design question that emerged from code that I originally discovered [https://ghc.haskell.org/trac/ghc/ticket/11369#comment:17 here] and [https://ghc.haskell.org/trac/ghc/ticket/12810#comment:3 here]. To recap, it's now possible to have code like this:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE GeneralizedNewtypeDeriving, TypeFamilies #-}\r\nclass C a where\r\n type T a\r\n\r\nnewtype Identity a = Identity a deriving C\r\n}}}\r\n\r\nCompiling this (with `-Wredundant-constraints`) generates this code:\r\n\r\n{{{#!hs\r\ninstance C a => C (Identity a) where\r\n type T (Identity a) = T a\r\n}}}\r\n\r\nBut now GHC will complain:\r\n\r\n{{{\r\n• Redundant constraint: C a\r\n• In the instance declaration for ‘C (Identity a)’\r\n}}}\r\n\r\nThis warning makes sense from the perspective that the `C a` constraint isn't ever used by the associated type family instance. So the question arises: should GND avoid generating an instance context for the representation type in the event it's deriving a class with no methods?\r\n\r\nFortunately, patching GHC to do this is trivial:\r\n\r\n{{{#!diff\r\ndiff --git a/compiler/typecheck/TcDeriv.hs b/compiler/typecheck/TcDeriv.hs\r\nindex 4722f16..df2d3d5 100644\r\n--- a/compiler/typecheck/TcDeriv.hs\r\n+++ b/compiler/typecheck/TcDeriv.hs\r\n@@ -1272,7 +1272,8 @@ mkNewTypeEqn dflags overlap_mode tvs\r\n [ let (Pair t1 t2) = mkCoerceClassMethEqn cls dfun_tvs inst_tys rep_inst_ty m\r\n in mkPredOrigin (DerivOriginCoerce meth t1 t2) TypeLevel\r\n (mkReprPrimEqPred t1 t2)\r\n- | meth <- classMethods cls ]\r\n+ | meth <- meths ]\r\n+ meths = classMethods cls\r\n \r\n -- If there are no tyvars, there's no need\r\n -- to abstract over the dictionaries we need\r\n@@ -1281,7 +1282,11 @@ mkNewTypeEqn dflags overlap_mode tvs\r\n -- instance C T\r\n -- rather than\r\n -- instance C Int => C T\r\n- all_preds = rep_pred_o : coercible_constraints ++ sc_theta -- NB: rep_pred comes \r\n+ all_preds = if null meths then [] else [rep_pred_o]\r\n+ -- See Note [GND and method-free classes]\r\n+ ++ coercible_constraints\r\n+ ++ sc_theta\r\n+ -- NB: rep_pred_o comes first\r\n \r\n -------------------------------------------------------------------\r\n -- Figuring out whether we can only do this newtype-deriving thing\r\n}}}\r\n\r\nAfter implementing this patch, I ran the testsuite, and there were some surprising results. One thing that shocked me was that the program reported in #6088, which had previously failed due to a patch resulting from #8984, was now passing!\r\n\r\n{{{#!hs\r\n{-# LANGUAGE TypeFamilies #-}\r\n{-# LANGUAGE GeneralizedNewtypeDeriving #-} \r\n{-# LANGUAGE EmptyDataDecls #-}\r\n\r\nmodule T6088 where\r\n\r\nclass C a\r\n\r\nnewtype A n = A Int\r\n\r\ntype family Pos n\r\ndata True\r\n\r\ninstance (Pos n ~ True) => C (A n)\r\n\r\nnewtype B n = B (A n) deriving (C)\r\n}}}\r\n\r\nThat is because previously, GHC was trying to generate an instance like this:\r\n\r\n{{{#!hs\r\ninstance (Pos n ~ True) => C (B n)\r\n}}}\r\n\r\nAnd this was rejected, since we don't infer exotic equality constraints when deriving. But with this patch, it now generates:\r\n\r\n{{{#!hs\r\ninstance {- Empty context => -} C (B n)\r\n}}}\r\n\r\nWhich is certainly valid. But is it what a user would expect? I'm not so sure.\r\n\r\nAs hvr notes in #11369, sometimes empty classes are used to enforce invariants, like in the following case:\r\n\r\n{{{#!hs\r\nclass Throws e\r\n\r\nreadFoo :: Throws IOError => FilePath -> IO Foo\r\nreadFoo fn = {- ... -}\r\n}}}\r\n\r\nWhat if you wanted to have a `Throws` instance for a newtype? You'd probably want something like this:\r\n\r\n{{{#!hs\r\nnewtype Id a = MkId a\r\n\r\ninstance Throws a => Throws (Id a)\r\n}}}\r\n\r\nWhich feels like something GND should be able to take care of with ease. But to your surprise, you try this:\r\n\r\n{{{#!hs\r\nnewtype Id a = MkId a\r\n deriving Throws\r\n}}}\r\n\r\nAnd now GHC generates not the instance above, but rather just:\r\n\r\n{{{#!hs\r\ninstance Throws (Identity a)\r\n}}}\r\n\r\nSo it's possible that we would lose some of the expressiveness of GND by implementing this change. Is that acceptable? I'm not sure, so I though I'd solicit feedback here.","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1Ryan ScottRyan Scotthttps://gitlab.haskell.org/ghc/ghc/-/issues/12811GHC tells me to use RankNTypes when it's already enabled2019-07-07T18:25:03ZRyan ScottGHC tells me to use RankNTypes when it's already enabledI was stumped for a while today because GHC kept telling me to turn on `RankNTypes` even when it was already enabled! I eventually realized this was the problem:
```hs
{-# LANGUAGE RankNTypes #-}
module Bug where
foo :: foral a. a -> a...I was stumped for a while today because GHC kept telling me to turn on `RankNTypes` even when it was already enabled! I eventually realized this was the problem:
```hs
{-# LANGUAGE RankNTypes #-}
module Bug where
foo :: foral a. a -> a
foo x = x
```
```
$ ghc Bug.hs
[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
Bug.hs:4:15: error:
Illegal symbol '.' in type
Perhaps you intended to use RankNTypes or a similar language
extension to enable explicit-forall syntax: forall <tvs>. <type>
```
That is, the real culprit was misspelling `forall` as `foral`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.0.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":"GHC tells me to use RankNTypes when it's already enabled","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I was stumped for a while today because GHC kept telling me to turn on `RankNTypes` even when it was already enabled! I eventually realized this was the problem:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE RankNTypes #-}\r\nmodule Bug where\r\n\r\nfoo :: foral a. a -> a\r\nfoo x = x\r\n}}}\r\n\r\n{{{\r\n$ ghc Bug.hs\r\n[1 of 1] Compiling Bug ( Bug.hs, Bug.o )\r\n\r\nBug.hs:4:15: error:\r\n Illegal symbol '.' in type\r\n Perhaps you intended to use RankNTypes or a similar language\r\n extension to enable explicit-forall syntax: forall <tvs>. <type>\r\n}}}\r\n\r\nThat is, the real culprit was misspelling `forall` as `foral`.","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1ruperthorlickruperthorlickhttps://gitlab.haskell.org/ghc/ghc/-/issues/12810-Wredundant-constraints doesn't factor in associated type families2019-07-07T18:25:03ZRyan Scott-Wredundant-constraints doesn't factor in associated type familiesIf I compile this code:
```hs
{-# LANGUAGE TypeFamilies #-}
module M where
class C a where
type T a
instance C a => C [a] where
type T [a] = T a
```
with `-Wredundant-constraints` enabled, it complains:
```
$ /opt/ghc/head/bin/g...If I compile this code:
```hs
{-# LANGUAGE TypeFamilies #-}
module M where
class C a where
type T a
instance C a => C [a] where
type T [a] = T a
```
with `-Wredundant-constraints` enabled, it complains:
```
$ /opt/ghc/head/bin/ghc -Wredundant-constraints M.hs
[1 of 1] Compiling M ( M.hs, M.o )
M.hs:7:10: warning: [-Wredundant-constraints]
• Redundant constraint: C a
• In the instance declaration for ‘C [a]’
```
I don't think this is right. The RHS of `T [a]` won't be able to reduce unless there's a `T a` instance available–that is, unless there's a `C a` instance available, which is what the context provides, making it non-redundant.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | simonpj |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"-Wredundant-constraints doesn't factor in associated type families","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["simonpj"],"type":"Bug","description":"If I compile this code:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE TypeFamilies #-}\r\nmodule M where\r\n\r\nclass C a where\r\n type T a\r\n\r\ninstance C a => C [a] where\r\n type T [a] = T a\r\n}}}\r\n\r\nwith `-Wredundant-constraints` enabled, it complains:\r\n\r\n{{{\r\n$ /opt/ghc/head/bin/ghc -Wredundant-constraints M.hs\r\n[1 of 1] Compiling M ( M.hs, M.o )\r\n\r\nM.hs:7:10: warning: [-Wredundant-constraints]\r\n • Redundant constraint: C a\r\n • In the instance declaration for ‘C [a]’\r\n}}}\r\n\r\nI don't think this is right. The RHS of `T [a]` won't be able to reduce unless there's a `T a` instance available–that is, unless there's a `C a` instance available, which is what the context provides, making it non-redundant.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/12809TYPE 'UnboxedTupleRep is still a lie2019-07-07T18:25:04ZRichard Eisenbergrae@richarde.devTYPE 'UnboxedTupleRep is still a lieThe new scheme for describing kinds of types with values with `TYPE :: RuntimeRep -> Type` is a large improvement on the old way of using kind `#` for all unlifted types. In particular, the new scheme differentiates between the kind of `...The new scheme for describing kinds of types with values with `TYPE :: RuntimeRep -> Type` is a large improvement on the old way of using kind `#` for all unlifted types. In particular, the new scheme differentiates between the kind of `Int#` and `Float#`, for example, because these have different calling conventions. This is Good.
But there is still a lie left in the whole scheme: `UnboxedTupleRep`, which covers all unboxed tuples. Of course, unboxed tuples of different arities and contents have different calling conventions, so these should be distinguished at the kind level.
Simon and I have cooked up a new scheme to handle this, summarized in these definitions:
```hs
TYPE :: RuntimeRep -> Type -- highly magical, just as before
type RuntimeRep = [UnaryRep] -- this bit is the new part
data UnaryRep = PtrRepLifted -- like the old RuntimeRep type
| PtrRepUnlifted
| IntRep
| ...
type Lifted = '[PtrRepLifted] -- a very common case
type Type = TYPE Lifted -- good old Type
```
The `UnaryRep` type is the big sum of all possible representations, just like the `RuntimeRep` of today. It drops `VoidRep` and `UnboxedTupleRep`, however.
The interpretation of this is that the kinds now include a *list* of unary representation forms. A "unary representation" corresponds to what we might expect to store in one machine register at runtime. Unboxed tuples naturally have a variable number of associated unary reps: this is precisely what an unboxed tuple means. It also baldly states that the unary unboxed tuple is identical (at runtime) to the thing in the tuple (which is correct) and also allows us to remove the runtime distinction between `(# #)` and `Void#`, which now both have kind `TYPE '[]`. (Indeed, perhaps we should just say `type Void# = (# #)`.)
This will not be backward compatible with GHC 8.0. But I'm OK with this, as any user access to these features requires importing internal modules, and it seems quite painful to try to come up with a migration story here for an experimental feature.
Patch will be written this weekend, with any luck.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"TYPE 'UnboxedTupleRep is still a lie","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"goldfire"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The new scheme for describing kinds of types with values with `TYPE :: RuntimeRep -> Type` is a large improvement on the old way of using kind `#` for all unlifted types. In particular, the new scheme differentiates between the kind of `Int#` and `Float#`, for example, because these have different calling conventions. This is Good.\r\n\r\nBut there is still a lie left in the whole scheme: `UnboxedTupleRep`, which covers all unboxed tuples. Of course, unboxed tuples of different arities and contents have different calling conventions, so these should be distinguished at the kind level.\r\n\r\nSimon and I have cooked up a new scheme to handle this, summarized in these definitions:\r\n\r\n{{{#!hs\r\nTYPE :: RuntimeRep -> Type -- highly magical, just as before\r\ntype RuntimeRep = [UnaryRep] -- this bit is the new part\r\ndata UnaryRep = PtrRepLifted -- like the old RuntimeRep type\r\n | PtrRepUnlifted\r\n | IntRep\r\n | ...\r\ntype Lifted = '[PtrRepLifted] -- a very common case\r\ntype Type = TYPE Lifted -- good old Type\r\n}}}\r\n\r\nThe `UnaryRep` type is the big sum of all possible representations, just like the `RuntimeRep` of today. It drops `VoidRep` and `UnboxedTupleRep`, however.\r\n\r\nThe interpretation of this is that the kinds now include a ''list'' of unary representation forms. A \"unary representation\" corresponds to what we might expect to store in one machine register at runtime. Unboxed tuples naturally have a variable number of associated unary reps: this is precisely what an unboxed tuple means. It also baldly states that the unary unboxed tuple is identical (at runtime) to the thing in the tuple (which is correct) and also allows us to remove the runtime distinction between `(# #)` and `Void#`, which now both have kind `TYPE '[]`. (Indeed, perhaps we should just say `type Void# = (# #)`.)\r\n\r\nThis will not be backward compatible with GHC 8.0. But I'm OK with this, as any user access to these features requires importing internal modules, and it seems quite painful to try to come up with a migration story here for an experimental feature.\r\n\r\nPatch will be written this weekend, with any luck.","type_of_failure":"OtherFailure","blocking":[]} -->Richard Eisenbergrae@richarde.devRichard Eisenbergrae@richarde.devhttps://gitlab.haskell.org/ghc/ghc/-/issues/12808For closures, Loop Invariant Code Flow related to captured free values not li...2022-03-31T10:42:29ZGordonBGoodFor closures, Loop Invariant Code Flow related to captured free values not lifted outside the loop...**Background:** I've been intrigued investigating whether GHC can produce code "as fast as Cee (C/C++/Rust/etc.)" by-any-means-possible, and have been using the very tight inner composite culling loops (purely integer operations) of a ba...**Background:** I've been intrigued investigating whether GHC can produce code "as fast as Cee (C/C++/Rust/etc.)" by-any-means-possible, and have been using the very tight inner composite culling loops (purely integer operations) of a basic Sieve of Eratosthenes implementation as a test vehicle.
**Synopsis:** This is a follow-on of the work leading to finding the efficiency problem described in ticket #12798, but involves pushing the speed even further as per the method described for "primesieve" as per [http://primesieve.org/](http://primesieve.org/) in the "Highly optimized inner loop" section.
**Shortest possible test code that clearly shows closures not being optimized, but optimized when unified by a "join point":** Please refer directly to comment 12https://ghc.haskell.org/trac/ghc/ticket/12808\#[ticket:12808\#comment:128621](https://gitlab.haskell.org//ghc/ghc/issues/12808#note_128621) and follow-on comments.
**A version of test code that triggered this ticket:** Essentially, this method involves extreme loop unrolling with very imperative code although coded functionally; in the case of the following code it means that, recognizing that for all odd primes (which they all are other than two), and that all word sizes are of an even number of bits, there will be a repeating pattern of composite number culls that repeats every word size number of bits. Thus for a word size of one eight-bit byte, we can unroll to eight composite culls in the body of one loop, with loops cases for the primes modulo 8 of 1, 3, 5, and 7, and for the eight bit start positions (b0..b7) meaning there are four times eight is 32 loop cases. When there are no longer a full eight culls left, the culling reverts to conventional single-cull-per-loop as per the test program of ticket #12798.
To do this using GHC we need pointer arithmetic, and the only way to implement pointer arithmetic in GHC is to use the Addr\# primitive. GHC/Haskell has one other slight overhead over Cee languages in that we need to move the culling array to a pinned array to avoid having it moved while the culling is going on and then move it back when finished but this takes a negligible amount of time (one percent or so) as compared to the culling. As usual for test programs, the culling operations are repeated in a loop for a number of times to give more accurate timing not influenced by execution not related to the culling. All of this is included in the following code (truncated as to loop coses for inclusion here):
```hs
-- EfficiencyBug.hs
-- showing that there is a register loop invariant bug in generation of assembler code...
-- LLVM shows the bug clearer since the code is generally a little faster...
{-# LANGUAGE FlexibleContexts, BangPatterns, MagicHash, UnboxedTuples #-}
{-# OPTIONS_GHC -O2 -rtsopts -keep-s-files #-} -- or -O2 -fllvm
import Data.Word
import Data.Bits
import Data.Array.ST (runSTUArray)
import Data.Array.Base
import GHC.ST ( ST(..) )
import GHC.Exts
numLOOPS = 10000 :: Int
-- Uses a very simple Sieve of Eratosthenes for fixed 2 ^ 18 range (so one L1 cache size) to prove it.
twos :: UArray Int Word32
twos = listArray (0, 31) [1 `shiftL` i | i <- [0 .. 31]]
soep1 :: () -> [Word32]
soep1() = 2 : [fromIntegral i * 2 + 3 | (i, False) <- assocs bufb] where
bufb = runSTUArray $ do
let bfBts = (256 * 1024) `div` 2 -- to 2^18 + 2 is 128 KBits = 16 KBytes
bf <- newArray (0, bfBts - 1) False :: ST s (STUArray s Int Bool)
cullb bf
cullb bf@(STUArray l u n marr#) = ST $ \s0# ->
case getSizeofMutableByteArray# marr# s0# of { (# s1#, n# #) ->
let loop t mr# s0# = -- cull a number of times to test timing
if t <= 0 then (# s0#, STUArray l u n mr# #) else
case getSizeofMutableByteArray# mr# s0# of { (# s1#, n# #) ->
case newPinnedByteArray# n# s1# of { (# s2#, marr'# #) ->
case copyMutableByteArray# mr# 0# marr'# 0# n# s2# of { s3# ->
case unsafeFreezeByteArray# marr'# s3# of { (# s4#, arr# #) -> -- must do this
case byteArrayContents# arr# of { adr# -> -- to obtain the addr# here
let cullp i@(I# i#) sp# =
let !p@(I# p#) = i + i + 3 in
let !s@(I# s#) = (p * p - 3) `div` 2 in
if s >= n then
case copyMutableByteArray# marr'# 0# mr# 0# n# sp# of
so# -> (# so#, mr# #) else
let !(UArray _ _ _ tarr#) = twos in
case readWord64Array# marr# (i# `uncheckedIShiftRL#` 6#) sp# of { (# sp0#, v0# #) ->
case (v0# `and#` ((int2Word# 1#) `uncheckedShiftL#` (i# `andI#` 63#))) `eqWord#` (int2Word# 0#) of
0# -> cullp (i + 1) sp0# -- not prime
_ -> -- is prime
-- most program execution time spent in the following tight loops.
-- the following code implments extream loop unrolling...
let !pi@(I# pi#) = fromIntegral p in
let !sw@(I# sw#) = s `shiftR` 3 in let !sb@(I# sb#) = s .&. 7 in
let p1 = sb + pi in let !(I# r1#) = p1 `shiftR` 3 in
let p2 = p1 + pi in let !(I# r2#) = p2 `shiftR` 3 in
let p3 = p2 + pi in let !(I# r3#) = p3 `shiftR` 3 in
let p4 = p3 + pi in let !(I# r4#) = p4 `shiftR` 3 in
let p5 = p4 + pi in let !(I# r5#) = p5 `shiftR` 3 in
let p6 = p5 + pi in let !(I# r6#) = p6 `shiftR` 3 in
let p7 = p6 + pi in let !(I# r7#) = p7 `shiftR` 3 in
let !lmt@(I# lmt#) = (fromIntegral n `shiftR` 3) - p7 in
let !lmt1# = plusAddr# adr# lmt# in
let !strt# = plusAddr# adr# sw# in
let !(I# n#) = n in
let (# !so#, !sco# #) = case ((((p - 1) `div` 2) .&. 3) `shiftL` 3) + sb of {
0 ->
let cull c# sp# =
case c# `ltAddr#` lmt1# of
0# -> (# c#, sp# #)
_ ->
case readWord8OffAddr# c# 0# sp# of { (# sp0#, v0# #) ->
case writeWord8OffAddr# c# 0# (v0# `or#` (int2Word# 1#)) sp0# of { sp1# ->
case readWord8OffAddr# c# r1# sp1# of { (# sp2#, v1# #) ->
case writeWord8OffAddr# c# r1# (v1# `or#` (int2Word# 2#)) sp2# of { sp3# ->
case readWord8OffAddr# c# r2# sp3# of { (# sp4#, v2# #) ->
case writeWord8OffAddr# c# r2# (v2# `or#` (int2Word# 4#)) sp4# of { sp5# ->
case readWord8OffAddr# c# r3# sp5# of { (# sp6#, v3# #) ->
case writeWord8OffAddr# c# r3# (v3# `or#` (int2Word# 8#)) sp6# of { sp7# ->
case readWord8OffAddr# c# r4# sp7# of { (# sp8#, v4# #) ->
case writeWord8OffAddr# c# r4# (v4# `or#` (int2Word# 16#)) sp8# of { sp9# ->
case readWord8OffAddr# c# r5# sp9# of { (# sp10#, v5# #) ->
case writeWord8OffAddr# c# r5# (v5# `or#` (int2Word# 32#)) sp10# of { sp11# ->
case readWord8OffAddr# c# r6# sp11# of { (# sp12#, v6# #) ->
case writeWord8OffAddr# c# r6# (v6# `or#` (int2Word# 64#)) sp12# of { sp13# ->
case readWord8OffAddr# c# r7# sp13# of { (# sp14#, v7# #) ->
case writeWord8OffAddr# c# r7# (v7# `or#` (int2Word# 128#)) sp14# of { sp15# ->
cull (plusAddr# c# pi#) sp15# }}}}}}}}}}}}}}}} in
cull strt# sp0#;
1 ->
let cull c# sp# =
case c# `ltAddr#` lmt1# of
0# -> (# c#, sp# #)
_ ->
case readWord8OffAddr# c# 0# sp# of { (# sp0#, v0# #) ->
case writeWord8OffAddr# c# 0# (v0# `or#` (int2Word# 2#)) sp0# of { sp1# ->
case readWord8OffAddr# c# r1# sp1# of { (# sp2#, v1# #) ->
case writeWord8OffAddr# c# r1# (v1# `or#` (int2Word# 4#)) sp2# of { sp3# ->
case readWord8OffAddr# c# r2# sp3# of { (# sp4#, v2# #) ->
case writeWord8OffAddr# c# r2# (v2# `or#` (int2Word# 8#)) sp4# of { sp5# ->
case readWord8OffAddr# c# r3# sp5# of { (# sp6#, v3# #) ->
case writeWord8OffAddr# c# r3# (v3# `or#` (int2Word# 16#)) sp6# of { sp7# ->
case readWord8OffAddr# c# r4# sp7# of { (# sp8#, v4# #) ->
case writeWord8OffAddr# c# r4# (v4# `or#` (int2Word# 32#)) sp8# of { sp9# ->
case readWord8OffAddr# c# r5# sp9# of { (# sp10#, v5# #) ->
case writeWord8OffAddr# c# r5# (v5# `or#` (int2Word# 64#)) sp10# of { sp11# ->
case readWord8OffAddr# c# r6# sp11# of { (# sp12#, v6# #) ->
case writeWord8OffAddr# c# r6# (v6# `or#` (int2Word# 128#)) sp12# of { sp13# ->
case readWord8OffAddr# c# r7# sp13# of { (# sp14#, v7# #) ->
case writeWord8OffAddr# c# r7# (v7# `or#` (int2Word# 1#)) sp14# of { sp15# ->
cull (plusAddr# c# pi#) sp15# }}}}}}}}}}}}}}}} in
cull strt# sp0#;
-- and so on for 30 more cases...
_ -> (# strt#, sp0# #) {- normally never taken case, all cases covered -} } in
let !ns# = ((minusAddr# so# adr#) `uncheckedIShiftL#` 3#) +# sb# in
-- extreme loop unrolling ends here; remaining primes culled conventionally...
let cull j# sc# = -- very tight inner loop
case j# <# n# of
0# -> cullp (i + 1) sc#
_ -> let i# = j# `andI#` 31# in
let !sh# = indexWord32Array# tarr# i# in -- (1 `shiftL` (j .&. 31)))
let w# = j# `uncheckedIShiftRL#` 5# in
case readWord32Array# marr'# w# sc# of { (# sc0#, ov# #) ->
case writeWord32Array# marr'# w# (ov# `or#` sh#) sc0# of { sc1# ->
cull (j# +# pi#) sc1# }} in
cull ns# sp0# } in
case cullp 0 s4# of (# sp#, mrp# #) -> loop (t - 1) mrp# sp# }}}}} in loop numLOOPS marr# s1# }
main = print $ length $ soep1()
```
**The problem:** The problem is in the innermost loop of the cases, for which case "0" the following assembly code (using -fllvm) is produced:
```
seGU_info$def:
# BB#0: # %cgRL
cmpq %r14, 70(%rbx)
jbe .LBB35_1
.align 16, 0x90
.LBB35_2: # %cgRJ
# =>This Inner Loop Header: Depth=1
movq 14(%rbx), %rcx
movq 22(%rbx), %rdx
movq 30(%rbx), %rsi
movq 38(%rbx), %rdi
movq 46(%rbx), %r8
movq 54(%rbx), %r9
movq 62(%rbx), %r10
movq 6(%rbx), %rax
addq %r14, %rax
orb $1, (%r14)
orb $2, (%rcx,%r14)
orb $4, (%rdx,%r14)
orb $8, (%rsi,%r14)
orb $16, (%rdi,%r14)
orb $32, (%r8,%r14)
orb $64, (%r9,%r14)
orb $-128, (%r10,%r14)
cmpq 70(%rbx), %rax
movq %rax, %r14
jb .LBB35_2
jmp .LBB35_3
.LBB35_1:
movq %r14, %rax
.LBB35_3: # %cgRK
movq (%rbp), %rcx
movq %rax, %rbx
rex64 jmpq *%rcx # TAILCALL
```
One can readily see that the compiler is not lifting the Loop Invariant Code Flow as in initializing the registers to outside the inner loop, meaning there are many register loads from memory which are not necessary.
**Desired results:** The desired assembly code is something like the following, which is similar to what is produced by Cee (C/C++/Rust/etc.):
```
seGU_info$def:
# BB#0: # %cgRL
movq 14(%rbx), %rcx
movq 22(%rbx), %rdx
movq 30(%rbx), %rsi
movq 38(%rbx), %rdi
movq 46(%rbx), %r8
movq 54(%rbx), %r9
movq 62(%rbx), %r10
movq 6(%rbx), %rax
movq 70(%rbx), %rbx
cmpq %r14, %rbx # rbx clobbered here, but old value
jbe .LBB35_1 # never used again until replaced after loop
.align 16, 0x90
.LBB35_2: # %cgRJ
# =>This Inner Loop Header: Depth=1
orb $1, (%r14)
orb $2, (%rcx,%r14)
orb $4, (%rdx,%r14)
orb $8, (%rsi,%r14)
orb $16, (%rdi,%r14)
orb $32, (%r8,%r14)
orb $64, (%r9,%r14)
orb $-128, (%r10,%r14)
addq %rax, %r14
cmpq %rbx, %r14
jb .LBB35_2
jmp .LBB35_3
.LBB35_1:
movq %r14, %rax
.LBB35_3: # %cgRK
movq (%rbp), %rcx
movq %rax, %rbx # rbx clobbered here anyway
rex64 jmpq *%rcx # TAILCALL
```
**Full testing:** The actual unrolled loop code including all the case loops is too long to post here, but to verify the result is correct (23000) and the performance, the full actual file is attached here. Due to the magic of modern CPU instruction fusion and Out Of Order (OOE) execution, the code is not as slow as it would indicate by the number of increased instructions, but while it is about twice as fast as when culled conventionally (Intel Skylake), it is about half again as slow as Cee. On an Intel Sky Lake i5-6500 (running at 3.5 GHz for single threading), this takes about one second, about two seconds culled conventionally, but only about 0.6 seconds for Rust/LLVM (with the assembly code output essentially identical to the "desired" code).
**Other back ends and targets:** Although the code generated by the native NCG has other problems (not moving the loop test to the end of the loop to avoid one jump, and not combining the read and modify and store instructions into the single available instruction), it exhibits the same problem as to not lifting the Loop Invariant Code Flow register initialization.
Although this code is x86_64, the problem also applies to x86 code even though the x86 architecture doesn't have enough registers to do this in one loop and needs to be split into two loops culling only four composites per loop, but there still is a significant gain in speed. Although not tested, it probably also applies to other targets such as ARM (which has many general purpose registers).
**Conclusion:** The use of Addr\# primitives is probably not a frequent use case, but as shown here that when one needs their use, they should be efficient.
I considered that GHC may intentionally limit the performance of these unsafe primitives to limit their use unless absolutely necessary as in marshalling, something as C\# does for the use of unsafe pointers, but surely GHC would not do that as the target programmers are different.
**If this and ticket #12798 were fixed, for this use case the GHC code would be within a percent or two of the performance of Cee.**https://gitlab.haskell.org/ghc/ghc/-/issues/12807GHC is too verbose by default (source/object paths)2019-07-07T18:25:04ZSylvain HenryGHC is too verbose by default (source/object paths)With the default verbosity, GHC shows the path of the source file and the path of the object file (or "interpreted" in GHCi) making the lines very long as in the following example:
```
[133 of 159] Compiling ViperVM.Arch.Linux.Internals...With the default verbosity, GHC shows the path of the source file and the path of the object file (or "interpreted" in GHCi) making the lines very long as in the following example:
```
[133 of 159] Compiling ViperVM.Arch.Linux.Internals.Input ( src/lib/ViperVM/Arch/Linux/Internals/Input.hs, .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/ViperVM/Arch/Linux/Internals/Input.o )
[134 of 159] Compiling ViperVM.Arch.Linux.Input ( src/lib/ViperVM/Arch/Linux/Input.hs, .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/ViperVM/Arch/Linux/Input.o )
[135 of 159] Compiling ViperVM.System.Input ( src/lib/ViperVM/System/Input.hs, .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/ViperVM/System/Input.o )
[136 of 159] Compiling ViperVM.Arch.Linux.Internals.Sound ( src/lib/ViperVM/Arch/Linux/Internals/Sound.hs, .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/ViperVM/Arch/Linux/Internals/Sound.o )
[137 of 159] Compiling ViperVM.Arch.Linux.Internals.Graphics ( src/lib/ViperVM/Arch/Linux/Internals/Graphics.hs, .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/ViperVM/Arch/Linux/Internals/Graphics.o )
```
In most cases, I think we don't need these paths. I propose that we keep this output for the verbose mode and that we change the default behaviour to something like:
```
[135 of 159] Compiling ViperVM.System.Input (.hs -> .o)
[136 of 159] Compiling ViperVM.Arch.Linux.Internals.Sound (.hs -> .o)
-- GHCi
[137 of 159] Compiling ViperVM.Arch.Linux.Internals.Graphics (.hs -> interpreted)
```
It is also particularily nice with BackPack that uses hashes in output paths: we may not want to expose them to users by default. Example:
```patch
[1 of 1] Including p[A=r:A]
Instantiating p[A=r:A]
- [1 of 2] Compiling A[sig] ( p/A.hsig, bkp26.out/p/p-8YQRY0unRYZCev5HBjXieS/A.o )
- [2 of 2] Compiling P ( p/P.hs, bkp26.out/p/p-8YQRY0unRYZCev5HBjXieS/P.o )
- [1 of 1] Compiling M ( q/M.hs, bkp26.out/q/M.o )
+ [1 of 2] Compiling A[sig] (.hsig -> .o)
+ [2 of 2] Compiling P (.hs -> .o)
+ [1 of 1] Compiling M (.hs -> .o)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.0.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC is too verbose by default (source/object paths)","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"hsyl20"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"With the default verbosity, GHC shows the path of the source file and the path of the object file (or \"interpreted\" in GHCi) making the lines very long as in the following example:\r\n\r\n{{{\r\n[133 of 159] Compiling ViperVM.Arch.Linux.Internals.Input ( src/lib/ViperVM/Arch/Linux/Internals/Input.hs, .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/ViperVM/Arch/Linux/Internals/Input.o )\r\n[134 of 159] Compiling ViperVM.Arch.Linux.Input ( src/lib/ViperVM/Arch/Linux/Input.hs, .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/ViperVM/Arch/Linux/Input.o )\r\n[135 of 159] Compiling ViperVM.System.Input ( src/lib/ViperVM/System/Input.hs, .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/ViperVM/System/Input.o )\r\n[136 of 159] Compiling ViperVM.Arch.Linux.Internals.Sound ( src/lib/ViperVM/Arch/Linux/Internals/Sound.hs, .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/ViperVM/Arch/Linux/Internals/Sound.o )\r\n[137 of 159] Compiling ViperVM.Arch.Linux.Internals.Graphics ( src/lib/ViperVM/Arch/Linux/Internals/Graphics.hs, .stack-work/dist/x86_64-linux/Cabal-1.24.0.0/build/ViperVM/Arch/Linux/Internals/Graphics.o )\r\n}}}\r\n\r\nIn most cases, I think we don't need these paths. I propose that we keep this output for the verbose mode and that we change the default behaviour to something like:\r\n{{{\r\n[135 of 159] Compiling ViperVM.System.Input (.hs -> .o)\r\n[136 of 159] Compiling ViperVM.Arch.Linux.Internals.Sound (.hs -> .o)\r\n-- GHCi\r\n[137 of 159] Compiling ViperVM.Arch.Linux.Internals.Graphics (.hs -> interpreted)\r\n}}}\r\n\r\nIt is also particularily nice with BackPack that uses hashes in output paths: we may not want to expose them to users by default. Example:\r\n\r\n{{{#!patch\r\n [1 of 1] Including p[A=r:A]\r\n Instantiating p[A=r:A]\r\n- [1 of 2] Compiling A[sig] ( p/A.hsig, bkp26.out/p/p-8YQRY0unRYZCev5HBjXieS/A.o )\r\n- [2 of 2] Compiling P ( p/P.hs, bkp26.out/p/p-8YQRY0unRYZCev5HBjXieS/P.o )\r\n- [1 of 1] Compiling M ( q/M.hs, bkp26.out/q/M.o )\r\n+ [1 of 2] Compiling A[sig] (.hsig -> .o)\r\n+ [2 of 2] Compiling P (.hs -> .o)\r\n+ [1 of 1] Compiling M (.hs -> .o)\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->Sylvain HenrySylvain Henry