GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2022-10-24T16:34:06Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/5262Compiling with -O makes some expressions too lazy and causes space leaks2022-10-24T16:34:06Zmichal.palkaCompiling with -O makes some expressions too lazy and causes space leaksHere are some expressions that are executed in a too lazy way when optimisation is turned on in GHC. GHC is known to make some expressions too lazy when full laziness is turned on (as in #917), and indeed some of these expressions execut...Here are some expressions that are executed in a too lazy way when optimisation is turned on in GHC. GHC is known to make some expressions too lazy when full laziness is turned on (as in #917), and indeed some of these expressions execute correctly when you add -fno-full-laziness. However, some of them are compiled too lazy even if -fno-full-laziness is present.
Here are terms that get compiled too lazy with -O only when full strictness is on:
```
seq (id (\a -> seq a (\b -> (undefined::Int))) (undefined::Bool))
\a -> seq (seq a (\b -> seq b null) (undefined::([] ([] Int)) -> [] Int)) (\b -> ([]::[] Int)) length
\a -> seq (id (\b -> seq b (\c -> seq)) (length a)) ([]::[] Int)
```
Here are terms which are compiled too lazy with -O regardless of full strictness:
```
seq (seq (odd (undefined::Int)) (\a -> (undefined::[] (Int -> Bool))))
foldr (\a -> seq) id ((:) True (undefined::[] Bool))
\a -> foldr (\b -> \c -> seq c (\d -> ([]::[] Int))) (undefined::Bool -> [] Int) a False
\a -> (\b -> map (seq b id) (seq b ([]::[] Int))) (seq a (\b -> (undefined::([] Bool))))
map (seq (seq (seq 0 (undefined::Bool)) (\a -> \b -> (undefined::Bool)) (undefined::Int)))
map (seq (seq (id (\a -> (undefined::Int)) ([]::[] Int)) (\a -> undefined::Bool)))
\a -> (\b -> (:) (seq b 2) (b (undefined::Int) 0)) (seq a (\b -> (undefined::Int -> [] Int)))
```
To discover the differences, just run the terms (whose types are \[Int\] -\> \[Int\]) on some partially or fully-defined small lists.
It is possible to construct programs which exhibit space leaks only when optimisation is turned on using some of these terms (examples attached).
All programs have been tested with a pre-built GHC 7.1.20110606 on linux x86-64.
Is this a bug? Well, full laziness comes with a disclaimer that some expressions will get too lazy, but this happens even when we turn off full laziness, so it might be a legitimate bug.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------------ |
| Version | 7.1 |
| Type | Bug |
| TypeOfFailure | IncorrectResultAtRuntime |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Compiling with -O makes some expressions too lazy and causes space leaks","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.1","keywords":["laziness,","leak","space","strictness,"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Here are some expressions that are executed in a too lazy way when optimisation is turned on in GHC. GHC is known to make some expressions too lazy when full laziness is turned on (as in #917), and indeed some of these expressions execute correctly when you add -fno-full-laziness. However, some of them are compiled too lazy even if -fno-full-laziness is present.\r\n\r\nHere are terms that get compiled too lazy with -O only when full strictness is on:\r\n{{{\r\nseq (id (\\a -> seq a (\\b -> (undefined::Int))) (undefined::Bool))\r\n\\a -> seq (seq a (\\b -> seq b null) (undefined::([] ([] Int)) -> [] Int)) (\\b -> ([]::[] Int)) length\r\n\\a -> seq (id (\\b -> seq b (\\c -> seq)) (length a)) ([]::[] Int)\r\n}}}\r\n\r\nHere are terms which are compiled too lazy with -O regardless of full strictness:\r\n{{{\r\nseq (seq (odd (undefined::Int)) (\\a -> (undefined::[] (Int -> Bool))))\r\nfoldr (\\a -> seq) id ((:) True (undefined::[] Bool))\r\n\\a -> foldr (\\b -> \\c -> seq c (\\d -> ([]::[] Int))) (undefined::Bool -> [] Int) a False\r\n\\a -> (\\b -> map (seq b id) (seq b ([]::[] Int))) (seq a (\\b -> (undefined::([] Bool))))\r\nmap (seq (seq (seq 0 (undefined::Bool)) (\\a -> \\b -> (undefined::Bool)) (undefined::Int)))\r\nmap (seq (seq (id (\\a -> (undefined::Int)) ([]::[] Int)) (\\a -> undefined::Bool)))\r\n\\a -> (\\b -> (:) (seq b 2) (b (undefined::Int) 0)) (seq a (\\b -> (undefined::Int -> [] Int)))\r\n}}}\r\n\r\nTo discover the differences, just run the terms (whose types are [Int] -> [Int]) on some partially or fully-defined small lists.\r\n\r\nIt is possible to construct programs which exhibit space leaks only when optimisation is turned on using some of these terms (examples attached).\r\n\r\nAll programs have been tested with a pre-built GHC 7.1.20110606 on linux x86-64.\r\n\r\nIs this a bug? Well, full laziness comes with a disclaimer that some expressions will get too lazy, but this happens even when we turn off full laziness, so it might be a legitimate bug.","type_of_failure":"IncorrectResultAtRuntime","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/4942GHC.ConsoleHandler does not call back application when Close button is pressed2019-07-07T18:57:41ZAmaticGHC.ConsoleHandler does not call back application when Close button is pressedThe test program below is not called back by GHC.ConsoleHandler when the Close button is pressed during the threadDelay call. A message is written to console_event.log as expected when Ctrl-C or Ctrl-Break is pressed, but not when the Cl...The test program below is not called back by GHC.ConsoleHandler when the Close button is pressed during the threadDelay call. A message is written to console_event.log as expected when Ctrl-C or Ctrl-Break is pressed, but not when the Close button is pressed.
```
import Control.Concurrent (threadDelay)
import GHC.ConsoleHandler
import System.IO
onConsoleEventReceived :: ConsoleEvent -> IO ()
onConsoleEventReceived event = withFile "console_event.log" AppendMode $ \ file -> do
hPutStrLn file $ case event of
ControlC -> "Received Ctrl-C event"
Break -> "Received Ctrl-Break event"
Close -> "Received X button event"
_ -> "Received other console event"
hFlush file
main :: IO ()
main = installHandler (Catch onConsoleEventReceived) >> threadDelay (20*1000000)
```
The host OS is Windows XP SP3.
Please let me know if you need any more info.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.12.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHC API |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | lightwing15@hotmail.com |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC.ConsoleHandler does not call back application when Close button is pressed","status":"New","operating_system":"","component":"GHC API","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["lightwing15@hotmail.com"],"type":"Bug","description":"The test program below is not called back by GHC.ConsoleHandler when the Close button is pressed during the threadDelay call. A message is written to console_event.log as expected when Ctrl-C or Ctrl-Break is pressed, but not when the Close button is pressed.\r\n\r\n{{{\r\nimport Control.Concurrent (threadDelay)\r\nimport GHC.ConsoleHandler\r\nimport System.IO\r\n\r\nonConsoleEventReceived :: ConsoleEvent -> IO ()\r\nonConsoleEventReceived event = withFile \"console_event.log\" AppendMode $ \\ file -> do\r\n hPutStrLn file $ case event of\r\n ControlC -> \"Received Ctrl-C event\"\r\n Break -> \"Received Ctrl-Break event\"\r\n Close -> \"Received X button event\"\r\n _ -> \"Received other console event\"\r\n hFlush file\r\n \r\nmain :: IO ()\r\nmain = installHandler (Catch onConsoleEventReceived) >> threadDelay (20*1000000)\r\n}}}\r\n\r\nThe host OS is Windows XP SP3.\r\n\r\nPlease let me know if you need any more info.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/4413(^^) is not correct for Double and Float2019-07-07T18:59:07Zdaniel.is.fischer(^^) is not correct for Double and FloatConsider
```
Prelude> 2 ^^ (-1024)
0.0
Prelude> 0.5 ^^ 1024
5.562684646268003e-309
```
The cause is
```
x ^^ n = if n >= 0 then x^n else recip (x^(negate n))
```
If we change it to
```
x ^^ n = if n >= 0 then x^n...Consider
```
Prelude> 2 ^^ (-1024)
0.0
Prelude> 0.5 ^^ 1024
5.562684646268003e-309
```
The cause is
```
x ^^ n = if n >= 0 then x^n else recip (x^(negate n))
```
If we change it to
```
x ^^ n = if n >= 0 then x^n else ((recip x)^(negate n))
```
it'll do the right thing for Double and Float, and I don't know of any type where it would produce incorrect results.
Does it need a library proposal or can the change be made without?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.1 |
| 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":"(^^) is not correct for Double and Float","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.1","keywords":["Double,","Float,","exponentiation"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Consider\r\n{{{\r\nPrelude> 2 ^^ (-1024)\r\n0.0\r\nPrelude> 0.5 ^^ 1024\r\n5.562684646268003e-309\r\n}}}\r\nThe cause is\r\n{{{\r\nx ^^ n = if n >= 0 then x^n else recip (x^(negate n))\r\n}}}\r\nIf we change it to\r\n{{{\r\nx ^^ n = if n >= 0 then x^n else ((recip x)^(negate n))\r\n}}}\r\nit'll do the right thing for Double and Float, and I don't know of any type where it would produce incorrect results.\r\n\r\nDoes it need a library proposal or can the change be made without?","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1tcsavagetcsavagehttps://gitlab.haskell.org/ghc/ghc/-/issues/4215canonicalizePath behaves strangely with paths that do not exist2019-07-07T19:00:04ZcreswickcanonicalizePath behaves strangely with paths that do not existThe behavior of System.Directory.canonicalizePath is not documented (and perhaps not defined) for paths that do not exist on the file system. The documentation should, minimally, indicate that this is the case. Ideally, the behavior woul...The behavior of System.Directory.canonicalizePath is not documented (and perhaps not defined) for paths that do not exist on the file system. The documentation should, minimally, indicate that this is the case. Ideally, the behavior would be well-defined.
This is complicated by differing behaviors of the underlying realpath(char\*, char\*) function in Linux and OS X. On Linux, realpath changes its behavior if the last existing portion of the input path is a file vs. a directory, while OS X does not alter behavior in these two cases. Specifically, assume the following:
- $HOME/tmp/foo is a file.
- $HOME/tmp/bar is a directory.
- $HOME/tmp/baz does not exist.
Linux:
```
Prelude System.Directory> canonicalizePath "/home/creswick/tmp/foo/subdir"
"/home/creswick/tmp/foo"
Prelude System.Directory> canonicalizePath "/home/creswick/tmp/bar/subdir"
"/home/creswick/tmp/bar/subdir"
Prelude System.Directory> canonicalizePath "/home/creswick/tmp/baz/subdir"
"/home/creswick/tmp/baz"
```
OS-X:
```
Prelude System.Directory> canonicalizePath "/Users/hudson/tmp/foo/subdir"
"/Users/hudson/tmp/foo/subdir"
Prelude System.Directory> canonicalizePath "/Users/hudson/tmp/bar/subdir"
"/Users/hudson/tmp/bar/subdir"
Prelude System.Directory> canonicalizePath "/Users/hudson/tmp/baz/subdir"
"/Users/hudson/tmp/baz"
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------- |
| Version | 6.12.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/directory |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"canonicalizePath behaves strangely with paths that do not exist","status":"New","operating_system":"","component":"libraries/directory","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The behavior of System.Directory.canonicalizePath is not documented (and perhaps not defined) for paths that do not exist on the file system. The documentation should, minimally, indicate that this is the case. Ideally, the behavior would be well-defined.\r\n\r\nThis is complicated by differing behaviors of the underlying realpath(char*, char*) function in Linux and OS X. On Linux, realpath changes its behavior if the last existing portion of the input path is a file vs. a directory, while OS X does not alter behavior in these two cases. Specifically, assume the following:\r\n\r\n * $HOME/tmp/foo is a file.\r\n * $HOME/tmp/bar is a directory.\r\n * $HOME/tmp/baz does not exist.\r\n\r\nLinux:\r\n{{{\r\nPrelude System.Directory> canonicalizePath \"/home/creswick/tmp/foo/subdir\"\r\n\"/home/creswick/tmp/foo\"\r\nPrelude System.Directory> canonicalizePath \"/home/creswick/tmp/bar/subdir\"\r\n\"/home/creswick/tmp/bar/subdir\"\r\nPrelude System.Directory> canonicalizePath \"/home/creswick/tmp/baz/subdir\"\r\n\"/home/creswick/tmp/baz\"\r\n}}}\r\n\r\nOS-X:\r\n{{{\r\nPrelude System.Directory> canonicalizePath \"/Users/hudson/tmp/foo/subdir\" \r\n\"/Users/hudson/tmp/foo/subdir\"\r\nPrelude System.Directory> canonicalizePath \"/Users/hudson/tmp/bar/subdir\"\r\n\"/Users/hudson/tmp/bar/subdir\"\r\nPrelude System.Directory> canonicalizePath \"/Users/hudson/tmp/baz/subdir\"\r\n\"/Users/hudson/tmp/baz\"\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1Edward KmettEdward Kmetthttps://gitlab.haskell.org/ghc/ghc/-/issues/4049Support for ABI versioning of C libraries2019-07-07T19:00:57ZmpiechotkaSupport for ABI versioning of C librariesCurrently the SO files can be versioned - like in libgtk-x11-2.0.so.0. However GHC provides no support for such versioning which may cause problems if the ABI of library will change.
Also it does not provide any support for ldscripts an...Currently the SO files can be versioned - like in libgtk-x11-2.0.so.0. However GHC provides no support for such versioning which may cause problems if the ABI of library will change.
Also it does not provide any support for ldscripts and fails if it seeks for libz.so and only found is ldscript.
More informations:
http://bugs.gentoo.org/show_bug.cgi?id=290974
http://bugs.gentoo.org/show_bug.cgi?id=311361
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.12.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Support for ldscripts and ABI versioning","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Currently the SO files can be versioned - like in libgtk-x11-2.0.so.0. However GHC provides no support for such versioning which may cause problems if the ABI of library will change.\r\n\r\nAlso it does not provide any support for ldscripts and fails if it seeks for libz.so and only found is ldscript.\r\n\r\nMore informations:\r\nhttp://bugs.gentoo.org/show_bug.cgi?id=290974\r\nhttp://bugs.gentoo.org/show_bug.cgi?id=311361","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/2401aborting an STM transaction should throw an exception2019-07-07T19:08:45Zsclvaborting an STM transaction should throw an exceptionThe attached test case will hang at +RTS -N2 and above. As noted in the other ticket I submitted (http://hackage.haskell.org/trac/ghc/ticket/2398), this behavior happens on an Core 2 Quad with 64 bit architecture, and does not take place...The attached test case will hang at +RTS -N2 and above. As noted in the other ticket I submitted (http://hackage.haskell.org/trac/ghc/ticket/2398), this behavior happens on an Core 2 Quad with 64 bit architecture, and does not take place on a PowerPC with 32 bit architecture and no multicore.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.8.3 |
| 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":"unsafeIOToSTM hangs with 64 bit multicore.","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"The attached test case will hang at +RTS -N2 and above. As noted in the other ticket I submitted (http://hackage.haskell.org/trac/ghc/ticket/2398), this behavior happens on an Core 2 Quad with 64 bit architecture, and does not take place on a PowerPC with 32 bit architecture and no multicore.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1