GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T19:02:53Zhttps://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/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/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/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/1969enormous compile times2019-07-07T19:10:50Zduncanenormous compile timesSome modules cause ghc to take a very very long time (and a lot of memory) to compile, even without optimisations.
Here is an example of a module that takes almost forever to compile. The `WASH/HTML/HTMLMonad98.hs` module from WASH-2.12...Some modules cause ghc to take a very very long time (and a lot of memory) to compile, even without optimisations.
Here is an example of a module that takes almost forever to compile. The `WASH/HTML/HTMLMonad98.hs` module from WASH-2.12 http://www.informatik.uni-freiburg.de/\~thiemann/haskell/WASH/
It is a 185k, 5,800 line module consisting almost entirely of data, class and instance declarations.
It might be interesting to use this module as a test case to profile ghc's front end to see if there are any obvious inefficiencies or unecessary non-linear algorithms.
`WASH/HTML/HTMLPrelude.hs` is almost as bad. Between the two of them they push the overall compile time for WASH to several minutes with -O0 and nearly half an hour with -O1. GHC's memory use while compiling WASH also grows to over 300Mb with -O0 and over 600Mb with -O1 (on a 64bit box).
All in all, WASH is an excellent stress test for GHC.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.8.1 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Multiple |
| Architecture | Multiple |
</details>
<!-- {"blocked_by":[],"summary":"enormous compile times","status":"New","operating_system":"Multiple","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.1","keywords":[],"differentials":[],"test_case":"","architecture":"Multiple","cc":[""],"type":"Task","description":"Some modules cause ghc to take a very very long time (and a lot of memory) to compile, even without optimisations.\r\n\r\nHere is an example of a module that takes almost forever to compile. The {{{WASH/HTML/HTMLMonad98.hs}}} module from WASH-2.12 http://www.informatik.uni-freiburg.de/~thiemann/haskell/WASH/\r\n\r\nIt is a 185k, 5,800 line module consisting almost entirely of data, class and instance declarations.\r\n\r\nIt might be interesting to use this module as a test case to profile ghc's front end to see if there are any obvious inefficiencies or unecessary non-linear algorithms.\r\n\r\n{{{WASH/HTML/HTMLPrelude.hs}}} is almost as bad. Between the two of them they push the overall compile time for WASH to several minutes with -O0 and nearly half an hour with -O1. GHC's memory use while compiling WASH also grows to over 300Mb with -O0 and over 600Mb with -O1 (on a 64bit box).\r\n\r\nAll in all, WASH is an excellent stress test for GHC.","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchIan Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/1954Incorrect "Defined but not used" warning when using GeneralizedNewtypeDeriving2019-07-07T19:10:54ZmagnusIncorrect "Defined but not used" warning when using GeneralizedNewtypeDerivingWhen compiling
```
{-# LANGUAGE GeneralizedNewtypeDeriving #-}
{-# OPTIONS_GHC -Wall -Werror #-}
module Bug(P, runP) where
import Control.Monad.Identity(Identity, runIdentity)
newtype P a = P { unP :: Identity a } deriving Monad
runP...When compiling
```
{-# LANGUAGE GeneralizedNewtypeDeriving #-}
{-# OPTIONS_GHC -Wall -Werror #-}
module Bug(P, runP) where
import Control.Monad.Identity(Identity, runIdentity)
newtype P a = P { unP :: Identity a } deriving Monad
runP :: P a -> a
runP = runIdentity . unP
```
I get
```
Bug.hs:7:14: Warning: Defined but not used: data constructor `P'
```
although the constructor is used in the derived Monad instance. This is obviously not a show stopper, but it forces me to rewrite what to me looks like an OK program if I want to stick to the given OPTIONS_GHC.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.8.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Incorrect \"Defined but not used\" warning when using GeneralizedNewtypeDeriving","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"When compiling\r\n{{{\r\n{-# LANGUAGE GeneralizedNewtypeDeriving #-}\r\n{-# OPTIONS_GHC -Wall -Werror #-}\r\nmodule Bug(P, runP) where\r\n\r\nimport Control.Monad.Identity(Identity, runIdentity)\r\n\r\nnewtype P a = P { unP :: Identity a } deriving Monad\r\n\r\nrunP :: P a -> a\r\nrunP = runIdentity . unP\r\n}}}\r\nI get \r\n{{{\r\nBug.hs:7:14: Warning: Defined but not used: data constructor `P'\r\n}}}\r\nalthough the constructor is used in the derived Monad instance. This is obviously not a show stopper, but it forces me to rewrite what to me looks like an OK program if I want to stick to the given OPTIONS_GHC.\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/1653GHCi ':set' completion does not list all options2019-07-07T19:12:23ZStefan O'Rear <stefanor@cox.net>GHCi ':set' completion does not list all optionsIn particular, the new -X options are missing:
```
stefan@stefans:/tmp$ ghci
GHCi, version 6.7.20070829: http://www.haskell.org/ghc/ :? for help
Loading package base ... linking ... done.
Prelude> :set -XTyp(TAB TAB, with no effect)
un...In particular, the new -X options are missing:
```
stefan@stefans:/tmp$ ghci
GHCi, version 6.7.20070829: http://www.haskell.org/ghc/ :? for help
Loading package base ... linking ... done.
Prelude> :set -XTyp(TAB TAB, with no effect)
unrecognised flags: -XTyp
Prelude> :set -XTypeFamilies
Prelude> Leaving GHCi.
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | sorear |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHCi ':set' completion does not list all options","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["sorear"],"type":"Bug","description":"In particular, the new -X options are missing:\r\n\r\n{{{\r\nstefan@stefans:/tmp$ ghci\r\nGHCi, version 6.7.20070829: http://www.haskell.org/ghc/ :? for help\r\nLoading package base ... linking ... done.\r\nPrelude> :set -XTyp(TAB TAB, with no effect)\r\nunrecognised flags: -XTyp\r\nPrelude> :set -XTypeFamilies\r\nPrelude> Leaving GHCi.\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchhttps://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/2861stage2 crash: PAP object entered!2019-07-07T19:06:31ZSimon Marlowstage2 crash: PAP object entered!With stage2 today:
```
$ ./ghc/stage2-inplace/ghc -package foo
ghc: internal error: PAP object entered!
(GHC version 6.11 for x86_64_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
Int...With stage2 today:
```
$ ./ghc/stage2-inplace/ghc -package foo
ghc: internal error: PAP object entered!
(GHC version 6.11 for x86_64_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
Interestingly, `-dcore-lint` doesn't find any errors. Looking at the `-ddump-simpl` output for `Packages.hs`, this is the function that is supposed to throw the exception containing the error message for an unknown package. It has been suspiciously eta-expanded a bit...
```
a_r5fu :: GHC.Base.String
-> GHC.Prim.State# GHC.Prim.RealWorld
-> GHC.Prim.State# GHC.Prim.RealWorld
-> GHC.Prim.State# GHC.Prim.RealWorld
-> GHC.Prim.State# GHC.Prim.RealWorld
-> GHC.Prim.State# GHC.Prim.RealWorld
-> GHC.Prim.State# GHC.Prim.RealWorld
-> GHC.Prim.State# GHC.Prim.RealWorld
-> GHC.Prim.State# GHC.Prim.RealWorld
-> GHC.Prim.State# GHC.Prim.RealWorld
-> GHC.Prim.State# GHC.Prim.RealWorld
-> GHC.Prim.State# GHC.Prim.RealWorld
-> GHC.Prim.State# GHC.Prim.RealWorld
-> GHC.Prim.State# GHC.Prim.RealWorld
-> GHC.Prim.State# GHC.Prim.RealWorld
-> GHC.Prim.State# GHC.Prim.RealWorld
-> GHC.Prim.State# GHC.Prim.RealWorld
-> GHC.Prim.State# GHC.Prim.RealWorld
-> GHC.Prim.State# GHC.Prim.RealWorld
-> GHC.Prim.State# GHC.Prim.RealWorld
-> GHC.Prim.State# GHC.Prim.RealWorld
-> GHC.Prim.State# GHC.Prim.RealWorld
-> GHC.Prim.State# GHC.Prim.RealWorld
-> GHC.Prim.State# GHC.Prim.RealWorld
-> GHC.IOBase.IO [PackageConfig.PackageConfig]
[GlobalId]
[Arity 25]
a_r5fu =
\ (p_a1Pc :: GHC.Base.String)
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
_
(eta22_s5c7 :: GHC.Prim.State# GHC.Prim.RealWorld) ->
(\ (eta23_s5dN :: GHC.Prim.State# GHC.Prim.RealWorld) ->
((Panic.ghcError
@ (GHC.IOBase.IO [PackageConfig.PackageConfig])
(Panic.CmdLineError
(Pretty.fullRender
@ GHC.Base.String
Pretty.PageMode
Pretty.lvl1
Pretty.lvl
Pretty.string_txt
(GHC.Types.[] @ GHC.Types.Char)
(Pretty.Beside lvl_r5fs GHC.Bool.True (Pretty.text p_a1Pc)))))
`cast` (GHC.IOBase.NTCo:IO [PackageConfig.PackageConfig]
:: GHC.IOBase.IO [PackageConfig.PackageConfig]
~
GHC.Prim.State# GHC.Prim.RealWorld
-> (# GHC.Prim.State# GHC.Prim.RealWorld,
[PackageConfig.PackageConfig] #)))
eta23_s5dN)
`cast` (sym (GHC.IOBase.NTCo:IO [PackageConfig.PackageConfig])
:: GHC.Prim.State# GHC.Prim.RealWorld
-> (# GHC.Prim.State# GHC.Prim.RealWorld,
[PackageConfig.PackageConfig] #)
~
GHC.IOBase.IO [PackageConfig.PackageConfig])
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"stage2 crash: PAP object entered!","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"6.12 branch","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"With stage2 today:\r\n\r\n{{{\r\n$ ./ghc/stage2-inplace/ghc -package foo\r\nghc: internal error: PAP object entered!\r\n (GHC version 6.11 for x86_64_unknown_linux)\r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\nInterestingly, `-dcore-lint` doesn't find any errors. Looking at the `-ddump-simpl` output for `Packages.hs`, this is the function that is supposed to throw the exception containing the error message for an unknown package. It has been suspiciously eta-expanded a bit...\r\n\r\n{{{\r\na_r5fu :: GHC.Base.String\r\n -> GHC.Prim.State# GHC.Prim.RealWorld\r\n -> GHC.Prim.State# GHC.Prim.RealWorld\r\n -> GHC.Prim.State# GHC.Prim.RealWorld\r\n -> GHC.Prim.State# GHC.Prim.RealWorld\r\n -> GHC.Prim.State# GHC.Prim.RealWorld\r\n -> GHC.Prim.State# GHC.Prim.RealWorld\r\n -> GHC.Prim.State# GHC.Prim.RealWorld\r\n -> GHC.Prim.State# GHC.Prim.RealWorld\r\n -> GHC.Prim.State# GHC.Prim.RealWorld\r\n -> GHC.Prim.State# GHC.Prim.RealWorld\r\n -> GHC.Prim.State# GHC.Prim.RealWorld\r\n -> GHC.Prim.State# GHC.Prim.RealWorld\r\n -> GHC.Prim.State# GHC.Prim.RealWorld\r\n -> GHC.Prim.State# GHC.Prim.RealWorld\r\n -> GHC.Prim.State# GHC.Prim.RealWorld\r\n -> GHC.Prim.State# GHC.Prim.RealWorld\r\n -> GHC.Prim.State# GHC.Prim.RealWorld\r\n -> GHC.Prim.State# GHC.Prim.RealWorld\r\n -> GHC.Prim.State# GHC.Prim.RealWorld\r\n -> GHC.Prim.State# GHC.Prim.RealWorld\r\n -> GHC.Prim.State# GHC.Prim.RealWorld\r\n -> GHC.Prim.State# GHC.Prim.RealWorld\r\n -> GHC.Prim.State# GHC.Prim.RealWorld\r\n -> GHC.IOBase.IO [PackageConfig.PackageConfig]\r\n[GlobalId]\r\n[Arity 25]\r\na_r5fu =\r\n \\ (p_a1Pc :: GHC.Base.String)\r\n _\r\n _\r\n _\r\n _\r\n _\r\n _\r\n _\r\n _\r\n _\r\n _\r\n _\r\n _\r\n _\r\n _\r\n _\r\n _\r\n _\r\n _\r\n _\r\n _\r\n _\r\n _\r\n (eta22_s5c7 :: GHC.Prim.State# GHC.Prim.RealWorld) ->\r\n (\\ (eta23_s5dN :: GHC.Prim.State# GHC.Prim.RealWorld) ->\r\n ((Panic.ghcError\r\n @ (GHC.IOBase.IO [PackageConfig.PackageConfig])\r\n (Panic.CmdLineError\r\n (Pretty.fullRender\r\n @ GHC.Base.String\r\n Pretty.PageMode\r\n Pretty.lvl1\r\n Pretty.lvl\r\n Pretty.string_txt\r\n (GHC.Types.[] @ GHC.Types.Char)\r\n (Pretty.Beside lvl_r5fs GHC.Bool.True (Pretty.text p_a1Pc)))))\r\n `cast` (GHC.IOBase.NTCo:IO [PackageConfig.PackageConfig]\r\n :: GHC.IOBase.IO [PackageConfig.PackageConfig]\r\n ~\r\n GHC.Prim.State# GHC.Prim.RealWorld\r\n -> (# GHC.Prim.State# GHC.Prim.RealWorld,\r\n [PackageConfig.PackageConfig] #)))\r\n eta23_s5dN)\r\n `cast` (sym (GHC.IOBase.NTCo:IO [PackageConfig.PackageConfig])\r\n :: GHC.Prim.State# GHC.Prim.RealWorld\r\n -> (# GHC.Prim.State# GHC.Prim.RealWorld,\r\n [PackageConfig.PackageConfig] #)\r\n ~\r\n GHC.IOBase.IO [PackageConfig.PackageConfig])\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/2844incorrect results when not compiling with optimisation2019-07-07T19:06:36ZIan Lynagh <igloo@earth.li>incorrect results when not compiling with optimisationThis is a cut-down `random1283`.
`R.hs`:
```
module R (randomIO) where
class Num a => Random a where
randomIO :: IO a
instance Random Int where
randomIO = return 10003
```
`s.hs`:
```
import R
main :: IO ()
main = do r >>=...This is a cut-down `random1283`.
`R.hs`:
```
module R (randomIO) where
class Num a => Random a where
randomIO :: IO a
instance Random Int where
randomIO = return 10003
```
`s.hs`:
```
import R
main :: IO ()
main = do r >>= print
r >>= print
r :: IO Int
r = randomIO
```
```
$ rm *.o *.hi s
$ ghc -c R.hs
$ ghc s.hs R.o -o s
$ ./s
-4611686018427387865
-4611686018427387865
$ rm *.o *.hi s
$ ghc -c R.hs
$ ghc s.hs R.o -o s -O
$ ./s
10003
10003
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.11.20081205
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.11 |
| 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":"incorrect results when not compiling with optimisation","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"6.12 branch","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This is a cut-down `random1283`.\r\n\r\n`R.hs`:\r\n{{{\r\nmodule R (randomIO) where\r\n\r\nclass Num a => Random a where\r\n randomIO :: IO a\r\n\r\ninstance Random Int where\r\n randomIO = return 10003\r\n}}}\r\n\r\n`s.hs`:\r\n{{{\r\nimport R\r\n\r\nmain :: IO ()\r\nmain = do r >>= print\r\n r >>= print\r\n\r\nr :: IO Int\r\nr = randomIO\r\n}}}\r\n\r\n{{{\r\n$ rm *.o *.hi s\r\n$ ghc -c R.hs\r\n$ ghc s.hs R.o -o s\r\n$ ./s\r\n-4611686018427387865\r\n-4611686018427387865\r\n$ rm *.o *.hi s\r\n$ ghc -c R.hs\r\n$ ghc s.hs R.o -o s -O\r\n$ ./s\r\n10003\r\n10003\r\n$ ghc --version\r\nThe Glorious Glasgow Haskell Compilation System, version 6.11.20081205\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/2813Create a utf8 bytestring-a-like2019-07-07T19:06:43ZIan Lynagh <igloo@earth.li>Create a utf8 bytestring-a-likeThere are a number of things we want a utf8 bytestring-a-like for:
- GHC's !FastString to be built on top of
- Text.!PrettyPrint.ptext (this means we can drop GHC's utils/Pretty)
- template haskell, to use in place of packedstring
- pos...There are a number of things we want a utf8 bytestring-a-like for:
- GHC's !FastString to be built on top of
- Text.!PrettyPrint.ptext (this means we can drop GHC's utils/Pretty)
- template haskell, to use in place of packedstring
- possibly to use in the base IO libraries (see also #2811)
- possibly to use in haskeline (see also #2812)
and probably more besides. Ideally all of this will be done comfortably in time for 6.12!
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | libraries (other) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Create a utf8 bytestring-a-like","status":"New","operating_system":"","component":"libraries (other)","related":[],"milestone":"6.12 branch","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"There are a number of things we want a utf8 bytestring-a-like for:\r\n * GHC's !FastString to be built on top of\r\n * Text.!PrettyPrint.ptext (this means we can drop GHC's utils/Pretty)\r\n * template haskell, to use in place of packedstring\r\n * possibly to use in the base IO libraries (see also #2811)\r\n * possibly to use in haskeline (see also #2812)\r\nand probably more besides. Ideally all of this will be done comfortably in time for 6.12!\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/2712Parallel GC scheduling problems2019-07-07T19:07:13ZSimon MarlowParallel GC scheduling problemsThe parallel GC uses its own gang of threads separate from those used to run the program. This is causing performance loss, severe in some cases, especially when the number of GC threads and mutator threads equals the number of processor...The parallel GC uses its own gang of threads separate from those used to run the program. This is causing performance loss, severe in some cases, especially when the number of GC threads and mutator threads equals the number of processor cores. In this case, when the GC spins up, the OS has to schedule N threads onto N cores, where all cores already have other threads running. It has to correctly choose to bump the old mutator threads off to make room for the new GC threads, but at least on Linux it doesn't always succeed in doing this, and there can be a delay while the scheduler sorts things out (as much as 50ms). The measurements I've been using to test the parallel GC so far have been mostly on single-threaded programs, so this problem only emerged recently.
Really we ought to be using the mutator threads as GC threads too. Things are made slightly more complicated by the fact that some of the mutator threads might not be awake when we GC, if not all cores are busy. Perhaps we should bite the bullet and try to set affinity masks.
If this is affecting you, try turning off the parallel GC, or reducing the number of threads it uses, with e.g. `+RTS -g1`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Parallel GC scheduling problems","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"6.10.2","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"simonmar"},"version":"6.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The parallel GC uses its own gang of threads separate from those used to run the program. This is causing performance loss, severe in some cases, especially when the number of GC threads and mutator threads equals the number of processor cores. In this case, when the GC spins up, the OS has to schedule N threads onto N cores, where all cores already have other threads running. It has to correctly choose to bump the old mutator threads off to make room for the new GC threads, but at least on Linux it doesn't always succeed in doing this, and there can be a delay while the scheduler sorts things out (as much as 50ms). The measurements I've been using to test the parallel GC so far have been mostly on single-threaded programs, so this problem only emerged recently.\r\n\r\nReally we ought to be using the mutator threads as GC threads too. Things are made slightly more complicated by the fact that some of the mutator threads might not be awake when we GC, if not all cores are busy. Perhaps we should bite the bullet and try to set affinity masks.\r\n\r\nIf this is affecting you, try turning off the parallel GC, or reducing the number of threads it uses, with e.g. `+RTS -g1`.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchSimon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/1673Template Haskell support for type families2019-07-07T19:12:12Zg9ks157k@acme.softbase.orgTemplate Haskell support for type familiesWould it be possible to add support for analyzing and generating type family stuff to Template Haskell?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------...Would it be possible to add support for analyzing and generating type family stuff to Template Haskell?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 6.7 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Template Haskell |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Linux |
| Architecture | x86 |
</details>
<!-- {"blocked_by":[],"summary":"Template Haskell support for type families","status":"New","operating_system":"Linux","component":"Template Haskell","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.7","keywords":[],"differentials":[],"test_case":"","architecture":"x86","cc":[""],"type":"FeatureRequest","description":"Would it be possible to add support for analyzing and generating type family stuff to Template Haskell?","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/1501Panic in RegisterAlloc2019-07-07T19:13:10ZguestPanic in RegisterAllocThe following code causes a panic when compiling with the NCG (i.e. with `-fasm`).
```
stg_ap_0_fast {
bits32 y, x;
c7: y = bits32[x];
goto c7;
}
```
The panic is
```
ghc-6.7.20070620: panic! (the 'impossible' happened...The following code causes a panic when compiling with the NCG (i.e. with `-fasm`).
```
stg_ap_0_fast {
bits32 y, x;
c7: y = bits32[x];
goto c7;
}
```
The panic is
```
ghc-6.7.20070620: panic! (the 'impossible' happened)
(GHC version 6.7.20070620 for i386-unknown-linux):
RegisterAlloc.joinToTargets
```
I do not know of any code that depends on this yet. I just tripped over it when writting tests for the CPS pass.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (NCG) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Multiple |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Panic in RegisterAlloc","status":"New","operating_system":"Multiple","component":"Compiler (NCG)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The following code causes a panic when compiling with the NCG (i.e. with {{{-fasm}}}).\r\n\r\n{{{\r\nstg_ap_0_fast {\r\n bits32 y, x;\r\n c7: y = bits32[x];\r\n goto c7;\r\n}\r\n}}}\r\n\r\nThe panic is\r\n{{{\r\nghc-6.7.20070620: panic! (the 'impossible' happened)\r\n (GHC version 6.7.20070620 for i386-unknown-linux):\r\n RegisterAlloc.joinToTargets\r\n}}}\r\n\r\nI do not know of any code that depends on this yet. I just tripped over it when writting tests for the CPS pass.","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchbenlbenlhttps://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/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/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 branch