GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2023-09-09T22:39:58Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/9817signal handlers in unix are passed garbage when using the signle threaded rts2023-09-09T22:39:58Zrednebsignal handlers in unix are passed garbage when using the signle threaded rtsWhen a signal handler (registered with `GHC.Conc.Signal.setHandler`) is called upon the receipt of the relevant signal, it is passed a memory buffer in the form of a `ForeignPtr Word8`. This buffer contains a copy of the `siginfo_t` stru...When a signal handler (registered with `GHC.Conc.Signal.setHandler`) is called upon the receipt of the relevant signal, it is passed a memory buffer in the form of a `ForeignPtr Word8`. This buffer contains a copy of the `siginfo_t` struct that was originally passed to the underlying os signal handler. Unfortunately, this only seems to work correctly in the threaded rts. In the single-threaded rts, the buffer contains garbage. This can be demonstrated by the following program:
```hs
import Control.Concurrent
import System.Posix.Signals
main :: IO ()
main = do
wait <- newEmptyMVar
_ <- flip (installHandler sig) Nothing $ CatchInfo $ \info -> do
putStrLn $ "Received a signal " ++ show (siginfoSignal info)
putMVar wait ()
raiseSignal sig
putStrLn $ "Sending myself a signal " ++ show sig
takeMVar wait
where
sig = sigUSR2
```
If you compile the program with the `-threaded` flag then everything works just fine:
```
Sending myself a signal 12
Received a signal 12
```
but without it, the signal handler will print a totaly random signal number:
```
Sending myself a signal 12
Received a signal 138644296
```
I was able to track this down to the function `startSignalHandlers` in `rts/posix/Signals.c`. This function (which is only used by the single threaded rts) allocates a buffer and copies the `siginfo_t` struct to it and then schedules `GHC.Conc.Signal.runHandlers` to be run in a new thread. The problem is that while `GHC.Conc.Signal.runHandlers` expects a `ForeignPtr Word8`, here it is given a `Ptr Word8`. This has two implications: the signal handler is given invalid data, and nobody is deallocating the buffer so we are leaking memory every time a signal is received that has a custom handler.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.8.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | simonmar |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"signal handlers in unix are passed garbage when using the signle threaded rts","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"simonmar"},"version":"7.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["simonmar"],"type":"Bug","description":"When a signal handler (registered with `GHC.Conc.Signal.setHandler`) is called upon the receipt of the relevant signal, it is passed a memory buffer in the form of a `ForeignPtr Word8`. This buffer contains a copy of the `siginfo_t` struct that was originally passed to the underlying os signal handler. Unfortunately, this only seems to work correctly in the threaded rts. In the single-threaded rts, the buffer contains garbage. This can be demonstrated by the following program:\r\n\r\n{{{#!hs\r\nimport Control.Concurrent\r\nimport System.Posix.Signals\r\n\r\nmain :: IO ()\r\nmain = do\r\n wait <- newEmptyMVar\r\n _ <- flip (installHandler sig) Nothing $ CatchInfo $ \\info -> do\r\n putStrLn $ \"Received a signal \" ++ show (siginfoSignal info)\r\n putMVar wait ()\r\n raiseSignal sig\r\n putStrLn $ \"Sending myself a signal \" ++ show sig\r\n takeMVar wait\r\n where\r\n sig = sigUSR2\r\n}}}\r\n\r\nIf you compile the program with the `-threaded` flag then everything works just fine:\r\n{{{\r\nSending myself a signal 12\r\nReceived a signal 12\r\n}}}\r\nbut without it, the signal handler will print a totaly random signal number:\r\n{{{\r\nSending myself a signal 12\r\nReceived a signal 138644296\r\n}}}\r\n\r\nI was able to track this down to the function `startSignalHandlers` in `rts/posix/Signals.c`. This function (which is only used by the single threaded rts) allocates a buffer and copies the `siginfo_t` struct to it and then schedules `GHC.Conc.Signal.runHandlers` to be run in a new thread. The problem is that while `GHC.Conc.Signal.runHandlers` expects a `ForeignPtr Word8`, here it is given a `Ptr Word8`. This has two implications: the signal handler is given invalid data, and nobody is deallocating the buffer so we are leaking memory every time a signal is received that has a custom handler.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.4Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/9783Pattern synonym matcher is unnecessarily strict on unboxed continuations2019-07-07T18:39:03ZGergő ÉrdiPattern synonym matcher is unnecessarily strict on unboxed continuationsAs discovered while investigating #9732, if you have something like
```
{-# LANGUAGE PatternSynonyms, MagicHash #-}
import GHC.Base
pattern P = True
f :: Bool -> Int#
f P = 42#
```
`f` is compiled into
```
Main.f :: GHC.Types.Bool -...As discovered while investigating #9732, if you have something like
```
{-# LANGUAGE PatternSynonyms, MagicHash #-}
import GHC.Base
pattern P = True
f :: Bool -> Int#
f P = 42#
```
`f` is compiled into
```
Main.f :: GHC.Types.Bool -> GHC.Prim.Int#
[LclIdX, Str=DmdType]
Main.f =
letrec {
f_apU :: GHC.Types.Bool -> GHC.Prim.Int#
[LclId, Str=DmdType]
f_apU =
\ (ds_dq1 :: GHC.Types.Bool) ->
break<2>()
let {
fail_dq2 :: GHC.Prim.Void# -> GHC.Prim.Int#
[LclId, Str=DmdType]
fail_dq2 =
\ (ds_dq3 [OS=OneShot] :: GHC.Prim.Void#) ->
Control.Exception.Base.patError
@ GHC.Prim.Int# "unboxed.hs:7:1-9|function f"# } in
case fail_dq2 GHC.Prim.void# of wild_00 { __DEFAULT ->
(case break<1>() 42 of wild_00 { __DEFAULT ->
Main.$mP @ GHC.Prim.Int# ds_dq1 wild_00
})
wild_00
}; } in
f_apU
```
Note how `fail_dq2` is applied on `void#` _before_ the pattern match, meaning the following expression:
```
I# (f True)
```
will fail with
```
*** Exception: unboxed.hs:7:1-9: Non-exhaustive patterns in function f
```
This is because the the type of `P`'s matcher, instantiated for its use in `f`, is
```
$mP :: Bool -> Int# -> Int# -> Int#
```
so of course it is strict both on the success and the failure continuation.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.8.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Pattern synonym matcher is unnecessarily strict on unboxed continuations","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"7.10.1","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"cactus"},"version":"7.8.3","keywords":["pattern","synonyms"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"As discovered while investigating #9732, if you have something like\r\n\r\n{{{\r\n{-# LANGUAGE PatternSynonyms, MagicHash #-}\r\nimport GHC.Base\r\n\r\npattern P = True\r\n\r\nf :: Bool -> Int#\r\nf P = 42#\r\n}}}\r\n\r\n`f` is compiled into\r\n\r\n{{{\r\nMain.f :: GHC.Types.Bool -> GHC.Prim.Int#\r\n[LclIdX, Str=DmdType]\r\nMain.f =\r\n letrec {\r\n f_apU :: GHC.Types.Bool -> GHC.Prim.Int#\r\n [LclId, Str=DmdType]\r\n f_apU =\r\n \\ (ds_dq1 :: GHC.Types.Bool) ->\r\n break<2>()\r\n let {\r\n fail_dq2 :: GHC.Prim.Void# -> GHC.Prim.Int#\r\n [LclId, Str=DmdType]\r\n fail_dq2 =\r\n \\ (ds_dq3 [OS=OneShot] :: GHC.Prim.Void#) ->\r\n Control.Exception.Base.patError\r\n @ GHC.Prim.Int# \"unboxed.hs:7:1-9|function f\"# } in\r\n case fail_dq2 GHC.Prim.void# of wild_00 { __DEFAULT ->\r\n (case break<1>() 42 of wild_00 { __DEFAULT ->\r\n Main.$mP @ GHC.Prim.Int# ds_dq1 wild_00\r\n })\r\n wild_00\r\n }; } in\r\n f_apU\r\n}}}\r\n\r\nNote how `fail_dq2` is applied on `void#` _before_ the pattern match, meaning the following expression:\r\n\r\n{{{\r\nI# (f True)\r\n}}}\r\n\r\nwill fail with\r\n\r\n{{{\r\n*** Exception: unboxed.hs:7:1-9: Non-exhaustive patterns in function f\r\n}}}\r\n\r\nThis is because the the type of `P`'s matcher, instantiated for its use in `f`, is\r\n\r\n{{{\r\n$mP :: Bool -> Int# -> Int# -> Int#\r\n}}}\r\n\r\nso of course it is strict both on the success and the failure continuation.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1Gergő ÉrdiGergő Érdihttps://gitlab.haskell.org/ghc/ghc/-/issues/9765Strange behavior of GC under ghci2019-07-07T18:39:08ZremdezxStrange behavior of GC under ghciReleasing the result of `newForeignPtr nullFunPtr nullPtr` end in core dump, due to the fact that finalizer function is set to null pointer.
When I run something like this in GHCI:
```hs
> import System.Mem
> import Foreign.Ptr
> impo...Releasing the result of `newForeignPtr nullFunPtr nullPtr` end in core dump, due to the fact that finalizer function is set to null pointer.
When I run something like this in GHCI:
```hs
> import System.Mem
> import Foreign.Ptr
> import Foreign.ForeignPtr
> import System.IO.Unsafe
> import qualified Data.Map as Map
> a <- return $ Map.singleton 1 (unsafePerformIO $ newForeignPtr nullFunPtr nullPtr)
Loading package array-0.5.0.0 ... linking ... done.
Loading package deepseq-1.3.0.2 ... linking ... done.
Loading package containers-0.5.5.1 ... linking ... done.
> print a
fromList [(1,0x0000000000000000)]
> performGC
> ^D
Leaving GHCi.
[1] 3782 segmentation fault (core dumped) ghci
```
it wont crash until exit from ghci which is correct. But if I do something similar but using `let` binding it will crash even if variable `a` didn't lose its scope
```hs
> import System.Mem
> import Foreign.Ptr
> import Foreign.ForeignPtr
> import System.IO.Unsafe
> import qualified Data.Map as Map
> let a = Map.singleton 1 (unsafePerformIO $ newForeignPtr nullFunPtr nullPtr)
Loading package array-0.5.0.0 ... linking ... done.
Loading package deepseq-1.3.0.2 ... linking ... done.
Loading package containers-0.5.5.1 ... linking ... done.
> print a
fromList [(1,0x0000000000000000)]
[1] 3842 segmentation fault (core dumped) ghci
```
Why is there a difference between doing it with `do` notation and with `let` binding?
I also expected that if I rebind variable `a` it will lose it's scope and will be released but it is not (see below)
```hs
> import System.Mem
> import Foreign.Ptr
> import Foreign.ForeignPtr
> import System.IO.Unsafe
> import qualified Data.Map as Map
> a <- return $ Map.singleton 1 (unsafePerformIO $ newForeignPtr nullFunPtr nullPtr)
Loading package array-0.5.0.0 ... linking ... done.
Loading package deepseq-1.3.0.2 ... linking ... done.
Loading package containers-0.5.5.1 ... linking ... done.
> print a
fromList [(1,0x0000000000000000)]
> a <- return () -- rebinding varable a, it is no longer used
> performGC
> -- no crash, varaible a not released
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | hvr |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Strange behavior of GC under ghci","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["hvr"],"type":"Bug","description":"Releasing the result of `newForeignPtr nullFunPtr nullPtr` end in core dump, due to the fact that finalizer function is set to null pointer.\r\n\r\nWhen I run something like this in GHCI:\r\n{{{#!hs\r\n> import System.Mem\r\n> import Foreign.Ptr \r\n> import Foreign.ForeignPtr\r\n> import System.IO.Unsafe\r\n> import qualified Data.Map as Map\r\n> a <- return $ Map.singleton 1 (unsafePerformIO $ newForeignPtr nullFunPtr nullPtr)\r\nLoading package array-0.5.0.0 ... linking ... done.\r\nLoading package deepseq-1.3.0.2 ... linking ... done.\r\nLoading package containers-0.5.5.1 ... linking ... done.\r\n> print a\r\nfromList [(1,0x0000000000000000)]\r\n> performGC\r\n> ^D\r\nLeaving GHCi.\r\n[1] 3782 segmentation fault (core dumped) ghci\r\n}}}\r\n\r\nit wont crash until exit from ghci which is correct. But if I do something similar but using `let` binding it will crash even if variable `a` didn't lose its scope\r\n{{{#!hs\r\n> import System.Mem\r\n> import Foreign.Ptr \r\n> import Foreign.ForeignPtr\r\n> import System.IO.Unsafe\r\n> import qualified Data.Map as Map\r\n> let a = Map.singleton 1 (unsafePerformIO $ newForeignPtr nullFunPtr nullPtr)\r\nLoading package array-0.5.0.0 ... linking ... done.\r\nLoading package deepseq-1.3.0.2 ... linking ... done.\r\nLoading package containers-0.5.5.1 ... linking ... done.\r\n> print a\r\nfromList [(1,0x0000000000000000)]\r\n[1] 3842 segmentation fault (core dumped) ghci\r\n}}}\r\n\r\nWhy is there a difference between doing it with `do` notation and with `let` binding?\r\n\r\nI also expected that if I rebind variable `a` it will lose it's scope and will be released but it is not (see below)\r\n{{{#!hs\r\n> import System.Mem\r\n> import Foreign.Ptr \r\n> import Foreign.ForeignPtr\r\n> import System.IO.Unsafe\r\n> import qualified Data.Map as Map\r\n> a <- return $ Map.singleton 1 (unsafePerformIO $ newForeignPtr nullFunPtr nullPtr)\r\nLoading package array-0.5.0.0 ... linking ... done.\r\nLoading package deepseq-1.3.0.2 ... linking ... done.\r\nLoading package containers-0.5.5.1 ... linking ... done.\r\n> print a\r\nfromList [(1,0x0000000000000000)]\r\n> a <- return () -- rebinding varable a, it is no longer used\r\n> performGC\r\n> -- no crash, varaible a not released\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/9752Output unicode characters on Windows2019-07-07T18:39:12ZpokiakaOutput unicode characters on WindowsOn Windows, when having an error with a unicode symbol lurking around, GHC fails to print its name.
So e.g. you get a message of an error "In the first argument of (\<stderr\>: commitBuffer: invalid argument (invalid character)".
I am n...On Windows, when having an error with a unicode symbol lurking around, GHC fails to print its name.
So e.g. you get a message of an error "In the first argument of (\<stderr\>: commitBuffer: invalid argument (invalid character)".
I am not certain, but I think that the fix would be to `hSetEncoding stderr utf8` before the output is printed. If so, hopefully it should be a quick easy fix.
(And perhaps it would be appropriate to do the same for stdout as-well).https://gitlab.haskell.org/ghc/ghc/-/issues/9668Unicode info is out of date2019-07-07T18:39:34ZDavid FeuerUnicode info is out of dateThe automatically generated `WCsubst.c` was last generated in 2011. The Unicode standard has been updated several times since then. I would like to try to replace that whole mechanism with something a little more cache-friendly, but at t...The automatically generated `WCsubst.c` was last generated in 2011. The Unicode standard has been updated several times since then. I would like to try to replace that whole mechanism with something a little more cache-friendly, but at the very least the tables need to be right. Unfortunately, the script that generates this file gives no information about its input format, or just where a file with the right format is supposed to come from.7.10.1Edward KmettEdward Kmetthttps://gitlab.haskell.org/ghc/ghc/-/issues/9616Incorrect numbers from HpcMarkup.markup_plugin2019-07-07T18:39:48ZDavid FeuerIncorrect numbers from HpcMarkup.markup_plugin`showBigNum` in the `openTick` function accidentally puts 0s in the wrong place when formatting large numbers. 12345 will be formatted as 120,345 instead of 012,345. The correct answer is probably to add some locale-specific numeric form...`showBigNum` in the `openTick` function accidentally puts 0s in the wrong place when formatting large numbers. 12345 will be formatted as 120,345 instead of 012,345. The correct answer is probably to add some locale-specific numeric formatting stuff somewhere, but until then, I'll just fix this.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 7.9 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Code Coverage |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Incorrect numbers from HpcMarkup.markup_plugin","status":"New","operating_system":"","component":"Code Coverage","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.9","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"`showBigNum` in the `openTick` function accidentally puts 0s in the wrong place when formatting large numbers. 12345 will be formatted as 120,345 instead of 012,345. The correct answer is probably to add some locale-specific numeric formatting stuff somewhere, but until then, I'll just fix this.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/9603getArgs path transformation is broken on Windows2019-07-07T18:39:51ZgintasgetArgs path transformation is broken on WindowsIt looks like System.Environment.getArgs is trying to be smart on Windows and to transform arguments drive paths to environment-local paths (e.g., 'C:/' =\> 'C:\\msys64', but it messes up the mangling somewhere if the path is not at the ...It looks like System.Environment.getArgs is trying to be smart on Windows and to transform arguments drive paths to environment-local paths (e.g., 'C:/' =\> 'C:\\msys64', but it messes up the mangling somewhere if the path is not at the beginning of the argument:
$ args "C:/"
\["C:/"\]
$ /tmp/args " C:/"
\[" C;C:\\\\msys64"\]
Note the leading "C;" which makes no sense.
$ uname -s
MINGW64_NT-6.3
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.9 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ekmett, hvr |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"getArgs path transformation is broken on Windows","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.9","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ekmett","hvr"],"type":"Bug","description":"It looks like System.Environment.getArgs is trying to be smart on Windows and to transform arguments drive paths to environment-local paths (e.g., 'C:/' => 'C:\\msys64', but it messes up the mangling somewhere if the path is not at the beginning of the argument:\r\n\r\n$ args \"C:/\"\r\n[\"C:/\"]\r\n\r\n$ /tmp/args \" C:/\"\r\n[\" C;C:\\\\msys64\"]\r\n\r\nNote the leading \"C;\" which makes no sense.\r\n\r\n$ uname -s\r\nMINGW64_NT-6.3\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/9564Floating point subnormals overrounded on output2019-07-07T18:40:00Zjrp2014Floating point subnormals overrounded on outputThe following test suggests that GHC is overrounding Float subnormals, when printing them out
```
Prelude> 2**(-149)
1.401298464324817e-45
Prelude> 2**(-149) :: Float
1.0e-45
Prelude> isDenormalized it
True
Prelude>
Prelude> 2**(-149) *...The following test suggests that GHC is overrounding Float subnormals, when printing them out
```
Prelude> 2**(-149)
1.401298464324817e-45
Prelude> 2**(-149) :: Float
1.0e-45
Prelude> isDenormalized it
True
Prelude>
Prelude> 2**(-149) * 2**(100) * 2**(49) :: Float
1.0
```
By comparison
```
#include <stdio.h>
#include <stdlib.h>
int main (void)
{
float clang_dec, clang_hex, libc_dec, libc_hex;
clang_dec = 1.401298464324817e-45;
clang_hex = 0x0.000002P-126;
printf("clang (from decimal) = %a\n",clang_dec);
printf("clang (from decimal) = %g\n",clang_dec);
printf("clang (from hex) = %a\n",clang_hex);
printf("clang (from hex) = %g\n",clang_hex);
libc_dec = strtod("1.401298464324817e-45",NULL);
libc_hex = strtod("0x0.000002P-126",NULL);
printf("libc (from decimal) = %a\n",libc_dec);
printf("libc (from decimal) = %g\n",libc_dec);
printf("libc (from hex) = %a\n",libc_hex);
printf("libc (from hex) = %g\n",libc_hex);
}
```
produces
```
clang (from decimal) = 0x1p-149
clang (from decimal) = 1.4013e-45
clang (from hex) = 0x1p-149
clang (from hex) = 1.4013e-45
libc (from decimal) = 0x1p-149
libc (from decimal) = 1.4013e-45
libc (from hex) = 0x1p-149
libc (from hex) = 1.4013e-45
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.8.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | simonmar |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Floating point subnormals overrounded on output","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"simonmar"},"version":"7.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["simonmar"],"type":"Bug","description":"The following test suggests that GHC is overrounding Float subnormals, when printing them out\r\n{{{\r\nPrelude> 2**(-149)\r\n1.401298464324817e-45\r\nPrelude> 2**(-149) :: Float\r\n1.0e-45\r\nPrelude> isDenormalized it\r\nTrue\r\nPrelude>\r\nPrelude> 2**(-149) * 2**(100) * 2**(49) :: Float\r\n1.0\r\n}}}\r\n\r\n\r\nBy comparison\r\n\r\n\r\n{{{\r\n#include <stdio.h>\r\n#include <stdlib.h>\r\n\r\nint main (void)\r\n{\r\n float clang_dec, clang_hex, libc_dec, libc_hex;\r\n\r\n clang_dec = 1.401298464324817e-45;\r\n clang_hex = 0x0.000002P-126;\r\n printf(\"clang (from decimal) = %a\\n\",clang_dec);\r\n printf(\"clang (from decimal) = %g\\n\",clang_dec);\r\n printf(\"clang (from hex) = %a\\n\",clang_hex);\r\n printf(\"clang (from hex) = %g\\n\",clang_hex);\r\n\r\n libc_dec = strtod(\"1.401298464324817e-45\",NULL);\r\n libc_hex = strtod(\"0x0.000002P-126\",NULL);\r\n printf(\"libc (from decimal) = %a\\n\",libc_dec);\r\n printf(\"libc (from decimal) = %g\\n\",libc_dec);\r\n printf(\"libc (from hex) = %a\\n\",libc_hex);\r\n printf(\"libc (from hex) = %g\\n\",libc_hex);\r\n}\r\n\r\n}}}\r\n\r\nproduces\r\n\r\n\r\n{{{\r\nclang (from decimal) = 0x1p-149\r\nclang (from decimal) = 1.4013e-45\r\nclang (from hex) = 0x1p-149\r\nclang (from hex) = 1.4013e-45\r\nlibc (from decimal) = 0x1p-149\r\nlibc (from decimal) = 1.4013e-45\r\nlibc (from hex) = 0x1p-149\r\nlibc (from hex) = 1.4013e-45\r\n\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/9534IEEE Standard 754 for Binary Floating-Point Arithmetic by Prof. W. Kahan, UCB2019-07-07T18:40:07Zjrp2014IEEE Standard 754 for Binary Floating-Point Arithmetic by Prof. W. Kahan, UCBThe attached is an implementation of the floating point accuracy test described in *The Baleful Influence of Benchmarks* section of http://www.eecs.berkeley.edu/\~wkahan/ieee754status/IEEE754.PDF
```
Results for Float:
r = 4098.0 produc...The attached is an implementation of the floating point accuracy test described in *The Baleful Influence of Benchmarks* section of http://www.eecs.berkeley.edu/\~wkahan/ieee754status/IEEE754.PDF
```
Results for Float:
r = 4098.0 produces 12.0 and 12.0 sig. bits
r = 4098.25 fails: root 0.99989897 isn't at least 1 <<<<
r = 4097.004 produces 12.0 and 11.999298 sig. bits
:
Worst accuracy is 11.999298 sig. bits
:
Results for Double:
r = 4098.0 produces Infinity and Infinity sig. bits
r = 4098.25 produces Infinity and 53.0 sig. bits
r = 4097.00390625 produces Infinity and 53.451178091541244 sig. bits
r = 1.6777218e7 produces Infinity and Infinity sig. bits
r = 1.677721825e7 produces Infinity and 75.0 sig. bits
r = 1.6777219e7 produces Infinity and 71.0 sig. bits
r = 9.4906267e7 produces 26.499999994288153 and 26.499999986733027 sig. bits
r = 9.490626725e7 fails: root 0.999999995635551 isn't at least 1 <<<
r = 2.684354505e8 produces 28.0 and 27.999999919383132 sig. bits
r = 2.684354515e8 produces 28.0 and 27.99999993013205 sig. bits
r = 2.68435458e8 produces 28.0 and 28.0 sig. bits
r = 2.6843545825e8 produces 28.0 and 28.00000000268723 sig. bits
r = 2.6843545700000006e8 produces 28.0 and 27.999999989251084 sig. bits
r = 4.294967298e9 produces 32.0 and 32.0 sig. bits
r = 4.29496729825e9 produces 32.0 and 32.00000000016795 sig. bits
Worst accuracy is 26.499999986733027 sig. bits
```
This seems to be comparable to a clang version, but seems to be fairly poor in comparison to some other machines, back in the day (1997).
**The attached could, possibly be turned into a testsuite test, by removing the QuickCheck tests that are included.**
Observations:
- There are a couple of failures (could be the implementation of sqrt or log).
- signum seems incorrect (signum Nan = -1.0)
- The prelude should have a copysign function
- min fails to produce the other argument if one argument is NaN
- The CFloat and CDouble variants seem to produce the same result as the native Float and Double versions
- The Haskell coding style could be improved to remove some boilerplate, make the code more idiomatic
- There may be a better way of entering the test values of r to ensure that they are accurate
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.3 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Test Suite |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"IEEE Standard 754 for Binary Floating-Point Arithmetic by Prof. W. Kahan, UCB","status":"New","operating_system":"","component":"Test Suite","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.3","keywords":["IEEE754"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"The attached is an implementation of the floating point accuracy test described in ''The Baleful Influence of Benchmarks'' section of http://www.eecs.berkeley.edu/~wkahan/ieee754status/IEEE754.PDF\r\n\r\n\r\n{{{\r\nResults for Float:\r\nr = 4098.0 produces 12.0 and 12.0 sig. bits\r\nr = 4098.25 fails: root 0.99989897 isn't at least 1 <<<<\r\nr = 4097.004 produces 12.0 and 11.999298 sig. bits\r\n:\r\nWorst accuracy is 11.999298 sig. bits\r\n\r\n:\r\n\r\nResults for Double:\r\nr = 4098.0 produces Infinity and Infinity sig. bits\r\nr = 4098.25 produces Infinity and 53.0 sig. bits\r\nr = 4097.00390625 produces Infinity and 53.451178091541244 sig. bits\r\nr = 1.6777218e7 produces Infinity and Infinity sig. bits\r\nr = 1.677721825e7 produces Infinity and 75.0 sig. bits\r\nr = 1.6777219e7 produces Infinity and 71.0 sig. bits\r\nr = 9.4906267e7 produces 26.499999994288153 and 26.499999986733027 sig. bits\r\nr = 9.490626725e7 fails: root 0.999999995635551 isn't at least 1 <<<\r\nr = 2.684354505e8 produces 28.0 and 27.999999919383132 sig. bits\r\nr = 2.684354515e8 produces 28.0 and 27.99999993013205 sig. bits\r\nr = 2.68435458e8 produces 28.0 and 28.0 sig. bits\r\nr = 2.6843545825e8 produces 28.0 and 28.00000000268723 sig. bits\r\nr = 2.6843545700000006e8 produces 28.0 and 27.999999989251084 sig. bits\r\nr = 4.294967298e9 produces 32.0 and 32.0 sig. bits\r\nr = 4.29496729825e9 produces 32.0 and 32.00000000016795 sig. bits\r\nWorst accuracy is 26.499999986733027 sig. bits\r\n}}}\r\n\r\nThis seems to be comparable to a clang version, but seems to be fairly poor in comparison to some other machines, back in the day (1997).\r\n\r\n'''The attached could, possibly be turned into a testsuite test, by removing the QuickCheck tests that are included.'''\r\n\r\nObservations:\r\n\r\n* There are a couple of failures (could be the implementation of sqrt or log). \r\n* signum seems incorrect (signum Nan = -1.0)\r\n* The prelude should have a copysign function\r\n* min fails to produce the other argument if one argument is NaN\r\n* The CFloat and CDouble variants seem to produce the same result as the native Float and Double versions\r\n* The Haskell coding style could be improved to remove some boilerplate, make the code more idiomatic\r\n* There may be a better way of entering the test values of r to ensure that they are accurate\r\n\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/9530min / max do not always return the other argument when one of the arguments i...2019-07-07T18:40:08Zjrp2014min / max do not always return the other argument when one of the arguments is NaNI assume that this is well-known, but it tripped me up:
```
Prelude> let inf = 1/0
Prelude> let nan = 0/0
Prelude> min nan inf
Infinity
Prelude> min inf nan
NaN
Prelude> min 3 nan
NaN
Prelude> min nan 3
3.0
Prelude> max nan inf
NaN
Pre...I assume that this is well-known, but it tripped me up:
```
Prelude> let inf = 1/0
Prelude> let nan = 0/0
Prelude> min nan inf
Infinity
Prelude> min inf nan
NaN
Prelude> min 3 nan
NaN
Prelude> min nan 3
3.0
Prelude> max nan inf
NaN
Prelude> max inf nan
Infinity
Prelude> max 3 nan
3.0
Prelude> max nan 3
NaN
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Prelude |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"min / max do not always return a NaN when one of the arguments is NaN","status":"New","operating_system":"","component":"Prelude","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I assume that this is well-known, but it tripped me up:\r\n\r\n{{{\r\nPrelude> let inf = 1/0\r\nPrelude> let nan = 0/0\r\nPrelude> min nan inf\r\nInfinity\r\nPrelude> min inf nan\r\nNaN\r\nPrelude> min 3 nan\r\nNaN\r\nPrelude> min nan 3\r\n3.0\r\nPrelude> max nan inf\r\nNaN\r\nPrelude> max inf nan\r\nInfinity\r\nPrelude> max 3 nan\r\n3.0\r\nPrelude> max nan 3\r\nNaN\r\n\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/9525+RTS -xc stack trace sometimes reported twice2019-07-07T18:40:10ZÖmer Sinan Ağacan+RTS -xc stack trace sometimes reported twiceNot sure if really a bug but just wanted to show. If this is a bug I'm hoping to fix this myself but I may need some guidance.
Stack trace reported by `+RTS -xc` is sometimes printed twice. This program reports it only once, as expected...Not sure if really a bug but just wanted to show. If this is a bug I'm hoping to fix this myself but I may need some guidance.
Stack trace reported by `+RTS -xc` is sometimes printed twice. This program reports it only once, as expected:
```haskell
f :: Int -> Int
f = error "hello"
main = print (f 20)
```
```
➜ ghc_patch ./error +RTS -xc
*** Exception (reporting due to +RTS -xc): (THUNK_1_0), stack trace:
Main.f,
called from Main.CAF
--> evaluated by: Main.main,
called from Main.CAF
error: hello
```
But if I change it to this:
```haskell
f :: Int -> Int
f x =
let x = x + 20
in x
main = print (f 20)
```
Stack trace is reported twice:
```
➜ ghc_patch ./error +RTS -xc
*** Exception (reporting due to +RTS -xc): (THUNK_STATIC), stack trace:
Main.f.x,
called from Main.f,
called from Main.main,
called from Main.CAF
*** Exception (reporting due to +RTS -xc): (THUNK_STATIC), stack trace:
Main.f.x,
called from Main.f,
called from Main.main,
called from Main.CAF
error: <<loop>>
```
Can anyone confirm that this is really a bug?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.8.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | simonmar |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"+RTS -xc stack trace sometimes reported twice","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"osa1"},"version":"7.8.3","keywords":["error","profiling,","stack","trace,"],"differentials":[],"test_case":"","architecture":"","cc":["simonmar"],"type":"Bug","description":"Not sure if really a bug but just wanted to show. If this is a bug I'm hoping to fix this myself but I may need some guidance.\r\n\r\nStack trace reported by `+RTS -xc` is sometimes printed twice. This program reports it only once, as expected:\r\n\r\n{{{#!haskell\r\nf :: Int -> Int\r\nf = error \"hello\"\r\n\r\nmain = print (f 20)\r\n}}}\r\n\r\n{{{\r\n➜ ghc_patch ./error +RTS -xc \r\n*** Exception (reporting due to +RTS -xc): (THUNK_1_0), stack trace: \r\n Main.f,\r\n called from Main.CAF\r\n --> evaluated by: Main.main,\r\n called from Main.CAF\r\nerror: hello\r\n}}}\r\n\r\nBut if I change it to this:\r\n\r\n{{{#!haskell\r\nf :: Int -> Int\r\nf x =\r\n let x = x + 20\r\n in x\r\n\r\nmain = print (f 20)\r\n}}}\r\n\r\nStack trace is reported twice:\r\n\r\n{{{\r\n➜ ghc_patch ./error +RTS -xc \r\n*** Exception (reporting due to +RTS -xc): (THUNK_STATIC), stack trace: \r\n Main.f.x,\r\n called from Main.f,\r\n called from Main.main,\r\n called from Main.CAF\r\n*** Exception (reporting due to +RTS -xc): (THUNK_STATIC), stack trace: \r\n Main.f.x,\r\n called from Main.f,\r\n called from Main.main,\r\n called from Main.CAF\r\nerror: <<loop>>\r\n}}}\r\n\r\nCan anyone confirm that this is really a bug?","type_of_failure":"OtherFailure","blocking":[]} -->Ömer Sinan AğacanÖmer Sinan Ağacanhttps://gitlab.haskell.org/ghc/ghc/-/issues/9504LLVM backend TBAA is too aggressive2019-07-07T18:40:15ZrwbartonLLVM backend TBAA is too aggressiveAt https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/Backends/LLVM/Alias\#HowtoTrackTBAAinformation there is written
> It \[a memory load/store\] is very rarely of the form:
>
> ```
> x = Sp + 8
> I64[x] = ...
> ```
>
> And when...At https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/Backends/LLVM/Alias\#HowtoTrackTBAAinformation there is written
> It \[a memory load/store\] is very rarely of the form:
>
> ```
> x = Sp + 8
> I64[x] = ...
> ```
>
> And when it is, 'it is' (unconfirmed) always deriving a "heap" pointer, "stack" pointers are always of the in-line variety.
In fact commit e10589a505b44f4f0394500c6a0d2db5baa7f3f4 treats any memory access through a Cmm local variable as having the "other" type, which cannot alias any non-"other" address.
But it turns out that a Cmm local might be either an offset from Sp (#9125, though TBAA doesn't seem to have been the cause of the bad code there) or an offset from a Cmm global variable (#9308). In general, we don't know anything about what it might be so we should conservatively use the "top" "type".
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | --------------- |
| Version | 7.8.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (LLVM) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"LLVM backend TBAA is too aggressive","status":"New","operating_system":"","component":"Compiler (LLVM)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"At https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/Backends/LLVM/Alias#HowtoTrackTBAAinformation there is written\r\n\r\n> It [a memory load/store] is very rarely of the form:\r\n> {{{\r\n> x = Sp + 8\r\n> I64[x] = ...\r\n> }}}\r\n> And when it is, 'it is' (unconfirmed) always deriving a \"heap\" pointer, \"stack\" pointers are always of the in-line variety.\r\n\r\nIn fact commit e10589a505b44f4f0394500c6a0d2db5baa7f3f4 treats any memory access through a Cmm local variable as having the \"other\" type, which cannot alias any non-\"other\" address.\r\n\r\nBut it turns out that a Cmm local might be either an offset from Sp (#9125, though TBAA doesn't seem to have been the cause of the bad code there) or an offset from a Cmm global variable (#9308). In general, we don't know anything about what it might be so we should conservatively use the \"top\" \"type\".","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/9494Probable data corruption with GHCi 7.8.* and Zlib2019-07-07T18:40:17Znominolo@gmail.comProbable data corruption with GHCi 7.8.* and ZlibThe following program causes Zlib data corruption errors when run from inside GHCi. It launches two threads which then concurrently read a file, compress it, and immediately decompress it. You need libraries `zlib`, `SHA`, and `async`.
...The following program causes Zlib data corruption errors when run from inside GHCi. It launches two threads which then concurrently read a file, compress it, and immediately decompress it. You need libraries `zlib`, `SHA`, and `async`.
```
module Main where
import qualified Codec.Compression.Zlib as Zlib
import qualified Data.ByteString.Lazy as BL
import qualified Data.ByteString.Internal as BI
import Control.Exception (bracket)
import Control.Concurrent
import Control.Monad
import Control.Exception ( evaluate)
import Data.Digest.Pure.SHA ( sha1) -- from the 'SHA' package
import Control.Concurrent.Async ( mapConcurrently)
import System.Mem ( performGC )
import Debug.Trace
test :: Int -> IO String
test _ = do
tid <- myThreadId
-- testdata is: dd if=/dev/urandom of=/tmp/testdata bs=100k count=100
-- Could also be replaced by: (BL.take (10^7) "/dev/urandom")
dat <- BL.readFile "/tmp/testdata"
let cbuf = Zlib.compress $ traceChunks tid $ dat
s <- evaluate $ sha1 $ Zlib.decompress $ cbuf
return $ show s
where
-- We used this to check whether buffers were reused by different threads, but that
-- doesn't seem to be the case. Removing the call to traceChunks, however, makes it
-- harder to reproduce possibly because of scheduler effects. In a much larger program
-- it could be reproduced more easily without the trace, but in this small example
-- tracing seems to cause the right amount of nondeterminism.
traceChunks tid bs =
BL.fromChunks
$ zipWith (\n x -> trace (show tid ++ ":" ++ showBS x) x) [1..]
$ BL.toChunks bs
showBS (BI.PS ptr off len) = show ptr
main = do
r <- withGCThread $ mapConcurrently (test) ([1..2] :: [Int])
putStrLn $ show $ r
where
-- Regularly forcing the GC makes the test-case more reproducible.
withGCThread io =
bracket (forkIO $ forever $ performGC >> threadDelay 1000)
killThread
(const io)
```
The output should be something like:
```
...
ThreadId 51:0x00000001091ee010
ThreadId 49:0x00000001091a7010
...
ThreadId 49:0x000000010986f010
zlib-test-case.hs: user error (Codec.Compression.Zlib: incorrect data check)
```
You'll get different Zlib errors, depending on where it detects the inconsistency. Sometimes Zlib doesn't throw an error, but the checksums are different.
So far we've only been able to reproduce this using GHCi 7.8.3 on both Linux (NixOS) and Mac. We haven't been able to trigger it with a compiled executable, nor with GHCi 7.6.3. It **was** reproducable with HEAD from Jan 30 (I had that lying around somewhere).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | hvr |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Probable data corruption with GHCi 7.8.* and Zlib","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["hvr"],"type":"Bug","description":"The following program causes Zlib data corruption errors when run from inside GHCi. It launches two threads which then concurrently read a file, compress it, and immediately decompress it. You need libraries `zlib`, `SHA`, and `async`.\r\n\r\n{{{\r\nmodule Main where\r\n\r\nimport qualified Codec.Compression.Zlib as Zlib\r\nimport qualified Data.ByteString.Lazy as BL\r\nimport qualified Data.ByteString.Internal as BI\r\n\r\nimport Control.Exception (bracket)\r\nimport Control.Concurrent\r\nimport Control.Monad\r\nimport Control.Exception ( evaluate)\r\nimport Data.Digest.Pure.SHA ( sha1) -- from the 'SHA' package\r\nimport Control.Concurrent.Async ( mapConcurrently)\r\nimport System.Mem ( performGC )\r\n\r\nimport Debug.Trace\r\n\r\ntest :: Int -> IO String\r\ntest _ = do\r\n tid <- myThreadId\r\n\r\n -- testdata is: dd if=/dev/urandom of=/tmp/testdata bs=100k count=100\r\n -- Could also be replaced by: (BL.take (10^7) \"/dev/urandom\")\r\n dat <- BL.readFile \"/tmp/testdata\"\r\n\r\n let cbuf = Zlib.compress $ traceChunks tid $ dat\r\n s <- evaluate $ sha1 $ Zlib.decompress $ cbuf\r\n return $ show s\r\n where\r\n -- We used this to check whether buffers were reused by different threads, but that\r\n -- doesn't seem to be the case. Removing the call to traceChunks, however, makes it\r\n -- harder to reproduce possibly because of scheduler effects. In a much larger program\r\n -- it could be reproduced more easily without the trace, but in this small example\r\n -- tracing seems to cause the right amount of nondeterminism.\r\n traceChunks tid bs =\r\n BL.fromChunks\r\n $ zipWith (\\n x -> trace (show tid ++ \":\" ++ showBS x) x) [1..]\r\n $ BL.toChunks bs\r\n\r\n showBS (BI.PS ptr off len) = show ptr\r\n\r\n\r\nmain = do\r\n r <- withGCThread $ mapConcurrently (test) ([1..2] :: [Int])\r\n putStrLn $ show $ r\r\n where\r\n -- Regularly forcing the GC makes the test-case more reproducible.\r\n withGCThread io =\r\n bracket (forkIO $ forever $ performGC >> threadDelay 1000)\r\n killThread\r\n (const io)\r\n}}}\r\n\r\nThe output should be something like:\r\n{{{\r\n...\r\nThreadId 51:0x00000001091ee010\r\nThreadId 49:0x00000001091a7010\r\n...\r\nThreadId 49:0x000000010986f010\r\nzlib-test-case.hs: user error (Codec.Compression.Zlib: incorrect data check)\r\n}}}\r\n\r\nYou'll get different Zlib errors, depending on where it detects the inconsistency. Sometimes Zlib doesn't throw an error, but the checksums are different.\r\n\r\nSo far we've only been able to reproduce this using GHCi 7.8.3 on both Linux (NixOS) and Mac. We haven't been able to trigger it with a compiled executable, nor with GHCi 7.6.3. It '''was''' reproducable with HEAD from Jan 30 (I had that lying around somewhere).\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/9451Incorrect optimizations involving negative zero2019-07-07T18:40:21ZmanzyukIncorrect optimizations involving negative zeroThe program
```hs
main = print $ if negativeZero == 0.0 then 1 / negativeZero else 0.0
where
negativeZero = negate 0.0
```
outputs `-Infinity` when compiled with GHC 7.6.3 and `Infinity` when compiled with GHC 7.8.3 and the optim...The program
```hs
main = print $ if negativeZero == 0.0 then 1 / negativeZero else 0.0
where
negativeZero = negate 0.0
```
outputs `-Infinity` when compiled with GHC 7.6.3 and `Infinity` when compiled with GHC 7.8.3 and the optimization level -O2. The relevant pieces of Core:
```
-- GHC 7.6.3
Main.main2 =
case GHC.Prim.==## (GHC.Prim.negateDouble# 0.0) 0.0 of _ {
GHC.Types.False -> Main.main3 (GHC.Types.[] @ GHC.Types.Char);
GHC.Types.True ->
case GHC.Prim./## 1.0 (GHC.Prim.negateDouble# 0.0)
of wild2_aK6 { __DEFAULT ->
GHC.Float.$w$sshowSignedFloat
GHC.Float.$fShowDouble_$sshowFloat
GHC.Show.shows26
wild2_aK6
(GHC.Types.[] @ GHC.Types.Char)
}
}
```
```
-- GHC 7.8.3
Main.main2 =
case GHC.Prim.negateDouble# 0.0 of _ [Occ=Dead] {
__DEFAULT -> Main.main3 (GHC.Types.[] @ GHC.Types.Char);
0.0 ->
case GHC.Prim./## 1.0 0.0 of wild2_a1NU { __DEFAULT ->
GHC.Float.$w$sshowSignedFloat
GHC.Float.$fShowDouble_$sshowFloat
GHC.Show.shows27
wild2_a1NU
(GHC.Types.[] @ GHC.Types.Char)
}
}
```
I don't think this problem is operating system/architecture dependent, but for the sake of completeness I'm on a 32-bit Linux, and this issue was first discovered on 64-bit Windows running in a virtual machine.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.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":"Incorrect optimizations involving negative zero","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The program\r\n\r\n{{{#!hs\r\nmain = print $ if negativeZero == 0.0 then 1 / negativeZero else 0.0\r\n where\r\n negativeZero = negate 0.0\r\n}}}\r\n\r\noutputs `-Infinity` when compiled with GHC 7.6.3 and `Infinity` when compiled with GHC 7.8.3 and the optimization level -O2. The relevant pieces of Core:\r\n\r\n{{{\r\n-- GHC 7.6.3\r\nMain.main2 =\r\n case GHC.Prim.==## (GHC.Prim.negateDouble# 0.0) 0.0 of _ {\r\n GHC.Types.False -> Main.main3 (GHC.Types.[] @ GHC.Types.Char);\r\n GHC.Types.True ->\r\n case GHC.Prim./## 1.0 (GHC.Prim.negateDouble# 0.0)\r\n of wild2_aK6 { __DEFAULT ->\r\n GHC.Float.$w$sshowSignedFloat\r\n GHC.Float.$fShowDouble_$sshowFloat\r\n GHC.Show.shows26\r\n wild2_aK6\r\n (GHC.Types.[] @ GHC.Types.Char)\r\n }\r\n }\r\n}}}\r\n\r\n{{{\r\n-- GHC 7.8.3\r\nMain.main2 =\r\n case GHC.Prim.negateDouble# 0.0 of _ [Occ=Dead] {\r\n __DEFAULT -> Main.main3 (GHC.Types.[] @ GHC.Types.Char);\r\n 0.0 ->\r\n case GHC.Prim./## 1.0 0.0 of wild2_a1NU { __DEFAULT ->\r\n GHC.Float.$w$sshowSignedFloat\r\n GHC.Float.$fShowDouble_$sshowFloat\r\n GHC.Show.shows27\r\n wild2_a1NU\r\n (GHC.Types.[] @ GHC.Types.Char)\r\n }\r\n }\r\n}}}\r\n\r\nI don't think this problem is operating system/architecture dependent, but for the sake of completeness I'm on a 32-bit Linux, and this issue was first discovered on 64-bit Windows running in a virtual machine.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/9435x86 sse4.2 popCnt16# needs to zero-extend its result2019-07-07T18:40:24Zrwbartonx86 sse4.2 popCnt16# needs to zero-extend its result`make TEST=cgrun071 EXTRA_HC_OPTS=-msse42` fails for me in all the non-ghci non-llvm ways.
For `popCnt16#` we emit `popcnt %ax,%ax` which doesn't clear the high 48 bits of the result.
Patch incoming.
<details><summary>Trac metadata</s...`make TEST=cgrun071 EXTRA_HC_OPTS=-msse42` fails for me in all the non-ghci non-llvm ways.
For `popCnt16#` we emit `popcnt %ax,%ax` which doesn't clear the high 48 bits of the result.
Patch incoming.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | --------------- |
| Version | 7.9 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (NCG) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | simonmar, tibbe |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"x86 sse4.2 popCnt16# needs to zero-extend its result","status":"New","operating_system":"","component":"Compiler (NCG)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.9","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["simonmar","tibbe"],"type":"Bug","description":"`make TEST=cgrun071 EXTRA_HC_OPTS=-msse42` fails for me in all the non-ghci non-llvm ways.\r\n\r\nFor `popCnt16#` we emit `popcnt %ax,%ax` which doesn't clear the high 48 bits of the result.\r\n\r\nPatch incoming.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.4https://gitlab.haskell.org/ghc/ghc/-/issues/9423shutdownCapability sometimes loops indefinitely on OSX after hs_exit()2019-07-07T18:40:28ZAndreasVoellmyshutdownCapability sometimes loops indefinitely on OSX after hs_exit()Issue #9284 relates to `forkProcess`, which previously invoked the same code that is invoked by `hs_exit` and uncovered this problem. The resolution of #9284 is to not invoke the equivalent of `hs_exit` (for reasons that you can see in #...Issue #9284 relates to `forkProcess`, which previously invoked the same code that is invoked by `hs_exit` and uncovered this problem. The resolution of #9284 is to not invoke the equivalent of `hs_exit` (for reasons that you can see in #9284). However, `hs_exit` can be called by programs that explicitly create and teardown a Haskell runtime, so the problem displayed by #9284 can still occur for those programs.
The problem has only been observed on OS X, though it probably could occur on Linux OSes as well.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.8.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | simonmar |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"shutdownCapability sometimes loops indefinitely on OSX after hs_exit()","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"simonmar"},"version":"7.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["simonmar"],"type":"Bug","description":"Issue #9284 relates to `forkProcess`, which previously invoked the same code that is invoked by `hs_exit` and uncovered this problem. The resolution of #9284 is to not invoke the equivalent of `hs_exit` (for reasons that you can see in #9284). However, `hs_exit` can be called by programs that explicitly create and teardown a Haskell runtime, so the problem displayed by #9284 can still occur for those programs.\r\n\r\nThe problem has only been observed on OS X, though it probably could occur on Linux OSes as well.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/9407Program produces different output when compiled with -O2019-07-07T18:40:30ZarotenbergProgram produces different output when compiled with -OWhen compiled and run as
```
ghc Subtlety.hs
Subtlety
```
the attached program generates the correct output of
```
Just (Vec3 0.0 0.0 1.0)
```
but when compiled and run using
```
ghc -O Subtlety.hs
Subtlety
```
the program's output...When compiled and run as
```
ghc Subtlety.hs
Subtlety
```
the attached program generates the correct output of
```
Just (Vec3 0.0 0.0 1.0)
```
but when compiled and run using
```
ghc -O Subtlety.hs
Subtlety
```
the program's output is
```
Just (Vec3 0.0 0.9805806756909202 0.19611613513818404)
```
Furthermore, subtle changes to the source code (like removing the strictness on the `Vec3` type's fields) can alter the behavior of the compiled program.
I am using GHC 7.8.3 x86-64 from Haskell Platform 2014.2.0.0 RC2 on Windows 8.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.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":"Program produces different output when compiled with -O","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When compiled and run as\r\n{{{\r\nghc Subtlety.hs\r\nSubtlety\r\n}}}\r\nthe attached program generates the correct output of\r\n{{{\r\nJust (Vec3 0.0 0.0 1.0)\r\n}}}\r\nbut when compiled and run using\r\n{{{\r\nghc -O Subtlety.hs\r\nSubtlety\r\n}}}\r\nthe program's output is\r\n{{{\r\nJust (Vec3 0.0 0.9805806756909202 0.19611613513818404)\r\n}}}\r\nFurthermore, subtle changes to the source code (like removing the strictness on the `Vec3` type's fields) can alter the behavior of the compiled program.\r\n\r\nI am using GHC 7.8.3 x86-64 from Haskell Platform 2014.2.0.0 RC2 on Windows 8.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/9406unexpected failure for T7837(profasm)2019-07-07T18:40:31Zjrp2014unexpected failure for T7837(profasm)This may be a test suite configuration error as the normal case works (and indeed I get a lot of profiled case failures of other cases). When run with an llvm-perf build of the HEAD, I get:
```
=====> T7837(normal) 1395 of 4068 [0, 0, 0...This may be a test suite configuration error as the normal case works (and indeed I get a lot of profiled case failures of other cases). When run with an llvm-perf build of the HEAD, I get:
```
=====> T7837(normal) 1395 of 4068 [0, 0, 0]
cd ./indexed-types/should_compile && '/Users/jrp/Projects/haskell/ghc/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T7837.hs -O -ddump-rule-firings >T7837.comp.stderr 2>&1
=====> T7837(profasm) 1395 of 4068 [0, 0, 0]
cd ./indexed-types/should_compile && '/Users/jrp/Projects/haskell/ghc/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c T7837.hs -O -prof -static -auto-all -O -ddump-rule-firings >T7837.comp.stderr 2>&1
Actual stderr output differs from expected:
--- ./indexed-types/should_compile/T7837.stderr 2014-08-03 11:36:53.000000000 +0100
+++ ./indexed-types/should_compile/T7837.comp.stderr 2014-08-04 23:16:34.000000000 +0100
@@ -1,3 +1,4 @@
Rule fired: Class op abs
Rule fired: Class op signum
Rule fired: normalize/Double
+Rule fired: Class op /
*** unexpected failure for T7837(profasm)
Unexpected results from:
TEST="T7837"
OVERALL SUMMARY for test run started at Mon Aug 4 23:16:32 2014 BST
0:00:02 spent to go through
4068 total tests, which gave rise to
19536 test cases, of which
19534 were skipped
0 had missing libraries
1 expected passes
0 expected failures
0 caused framework failures
0 unexpected passes
1 unexpected failures
Unexpected failures:
indexed-types/should_compile T7837 [stderr mismatch] (profasm)
```https://gitlab.haskell.org/ghc/ghc/-/issues/9401MVar deadlock exceptions cause exceptions in later MVar ops2019-07-07T18:40:33ZMichael Snoymanmichael@snoyman.comMVar deadlock exceptions cause exceptions in later MVar opsTake the following code:
```hs
import Control.Concurrent
import Control.Concurrent.MVar
import Control.Exception
main :: IO ()
main = do
var <- newEmptyMVar
_ <- forkIO $ do
res <- try $ newEmptyMVar >>= takeMVar
...Take the following code:
```hs
import Control.Concurrent
import Control.Concurrent.MVar
import Control.Exception
main :: IO ()
main = do
var <- newEmptyMVar
_ <- forkIO $ do
res <- try $ newEmptyMVar >>= takeMVar
putMVar var res
putStrLn "Successfully filled var"
res <- readMVar var `onException` do
putStrLn "Received exception, delaying..."
threadDelay 1000000
res <- readMVar var
putStrLn $ "After delay, res is: " ++ show res
print (res :: Either SomeException Int)
putStrLn "Exiting..."
```
On line 9, an MVar deadlock exception is thrown, which is caught by `try`. That result is then put into the var MVar. On line 13, I `readMVar` to get this value. I would expect it to return the exception previously thrown, as a `Left` value. Instead, a __new__ exception is thrown. I say new, because if I switch over to using STM instead of an MVar, I get a different exception (STM transaction instead of MVar deadlock).
With the program as above, my output is:
```
Successfully filled var
Received exception, delaying...
After delay, res is: Left thread blocked indefinitely in an MVar operation
async14.hs: thread blocked indefinitely in an MVar operation
```
I originally filed this as an issue against the async package: https://github.com/simonmar/async/issues/14
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.8.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | simonmar |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"MVar deadlock exceptions cause exceptions in later MVar ops","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"simonmar"},"version":"7.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["simonmar"],"type":"Bug","description":"Take the following code:\r\n\r\n{{{#!hs\r\nimport Control.Concurrent\r\nimport Control.Concurrent.MVar\r\nimport Control.Exception\r\n\r\nmain :: IO ()\r\nmain = do\r\n var <- newEmptyMVar\r\n _ <- forkIO $ do\r\n res <- try $ newEmptyMVar >>= takeMVar\r\n putMVar var res\r\n putStrLn \"Successfully filled var\"\r\n\r\n res <- readMVar var `onException` do\r\n putStrLn \"Received exception, delaying...\"\r\n threadDelay 1000000\r\n res <- readMVar var\r\n putStrLn $ \"After delay, res is: \" ++ show res\r\n\r\n print (res :: Either SomeException Int)\r\n putStrLn \"Exiting...\"\r\n}}}\r\n\r\nOn line 9, an MVar deadlock exception is thrown, which is caught by `try`. That result is then put into the var MVar. On line 13, I `readMVar` to get this value. I would expect it to return the exception previously thrown, as a `Left` value. Instead, a __new__ exception is thrown. I say new, because if I switch over to using STM instead of an MVar, I get a different exception (STM transaction instead of MVar deadlock).\r\n\r\nWith the program as above, my output is:\r\n\r\n{{{\r\nSuccessfully filled var\r\nReceived exception, delaying...\r\nAfter delay, res is: Left thread blocked indefinitely in an MVar operation\r\nasync14.hs: thread blocked indefinitely in an MVar operation\r\n}}}\r\n\r\nI originally filed this as an issue against the async package: https://github.com/simonmar/async/issues/14","type_of_failure":"OtherFailure","blocking":[]} -->Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/9395Debug.Trace should not use %s for format string2020-04-10T18:05:46ZEdward Z. YangDebug.Trace should not use %s for format stringThe current implementation of traceIO in Debug.Trace is as follows:
```
traceIO :: String -> IO ()
traceIO msg = do
withCString "%s\n" $ \cfmt ->
withCString msg $ \cmsg ->
debugBelch cfmt cmsg
```
This is bad news: it ...The current implementation of traceIO in Debug.Trace is as follows:
```
traceIO :: String -> IO ()
traceIO msg = do
withCString "%s\n" $ \cfmt ->
withCString msg $ \cmsg ->
debugBelch cfmt cmsg
```
This is bad news: it means if the String has a null in it, the string will be silently truncated. For example, in GHC, this means that you cannot pretty-print FastString uniques, since the default printing algorithm often results in a null.
Probably the proper thing to do here is to also pass a length indicator for the CString. We should also fix unique pretty-printing to never generate nulls. A good test case would be:
```
main = trace "\0foo" (return ())
```
which should have non-empty output.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.8.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ekmett, hvr |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Debug.Trace should not use %s for format string","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ekmett","hvr"],"type":"Bug","description":"The current implementation of traceIO in Debug.Trace is as follows:\r\n\r\n{{{\r\ntraceIO :: String -> IO ()\r\ntraceIO msg = do\r\n withCString \"%s\\n\" $ \\cfmt ->\r\n withCString msg $ \\cmsg ->\r\n debugBelch cfmt cmsg\r\n}}}\r\n\r\nThis is bad news: it means if the String has a null in it, the string will be silently truncated. For example, in GHC, this means that you cannot pretty-print FastString uniques, since the default printing algorithm often results in a null.\r\n\r\nProbably the proper thing to do here is to also pass a length indicator for the CString. We should also fix unique pretty-printing to never generate nulls. A good test case would be:\r\n\r\n{{{\r\nmain = trace \"\\0foo\" (return ())\r\n}}}\r\n\r\nwhich should have non-empty output.","type_of_failure":"OtherFailure","blocking":[]} -->Edward Z. YangEdward Z. Yang