GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:01:52Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/16045improve dwarf support on OSX2019-07-07T18:01:52ZCarter Schonwaldimprove dwarf support on OSXcurrently
1) we dont have stack unwinding support on OSX (libDwarf is ELF format only)
2) the current way dwarf data is generated on OSX / for macho triggers some segment issue when linking base into a libbase archive, when g1 or g2 is...currently
1) we dont have stack unwinding support on OSX (libDwarf is ELF format only)
2) the current way dwarf data is generated on OSX / for macho triggers some segment issue when linking base into a libbase archive, when g1 or g2 is set , but not when g0 is set. that is, even if we had a macho unwinding library for use with GHC, currently we can't even unwind base if we wanted to
3) currently the stgcrun.c code for darwin/unix envs when build on OSX, can't be built with GCC, because of some mismatch in how llvm vs gcc flavored tools on osx handle dwarf. This means this file, IF we had unwinding support, would need to be built with clang (apple or llvm flavored).
3 a)HOWEVER: on OSX the threaded RTS (when built with clang) is \~15% slower than the same built with GCC.
3 b) so ideally, in a future world with unwinding on OSX, tweaking the build system to make sure that the STGCRUN.c code it always built with clang, or some other fix, that still permits a GCC built RTS OR otherwise does a fix to that GC rts perf issue, would be ideal
Theres a few different action items here, and some of them are quite messy, but they all need to be done for decent perf and debugging experiences on OSX to be in the GHC future!
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"improve dwarf support on OSX","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"currently \r\n\r\n1) we dont have stack unwinding support on OSX (libDwarf is ELF format only)\r\n\r\n2) the current way dwarf data is generated on OSX / for macho triggers some segment issue when linking base into a libbase archive, when g1 or g2 is set , but not when g0 is set. that is, even if we had a macho unwinding library for use with GHC, currently we can't even unwind base if we wanted to \r\n\r\n3) currently the stgcrun.c code for darwin/unix envs when build on OSX, can't be built with GCC, because of some mismatch in how llvm vs gcc flavored tools on osx handle dwarf. This means this file, IF we had unwinding support, would need to be built with clang (apple or llvm flavored). \r\n\r\n3 a)HOWEVER: on OSX the threaded RTS (when built with clang) is ~15% slower than the same built with GCC.\r\n\r\n3 b) so ideally, in a future world with unwinding on OSX, tweaking the build system to make sure that the STGCRUN.c code it always built with clang, or some other fix, that still permits a GCC built RTS OR otherwise does a fix to that GC rts perf issue, would be ideal\r\n\r\nTheres a few different action items here, and some of them are quite messy, but they all need to be done for decent perf and debugging experiences on OSX to be in the GHC future!","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/16044Transition to C11 memory model2024-01-25T14:52:44ZulanTransition to C11 memory modelFollowing offline discussion with Ben Gamari and [Cmm Memory Model thread on ghc-devs@](https://mail.haskell.org/pipermail/ghc-devs/2018-November/016581.html), I would like to propose to gradually transition RTS and Cmm to C11 memory mod...Following offline discussion with Ben Gamari and [Cmm Memory Model thread on ghc-devs@](https://mail.haskell.org/pipermail/ghc-devs/2018-November/016581.html), I would like to propose to gradually transition RTS and Cmm to C11 memory model.
There are multiple benefits:
1) Correctness: C11 atomics are properly specified and are easier to reason about than the existing SMP.h barriers.
2) Performance: compilers can optimize and generate better code for C11 atomics. For example, on ARMv8 acquire/release operations use specialized LDA/STL instructions.
3) Tooling support: once all code transitions to C11 atomics, tools like ThreadSanitizer can be used to find subtle data races.
To make sure that code continues to compile with old compilers (pre C11), I plan to introduce wrapper functions (acquire_load, release_store, etc.) that are implemented either using C11 atomics or SMP.h barriers depending on the STDC_VERSION. Here is a [prototype implementation](https://github.com/ulan/ghc/commit/0e8822a8038c3d0c770f4582c8f65b20d7823769).
The idea is that newly written code should use the wrappers and we can gradually update the existing code.
I think updating C code in RTS would work with this approach, but I am not sure about Cmm.
Please let me know if you see potential issues, a better way to implement it, or oppose moving to C11 memory model.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.6.3 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Transition to C11 memory model","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"Following offline discussion with Ben Gamari and [https://mail.haskell.org/pipermail/ghc-devs/2018-November/016581.html Cmm Memory Model thread on ghc-devs@], I would like to propose to gradually transition RTS and Cmm to C11 memory model.\r\n\r\nThere are multiple benefits:\r\n\r\n1) Correctness: C11 atomics are properly specified and are easier to reason about than the existing SMP.h barriers. \r\n\r\n2) Performance: compilers can optimize and generate better code for C11 atomics. For example, on ARMv8 acquire/release operations use specialized LDA/STL instructions.\r\n\r\n3) Tooling support: once all code transitions to C11 atomics, tools like ThreadSanitizer can be used to find subtle data races. \r\n\r\nTo make sure that code continues to compile with old compilers (pre C11), I plan to introduce wrapper functions (acquire_load, release_store, etc.) that are implemented either using C11 atomics or SMP.h barriers depending on the STDC_VERSION. Here is a [https://github.com/ulan/ghc/commit/0e8822a8038c3d0c770f4582c8f65b20d7823769 prototype implementation].\r\n\r\nThe idea is that newly written code should use the wrappers and we can gradually update the existing code.\r\n\r\nI think updating C code in RTS would work with this approach, but I am not sure about Cmm. \r\n\r\nPlease let me know if you see potential issues, a better way to implement it, or oppose moving to C11 memory model.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/16043Lots of testsuite output breaks with integer-simple2019-07-07T18:01:53ZBen GamariLots of testsuite output breaks with integer-simpleNumerous testsuite tests assume that we are using `integer-gmp`. This assumption mostly arises due to the lack of support for `integer-simple` `Integer`s in `RtClosureInspect.cPprTermBase`, causing many GHCi tests to break. I have marked...Numerous testsuite tests assume that we are using `integer-gmp`. This assumption mostly arises due to the lack of support for `integer-simple` `Integer`s in `RtClosureInspect.cPprTermBase`, causing many GHCi tests to break. I have marked these as broken to make progress on #15915.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Lots of testsuite output breaks with integer-simple","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Numerous testsuite tests assume that we are using `integer-gmp`. This assumption mostly arises due to the lack of support for `integer-simple` `Integer`s in `RtClosureInspect.cPprTermBase`, causing many GHCi tests to break. I have marked these as broken to make progress on #15915.","type_of_failure":"OtherFailure","blocking":[]} -->8.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/16042T13031 doesn't get run2019-10-17T10:40:23ZBen GamariT13031 doesn't get runSimon wrote noting that two tests in `stranal/should_compile` didn't appear to be run in his testing. I have been able to reproduce this.
A few observations:
- There is a `setTestOpts( only_ways(['optasm']) )` at the top of `stranal/sh...Simon wrote noting that two tests in `stranal/should_compile` didn't appear to be run in his testing. I have been able to reproduce this.
A few observations:
- There is a `setTestOpts( only_ways(['optasm']) )` at the top of `stranal/should_compile/test.T`
- in a `validate` build `T13031` is skipped when run with:
- `make test TEST=T13031 WAY=normal`
- `make test TEST=T13031 WAY=optasm`
- `make slowtest TEST=T13031 WAY=normal`
- `make slowtest TEST=T13031 WAY=optasm`
- When the `setTestOpts` call is commented out `T13031` is
- skipped with `make test TEST=T13031 WAY=optasm`
- run with `make test TEST=T13031 WAY=normal`
- `optasm` is in the `config.run_ways` list
I suspect what is happening here is that the `optasm` way is not being run
To be continued...
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"T13031 doesn't get run","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Simon wrote noting that two tests in `stranal/should_compile` didn't appear to be run in his testing. I have been able to reproduce this.\r\n\r\nA few observations:\r\n\r\n * There is a `setTestOpts( only_ways(['optasm']) )` at the top of `stranal/should_compile/test.T`\r\n * in a `validate` build `T13031` is skipped when run with:\r\n * `make test TEST=T13031 WAY=normal`\r\n * `make test TEST=T13031 WAY=optasm`\r\n * `make slowtest TEST=T13031 WAY=normal`\r\n * `make slowtest TEST=T13031 WAY=optasm`\r\n * When the `setTestOpts` call is commented out `T13031` is \r\n * skipped with `make test TEST=T13031 WAY=optasm`\r\n * run with `make test TEST=T13031 WAY=normal`\r\n * `optasm` is in the `config.run_ways` list\r\n\r\nI suspect what is happening here is that the `optasm` way is not being run \r\n\r\nTo be continued...","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/16041Address warnings reported by -Wincomplete-uni-patterns and -Wincomplete-recor...2020-01-23T19:38:55ZChaitanya Koparkarckoparkar@gmail.comAddress warnings reported by -Wincomplete-uni-patterns and -Wincomplete-record-updatesWhile implementing the GHC proposal which adds these flags to `-Wall`, we suppressed a lot of warnings generated due to code that is considered *unsafe* per these flags. However, the proper way to fix this is to refine things so that the...While implementing the GHC proposal which adds these flags to `-Wall`, we suppressed a lot of warnings generated due to code that is considered *unsafe* per these flags. However, the proper way to fix this is to refine things so that these warnings go away. See #15656\##16041 for more details.
w
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------------------- |
| Version | 8.6.3 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | RolandSenn, ckoparkar, goldfire |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Address warnings reported by -Wincomplete-uni-patterns and -Wincomplete-record-updates","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.10.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["RolandSenn","ckoparkar","goldfire"],"type":"Task","description":"While implementing the GHC proposal which adds these flags to {{{-Wall}}}, we suppressed a lot of warnings generated due to code that is considered ''unsafe'' per these flags. However, the proper way to fix this is to refine things so that these warnings go away. See https://ghc.haskell.org/trac/ghc/ticket/15656#comment:6 for more details.\r\nw","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/16040Unboxing-Related Performance Issue with Polymorphic Functions2022-03-16T08:32:45ZAra AdkinsUnboxing-Related Performance Issue with Polymorphic FunctionsMy team has observed a 2x performance degradation in code that makes use of `StateT` that appears to be related to strictness and unboxing, even when built with `-O2`. Our code makes heavy use of the state monad, and when GHC fails to op...My team has observed a 2x performance degradation in code that makes use of `StateT` that appears to be related to strictness and unboxing, even when built with `-O2`. Our code makes heavy use of the state monad, and when GHC fails to optimise this usage, the performance becomes untenably slow.
We've managed to minimise the behaviour to the following reproducer (that ignores state entirely), consisting of two files. It depends on `criterion`
`Lib.hs`:
```hs
{-# LANGUAGE BangPatterns #-}
module Lib where
-- A type to take the place of state
data X a = X { runX :: !a }
test1 :: Int -> Int
test1 = \(!i) -> go i where
go = \(!i) -> if i > 0
then go $! i - 1
else i
{-# NOINLINE test1 #-}
test2 :: Int -> Int
test2 = \(!i) -> runX (go i) where
go = \(!i) -> if i > 0
then go $! i - 1
else X i
{-# NOINLINE test2 #-}
```
`Main.hs`:
```hs
{-# LANGUAGE Strict #-}
module Main where
import Lib
import Criterion
import Criterion.Main
main :: IO ()
main = defaultMain
[ bgroup "main"
[ bgroup "small"
[ bench "without state" $ whnf test1 100000000
, bench "with state" $ whnf test2 100000000
]
]
]
```
Run as above, the code takes twice as long to execute `test2` as it does `test1`. However, when the signature for `runX` is changed to `runX :: !Int`, the code in `test2` exhibits identical performance to `test1`.
It has been reproduced across multiple linux64 machines, but not tested on any other architecture or operating system.
Please find the full (stack - yes, I know) project as an attachment. You can simply `stack run` to observe the issue. If you have any further queries please let me know.https://gitlab.haskell.org/ghc/ghc/-/issues/16039'GHC.Magic.noinline <var>' should not float out2020-01-23T19:38:55ZGabor Greif'GHC.Magic.noinline <var>' should not float outWhile working on #15155, I discovered that the magic function `GHC.Magic.noinline` tricked the float-out transformation into performing undesirable operations:
Looking at the Core produced:
```hs
{ ghc-prim-0.5.3:GHC....While working on #15155, I discovered that the magic function `GHC.Magic.noinline` tricked the float-out transformation into performing undesirable operations:
Looking at the Core produced:
```hs
{ ghc-prim-0.5.3:GHC.Types.I# x_azMX [Dmd=<S,U>] ->
case x_azMX of {
__DEFAULT -> jump $j_sMly;
3674937295934324920# ->
src<compiler/typecheck/TcTyClsDecls.hs:3561:9-35>
check_ty_roles_sLb3
(src<compiler/typecheck/TcTyClsDecls.hs:3561:24-26> env_aqfK)
(src<compiler/typecheck/TcTyClsDecls.hs:3561:28-31> role_aqfL)
(ghc-prim-0.5.3:GHC.Magic.noinline @ Kind liftedTypeKind)
}
}
```
After simplification we end up with a toplevel variable basically redirecting to an imported variable.
```hs
-- RHS size: {terms: 2, types: 1, coercions: 0, joins: 0/0}
lvl330_r12qn :: Kind
[GblId]
lvl330_r12qn
= ghc-prim-0.5.3:GHC.Magic.noinline @ Kind liftedTypeKind
```
This would cause `IND_STATIC`s when eventually emitted as assembly.
IIRC `GHC.Magic.noinline` was introduced with GHC v8.2. This probably regressed the float-out optimisation.
I have a patch to reclassify `noinline <some-var>` as cheap, so that it won't be floated out.
N.B.: for more details, see: https://github.com/ghc/ghc/pull/224
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"'GHC.Magic.noinline <var>' should not float out","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1","keywords":["FloatOut"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"While working on #15155, I discovered that the magic function `GHC.Magic.noinline` tricked the float-out transformation into performing undesirable operations:\r\n\r\nLooking at the Core produced:\r\n{{{#!hs\r\n { ghc-prim-0.5.3:GHC.Types.I# x_azMX [Dmd=<S,U>] ->\r\n case x_azMX of {\r\n __DEFAULT -> jump $j_sMly;\r\n 3674937295934324920# ->\r\n src<compiler/typecheck/TcTyClsDecls.hs:3561:9-35>\r\n check_ty_roles_sLb3\r\n (src<compiler/typecheck/TcTyClsDecls.hs:3561:24-26> env_aqfK)\r\n (src<compiler/typecheck/TcTyClsDecls.hs:3561:28-31> role_aqfL)\r\n (ghc-prim-0.5.3:GHC.Magic.noinline @ Kind liftedTypeKind)\r\n }\r\n }\r\n}}}\r\nAfter simplification we end up with a toplevel variable basically redirecting to an imported variable.\r\n{{{#!hs\r\n-- RHS size: {terms: 2, types: 1, coercions: 0, joins: 0/0}\r\nlvl330_r12qn :: Kind\r\n[GblId]\r\nlvl330_r12qn\r\n = ghc-prim-0.5.3:GHC.Magic.noinline @ Kind liftedTypeKind\r\n}}}\r\nThis would cause `IND_STATIC`s when eventually emitted as assembly.\r\n\r\nIIRC `GHC.Magic.noinline` was introduced with GHC v8.2. This probably regressed the float-out optimisation.\r\n\r\nI have a patch to reclassify `noinline <some-var>` as cheap, so that it won't be floated out.\r\n\r\nN.B.: for more details, see: https://github.com/ghc/ghc/pull/224","type_of_failure":"OtherFailure","blocking":[]} -->Gabor GreifGabor Greifhttps://gitlab.haskell.org/ghc/ghc/-/issues/16038Simplifier incorrectly breaks recursive groups2019-07-07T18:01:55ZÖmer Sinan AğacanSimplifier incorrectly breaks recursive groupsI found this while looking at compile time panic in my code for #9718. The test
that triggers the panic is `T4003`, but here's a simpler version of the test:
```
-- T4003B.hs
module T4003B where
import {-# SOURCE #-} T4003A (HsExpr)
d...I found this while looking at compile time panic in my code for #9718. The test
that triggers the panic is `T4003`, but here's a simpler version of the test:
```
-- T4003B.hs
module T4003B where
import {-# SOURCE #-} T4003A (HsExpr)
data HsOverLit id
= OverLit (HsExpr id)
deriving Eq
-----------------------------------
-- T4003A.hs-boot
module T4003A where
data HsExpr i
instance Eq i => Eq (HsExpr i)
-----------------------------------
-- T4003A.hs
module T4003A where
import T4003B
data HsExpr id
= HsOverLit (HsOverLit id)
| HsBracketOut (HsExpr id)
deriving Eq
```
Compile in this order: T4003A.hs-boot, T4003B.hs, T4003A.hs
```
$ ghc-stage1 -O -c T4003A.hs-boot
$ ghc-stage1 -O -c T4003B.hs
$ ghc-stage1 -O -c T4003A.hs
```
The last step fails with a panic because in the new STG pass I implemented for
#9718 I assume that all recursive groups are already in a `Rec`, but this
program has a set of bindings that are actually recursive but not in a `Rec`.
If I dump ds and simpl outputs of the last step I see that this recursive group:
(in the ds output)
```
Rec {
-- RHS size: {terms: 7, types: 8, coercions: 0, joins: 0/0}
$fEqHsExpr
$fEqHsExpr
= \ @ id_a27U $dEq_a27V ->
C:Eq ($c==_a27X $dEq_a27V) ($c/=_a287 $dEq_a27V)
-- RHS size: {terms: 9, types: 11, coercions: 0, joins: 0/0}
$c/=_a287
$c/=_a287
= \ @ id_a27U $dEq_a27V eta_B2 eta_B1 ->
$dm/= ($fEqHsExpr $dEq_a27V) eta_B2 eta_B1
-- RHS size: {terms: 37, types: 37, coercions: 0, joins: 1/3}
$c==_a27X
$c==_a27X
= \ @ id_a27U $dEq_a27V ->
let {
$dEq_a283
$dEq_a283 = $fEqHsExpr $dEq_a27V } in
let {
$dEq_a281
$dEq_a281 = $fEqHsOverLit $dEq_a27V } in
\ ds_d2jB ds_d2jC ->
join {
fail_d2jD
fail_d2jD _ = False } in
case ds_d2jB of {
HsOverLit a1_a27Q ->
case ds_d2jC of {
__DEFAULT -> jump fail_d2jD void#;
HsOverLit b1_a27R -> == $dEq_a281 a1_a27Q b1_a27R
};
HsBracketOut a1_a27S ->
case ds_d2jC of {
__DEFAULT -> jump fail_d2jD void#;
HsBracketOut b1_a27T -> == $dEq_a283 a1_a27S b1_a27T
}
}
end Rec }
-- RHS size: {terms: 1, types: 0, coercions: 0, joins: 0/0}
$fxEqHsExpr
$fxEqHsExpr = $fEqHsExpr
```
Becomes non-recursive in simplifier output:
```
Rec {
-- RHS size: {terms: 34, types: 45, coercions: 0, joins: 0/0}
$fEqHsExpr_$c==
$fEqHsExpr_$c==
= \ @ id_a27U $dEq_a27V ds_d2jB ds1_d2jC ->
case ds_d2jB of {
HsOverLit a1_a27Q ->
case ds1_d2jC of {
HsOverLit b1_a27R ->
case a1_a27Q of { OverLit a2_a2k8 ->
case b1_a27R of { OverLit b2_a2kc ->
== (noinline $fxEqHsExpr $dEq_a27V) a2_a2k8 b2_a2kc
}
};
HsBracketOut ipv_s2kg -> False
};
HsBracketOut a1_a27S ->
case ds1_d2jC of {
HsOverLit ipv_s2kj -> False;
HsBracketOut b1_a27T -> $fEqHsExpr_$c== $dEq_a27V a1_a27S b1_a27T
}
}
end Rec }
-- RHS size: {terms: 13, types: 10, coercions: 0, joins: 0/0}
$fEqHsExpr_$c/=
$fEqHsExpr_$c/=
= \ @ id_a27U $dEq_a27V eta_B2 eta1_B1 ->
case $fEqHsExpr_$c== $dEq_a27V eta_B2 eta1_B1 of {
False -> True;
True -> False
}
-- RHS size: {terms: 7, types: 8, coercions: 0, joins: 0/0}
$fEqHsExpr
$fEqHsExpr
= \ @ id_a27U $dEq_a27V ->
C:Eq ($fEqHsExpr_$c== $dEq_a27V) ($fEqHsExpr_$c/= $dEq_a27V)
-- RHS size: {terms: 1, types: 0, coercions: 0, joins: 0/0}
$fxEqHsExpr
$fxEqHsExpr = $fEqHsExpr
```
Notice that `c==` refers to `fxEqHsExpr`, which refers to `fEqHsExpr`, which
refers to `c==`, forming a recursive group.
(Confirmed with GHC 8.6.3 and GHC HEAD)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | simonpj |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Simplifier incorrectly breaks recursive groups","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["simonpj"],"type":"Bug","description":"I found this while looking at compile time panic in my code for #9718. The test\r\nthat triggers the panic is `T4003`, but here's a simpler version of the test:\r\n\r\n{{{\r\n-- T4003B.hs\r\nmodule T4003B where\r\n\r\nimport {-# SOURCE #-} T4003A (HsExpr)\r\n\r\ndata HsOverLit id\r\n = OverLit (HsExpr id)\r\n deriving Eq\r\n\r\n-----------------------------------\r\n-- T4003A.hs-boot\r\nmodule T4003A where\r\n\r\ndata HsExpr i\r\n\r\ninstance Eq i => Eq (HsExpr i)\r\n\r\n-----------------------------------\r\n-- T4003A.hs\r\nmodule T4003A where\r\n\r\nimport T4003B\r\n\r\ndata HsExpr id\r\n = HsOverLit (HsOverLit id)\r\n | HsBracketOut (HsExpr id)\r\n deriving Eq\r\n}}}\r\n\r\nCompile in this order: T4003A.hs-boot, T4003B.hs, T4003A.hs\r\n\r\n{{{\r\n$ ghc-stage1 -O -c T4003A.hs-boot\r\n$ ghc-stage1 -O -c T4003B.hs\r\n$ ghc-stage1 -O -c T4003A.hs\r\n}}}\r\n\r\nThe last step fails with a panic because in the new STG pass I implemented for\r\n#9718 I assume that all recursive groups are already in a `Rec`, but this\r\nprogram has a set of bindings that are actually recursive but not in a `Rec`.\r\n\r\nIf I dump ds and simpl outputs of the last step I see that this recursive group:\r\n(in the ds output)\r\n\r\n{{{\r\nRec {\r\n-- RHS size: {terms: 7, types: 8, coercions: 0, joins: 0/0}\r\n$fEqHsExpr\r\n$fEqHsExpr\r\n = \\ @ id_a27U $dEq_a27V ->\r\n C:Eq ($c==_a27X $dEq_a27V) ($c/=_a287 $dEq_a27V)\r\n\r\n-- RHS size: {terms: 9, types: 11, coercions: 0, joins: 0/0}\r\n$c/=_a287\r\n$c/=_a287\r\n = \\ @ id_a27U $dEq_a27V eta_B2 eta_B1 ->\r\n $dm/= ($fEqHsExpr $dEq_a27V) eta_B2 eta_B1\r\n\r\n-- RHS size: {terms: 37, types: 37, coercions: 0, joins: 1/3}\r\n$c==_a27X\r\n$c==_a27X\r\n = \\ @ id_a27U $dEq_a27V ->\r\n let {\r\n $dEq_a283\r\n $dEq_a283 = $fEqHsExpr $dEq_a27V } in\r\n let {\r\n $dEq_a281\r\n $dEq_a281 = $fEqHsOverLit $dEq_a27V } in\r\n \\ ds_d2jB ds_d2jC ->\r\n join {\r\n fail_d2jD\r\n fail_d2jD _ = False } in\r\n case ds_d2jB of {\r\n HsOverLit a1_a27Q ->\r\n case ds_d2jC of {\r\n __DEFAULT -> jump fail_d2jD void#;\r\n HsOverLit b1_a27R -> == $dEq_a281 a1_a27Q b1_a27R\r\n };\r\n HsBracketOut a1_a27S ->\r\n case ds_d2jC of {\r\n __DEFAULT -> jump fail_d2jD void#;\r\n HsBracketOut b1_a27T -> == $dEq_a283 a1_a27S b1_a27T\r\n }\r\n }\r\nend Rec }\r\n\r\n-- RHS size: {terms: 1, types: 0, coercions: 0, joins: 0/0}\r\n$fxEqHsExpr\r\n$fxEqHsExpr = $fEqHsExpr\r\n}}}\r\n\r\nBecomes non-recursive in simplifier output:\r\n\r\n{{{\r\nRec {\r\n-- RHS size: {terms: 34, types: 45, coercions: 0, joins: 0/0}\r\n$fEqHsExpr_$c==\r\n$fEqHsExpr_$c==\r\n = \\ @ id_a27U $dEq_a27V ds_d2jB ds1_d2jC ->\r\n case ds_d2jB of {\r\n HsOverLit a1_a27Q ->\r\n case ds1_d2jC of {\r\n HsOverLit b1_a27R ->\r\n case a1_a27Q of { OverLit a2_a2k8 ->\r\n case b1_a27R of { OverLit b2_a2kc ->\r\n == (noinline $fxEqHsExpr $dEq_a27V) a2_a2k8 b2_a2kc\r\n }\r\n };\r\n HsBracketOut ipv_s2kg -> False\r\n };\r\n HsBracketOut a1_a27S ->\r\n case ds1_d2jC of {\r\n HsOverLit ipv_s2kj -> False;\r\n HsBracketOut b1_a27T -> $fEqHsExpr_$c== $dEq_a27V a1_a27S b1_a27T\r\n }\r\n }\r\nend Rec }\r\n\r\n-- RHS size: {terms: 13, types: 10, coercions: 0, joins: 0/0}\r\n$fEqHsExpr_$c/=\r\n$fEqHsExpr_$c/=\r\n = \\ @ id_a27U $dEq_a27V eta_B2 eta1_B1 ->\r\n case $fEqHsExpr_$c== $dEq_a27V eta_B2 eta1_B1 of {\r\n False -> True;\r\n True -> False\r\n }\r\n\r\n-- RHS size: {terms: 7, types: 8, coercions: 0, joins: 0/0}\r\n$fEqHsExpr\r\n$fEqHsExpr\r\n = \\ @ id_a27U $dEq_a27V ->\r\n C:Eq ($fEqHsExpr_$c== $dEq_a27V) ($fEqHsExpr_$c/= $dEq_a27V)\r\n\r\n-- RHS size: {terms: 1, types: 0, coercions: 0, joins: 0/0}\r\n$fxEqHsExpr\r\n$fxEqHsExpr = $fEqHsExpr\r\n}}}\r\n\r\nNotice that `c==` refers to `fxEqHsExpr`, which refers to `fEqHsExpr`, which\r\nrefers to `c==`, forming a recursive group.\r\n\r\n(Confirmed with GHC 8.6.3 and GHC HEAD)","type_of_failure":"OtherFailure","blocking":[]} -->Ömer Sinan AğacanÖmer Sinan Ağacanhttps://gitlab.haskell.org/ghc/ghc/-/issues/16037memcpy test inexplicably failing2020-01-23T18:30:58ZBen Gamarimemcpy test inexplicably failingI have started seeing failures in the `memcpy` test:
```diff
diff -uw "codeGen/should_gen_asm/memcpy.run/memcpy.asm.normalised" "codeGen/should_gen_asm/memcpy.run/memcpy.s.normalised"
--- codeGen/should_gen_asm/memcpy.run/memcpy.asm.nor...I have started seeing failures in the `memcpy` test:
```diff
diff -uw "codeGen/should_gen_asm/memcpy.run/memcpy.asm.normalised" "codeGen/should_gen_asm/memcpy.run/memcpy.s.normalised"
--- codeGen/should_gen_asm/memcpy.run/memcpy.asm.normalised 2018-12-11 23:13:18.763730758 -0500
+++ codeGen/should_gen_asm/memcpy.run/memcpy.s.normalised 2018-12-11 23:13:18.763730758 -0500
@@ -1,9 +1,9 @@
callMemcpy:
+subq
movq
movq
movl
-subq
-movl
+xorl
call memcpy
addq
jmp
```
The failures aren't themselves concerning; the new assembler is perfectly valid:
```asm
.section .text
.align 8
.globl callMemcpy
.type callMemcpy, @function
callMemcpy:
.Lc6:
movl $1024,%eax
subq $8,%rsp
movq %rax,%rdx
movq %rbx,%rdi
movq %r14,%rsi
xorl %eax,%eax
call memcpy
addq $8,%rsp
jmp *(%rbp)
.size callMemcpy, .-callMemcpy
.section .note.GNU-stack,"",@progbits
.ident "GHC 8.7.20181211"
```
However, I have no explanation for why this suddenly started happening.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.7 |
| 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":"memcpy test inexplicably failing","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I have started seeing failures in the `memcpy` test:\r\n{{{#!diff\r\ndiff -uw \"codeGen/should_gen_asm/memcpy.run/memcpy.asm.normalised\" \"codeGen/should_gen_asm/memcpy.run/memcpy.s.normalised\"\r\n--- codeGen/should_gen_asm/memcpy.run/memcpy.asm.normalised\t2018-12-11 23:13:18.763730758 -0500\r\n+++ codeGen/should_gen_asm/memcpy.run/memcpy.s.normalised\t2018-12-11 23:13:18.763730758 -0500\r\n@@ -1,9 +1,9 @@\r\n callMemcpy:\r\n+subq\r\n movq\r\n movq\r\n movl\r\n-subq\r\n-movl\r\n+xorl\r\n call memcpy\r\n addq\r\n jmp\r\n}}}\r\nThe failures aren't themselves concerning; the new assembler is perfectly valid:\r\n{{{#!asm\r\n\r\n.section .text\r\n.align 8\r\n.globl callMemcpy\r\n.type callMemcpy, @function\r\ncallMemcpy:\r\n.Lc6:\r\n movl $1024,%eax\r\n subq $8,%rsp\r\n movq %rax,%rdx\r\n movq %rbx,%rdi\r\n movq %r14,%rsi\r\n xorl %eax,%eax\r\n call memcpy\r\n addq $8,%rsp\r\n jmp *(%rbp)\r\n .size callMemcpy, .-callMemcpy\r\n.section .note.GNU-stack,\"\",@progbits\r\n.ident \"GHC 8.7.20181211\"\r\n}}}\r\n\r\nHowever, I have no explanation for why this suddenly started happening.","type_of_failure":"OtherFailure","blocking":[]} -->8.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/16036expDouble## 0.0## doesn't get complied into 1.0##2019-07-07T18:01:56ZMateusz KowalczykexpDouble## 0.0## doesn't get complied into 1.0##```
[nix-shell:/tmp]$ cat T.hs
{-# LANGUAGE MagicHash #-}
{-# OPTIONS_GHC -O2 -ddump-simpl -ddump-to-file #-}
module T (f) where
import GHC.Float
import GHC.Prim
f :: Double
f = D# (expDouble# 0.0## -## 1.0##)
[nix-shell:/tmp]$ ghc -...```
[nix-shell:/tmp]$ cat T.hs
{-# LANGUAGE MagicHash #-}
{-# OPTIONS_GHC -O2 -ddump-simpl -ddump-to-file #-}
module T (f) where
import GHC.Float
import GHC.Prim
f :: Double
f = D# (expDouble# 0.0## -## 1.0##)
[nix-shell:/tmp]$ ghc -fforce-recomp T.hs
[1 of 1] Compiling T ( T.hs, T.o )
[nix-shell:/tmp]$ cat T.dump-simpl
==================== Tidy Core ====================
2018-12-12 02:23:40.288094743 UTC
Result size of Tidy Core
= {terms: 20, types: 6, coercions: 0, joins: 0/0}
-- RHS size: {terms: 5, types: 0, coercions: 0, joins: 0/0}
f :: Double
[GblId,
Str=m,
Unf=Unf{Src=<vanilla>, TopLvl=True, Value=True, ConLike=True,
WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 15 20}]
f = GHC.Types.D# (-## (expDouble# 0.0##) 1.0##)
…
```
This was spotted in real code where we had GHC generate something like
```haskell
1# ->
jump $j9_s1IVU
(GHC.Prim.+##
sc3_s2pVI
(GHC.Prim.-##
(GHC.Prim.expDouble#
0.0##)
1.0##))
```
I would expect this (I think reasonably) to be just `{{{jump $j9_s1IVU sc3_s2pVI}}}`.
Maybe `expDouble## <literal>##` should always evaluate at compile time to not block further constant folding?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.6.3 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"expDouble## 0.0## doesn't get complied into 1.0##","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"{{{\r\n[nix-shell:/tmp]$ cat T.hs \r\n{-# LANGUAGE MagicHash #-}\r\n{-# OPTIONS_GHC -O2 -ddump-simpl -ddump-to-file #-}\r\nmodule T (f) where\r\n\r\nimport GHC.Float\r\nimport GHC.Prim\r\n\r\nf :: Double\r\nf = D# (expDouble# 0.0## -## 1.0##)\r\n\r\n[nix-shell:/tmp]$ ghc -fforce-recomp T.hs \r\n[1 of 1] Compiling T ( T.hs, T.o )\r\n\r\n[nix-shell:/tmp]$ cat T.dump-simpl \r\n\r\n==================== Tidy Core ====================\r\n2018-12-12 02:23:40.288094743 UTC\r\n\r\nResult size of Tidy Core\r\n = {terms: 20, types: 6, coercions: 0, joins: 0/0}\r\n\r\n-- RHS size: {terms: 5, types: 0, coercions: 0, joins: 0/0}\r\nf :: Double\r\n[GblId,\r\n Str=m,\r\n Unf=Unf{Src=<vanilla>, TopLvl=True, Value=True, ConLike=True,\r\n WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 15 20}]\r\nf = GHC.Types.D# (-## (expDouble# 0.0##) 1.0##)\r\n\r\n…\r\n}}}\r\n\r\nThis was spotted in real code where we had GHC generate something like\r\n\r\n{{{#!haskell\r\n1# ->\r\n jump $j9_s1IVU\r\n (GHC.Prim.+##\r\n sc3_s2pVI\r\n (GHC.Prim.-##\r\n (GHC.Prim.expDouble#\r\n 0.0##)\r\n 1.0##))\r\n}}}\r\n\r\nI would expect this (I think reasonably) to be just `{{{jump $j9_s1IVU sc3_s2pVI}}}`.\r\n\r\nMaybe {{{expDouble## <literal>##}}} should always evaluate at compile time to not block further constant folding?","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/16035keep-cafs fails on FreeBSD 112021-12-20T01:37:15ZBen Gamarikeep-cafs fails on FreeBSD 11It's a bit unclear why:
```patch
=====> keep-cafs(normal) 9 of 10 [0, 4, 2]
cd "rts/keep-cafs.run" && $MAKE -s --no-print-directory KeepCafs
Actual stdout output differs from expected:
diff -uw "rts/keep-cafs.run/keep-cafs.stdout.norm...It's a bit unclear why:
```patch
=====> keep-cafs(normal) 9 of 10 [0, 4, 2]
cd "rts/keep-cafs.run" && $MAKE -s --no-print-directory KeepCafs
Actual stdout output differs from expected:
diff -uw "rts/keep-cafs.run/keep-cafs.stdout.normalised" "rts/keep-cafs.run/keep-cafs.run.stdout.normalised"
--- rts/keep-cafs.run/keep-cafs.stdout.normalised 2018-12-11 22:41:53.650952000 +0000
+++ rts/keep-cafs.run/keep-cafs.run.stdout.normalised 2018-12-11 22:41:53.651227000 +0000
@@ -1,2 +1,4 @@
-1000
-1001
+KeepCafsMain: KeepCafs1.o: unknown symbol `base_GHCziBase_zdfMonadIO_closure'
+KeepCafsMain: KeepCafs2.o: unknown symbol `base_GHCziNum_zdfNumInt_closure'
+34410180672
+34410180672
```
Perhaps a GHCi linker issue?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System (Linker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"keep-cafs fails on FreeBSD 11","status":"New","operating_system":"","component":"Runtime System (Linker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"It's a bit unclear why:\r\n{{{#!patch\r\n=====> keep-cafs(normal) 9 of 10 [0, 4, 2]\r\ncd \"rts/keep-cafs.run\" && $MAKE -s --no-print-directory KeepCafs \r\nActual stdout output differs from expected:\r\ndiff -uw \"rts/keep-cafs.run/keep-cafs.stdout.normalised\" \"rts/keep-cafs.run/keep-cafs.run.stdout.normalised\"\r\n--- rts/keep-cafs.run/keep-cafs.stdout.normalised\t2018-12-11 22:41:53.650952000 +0000\r\n+++ rts/keep-cafs.run/keep-cafs.run.stdout.normalised\t2018-12-11 22:41:53.651227000 +0000\r\n@@ -1,2 +1,4 @@\r\n-1000\r\n-1001\r\n+KeepCafsMain: KeepCafs1.o: unknown symbol `base_GHCziBase_zdfMonadIO_closure'\r\n+KeepCafsMain: KeepCafs2.o: unknown symbol `base_GHCziNum_zdfNumInt_closure'\r\n+34410180672\r\n+34410180672\r\n}}}\r\n\r\nPerhaps a GHCi linker issue?","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/16034Quadratic GC slowdown using RTS debug2019-07-07T18:01:56ZremyoQuadratic GC slowdown using RTS debugHello,
Under some conditions of heavy heap usage, I seem to experience a quadratic slowdown due to GC using the debugging RTS only (for example, in the context of ticky profiling).
I have been able to reproduce it using the following p...Hello,
Under some conditions of heavy heap usage, I seem to experience a quadratic slowdown due to GC using the debugging RTS only (for example, in the context of ticky profiling).
I have been able to reproduce it using the following program (depending on the aeson library):
```hs
import Data.Aeson (eitherDecode, Value)
import qualified Data.ByteString.Lazy as BL
import Data.Maybe (catMaybes)
import System.Directory (listDirectory)
import System.FilePath ( (</>) )
main :: IO()
main = do
let dir = "data"
files <- listDirectory dir
values <- catMaybes <$> mapM (readF dir) files
print $ length values
readF :: FilePath -> FilePath -> IO (Maybe Value)
readF dir fp = do
print (dir </> fp)
blob <- BL.readFile (dir </> fp)
case eitherDecode blob of
Left _ -> return Nothing
Right v -> return $ Just $! v
```
Here data is a directory filled with (identical) JSON files. See the attached Python script for the proposed dataset.
```
$ ghc -O -dynamic -o main Main.hs
$ ./main +RTS -s
...
18,583,045,600 bytes allocated in the heap
6,334,338,280 bytes copied during GC
975,763,072 bytes maximum residency (14 sample(s))
6,986,112 bytes maximum slop
930 MB total memory in use (0 MB lost due to fragmentation)
Tot time (elapsed) Avg pause Max pause
Gen 0 17727 colls, 0 par 2.596s 2.597s 0.0001s 0.0006s
Gen 1 14 colls, 0 par 2.422s 2.422s 0.1730s 0.7947s
INIT time 0.000s ( 0.000s elapsed)
MUT time 3.349s ( 3.351s elapsed)
GC time 5.019s ( 5.020s elapsed)
EXIT time 0.000s ( 0.000s elapsed)
Total time 8.368s ( 8.371s elapsed)
%GC time 0.0% (0.0% elapsed)
Alloc rate 5,548,968,539 bytes per MUT second
Productivity 40.0% of total user, 40.0% of total elapsed
```
```
$ ghc -O -dynamic -debug -o main.debug Main.hs
$ ./main +RTS -s
...
18,583,045,600 bytes allocated in the heap
6,334,332,424 bytes copied during GC
975,763,072 bytes maximum residency (14 sample(s))
6,986,112 bytes maximum slop
930 MB total memory in use (0 MB lost due to fragmentation)
Tot time (elapsed) Avg pause Max pause
Gen 0 17727 colls, 0 par 172.941s 172.959s 0.0098s 0.0459s
Gen 1 14 colls, 0 par 9.532s 9.532s 0.6808s 3.2061s
INIT time 0.000s ( 0.000s elapsed)
MUT time 5.020s ( 5.017s elapsed)
GC time 182.473s (182.491s elapsed)
EXIT time 0.000s ( 0.000s elapsed)
Total time 187.492s (187.508s elapsed)
%GC time 0.0% (0.0% elapsed)
Alloc rate 3,701,999,827 bytes per MUT second
Productivity 2.7% of total user, 2.7% of total elapsed
```
In debug mode, the runtime is almost quadratic:
```
Nb of files Duration (non-debug) Duration (debug)
100 0.8s 2.8s
200 1.6s 8.8s
400 3.2s 27.6s
1000 8.2s 168.9s
```
The problem can be seen with either GHC 8.6.3 (here on Archlinux, with aeson 1.4.2.0) but was also observed using GHC 8.4.4, with static binaries, using "stack". I was able to reproduce with both threaded and non-threaded mode.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.6.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | aspiwack |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Quadratic GC slowdown using RTS debug","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["aspiwack"],"type":"Bug","description":"Hello,\r\n\r\nUnder some conditions of heavy heap usage, I seem to experience a quadratic slowdown due to GC using the debugging RTS only (for example, in the context of ticky profiling).\r\n\r\nI have been able to reproduce it using the following program (depending on the aeson library):\r\n{{{#!hs\r\nimport Data.Aeson (eitherDecode, Value)\r\nimport qualified Data.ByteString.Lazy as BL\r\nimport Data.Maybe (catMaybes)\r\nimport System.Directory (listDirectory)\r\nimport System.FilePath ( (</>) )\r\n\r\nmain :: IO()\r\nmain = do\r\n let dir = \"data\"\r\n files <- listDirectory dir\r\n values <- catMaybes <$> mapM (readF dir) files\r\n print $ length values\r\n\r\nreadF :: FilePath -> FilePath -> IO (Maybe Value)\r\nreadF dir fp = do\r\n print (dir </> fp)\r\n blob <- BL.readFile (dir </> fp)\r\n case eitherDecode blob of\r\n Left _ -> return Nothing\r\n Right v -> return $ Just $! v\r\n}}}\r\n\r\nHere data is a directory filled with (identical) JSON files. See the attached Python script for the proposed dataset.\r\n\r\n{{{\r\n$ ghc -O -dynamic -o main Main.hs\r\n$ ./main +RTS -s\r\n...\r\n 18,583,045,600 bytes allocated in the heap\r\n 6,334,338,280 bytes copied during GC\r\n 975,763,072 bytes maximum residency (14 sample(s))\r\n 6,986,112 bytes maximum slop\r\n 930 MB total memory in use (0 MB lost due to fragmentation)\r\n\r\n Tot time (elapsed) Avg pause Max pause\r\n Gen 0 17727 colls, 0 par 2.596s 2.597s 0.0001s 0.0006s\r\n Gen 1 14 colls, 0 par 2.422s 2.422s 0.1730s 0.7947s\r\n\r\n INIT time 0.000s ( 0.000s elapsed)\r\n MUT time 3.349s ( 3.351s elapsed)\r\n GC time 5.019s ( 5.020s elapsed)\r\n EXIT time 0.000s ( 0.000s elapsed)\r\n Total time 8.368s ( 8.371s elapsed)\r\n\r\n %GC time 0.0% (0.0% elapsed)\r\n\r\n Alloc rate 5,548,968,539 bytes per MUT second\r\n\r\n Productivity 40.0% of total user, 40.0% of total elapsed\r\n}}}\r\n\r\n{{{\r\n$ ghc -O -dynamic -debug -o main.debug Main.hs\r\n$ ./main +RTS -s\r\n...\r\n 18,583,045,600 bytes allocated in the heap\r\n 6,334,332,424 bytes copied during GC\r\n 975,763,072 bytes maximum residency (14 sample(s))\r\n 6,986,112 bytes maximum slop\r\n 930 MB total memory in use (0 MB lost due to fragmentation)\r\n\r\n Tot time (elapsed) Avg pause Max pause\r\n Gen 0 17727 colls, 0 par 172.941s 172.959s 0.0098s 0.0459s\r\n Gen 1 14 colls, 0 par 9.532s 9.532s 0.6808s 3.2061s\r\n\r\n INIT time 0.000s ( 0.000s elapsed)\r\n MUT time 5.020s ( 5.017s elapsed)\r\n GC time 182.473s (182.491s elapsed)\r\n EXIT time 0.000s ( 0.000s elapsed)\r\n Total time 187.492s (187.508s elapsed)\r\n\r\n %GC time 0.0% (0.0% elapsed)\r\n\r\n Alloc rate 3,701,999,827 bytes per MUT second\r\n\r\n Productivity 2.7% of total user, 2.7% of total elapsed\r\n}}}\r\n\r\nIn debug mode, the runtime is almost quadratic:\r\n{{{\r\nNb of files Duration (non-debug) Duration (debug)\r\n 100 0.8s 2.8s\r\n 200 1.6s 8.8s\r\n 400 3.2s 27.6s\r\n1000 8.2s 168.9s\r\n}}}\r\n\r\nThe problem can be seen with either GHC 8.6.3 (here on Archlinux, with aeson 1.4.2.0) but was also observed using GHC 8.4.4, with static binaries, using \"stack\". I was able to reproduce with both threaded and non-threaded mode.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/16033Rank-n typechecking regression between GHC 8.4 and 8.62019-07-07T18:01:56ZRyan ScottRank-n typechecking regression between GHC 8.4 and 8.6The following program typechecks on GHC 7.0.4 through 8.4.4:
```hs
{-# LANGUAGE GADTs #-}
{-# LANGUAGE RankNTypes #-}
{-# LANGUAGE ScopedTypeVariables #-}
module Bug where
f :: (forall a. a -> forall b. b -> c) -> ()
f (_ :: forall...The following program typechecks on GHC 7.0.4 through 8.4.4:
```hs
{-# LANGUAGE GADTs #-}
{-# LANGUAGE RankNTypes #-}
{-# LANGUAGE ScopedTypeVariables #-}
module Bug where
f :: (forall a. a -> forall b. b -> c) -> ()
f (_ :: forall a. a -> forall b. b -> c) = ()
```
However, it does not typecheck on GHC 8.6.3:
```
$ /opt/ghc/8.6.3/bin/ghc Bug.hs
[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
Bug.hs:7:4: error:
• Couldn't match type ‘b0 -> c1’ with ‘forall b. b -> c’
Expected type: a -> forall b. b -> c
Actual type: a -> b0 -> c1
• When checking that the pattern signature:
forall a. a -> forall b. b -> c
fits the type of its context: forall a. a -> forall b. b -> c1
In the pattern: _ :: forall a. a -> forall b. b -> c
In an equation for ‘f’:
f (_ :: forall a. a -> forall b. b -> c) = ()
• Relevant bindings include
f :: (forall a. a -> forall b. b -> c1) -> () (bound at Bug.hs:7:1)
|
7 | f (_ :: forall a. a -> forall b. b -> c) = ()
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
```8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/16032Compile speed regression2019-07-07T18:01:57Zlennart@augustsson.netCompile speed regressionGHC 8.6.3 seems to be about 10% slower than GHC 8.4.4 compiling a large input. The times goes from 22.25m to 24.5m.
Unfortunately, I cannot include the modules to reproduce it.
<details><summary>Trac metadata</summary>
| Trac field ...GHC 8.6.3 seems to be about 10% slower than GHC 8.4.4 compiling a large input. The times goes from 22.25m to 24.5m.
Unfortunately, I cannot include the modules to reproduce it.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Compile speed regression","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"GHC 8.6.3 seems to be about 10% slower than GHC 8.4.4 compiling a large input. The times goes from 22.25m to 24.5m.\r\n\r\nUnfortunately, I cannot include the modules to reproduce it.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/16031Show instance for Data.Fixed does not show parentheses for negatives2019-07-07T18:01:57ZSteven KeuchelShow instance for Data.Fixed does not show parentheses for negativesWhen showing negative numbers most types emit parentheses in precedence level 11 because the result is not atomic:
```hs
GHCi, version 8.7.20181015: http://www.haskell.org/ghc/ :? for help
Prelude> show (Just (-1 :: Int))
"Just (-1)"
P...When showing negative numbers most types emit parentheses in precedence level 11 because the result is not atomic:
```hs
GHCi, version 8.7.20181015: http://www.haskell.org/ghc/ :? for help
Prelude> show (Just (-1 :: Int))
"Just (-1)"
Prelude> show (Just (-1 :: Float))
"Just (-1.0)"
```
However, the Show instance for Fixed does not
```hs
Prelude> :m Data.Fixed
Prelude Data.Fixed> show (Just (-1 :: Fixed E2))
"Just -1.00"
Prelude Data.Fixed>
```
I would expect it to, because of consistency and because the result "Just -1.00" is ill-typed when seen as an expression.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Show instance for Data.Fixed does not show parentheses for negatives","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.7","keywords":["Data.Fixed,","Show"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When showing negative numbers most types emit parentheses in precedence level 11 because the result is not atomic: \r\n\r\n{{{#!hs\r\nGHCi, version 8.7.20181015: http://www.haskell.org/ghc/ :? for help\r\nPrelude> show (Just (-1 :: Int))\r\n\"Just (-1)\"\r\nPrelude> show (Just (-1 :: Float))\r\n\"Just (-1.0)\"\r\n}}}\r\n\r\nHowever, the Show instance for Fixed does not\r\n\r\n{{{#!hs\r\nPrelude> :m Data.Fixed\r\nPrelude Data.Fixed> show (Just (-1 :: Fixed E2))\r\n\"Just -1.00\"\r\nPrelude Data.Fixed> \r\n}}}\r\n\r\nI would expect it to, because of consistency and because the result \"Just -1.00\" is ill-typed when seen as an expression.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1Sven TennieSven Tenniehttps://gitlab.haskell.org/ghc/ghc/-/issues/16030Poor pretty-printing of GADT constructors in GHCi2019-07-07T18:01:57ZRyan ScottPoor pretty-printing of GADT constructors in GHCiI recently loaded this file into GHCi:
```hs
{-# LANGUAGE GADTs #-}
{-# LANGUAGE PolyKinds #-}
{-# LANGUAGE TypeFamilies #-}
module Bug where
import Data.Proxy
data Foo1 (a :: k) where
MkFoo1a :: Proxy a -> Int -> Foo1 a
MkFoo1b :...I recently loaded this file into GHCi:
```hs
{-# LANGUAGE GADTs #-}
{-# LANGUAGE PolyKinds #-}
{-# LANGUAGE TypeFamilies #-}
module Bug where
import Data.Proxy
data Foo1 (a :: k) where
MkFoo1a :: Proxy a -> Int -> Foo1 a
MkFoo1b :: { a :: Proxy a, b :: Int } -> Foo1 a
data family Foo2 (a :: k)
data instance Foo2 (a :: k) where
MkFoo2a :: Proxy a -> Int -> Foo2 a
MkFoo2b :: { c :: Proxy a, d :: Int} -> Foo2 a
```
And when I queried these datatypes with `:info`, I saw this:
```
$ ~/Software/ghc/inplace/bin/ghc-stage2 --interactive Bug.hs -fprint-explicit-kinds
GHCi, version 8.7.20181129: http://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /home/rgscott/.ghci
[1 of 1] Compiling Bug ( Bug.hs, interpreted )
Ok, one module loaded.
λ> :i Foo1 Foo2
type role Foo1 nominal phantom
data Foo1 @k (a :: k) where
MkFoo1a :: forall k (a :: k). (Proxy @{k} a) -> Int -> Foo1 k a
MkFoo1b :: forall k (a :: k).
{a :: Proxy @{k} a, b :: Int} -> Foo1 k a
-- Defined at Bug.hs:8:1
data family Foo2 @k (a :: k) -- Defined at Bug.hs:12:1
data instance forall k (a :: k). Foo2 @k a where
MkFoo2a :: forall k (a :: k). (Proxy @{k} a) -> Int -> Foo2 @k a
MkFoo2b :: forall k (a :: k).
{c :: Proxy @{k} a, d :: Int} -> Foo2 @k a
-- Defined at Bug.hs:13:15
```
Yuck. A couple of icky things to note here:
- For some reason, the `Proxy @{k} a` field is needlessly parenthesized in `MkFoo1a` and `MkFoo2a`. This does //not// happen when record syntax is used, as demonstrated with `MkFoo1b` and `MkFoo2b`.
- Even more strangely, despite the fact that `k` is a specified argument, we're pretty-printing the return type of `MkFoo1{a,b}` as `Foo k a`, not `Foo @k a`. This problem doesn't appear to happen for data family instances, since `MkFoo2{a,b}` don't have this issue.
Patch incoming.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Poor pretty-printing of GADT constructors in GHCi","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I recently loaded this file into GHCi:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE GADTs #-}\r\n{-# LANGUAGE PolyKinds #-}\r\n{-# LANGUAGE TypeFamilies #-}\r\nmodule Bug where\r\n\r\nimport Data.Proxy\r\n\r\ndata Foo1 (a :: k) where\r\n MkFoo1a :: Proxy a -> Int -> Foo1 a\r\n MkFoo1b :: { a :: Proxy a, b :: Int } -> Foo1 a\r\n\r\ndata family Foo2 (a :: k)\r\ndata instance Foo2 (a :: k) where\r\n MkFoo2a :: Proxy a -> Int -> Foo2 a\r\n MkFoo2b :: { c :: Proxy a, d :: Int} -> Foo2 a\r\n}}}\r\n\r\nAnd when I queried these datatypes with `:info`, I saw this:\r\n\r\n{{{\r\n$ ~/Software/ghc/inplace/bin/ghc-stage2 --interactive Bug.hs -fprint-explicit-kinds\r\nGHCi, version 8.7.20181129: http://www.haskell.org/ghc/ :? for help\r\nLoaded GHCi configuration from /home/rgscott/.ghci\r\n[1 of 1] Compiling Bug ( Bug.hs, interpreted )\r\nOk, one module loaded.\r\nλ> :i Foo1 Foo2\r\ntype role Foo1 nominal phantom\r\ndata Foo1 @k (a :: k) where\r\n MkFoo1a :: forall k (a :: k). (Proxy @{k} a) -> Int -> Foo1 k a\r\n MkFoo1b :: forall k (a :: k).\r\n {a :: Proxy @{k} a, b :: Int} -> Foo1 k a\r\n -- Defined at Bug.hs:8:1\r\ndata family Foo2 @k (a :: k) -- Defined at Bug.hs:12:1\r\ndata instance forall k (a :: k). Foo2 @k a where\r\n MkFoo2a :: forall k (a :: k). (Proxy @{k} a) -> Int -> Foo2 @k a\r\n MkFoo2b :: forall k (a :: k).\r\n {c :: Proxy @{k} a, d :: Int} -> Foo2 @k a\r\n -- Defined at Bug.hs:13:15\r\n}}}\r\n\r\nYuck. A couple of icky things to note here:\r\n\r\n* For some reason, the `Proxy @{k} a` field is needlessly parenthesized in `MkFoo1a` and `MkFoo2a`. This does //not// happen when record syntax is used, as demonstrated with `MkFoo1b` and `MkFoo2b`.\r\n* Even more strangely, despite the fact that `k` is a specified argument, we're pretty-printing the return type of `MkFoo1{a,b}` as `Foo k a`, not `Foo @k a`. This problem doesn't appear to happen for data family instances, since `MkFoo2{a,b}` don't have this issue.\r\n\r\nPatch incoming.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/16029Inadequate absence analysis2019-07-07T18:01:57ZSimon Peyton JonesInadequate absence analysisConsider
```
data S = MkS Int Int
g1 :: S -> Int -> Int
g1 (MkS x y) 0 = 0
g1 (MkS x y) n = g1 (MkS y x) (n-1)
```
With GHC 8.6 we get
```
$wg1 :: S -> GHC.Prim.Int# -> GHC.Prim.Int#
[Str=<S,1*H><S,1*U>]
$wg1 = \ (w_s2oH :: S)
...Consider
```
data S = MkS Int Int
g1 :: S -> Int -> Int
g1 (MkS x y) 0 = 0
g1 (MkS x y) n = g1 (MkS y x) (n-1)
```
With GHC 8.6 we get
```
$wg1 :: S -> GHC.Prim.Int# -> GHC.Prim.Int#
[Str=<S,1*H><S,1*U>]
$wg1 = \ (w_s2oH :: S)
(ww_s2oL :: GHC.Prim.Int#) ->
case w_s2oH of { MkS x_s2pz y_s2pA ->
case ww_s2oL of ds_X2nb {
__DEFAULT ->
Foo.$wg1 (Foo.MkS y_s2pA x_s2pz) (GHC.Prim.-# ds_X2nb 1#);
0# -> 0# }}
g1 :: S -> Int -> Int
[Str=<S,1*H><S(S),1*U(1*U)>m]
g1 = \ (w_s2oH :: S) (w1_s2oI :: Int) ->
case w_s2oH of w2_X2pG { MkS ipv_s2p2 ipv1_s2p3 ->
case w1_s2oI of { GHC.Types.I# ww1_s2oL ->
case Foo.$wg1 w2_X2pG ww1_s2oL of ww2_s2oP { __DEFAULT ->
GHC.Types.I# ww2_s2oP }}}
```
What terrible code! We evaluate the S argument in the wrapper,
and box and unbox it every time around the loop, even though it is never ultimately used.
Here's what happens if the arguments are banged:
```
data T = MkT !Int !Int
g2 :: T -> Int -> Int
g2 (MkT x y) 0 = 0
g2 (MkT x y) n = g2 (MkT y x) (n-1)
```
We get
```
$wg2 GHC.Prim.Int# -> GHC.Prim.Int# -> GHC.Prim.Int# -> GHC.Prim.Int#
[Str=<L,1*U><L,1*U><S,1*U>]
Foo.$wg2 = \ (ww_s2ow :: GHC.Prim.Int#)
(ww1_s2ox :: GHC.Prim.Int#)
(ww2_s2oB :: GHC.Prim.Int#) ->
case ww2_s2oB of ds_X2n0 {
__DEFAULT -> Foo.$wg2 ww1_s2ox ww_s2ow (GHC.Prim.-# ds_X2n0 1#);
0# -> 0# }
g2 :: T -> Int -> Int
[Str=<S(SS),1*U(1*U,1*U)><S(S),1*U(1*U)>m ]
g2 = \ (w_s2os :: T) (w1_s2ot :: Int) ->
case w_s2os of { MkT ww1_s2ow ww2_s2ox ->
case w1_s2ot of { GHC.Types.I# ww4_s2oB ->
case Foo.$wg2 ww1_s2ow ww2_s2ox ww4_s2oB of ww5_s2oF {
__DEFAULT -> GHC.Types.I# ww5_s2oF }}}
```
Still terrible. We pass the two components around the loop before discarding them
at the end.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Inadequate absence analysis","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Consider\r\n{{{\r\ndata S = MkS Int Int\r\ng1 :: S -> Int -> Int\r\ng1 (MkS x y) 0 = 0\r\ng1 (MkS x y) n = g1 (MkS y x) (n-1)\r\n}}}\r\nWith GHC 8.6 we get\r\n{{{\r\n$wg1 :: S -> GHC.Prim.Int# -> GHC.Prim.Int#\r\n[Str=<S,1*H><S,1*U>]\r\n$wg1 = \\ (w_s2oH :: S)\r\n (ww_s2oL :: GHC.Prim.Int#) ->\r\n case w_s2oH of { MkS x_s2pz y_s2pA ->\r\n case ww_s2oL of ds_X2nb {\r\n __DEFAULT ->\r\n Foo.$wg1 (Foo.MkS y_s2pA x_s2pz) (GHC.Prim.-# ds_X2nb 1#);\r\n 0# -> 0# }}\r\n\r\ng1 :: S -> Int -> Int\r\n[Str=<S,1*H><S(S),1*U(1*U)>m]\r\ng1 = \\ (w_s2oH :: S) (w1_s2oI :: Int) ->\r\n case w_s2oH of w2_X2pG { MkS ipv_s2p2 ipv1_s2p3 ->\r\n case w1_s2oI of { GHC.Types.I# ww1_s2oL ->\r\n case Foo.$wg1 w2_X2pG ww1_s2oL of ww2_s2oP { __DEFAULT ->\r\n GHC.Types.I# ww2_s2oP }}}\r\n}}}\r\nWhat terrible code! We evaluate the S argument in the wrapper,\r\nand box and unbox it every time around the loop, even though it is never ultimately used.\r\n\r\nHere's what happens if the arguments are banged:\r\n{{{\r\ndata T = MkT !Int !Int\r\ng2 :: T -> Int -> Int\r\ng2 (MkT x y) 0 = 0\r\ng2 (MkT x y) n = g2 (MkT y x) (n-1)\r\n}}}\r\nWe get\r\n{{{\r\n$wg2 GHC.Prim.Int# -> GHC.Prim.Int# -> GHC.Prim.Int# -> GHC.Prim.Int#\r\n[Str=<L,1*U><L,1*U><S,1*U>]\r\nFoo.$wg2 = \\ (ww_s2ow :: GHC.Prim.Int#)\r\n (ww1_s2ox :: GHC.Prim.Int#)\r\n (ww2_s2oB :: GHC.Prim.Int#) ->\r\n case ww2_s2oB of ds_X2n0 {\r\n __DEFAULT -> Foo.$wg2 ww1_s2ox ww_s2ow (GHC.Prim.-# ds_X2n0 1#);\r\n 0# -> 0# }\r\n\r\ng2 :: T -> Int -> Int\r\n[Str=<S(SS),1*U(1*U,1*U)><S(S),1*U(1*U)>m ]\r\ng2 = \\ (w_s2os :: T) (w1_s2ot :: Int) ->\r\n case w_s2os of { MkT ww1_s2ow ww2_s2ox ->\r\n case w1_s2ot of { GHC.Types.I# ww4_s2oB ->\r\n case Foo.$wg2 ww1_s2ow ww2_s2ox ww4_s2oB of ww5_s2oF {\r\n __DEFAULT -> GHC.Types.I# ww5_s2oF }}}\r\n}}}\r\nStill terrible. We pass the two components around the loop before discarding them\r\nat the end.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.6.3https://gitlab.haskell.org/ghc/ghc/-/issues/16028tyThingCoAxiom panics while building Agda2019-07-07T18:01:58ZIlias TsitsimpistyThingCoAxiom panics while building Agdaghc-8.4.4 panics while building Agda on armhf (https://buildd.debian.org/status/fetch.php?pkg=agda&arch=armhf&ver=2.5.4.1-3%2Bb1&stamp=1544132023&raw=0):
```
ghc: panic! (the 'impossible' happened)
(GHC version 8.4.4 for arm-unknown-l...ghc-8.4.4 panics while building Agda on armhf (https://buildd.debian.org/status/fetch.php?pkg=agda&arch=armhf&ver=2.5.4.1-3%2Bb1&stamp=1544132023&raw=0):
```
ghc: panic! (the 'impossible' happened)
(GHC version 8.4.4 for arm-unknown-linux):
tyThingCoAxiom
Identifier ‘fromDescListWithKey’
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable
pprPanic, called at compiler/main/HscTypes.hs:2153:32 in ghc:HscTypes
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
The same version of Agda builds fine with ghc-8.4.3 on armhf (https://buildd.debian.org/status/fetch.php?pkg=agda&arch=armhf&ver=2.5.4.1-3&stamp=1540145469&raw=0).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.4 |
| 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":"tyThingCoAxiom panics while building Agda","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.4","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"ghc-8.4.4 panics while building Agda on armhf (https://buildd.debian.org/status/fetch.php?pkg=agda&arch=armhf&ver=2.5.4.1-3%2Bb1&stamp=1544132023&raw=0):\r\n{{{\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 8.4.4 for arm-unknown-linux):\r\n\ttyThingCoAxiom\r\n Identifier ‘fromDescListWithKey’\r\n Call stack:\r\n CallStack (from HasCallStack):\r\n callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable\r\n pprPanic, called at compiler/main/HscTypes.hs:2153:32 in ghc:HscTypes\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\nThe same version of Agda builds fine with ghc-8.4.3 on armhf (https://buildd.debian.org/status/fetch.php?pkg=agda&arch=armhf&ver=2.5.4.1-3&stamp=1540145469&raw=0).","type_of_failure":"OtherFailure","blocking":[]} -->8.6.4https://gitlab.haskell.org/ghc/ghc/-/issues/16027Cannot use DefaultSignatures for TypeFamiles2019-07-07T18:01:58ZJohn EricsonCannot use DefaultSignatures for TypeFamilesI'm surprised there wasn't a ticket for this. Maybe I just couldn't find it.
In short, I want to do something like:
```
class Monad m => MyMonad m where
type AssociatedMonad m :: Type -> Type
default type AssociatedMonad m :: (...I'm surprised there wasn't a ticket for this. Maybe I just couldn't find it.
In short, I want to do something like:
```
class Monad m => MyMonad m where
type AssociatedMonad m :: Type -> Type
default type AssociatedMonad m :: (m ~ t m', MonadTrans t, MyMonad m') => Type -> Type
type AssociatedMonad (t m') = t (AssociatedMonad m')
fun :: Foo -> m ()
default fun :: (m ~ t m', MonadTrans t, MyMonad m') => Foo -> m ()
fun = lift . fun
```
The syntax is a bit weird, but I hope in the process of implementing constrained type families the syntax properly analogous to the term-level would shake itself out.
The use-case, like the normal method original, is to assist with monad transformer boilerplate. `MonadTrans` wouldn't be enough, but `MFunctor` from mmorph might be depending on the method using the associated type.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.6.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Cannot use DefaultSignatures for TypeFamiles","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"I'm surprised there wasn't a ticket for this. Maybe I just couldn't find it.\r\n\r\nIn short, I want to do something like:\r\n{{{\r\nclass Monad m => MyMonad m where\r\n type AssociatedMonad m :: Type -> Type\r\n default type AssociatedMonad m :: (m ~ t m', MonadTrans t, MyMonad m') => Type -> Type\r\n type AssociatedMonad (t m') = t (AssociatedMonad m')\r\n\r\n fun :: Foo -> m ()\r\n default fun :: (m ~ t m', MonadTrans t, MyMonad m') => Foo -> m ()\r\n fun = lift . fun\r\n}}}\r\n\r\nThe syntax is a bit weird, but I hope in the process of implementing constrained type families the syntax properly analogous to the term-level would shake itself out.\r\n\r\nThe use-case, like the normal method original, is to assist with monad transformer boilerplate. {{{MonadTrans}}} wouldn't be enough, but {{{MFunctor}}} from mmorph might be depending on the method using the associated type.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.3https://gitlab.haskell.org/ghc/ghc/-/issues/16026No way to run a subset of the testsuite2019-07-07T18:01:58ZBen GamariNo way to run a subset of the testsuiteCurrently Hadrian lacks an analogue of the `TEST=...` variables in the `make` build system's `test` target. In other words, it's not possible to run a subset of the testsuite.
<details><summary>Trac metadata</summary>
| Trac field ...Currently Hadrian lacks an analogue of the `TEST=...` variables in the `make` build system's `test` target. In other words, it's not possible to run a subset of the testsuite.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------------- |
| Version | 8.6.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Build System (Hadrian) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"No way to run a subset of the testsuite","status":"New","operating_system":"","component":"Build System (Hadrian)","related":[],"milestone":"8.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Currently Hadrian lacks an analogue of the `TEST=...` variables in the `make` build system's `test` target. In other words, it's not possible to run a subset of the testsuite.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1Alp MestanogullariAlp Mestanogullari