GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:59:55Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/4237-dcore-lint error after simplifier iteration 1 when profiling2019-07-07T18:59:55ZWolfram Kahl-dcore-lint error after simplifier iteration 1 when profilingThis happens with the current development version of Agda, with last change from July 20.
```
darcs get --lazy http://code.haskell.org/Agda
```
I did:
```
./Setup configure -p --prefix=/usr/local/packages/ghc-6.12.3 --ghc-option=-dcor...This happens with the current development version of Agda, with last change from July 20.
```
darcs get --lazy http://code.haskell.org/Agda
```
I did:
```
./Setup configure -p --prefix=/usr/local/packages/ghc-6.12.3 --ghc-option=-dcore-lint
./Setup build -v > build.log 2>&1
```
`build.log` is attached, and shows a core-lint error in the profiling way.
I tried this since I am getting segfaults and other errors in long Agda runs with more than 4GB heap, and have no idea yet how to trim them down.
Wolfram
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.12.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":"-dcore-lint error after simplifier iteration 1 when profiling","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.3","keywords":["core-lint","profiling,","simplifier,"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This happens with the current development version of Agda, with last change from July 20.\r\n\r\n{{{\r\ndarcs get --lazy http://code.haskell.org/Agda\r\n}}}\r\n\r\nI did:\r\n\r\n{{{\r\n./Setup configure -p --prefix=/usr/local/packages/ghc-6.12.3 --ghc-option=-dcore-lint\r\n./Setup build -v > build.log 2>&1\r\n}}}\r\n\r\n{{{build.log}}} is attached, and shows a core-lint error in the profiling way.\r\n\r\nI tried this since I am getting segfaults and other errors in long Agda runs with more than 4GB heap, and have no idea yet how to trim them down.\r\n\r\nWolfram","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/3856Share code between C wrappers2019-07-07T19:01:50ZIan Lynagh <igloo@earth.li>Share code between C wrappers`driver/ghci/ghci.c` and `driver/gcc/gcc.c` do more-or-less the same thing in different ways; I think `gcc.c` is the newer, and simpler. Share code if possible.
<details><summary>Trac metadata</summary>
| Trac field | Value...`driver/ghci/ghci.c` and `driver/gcc/gcc.c` do more-or-less the same thing in different ways; I think `gcc.c` is the newer, and simpler. Share code if possible.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.12.1 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Driver |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Share code between C wrappers","status":"New","operating_system":"","component":"Driver","related":[],"milestone":"6.12 branch","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"igloo"},"version":"6.12.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"`driver/ghci/ghci.c` and `driver/gcc/gcc.c` do more-or-less the same thing in different ways; I think `gcc.c` is the newer, and simpler. Share code if possible.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchIan Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3853make tags work in the new build system2019-07-07T19:01:51ZIan Lynagh <igloo@earth.li>make tags work in the new build systemMake tags work in the new build system.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.12.1 |
| Type | ...Make tags work in the new build system.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.12.1 |
| Type | Task |
| 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 tags work in the new build system","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"6.12 branch","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"igloo"},"version":"6.12.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"Make tags work in the new build system.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchIan Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3772Methods not inlined2019-07-07T19:02:14Zrl@cse.unsw.edu.auMethods not inlinedThis affects both 6.12 and the HEAD (albeit differently) but works fine with 6.10. It also works if everything is in one module. We are interested in the function `U.foo`; in particular, we want the call to `deepSeq` (resulting from inli...This affects both 6.12 and the HEAD (albeit differently) but works fine with 6.10. It also works if everything is in one module. We are interested in the function `U.foo`; in particular, we want the call to `deepSeq` (resulting from inlining `T.apply`) to be inlined. This is what we get with 6.10 (compiling with `-O2`):
```
go_riA :: [GHC.Types.Double] -> ()
go_riA =
\ (ds_agP :: [GHC.Types.Double]) ->
case ds_agP of wild_agQ {
[] -> GHC.Unit.();
: y_agU ys_agV ->
case y_agU of tpl2_ah1 { GHC.Types.D# ipv_ah3 -> go_riA ys_agV }
}
U.foo :: GHC.Types.Int -> ()
U.foo =
\ (n_afR :: GHC.Types.Int) ->
case n_afR of w_Xhn { GHC.Types.I# ww_ahi ->
go_riA (T.$wgen @ GHC.Types.Double T.$f2 ww_ahi)
}
```
Everything has been nicely inlined. With 6.12, we get this:
```
U.foo [NEVER Nothing] :: GHC.Types.Int -> ()
U.foo =
\ (n_adD :: GHC.Types.Int) ->
case n_adD of _ { GHC.Types.I# ww_afv ->
let {
eta_sgc :: [GHC.Types.Double]
eta_sgc = T.$wgen @ GHC.Types.Double T.$fCDouble ww_afv } in
__inline_me (GHC.Base.foldr
@ GHC.Types.Double @ () (T.$fCDouble1 @ ()) GHC.Unit.() eta_sgc)
}
```
The `deepSeq` call has been inlined but hasn't been optimised, I guess because GHC retained the `__inline_me` for some reason. Things are even worse with the HEAD:
```
U.foo :: GHC.Types.Int -> ()
U.foo =
\ (n_aaO :: GHC.Types.Int) ->
case n_aaO of _ { GHC.Types.I# ww_abR ->
T.$fC[]1
@ GHC.Types.Double
T.$fCDouble
@ ()
(T.$w$cgen @ GHC.Types.Double T.$fCDouble ww_abR)
GHC.Unit.()
}
```
Here, `deepSeq` hasn't even been inlined. But let's add a dummy method to `DeepSeq`:
```
class DeepSeq a where
deepSeq :: a -> b -> b
dummy :: a
dummy = undefined
```
Now, the HEAD actually inlines the call:
```
go_rcM :: [GHC.Types.Double] -> ()
go_rcM =
\ (ds_acl :: [GHC.Types.Double]) ->
case ds_acl of _ {
[] -> GHC.Unit.();
: y_acq ys_acr ->
case y_acq of _ { GHC.Types.D# _ -> go_rcM ys_acr }
}
U.foo :: GHC.Types.Int -> ()
U.foo =
\ (n_aaQ :: GHC.Types.Int) ->
case n_aaQ of _ { GHC.Types.I# ww_abI ->
go_rcM (T.$w$cgen @ GHC.Types.Double T.$fCDouble ww_abI)
}
```
Unfortunately, 6.12 still doesn't.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.12.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":"Methods not inlined","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This affects both 6.12 and the HEAD (albeit differently) but works fine with 6.10. It also works if everything is in one module. We are interested in the function `U.foo`; in particular, we want the call to `deepSeq` (resulting from inlining `T.apply`) to be inlined. This is what we get with 6.10 (compiling with `-O2`):\r\n{{{\r\ngo_riA :: [GHC.Types.Double] -> ()\r\ngo_riA =\r\n \\ (ds_agP :: [GHC.Types.Double]) ->\r\n case ds_agP of wild_agQ {\r\n [] -> GHC.Unit.();\r\n : y_agU ys_agV ->\r\n case y_agU of tpl2_ah1 { GHC.Types.D# ipv_ah3 -> go_riA ys_agV }\r\n }\r\n\r\nU.foo :: GHC.Types.Int -> ()\r\nU.foo =\r\n \\ (n_afR :: GHC.Types.Int) ->\r\n case n_afR of w_Xhn { GHC.Types.I# ww_ahi ->\r\n go_riA (T.$wgen @ GHC.Types.Double T.$f2 ww_ahi)\r\n }\r\n}}}\r\nEverything has been nicely inlined. With 6.12, we get this:\r\n{{{\r\nU.foo [NEVER Nothing] :: GHC.Types.Int -> ()\r\nU.foo =\r\n \\ (n_adD :: GHC.Types.Int) ->\r\n case n_adD of _ { GHC.Types.I# ww_afv ->\r\n let {\r\n eta_sgc :: [GHC.Types.Double]\r\n eta_sgc = T.$wgen @ GHC.Types.Double T.$fCDouble ww_afv } in\r\n __inline_me (GHC.Base.foldr\r\n @ GHC.Types.Double @ () (T.$fCDouble1 @ ()) GHC.Unit.() eta_sgc)\r\n }\r\n}}}\r\nThe `deepSeq` call has been inlined but hasn't been optimised, I guess because GHC retained the `__inline_me` for some reason. Things are even worse with the HEAD:\r\n{{{\r\nU.foo :: GHC.Types.Int -> ()\r\nU.foo =\r\n \\ (n_aaO :: GHC.Types.Int) ->\r\n case n_aaO of _ { GHC.Types.I# ww_abR ->\r\n T.$fC[]1\r\n @ GHC.Types.Double\r\n T.$fCDouble\r\n @ ()\r\n (T.$w$cgen @ GHC.Types.Double T.$fCDouble ww_abR)\r\n GHC.Unit.()\r\n }\r\n}}}\r\nHere, `deepSeq` hasn't even been inlined. But let's add a dummy method to `DeepSeq`:\r\n{{{\r\nclass DeepSeq a where\r\n deepSeq :: a -> b -> b\r\n\r\n dummy :: a\r\n dummy = undefined\r\n}}}\r\nNow, the HEAD actually inlines the call:\r\n{{{\r\ngo_rcM :: [GHC.Types.Double] -> ()\r\ngo_rcM =\r\n \\ (ds_acl :: [GHC.Types.Double]) ->\r\n case ds_acl of _ {\r\n [] -> GHC.Unit.();\r\n : y_acq ys_acr ->\r\n case y_acq of _ { GHC.Types.D# _ -> go_rcM ys_acr }\r\n }\r\n\r\nU.foo :: GHC.Types.Int -> ()\r\nU.foo =\r\n \\ (n_aaQ :: GHC.Types.Int) ->\r\n case n_aaQ of _ { GHC.Types.I# ww_abI ->\r\n go_rcM (T.$w$cgen @ GHC.Types.Double T.$fCDouble ww_abI)\r\n }\r\n}}}\r\nUnfortunately, 6.12 still doesn't.","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/3664Ghc eats tremendous heaps of RAM in -prof build (highlighting-kate)2019-07-07T19:02:53ZSergei TrofimovichGhc eats tremendous heaps of RAM in -prof build (highlighting-kate)Tried to build **highlighting-kate-0.2.5** from hackage with ghc-6.12rc1
and could not wait build result. Ghc ate 2.5BG of ram in 6 minutes, then I
stopped it as machine swapped horribly.
```
$ ghc --info
[("Project name","The Glorious...Tried to build **highlighting-kate-0.2.5** from hackage with ghc-6.12rc1
and could not wait build result. Ghc ate 2.5BG of ram in 6 minutes, then I
stopped it as machine swapped horribly.
```
$ ghc --info
[("Project name","The Glorious Glasgow Haskell Compilation System")
,("Project version","6.12.0.20091010")
,("Booter version","6.10.4")
,("Stage","2")
,("Have interpreter","YES")
,("Object splitting","YES")
,("Have native code generator","YES")
,("Support SMP","YES")
,("Unregisterised","NO")
,("Tables next to code","YES")
,("Win32 DLLs","")
,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn thr_debug_dyn")
,("Leading underscore","NO")
,("Debug on","False")
,("LibDir","/usr/lib64/ghc-6.12.0.20091010")
```
```
* Using cabal-1.8.0.
[1 of 1] Compiling Main ( /tmp/paludis/dev-haskell-highlighting-kate-0.2.5/work/highlighting-kate-0.2.5/Setup.lhs, /tmp/paludis/dev-haskell-highlighting-kate-0.2.5/work/highlighting-kate-0.2.5/Setup.o )
Linking setup ...
Configuring highlighting-kate-0.2.5...
Flags chosen: executable=True, splitbase=True
Dependency base >=3 && <5: using base-4.2.0.0
Dependency containers -any: using containers-0.3.0.0
Dependency filepath -any: using filepath-1.1.0.3
Dependency parsec <3: using parsec-2.1.0.1
Dependency pcre-light -any: using pcre-light-0.3.1
Dependency xhtml -any: using xhtml-3000.2.0.1
Using Cabal-1.8.0 compiled by ghc-6.12
Using compiler: ghc-6.12.0.20091010
```
1. ..
```
/usr/bin/gcc /tmp/paludis/dev-haskell-highlighting-kate-0.2.5/temp/14064.c -o /tmp/paludis/dev-haskell-highlighting-kate-0.2.5/temp/14064 -D__GLASGOW_HASKELL__=612 -I. -O0 -O0 -I/usr/lib64/ghc-6.12.0.20091010/bytestring-0.9.1.5/include -I/usr/lib64/ghc-6.12.0.20091010/base-4.2.0.0/include -I/usr/lib64/ghc-6.12.0.20091010/include -I/usr/lib64/ghc-6.12.0.20091010/include -L/usr/lib64/xhtml-3000.2.0.1/ghc-6.12.0.20091010 -L/usr/lib64/pcre-light-0.3.1/ghc-6.12.0.20091010 -L/usr/lib64/parsec-2.1.0.1/ghc-6.12.0.20091010 -L/usr/lib64/ghc-6.12.0.20091010/filepath-1.1.0.3 -L/usr/lib64/ghc-6.12.0.20091010/containers-0.3.0.0 -L/usr/lib64/ghc-6.12.0.20091010/bytestring-0.9.1.5 -L/usr/lib64/ghc-6.12.0.20091010/array-0.3.0.0 -L/usr/lib64/ghc-6.12.0.20091010/base-4.2.0.0 -L/usr/lib64/ghc-6.12.0.20091010/integer-gmp-0.2.0.0 -L/usr/lib64/ghc-6.12.0.20091010/ghc-prim-0.2.0.0 -L/usr/lib64/ghc-6.12.0.20091010 -L/usr/lib64/ghc-6.12.0.20091010
Preprocessing library highlighting-kate-0.2.5...
Preprocessing executables for highlighting-kate-0.2.5...
Building highlighting-kate-0.2.5...
```
1. ..
```
[41 of 61] Compiling Text.Highlighting.Kate.Syntax.Php ( Text/Highlighting/Kate/Syntax/Php.hs, dist/build/Text/Highlighting/Kate/Syntax/Php.p_o )
Ctrl+C
VIRT: 2.5G RAM, RSS 1.2G RAM, swap activity is large.
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.12.1 RC1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Ghc eats tremendous heaps of RAM in -prof build (highlighting-kate)","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.1 RC1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Tried to build '''highlighting-kate-0.2.5''' from hackage with ghc-6.12rc1\r\nand could not wait build result. Ghc ate 2.5BG of ram in 6 minutes, then I\r\nstopped it as machine swapped horribly.\r\n\r\n{{{\r\n$ ghc --info\r\n [(\"Project name\",\"The Glorious Glasgow Haskell Compilation System\")\r\n ,(\"Project version\",\"6.12.0.20091010\")\r\n ,(\"Booter version\",\"6.10.4\")\r\n ,(\"Stage\",\"2\")\r\n ,(\"Have interpreter\",\"YES\")\r\n ,(\"Object splitting\",\"YES\")\r\n ,(\"Have native code generator\",\"YES\")\r\n ,(\"Support SMP\",\"YES\")\r\n ,(\"Unregisterised\",\"NO\")\r\n ,(\"Tables next to code\",\"YES\")\r\n ,(\"Win32 DLLs\",\"\")\r\n ,(\"RTS ways\",\"l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn thr_debug_dyn\")\r\n ,(\"Leading underscore\",\"NO\")\r\n ,(\"Debug on\",\"False\")\r\n ,(\"LibDir\",\"/usr/lib64/ghc-6.12.0.20091010\")\r\n}}}\r\n\r\n{{{\r\n * Using cabal-1.8.0.\r\n[1 of 1] Compiling Main ( /tmp/paludis/dev-haskell-highlighting-kate-0.2.5/work/highlighting-kate-0.2.5/Setup.lhs, /tmp/paludis/dev-haskell-highlighting-kate-0.2.5/work/highlighting-kate-0.2.5/Setup.o )\r\nLinking setup ...\r\nConfiguring highlighting-kate-0.2.5...\r\nFlags chosen: executable=True, splitbase=True\r\nDependency base >=3 && <5: using base-4.2.0.0\r\nDependency containers -any: using containers-0.3.0.0\r\nDependency filepath -any: using filepath-1.1.0.3\r\nDependency parsec <3: using parsec-2.1.0.1\r\nDependency pcre-light -any: using pcre-light-0.3.1\r\nDependency xhtml -any: using xhtml-3000.2.0.1\r\nUsing Cabal-1.8.0 compiled by ghc-6.12\r\nUsing compiler: ghc-6.12.0.20091010\r\n}}}\r\n...\r\n{{{\r\n/usr/bin/gcc /tmp/paludis/dev-haskell-highlighting-kate-0.2.5/temp/14064.c -o /tmp/paludis/dev-haskell-highlighting-kate-0.2.5/temp/14064 -D__GLASGOW_HASKELL__=612 -I. -O0 -O0 -I/usr/lib64/ghc-6.12.0.20091010/bytestring-0.9.1.5/include -I/usr/lib64/ghc-6.12.0.20091010/base-4.2.0.0/include -I/usr/lib64/ghc-6.12.0.20091010/include -I/usr/lib64/ghc-6.12.0.20091010/include -L/usr/lib64/xhtml-3000.2.0.1/ghc-6.12.0.20091010 -L/usr/lib64/pcre-light-0.3.1/ghc-6.12.0.20091010 -L/usr/lib64/parsec-2.1.0.1/ghc-6.12.0.20091010 -L/usr/lib64/ghc-6.12.0.20091010/filepath-1.1.0.3 -L/usr/lib64/ghc-6.12.0.20091010/containers-0.3.0.0 -L/usr/lib64/ghc-6.12.0.20091010/bytestring-0.9.1.5 -L/usr/lib64/ghc-6.12.0.20091010/array-0.3.0.0 -L/usr/lib64/ghc-6.12.0.20091010/base-4.2.0.0 -L/usr/lib64/ghc-6.12.0.20091010/integer-gmp-0.2.0.0 -L/usr/lib64/ghc-6.12.0.20091010/ghc-prim-0.2.0.0 -L/usr/lib64/ghc-6.12.0.20091010 -L/usr/lib64/ghc-6.12.0.20091010\r\nPreprocessing library highlighting-kate-0.2.5...\r\nPreprocessing executables for highlighting-kate-0.2.5...\r\nBuilding highlighting-kate-0.2.5...\r\n}}}\r\n...\r\n{{{\r\n[41 of 61] Compiling Text.Highlighting.Kate.Syntax.Php ( Text/Highlighting/Kate/Syntax/Php.hs, dist/build/Text/Highlighting/Kate/Syntax/Php.p_o )\r\n \r\nCtrl+C\r\nVIRT: 2.5G RAM, RSS 1.2G RAM, swap activity is large.\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchIan Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3641^L Does Not Work Anymore in Interactive Mode for 6.10.x?2019-07-07T19:03:00ZAviator^L Does Not Work Anymore in Interactive Mode for 6.10.x?I use Ctrl+L a lot to clear the terminal. The clear screen feature is incorporated in various Unix shells, also programming language interpreters like Python. This worked in 6.8.x as I can remember, but not in 6.10.x.
I don't know if so...I use Ctrl+L a lot to clear the terminal. The clear screen feature is incorporated in various Unix shells, also programming language interpreters like Python. This worked in 6.8.x as I can remember, but not in 6.10.x.
I don't know if someone has posted a similar bug.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"^L Does Not Work Anymore in Interactive Mode for 6.10.x?","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I use Ctrl+L a lot to clear the terminal. The clear screen feature is incorporated in various Unix shells, also programming language interpreters like Python. This worked in 6.8.x as I can remember, but not in 6.10.x.\r\n\r\nI don't know if someone has posted a similar bug.","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchjudahjudahhttps://gitlab.haskell.org/ghc/ghc/-/issues/3540Parser accepts malformed types with implicit parameters2019-07-07T19:03:25ZbenlParser accepts malformed types with implicit parametersThe parser in GHC 6.11 currently accepts this:
```
thing :: (?dude :: Int) -> Int
thing = undefined
```
Where the type should really be written with =\> like
```
thing :: (?dude :: Int) => Int
thing = undefined
```
Running hlint on t...The parser in GHC 6.11 currently accepts this:
```
thing :: (?dude :: Int) -> Int
thing = undefined
```
Where the type should really be written with =\> like
```
thing :: (?dude :: Int) => Int
thing = undefined
```
Running hlint on the malformed-but-accepted-by-GHC version crashes haskell-src-exts:
```
benl@humboldt:~$ cat tmp/Main.hs
main = undefined
thing :: (?dude :: Int) -> Int
thing = undefined
benl@humboldt:~$ hlint tmp/Main.hs
hlint: src/Language/Haskell/Exts/ParseUtils.hs:(841,18)-(863,53): Non-exhaustive patterns in case
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 6.11 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Parser) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Parser accepts malformed types with implicit parameters","status":"New","operating_system":"","component":"Compiler (Parser)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"\r\nThe parser in GHC 6.11 currently accepts this:\r\n{{{\r\nthing :: (?dude :: Int) -> Int\r\nthing = undefined\r\n}}}\r\n\r\nWhere the type should really be written with => like\r\n{{{\r\nthing :: (?dude :: Int) => Int\r\nthing = undefined\r\n}}}\r\n\r\nRunning hlint on the malformed-but-accepted-by-GHC version crashes haskell-src-exts:\r\n{{{\r\nbenl@humboldt:~$ cat tmp/Main.hs \r\nmain = undefined\r\n\r\nthing :: (?dude :: Int) -> Int\r\nthing = undefined\r\n\r\nbenl@humboldt:~$ hlint tmp/Main.hs \r\nhlint: src/Language/Haskell/Exts/ParseUtils.hs:(841,18)-(863,53): Non-exhaustive patterns in case\r\n}}}\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchIan Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3331control-monad-queue performance regression2019-07-07T19:04:23ZLeon P Smithleon.p.smith@gmail.comcontrol-monad-queue performance regression```
$ cabal unpack control-monad-queue
$ cd control-monad-queue-0.0.9.1/tests
$ ghc --make -O2 Time.hs -i..
$ ./Time allison 34 20
$ ./Time corec1 34 20
$ ./Time corec2 34 20
```
Runs anywhere from 16-32% slower on GHC 6.10.3 than GHC...```
$ cabal unpack control-monad-queue
$ cd control-monad-queue-0.0.9.1/tests
$ ghc --make -O2 Time.hs -i..
$ ./Time allison 34 20
$ ./Time corec1 34 20
$ ./Time corec2 34 20
```
Runs anywhere from 16-32% slower on GHC 6.10.3 than GHC 6.8.3, and allocates significantly more memory.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.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":"control-monad-queue performance regression","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\n$ cabal unpack control-monad-queue\r\n$ cd control-monad-queue-0.0.9.1/tests\r\n$ ghc --make -O2 Time.hs -i..\r\n$ ./Time allison 34 20\r\n$ ./Time corec1 34 20\r\n$ ./Time corec2 34 20\r\n}}}\r\n\r\nRuns anywhere from 16-32% slower on GHC 6.10.3 than GHC 6.8.3, and allocates significantly more memory. ","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/3273memory leak due to optimisation2020-11-17T17:20:15Zsebfmemory leak due to optimisationShort summary:
The attached programs use lots of space when compiled with -O and run in constant space without -O.
condensed.hs runs in constant space with -O too, if you remove any occurrence of 'id'.
original.hs uses a lot of space wi...Short summary:
The attached programs use lots of space when compiled with -O and run in constant space without -O.
condensed.hs runs in constant space with -O too, if you remove any occurrence of 'id'.
original.hs uses a lot of space without -O too, if an alternative definition of 'iterDepth' is used (see comment there).
I could reproduce this behaviour with ghc-6.8.2 under Linux as well as ghc-6.10.1 and ghc-6.11.20090331 under Mac OS X 10.5.7.
Full description:
This ticket has an attached tar file with two source files -- original.hs and condensed.hs -- that can be compiled with and without -O to reproduce the bug:
```
$ ghc -fforce-recomp --make original
[1 of 1] Compiling Main ( original.hs, original.o )
Linking original ...
$ ./original
^C <constant space usage>
$ ghc -v -dcore-lint -O -fforce-recomp --make original
Glasgow Haskell Compiler, Version 6.10.1, for Haskell 98, stage 2 booted by GHC version 6.8.3
Using package config file: /Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.1/./package.conf
Using package config file: /Users/sebf/.ghc/i386-darwin-6.10.1/package.conf
hiding package HTTP-3001.1.3 to avoid conflict with later version HTTP-3001.1.4
hiding package haddock-2.3.0 to avoid conflict with later version haddock-2.4.1
hiding package base-3.0.3.0 to avoid conflict with later version base-4.0.0.0
hiding package old-time-1.0.0.1 to avoid conflict with later version old-time-1.0.0.2
hiding package filepath-1.1.0.1 to avoid conflict with later version filepath-1.1.0.2
hiding package process-1.0.1.0 to avoid conflict with later version process-1.0.1.1
hiding package Cabal-1.6.0.1 to avoid conflict with later version Cabal-1.6.0.2
hiding package regex-base-0.72.0.2 to avoid conflict with later version regex-base-0.93.1
hiding package regex-posix-0.72.0.3 to avoid conflict with later version regex-posix-0.93.2
hiding package regex-compat-0.71.0.1 to avoid conflict with later version regex-compat-0.92
hiding package network-2.2.0.1 to avoid conflict with later version network-2.2.1.2
hiding package QuickCheck-1.2.0.0 to avoid conflict with later version QuickCheck-2.1.0.1
hiding package time-1.1.2.2 to avoid conflict with later version time-1.1.2.3
hiding package zlib-0.4.0.4 to avoid conflict with later version zlib-0.5.0.0
hiding package HTTP-3001.1.4 to avoid conflict with later version HTTP-3001.1.5
hiding package regex-posix-0.93.2 to avoid conflict with later version regex-posix-0.94.1
hiding package utf8-string-0.3.3 to avoid conflict with later version utf8-string-0.3.4
hiding package binary-0.4.3.1 to avoid conflict with later version binary-0.4.4
hiding package zip-archive-0.1.1.1 to avoid conflict with later version zip-archive-0.1.1.3
hiding package binary-0.4.4 to avoid conflict with later version binary-0.5
hiding package haddock-2.4.1 to avoid conflict with later version haddock-2.4.2
hiding package HTTP-3001.1.5 to avoid conflict with later version HTTP-4000.0.0
hiding package hscolour-1.10.1 to avoid conflict with later version hscolour-1.11
hiding package HTTP-4000.0.0 to avoid conflict with later version HTTP-4000.0.1
hiding package haskell-src-exts-0.4.6 to avoid conflict with later version haskell-src-exts-0.4.8
hiding package HTTP-4000.0.1 to avoid conflict with later version HTTP-4000.0.4
hiding package digest-0.0.0.1 to avoid conflict with later version digest-0.0.0.2
hiding package level-monad-0.2.1 to avoid conflict with later version level-monad-0.3
hiding package HTTP-4000.0.4 to avoid conflict with later version HTTP-4000.0.7
hiding package digest-0.0.0.2 to avoid conflict with later version digest-0.0.0.4
hiding package terminfo-0.2.2.1 to avoid conflict with later version terminfo-0.3.0.2
hiding package stream-monad-0.1 to avoid conflict with later version stream-monad-0.1.1.0
hiding package tree-monad-0.1 to avoid conflict with later version tree-monad-0.1.1
hiding package parallel-tree-search-0.2.1 to avoid conflict with later version parallel-tree-search-0.4
hiding package explicit-sharing-0.2 to avoid conflict with later version explicit-sharing-0.3.1.1
hiding package tree-monad-0.1.1 to avoid conflict with later version tree-monad-0.2
hiding package tree-monad-0.2 to avoid conflict with later version tree-monad-0.2.1
hiding package parallel-tree-search-0.4 to avoid conflict with later version parallel-tree-search-0.4.1
hiding package level-monad-0.3 to avoid conflict with later version level-monad-0.3.1
hiding package explicit-sharing-0.3.1.1 to avoid conflict with later version explicit-sharing-0.3.1.2
hiding package explicit-sharing-0.3.1.2 to avoid conflict with later version explicit-sharing-0.3.1.3
hiding package explicit-sharing-0.3.1.3 to avoid conflict with later version explicit-sharing-0.4.0
hiding package explicit-sharing-0.4.0 to avoid conflict with later version explicit-sharing-0.5.0
wired-in package ghc-prim mapped to ghc-prim-0.1.0.0
wired-in package integer mapped to integer-0.1.0.0
wired-in package base mapped to base-4.0.0.0
wired-in package rts mapped to rts-1.0
wired-in package haskell98 mapped to haskell98-1.0.1.0
wired-in package syb mapped to syb-0.1.0.0
wired-in package template-haskell mapped to template-haskell-2.3.0.0
wired-in package dph-seq mapped to dph-seq-0.3
wired-in package dph-par mapped to dph-par-0.3
Hsc static flags: -static
*** Chasing dependencies:
Chasing modules from: *original.hs
Stable obj: [Main]
Stable BCO: []
Ready for upsweep
[NONREC
ModSummary {
ms_hs_date = Thu Jun 4 13:23:20 CEST 2009
ms_mod = main:Main,
ms_imps = [Control.Monad.Cont]
ms_srcimps = []
}]
compile: input file original.hs
Created temporary directory: /var/folders/uZ/uZjvUnuPHNmMwDWLlrsGT++++TI/-Tmp-//ghc13029_0
*** Checking old interface for main:Main:
[1 of 1] Compiling Main ( original.hs, original.o )
*** Parser:
*** Renamer/typechecker:
*** Desugar:
Result size = 753
*** Core Linted result of Desugar:
*** Simplify:
Result size = 290
*** Core Linted result of Simplifier phase gentle, iteration 1 out of 4:
Result size = 280
*** Core Linted result of Simplifier phase gentle, iteration 2 out of 4:
Result size = 280
*** Core Linted result of Simplify phase gentle done:
*** Specialise:
Result size = 331
*** Core Linted result of Specialise:
*** Float out (not lambdas, not constants):
Result size = 351
*** Core Linted result of Float out (not lambdas, not constants):
*** Float inwards:
Result size = 351
*** Core Linted result of Float inwards:
*** Simplify:
Result size = 587
*** Core Linted result of Simplifier phase 2 [main], iteration 1 out of 4:
Result size = 390
*** Core Linted result of Simplifier phase 2 [main], iteration 2 out of 4:
Result size = 304
*** Core Linted result of Simplify phase 2 [main] done:
*** Simplify:
Result size = 287
*** Core Linted result of Simplifier phase 1 [main], iteration 1 out of 4:
Result size = 287
*** Core Linted result of Simplify phase 1 [main] done:
*** Simplify:
Result size = 330
*** Core Linted result of Simplifier phase 0 [main], iteration 1 out of 4:
Result size = 310
*** Core Linted result of Simplifier phase 0 [main], iteration 2 out of 4:
Result size = 304
*** Core Linted result of Simplifier phase 0 [main], iteration 3 out of 4:
Result size = 304
*** Core Linted result of Simplify phase 0 [main] done:
*** Demand analysis:
Result size = 304
*** Core Linted result of Demand analysis:
*** Worker Wrapper binds:
Result size = 330
*** Core Linted result of Worker Wrapper binds:
*** GlomBinds:
*** Simplify:
Result size = 345
*** Core Linted result of Simplifier phase 0 [post-worker-wrapper], iteration 1 out of 4:
Result size = 345
*** Core Linted result of Simplify phase 0 [post-worker-wrapper] done:
*** Float out (not lambdas, constants):
Result size = 353
*** Core Linted result of Float out (not lambdas, constants):
*** Common sub-expression:
Result size = 352
*** Core Linted result of Common sub-expression:
*** Float inwards:
Result size = 352
*** Core Linted result of Float inwards:
*** Simplify:
Result size = 353
*** Core Linted result of Simplifier phase 0 [final], iteration 1 out of 4:
Result size = 353
*** Core Linted result of Simplify phase 0 [final] done:
*** Tidy Core:
Result size = 353
*** Core Linted result of Tidy Core:
writeBinIface: 49 Names
writeBinIface: 98 dict entries
*** CorePrep:
Result size = 430
*** Core Linted result of CorePrep:
*** Stg2Stg:
*** CodeGen:
*** CodeOutput:
*** Assembler:
gcc -I. -c /var/folders/uZ/uZjvUnuPHNmMwDWLlrsGT++++TI/-Tmp-//ghc13029_0/ghc13029_0.s -o original.o
*** Deleting temp files:
Deleting: /var/folders/uZ/uZjvUnuPHNmMwDWLlrsGT++++TI/-Tmp-//ghc13029_0/ghc13029_0.s
Upsweep completely successful.
*** Deleting temp files:
Deleting:
link: linkables are ...
LinkableM (Thu Jun 4 13:55:23 CEST 2009) main:Main
[DotO original.o]
Linking original ...
*** Linker:
gcc -v -o original -DDONT_WANT_WIN32_DLL_SUPPORT original.o -L/Library/Frameworks/GHC.framework
/Versions/610/usr/lib/ghc-6.10.1/mtl-1.1.0.2 -L/Library/Frameworks/GHC.framework/Versions/610/usr
/lib/ghc-6.10.1/base-4.0.0.0 -L/Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.1/
integer-0.1.0.0 -L/Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.1/ghc-prim-0.1.0.0
-L/Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.1 -lHSmtl-1.1.0.2 -lHSbase-4.0.0.0
-lHSinteger-0.1.0.0 -lHSghc-prim-0.1.0.0 -lHSrts -lm -lffi -lgmp -ldl -u _ghczmprim_GHCziTypes_Izh_static_info
-u _ghczmprim_GHCziTypes_Czh_static_info -u _ghczmprim_GHCziTypes_Fzh_static_info
-u _ghczmprim_GHCziTypes_Dzh_static_info -u _base_GHCziPtr_Ptr_static_info -u _base_GHCziWord_Wzh_static_info
-u _base_GHCziInt_I8zh_static_info -u _base_GHCziInt_I16zh_static_info -u _base_GHCziInt_I32zh_static_info
-u _base_GHCziInt_I64zh_static_info -u _base_GHCziWord_W8zh_static_info -u _base_GHCziWord_W16zh_static_info
-u _base_GHCziWord_W32zh_static_info -u _base_GHCziWord_W64zh_static_info -u _base_GHCziStable_StablePtr_static_info
-u _ghczmprim_GHCziTypes_Izh_con_info -u _ghczmprim_GHCziTypes_Czh_con_info -u _ghczmprim_GHCziTypes_Fzh_con_info
-u _ghczmprim_GHCziTypes_Dzh_con_info -u _base_GHCziPtr_Ptr_con_info -u _base_GHCziPtr_FunPtr_con_info
-u _base_GHCziStable_StablePtr_con_info -u _ghczmprim_GHCziBool_False_closure -u _ghczmprim_GHCziBool_True_closure
-u _base_GHCziPack_unpackCString_closure -u _base_GHCziIOBase_stackOverflow_closure
-u _base_GHCziIOBase_heapOverflow_closure -u _base_ControlziExceptionziBase_nonTermination_closure
-u _base_GHCziIOBase_blockedOnDeadMVar_closure -u _base_GHCziIOBase_blockedIndefinitely_closure
-u _base_ControlziExceptionziBase_nestedAtomically_closure -u _base_GHCziWeak_runFinalizzerBatch_closure
-u _base_GHCziTopHandler_runIO_closure -u _base_GHCziTopHandler_runNonIO_closure
-u _base_GHCziConc_ensureIOManagerIsRunning_closure -Wl,-search_paths_first
Using built-in specs.
Target: i686-apple-darwin9
Configured with: /var/tmp/gcc/gcc-5488~2/src/configure --disable-checking -enable-werror --prefix=/usr
--mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/
--with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib --build=i686-apple-darwin9 --with-arch=apple
--with-tune=generic --host=i686-apple-darwin9 --target=i686-apple-darwin9
Thread model: posix
gcc version 4.0.1 (Apple Inc. build 5488)
/usr/libexec/gcc/i686-apple-darwin9/4.0.1/collect2 -dynamic -arch i386 -macosx_version_min 10.5.7
-weak_reference_mismatches non-weak -u _ghczmprim_GHCziTypes_Izh_static_info
-u _ghczmprim_GHCziTypes_Czh_static_info -u _ghczmprim_GHCziTypes_Fzh_static_info
-u _ghczmprim_GHCziTypes_Dzh_static_info -u _base_GHCziPtr_Ptr_static_info -u _base_GHCziWord_Wzh_static_info
-u _base_GHCziInt_I8zh_static_info -u _base_GHCziInt_I16zh_static_info -u _base_GHCziInt_I32zh_static_info
-u _base_GHCziInt_I64zh_static_info -u _base_GHCziWord_W8zh_static_info -u _base_GHCziWord_W16zh_static_info
-u _base_GHCziWord_W32zh_static_info -u _base_GHCziWord_W64zh_static_info -u _base_GHCziStable_StablePtr_static_info
-u _ghczmprim_GHCziTypes_Izh_con_info -u _ghczmprim_GHCziTypes_Czh_con_info -u _ghczmprim_GHCziTypes_Fzh_con_info
-u _ghczmprim_GHCziTypes_Dzh_con_info -u _base_GHCziPtr_Ptr_con_info -u _base_GHCziPtr_FunPtr_con_info
-u _base_GHCziStable_StablePtr_con_info -u _ghczmprim_GHCziBool_False_closure -u _ghczmprim_GHCziBool_True_closure
-u _base_GHCziPack_unpackCString_closure -u _base_GHCziIOBase_stackOverflow_closure
-u _base_GHCziIOBase_heapOverflow_closure -u _base_ControlziExceptionziBase_nonTermination_closure
-u _base_GHCziIOBase_blockedOnDeadMVar_closure -u _base_GHCziIOBase_blockedIndefinitely_closure
-u _base_ControlziExceptionziBase_nestedAtomically_closure -u _base_GHCziWeak_runFinalizzerBatch_closure
-u _base_GHCziTopHandler_runIO_closure -u _base_GHCziTopHandler_runNonIO_closure
-u _base_GHCziConc_ensureIOManagerIsRunning_closure -o original -lcrt1.10.5.o -L/Library/Frameworks/GHC.framework/
Versions/610/usr/lib/ghc-6.10.1/mtl-1.1.0.2 -L/Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.1/base-4.0.0.0
-L/Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.1/integer-0.1.0.0 -L/Library/Frameworks/GHC.framework
/Versions/610/usr/lib/ghc-6.10.1/ghc-prim-0.1.0.0 -L/Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.1
-L/usr/lib/i686-apple-darwin9/4.0.1 -L/usr/lib/gcc/i686-apple-darwin9/4.0.1 -L/usr/lib/gcc/i686-apple-darwin9/4.0.1
-L/usr/lib/gcc/i686-apple-darwin9/4.0.1/../../../i686-apple-darwin9/4.0.1 -L/usr/lib/gcc/i686-apple-darwin9/4.0.1
/../../.. original.o -lHSmtl-1.1.0.2 -lHSbase-4.0.0.0 -lHSinteger-0.1.0.0 -lHSghc-prim-0.1.0.0 -lHSrts -lm
-lffi -lgmp -ldl -search_paths_first -lgcc_s.10.5 -lgcc -lSystem
link: done
*** Deleting temp files:
Deleting:
*** Deleting temp dirs:
Deleting: /var/folders/uZ/uZjvUnuPHNmMwDWLlrsGT++++TI/-Tmp-//ghc13029_0
$ ./original
^C <increasing space usage>
$ ghc -fforce-recomp --make condensed
[1 of 1] Compiling Main ( condensed.hs, condensed.o )
Linking condensed ...
$ ./condensed
^C <constant space>
13:50 memleak$ ghc -O -fforce-recomp --make condensed
[1 of 1] Compiling Main ( condensed.hs, condensed.o )
Linking condensed ...
$ ./condensed
^C <increasing space usage>
```
I have checked with ghc-6.8.2 on "Linux 2.6.27-11-generic 1 SMP Wed Apr 1 20:53:41 UTC 2009 x86_64 GNU/Linux" and with ghc-6.10.1 and 6.11.200903331 on "Darwin 9.7.0 Darwin Kernel Version 9.7.0: Tue Mar 31 22:52:17 PDT 2009; root:xnu-1228.12.14\~1/RELEASE_I386 i386"
Here are some more runs with -fno-full-laziness and/or -fno-cse. Neither switch affects the memory requirements with -O:
```
$ ghc -fno-full-laziness -O -fforce-recomp --make condensed
[1 of 1] Compiling Main ( condensed.hs, condensed.o )
Linking condensed ...
$ ./condensed
^C <increasing memory usage>
$ ghc -fno-cse -O -fforce-recomp --make condensed
[1 of 1] Compiling Main ( condensed.hs, condensed.o )
Linking condensed ...
$ ./condensed
^C <increasing memory usage>
$ ghc -fno-full-laziness -fno-cse -O -fforce-recomp --make condensed
[1 of 1] Compiling Main ( condensed.hs, condensed.o )
Linking condensed ...
$ ./condensed
^C <increasing memory usage>
```
The program original.hs contains an alternative implementation of 'iterDepth' that seems to hint at the problem. I think, the argument of 'runDepthBound' is held in memory for a good reason there.
The program condensed.hs contains four superflous occurrences of 'id' that seem to play together to cause the memory leak. If all of them are present then the program uses lots of space with -O, if either one is missing it runs in constant space. The program always runs in constant space without -O. I think, the space leak is caused by holding the arguments of 'id' in memory. If that is true, however, I don't see why \*all\* occurrences of 'id' are necessary to cause the leak.
I think the original program and all versions of the condensed program should run in constant space with and without -O. It would be nice if the alternative version of the original program would run in constant space too but I see that there is sharing that may prevent this.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | --------------------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | sebf@informatik.uni-kiel.de |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"memory leak due to optimisation","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["sebf@informatik.uni-kiel.de"],"type":"Bug","description":"Short summary:\r\n\r\nThe attached programs use lots of space when compiled with -O and run in constant space without -O.\r\ncondensed.hs runs in constant space with -O too, if you remove any occurrence of 'id'.\r\noriginal.hs uses a lot of space without -O too, if an alternative definition of 'iterDepth' is used (see comment there).\r\n\r\nI could reproduce this behaviour with ghc-6.8.2 under Linux as well as ghc-6.10.1 and ghc-6.11.20090331 under Mac OS X 10.5.7.\r\n\r\nFull description:\r\n\r\nThis ticket has an attached tar file with two source files -- original.hs and condensed.hs -- that can be compiled with and without -O to reproduce the bug:\r\n\r\n{{{\r\n$ ghc -fforce-recomp --make original\r\n[1 of 1] Compiling Main ( original.hs, original.o )\r\nLinking original ...\r\n\r\n$ ./original \r\n^C <constant space usage>\r\n\r\n$ ghc -v -dcore-lint -O -fforce-recomp --make original\r\nGlasgow Haskell Compiler, Version 6.10.1, for Haskell 98, stage 2 booted by GHC version 6.8.3\r\nUsing package config file: /Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.1/./package.conf\r\nUsing package config file: /Users/sebf/.ghc/i386-darwin-6.10.1/package.conf\r\nhiding package HTTP-3001.1.3 to avoid conflict with later version HTTP-3001.1.4\r\nhiding package haddock-2.3.0 to avoid conflict with later version haddock-2.4.1\r\nhiding package base-3.0.3.0 to avoid conflict with later version base-4.0.0.0\r\nhiding package old-time-1.0.0.1 to avoid conflict with later version old-time-1.0.0.2\r\nhiding package filepath-1.1.0.1 to avoid conflict with later version filepath-1.1.0.2\r\nhiding package process-1.0.1.0 to avoid conflict with later version process-1.0.1.1\r\nhiding package Cabal-1.6.0.1 to avoid conflict with later version Cabal-1.6.0.2\r\nhiding package regex-base-0.72.0.2 to avoid conflict with later version regex-base-0.93.1\r\nhiding package regex-posix-0.72.0.3 to avoid conflict with later version regex-posix-0.93.2\r\nhiding package regex-compat-0.71.0.1 to avoid conflict with later version regex-compat-0.92\r\nhiding package network-2.2.0.1 to avoid conflict with later version network-2.2.1.2\r\nhiding package QuickCheck-1.2.0.0 to avoid conflict with later version QuickCheck-2.1.0.1\r\nhiding package time-1.1.2.2 to avoid conflict with later version time-1.1.2.3\r\nhiding package zlib-0.4.0.4 to avoid conflict with later version zlib-0.5.0.0\r\nhiding package HTTP-3001.1.4 to avoid conflict with later version HTTP-3001.1.5\r\nhiding package regex-posix-0.93.2 to avoid conflict with later version regex-posix-0.94.1\r\nhiding package utf8-string-0.3.3 to avoid conflict with later version utf8-string-0.3.4\r\nhiding package binary-0.4.3.1 to avoid conflict with later version binary-0.4.4\r\nhiding package zip-archive-0.1.1.1 to avoid conflict with later version zip-archive-0.1.1.3\r\nhiding package binary-0.4.4 to avoid conflict with later version binary-0.5\r\nhiding package haddock-2.4.1 to avoid conflict with later version haddock-2.4.2\r\nhiding package HTTP-3001.1.5 to avoid conflict with later version HTTP-4000.0.0\r\nhiding package hscolour-1.10.1 to avoid conflict with later version hscolour-1.11\r\nhiding package HTTP-4000.0.0 to avoid conflict with later version HTTP-4000.0.1\r\nhiding package haskell-src-exts-0.4.6 to avoid conflict with later version haskell-src-exts-0.4.8\r\nhiding package HTTP-4000.0.1 to avoid conflict with later version HTTP-4000.0.4\r\nhiding package digest-0.0.0.1 to avoid conflict with later version digest-0.0.0.2\r\nhiding package level-monad-0.2.1 to avoid conflict with later version level-monad-0.3\r\nhiding package HTTP-4000.0.4 to avoid conflict with later version HTTP-4000.0.7\r\nhiding package digest-0.0.0.2 to avoid conflict with later version digest-0.0.0.4\r\nhiding package terminfo-0.2.2.1 to avoid conflict with later version terminfo-0.3.0.2\r\nhiding package stream-monad-0.1 to avoid conflict with later version stream-monad-0.1.1.0\r\nhiding package tree-monad-0.1 to avoid conflict with later version tree-monad-0.1.1\r\nhiding package parallel-tree-search-0.2.1 to avoid conflict with later version parallel-tree-search-0.4\r\nhiding package explicit-sharing-0.2 to avoid conflict with later version explicit-sharing-0.3.1.1\r\nhiding package tree-monad-0.1.1 to avoid conflict with later version tree-monad-0.2\r\nhiding package tree-monad-0.2 to avoid conflict with later version tree-monad-0.2.1\r\nhiding package parallel-tree-search-0.4 to avoid conflict with later version parallel-tree-search-0.4.1\r\nhiding package level-monad-0.3 to avoid conflict with later version level-monad-0.3.1\r\nhiding package explicit-sharing-0.3.1.1 to avoid conflict with later version explicit-sharing-0.3.1.2\r\nhiding package explicit-sharing-0.3.1.2 to avoid conflict with later version explicit-sharing-0.3.1.3\r\nhiding package explicit-sharing-0.3.1.3 to avoid conflict with later version explicit-sharing-0.4.0\r\nhiding package explicit-sharing-0.4.0 to avoid conflict with later version explicit-sharing-0.5.0\r\nwired-in package ghc-prim mapped to ghc-prim-0.1.0.0\r\nwired-in package integer mapped to integer-0.1.0.0\r\nwired-in package base mapped to base-4.0.0.0\r\nwired-in package rts mapped to rts-1.0\r\nwired-in package haskell98 mapped to haskell98-1.0.1.0\r\nwired-in package syb mapped to syb-0.1.0.0\r\nwired-in package template-haskell mapped to template-haskell-2.3.0.0\r\nwired-in package dph-seq mapped to dph-seq-0.3\r\nwired-in package dph-par mapped to dph-par-0.3\r\nHsc static flags: -static\r\n*** Chasing dependencies:\r\nChasing modules from: *original.hs\r\nStable obj: [Main]\r\nStable BCO: []\r\nReady for upsweep\r\n [NONREC\r\n ModSummary {\r\n ms_hs_date = Thu Jun 4 13:23:20 CEST 2009\r\n ms_mod = main:Main,\r\n ms_imps = [Control.Monad.Cont]\r\n ms_srcimps = []\r\n }]\r\ncompile: input file original.hs\r\nCreated temporary directory: /var/folders/uZ/uZjvUnuPHNmMwDWLlrsGT++++TI/-Tmp-//ghc13029_0\r\n*** Checking old interface for main:Main:\r\n[1 of 1] Compiling Main ( original.hs, original.o )\r\n*** Parser:\r\n*** Renamer/typechecker:\r\n*** Desugar:\r\n Result size = 753\r\n*** Core Linted result of Desugar:\r\n*** Simplify:\r\n Result size = 290\r\n*** Core Linted result of Simplifier phase gentle, iteration 1 out of 4:\r\n Result size = 280\r\n*** Core Linted result of Simplifier phase gentle, iteration 2 out of 4:\r\n Result size = 280\r\n*** Core Linted result of Simplify phase gentle done:\r\n*** Specialise:\r\n Result size = 331\r\n*** Core Linted result of Specialise:\r\n*** Float out (not lambdas, not constants):\r\n Result size = 351\r\n*** Core Linted result of Float out (not lambdas, not constants):\r\n*** Float inwards:\r\n Result size = 351\r\n*** Core Linted result of Float inwards:\r\n*** Simplify:\r\n Result size = 587\r\n*** Core Linted result of Simplifier phase 2 [main], iteration 1 out of 4:\r\n Result size = 390\r\n*** Core Linted result of Simplifier phase 2 [main], iteration 2 out of 4:\r\n Result size = 304\r\n*** Core Linted result of Simplify phase 2 [main] done:\r\n*** Simplify:\r\n Result size = 287\r\n*** Core Linted result of Simplifier phase 1 [main], iteration 1 out of 4:\r\n Result size = 287\r\n*** Core Linted result of Simplify phase 1 [main] done:\r\n*** Simplify:\r\n Result size = 330\r\n*** Core Linted result of Simplifier phase 0 [main], iteration 1 out of 4:\r\n Result size = 310\r\n*** Core Linted result of Simplifier phase 0 [main], iteration 2 out of 4:\r\n Result size = 304\r\n*** Core Linted result of Simplifier phase 0 [main], iteration 3 out of 4:\r\n Result size = 304\r\n*** Core Linted result of Simplify phase 0 [main] done:\r\n*** Demand analysis:\r\n Result size = 304\r\n*** Core Linted result of Demand analysis:\r\n*** Worker Wrapper binds:\r\n Result size = 330\r\n*** Core Linted result of Worker Wrapper binds:\r\n*** GlomBinds:\r\n*** Simplify:\r\n Result size = 345\r\n*** Core Linted result of Simplifier phase 0 [post-worker-wrapper], iteration 1 out of 4:\r\n Result size = 345\r\n*** Core Linted result of Simplify phase 0 [post-worker-wrapper] done:\r\n*** Float out (not lambdas, constants):\r\n Result size = 353\r\n*** Core Linted result of Float out (not lambdas, constants):\r\n*** Common sub-expression:\r\n Result size = 352\r\n*** Core Linted result of Common sub-expression:\r\n*** Float inwards:\r\n Result size = 352\r\n*** Core Linted result of Float inwards:\r\n*** Simplify:\r\n Result size = 353\r\n*** Core Linted result of Simplifier phase 0 [final], iteration 1 out of 4:\r\n Result size = 353\r\n*** Core Linted result of Simplify phase 0 [final] done:\r\n*** Tidy Core:\r\n Result size = 353\r\n*** Core Linted result of Tidy Core:\r\nwriteBinIface: 49 Names\r\nwriteBinIface: 98 dict entries\r\n*** CorePrep:\r\n Result size = 430\r\n*** Core Linted result of CorePrep:\r\n*** Stg2Stg:\r\n*** CodeGen:\r\n*** CodeOutput:\r\n*** Assembler:\r\ngcc -I. -c /var/folders/uZ/uZjvUnuPHNmMwDWLlrsGT++++TI/-Tmp-//ghc13029_0/ghc13029_0.s -o original.o\r\n*** Deleting temp files:\r\nDeleting: /var/folders/uZ/uZjvUnuPHNmMwDWLlrsGT++++TI/-Tmp-//ghc13029_0/ghc13029_0.s\r\nUpsweep completely successful.\r\n*** Deleting temp files:\r\nDeleting: \r\nlink: linkables are ...\r\nLinkableM (Thu Jun 4 13:55:23 CEST 2009) main:Main\r\n [DotO original.o]\r\nLinking original ...\r\n*** Linker:\r\ngcc -v -o original -DDONT_WANT_WIN32_DLL_SUPPORT original.o -L/Library/Frameworks/GHC.framework\r\n/Versions/610/usr/lib/ghc-6.10.1/mtl-1.1.0.2 -L/Library/Frameworks/GHC.framework/Versions/610/usr\r\n/lib/ghc-6.10.1/base-4.0.0.0 -L/Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.1/\r\ninteger-0.1.0.0 -L/Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.1/ghc-prim-0.1.0.0\r\n -L/Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.1 -lHSmtl-1.1.0.2 -lHSbase-4.0.0.0\r\n -lHSinteger-0.1.0.0 -lHSghc-prim-0.1.0.0 -lHSrts -lm -lffi -lgmp -ldl -u _ghczmprim_GHCziTypes_Izh_static_info\r\n -u _ghczmprim_GHCziTypes_Czh_static_info -u _ghczmprim_GHCziTypes_Fzh_static_info \r\n-u _ghczmprim_GHCziTypes_Dzh_static_info -u _base_GHCziPtr_Ptr_static_info -u _base_GHCziWord_Wzh_static_info\r\n -u _base_GHCziInt_I8zh_static_info -u _base_GHCziInt_I16zh_static_info -u _base_GHCziInt_I32zh_static_info\r\n -u _base_GHCziInt_I64zh_static_info -u _base_GHCziWord_W8zh_static_info -u _base_GHCziWord_W16zh_static_info\r\n -u _base_GHCziWord_W32zh_static_info -u _base_GHCziWord_W64zh_static_info -u _base_GHCziStable_StablePtr_static_info\r\n -u _ghczmprim_GHCziTypes_Izh_con_info -u _ghczmprim_GHCziTypes_Czh_con_info -u _ghczmprim_GHCziTypes_Fzh_con_info\r\n -u _ghczmprim_GHCziTypes_Dzh_con_info -u _base_GHCziPtr_Ptr_con_info -u _base_GHCziPtr_FunPtr_con_info\r\n -u _base_GHCziStable_StablePtr_con_info -u _ghczmprim_GHCziBool_False_closure -u _ghczmprim_GHCziBool_True_closure\r\n -u _base_GHCziPack_unpackCString_closure -u _base_GHCziIOBase_stackOverflow_closure\r\n -u _base_GHCziIOBase_heapOverflow_closure -u _base_ControlziExceptionziBase_nonTermination_closure\r\n -u _base_GHCziIOBase_blockedOnDeadMVar_closure -u _base_GHCziIOBase_blockedIndefinitely_closure\r\n -u _base_ControlziExceptionziBase_nestedAtomically_closure -u _base_GHCziWeak_runFinalizzerBatch_closure\r\n -u _base_GHCziTopHandler_runIO_closure -u _base_GHCziTopHandler_runNonIO_closure\r\n -u _base_GHCziConc_ensureIOManagerIsRunning_closure -Wl,-search_paths_first\r\nUsing built-in specs.\r\nTarget: i686-apple-darwin9\r\nConfigured with: /var/tmp/gcc/gcc-5488~2/src/configure --disable-checking -enable-werror --prefix=/usr\r\n --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.0/\r\n --with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib --build=i686-apple-darwin9 --with-arch=apple\r\n --with-tune=generic --host=i686-apple-darwin9 --target=i686-apple-darwin9\r\nThread model: posix\r\ngcc version 4.0.1 (Apple Inc. build 5488)\r\n /usr/libexec/gcc/i686-apple-darwin9/4.0.1/collect2 -dynamic -arch i386 -macosx_version_min 10.5.7\r\n -weak_reference_mismatches non-weak -u _ghczmprim_GHCziTypes_Izh_static_info \r\n-u _ghczmprim_GHCziTypes_Czh_static_info -u _ghczmprim_GHCziTypes_Fzh_static_info\r\n -u _ghczmprim_GHCziTypes_Dzh_static_info -u _base_GHCziPtr_Ptr_static_info -u _base_GHCziWord_Wzh_static_info\r\n -u _base_GHCziInt_I8zh_static_info -u _base_GHCziInt_I16zh_static_info -u _base_GHCziInt_I32zh_static_info\r\n -u _base_GHCziInt_I64zh_static_info -u _base_GHCziWord_W8zh_static_info -u _base_GHCziWord_W16zh_static_info\r\n -u _base_GHCziWord_W32zh_static_info -u _base_GHCziWord_W64zh_static_info -u _base_GHCziStable_StablePtr_static_info\r\n -u _ghczmprim_GHCziTypes_Izh_con_info -u _ghczmprim_GHCziTypes_Czh_con_info -u _ghczmprim_GHCziTypes_Fzh_con_info\r\n -u _ghczmprim_GHCziTypes_Dzh_con_info -u _base_GHCziPtr_Ptr_con_info -u _base_GHCziPtr_FunPtr_con_info\r\n -u _base_GHCziStable_StablePtr_con_info -u _ghczmprim_GHCziBool_False_closure -u _ghczmprim_GHCziBool_True_closure\r\n -u _base_GHCziPack_unpackCString_closure -u _base_GHCziIOBase_stackOverflow_closure\r\n -u _base_GHCziIOBase_heapOverflow_closure -u _base_ControlziExceptionziBase_nonTermination_closure\r\n -u _base_GHCziIOBase_blockedOnDeadMVar_closure -u _base_GHCziIOBase_blockedIndefinitely_closure\r\n -u _base_ControlziExceptionziBase_nestedAtomically_closure -u _base_GHCziWeak_runFinalizzerBatch_closure\r\n -u _base_GHCziTopHandler_runIO_closure -u _base_GHCziTopHandler_runNonIO_closure\r\n -u _base_GHCziConc_ensureIOManagerIsRunning_closure -o original -lcrt1.10.5.o -L/Library/Frameworks/GHC.framework/\r\nVersions/610/usr/lib/ghc-6.10.1/mtl-1.1.0.2 -L/Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.1/base-4.0.0.0\r\n -L/Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.1/integer-0.1.0.0 -L/Library/Frameworks/GHC.framework\r\n/Versions/610/usr/lib/ghc-6.10.1/ghc-prim-0.1.0.0 -L/Library/Frameworks/GHC.framework/Versions/610/usr/lib/ghc-6.10.1\r\n -L/usr/lib/i686-apple-darwin9/4.0.1 -L/usr/lib/gcc/i686-apple-darwin9/4.0.1 -L/usr/lib/gcc/i686-apple-darwin9/4.0.1\r\n -L/usr/lib/gcc/i686-apple-darwin9/4.0.1/../../../i686-apple-darwin9/4.0.1 -L/usr/lib/gcc/i686-apple-darwin9/4.0.1\r\n/../../.. original.o -lHSmtl-1.1.0.2 -lHSbase-4.0.0.0 -lHSinteger-0.1.0.0 -lHSghc-prim-0.1.0.0 -lHSrts -lm \r\n-lffi -lgmp -ldl -search_paths_first -lgcc_s.10.5 -lgcc -lSystem\r\nlink: done\r\n*** Deleting temp files:\r\nDeleting: \r\n*** Deleting temp dirs:\r\nDeleting: /var/folders/uZ/uZjvUnuPHNmMwDWLlrsGT++++TI/-Tmp-//ghc13029_0\r\n\r\n$ ./original \r\n^C <increasing space usage>\r\n\r\n$ ghc -fforce-recomp --make condensed\r\n[1 of 1] Compiling Main ( condensed.hs, condensed.o )\r\nLinking condensed ...\r\n\r\n$ ./condensed \r\n^C <constant space>\r\n\r\n13:50 memleak$ ghc -O -fforce-recomp --make condensed\r\n[1 of 1] Compiling Main ( condensed.hs, condensed.o )\r\nLinking condensed ...\r\n\r\n$ ./condensed \r\n^C <increasing space usage>\r\n}}}\r\n\r\nI have checked with ghc-6.8.2 on \"Linux 2.6.27-11-generic 1 SMP Wed Apr 1 20:53:41 UTC 2009 x86_64 GNU/Linux\" and with ghc-6.10.1 and 6.11.200903331 on \"Darwin 9.7.0 Darwin Kernel Version 9.7.0: Tue Mar 31 22:52:17 PDT 2009; root:xnu-1228.12.14~1/RELEASE_I386 i386\"\r\n\r\nHere are some more runs with -fno-full-laziness and/or -fno-cse. Neither switch affects the memory requirements with -O:\r\n\r\n{{{\r\n$ ghc -fno-full-laziness -O -fforce-recomp --make condensed\r\n[1 of 1] Compiling Main ( condensed.hs, condensed.o )\r\nLinking condensed ...\r\n\r\n$ ./condensed \r\n^C <increasing memory usage>\r\n\r\n$ ghc -fno-cse -O -fforce-recomp --make condensed\r\n[1 of 1] Compiling Main ( condensed.hs, condensed.o )\r\nLinking condensed ...\r\n\r\n$ ./condensed \r\n^C <increasing memory usage>\r\n\r\n$ ghc -fno-full-laziness -fno-cse -O -fforce-recomp --make condensed\r\n[1 of 1] Compiling Main ( condensed.hs, condensed.o )\r\nLinking condensed ...\r\n\r\n$ ./condensed \r\n^C <increasing memory usage>\r\n}}}\r\n\r\nThe program original.hs contains an alternative implementation of 'iterDepth' that seems to hint at the problem. I think, the argument of 'runDepthBound' is held in memory for a good reason there.\r\n\r\nThe program condensed.hs contains four superflous occurrences of 'id' that seem to play together to cause the memory leak. If all of them are present then the program uses lots of space with -O, if either one is missing it runs in constant space. The program always runs in constant space without -O. I think, the space leak is caused by holding the arguments of 'id' in memory. If that is true, however, I don't see why *all* occurrences of 'id' are necessary to cause the leak.\r\n\r\nI think the original program and all versions of the condensed program should run in constant space with and without -O. It would be nice if the alternative version of the original program would run in constant space too but I see that there is sharing that may prevent this.","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/3245Quadratic slowdown in Data.Typeable2019-07-07T19:04:45ZguestQuadratic slowdown in Data.TypeableData.Typeable has a significant asymptotic performance problem. In the
attached code, sum2 runs much slower than either sum1 or sum3. It
should be linear but it seems to slow down quadratically (i.e.
doubling "len" quadruples the time fo...Data.Typeable has a significant asymptotic performance problem. In the
attached code, sum2 runs much slower than either sum1 or sum3. It
should be linear but it seems to slow down quadratically (i.e.
doubling "len" quadruples the time for sum2). Here is an example run:
```
$ ghc --make -O3 CastSpeed.hs
$ ./CastSpeed 20000
gsum1
Result: 200010000
Time(sec): 7.999e-3
Result: 200010000
Time(sec): 0.0
Result: 200010000
Time(sec): 1.0e-3
gsum2
Result: 200010000
Time(sec): 1.483774
Result: 200010000
Time(sec): 1.477776
Result: 200010000
Time(sec): 1.523768
gsum3
Result: 200010000
Time(sec): 5.999e-3
Result: 200010000
Time(sec): 0.0
Result: 200010000
Time(sec): 0.0
```
The only difference between sum1 and sum2 is that sum2 wraps a
singleton list around each element (i.e. the cast is to \[Int\] instead
of Int). The only difference between sum2 and sum3 is that sum3 uses
an unchecked cast (unsafeCoerce) instead of a checked cast. This
problem seems to crop up only for those types which are made up of a
type constructor applied to an argument (e.g. "\[\]" applied to "Int").
Because of sum3 runs fast, I suspect that something is going wrong
with the "typeOf" call in a checked cast, and because sum1 runs fast I
suspect that what is going wrong is the call to appKey that is called
from mkAppTy that is called from typeOfDefault that is called from the
Typeable instance for \[Int\] (i.e. instance (Typeable1 s, Typeable a)
=\> Typeable (s a)). This is a bit of speculation and I don't have
hard evidence for that being the source of the problems, but tests
that I have run (not listed here) are strongly suggestive of appKey
being the culprit.
- Michael D. Adams
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries (other) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Quadratic slowdown in Data.Typeable","status":"New","operating_system":"","component":"libraries (other)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Data.Typeable has a significant asymptotic performance problem. In the\r\nattached code, sum2 runs much slower than either sum1 or sum3. It\r\nshould be linear but it seems to slow down quadratically (i.e.\r\ndoubling \"len\" quadruples the time for sum2). Here is an example run:\r\n\r\n{{{\r\n$ ghc --make -O3 CastSpeed.hs\r\n$ ./CastSpeed 20000\r\ngsum1\r\nResult: 200010000\r\nTime(sec): 7.999e-3\r\nResult: 200010000\r\nTime(sec): 0.0\r\nResult: 200010000\r\nTime(sec): 1.0e-3\r\n\r\ngsum2\r\nResult: 200010000\r\nTime(sec): 1.483774\r\nResult: 200010000\r\nTime(sec): 1.477776\r\nResult: 200010000\r\nTime(sec): 1.523768\r\n\r\ngsum3\r\nResult: 200010000\r\nTime(sec): 5.999e-3\r\nResult: 200010000\r\nTime(sec): 0.0\r\nResult: 200010000\r\nTime(sec): 0.0\r\n}}}\r\n\r\nThe only difference between sum1 and sum2 is that sum2 wraps a\r\nsingleton list around each element (i.e. the cast is to [Int] instead\r\nof Int). The only difference between sum2 and sum3 is that sum3 uses\r\nan unchecked cast (unsafeCoerce) instead of a checked cast. This\r\nproblem seems to crop up only for those types which are made up of a\r\ntype constructor applied to an argument (e.g. \"[]\" applied to \"Int\").\r\n\r\nBecause of sum3 runs fast, I suspect that something is going wrong\r\nwith the \"typeOf\" call in a checked cast, and because sum1 runs fast I\r\nsuspect that what is going wrong is the call to appKey that is called\r\nfrom mkAppTy that is called from typeOfDefault that is called from the\r\nTypeable instance for [Int] (i.e. instance (Typeable1 s, Typeable a)\r\n=> Typeable (s a)). This is a bit of speculation and I don't have\r\nhard evidence for that being the source of the problems, but tests\r\nthat I have run (not listed here) are strongly suggestive of appKey\r\nbeing the culprit.\r\n\r\n- Michael D. Adams\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchIan Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3240Bad jump on PowerPC2019-07-07T19:04:46ZduaneBad jump on PowerPC```
ghc: internal error: unconditional relative branch out of range: jump island out of range
(GHC version 6.10.1 for powerpc_apple_darwin)
```
That's it. NOTE: I was compiling LHC when this happened.```
ghc: internal error: unconditional relative branch out of range: jump island out of range
(GHC version 6.10.1 for powerpc_apple_darwin)
```
That's it. NOTE: I was compiling LHC when this happened.6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/3221Incorrect "defined but not used" warning for data types using deriving2019-07-07T19:04:50ZNeil MitchellIncorrect "defined but not used" warning for data types using derivingConsider:
```
module Main() where
import System
data Foo = Bar | Baz
deriving (Show,Read)
main = do
[x] <- getArgs
print (read x :: Foo)
```
When we compile:
```
$ ghc -c Test.hs -fwarn-unused-binds
Test.hs:6:11:...Consider:
```
module Main() where
import System
data Foo = Bar | Baz
deriving (Show,Read)
main = do
[x] <- getArgs
print (read x :: Foo)
```
When we compile:
```
$ ghc -c Test.hs -fwarn-unused-binds
Test.hs:6:11: Warning: Defined but not used: data constructor `Bar'
Test.hs:6:17: Warning: Defined but not used: data constructor `Baz'
```
This is incorrect. If a data type derives `Read`, `Enum` or `Bounded` (and for `Bounded`, is either the first or last element), then the values are used - even if not by name.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------------- |
| Version | 6.10.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ndmitchell@gmail.com |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Incorrect \"defined but not used\" warning for data types using deriving","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ndmitchell@gmail.com"],"type":"Bug","description":"Consider:\r\n\r\n{{{\r\n\r\nmodule Main() where\r\n\r\nimport System\r\n\r\ndata Foo = Bar | Baz\r\n deriving (Show,Read)\r\n\r\nmain = do\r\n [x] <- getArgs\r\n print (read x :: Foo)\r\n}}}\r\n\r\nWhen we compile:\r\n\r\n{{{\r\n$ ghc -c Test.hs -fwarn-unused-binds\r\nTest.hs:6:11: Warning: Defined but not used: data constructor `Bar'\r\nTest.hs:6:17: Warning: Defined but not used: data constructor `Baz'\r\n}}}\r\n\r\nThis is incorrect. If a data type derives {{{Read}}}, {{{Enum}}} or {{{Bounded}}} (and for {{{Bounded}}}, is either the first or last element), then the values are used - even if not by name.","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/3193line number for GADT type error is very inaccurate2019-07-07T19:04:57Znr@eecs.harvard.eduline number for GADT type error is very inaccurateHere is an error message from 6.11:
```
cmm/ZDF5ex.hs:528:2:
Couldn't match expected type `ZOpen'
against inferred type `ZClosed'
Expected type: ZipGF m l e x
Inferred type: ZipGF m l C O
In the first argu...Here is an error message from 6.11:
```
cmm/ZDF5ex.hs:528:2:
Couldn't match expected type `ZOpen'
against inferred type `ZClosed'
Expected type: ZipGF m l e x
Inferred type: ZipGF m l C O
In the first argument of `anal_f', namely `g'
In the expression: anal_f g (return . fromZJust) ZNothing
```
This is all very well, but the offending term (the one shown in the message) is actually on line 697, not line 528. The term is part of one declaration in a monster 'where' clause attached to the definition on line 528, column 2. The next one might not be so easy to find.
I'm attaching the file, which is part of some new GHC code I'm hoping to deliver one of these months. If you need access to the whole thing I'll have a branch in a git repository.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.11 |
| 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":"line number for GADT type error is very inaccurate","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.11","keywords":["GADTs"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Here is an error message from 6.11:\r\n{{{\r\ncmm/ZDF5ex.hs:528:2:\r\n Couldn't match expected type `ZOpen'\r\n against inferred type `ZClosed'\r\n Expected type: ZipGF m l e x\r\n Inferred type: ZipGF m l C O\r\n In the first argument of `anal_f', namely `g'\r\n In the expression: anal_f g (return . fromZJust) ZNothing\r\n}}}\r\nThis is all very well, but the offending term (the one shown in the message) is actually on line 697, not line 528. The term is part of one declaration in a monster 'where' clause attached to the definition on line 528, column 2. The next one might not be so easy to find.\r\n\r\nI'm attaching the file, which is part of some new GHC code I'm hoping to deliver one of these months. If you need access to the whole thing I'll have a branch in a git repository.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/3177support quasiquoting for types2019-07-07T19:05:01Zclaus.reinke@talk21.comsupport quasiquoting for typesCurrently, quasiquotes are limited to patterns and expressions, though patterns and expressions with explicit type signatures can be generated (with appropriate language flag for pattern signatures).
Since so much of Haskell programming...Currently, quasiquotes are limited to patterns and expressions, though patterns and expressions with explicit type signatures can be generated (with appropriate language flag for pattern signatures).
Since so much of Haskell programming happens at the type level, it would be great if quasiquoting wasn't excluded from that part of the game (think type-level numbers, for instance, or any type-level library that requires constants translated into types).
For just one example, see http://www.haskell.org/pipermail/haskell-cafe/2009-April/059819.html , where I would like to be able to specify label types and type tags directly at the type-level as well.
related: #1476 (Template Haskell won't address this in the near future, so having quasiquotes for types would narrow the gap)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.11 |
| 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":"support quasiquoting for types","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Currently, quasiquotes are limited to patterns and expressions, though patterns and expressions with explicit type signatures can be generated (with appropriate language flag for pattern signatures).\r\n\r\nSince so much of Haskell programming happens at the type level, it would be great if quasiquoting wasn't excluded from that part of the game (think type-level numbers, for instance, or any type-level library that requires constants translated into types).\r\n\r\nFor just one example, see http://www.haskell.org/pipermail/haskell-cafe/2009-April/059819.html , where I would like to be able to specify label types and type tags directly at the type-level as well. \r\n\r\nrelated: #1476 (Template Haskell won't address this in the near future, so having quasiquotes for types would narrow the gap)","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/3100GHC Panic "reifyType PredTy" in HAppS.Data.IxSet.inferIxSet2019-07-07T19:05:24ZmightybyteGHC Panic "reifyType PredTy" in HAppS.Data.IxSet.inferIxSet```
Exception when trying to run compile-time code:
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.1 for x86_64-unknown-linux):
reifyType PredTy
```
Code reproducing this bug can be found at:
http://hpaste.org/fastcgi...```
Exception when trying to run compile-time code:
ghc: panic! (the 'impossible' happened)
(GHC version 6.10.1 for x86_64-unknown-linux):
reifyType PredTy
```
Code reproducing this bug can be found at:
http://hpaste.org/fastcgi/hpaste.fcgi/view?id=2419
Marked as critical because I haven't found a workaround yet.6.12 branchIan Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/3019sparc membar asm instruction requires mode parameter2019-07-07T19:05:51Zduncansparc membar asm instruction requires mode parameterThe new `parallel/WSDeque.c` uses `store_load_barrier()` from `includes/SMP.h`.
```
EXTERN_INLINE void
store_load_barrier(void) {
#if i386_HOST_ARCH
__asm__ __volatile__ ("lock; addl $0,0(%%esp)" : : : "memory");
#elif x86_64_HOST_A...The new `parallel/WSDeque.c` uses `store_load_barrier()` from `includes/SMP.h`.
```
EXTERN_INLINE void
store_load_barrier(void) {
#if i386_HOST_ARCH
__asm__ __volatile__ ("lock; addl $0,0(%%esp)" : : : "memory");
#elif x86_64_HOST_ARCH
__asm__ __volatile__ ("lock; addq $0,0(%%rsp)" : : : "memory");
#elif powerpc_HOST_ARCH
__asm__ __volatile__ ("msync" : : : "memory");
#elif sparc_HOST_ARCH
/* Sparc in TSO mode does not require write/write barriers. */
__asm__ __volatile__ ("membar" : : : "memory");
#elif !defined(WITHSMP)
return;
#else
#error memory barriers unimplemented on this architecture
#endif
```
In particular for sparc the bit:
```
/* Sparc in TSO mode does not require write/write barriers. */
__asm__ __volatile__ ("membar" : : : "memory");
```
This is not right. The membar assembly statement requires a parameter to specify which kind of memory barrier is required. For `store_load_barrier()` it is of course `membar #StoreLoad`.
Without this the assembler complains:
```
/usr/ccs/bin/as: "parallel/WSDeque.s", line 11: error: statement syntax
```
With `#StoreLoad` added it's fine.
Note also that the comment appears to be wrong
```
/* Sparc in TSO mode does not require write/write barriers. */
```
This is `store_load_barrier()` not `store_store_barrier()` so it is exactly and only this case that is required.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.11 |
| 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":"sparc membar asm instruction requires mode parameter","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"simonmar"},"version":"6.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The new `parallel/WSDeque.c` uses `store_load_barrier()` from `includes/SMP.h`.\r\n\r\n{{{\r\nEXTERN_INLINE void\r\nstore_load_barrier(void) {\r\n#if i386_HOST_ARCH\r\n __asm__ __volatile__ (\"lock; addl $0,0(%%esp)\" : : : \"memory\");\r\n#elif x86_64_HOST_ARCH\r\n __asm__ __volatile__ (\"lock; addq $0,0(%%rsp)\" : : : \"memory\");\r\n#elif powerpc_HOST_ARCH\r\n __asm__ __volatile__ (\"msync\" : : : \"memory\");\r\n#elif sparc_HOST_ARCH\r\n /* Sparc in TSO mode does not require write/write barriers. */\r\n __asm__ __volatile__ (\"membar\" : : : \"memory\");\r\n#elif !defined(WITHSMP)\r\n return;\r\n#else\r\n#error memory barriers unimplemented on this architecture\r\n#endif\r\n}}}\r\n\r\nIn particular for sparc the bit:\r\n{{{\r\n /* Sparc in TSO mode does not require write/write barriers. */\r\n __asm__ __volatile__ (\"membar\" : : : \"memory\");\r\n}}}\r\n\r\nThis is not right. The membar assembly statement requires a parameter to specify which kind of memory barrier is required. For `store_load_barrier()` it is of course `membar #StoreLoad`.\r\n\r\nWithout this the assembler complains:\r\n{{{\r\n/usr/ccs/bin/as: \"parallel/WSDeque.s\", line 11: error: statement syntax\r\n}}}\r\n\r\nWith `#StoreLoad` added it's fine.\r\n\r\nNote also that the comment appears to be wrong\r\n{{{\r\n /* Sparc in TSO mode does not require write/write barriers. */\r\n}}}\r\nThis is `store_load_barrier()` not `store_store_barrier()` so it is exactly and only this case that is required.","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchSimon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/2995ghc -Wall does not complain about unnecessary data constructor imports2019-07-07T19:05:58ZEyalLotemghc -Wall does not complain about unnecessary data constructor importsIf it is enough to import:
```
import SomeModule(SomeType)
```
Then ghc should complain (warn) when importing:
```
import SomeModule(SomeType(..))
```
or:
```
import SomeModule(SomeType(SomeConstructor))
```
But it doesn't output a...If it is enough to import:
```
import SomeModule(SomeType)
```
Then ghc should complain (warn) when importing:
```
import SomeModule(SomeType(..))
```
or:
```
import SomeModule(SomeType(SomeConstructor))
```
But it doesn't output any complaint or warning.6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/2984Vectorized dph code doesn't terminate2019-07-07T19:06:00ZfreVectorized dph code doesn't terminateThe program attached to this ticket doesn't terminate when vectorisation is used. It runs fine when vectorisation is not enabled.
The problem seems to be the use of sumP or mapP with the empty array.
<details><summary>Trac metadata</su...The program attached to this ticket doesn't terminate when vectorisation is used. It runs fine when vectorisation is not enabled.
The problem seems to be the use of sumP or mapP with the empty array.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | --------------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Data Parallel Haskell |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Linux |
| Architecture | x86 |
</details>
<!-- {"blocked_by":[],"summary":"Vectorized dph code doesn't terminate","status":"New","operating_system":"Linux","component":"Data Parallel Haskell","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"x86","cc":[""],"type":"Bug","description":"The program attached to this ticket doesn't terminate when vectorisation is used. It runs fine when vectorisation is not enabled.\r\n\r\nThe problem seems to be the use of sumP or mapP with the empty array. ","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchrl@cse.unsw.edu.aurl@cse.unsw.edu.auhttps://gitlab.haskell.org/ghc/ghc/-/issues/2981".space" directive not recognised by solaris assembler2019-07-07T19:06:01Zduncan".space" directive not recognised by solaris assemblerThe Solaris assembler (`/usr/ccs/bin/as`) does not recognise the `.space` directive. Presumably the GNU assembler does.
```
/usr/ccs/bin/as: "test.s", line 484: error: unknown opcode ".space"
/usr/ccs/bin/as: "test.s", line 484: error: ...The Solaris assembler (`/usr/ccs/bin/as`) does not recognise the `.space` directive. Presumably the GNU assembler does.
```
/usr/ccs/bin/as: "test.s", line 484: error: unknown opcode ".space"
/usr/ccs/bin/as: "test.s", line 484: error: statement syntax
```
It happens building ghc head on sparc solaris with the NCG turned on. However the pretty-printing code:
`compiler/nativeGen/PprMach.hs:`
```
pprData (CmmUninitialised bytes) = ptext (sLit ".space ") <> int bytes
```
does not look like it's in a section that is specific to sparc or solaris. So presumably the same issue applies on Solaris on x86 systems when using the system gcc and assembler rather than GNU as.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.11 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (NCG) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"\".space\" directive not recognised by solaris assembler","status":"New","operating_system":"","component":"Compiler (NCG)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The Solaris assembler (`/usr/ccs/bin/as`) does not recognise the `.space` directive. Presumably the GNU assembler does.\r\n\r\n{{{\r\n/usr/ccs/bin/as: \"test.s\", line 484: error: unknown opcode \".space\"\r\n/usr/ccs/bin/as: \"test.s\", line 484: error: statement syntax\r\n}}}\r\n\r\nIt happens building ghc head on sparc solaris with the NCG turned on. However the pretty-printing code:\r\n\r\n`compiler/nativeGen/PprMach.hs:`\r\n{{{\r\npprData (CmmUninitialised bytes) = ptext (sLit \".space \") <> int bytes\r\n}}}\r\n\r\ndoes not look like it's in a section that is specific to sparc or solaris. So presumably the same issue applies on Solaris on x86 systems when using the system gcc and assembler rather than GNU as.","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchbenlbenlhttps://gitlab.haskell.org/ghc/ghc/-/issues/2962Reduce space usage of genericLength for common Num instances2019-07-07T19:06:07ZthorkilnaurReduce space usage of genericLength for common Num instancesThere is a space leak in `genericLength`:
```
$ ghc/stage2-inplace/ghc --interactive
GHCi, version 6.11.20090116: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer ... linkin...There is a space leak in `genericLength`:
```
$ ghc/stage2-inplace/ghc --interactive
GHCi, version 6.11.20090116: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer ... linking ... done.
Loading package base ... linking ... done.
Loading package ffi-1.0 ... linking ... done.
Prelude> :module +List
Prelude List> genericLength [1..600000]
*** Exception: stack overflow
Prelude List>
Prelude List> length [1..600000]
600000
Prelude List>
```
The attached patch against the base library provides a fix.
Best regards
Thorkil
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.11 |
| 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":"Fix space leak in genericLength","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"There is a space leak in {{{genericLength}}}:\r\n{{{\r\n$ ghc/stage2-inplace/ghc --interactive\r\nGHCi, version 6.11.20090116: http://www.haskell.org/ghc/ :? for help\r\nLoading package ghc-prim ... linking ... done.\r\nLoading package integer ... linking ... done.\r\nLoading package base ... linking ... done.\r\nLoading package ffi-1.0 ... linking ... done.\r\nPrelude> :module +List\r\nPrelude List> genericLength [1..600000]\r\n*** Exception: stack overflow\r\nPrelude List>\r\nPrelude List> length [1..600000]\r\n600000\r\nPrelude List>\r\n}}}\r\nThe attached patch against the base library provides a fix.\r\n\r\nBest regards\r\nThorkil\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchthorkilnaurthorkilnaur