GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:38:44Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/9860Package flags not command line completable in 7.82019-07-07T18:38:44Zkolmodin@dtek.chalmers.sePackage flags not command line completable in 7.8Passing `--show-options` to ghc shows all the flags that ghc understands.
Unfortunately `--show-options` does not list the package flags, `-package-db -package-id` etc.
Requires a 1 line fix in `ghc/Main.hs`.
<details><summary>Trac me...Passing `--show-options` to ghc shows all the flags that ghc understands.
Unfortunately `--show-options` does not list the package flags, `-package-db -package-id` etc.
Requires a 1 line fix in `ghc/Main.hs`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Package flags not command line completable in 7.8","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"7.8.4","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Passing `--show-options` to ghc shows all the flags that ghc understands.\r\n\r\nUnfortunately `--show-options` does not list the package flags, `-package-db -package-id` etc.\r\n\r\nRequires a 1 line fix in `ghc/Main.hs`.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.4kolmodin@dtek.chalmers.sekolmodin@dtek.chalmers.sehttps://gitlab.haskell.org/ghc/ghc/-/issues/9817signal handlers in unix are passed garbage when using the signle threaded rts2023-09-09T22:39:58Zrednebsignal handlers in unix are passed garbage when using the signle threaded rtsWhen a signal handler (registered with `GHC.Conc.Signal.setHandler`) is called upon the receipt of the relevant signal, it is passed a memory buffer in the form of a `ForeignPtr Word8`. This buffer contains a copy of the `siginfo_t` stru...When a signal handler (registered with `GHC.Conc.Signal.setHandler`) is called upon the receipt of the relevant signal, it is passed a memory buffer in the form of a `ForeignPtr Word8`. This buffer contains a copy of the `siginfo_t` struct that was originally passed to the underlying os signal handler. Unfortunately, this only seems to work correctly in the threaded rts. In the single-threaded rts, the buffer contains garbage. This can be demonstrated by the following program:
```hs
import Control.Concurrent
import System.Posix.Signals
main :: IO ()
main = do
wait <- newEmptyMVar
_ <- flip (installHandler sig) Nothing $ CatchInfo $ \info -> do
putStrLn $ "Received a signal " ++ show (siginfoSignal info)
putMVar wait ()
raiseSignal sig
putStrLn $ "Sending myself a signal " ++ show sig
takeMVar wait
where
sig = sigUSR2
```
If you compile the program with the `-threaded` flag then everything works just fine:
```
Sending myself a signal 12
Received a signal 12
```
but without it, the signal handler will print a totaly random signal number:
```
Sending myself a signal 12
Received a signal 138644296
```
I was able to track this down to the function `startSignalHandlers` in `rts/posix/Signals.c`. This function (which is only used by the single threaded rts) allocates a buffer and copies the `siginfo_t` struct to it and then schedules `GHC.Conc.Signal.runHandlers` to be run in a new thread. The problem is that while `GHC.Conc.Signal.runHandlers` expects a `ForeignPtr Word8`, here it is given a `Ptr Word8`. This has two implications: the signal handler is given invalid data, and nobody is deallocating the buffer so we are leaking memory every time a signal is received that has a custom handler.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.8.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | simonmar |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"signal handlers in unix are passed garbage when using the signle threaded rts","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"simonmar"},"version":"7.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["simonmar"],"type":"Bug","description":"When a signal handler (registered with `GHC.Conc.Signal.setHandler`) is called upon the receipt of the relevant signal, it is passed a memory buffer in the form of a `ForeignPtr Word8`. This buffer contains a copy of the `siginfo_t` struct that was originally passed to the underlying os signal handler. Unfortunately, this only seems to work correctly in the threaded rts. In the single-threaded rts, the buffer contains garbage. This can be demonstrated by the following program:\r\n\r\n{{{#!hs\r\nimport Control.Concurrent\r\nimport System.Posix.Signals\r\n\r\nmain :: IO ()\r\nmain = do\r\n wait <- newEmptyMVar\r\n _ <- flip (installHandler sig) Nothing $ CatchInfo $ \\info -> do\r\n putStrLn $ \"Received a signal \" ++ show (siginfoSignal info)\r\n putMVar wait ()\r\n raiseSignal sig\r\n putStrLn $ \"Sending myself a signal \" ++ show sig\r\n takeMVar wait\r\n where\r\n sig = sigUSR2\r\n}}}\r\n\r\nIf you compile the program with the `-threaded` flag then everything works just fine:\r\n{{{\r\nSending myself a signal 12\r\nReceived a signal 12\r\n}}}\r\nbut without it, the signal handler will print a totaly random signal number:\r\n{{{\r\nSending myself a signal 12\r\nReceived a signal 138644296\r\n}}}\r\n\r\nI was able to track this down to the function `startSignalHandlers` in `rts/posix/Signals.c`. This function (which is only used by the single threaded rts) allocates a buffer and copies the `siginfo_t` struct to it and then schedules `GHC.Conc.Signal.runHandlers` to be run in a new thread. The problem is that while `GHC.Conc.Signal.runHandlers` expects a `ForeignPtr Word8`, here it is given a `Ptr Word8`. This has two implications: the signal handler is given invalid data, and nobody is deallocating the buffer so we are leaking memory every time a signal is received that has a custom handler.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.4Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/9705Panic on a pattern synonym in a class2019-07-07T18:39:22ZKrzysztof GogolewskiPanic on a pattern synonym in a classThis silly code causes a panic in rnMethodBind:
```hs
{-# LANGUAGE PatternSynonyms #-}
class C a where
pattern P = ()
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- |...This silly code causes a panic in rnMethodBind:
```hs
{-# LANGUAGE PatternSynonyms #-}
class C a where
pattern P = ()
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Panic on a pattern synonym in a class","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This silly code causes a panic in rnMethodBind:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE PatternSynonyms #-}\r\nclass C a where\r\n pattern P = ()\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->7.8.4Gergő ÉrdiGergő Érdihttps://gitlab.haskell.org/ghc/ghc/-/issues/9658Prettyprint constraints in type signatures can omit necessary parentheses2019-07-07T18:39:37ZBlaisorbladePrettyprint constraints in type signatures can omit necessary parenthesesGHCi prettyprinting can omit parentheses around constraints, even when they are necessary for the signature to be syntactically valid. This breaks the workflow where one uses type inference to generate type annotations to add to the prog...GHCi prettyprinting can omit parentheses around constraints, even when they are necessary for the signature to be syntactically valid. This breaks the workflow where one uses type inference to generate type annotations to add to the program. Admittedly, this is nitpicking, but it'd be nice to fix.
The example I'm running into is the following (in the context of https://github.com/Blaisorblade/learning-syntactic/blob/e198381e07103d436f4ade24f36d344682dbe5b1/src/Syntactic.hs):
```hs
num = inj . Num
> :t num
num :: NUM :<: sup => Int -> sup (Full Int)
```
Adding the type annotation in gives:
```
src/Syntactic.hs:115:20: parse error on input `=>'
```
To fix the parse error, I need to add parentheses around the constraint:
```hs
num :: (NUM :<: sup) => Int -> sup (Full Int)
```
(Here this happens to be the wrong type signature, but that's orthogonal).
I imagine that's just because the constraint uses an operator (probably only possible with TypeOperators).
This happens whether I explicitly supply the signature or not, and it also happens on GHC 7.6.3.
Misc: I selected milestone, difficulty, priority because it's possible and because fixing this sounds easy; sorry if I shouldn't have. I also didn't check whether this affects HEAD.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | hvr |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Prettyprint constraints in type signatures can omit necessary parentheses","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"7.8.4","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["hvr"],"type":"Bug","description":"GHCi prettyprinting can omit parentheses around constraints, even when they are necessary for the signature to be syntactically valid. This breaks the workflow where one uses type inference to generate type annotations to add to the program. Admittedly, this is nitpicking, but it'd be nice to fix.\r\n\r\nThe example I'm running into is the following (in the context of https://github.com/Blaisorblade/learning-syntactic/blob/e198381e07103d436f4ade24f36d344682dbe5b1/src/Syntactic.hs):\r\n\r\n{{{#!hs\r\nnum = inj . Num\r\n\r\n> :t num\r\nnum :: NUM :<: sup => Int -> sup (Full Int)\r\n}}}\r\n\r\nAdding the type annotation in gives:\r\n\r\n{{{\r\nsrc/Syntactic.hs:115:20: parse error on input `=>'\r\n}}}\r\nTo fix the parse error, I need to add parentheses around the constraint:\r\n\r\n{{{#!hs\r\nnum :: (NUM :<: sup) => Int -> sup (Full Int)\r\n}}}\r\n(Here this happens to be the wrong type signature, but that's orthogonal).\r\n\r\nI imagine that's just because the constraint uses an operator (probably only possible with TypeOperators).\r\n\r\nThis happens whether I explicitly supply the signature or not, and it also happens on GHC 7.6.3.\r\n\r\nMisc: I selected milestone, difficulty, priority because it's possible and because fixing this sounds easy; sorry if I shouldn't have. I also didn't check whether this affects HEAD.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.4https://gitlab.haskell.org/ghc/ghc/-/issues/9620libffi.a is put in the wrong folder2019-07-07T18:39:47Zrezb1tlibffi.a is put in the wrong folderThis is dfeuer's error message, but it is equivalent to mine on NixOS x86_64
```
"/home/dfeuer/GHC/7.8.3.bin/bin/ghc" -o utils/genapply/dist/build/tmp/genapply -hisuf hi -osuf o -hcsuf hc -static -O -H64m -package pretty -package-db l...This is dfeuer's error message, but it is equivalent to mine on NixOS x86_64
```
"/home/dfeuer/GHC/7.8.3.bin/bin/ghc" -o utils/genapply/dist/build/tmp/genapply -hisuf hi -osuf o -hcsuf hc -static -O -H64m -package pretty -package-db libraries/bootstrapping.conf -i -iutils/genapply/. -iutils/genapply/dist/build -iutils/genapply/dist/build/autogen -Iutils/genapply/dist/build -Iutils/genapply/dist/build/autogen -no-user-package-db -rtsopts -odir utils/genapply/dist/build -hidir utils/genapply/dist/build -stubdir utils/genapply/dist/build -static -O -H64m -package pretty -package-db libraries/bootstrapping.conf -i -iutils/genapply/. -iutils/genapply/dist/build -iutils/genapply/dist/build/autogen -Iutils/genapply/dist/build -Iutils/genapply/dist/build/autogen -no-user-package-db -rtsopts utils/genapply/dist/build/GenApply.o
libffi/stamp.ffi.static-shared.install exists, but libffi/build/inst/lib/libffi.a does not.
Suggest removing libffi/stamp.ffi.static-shared.install.
make[1]: *** [libffi/build/inst/lib/libffi.a] Error 1
make[1]: *** Waiting for unfinished jobs....
make: *** [all] Error 2
```
libffi.a is build and linked into libffi/build/inst/lib64 instead of libffi/build/inst/lib, but the includes and pkg-config specific stuff is still put into libffi/build/inst/lib. GHC looks in lib for libffi.a and fails, the current workaround is to copy the contents of libffi/build/inst/lib64 into libffi/build/inst/lib and type make again. Symlinking won't work because libffi seems to sanitize the build directory before building the library
I'd like to note that when compiling via the Debian source snapshot, libffi is put in the correct place if I run ./configure without using perl boot.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.9 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"libffi.a is put in the wrong folder","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"7.10.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.9","keywords":["lib64","libffi","nixos"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This is dfeuer's error message, but it is equivalent to mine on NixOS x86_64\r\n\r\n{{{\r\n\"/home/dfeuer/GHC/7.8.3.bin/bin/ghc\" -o utils/genapply/dist/build/tmp/genapply -hisuf hi -osuf o -hcsuf hc -static -O -H64m -package pretty -package-db libraries/bootstrapping.conf -i -iutils/genapply/. -iutils/genapply/dist/build -iutils/genapply/dist/build/autogen -Iutils/genapply/dist/build -Iutils/genapply/dist/build/autogen -no-user-package-db -rtsopts -odir utils/genapply/dist/build -hidir utils/genapply/dist/build -stubdir utils/genapply/dist/build -static -O -H64m -package pretty -package-db libraries/bootstrapping.conf -i -iutils/genapply/. -iutils/genapply/dist/build -iutils/genapply/dist/build/autogen -Iutils/genapply/dist/build -Iutils/genapply/dist/build/autogen -no-user-package-db -rtsopts utils/genapply/dist/build/GenApply.o \r\nlibffi/stamp.ffi.static-shared.install exists, but libffi/build/inst/lib/libffi.a does not.\r\nSuggest removing libffi/stamp.ffi.static-shared.install.\r\nmake[1]: *** [libffi/build/inst/lib/libffi.a] Error 1\r\nmake[1]: *** Waiting for unfinished jobs....\r\nmake: *** [all] Error 2\r\n}}}\r\n\r\nlibffi.a is build and linked into libffi/build/inst/lib64 instead of libffi/build/inst/lib, but the includes and pkg-config specific stuff is still put into libffi/build/inst/lib. GHC looks in lib for libffi.a and fails, the current workaround is to copy the contents of libffi/build/inst/lib64 into libffi/build/inst/lib and type make again. Symlinking won't work because libffi seems to sanitize the build directory before building the library\r\n\r\nI'd like to note that when compiling via the Debian source snapshot, libffi is put in the correct place if I run ./configure without using perl boot.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.4https://gitlab.haskell.org/ghc/ghc/-/issues/9575-XAutoDeriveTypeable fails to generate instances2019-07-07T18:39:57ZHerbert Valerio Riedelhvr@gnu.org-XAutoDeriveTypeable fails to generate instancesThe following doesn't compile with GHC 7.8.3, but works with GHC HEAD. I couldn't find a matching ticket, so I don't know if this was fixed knowingly or not...
```hs
{-# LANGUAGE AutoDeriveTypeable #-}
import Data.Typeable (Typeable)
...The following doesn't compile with GHC 7.8.3, but works with GHC HEAD. I couldn't find a matching ticket, so I don't know if this was fixed knowingly or not...
```hs
{-# LANGUAGE AutoDeriveTypeable #-}
import Data.Typeable (Typeable)
data T1 = C1 Int
deriving (Eq,Ord)
tvoid :: Typeable a => a -> IO ()
tvoid _ = return ()
main :: IO ()
main = tvoid (C1 0)
```
1. ..fails for GHC 7.8.3 with
```
No instance for (Typeable T1) arising from a use of ‘tvoid’
In the expression: tvoid (C1 0)
In an equation for ‘main’: main = tvoid (C1 0)
```
I'm marking this with high priority, as it makes `-XAutoDeriveTypeable` unusable on GHC 7.8.3 as it stands.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.3 |
| 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":"-XAutoDeriveTypeable fails to generate instances","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"7.8.4","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The following doesn't compile with GHC 7.8.3, but works with GHC HEAD. I couldn't find a matching ticket, so I don't know if this was fixed knowingly or not...\r\n\r\n{{{#!hs\r\n{-# LANGUAGE AutoDeriveTypeable #-}\r\n\r\nimport Data.Typeable (Typeable)\r\n\r\ndata T1 = C1 Int\r\n deriving (Eq,Ord)\r\n\r\ntvoid :: Typeable a => a -> IO ()\r\ntvoid _ = return ()\r\n\r\nmain :: IO ()\r\nmain = tvoid (C1 0)\r\n}}}\r\n\r\n...fails for GHC 7.8.3 with\r\n\r\n{{{\r\n No instance for (Typeable T1) arising from a use of ‘tvoid’\r\n In the expression: tvoid (C1 0)\r\n In an equation for ‘main’: main = tvoid (C1 0)\r\n}}}\r\n\r\nI'm marking this with high priority, as it makes `-XAutoDeriveTypeable` unusable on GHC 7.8.3 as it stands.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.4dreixeldreixelhttps://gitlab.haskell.org/ghc/ghc/-/issues/9563Support for deriving Generic1 for data families2019-07-07T18:40:00ZmnislaihSupport for deriving Generic1 for data familiesThe following code:
```hs
import GHC.Generics
data family F typ :: * -> *
data A
data instance F A a = AData a deriving Generic1
```
produces an error when run with ghc 7.8.2 or 7.8.3:
```
Couldn't match type ‘Rep1 (F A)’
...The following code:
```hs
import GHC.Generics
data family F typ :: * -> *
data A
data instance F A a = AData a deriving Generic1
```
produces an error when run with ghc 7.8.2 or 7.8.3:
```
Couldn't match type ‘Rep1 (F A)’
with ‘M1 t0 t1 (M1 t2 t3 (M1 t4 t5 Par1))’
The type variables ‘t0’, ‘t1’, ‘t2’, ‘t3’, ‘t4’, ‘t5’ are ambiguous
Expected type: Rep1 (F A) a
Actual type: M1 t0 t1 (M1 t2 t3 (M1 t4 t5 Par1)) a
In the pattern: M1 (M1 (M1 g1))
In an equation for ‘to1’: to1 (M1 (M1 (M1 g1))) = AData (unPar1 g1)
In the instance declaration for ‘Generic1 (F A)’
```
whereas ghc 7.6.3 simply refuses to go ahead with the message:
```
generic1.hs:14:40:
Derived instance `Generic1 (F A)'
requires illegal partial application of data type family F
In the data instance declaration for `F'
```
Either a check has gone missing in 7.8.x, or a bug has crept up in the Generic1 support. I have gone through past tickets and #5936 suggests that it is the latter.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Support for deriving Generic1 for data families","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The following code:\r\n{{{#!hs\r\n\r\nimport GHC.Generics\r\n\r\ndata family F typ :: * -> *\r\ndata A\r\ndata instance F A a = AData a deriving Generic1\r\n}}}\r\nproduces an error when run with ghc 7.8.2 or 7.8.3:\r\n{{{\r\nCouldn't match type ‘Rep1 (F A)’\r\n with ‘M1 t0 t1 (M1 t2 t3 (M1 t4 t5 Par1))’\r\nThe type variables ‘t0’, ‘t1’, ‘t2’, ‘t3’, ‘t4’, ‘t5’ are ambiguous\r\nExpected type: Rep1 (F A) a\r\n Actual type: M1 t0 t1 (M1 t2 t3 (M1 t4 t5 Par1)) a\r\nIn the pattern: M1 (M1 (M1 g1))\r\nIn an equation for ‘to1’: to1 (M1 (M1 (M1 g1))) = AData (unPar1 g1)\r\nIn the instance declaration for ‘Generic1 (F A)’\r\n}}}\r\n\r\nwhereas ghc 7.6.3 simply refuses to go ahead with the message:\r\n{{{\r\n\r\ngeneric1.hs:14:40:\r\n Derived instance `Generic1 (F A)'\r\n requires illegal partial application of data type family F\r\n In the data instance declaration for `F'\r\n}}}\r\n\r\nEither a check has gone missing in 7.8.x, or a bug has crept up in the Generic1 support. I have gone through past tickets and https://ghc.haskell.org/trac/ghc/ticket/5936 suggests that it is the latter.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.4dreixeldreixelhttps://gitlab.haskell.org/ghc/ghc/-/issues/9552powerpc64 little endian: dll-split: Reachable modules from DynFlags out of date2019-07-07T18:40:03ZPeter Trommlerptrommler@acm.orgpowerpc64 little endian: dll-split: Reachable modules from DynFlags out of dateBuilding ghc for powerpc64 little endian (powerpc64le) on Linux fails:
```
inplace/bin/dll-split compiler/stage2/build/.depend-v-dyn.haskell "DynFlags" "Annotations Avail Bag BasicTypes BinIface Binary Bitmap BlockId BooleanFormula Brea...Building ghc for powerpc64 little endian (powerpc64le) on Linux fails:
```
inplace/bin/dll-split compiler/stage2/build/.depend-v-dyn.haskell "DynFlags" "Annotations Avail Bag BasicTypes BinIface Binary Bitmap BlockId BooleanFormula BreakArray BufWrite BuildTyCl ByteCodeAsm ByteCodeInstr ByteCodeItbls CLabel Class CmdLineParser Cmm CmmCallConv CmmExpr CmmInfo CmmMachOp CmmNode CmmType CmmUtils CoAxiom ConLike CodeGen.Platform CodeGen.Platform.ARM CodeGen.Platform.NoRegs CodeGen.Platform.PPC CodeGen.Platform.PPC_Darwin CodeGen.Platform.SPARC CodeGen.Platform.X86 CodeGen.Platform.X86_64 Coercion Config Constants CoreArity CoreFVs CoreLint CoreSubst CoreSyn CoreTidy CoreUnfold CoreUtils CostCentre DataCon Demand Digraph DriverPhases DsMonad DynFlags Encoding ErrUtils Exception ExtsCompat46 FamInstEnv FastBool FastFunctions FastMutInt FastString FastTypes Finder Fingerprint FiniteMap ForeignCall Hooks Hoopl Hoopl.Dataflow HsBinds HsDecls HsDoc HsExpr HsImpExp HsLit HsPat HsSyn HsTypes HsUtils HscTypes IOEnv Id IdInfo IfaceEnv IfaceSyn IfaceType InstEnv InteractiveEvalTypes Kind ListSetOps Literal LoadIface Maybes MkCore MkGraph MkId Module MonadUtils Name NameEnv NameSet OccName OccurAnal OptCoercion OrdList Outputable PackageConfig Packages Pair Panic PatSyn PipelineMonad Platform PlatformConstants PprCmm PprCmmDecl PprCmmExpr PprCore PrelInfo PrelNames PrelRules Pretty PrimOp RdrName Reg RegClass Rules SMRep Serialized SrcLoc StaticFlags StgCmmArgRep StgCmmClosure StgCmmEnv StgCmmLayout StgCmmMonad StgCmmProf StgCmmTicky StgCmmUtils StgSyn Stream StringBuffer TcEvidence TcIface TcRnMonad TcRnTypes TcType TcTypeNats TrieMap TyCon Type TypeRep TysPrim TysWiredIn Unify UniqFM UniqSet UniqSupply Unique Util Var VarEnv VarSet"
Reachable modules from DynFlags out of date
Please fix compiler/ghc.mk, or building DLLs on Windows may break (#7780)
Redundant modules: Bitmap BlockId ByteCodeAsm ByteCodeInstr ByteCodeItbls CLabel Cmm CmmCallConv CmmExpr CmmInfo CmmMachOp CmmNode CmmUtils CodeGen.Platform CodeGen.Platform.ARM CodeGen.Platform.NoRegs CodeGen.Platform.PPC CodeGen.Platform.PPC_Darwin CodeGen.Platform.SPARC CodeGen.Platform.X86 CodeGen.Platform.X86_64 FastBool Hoopl Hoopl.Dataflow InteractiveEvalTypes MkGraph PprCmm PprCmmDecl PprCmmExpr Reg RegClass SMRep StgCmmArgRep StgCmmClosure StgCmmEnv StgCmmLayout StgCmmMonad StgCmmProf StgCmmTicky StgCmmUtils StgSyn Stream
compiler/ghc.mk:640: recipe for target 'compiler/stage2/dll-split.stamp' failed
```
The same build, however, works for big endian powerpc64 which is also an unregisterised build via C code.
Both builds were done with `GHC_DYNAMIC_PROGRAMS=YES` in `mk/build.mk`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | Other |
</details>
<!-- {"blocked_by":[],"summary":"powerpc64 little endian: dll-split: Reachable modules from DynFlags out of date","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"Other","cc":[""],"type":"Bug","description":"Building ghc for powerpc64 little endian (powerpc64le) on Linux fails:\r\n\r\n{{{\r\ninplace/bin/dll-split compiler/stage2/build/.depend-v-dyn.haskell \"DynFlags\" \"Annotations Avail Bag BasicTypes BinIface Binary Bitmap BlockId BooleanFormula BreakArray BufWrite BuildTyCl ByteCodeAsm ByteCodeInstr ByteCodeItbls CLabel Class CmdLineParser Cmm CmmCallConv CmmExpr CmmInfo CmmMachOp CmmNode CmmType CmmUtils CoAxiom ConLike CodeGen.Platform CodeGen.Platform.ARM CodeGen.Platform.NoRegs CodeGen.Platform.PPC CodeGen.Platform.PPC_Darwin CodeGen.Platform.SPARC CodeGen.Platform.X86 CodeGen.Platform.X86_64 Coercion Config Constants CoreArity CoreFVs CoreLint CoreSubst CoreSyn CoreTidy CoreUnfold CoreUtils CostCentre DataCon Demand Digraph DriverPhases DsMonad DynFlags Encoding ErrUtils Exception ExtsCompat46 FamInstEnv FastBool FastFunctions FastMutInt FastString FastTypes Finder Fingerprint FiniteMap ForeignCall Hooks Hoopl Hoopl.Dataflow HsBinds HsDecls HsDoc HsExpr HsImpExp HsLit HsPat HsSyn HsTypes HsUtils HscTypes IOEnv Id IdInfo IfaceEnv IfaceSyn IfaceType InstEnv InteractiveEvalTypes Kind ListSetOps Literal LoadIface Maybes MkCore MkGraph MkId Module MonadUtils Name NameEnv NameSet OccName OccurAnal OptCoercion OrdList Outputable PackageConfig Packages Pair Panic PatSyn PipelineMonad Platform PlatformConstants PprCmm PprCmmDecl PprCmmExpr PprCore PrelInfo PrelNames PrelRules Pretty PrimOp RdrName Reg RegClass Rules SMRep Serialized SrcLoc StaticFlags StgCmmArgRep StgCmmClosure StgCmmEnv StgCmmLayout StgCmmMonad StgCmmProf StgCmmTicky StgCmmUtils StgSyn Stream StringBuffer TcEvidence TcIface TcRnMonad TcRnTypes TcType TcTypeNats TrieMap TyCon Type TypeRep TysPrim TysWiredIn Unify UniqFM UniqSet UniqSupply Unique Util Var VarEnv VarSet\"\r\n\r\nReachable modules from DynFlags out of date\r\nPlease fix compiler/ghc.mk, or building DLLs on Windows may break (#7780)\r\nRedundant modules: Bitmap BlockId ByteCodeAsm ByteCodeInstr ByteCodeItbls CLabel Cmm CmmCallConv CmmExpr CmmInfo CmmMachOp CmmNode CmmUtils CodeGen.Platform CodeGen.Platform.ARM CodeGen.Platform.NoRegs CodeGen.Platform.PPC CodeGen.Platform.PPC_Darwin CodeGen.Platform.SPARC CodeGen.Platform.X86 CodeGen.Platform.X86_64 FastBool Hoopl Hoopl.Dataflow InteractiveEvalTypes MkGraph PprCmm PprCmmDecl PprCmmExpr Reg RegClass SMRep StgCmmArgRep StgCmmClosure StgCmmEnv StgCmmLayout StgCmmMonad StgCmmProf StgCmmTicky StgCmmUtils StgSyn Stream\r\ncompiler/ghc.mk:640: recipe for target 'compiler/stage2/dll-split.stamp' failed\r\n}}}\r\n\r\nThe same build, however, works for big endian powerpc64 which is also an unregisterised build via C code.\r\n\r\nBoth builds were done with `GHC_DYNAMIC_PROGRAMS=YES` in `mk/build.mk`.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.4https://gitlab.haskell.org/ghc/ghc/-/issues/9523Typo in GHC Generics documentation2019-07-07T18:40:10ZDavid FeuerTypo in GHC Generics documentationIn `GHC.Generics`:
The types `S`, `C` and `R` are once again type-level proxies, just used to create several variants of `M1`.
The `R`, it seems, is supposed to be a `D`.
<details><summary>Trac metadata</summary>
| Trac field ...In `GHC.Generics`:
The types `S`, `C` and `R` are once again type-level proxies, just used to create several variants of `M1`.
The `R`, it seems, is supposed to be a `D`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 7.8.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Documentation |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Typo in GHC Generics documentation","status":"New","operating_system":"","component":"Documentation","related":[],"milestone":"7.8.4","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"In `GHC.Generics`:\r\n\r\n The types `S`, `C` and `R` are once again type-level proxies, just used to create several variants of `M1`.\r\n\r\nThe `R`, it seems, is supposed to be a `D`.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.4https://gitlab.haskell.org/ghc/ghc/-/issues/9439LlvmCodegen: Overzealous mangler incorrectly transforms user code2019-07-07T18:40:23ZBen GamariLlvmCodegen: Overzealous mangler incorrectly transforms user codeIn an attempt to close #4210 the LLVM code generator's mangler was modified in
ed67d290e7389bd87a6feea269a0275e0f0f5e2f to rewrite symbol types from `@function` to `@object`. This was done in order to prevent the linker from sending refe...In an attempt to close #4210 the LLVM code generator's mangler was modified in
ed67d290e7389bd87a6feea269a0275e0f0f5e2f to rewrite symbol types from `@function` to `@object`. This was done in order to prevent the linker from sending reference through the PLT which breaks info tables.
Unfortunately, this mangling was a simple text replacement of `@function` to `@object` in the assembler produced by LLVM and made no attempt to distinguish `.type` directives (which the mangling targets) from other occurrences of the token. As rwbarton unfortunately found out, this means that any occurrences of `"@function"` in user code (e.g. the LLVM backend itself while compiling GHC) will be rewritten to `"@object"` in the produced object. Hilarity ensues.
This can be demonstrated by the simple test `main = putStrLn "@function"`, which prints `@object` in the affected releases (7.8.1 through 7.8.3 thusfar).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | --------------- |
| Version | 7.8.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (LLVM) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"LlvmCodegen: Overzealous mangler incorrectly transforms user code","status":"New","operating_system":"","component":"Compiler (LLVM)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"In an attempt to close #4210 the LLVM code generator's mangler was modified in \r\ned67d290e7389bd87a6feea269a0275e0f0f5e2f to rewrite symbol types from `@function` to `@object`. This was done in order to prevent the linker from sending reference through the PLT which breaks info tables.\r\n\r\nUnfortunately, this mangling was a simple text replacement of `@function` to `@object` in the assembler produced by LLVM and made no attempt to distinguish `.type` directives (which the mangling targets) from other occurrences of the token. As rwbarton unfortunately found out, this means that any occurrences of `\"@function\"` in user code (e.g. the LLVM backend itself while compiling GHC) will be rewritten to `\"@object\"` in the produced object. Hilarity ensues.\r\n\r\nThis can be demonstrated by the simple test `main = putStrLn \"@function\"`, which prints `@object` in the affected releases (7.8.1 through 7.8.3 thusfar).","type_of_failure":"OtherFailure","blocking":[]} -->7.8.4https://gitlab.haskell.org/ghc/ghc/-/issues/9435x86 sse4.2 popCnt16# needs to zero-extend its result2019-07-07T18:40:24Zrwbartonx86 sse4.2 popCnt16# needs to zero-extend its result`make TEST=cgrun071 EXTRA_HC_OPTS=-msse42` fails for me in all the non-ghci non-llvm ways.
For `popCnt16#` we emit `popcnt %ax,%ax` which doesn't clear the high 48 bits of the result.
Patch incoming.
<details><summary>Trac metadata</s...`make TEST=cgrun071 EXTRA_HC_OPTS=-msse42` fails for me in all the non-ghci non-llvm ways.
For `popCnt16#` we emit `popcnt %ax,%ax` which doesn't clear the high 48 bits of the result.
Patch incoming.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | --------------- |
| Version | 7.9 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (NCG) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | simonmar, tibbe |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"x86 sse4.2 popCnt16# needs to zero-extend its result","status":"New","operating_system":"","component":"Compiler (NCG)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.9","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["simonmar","tibbe"],"type":"Bug","description":"`make TEST=cgrun071 EXTRA_HC_OPTS=-msse42` fails for me in all the non-ghci non-llvm ways.\r\n\r\nFor `popCnt16#` we emit `popcnt %ax,%ax` which doesn't clear the high 48 bits of the result.\r\n\r\nPatch incoming.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.4https://gitlab.haskell.org/ghc/ghc/-/issues/9433Partially applied type family allowed but unusable2019-07-07T18:40:25ZhesselinkPartially applied type family allowed but unusableI was playing around with the following code, which tries to map a type family over a type (something I thought would not be allowed):
```hs
{-# LANGUAGE
TypeFamilies
, KindSignatures
#-}
type family Id x :: *
type instance Id ...I was playing around with the following code, which tries to map a type family over a type (something I thought would not be allowed):
```hs
{-# LANGUAGE
TypeFamilies
, KindSignatures
#-}
type family Id x :: *
type instance Id a = a
type family Map (f :: * -> *) x :: *
type instance Map f [a] = [f a]
x :: Map Id [Bool]
x = []
```
Both GHC 7.8.3 and the current HEAD (7.9.20140811) accept this program! However, changing the definition of `x` to `[True]` gives an error:
```
Couldn't match type ‘Id Bool’ with ‘Bool’
Expected type: Map Id [Bool]
Actual type: [Bool]
In the expression: [True]
In an equation for ‘x’: x = [True]
```
If I define `y :: Id Bool` with value `True` (which works fine) and define `x = [y]`, I even get this error:
```
Couldn't match type ‘Bool’ with ‘Id Bool’
Expected type: Id Bool
Actual type: Id Bool
In the expression: y
In the expression: [y]
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.9 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Partially applied type family allowed but unusable","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.9","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I was playing around with the following code, which tries to map a type family over a type (something I thought would not be allowed):\r\n\r\n{{{#!hs\r\n{-# LANGUAGE\r\n TypeFamilies\r\n , KindSignatures\r\n #-}\r\n\r\ntype family Id x :: *\r\ntype instance Id a = a\r\n\r\ntype family Map (f :: * -> *) x :: *\r\ntype instance Map f [a] = [f a]\r\n\r\nx :: Map Id [Bool]\r\nx = []\r\n}}}\r\n\r\nBoth GHC 7.8.3 and the current HEAD (7.9.20140811) accept this program! However, changing the definition of `x` to `[True]` gives an error:\r\n\r\n{{{\r\n Couldn't match type ‘Id Bool’ with ‘Bool’\r\n Expected type: Map Id [Bool]\r\n Actual type: [Bool]\r\n In the expression: [True]\r\n In an equation for ‘x’: x = [True]\r\n}}}\r\n\r\nIf I define `y :: Id Bool` with value `True` (which works fine) and define `x = [y]`, I even get this error:\r\n\r\n{{{\r\n Couldn't match type ‘Bool’ with ‘Id Bool’\r\n Expected type: Id Bool\r\n Actual type: Id Bool\r\n In the expression: y\r\n In the expression: [y]\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->7.8.4https://gitlab.haskell.org/ghc/ghc/-/issues/9417Pattern synonyms across modules broken in Haddock2019-07-07T18:40:29ZMateusz KowalczykPattern synonyms across modules broken in HaddockCreate modules as follows
```hs
-- PatSymDef.hs
{-# Language PatternSynonyms #-}
module PatSymDef where
pattern Some a = Just a
```
```hs
-- PatSymUse.hs
{-# Language PatternSynonyms #-}
m...Create modules as follows
```hs
-- PatSymDef.hs
{-# Language PatternSynonyms #-}
module PatSymDef where
pattern Some a = Just a
```
```hs
-- PatSymUse.hs
{-# Language PatternSynonyms #-}
module PatSymUse where
import PatSymDef
f :: Maybe Int -> Int
f (Some a) = a
f Nothing = 0
```
Then run Haddock against them:
```
[nix-shell:~/programming/haddock]$ ./dist/build/haddock/haddock -h /tmp/PatSymUse.hs /tmp/PatSymDef.hs -o /tmp
Haddock coverage:
Warning: Not found in environment: Some
50% ( 1 / 2) in 'PatSymDef'
/tmp/PatSymUse.hs:9:4:
Can't find interface-file declaration for data constructor Some
Probable cause: bug in .hi-boot file, or inconsistent .hi file
Use -ddump-if-trace to get an idea of which file caused the error
In the pattern: Some a
In an equation for ‘f’: f (Some a) = a
```
Here with -ddump-if-trace:
```
[nix-shell:~/programming/haddock]$ ./dist/build/haddock/haddock -h /tmp/PatSymUse.hs /tmp/PatSymDef.hs -o /tmp --optghc='-ddump-if-trace'
Haddock coverage:
Considering whether to load base:Prelude
Reading interface for base:Prelude;
reason: Prelude is directly imported
readIFace /nix/store/m347lhn3g6sh2s9pv7kz68qs2jyhzphg-ghc-7.9.20140805/lib/ghc-7.9.20140805/base_DiPQ1siqG3SBjHauL3L03p/Prelude.hi
readIFace /nix/store/m347lhn3g6sh2s9pv7kz68qs2jyhzphg-ghc-7.9.20140805/lib/ghc-7.9.20140805/base_DiPQ1siqG3SBjHauL3L03p/Prelude.dyn_hi
updating EPS_
updating EPS_
Considering whether to load base:GHC.Base {- SYSTEM -}
Reading interface for base:GHC.Base;
reason: Loading orphan modules (base:GHC.Base)
readIFace /nix/store/m347lhn3g6sh2s9pv7kz68qs2jyhzphg-ghc-7.9.20140805/lib/ghc-7.9.20140805/base_DiPQ1siqG3SBjHauL3L03p/GHC/Base.hi
readIFace /nix/store/m347lhn3g6sh2s9pv7kz68qs2jyhzphg-ghc-7.9.20140805/lib/ghc-7.9.20140805/base_DiPQ1siqG3SBjHauL3L03p/GHC/Base.dyn_hi
updating EPS_
Considering whether to load base:GHC.Float {- SYSTEM -}
Reading interface for base:GHC.Float;
reason: Loading orphan modules (base:GHC.Float)
readIFace /nix/store/m347lhn3g6sh2s9pv7kz68qs2jyhzphg-ghc-7.9.20140805/lib/ghc-7.9.20140805/base_DiPQ1siqG3SBjHauL3L03p/GHC/Float.hi
readIFace /nix/store/m347lhn3g6sh2s9pv7kz68qs2jyhzphg-ghc-7.9.20140805/lib/ghc-7.9.20140805/base_DiPQ1siqG3SBjHauL3L03p/GHC/Float.dyn_hi
updating EPS_
Considering whether to load base:GHC.Real {- SYSTEM -}
Reading interface for base:GHC.Real;
reason: Loading orphan modules (base:GHC.Real)
readIFace /nix/store/m347lhn3g6sh2s9pv7kz68qs2jyhzphg-ghc-7.9.20140805/lib/ghc-7.9.20140805/base_DiPQ1siqG3SBjHauL3L03p/GHC/Real.hi
readIFace /nix/store/m347lhn3g6sh2s9pv7kz68qs2jyhzphg-ghc-7.9.20140805/lib/ghc-7.9.20140805/base_DiPQ1siqG3SBjHauL3L03p/GHC/Real.dyn_hi
updating EPS_
loadHiBootInterface main@main:PatSymDef
Considering whether to load base:Data.Maybe {- SYSTEM -}
Reading interface for base:Data.Maybe;
reason: The name ‘Data.Maybe.Just’ is mentioned explicitly
readIFace /nix/store/m347lhn3g6sh2s9pv7kz68qs2jyhzphg-ghc-7.9.20140805/lib/ghc-7.9.20140805/base_DiPQ1siqG3SBjHauL3L03p/Data/Maybe.hi
readIFace /nix/store/m347lhn3g6sh2s9pv7kz68qs2jyhzphg-ghc-7.9.20140805/lib/ghc-7.9.20140805/base_DiPQ1siqG3SBjHauL3L03p/Data/Maybe.dyn_hi
updating EPS_
Starting fork { Declaration for Maybe
Loading decl for Data.Maybe.Maybe
updating EPS_
Considering whether to load ghc-prim:GHC.Prim {- SYSTEM -}
Reading interface for ghc-prim:GHC.Prim;
reason: Need home interface for wired-in thing *
updating EPS_
Start interface-file tc_con_decl Nothing
Done interface-file tc_con_decl Data.Maybe.Nothing
Start interface-file tc_con_decl Just
Done interface-file tc_con_decl Data.Maybe.Just
tcIfaceDecl4 Data.Maybe.Maybe
} ending fork Declaration for Maybe
Starting fork { Constructor Data.Maybe.Nothing
} ending fork Constructor Data.Maybe.Nothing
Starting fork { Constructor Data.Maybe.Just
} ending fork Constructor Data.Maybe.Just
==================== Interface statistics ====================
Renamer stats: 6 interfaces read
1 type/class/variable imported, out of 776 read
0 instance decls imported, out of 42 read
0 rule decls imported, out of 53 read
Need decl for PatSymDef.Some
Considering whether to load main@main:PatSymDef {- SYSTEM -}
Warning: Not found in environment: Some
50% ( 1 / 2) in 'PatSymDef'
Considering whether to load base:Prelude
Considering whether to load main@main:PatSymDef
updating EPS_
Considering whether to load base:GHC.Base {- SYSTEM -}
Considering whether to load base:GHC.Float {- SYSTEM -}
Considering whether to load base:GHC.Real {- SYSTEM -}
loadHiBootInterface main@main:PatSymUse
Considering whether to load base:Data.Maybe {- SYSTEM -}
Considering whether to load ghc-prim:GHC.Types {- SYSTEM -}
Reading interface for ghc-prim:GHC.Types;
reason: The name ‘GHC.Types.Int’ is mentioned explicitly
readIFace /nix/store/m347lhn3g6sh2s9pv7kz68qs2jyhzphg-ghc-7.9.20140805/lib/ghc-7.9.20140805/ghcpr_BE58KUgBe9ELCsPXiJ1Q2r/GHC/Types.hi
readIFace /nix/store/m347lhn3g6sh2s9pv7kz68qs2jyhzphg-ghc-7.9.20140805/lib/ghc-7.9.20140805/ghcpr_BE58KUgBe9ELCsPXiJ1Q2r/GHC/Types.dyn_hi
updating EPS_
Considering whether to load ghc-prim:GHC.Types {- SYSTEM -}
Considering whether to load main@main:PatSymDef {- SYSTEM -}
Considering whether to load base:Data.Maybe {- SYSTEM -}
Considering whether to load ghc-prim:GHC.Types {- SYSTEM -}
Considering whether to load ghc-prim:GHC.Types {- SYSTEM -}
Need decl for PatSymDef.Some
Considering whether to load main@main:PatSymDef {- SYSTEM -}
/tmp/PatSymUse.hs:9:4:
Can't find interface-file declaration for data constructor Some
Probable cause: bug in .hi-boot file, or inconsistent .hi file
Use -ddump-if-trace to get an idea of which file caused the error
In the pattern: Some a
In an equation for ‘f’: f (Some a) = a
```
Originally reported to me against Haddock 2.14.3, GHC 7.8.3 and I can confirm both there and on yesterday's GHC HEAD.
It'd be great if whoever is involved with pattern synonyms could take a look.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.9 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Pattern synonyms across modules broken in Haddock","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.9","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Create modules as follows\r\n\r\n{{{#!hs\r\n-- PatSymDef.hs\r\n\r\n{-# Language PatternSynonyms #-} \r\nmodule PatSymDef where\r\n\r\npattern Some a = Just a\r\n}}}\r\n\r\n{{{#!hs\r\n-- PatSymUse.hs\r\n\r\n{-# Language PatternSynonyms #-}\r\nmodule PatSymUse where\r\n\r\nimport PatSymDef\r\n\r\nf :: Maybe Int -> Int\r\nf (Some a) = a\r\nf Nothing = 0\r\n}}}\r\n\r\nThen run Haddock against them:\r\n\r\n{{{\r\n[nix-shell:~/programming/haddock]$ ./dist/build/haddock/haddock -h /tmp/PatSymUse.hs /tmp/PatSymDef.hs -o /tmp \r\nHaddock coverage:\r\nWarning: Not found in environment: Some\r\n 50% ( 1 / 2) in 'PatSymDef'\r\n\r\n/tmp/PatSymUse.hs:9:4:\r\n Can't find interface-file declaration for data constructor Some\r\n Probable cause: bug in .hi-boot file, or inconsistent .hi file\r\n Use -ddump-if-trace to get an idea of which file caused the error\r\n In the pattern: Some a\r\n In an equation for ‘f’: f (Some a) = a\r\n}}}\r\n\r\nHere with -ddump-if-trace:\r\n\r\n{{{\r\n[nix-shell:~/programming/haddock]$ ./dist/build/haddock/haddock -h /tmp/PatSymUse.hs /tmp/PatSymDef.hs -o /tmp --optghc='-ddump-if-trace'\r\nHaddock coverage:\r\nConsidering whether to load base:Prelude\r\nReading interface for base:Prelude;\r\n reason: Prelude is directly imported\r\nreadIFace /nix/store/m347lhn3g6sh2s9pv7kz68qs2jyhzphg-ghc-7.9.20140805/lib/ghc-7.9.20140805/base_DiPQ1siqG3SBjHauL3L03p/Prelude.hi\r\nreadIFace /nix/store/m347lhn3g6sh2s9pv7kz68qs2jyhzphg-ghc-7.9.20140805/lib/ghc-7.9.20140805/base_DiPQ1siqG3SBjHauL3L03p/Prelude.dyn_hi\r\nupdating EPS_\r\nupdating EPS_\r\nConsidering whether to load base:GHC.Base {- SYSTEM -}\r\nReading interface for base:GHC.Base;\r\n reason: Loading orphan modules (base:GHC.Base)\r\nreadIFace /nix/store/m347lhn3g6sh2s9pv7kz68qs2jyhzphg-ghc-7.9.20140805/lib/ghc-7.9.20140805/base_DiPQ1siqG3SBjHauL3L03p/GHC/Base.hi\r\nreadIFace /nix/store/m347lhn3g6sh2s9pv7kz68qs2jyhzphg-ghc-7.9.20140805/lib/ghc-7.9.20140805/base_DiPQ1siqG3SBjHauL3L03p/GHC/Base.dyn_hi\r\nupdating EPS_\r\nConsidering whether to load base:GHC.Float {- SYSTEM -}\r\nReading interface for base:GHC.Float;\r\n reason: Loading orphan modules (base:GHC.Float)\r\nreadIFace /nix/store/m347lhn3g6sh2s9pv7kz68qs2jyhzphg-ghc-7.9.20140805/lib/ghc-7.9.20140805/base_DiPQ1siqG3SBjHauL3L03p/GHC/Float.hi\r\nreadIFace /nix/store/m347lhn3g6sh2s9pv7kz68qs2jyhzphg-ghc-7.9.20140805/lib/ghc-7.9.20140805/base_DiPQ1siqG3SBjHauL3L03p/GHC/Float.dyn_hi\r\nupdating EPS_\r\nConsidering whether to load base:GHC.Real {- SYSTEM -}\r\nReading interface for base:GHC.Real;\r\n reason: Loading orphan modules (base:GHC.Real)\r\nreadIFace /nix/store/m347lhn3g6sh2s9pv7kz68qs2jyhzphg-ghc-7.9.20140805/lib/ghc-7.9.20140805/base_DiPQ1siqG3SBjHauL3L03p/GHC/Real.hi\r\nreadIFace /nix/store/m347lhn3g6sh2s9pv7kz68qs2jyhzphg-ghc-7.9.20140805/lib/ghc-7.9.20140805/base_DiPQ1siqG3SBjHauL3L03p/GHC/Real.dyn_hi\r\nupdating EPS_\r\nloadHiBootInterface main@main:PatSymDef\r\nConsidering whether to load base:Data.Maybe {- SYSTEM -}\r\nReading interface for base:Data.Maybe;\r\n reason: The name ‘Data.Maybe.Just’ is mentioned explicitly\r\nreadIFace /nix/store/m347lhn3g6sh2s9pv7kz68qs2jyhzphg-ghc-7.9.20140805/lib/ghc-7.9.20140805/base_DiPQ1siqG3SBjHauL3L03p/Data/Maybe.hi\r\nreadIFace /nix/store/m347lhn3g6sh2s9pv7kz68qs2jyhzphg-ghc-7.9.20140805/lib/ghc-7.9.20140805/base_DiPQ1siqG3SBjHauL3L03p/Data/Maybe.dyn_hi\r\nupdating EPS_\r\nStarting fork { Declaration for Maybe\r\nLoading decl for Data.Maybe.Maybe\r\nupdating EPS_\r\nConsidering whether to load ghc-prim:GHC.Prim {- SYSTEM -}\r\nReading interface for ghc-prim:GHC.Prim;\r\n reason: Need home interface for wired-in thing *\r\nupdating EPS_\r\nStart interface-file tc_con_decl Nothing\r\nDone interface-file tc_con_decl Data.Maybe.Nothing\r\nStart interface-file tc_con_decl Just\r\nDone interface-file tc_con_decl Data.Maybe.Just\r\ntcIfaceDecl4 Data.Maybe.Maybe\r\n} ending fork Declaration for Maybe\r\nStarting fork { Constructor Data.Maybe.Nothing\r\n} ending fork Constructor Data.Maybe.Nothing\r\nStarting fork { Constructor Data.Maybe.Just\r\n} ending fork Constructor Data.Maybe.Just\r\n\r\n==================== Interface statistics ====================\r\nRenamer stats: 6 interfaces read\r\n 1 type/class/variable imported, out of 776 read\r\n 0 instance decls imported, out of 42 read\r\n 0 rule decls imported, out of 53 read\r\n\r\n\r\nNeed decl for PatSymDef.Some\r\nConsidering whether to load main@main:PatSymDef {- SYSTEM -}\r\nWarning: Not found in environment: Some\r\n 50% ( 1 / 2) in 'PatSymDef'\r\nConsidering whether to load base:Prelude\r\nConsidering whether to load main@main:PatSymDef\r\nupdating EPS_\r\nConsidering whether to load base:GHC.Base {- SYSTEM -}\r\nConsidering whether to load base:GHC.Float {- SYSTEM -}\r\nConsidering whether to load base:GHC.Real {- SYSTEM -}\r\nloadHiBootInterface main@main:PatSymUse\r\nConsidering whether to load base:Data.Maybe {- SYSTEM -}\r\nConsidering whether to load ghc-prim:GHC.Types {- SYSTEM -}\r\nReading interface for ghc-prim:GHC.Types;\r\n reason: The name ‘GHC.Types.Int’ is mentioned explicitly\r\nreadIFace /nix/store/m347lhn3g6sh2s9pv7kz68qs2jyhzphg-ghc-7.9.20140805/lib/ghc-7.9.20140805/ghcpr_BE58KUgBe9ELCsPXiJ1Q2r/GHC/Types.hi\r\nreadIFace /nix/store/m347lhn3g6sh2s9pv7kz68qs2jyhzphg-ghc-7.9.20140805/lib/ghc-7.9.20140805/ghcpr_BE58KUgBe9ELCsPXiJ1Q2r/GHC/Types.dyn_hi\r\nupdating EPS_\r\nConsidering whether to load ghc-prim:GHC.Types {- SYSTEM -}\r\nConsidering whether to load main@main:PatSymDef {- SYSTEM -}\r\nConsidering whether to load base:Data.Maybe {- SYSTEM -}\r\nConsidering whether to load ghc-prim:GHC.Types {- SYSTEM -}\r\nConsidering whether to load ghc-prim:GHC.Types {- SYSTEM -}\r\nNeed decl for PatSymDef.Some\r\nConsidering whether to load main@main:PatSymDef {- SYSTEM -}\r\n\r\n/tmp/PatSymUse.hs:9:4:\r\n Can't find interface-file declaration for data constructor Some\r\n Probable cause: bug in .hi-boot file, or inconsistent .hi file\r\n Use -ddump-if-trace to get an idea of which file caused the error\r\n In the pattern: Some a\r\n In an equation for ‘f’: f (Some a) = a\r\n}}}\r\n\r\nOriginally reported to me against Haddock 2.14.3, GHC 7.8.3 and I can confirm both there and on yesterday's GHC HEAD.\r\n\r\nIt'd be great if whoever is involved with pattern synonyms could take a look.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.4Gergő ÉrdiGergő Érdihttps://gitlab.haskell.org/ghc/ghc/-/issues/9415Superclass cycle with ambiguous type causes loop2019-07-07T18:40:29ZRichard Eisenbergrae@richarde.devSuperclass cycle with ambiguous type causes loopIf I say
```
class D a => C a where
meth :: D a => ()
class C a => D a
```
I get a loop in the typechecker.
I know what's going on here: the error for the superclass cycle is added during the validity check, but then we go on to do ...If I say
```
class D a => C a where
meth :: D a => ()
class C a => D a
```
I get a loop in the typechecker.
I know what's going on here: the error for the superclass cycle is added during the validity check, but then we go on to do ambiguity checks. Unfortunately, the ambiguity check never finishes. We just need to bail when there are superclass errors before doing the ambiguity check.
Patch on the way.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.9 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Superclass cycle with ambiguous type causes loop","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"goldfire"},"version":"7.9","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"If I say\r\n\r\n{{{\r\nclass D a => C a where\r\n meth :: D a => ()\r\nclass C a => D a\r\n}}}\r\n\r\nI get a loop in the typechecker.\r\n\r\nI know what's going on here: the error for the superclass cycle is added during the validity check, but then we go on to do ambiguity checks. Unfortunately, the ambiguity check never finishes. We just need to bail when there are superclass errors before doing the ambiguity check.\r\n\r\nPatch on the way.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.4Richard Eisenbergrae@richarde.devRichard Eisenbergrae@richarde.devhttps://gitlab.haskell.org/ghc/ghc/-/issues/9390Inlining prevents evaluation of ignored parts of unboxed tuples2021-12-15T16:11:17ZMichael Snoymanmichael@snoyman.comInlining prevents evaluation of ignored parts of unboxed tuplesConsider the following code:
```hs
{-# LANGUAGE MagicHash, UnboxedTuples #-}
import GHC.IO (IO (..))
import GHC.Prim
writeB :: MutableArray# RealWorld Char -> IO ()
writeB arr# =
IO $ \s0# ->
(# writeArray# arr# 0# 'B' s0#,...Consider the following code:
```hs
{-# LANGUAGE MagicHash, UnboxedTuples #-}
import GHC.IO (IO (..))
import GHC.Prim
writeB :: MutableArray# RealWorld Char -> IO ()
writeB arr# =
IO $ \s0# ->
(# writeArray# arr# 0# 'B' s0#, () #)
inlineWriteB :: MutableArray# RealWorld Char -> ()
inlineWriteB arr# =
case f realWorld# of
(# _, x #) -> x
where
IO f = writeB arr#
test :: IO Char
test = IO $ \s0# ->
case newArray# 1# 'A' s0# of
(# s1#, arr# #) ->
case seq# (inlineWriteB arr#) s1# of
(# s2#, () #) ->
readArray# arr# 0# s2#
main :: IO ()
main = test >>= print
```
I would expect this code to output the letter 'B'. When compiled without optimizations, that's exactly what it does. However, with optimizations turned on, it seems that it decides that, in `inlineWriteB`, the state value does not need to be evaluated, which results in the `writeArray#` call never occurring.
This affected me when working with the vector and primitive packages. I believe I have a workaround in place (see https://github.com/haskell/primitive/pull/11), but this should probably be fixed in GHC as well.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Inlining prevents evaluation of ignored parts of unboxed tuples","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Consider the following code:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE MagicHash, UnboxedTuples #-}\r\nimport GHC.IO (IO (..))\r\nimport GHC.Prim\r\n\r\nwriteB :: MutableArray# RealWorld Char -> IO ()\r\nwriteB arr# =\r\n IO $ \\s0# ->\r\n (# writeArray# arr# 0# 'B' s0#, () #)\r\n\r\ninlineWriteB :: MutableArray# RealWorld Char -> ()\r\ninlineWriteB arr# =\r\n case f realWorld# of\r\n (# _, x #) -> x\r\n where\r\n IO f = writeB arr#\r\n\r\ntest :: IO Char\r\ntest = IO $ \\s0# ->\r\n case newArray# 1# 'A' s0# of\r\n (# s1#, arr# #) ->\r\n case seq# (inlineWriteB arr#) s1# of\r\n (# s2#, () #) ->\r\n readArray# arr# 0# s2#\r\n\r\nmain :: IO ()\r\nmain = test >>= print\r\n}}}\r\n\r\nI would expect this code to output the letter 'B'. When compiled without optimizations, that's exactly what it does. However, with optimizations turned on, it seems that it decides that, in `inlineWriteB`, the state value does not need to be evaluated, which results in the `writeArray#` call never occurring.\r\n\r\nThis affected me when working with the vector and primitive packages. I believe I have a workaround in place (see https://github.com/haskell/primitive/pull/11), but this should probably be fixed in GHC as well.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.4https://gitlab.haskell.org/ghc/ghc/-/issues/9379Blocked STM transaction is not interruptible2019-07-07T18:40:39ZFeuerbachBlocked STM transaction is not interruptible```hs
import Control.Exception
import Control.Concurrent
import Control.Concurrent.STM
import Foreign.StablePtr
main :: IO ()
main = do
tv <- atomically $ newTVar True
_ <- newStablePtr tv
t <- mask_ $ forkIO (blockSTM tv)
killT...```hs
import Control.Exception
import Control.Concurrent
import Control.Concurrent.STM
import Foreign.StablePtr
main :: IO ()
main = do
tv <- atomically $ newTVar True
_ <- newStablePtr tv
t <- mask_ $ forkIO (blockSTM tv)
killThread t
blockSTM :: TVar Bool -> IO ()
blockSTM tv = do
atomically $ do
v <- readTVar tv
check $ not v
```
This code blocks forever. As I understand it, since the transaction blocks, it should be interruptible even despite the mask, and so killThread must succeed here, and the program should finish promptly.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.8.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | simonmar |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Blocked STM transaction is not interruptible","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"simonmar"},"version":"7.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["simonmar"],"type":"Bug","description":"{{{#!hs\r\nimport Control.Exception\r\nimport Control.Concurrent\r\nimport Control.Concurrent.STM\r\nimport Foreign.StablePtr\r\n\r\nmain :: IO ()\r\nmain = do\r\n tv <- atomically $ newTVar True\r\n _ <- newStablePtr tv\r\n t <- mask_ $ forkIO (blockSTM tv)\r\n killThread t\r\n\r\nblockSTM :: TVar Bool -> IO ()\r\nblockSTM tv = do\r\n atomically $ do\r\n v <- readTVar tv\r\n check $ not v\r\n}}}\r\n\r\nThis code blocks forever. As I understand it, since the transaction blocks, it should be interruptible even despite the mask, and so killThread must succeed here, and the program should finish promptly.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.4Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/9371Overlapping type families, segafult2019-07-07T18:40:41ZpinguOverlapping type families, segafultNot entirely sure what's going on here. I don't think this should type check; it appears to segfault whilst calling show on the wrong type.
This is probably not the absolute minimum required to reproduce.
I have reproduced on 7.8.3 and...Not entirely sure what's going on here. I don't think this should type check; it appears to segfault whilst calling show on the wrong type.
This is probably not the absolute minimum required to reproduce.
I have reproduced on 7.8.3 and 7.9.20140727.
```haskell
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE FlexibleInstances #-}
{-# LANGUAGE UndecidableInstances #-}
{-# LANGUAGE OverlappingInstances #-}
import Data.Monoid
class C x where
data D x :: *
makeD :: D x
instance Monoid x => C x where
data D x = D1 (Either x ())
makeD = D1 (Left mempty)
instance (Monoid x, Monoid y) => C (x, y) where
data D (x,y) = D2 (x,y)
makeD = D2 (mempty, mempty)
instance Show x => Show (D x) where
show (D1 x) = show x
main = print (makeD :: D (String, String))
```
This does not segfault if you add:
```haskell
instance (Show x, Show y) => Show (D (x,y)) where
show (D2 x) = show x
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Overlapping type families, segafult","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Not entirely sure what's going on here. I don't think this should type check; it appears to segfault whilst calling show on the wrong type.\r\n\r\nThis is probably not the absolute minimum required to reproduce.\r\n\r\nI have reproduced on 7.8.3 and 7.9.20140727.\r\n\r\n{{{#!haskell\r\n{-# LANGUAGE TypeFamilies #-}\r\n{-# LANGUAGE FlexibleInstances #-}\r\n{-# LANGUAGE UndecidableInstances #-}\r\n{-# LANGUAGE OverlappingInstances #-}\r\nimport Data.Monoid\r\n\r\nclass C x where\r\n data D x :: *\r\n makeD :: D x\r\n\r\ninstance Monoid x => C x where\r\n data D x = D1 (Either x ())\r\n makeD = D1 (Left mempty)\r\n\r\ninstance (Monoid x, Monoid y) => C (x, y) where\r\n data D (x,y) = D2 (x,y)\r\n makeD = D2 (mempty, mempty)\r\n\r\ninstance Show x => Show (D x) where\r\n show (D1 x) = show x\r\n\r\n\r\nmain = print (makeD :: D (String, String))\r\n}}}\r\n\r\nThis does not segfault if you add:\r\n\r\n{{{#!haskell\r\n instance (Show x, Show y) => Show (D (x,y)) where\r\n show (D2 x) = show x\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->7.8.4Richard Eisenbergrae@richarde.devRichard Eisenbergrae@richarde.devhttps://gitlab.haskell.org/ghc/ghc/-/issues/9345Data.List.inits is extremely slow2019-07-07T18:40:47ZDavid FeuerData.List.inits is extremely slowAs discussed on libraries\@haskell.org, `Data.List.inits` is extremely slow (try running `print $ length $ inits [1..100000]` if you don't believe me). As discussed, there are at least two reasonable fixes. One of them (named `initsR` in...As discussed on libraries\@haskell.org, `Data.List.inits` is extremely slow (try running `print $ length $ inits [1..100000]` if you don't believe me). As discussed, there are at least two reasonable fixes. One of them (named `initsR` in the attached) is a one-liner and gives very good performance in general, but poor performance in certain cases that may or may not appear in real code. The other (named `initsQ` in the attached) is slightly more complex and slightly slower in general, but its performance appears to be robust. I would personally lean toward `initsQ` for `Data.List`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.8.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ekmett, hvr |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Data.List.inits is extremely slow","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ekmett","hvr"],"type":"Bug","description":"As discussed on libraries@haskell.org, `Data.List.inits` is extremely slow (try running `print $ length $ inits [1..100000]` if you don't believe me). As discussed, there are at least two reasonable fixes. One of them (named `initsR` in the attached) is a one-liner and gives very good performance in general, but poor performance in certain cases that may or may not appear in real code. The other (named `initsQ` in the attached) is slightly more complex and slightly slower in general, but its performance appears to be robust. I would personally lean toward `initsQ` for `Data.List`.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.4Edward KmettEdward Kmetthttps://gitlab.haskell.org/ghc/ghc/-/issues/9336binutils gold linker detection does not work when called via gcc and selected...2019-07-07T18:40:50Zslomobinutils gold linker detection does not work when called via gcc and selected by commandline parametersThe binutils gold detection does not work if it is called via gcc and only selected via commandline parameters (i.e. -fuse-ld=gold). Reason is that the "linker" (actually compiler) is called without its commandline parameters.
Attached ...The binutils gold detection does not work if it is called via gcc and only selected via commandline parameters (i.e. -fuse-ld=gold). Reason is that the "linker" (actually compiler) is called without its commandline parameters.
Attached patch fixes that.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"binutils gold linker detection does not work when called via gcc and selected by commandline parameters","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The binutils gold detection does not work if it is called via gcc and only selected via commandline parameters (i.e. -fuse-ld=gold). Reason is that the \"linker\" (actually compiler) is called without its commandline parameters.\r\n\r\nAttached patch fixes that.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.4https://gitlab.haskell.org/ghc/ghc/-/issues/9329GHC panics when Cmm-compiling `STK_CHK_GEN_N (8);`2019-07-07T18:40:52ZHerbert Valerio Riedelhvr@gnu.orgGHC panics when Cmm-compiling `STK_CHK_GEN_N (8);`The following Cmm code snippet compiles fine
```c
foo ()
{
STK_CHK_GEN_N (((1)*8)); /* works */
return (0);
}
```
The following one, however, only compiles with `-O0`, but panics with `-O1` or more:
```c
foo ()
{
STK_CHK_GEN_N (...The following Cmm code snippet compiles fine
```c
foo ()
{
STK_CHK_GEN_N (((1)*8)); /* works */
return (0);
}
```
The following one, however, only compiles with `-O0`, but panics with `-O1` or more:
```c
foo ()
{
STK_CHK_GEN_N (8); /* panics */
return (0);
}
```
```
ghc: panic! (the 'impossible' happened)
(GHC version 7.8.3 for x86_64-unknown-linux):
bundle
c1 foo [(c1,
label: block{v c1}_info
rep:StackRep [])]
[(c0, {}), (c3, {})]
foo() // []
{ info_tbl: [(c1,
label: block{v c1}_info
rep:StackRep [])]
stack_info: arg_space: 8 updfr_space: Just 8
}
{offset
c0: R1 = 0;
call (P64[Sp])(R1) args: 8, res: 0, upd: 8;
}
}
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | simonmar |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC panics when Cmm-compiling `STK_CHK_GEN_N (8);`","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"7.10.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["simonmar"],"type":"Bug","description":"The following Cmm code snippet compiles fine\r\n\r\n{{{#!c\r\nfoo ()\r\n{\r\n STK_CHK_GEN_N (((1)*8)); /* works */\r\n return (0);\r\n}\r\n}}}\r\n\r\n\r\nThe following one, however, only compiles with `-O0`, but panics with `-O1` or more:\r\n\r\n{{{#!c\r\nfoo ()\r\n{\r\n STK_CHK_GEN_N (8); /* panics */\r\n return (0);\r\n}\r\n}}}\r\n\r\n\r\n{{{\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 7.8.3 for x86_64-unknown-linux):\r\n\tbundle\r\n c1 foo [(c1,\r\n label: block{v c1}_info\r\n rep:StackRep [])]\r\n [(c0, {}), (c3, {})]\r\n foo() // []\r\n { info_tbl: [(c1,\r\n label: block{v c1}_info\r\n rep:StackRep [])]\r\n stack_info: arg_space: 8 updfr_space: Just 8\r\n }\r\n {offset\r\n c0: R1 = 0;\r\n call (P64[Sp])(R1) args: 8, res: 0, upd: 8;\r\n }\r\n }\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->7.8.4Simon MarlowSimon Marlow