GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2020-02-24T13:31:34Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/9391LLVM 3.2 crash (AVX messes up GHC calling convention)2020-02-24T13:31:34ZscpmwLLVM 3.2 crash (AVX messes up GHC calling convention)I stumbled across the problem of LLVM 3.2 builds seemingly randomly crashing on my Mac. After quite a bit of investigation I found that the source of the problem was somewhere in the `base` library (`span` to be precise), where it encoun...I stumbled across the problem of LLVM 3.2 builds seemingly randomly crashing on my Mac. After quite a bit of investigation I found that the source of the problem was somewhere in the `base` library (`span` to be precise), where it encountered Cmm like follows:
```
cp7n:
if ((Sp + -56) < SpLim) goto cp8c; else goto cp8d;
...
cp8d:
I64[Sp - 40] = block_cp7g_info;
_smKL::P64 = P64[R1 + 7];
_smKO::P64 = P64[R1 + 15];
_smKP::P64 = P64[R1 + 23];
_smL0::P64 = P64[R1 + 31];
R1 = R2;
P64[Sp - 32] = _smKL::P64;
P64[Sp - 24] = _smKO::P64;
P64[Sp - 16] = _smKP::P64;
P64[Sp - 8] = _smL0::P64;
Sp = Sp - 40;
if (R1 & 7 != 0) goto up8R; else goto cp7h;
up8R:
call block_cp7g_info(R1) args: 0, res: 0, upd: 0;
...
```
which leads LLVM 3.2 to produce the following assembly:
```
_smL1_info: ## @smL1_info
## BB#0: ## %cp7n
pushq %rbp
movq %rsp, %rbp
movq %r14, %rax
movq %rbp, %rcx
leaq -56(%rcx), %rdx
cmpq %r15, %rdx
jae LBB160_1
...
LBB160_1: ## %cp8d
leaq _cp7g_info(%rip), %rdx
movq %rdx, -40(%rcx)
vmovups 7(%rbx), %ymm0
vmovups %ymm0, -32(%rcx)
addq $-40, %rcx
testb $7, %al
je LBB160_4
## BB#2: ## %up8R
movq %rcx, %rbp
movq %rax, %rbx
popq %rbp
vzeroupper
jmp _cp7g_info ## TAILCALL
```
So here LLVM has figured out that it can use `vmovups` in order to move 4 words at the same time. However, there is a puzzling side effect: All of sudden we have a `pushq %rbp` at the start of the function with a matching `popq %rbp` at the very end. This overwrites the stack pointer update (`movq %rcx, %rbp`) and - unsurprisingly - causes the program to crash rather quickly.
My interpretation is that LLVM 3.2 erroneously thinks that AVX instructions are incompatible with frame pointer elimination. The reasoning is that this is exactly the kind of code LLVM generates if we disable this "optimisation" (`--disable-fp-elim`). Furthermore, disabling AVX instructions (`-mattr=-avx`) fixes the problem - LLVM falls back to the less efficient `movups`, with `pushq $rbp` vanishing as well. Finally, this bug seems to happen exactly with LLVM 3.2, with 3.3 upwards generating correct code.
My proposed fix would be to add `-mattr=-avx` to the `llc` command line by default for LLVM 3.2. This issue might be related to #7694.
<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":"LLVM 3.2 crash (AVX messes up GHC calling convention)","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":"I stumbled across the problem of LLVM 3.2 builds seemingly randomly crashing on my Mac. After quite a bit of investigation I found that the source of the problem was somewhere in the `base` library (`span` to be precise), where it encountered Cmm like follows:\r\n{{{\r\n cp7n:\r\n if ((Sp + -56) < SpLim) goto cp8c; else goto cp8d;\r\n ...\r\n cp8d:\r\n I64[Sp - 40] = block_cp7g_info;\r\n _smKL::P64 = P64[R1 + 7];\r\n _smKO::P64 = P64[R1 + 15];\r\n _smKP::P64 = P64[R1 + 23];\r\n _smL0::P64 = P64[R1 + 31];\r\n R1 = R2;\r\n P64[Sp - 32] = _smKL::P64;\r\n P64[Sp - 24] = _smKO::P64;\r\n P64[Sp - 16] = _smKP::P64;\r\n P64[Sp - 8] = _smL0::P64;\r\n Sp = Sp - 40;\r\n if (R1 & 7 != 0) goto up8R; else goto cp7h;\r\n up8R:\r\n call block_cp7g_info(R1) args: 0, res: 0, upd: 0;\r\n ...\r\n}}}\r\n\r\nwhich leads LLVM 3.2 to produce the following assembly:\r\n\r\n{{{\r\n_smL1_info: ## @smL1_info\r\n## BB#0: ## %cp7n\r\n pushq %rbp\r\n movq %rsp, %rbp\r\n movq %r14, %rax\r\n movq %rbp, %rcx\r\n leaq -56(%rcx), %rdx\r\n cmpq %r15, %rdx\r\n jae LBB160_1\r\n...\r\nLBB160_1: ## %cp8d\r\n leaq _cp7g_info(%rip), %rdx\r\n movq %rdx, -40(%rcx)\r\n vmovups 7(%rbx), %ymm0\r\n vmovups %ymm0, -32(%rcx)\r\n addq $-40, %rcx\r\n testb $7, %al\r\n je LBB160_4\r\n## BB#2: ## %up8R\r\n movq %rcx, %rbp\r\n movq %rax, %rbx\r\n popq %rbp\r\n vzeroupper\r\n jmp _cp7g_info ## TAILCALL\r\n}}}\r\n\r\nSo here LLVM has figured out that it can use `vmovups` in order to move 4 words at the same time. However, there is a puzzling side effect: All of sudden we have a `pushq %rbp` at the start of the function with a matching `popq %rbp` at the very end. This overwrites the stack pointer update (`movq %rcx, %rbp`) and - unsurprisingly - causes the program to crash rather quickly.\r\n\r\nMy interpretation is that LLVM 3.2 erroneously thinks that AVX instructions are incompatible with frame pointer elimination. The reasoning is that this is exactly the kind of code LLVM generates if we disable this \"optimisation\" (`--disable-fp-elim`). Furthermore, disabling AVX instructions (`-mattr=-avx`) fixes the problem - LLVM falls back to the less efficient `movups`, with `pushq $rbp` vanishing as well. Finally, this bug seems to happen exactly with LLVM 3.2, with 3.3 upwards generating correct code.\r\n\r\nMy proposed fix would be to add `-mattr=-avx` to the `llc` command line by default for LLVM 3.2. This issue might be related to #7694.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/9384setNumCapabilities call breaks eventlog events2019-07-07T18:40:37ZSergei TrofimovichsetNumCapabilities call breaks eventlog eventsThe problem was found when i tried to eventlog **ghc --make** itself.
I've missinterpreted is as a threadscope bug: https://github.com/haskell/ThreadScope/issues/37
Here is small program to reliably reproduce the bug:
```hs
module Main...The problem was found when i tried to eventlog **ghc --make** itself.
I've missinterpreted is as a threadscope bug: https://github.com/haskell/ThreadScope/issues/37
Here is small program to reliably reproduce the bug:
```hs
module Main where
import qualified Data.List as L
import qualified System.Environment as E
import Control.Monad
import qualified Control.Concurrent as CC
import qualified Control.Concurrent.MVar as CC
slow_and_silly :: Int -> IO Int
slow_and_silly i = return $ length $ L.foldl' (\a v -> a ++ [v]) [] [1..i]
-- build as:
-- $ ghc --make a -O2 -threaded -eventlog
-- valid eventlog:
-- $ ./a 2 7000 +RTS -ls -N2
-- $ ghc-events validate threads a.eventlog
-- Valid eventlog:
-- ...
-- invalid eventlog
-- $ ./a 2 7000 +RTS -ls
-- $ ghc-events validate threads a.eventlog
-- Invalid eventlog:
-- ...
main = do
[caps, count] <- E.getArgs
let n_caps :: Int
n_caps = read caps
max_n :: Int
max_n = read count
CC.setNumCapabilities n_caps
waits <- replicateM n_caps $ CC.newEmptyMVar
forM_ waits $ \w -> CC.forkIO $ do
slow_and_silly max_n >>= print
CC.putMVar w ()
forM_ waits $ \w -> CC.takeMVar w
```
How to reproduce (comments have **ghc-events** version):
```
$ ghc --make a -O2 -threaded -eventlog
$ ./a 2 7000 +RTS -ls -N2
$ threadscope a.eventlog # works
$ ./a 2 7000 +RTS -ls
$ threadscope a.eventlog # crashes
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Profiling |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"setNumCapabilities call breaks eventlog events","status":"New","operating_system":"","component":"Profiling","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The problem was found when i tried to eventlog '''ghc --make''' itself.\r\nI've missinterpreted is as a threadscope bug: https://github.com/haskell/ThreadScope/issues/37\r\n\r\nHere is small program to reliably reproduce the bug:\r\n\r\n{{{#!hs\r\nmodule Main where\r\n\r\nimport qualified Data.List as L\r\nimport qualified System.Environment as E\r\nimport Control.Monad\r\nimport qualified Control.Concurrent as CC\r\nimport qualified Control.Concurrent.MVar as CC\r\n\r\nslow_and_silly :: Int -> IO Int\r\nslow_and_silly i = return $ length $ L.foldl' (\\a v -> a ++ [v]) [] [1..i]\r\n\r\n-- build as:\r\n-- $ ghc --make a -O2 -threaded -eventlog\r\n\r\n-- valid eventlog:\r\n-- $ ./a 2 7000 +RTS -ls -N2\r\n-- $ ghc-events validate threads a.eventlog\r\n-- Valid eventlog:\r\n-- ...\r\n\r\n-- invalid eventlog\r\n-- $ ./a 2 7000 +RTS -ls\r\n-- $ ghc-events validate threads a.eventlog\r\n-- Invalid eventlog:\r\n-- ...\r\n\r\nmain = do\r\n [caps, count] <- E.getArgs\r\n let n_caps :: Int\r\n n_caps = read caps\r\n max_n :: Int\r\n max_n = read count\r\n\r\n CC.setNumCapabilities n_caps\r\n\r\n waits <- replicateM n_caps $ CC.newEmptyMVar\r\n\r\n forM_ waits $ \\w -> CC.forkIO $ do\r\n slow_and_silly max_n >>= print\r\n CC.putMVar w ()\r\n\r\n forM_ waits $ \\w -> CC.takeMVar w\r\n}}}\r\n\r\nHow to reproduce (comments have '''ghc-events''' version):\r\n{{{\r\n$ ghc --make a -O2 -threaded -eventlog\r\n$ ./a 2 7000 +RTS -ls -N2\r\n$ threadscope a.eventlog # works\r\n$ ./a 2 7000 +RTS -ls\r\n$ threadscope a.eventlog # crashes\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/9382Have rts/Linker.c lookupSymbol find symbols in the process executable.2019-07-07T18:40:38ZFacundo DomínguezHave rts/Linker.c lookupSymbol find symbols in the process executable.In windows, the function `lookupSymbol` in `Linker.c` does not look for symbols exported in the executable. Thus, when a program is linked with `-optl -export-all-symbols`, the function `lookupSymbol` still fails to find them.
Fixing th...In windows, the function `lookupSymbol` in `Linker.c` does not look for symbols exported in the executable. Thus, when a program is linked with `-optl -export-all-symbols`, the function `lookupSymbol` still fails to find them.
Fixing this would improve the usability of `-rdynamic` (#9381) and an upcoming implementation for #7015.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | |
| 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":"Have rts/Linker.c lookupSymbol find symbols in the process executable.","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"facundo.dominguez"},"version":"","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"In windows, the function `lookupSymbol` in `Linker.c` does not look for symbols exported in the executable. Thus, when a program is linked with `-optl -export-all-symbols`, the function `lookupSymbol` still fails to find them.\r\n\r\nFixing this would improve the usability of `-rdynamic` (#9381) and an upcoming implementation for #7015.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1Facundo DomínguezFacundo Domínguezhttps://gitlab.haskell.org/ghc/ghc/-/issues/9372dll-split during stage 2 compiling ghc v7.8.3 for arm_linux2019-07-07T18:40:41Zchrisfgldll-split during stage 2 compiling ghc v7.8.3 for arm_linuxTrying to compile GHC 7.8.3 for ubuntu/arm. Was in Stage 1 for 8 hours before exiting with following message:
```
dll-split: internal error: evacuate(static): strange closure type 0
(GHC version 7.8.3 for arm_unknown_linux)
Plea...Trying to compile GHC 7.8.3 for ubuntu/arm. Was in Stage 1 for 8 hours before exiting with following message:
```
dll-split: internal error: evacuate(static): strange closure type 0
(GHC version 7.8.3 for arm_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
make[1]: *** [compiler/stage2/dll-split.stamp] Aborted (core dumped)
make: *** [all] Error 2
```7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/9369Data.List.unfoldr does not fuse and is not inlined.2019-07-07T18:40:41ZDavid FeuerData.List.unfoldr does not fuse and is not inlined.`Data.List.unfoldr` is not a good producer for foldr/build fusion, and it's not wrapped to enable inlining. I don't know how often people explicitly fold over an unfold, but this of course also affects map and filter. The inlining issue ...`Data.List.unfoldr` is not a good producer for foldr/build fusion, and it's not wrapped to enable inlining. I don't know how often people explicitly fold over an unfold, but this of course also affects map and filter. The inlining issue is also serious: inlining `unfoldr` can often allow the `Maybe` to be erased altogether. I'm not sure this fix is perfect, but it seems a lot better than the current situation:
```hs
import GHC.Exts (build)
{-# NOINLINE [1] unfoldr #-}
unfoldr :: (b -> Maybe (a, b)) -> b -> [a]
unfoldr f b = go b
where
go b = case f b of
Just (a,new_b) -> a : go new_b
Nothing -> []
{-# INLINE [0] unfoldrB #-}
unfoldrB :: (b -> Maybe (a, b)) -> b -> (a -> c -> c) -> c -> c
unfoldrB f b' c n = go b'
where
go b = case f b of
Just (a,new_b) -> a `c` go new_b
Nothing -> n
{-# RULES
"unfoldr" [~1] forall f b . unfoldr f b = build (unfoldrB f b)
#-}
```
As a simple example, consider the code
```hs
hello :: Double -> Double -> [Double]
hello x n = map (* 3) $ L.unfoldr f x
where
f x | x < n = Just (x, x**1.2)
| otherwise = Nothing
```
With `Data.List.unfoldr` and the latest bleeding-edge GHC, this produces
```hs
hello1
hello1 =
\ ds_d1ZF -> case ds_d1ZF of _ { D# x_a21W -> D# (*## x_a21W 3.0) }
$whello
$whello =
\ w_s266 ww_s26a ->
map
hello1
(unfoldr
(\ x_X1Hx ->
case x_X1Hx of wild_a20E { D# x1_a20G ->
case tagToEnum# (<## x1_a20G ww_s26a) of _ {
False -> Nothing;
True -> Just (wild_a20E, D# (**## x1_a20G 1.2))
}
})
w_s266)
hello
hello =
\ w_s266 w1_s267 ->
case w1_s267 of _ { D# ww1_s26a -> $whello w_s266 ww1_s26a }
```
Using the above implementation (and renaming the function from `hello` to `bye`) yields
```hs
$wbye
$wbye =
\ ww_s25Z ww1_s263 ->
letrec {
$wgo_s25U
$wgo_s25U =
\ ww2_s25S ->
case tagToEnum# (<## ww2_s25S ww1_s263) of _ {
False -> [];
True -> : (D# (*## ww2_s25S 3.0)) ($wgo_s25U (**## ww2_s25S 1.2))
}; } in
$wgo_s25U ww_s25Z
bye
bye =
\ w_s25V w1_s25W ->
case w_s25V of _ { D# ww1_s25Z ->
case w1_s25W of _ { D# ww3_s263 -> $wbye ww1_s25Z ww3_s263 }
}
```
I don't think there can be any doubt which is better. Yes, some fine tuning may be needed to make the rules apply in all appropriate cases. I don't understand things like the comment on the definition of `map` drawing attention to eta expansion.
<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.unfoldr does not fuse and is not inlined.","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"7.8.4","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ekmett","hvr"],"type":"Bug","description":"`Data.List.unfoldr` is not a good producer for foldr/build fusion, and it's not wrapped to enable inlining. I don't know how often people explicitly fold over an unfold, but this of course also affects map and filter. The inlining issue is also serious: inlining `unfoldr` can often allow the `Maybe` to be erased altogether. I'm not sure this fix is perfect, but it seems a lot better than the current situation:\r\n\r\n{{{#!hs\r\nimport GHC.Exts (build)\r\n\r\n{-# NOINLINE [1] unfoldr #-}\r\nunfoldr :: (b -> Maybe (a, b)) -> b -> [a]\r\nunfoldr f b = go b\r\n where\r\n go b = case f b of\r\n Just (a,new_b) -> a : go new_b\r\n Nothing -> []\r\n\r\n{-# INLINE [0] unfoldrB #-}\r\nunfoldrB :: (b -> Maybe (a, b)) -> b -> (a -> c -> c) -> c -> c\r\nunfoldrB f b' c n = go b'\r\n where\r\n go b = case f b of\r\n Just (a,new_b) -> a `c` go new_b\r\n Nothing -> n\r\n\r\n{-# RULES\r\n\"unfoldr\" [~1] forall f b . unfoldr f b = build (unfoldrB f b)\r\n #-}\r\n}}}\r\n\r\nAs a simple example, consider the code\r\n\r\n{{{#!hs\r\nhello :: Double -> Double -> [Double]\r\nhello x n = map (* 3) $ L.unfoldr f x\r\n where\r\n f x | x < n = Just (x, x**1.2)\r\n | otherwise = Nothing\r\n}}}\r\n\r\nWith `Data.List.unfoldr` and the latest bleeding-edge GHC, this produces\r\n\r\n{{{#!hs\r\nhello1\r\nhello1 =\r\n \\ ds_d1ZF -> case ds_d1ZF of _ { D# x_a21W -> D# (*## x_a21W 3.0) }\r\n\r\n$whello\r\n$whello =\r\n \\ w_s266 ww_s26a ->\r\n map\r\n hello1\r\n (unfoldr\r\n (\\ x_X1Hx ->\r\n case x_X1Hx of wild_a20E { D# x1_a20G ->\r\n case tagToEnum# (<## x1_a20G ww_s26a) of _ {\r\n False -> Nothing;\r\n True -> Just (wild_a20E, D# (**## x1_a20G 1.2))\r\n }\r\n })\r\n w_s266)\r\n\r\nhello\r\nhello =\r\n \\ w_s266 w1_s267 ->\r\n case w1_s267 of _ { D# ww1_s26a -> $whello w_s266 ww1_s26a }\r\n}}}\r\n\r\nUsing the above implementation (and renaming the function from `hello` to `bye`) yields\r\n\r\n{{{#!hs\r\n$wbye\r\n$wbye =\r\n \\ ww_s25Z ww1_s263 ->\r\n letrec {\r\n $wgo_s25U\r\n $wgo_s25U =\r\n \\ ww2_s25S ->\r\n case tagToEnum# (<## ww2_s25S ww1_s263) of _ {\r\n False -> [];\r\n True -> : (D# (*## ww2_s25S 3.0)) ($wgo_s25U (**## ww2_s25S 1.2))\r\n }; } in\r\n $wgo_s25U ww_s25Z\r\n\r\nbye\r\nbye =\r\n \\ w_s25V w1_s25W ->\r\n case w_s25V of _ { D# ww1_s25Z ->\r\n case w1_s25W of _ { D# ww3_s263 -> $wbye ww1_s25Z ww3_s263 }\r\n }\r\n}}}\r\n\r\nI don't think there can be any doubt which is better. Yes, some fine tuning may be needed to make the rules apply in all appropriate cases. I don't understand things like the comment on the definition of `map` drawing attention to eta expansion.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/9368Add strictly accumulating scanl' to Data.List2019-07-07T18:40:42ZDavid FeuerAdd strictly accumulating scanl' to Data.ListJoachim Breitner wrote a strictly accumulating fusable `scanl'` in a comment on #9345, and demonstrated that it can produce spectacularly good code. Therefore, it seems like a good thing to have in Data.List.
<details><summary>Trac meta...Joachim Breitner wrote a strictly accumulating fusable `scanl'` in a comment on #9345, and demonstrated that it can produce spectacularly good code. Therefore, it seems like a good thing to have in Data.List.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.8.3 |
| Type | FeatureRequest |
| 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":"Add strictly accumulating scanl' to Data.List","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":"FeatureRequest","description":"Joachim Breitner wrote a strictly accumulating fusable `scanl'` in a comment on #9345, and demonstrated that it can produce spectacularly good code. Therefore, it seems like a good thing to have in Data.List.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/9363windows configure 'find invalid mode'2019-07-07T18:40:43Zniklaslwindows configure 'find invalid mode'When running `configure` on Windows several tests fail with `/usr/bin/find: invalid mode '+111'`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version ...When running `configure` on Windows several tests fail with `/usr/bin/find: invalid mode '+111'`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.2 |
| 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":"windows configure 'find invalid mode'","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When running `configure` on Windows several tests fail with `/usr/bin/find: invalid mode '+111'`.\r\n ","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/9362make clean deletes inplace mingw2019-07-07T18:40:43Zniklaslmake clean deletes inplace mingwRunning `make clean` removes the mingw toolchain from the inplace directory, forcing another `configure` before building is possible again.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------...Running `make clean` removes the mingw toolchain from the inplace directory, forcing another `configure` before building is possible again.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.2 |
| 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":"make clean deletes inplace mingw","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Running `make clean` removes the mingw toolchain from the inplace directory, forcing another `configure` before building is possible again. ","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/9359Deriving clause failure with polymorphic kinds2019-07-07T18:40:44ZSimon Peyton JonesDeriving clause failure with polymorphic kindsConsider
```
{-# Language GADTs, PolyKinds, TypeFamilies, DataKinds #-}
module Fam where
data Cmp a where
Sup :: Cmp a
V :: a -> Cmp a
deriving (Show, Eq)
data family CmpInterval (a :: Cmp k) (b :: Cmp k) :: *
data instanc...Consider
```
{-# Language GADTs, PolyKinds, TypeFamilies, DataKinds #-}
module Fam where
data Cmp a where
Sup :: Cmp a
V :: a -> Cmp a
deriving (Show, Eq)
data family CmpInterval (a :: Cmp k) (b :: Cmp k) :: *
data instance CmpInterval (V c) Sup = Starting c
deriving( Show )
```
GHC 7.8.3 gives
```
Fam.hs:12:13:
Can't make a derived instance of ‘Show (CmpInterval ('V c) 'Sup)’:
No family instance for ‘CmpInterval ('V c) 'Sup’
In the data instance declaration for ‘CmpInterval’
```
which is obviously wrong.
Reported on [glasgow-haskell-users](http://www.haskell.org/pipermail/glasgow-haskell-users/2014-July/025145.html).7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/9355scanr does not participate in stream fusion2019-08-30T15:34:37ZDavid Feuerscanr does not participate in stream fusionThis should be a no-brainer—it's trivial two write `scanr` as a foldr, making it a good consumer. Wrapping it up in `build` makes it a good producer too, but may require back-and-forth RULES.
<details><summary>Trac metadata</summary>
|...This should be a no-brainer—it's trivial two write `scanr` as a foldr, making it a good consumer. Wrapping it up in `build` makes it a good producer too, but may require back-and-forth RULES.
<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":"scanr does not participate in stream fusion","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"7.8.4","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ekmett","hvr"],"type":"Bug","description":"This should be a no-brainer—it's trivial two write `scanr` as a foldr, making it a good consumer. Wrapping it up in `build` makes it a good producer too, but may require back-and-forth RULES.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/9341Evaluate default CPUs setting for validate2019-07-07T18:40:49ZJoachim Breitnermail@joachim-breitner.deEvaluate default CPUs setting for validateThis is a fork off #9315:comment 16. `./validate` runs `-j2` (i.e. CPUS=1). I guess most developers these days have a stronger system that would allow for more cores to be used.
This ticket should discuss if this default should changed ...This is a fork off #9315:comment 16. `./validate` runs `-j2` (i.e. CPUS=1). I guess most developers these days have a stronger system that would allow for more cores to be used.
This ticket should discuss if this default should changed to something higher, or possibly something dynamic. On Linux, there is the command `nproc`, part of coreutils, for that – is that also provided by our default windows environment?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.2 |
| 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":"Evaluate default CPUs setting for validate","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This is a fork off #9315:comment 16. `./validate` runs `-j2` (i.e. CPUS=1). I guess most developers these days have a stronger system that would allow for more cores to be used.\r\n\r\nThis ticket should discuss if this default should changed to something higher, or possibly something dynamic. On Linux, there is the command `nproc`, part of coreutils, for that – is that also provided by our default windows environment?","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/9340Implement new `clz` inline primop2019-07-07T18:40:49ZHerbert Valerio Riedelhvr@gnu.orgImplement new `clz` inline primopFrom a draft for #9281, I had to use a C FFI and using a gcc/clang `__builtin` to get access to the [CLZ instruction](http://en.wikipedia.org/wiki/Find_first_set):
```hs
-- | Compute base-2 log of 'Word#'
--
-- This is internally implem...From a draft for #9281, I had to use a C FFI and using a gcc/clang `__builtin` to get access to the [CLZ instruction](http://en.wikipedia.org/wiki/Find_first_set):
```hs
-- | Compute base-2 log of 'Word#'
--
-- This is internally implemented as count-leading-zeros machine instruction.
foreign import ccall unsafe "integer_gmp_word_log2"
wordLog2# :: Word# -> Int#
```
```c
HsWord
integer_gmp_word_log2(HsWord x)
{
#if (SIZEOF_HSWORD) == (SIZEOF_INT)
return x ? (WORD_SIZE_IN_BITS-1) - __builtin_clz(x) : -1;
#elif (SIZEOF_HSWORD) == (SIZEOF_LONG)
return x ? (WORD_SIZE_IN_BITS-1) - __builtin_clzl(x) : -1;
#elif (SIZEOF_HSWORD) == (SIZEOF_LONG_LONG)
return x ? (WORD_SIZE_IN_BITS-1) - __builtin_clzll(x) : -1;
#else
# error unsupported SIZEOF_HSWORD
#endif
}
```
Since a `clz`-like operation should be available on most cpus GHC should expose that as a primop (`clz# :: Word# -> Int#`).7.10.1Herbert Valerio Riedelhvr@gnu.orgHerbert Valerio Riedelhvr@gnu.orghttps://gitlab.haskell.org/ghc/ghc/-/issues/9337Add `sortOn` function to Data.List2019-07-07T18:40:50ZJohnWiegleyAdd `sortOn` function to Data.ListThis passed the vote on the libraries list a while ago, but I forget to add a ticket. The request was to add `sortOn` to `Data.List`:
```
-- | Sort a list using a key on each element. This implements the
-- decorate-sort-undecorate p...This passed the vote on the libraries list a while ago, but I forget to add a ticket. The request was to add `sortOn` to `Data.List`:
```
-- | Sort a list using a key on each element. This implements the
-- decorate-sort-undecorate paradigm, also called a Schwarzian transform.
sortOn :: Ord b => (a -> b) -> [a] -> [a]
sortOn f = map snd . sortBy (comparing fst) . map (\x -> (f x, x))
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.8.3 |
| Type | FeatureRequest |
| 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":"Add `sortOn` function to Data.List","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"7.10.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ekmett","hvr"],"type":"FeatureRequest","description":"This passed the vote on the libraries list a while ago, but I forget to add a ticket. The request was to add `sortOn` to `Data.List`:\r\n\r\n{{{\r\n-- | Sort a list using a key on each element. This implements the\r\n-- decorate-sort-undecorate paradigm, also called a Schwarzian transform.\r\nsortOn :: Ord b => (a -> b) -> [a] -> [a]\r\nsortOn f = map snd . sortBy (comparing fst) . map (\\x -> (f x, x))\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/9333Thread status decoded wrong in base library2019-07-07T18:40:51ZJost BertholdThread status decoded wrong in base libraryKyle Van Berendonck \<kvanberendonck\@gmail.com\> in [a message on ghc-devs](http://www.haskell.org/pipermail/ghc-devs/2014-July/005677.html) pointed to [base/GHC/Conc/Sync.lhs](https://github.com/ghc/ghc/blob/master/libraries/base/GHC/C...Kyle Van Berendonck \<kvanberendonck\@gmail.com\> in [a message on ghc-devs](http://www.haskell.org/pipermail/ghc-devs/2014-July/005677.html) pointed to [base/GHC/Conc/Sync.lhs](https://github.com/ghc/ghc/blob/master/libraries/base/GHC/Conc/Sync.lhs#L483) decoding thread block reasons from constants defined in includes/rts/Constants.h to a Haskell type.
The constants were modified in GHC-7.8.2, which created problems with eventlogs (ticket #9003), so the constants were reverted, but base was not adapted to the respective fix.
<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, ezyang, hvr, simonmar |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Thread status decoded wrong in base library","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","ezyang","hvr","simonmar"],"type":"Bug","description":"Kyle Van Berendonck <kvanberendonck@gmail.com> in [http://www.haskell.org/pipermail/ghc-devs/2014-July/005677.html a message on ghc-devs] pointed to [https://github.com/ghc/ghc/blob/master/libraries/base/GHC/Conc/Sync.lhs#L483 base/GHC/Conc/Sync.lhs] decoding thread block reasons from constants defined in includes/rts/Constants.h to a Haskell type.\r\n\r\nThe constants were modified in GHC-7.8.2, which created problems with eventlogs (ticket #9003), so the constants were reverted, but base was not adapted to the respective fix.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1Jost BertholdJost Bertholdhttps://gitlab.haskell.org/ghc/ghc/-/issues/9332Memory blowing up for strict sum/strict foldl in ghci2019-07-07T18:40:51Zartella.codingMemory blowing up for strict sum/strict foldl in ghci(http://stackoverflow.com/questions/24838982/memory-blowing-up-for-strict-sum-strict-foldl-in-ghci)
Suppose we have
```
--Test.hs
import Data.List
longList::[Int]
longList = [1 .. ]
result :: Int
result = foldl' (+) 0 $ takeWhile (< ...(http://stackoverflow.com/questions/24838982/memory-blowing-up-for-strict-sum-strict-foldl-in-ghci)
Suppose we have
```
--Test.hs
import Data.List
longList::[Int]
longList = [1 .. ]
result :: Int
result = foldl' (+) 0 $ takeWhile (< 10000000) longList
main = do
print $ result
```
If one deletes all the ".hi" and ".o" files and then loads into ghci via :
```
ghci -fobject-code Test.hs
```
then upon running "main" the memory blows up.7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/9331Release Cabal 1.22 before GHC 7.10 release2019-07-07T18:40:51ZEdward Z. YangRelease Cabal 1.22 before GHC 7.10 releaseJust a tracking bug so we don't forget.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.9 |
| Type ...Just a tracking bug so we don't forget.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.9 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Package system |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Release Cabal 1.22 before GHC 7.10 release","status":"New","operating_system":"","component":"Package system","related":[],"milestone":"7.10.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.9","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"Just a tracking bug so we don't forget.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/9324GHCi permission checks should ignore root user2019-07-07T18:40:53ZMathieu BoespflugGHCi permission checks should ignore root userAs a security precaution, GHCi helpfully refuses to run a `.ghci` file if it is owned by another user. But if the that other user is root, then arguably GHCi should not refuse to interpret the file, because if root really was malicious, ...As a security precaution, GHCi helpfully refuses to run a `.ghci` file if it is owned by another user. But if the that other user is root, then arguably GHCi should not refuse to interpret the file, because if root really was malicious, then the user would be having a bad day anyways.
This means that .ghci files installed in a global location, say under `/usr/local/`, can then be read.
<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":"GHCi permission checks should ignore root user","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":"As a security precaution, GHCi helpfully refuses to run a `.ghci` file if it is owned by another user. But if the that other user is root, then arguably GHCi should not refuse to interpret the file, because if root really was malicious, then the user would be having a bad day anyways.\r\n\r\nThis means that .ghci files installed in a global location, say under `/usr/local/`, can then be read.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/9323Confusing type error behaviour2019-07-07T18:40:53ZSimon Peyton JonesConfusing type error behaviourCompile this example with GHC 7.8.3.
```
module Foo where
broken :: [Int]
broken = ()
ambiguous :: a -> String
ambiguous _ = show 0
```
You get
```
Foo.hs:4:10:
Couldn't match expected type ‘[Int]’ with actual type ‘()’
In t...Compile this example with GHC 7.8.3.
```
module Foo where
broken :: [Int]
broken = ()
ambiguous :: a -> String
ambiguous _ = show 0
```
You get
```
Foo.hs:4:10:
Couldn't match expected type ‘[Int]’ with actual type ‘()’
In the expression: ()
In an equation for ‘broken’: broken = ()
Foo.hs:7:15:
No instance for (Show a0) arising from a use of ‘show’
The type variable ‘a0’ is ambiguous
```
(and a similar ambiguous `(Num a0)` error).
**But if you comment out `broken`, the program compiles**, using the defaulting rules to choose `a0` = `Integer`.
This is obviously wrong.
Reported by Evan Laforge.7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/9318Type error reported in wrong place with repeated type family expressions2019-07-07T18:40:54ZRichard Eisenbergrae@richarde.devType error reported in wrong place with repeated type family expressionsWhen I say
```
{-# LANGUAGE TypeFamilies #-}
type family F x
type instance F Int = Bool
foo :: F Int -> ()
foo True = ()
bar :: F Int -> ()
bar 'x' = ()
```
I get
```
/Users/rae/temp/Bug.hs:7:5:
Couldn't match type ‘Char’ with ...When I say
```
{-# LANGUAGE TypeFamilies #-}
type family F x
type instance F Int = Bool
foo :: F Int -> ()
foo True = ()
bar :: F Int -> ()
bar 'x' = ()
```
I get
```
/Users/rae/temp/Bug.hs:7:5:
Couldn't match type ‘Char’ with ‘Bool’
Expected type: F Int
Actual type: Bool
In the pattern: True
In an equation for ‘foo’: foo True = ()
/Users/rae/temp/Bug.hs:10:5:
Couldn't match type ‘Bool’ with ‘Char’
Expected type: F Int
Actual type: Char
In the pattern: 'x'
In an equation for ‘bar’: bar 'x' = ()
```
The second error is most certainly correct, but the first one is most certainly not. Note that the first error is reported on the definition of `foo`, which should type-check. Also, the "Couldn't match ..." bit doesn't correspond at all with the expected/actual bit. And, the expected/actual bit shows two types that are in fact equal.
This behavior can be seen in HEAD (as of Jul. 2), 7.8.3, and 7.8.2. This is a regression from 7.6.3, where this behavior does not appear.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.8.3 |
| 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":"Type error reported in wrong place with repeated type family expressions","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When I say\r\n\r\n{{{\r\n{-# LANGUAGE TypeFamilies #-}\r\n\r\ntype family F x\r\ntype instance F Int = Bool\r\n\r\nfoo :: F Int -> ()\r\nfoo True = ()\r\n\r\nbar :: F Int -> ()\r\nbar 'x' = ()\r\n}}}\r\n\r\nI get\r\n\r\n{{{\r\n/Users/rae/temp/Bug.hs:7:5:\r\n Couldn't match type ‘Char’ with ‘Bool’\r\n Expected type: F Int\r\n Actual type: Bool\r\n In the pattern: True\r\n In an equation for ‘foo’: foo True = ()\r\n\r\n/Users/rae/temp/Bug.hs:10:5:\r\n Couldn't match type ‘Bool’ with ‘Char’\r\n Expected type: F Int\r\n Actual type: Char\r\n In the pattern: 'x'\r\n In an equation for ‘bar’: bar 'x' = ()\r\n}}}\r\n\r\nThe second error is most certainly correct, but the first one is most certainly not. Note that the first error is reported on the definition of `foo`, which should type-check. Also, the \"Couldn't match ...\" bit doesn't correspond at all with the expected/actual bit. And, the expected/actual bit shows two types that are in fact equal.\r\n\r\nThis behavior can be seen in HEAD (as of Jul. 2), 7.8.3, and 7.8.2. This is a regression from 7.6.3, where this behavior does not appear.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/9317Add PolyKinds extension to Data.Monoid2019-07-07T18:40:55ZbernalexAdd PolyKinds extension to Data.MonoidPolyKinds got lost in 1d1ff77aaa09efaddc8cfe0dcf92d6763297cf11. See discussion here: \<http://www.haskell.org/pipermail/libraries/2014-July/023261.html\>.
<details><summary>Trac metadata</summary>
| Trac field | Value ...PolyKinds got lost in 1d1ff77aaa09efaddc8cfe0dcf92d6763297cf11. See discussion here: \<http://www.haskell.org/pipermail/libraries/2014-July/023261.html\>.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.8.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ekmett, hvr |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Add PolyKinds extension to Data.Monoid","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ekmett","hvr"],"type":"Bug","description":"PolyKinds got lost in 1d1ff77aaa09efaddc8cfe0dcf92d6763297cf11. See discussion here: <http://www.haskell.org/pipermail/libraries/2014-July/023261.html>.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1