GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:54:18Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/5626Miscompilation, exception omitted with -O2019-07-07T18:54:18Zmichal.palkaMiscompilation, exception omitted with -OFollowing program is miscompiled when compiled with `-O`.
```
module Main where
wrap x = [x]!!0
f :: [Int] -> a
f a = foldr (\b -> \c -> c) (undefined ()) (a ++ a) 0
main = do
print $ (f [] :: String)
print $ wrap $ (f [] :: Int)...Following program is miscompiled when compiled with `-O`.
```
module Main where
wrap x = [x]!!0
f :: [Int] -> a
f a = foldr (\b -> \c -> c) (undefined ()) (a ++ a) 0
main = do
print $ (f [] :: String)
print $ wrap $ (f [] :: Int)
print $ wrap $ (f [] :: (Int, Int, Int, Int))
```
The result of running it on my machine (Linux x86-64) is following:
```
"
1099511628032
zsh: segmentation fault ./test7
```
Looking at the Core it seems that instead of the expected `undefined` a partially-applied function is returned. GHC 7.3.20111022 was used for testing.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------------- |
| Version | 7.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | michal.palka@poczta.fm |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Miscompilation, exception omitted with -O","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.3","keywords":["exception","miscompilation","strict","strictness"],"differentials":[],"test_case":"","architecture":"","cc":["michal.palka@poczta.fm"],"type":"Bug","description":"Following program is miscompiled when compiled with `-O`.\r\n{{{\r\nmodule Main where\r\n\r\nwrap x = [x]!!0\r\n\r\nf :: [Int] -> a\r\nf a = foldr (\\b -> \\c -> c) (undefined ()) (a ++ a) 0\r\n\r\nmain = do\r\n print $ (f [] :: String)\r\n print $ wrap $ (f [] :: Int)\r\n print $ wrap $ (f [] :: (Int, Int, Int, Int))\r\n}}}\r\n\r\nThe result of running it on my machine (Linux x86-64) is following:\r\n{{{\r\n\"\r\n1099511628032\r\nzsh: segmentation fault ./test7\r\n}}}\r\n\r\nLooking at the Core it seems that instead of the expected `undefined` a partially-applied function is returned. GHC 7.3.20111022 was used for testing.","type_of_failure":"OtherFailure","blocking":[]} -->7.4.1Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/5625Code using seq has wrong strictness when unoptimised (too lazy)2019-07-07T18:54:18Zmichal.palkaCode using seq has wrong strictness when unoptimised (too lazy)The code code should crash with Prelude.undefined. When compiled with `-O` it behaves correctly, however with no optimisation (`-O0`) it prints `[0]` instead. Reading the Core suggests that the expression gets translated into `print (id ...The code code should crash with Prelude.undefined. When compiled with `-O` it behaves correctly, however with no optimisation (`-O0`) it prints `[0]` instead. Reading the Core suggests that the expression gets translated into `print (id [0])` when compiled with `-O0`. It was tested with GHC 7.3.20111022.
```
main = do
let a = \x -> seq undefined (+1)
print $ (a `seq` a [] `seq` id) [0]
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------------- |
| Version | 7.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | michal.palka@poczta.fm |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Code using seq has wrong strictness when unoptimised (too lazy)","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.3","keywords":["lazy","seq","strict","strictness"],"differentials":[],"test_case":"","architecture":"","cc":["michal.palka@poczta.fm"],"type":"Bug","description":"The code code should crash with Prelude.undefined. When compiled with `-O` it behaves correctly, however with no optimisation (`-O0`) it prints `[0]` instead. Reading the Core suggests that the expression gets translated into `print (id [0])` when compiled with `-O0`. It was tested with GHC 7.3.20111022.\r\n\r\n{{{\r\nmain = do\r\n let a = \\x -> seq undefined (+1)\r\n print $ (a `seq` a [] `seq` id) [0]\r\n}}}\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.4.1Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/5614recompilation bug with -O2019-07-07T18:54:21Zgmi001recompilation bug with -ORecompilation with -O should also rebuild Main.hs in the attached test application consisting of Main.hs and X.hs.
Test case:
1) build the app with GHC --make -O Main.hs
2) run Main (output = B)
3) change and save in X.hs
> x = D {...Recompilation with -O should also rebuild Main.hs in the attached test application consisting of Main.hs and X.hs.
Test case:
1) build the app with GHC --make -O Main.hs
2) run Main (output = B)
3) change and save in X.hs
> x = D { f = B }
> to
> x = D { f = A }
4) rebuild the app with GHC --make -O Main.hs (recompiles only X.hs)
5) run Main (unexpected output = B)
6) force recompilation of both X.hs and Main.hs
7) run Main (output = A)
The bug is in -O.
A similar test with f :: String instead of f :: D2 runs without problems.
Problem is tested positive on WIN GHC 7.0.2, OpenSuse GHC 6.12.3, Mac OS X GHC 7.0.3 and GHC 7.2.1 (MAC?).
for more detail see http://sourceforge.net/apps/trac/ampersand/ticket/172.
the closed #1959 and #3166 describe similar problems.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.2.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"recompilation bug with -O","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.2.1","keywords":["recompilation"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Recompilation with -O should also rebuild Main.hs in the attached test application consisting of Main.hs and X.hs.\r\n\r\nTest case:\r\n\r\n1) build the app with GHC --make -O Main.hs\r\n\r\n2) run Main (output = B)\r\n\r\n3) change and save in X.hs\r\n\r\n x = D { f = B }\r\n\r\n to\r\n\r\n x = D { f = A }\r\n\r\n4) rebuild the app with GHC --make -O Main.hs (recompiles only X.hs) \r\n\r\n5) run Main (unexpected output = B)\r\n\r\n6) force recompilation of both X.hs and Main.hs\r\n\r\n7) run Main (output = A)\r\n\r\nThe bug is in -O.\r\nA similar test with f :: String instead of f :: D2 runs without problems.\r\n\r\nProblem is tested positive on WIN GHC 7.0.2, OpenSuse GHC 6.12.3, Mac OS X GHC 7.0.3 and GHC 7.2.1 (MAC?).\r\n\r\nfor more detail see http://sourceforge.net/apps/trac/ampersand/ticket/172.\r\n\r\nthe closed #1959 and #3166 describe similar problems.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.4.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/5611Asynchronous exception discarded after safe FFI call2019-07-07T18:54:23ZjoeyadamsAsynchronous exception discarded after safe FFI call**Note:** This bug appears to be fixed already, as it does not appear with GHC 7.2.1 . I'm submitting a bug report anyway, to document its presence.
The bug is: when an asynchronous exception is thrown to a thread making a (safe) foreig...**Note:** This bug appears to be fixed already, as it does not appear with GHC 7.2.1 . I'm submitting a bug report anyway, to document its presence.
The bug is: when an asynchronous exception is thrown to a thread making a (safe) foreign call, the thread throwing the exception blocks like it should, but then the exception isn't actually delivered. For example:
```haskell
{-# LANGUAGE ForeignFunctionInterface #-}
import Control.Concurrent
import Foreign.C
import System.IO
foreign import ccall safe "unistd.h sleep"
sleep :: CUInt -> IO CUInt
main :: IO ()
main = do
hSetBuffering stdout LineBuffering
tid <- forkIO $ do
putStrLn "child: Sleeping"
_ <- sleep 1
-- The following lines should not happen after the killThread from the
-- parent thread completes. However, they do...
putStrLn "child: Done sleeping"
threadDelay 1000000
putStrLn "child: Done waiting"
threadDelay 100000
putStrLn $ "parent: Throwing exception to thread " ++ show tid
throwTo tid $ userError "Exception delivered successfully"
putStrLn "parent: Done throwing exception"
threadDelay 2000000
```
When the bug is present, the program prints:
```
child: Sleeping
parent: Throwing exception to thread ThreadId 4
child: Done sleeping
parent: Done throwing exception
child: Done waiting
```
"child: Done waiting" should not be printed after completion of the throwTo, and the exception message should appear. On GHC 7.2.1, the program prints:
```
child: Sleeping
parent: Throwing exception to thread ThreadId 4
parent: Done throwing exception
ffi-sleep: user error (Exception delivered successfully)
```
This bug has been reproduced in GHC 7.0.3, on both Linux and Windows. It has also been reproduced on GHC 7.0.4.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.0.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Asynchronous exception discarded after safe FFI call","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.3","keywords":["FFI,","exception"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"'''Note:''' This bug appears to be fixed already, as it does not appear with GHC 7.2.1 . I'm submitting a bug report anyway, to document its presence.\r\n\r\nThe bug is: when an asynchronous exception is thrown to a thread making a (safe) foreign call, the thread throwing the exception blocks like it should, but then the exception isn't actually delivered. For example:\r\n\r\n{{{\r\n\r\n{-# LANGUAGE ForeignFunctionInterface #-}\r\n\r\nimport Control.Concurrent\r\nimport Foreign.C\r\nimport System.IO\r\n\r\nforeign import ccall safe \"unistd.h sleep\"\r\n sleep :: CUInt -> IO CUInt\r\n\r\nmain :: IO ()\r\nmain = do\r\n hSetBuffering stdout LineBuffering\r\n\r\n tid <- forkIO $ do\r\n putStrLn \"child: Sleeping\"\r\n _ <- sleep 1\r\n\r\n -- The following lines should not happen after the killThread from the\r\n -- parent thread completes. However, they do...\r\n putStrLn \"child: Done sleeping\"\r\n threadDelay 1000000\r\n putStrLn \"child: Done waiting\"\r\n\r\n threadDelay 100000\r\n putStrLn $ \"parent: Throwing exception to thread \" ++ show tid\r\n throwTo tid $ userError \"Exception delivered successfully\"\r\n putStrLn \"parent: Done throwing exception\"\r\n\r\n threadDelay 2000000\r\n}}}\r\n\r\nWhen the bug is present, the program prints:\r\n\r\n{{{\r\nchild: Sleeping\r\nparent: Throwing exception to thread ThreadId 4\r\nchild: Done sleeping\r\nparent: Done throwing exception\r\nchild: Done waiting\r\n}}}\r\n\r\n\"child: Done waiting\" should not be printed after completion of the throwTo, and the exception message should appear. On GHC 7.2.1, the program prints:\r\n\r\n{{{\r\nchild: Sleeping\r\nparent: Throwing exception to thread ThreadId 4\r\nparent: Done throwing exception\r\nffi-sleep: user error (Exception delivered successfully)\r\n}}}\r\n\r\nThis bug has been reproduced in GHC 7.0.3, on both Linux and Windows. It has also been reproduced on GHC 7.0.4.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/5594stdout is not flushed using custom main2019-07-07T18:54:35Zhandonsonstdout is not flushed using custom mainAccording to the [using your own main()](http://www.haskell.org/ghc/docs/latest/html/users_guide/ffi-ghc.html#using-own-main) guide, Prepare two files.
main.c:
```
#include <stdio.h>
#include "HsFFI.h"
#ifdef __GLASGOW_HASKELL__
#incl...According to the [using your own main()](http://www.haskell.org/ghc/docs/latest/html/users_guide/ffi-ghc.html#using-own-main) guide, Prepare two files.
main.c:
```
#include <stdio.h>
#include "HsFFI.h"
#ifdef __GLASGOW_HASKELL__
#include "Vomit_stub.h"
#endif
int main(int argc, char *argv[])
{
int i;
hs_init(&argc, &argv);
vomit();
hs_exit();
return 0;
}
```
Vomit.hs:
```
{-# LANGUAGE ForeignFunctionInterface #-}
{-# LANGUAGE OverloadedStrings #-}
module Vomit where
import Data.ByteString
import Data.ByteString.Char8 ()
import Prelude hiding (putStr)
foreign export ccall vomit :: IO ()
vomit = putStr "Wrrreerrerek\n"
```
Compile the code:
```
$ ghc -c Vomit.hs
$ ghc --make -no-hs-main -optc-O main.c Vomit -o main
```
Run:
```
$ ./main
Wrrreerrerek
$
```
Looks fine. However:
```
$ ./main > output.txt
$ cat output.txt
$
```
output.txt is empty.
It seems when the output is done by some Haskell code called by a C code, and the stdout is redirected to a file, the output is not properly flushed. Changing Vomit.hs to:
```
{-# LANGUAGE ForeignFunctionInterface #-}
{-# LANGUAGE OverloadedStrings #-}
module Vomit where
import Data.ByteString
import Data.ByteString.Char8 ()
import Prelude hiding (putStr)
import System.IO (hFlush, stdout)
foreign export ccall vomit :: IO ()
vomit = putStr "Wrrreerrerek\n" >> hFlush stdout
```
which manually flushes stdout, fixes the behavior.
Since hs_exit() on the C side is supposed to terminate the RTS and flush all output, this seems to be a bug.
Tested with GHC 7.0.4 on Debian GNU/Linux for x86.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.0.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"stdout is not flushed using custom main","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"According to the [http://www.haskell.org/ghc/docs/latest/html/users_guide/ffi-ghc.html#using-own-main using your own main()] guide, Prepare two files.\r\n\r\nmain.c:\r\n\r\n{{{\r\n#include <stdio.h>\r\n#include \"HsFFI.h\"\r\n\r\n#ifdef __GLASGOW_HASKELL__\r\n#include \"Vomit_stub.h\"\r\n#endif\r\n\r\nint main(int argc, char *argv[])\r\n{\r\n int i;\r\n\r\n hs_init(&argc, &argv);\r\n\r\n vomit();\r\n\r\n hs_exit();\r\n return 0;\r\n}\r\n}}}\r\n\r\nVomit.hs:\r\n\r\n{{{\r\n{-# LANGUAGE ForeignFunctionInterface #-}\r\n{-# LANGUAGE OverloadedStrings #-}\r\n\r\nmodule Vomit where\r\n\r\nimport Data.ByteString\r\nimport Data.ByteString.Char8 ()\r\nimport Prelude hiding (putStr)\r\n\r\nforeign export ccall vomit :: IO ()\r\nvomit = putStr \"Wrrreerrerek\\n\"\r\n}}}\r\n\r\nCompile the code:\r\n\r\n{{{\r\n$ ghc -c Vomit.hs\r\n$ ghc --make -no-hs-main -optc-O main.c Vomit -o main\r\n}}}\r\n\r\nRun:\r\n\r\n{{{\r\n$ ./main\r\nWrrreerrerek\r\n$\r\n}}}\r\n\r\nLooks fine. However:\r\n\r\n{{{\r\n$ ./main > output.txt\r\n$ cat output.txt\r\n$\r\n}}}\r\n\r\noutput.txt is empty.\r\n\r\nIt seems when the output is done by some Haskell code called by a C code, and the stdout is redirected to a file, the output is not properly flushed. Changing Vomit.hs to:\r\n\r\n{{{\r\n{-# LANGUAGE ForeignFunctionInterface #-}\r\n{-# LANGUAGE OverloadedStrings #-}\r\n\r\nmodule Vomit where\r\n\r\nimport Data.ByteString\r\nimport Data.ByteString.Char8 ()\r\nimport Prelude hiding (putStr)\r\n\r\nimport System.IO (hFlush, stdout)\r\n\r\nforeign export ccall vomit :: IO ()\r\nvomit = putStr \"Wrrreerrerek\\n\" >> hFlush stdout\r\n}}}\r\n\r\nwhich manually flushes stdout, fixes the behavior.\r\n\r\nSince hs_exit() on the C side is supposed to terminate the RTS and flush all output, this seems to be a bug.\r\n\r\nTested with GHC 7.0.4 on Debian GNU/Linux for x86.","type_of_failure":"OtherFailure","blocking":[]} -->7.4.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/5587Code using seq has wrong strictness (too lazy) when optimised2020-02-26T21:26:10Zmichal.palkaCode using seq has wrong strictness (too lazy) when optimisedFollowing program prints `[1]` instead of crashing when compiled with `-O -fno-full-laziness`. Note that it's neccessary to use the extra definition `hiddenError` instead of calling `error` directly. The problem might be related to #5557...Following program prints `[1]` instead of crashing when compiled with `-O -fno-full-laziness`. Note that it's neccessary to use the extra definition `hiddenError` instead of calling `error` directly. The problem might be related to #5557, which, however, has already been fixed and optimisation is needed to trigger the current bug.
```
hiddenError = error "hidden error"
main = do
print $ seq (head (map (\a -> \b -> hiddenError) (hiddenError::[] Bool))) id [1]
```
I used GHC 7.3.20111022 for triggering this problem.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------------- |
| Version | 7.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | michal.palka@poczta.fm |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Code using seq has wrong strictness (too lazy) when optimised","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.3","keywords":["lazy","seq","strict","strictness"],"differentials":[],"test_case":"","architecture":"","cc":["michal.palka@poczta.fm"],"type":"Bug","description":"Following program prints `[1]` instead of crashing when compiled with `-O -fno-full-laziness`. Note that it's neccessary to use the extra definition `hiddenError` instead of calling `error` directly. The problem might be related to #5557, which, however, has already been fixed and optimisation is needed to trigger the current bug.\r\n\r\n{{{\r\nhiddenError = error \"hidden error\"\r\n\r\nmain = do\r\n print $ seq (head (map (\\a -> \\b -> hiddenError) (hiddenError::[] Bool))) id [1]\r\n}}}\r\n\r\nI used GHC 7.3.20111022 for triggering this problem.","type_of_failure":"OtherFailure","blocking":[]} -->7.4.1Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/5570($) of an unboxed double appears to be treated as 0.02019-07-07T18:54:41Zmanzyuk($) of an unboxed double appears to be treated as 0.0The following program compiles cleanly with GHC 7.0.3 running on a 64 bit Linux machine, but produces the wrong answer:
```
$ uname -a
Linux pandora 2.6.32-5-amd64 #1 SMP Fri Sep 9 20:23:16 UTC 2011 x86_64 GNU/Linux
$ ghc --version
The ...The following program compiles cleanly with GHC 7.0.3 running on a 64 bit Linux machine, but produces the wrong answer:
```
$ uname -a
Linux pandora 2.6.32-5-amd64 #1 SMP Fri Sep 9 20:23:16 UTC 2011 x86_64 GNU/Linux
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.0.3
$ cat bug.hs
{-# LANGUAGE MagicHash #-}
import GHC.Exts
main :: IO ()
main = print $ D# $ 3.0##
$ ghc -Wall bug.hs
[1 of 1] Compiling Main ( bug.hs, bug.o )
Linking bug ...
$ ./bug
0.0
```
The expected behavior was to either produce a compile-time error message or to output 3.0.
Compiling this program on the same machine with `-dcore-lint` produces:
```
$ ghc bug.hs -dcore-lint
[1 of 1] Compiling Main ( bug.hs, bug.o )
*** Core Lint errors : in result of Desugar ***
<no location info>:
In the expression: GHC.Base.$ @ GHC.Prim.Double#
Kinds don't match in type application:
Type variable: a_ahX :: *
Arg type: GHC.Prim.Double# :: #
*** Offending Program ***
Main.main :: GHC.Types.IO ()
[LclIdX]
Main.main =
GHC.Base.$
@ GHC.Types.Double
@ (GHC.Types.IO ())
(System.IO.print @ GHC.Types.Double GHC.Float.$fShowDouble)
(GHC.Base.$ @ GHC.Prim.Double# @ GHC.Types.Double GHC.Types.D# 3.0)
:Main.main :: GHC.Types.IO ()
[LclIdX]
:Main.main = GHC.TopHandler.runMainIO @ () Main.main
*** End of Offense ***
<no location info>:
Compilation had errors
```
Compiling the program with GHC 6.12.1 on a different machine running 32 bit Linux fails with the following perfectly reasonable error message:
```
$ uname -a
Linux golconda 2.6.32-5-686 #1 SMP Mon Jun 13 04:13:06 UTC 2011 i686 GNU/Linux
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.12.1
$ ghc bug.hs
bug.hs:6:15:
Couldn't match kind `#' against `*'
When matching the kinds of `Double# :: #' and `a :: *'
Expected type: a
Inferred type: Double#
In the first argument of `($)', namely `D#'
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.0.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | axch@mit.edu |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"($) of an unboxed double appears to be treated as 0.0","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["axch@mit.edu"],"type":"Bug","description":"The following program compiles cleanly with GHC 7.0.3 running on a 64 bit Linux machine, but produces the wrong answer:\r\n\r\n{{{\r\n$ uname -a\r\nLinux pandora 2.6.32-5-amd64 #1 SMP Fri Sep 9 20:23:16 UTC 2011 x86_64 GNU/Linux\r\n$ ghc --version\r\nThe Glorious Glasgow Haskell Compilation System, version 7.0.3\r\n$ cat bug.hs\r\n{-# LANGUAGE MagicHash #-}\r\n\r\nimport GHC.Exts\r\n\r\nmain :: IO ()\r\nmain = print $ D# $ 3.0##\r\n$ ghc -Wall bug.hs\r\n[1 of 1] Compiling Main ( bug.hs, bug.o )\r\nLinking bug ...\r\n$ ./bug\r\n0.0\r\n}}}\r\n\r\nThe expected behavior was to either produce a compile-time error message or to output 3.0.\r\n\r\nCompiling this program on the same machine with `-dcore-lint` produces:\r\n\r\n{{{\r\n$ ghc bug.hs -dcore-lint\r\n[1 of 1] Compiling Main ( bug.hs, bug.o )\r\n*** Core Lint errors : in result of Desugar ***\r\n<no location info>:\r\n In the expression: GHC.Base.$ @ GHC.Prim.Double#\r\n Kinds don't match in type application:\r\n Type variable: a_ahX :: *\r\n Arg type: GHC.Prim.Double# :: #\r\n*** Offending Program ***\r\nMain.main :: GHC.Types.IO ()\r\n[LclIdX]\r\nMain.main =\r\n GHC.Base.$\r\n @ GHC.Types.Double\r\n @ (GHC.Types.IO ())\r\n (System.IO.print @ GHC.Types.Double GHC.Float.$fShowDouble)\r\n (GHC.Base.$ @ GHC.Prim.Double# @ GHC.Types.Double GHC.Types.D# 3.0)\r\n\r\n:Main.main :: GHC.Types.IO ()\r\n[LclIdX]\r\n:Main.main = GHC.TopHandler.runMainIO @ () Main.main\r\n\r\n*** End of Offense ***\r\n\r\n\r\n<no location info>: \r\nCompilation had errors\r\n}}}\r\n\r\nCompiling the program with GHC 6.12.1 on a different machine running 32 bit Linux fails with the following perfectly reasonable error message:\r\n\r\n{{{\r\n$ uname -a\r\nLinux golconda 2.6.32-5-686 #1 SMP Mon Jun 13 04:13:06 UTC 2011 i686 GNU/Linux\r\n$ ghc --version\r\nThe Glorious Glasgow Haskell Compilation System, version 6.12.1\r\n$ ghc bug.hs\r\n\r\nbug.hs:6:15:\r\n Couldn't match kind `#' against `*'\r\n When matching the kinds of `Double# :: #' and `a :: *'\r\n Expected type: a\r\n Inferred type: Double#\r\n In the first argument of `($)', namely `D#'\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/5561assertion overriden by other exceptions2019-07-07T18:54:44ZMikolaj Konarskiassertion overriden by other exceptionsThe attached file, containing
```
main = let e1 i = throw Overflow
in assert False (e1 5)
```
and compiled with
```
ghc --make -O1 -fno-ignore-asserts test.hs
```
produces
```
test: arithmetic overflow
```
and should produce...The attached file, containing
```
main = let e1 i = throw Overflow
in assert False (e1 5)
```
and compiled with
```
ghc --make -O1 -fno-ignore-asserts test.hs
```
produces
```
test: arithmetic overflow
```
and should produce
```
test: test.hs:25:11-16: Assertion failed
```
Works OK, if compiled with
```
ghc --make -O0 test.hs
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.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":"assertion overriden by other exceptions","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The attached file, containing\r\n\r\n{{{\r\nmain = let e1 i = throw Overflow\r\n in assert False (e1 5)\r\n}}}\r\n\r\nand compiled with\r\n\r\n{{{\r\nghc --make -O1 -fno-ignore-asserts test.hs\r\n}}}\r\n\r\nproduces\r\n\r\n{{{\r\ntest: arithmetic overflow\r\n}}}\r\n\r\nand should produce\r\n\r\n{{{\r\ntest: test.hs:25:11-16: Assertion failed\r\n}}}\r\n\r\nWorks OK, if compiled with\r\n\r\n{{{\r\nghc --make -O0 test.hs\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/5560case and type synonym2019-07-07T18:54:44ZsleepyMonadcase and type synonymObserved on arch linux, 7.0.3 ghc. (package version 7.0.3-2)
The warning is suspicious; the result for switchOnEvent2 bp is wrong.
It works however if no type synonym is used (as illustrated).
Thanks
-- patrick
```
[patrick@eee2 launc...Observed on arch linux, 7.0.3 ghc. (package version 7.0.3-2)
The warning is suspicious; the result for switchOnEvent2 bp is wrong.
It works however if no type synonym is used (as illustrated).
Thanks
-- patrick
```
[patrick@eee2 launcher]$ ghci
GHCi, version 7.0.3: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package ffi-1.0 ... linking ... done.
Prelude> :l testme
[1 of 1] Compiling Main ( testme.hs, interpreted )
testme.hs:10:1:
Warning: Pattern match(es) are overlapped
In an equation for `switchOnEvent2':
switchOnEvent2 bp = ...
switchOnEvent2 _ = ...
Ok, modules loaded: Main.
*Main> switchOnEvent2 kp
KP
*Main> switchOnEvent2 bp
KP
*Main> switchOnEvent3 202
KP
*Main> switchOnEvent3 204
BP
*Main> switchOnEvent3 203
??
*Main> >
```
```
-- testme.hs:
import Data.Word
type MyEventType = Word32
kp :: MyEventType
kp = 102
bp :: MyEventType
bp = 104
switchOnEvent2 :: MyEventType -> IO ()
switchOnEvent2 kp = do putStrLn "KP"
switchOnEvent2 bp = do putStrLn "BP"
switchOnEvent2 _ = do putStrLn "??"
switchOnEvent3 :: Word32 -> IO ()
switchOnEvent3 202 = do putStrLn "KP"
switchOnEvent3 204 = do putStrLn "BP"
switchOnEvent3 _ = do putStrLn "??"
```https://gitlab.haskell.org/ghc/ghc/-/issues/5558Deadlock using unsafePerformIO to create a global MVar2020-12-15T15:14:47ZBertram FelgenhauerDeadlock using unsafePerformIO to create a global MVarThe following program occasionally terminates with a BlockedIndefinitelyOnMVar exception. This is unexpected.
(According to SimonM, http://www.haskell.org/pipermail/glasgow-haskell-users/2011-October/021084.html)
```
import Control.Conc...The following program occasionally terminates with a BlockedIndefinitelyOnMVar exception. This is unexpected.
(According to SimonM, http://www.haskell.org/pipermail/glasgow-haskell-users/2011-October/021084.html)
```
import Control.Concurrent
import Control.Exception
import Control.Monad
import System.IO.Unsafe
main :: IO ()
main = do
-- evaluate lock -- adding this line fixes the problem
fin1 <- newEmptyMVar
fin2 <- newEmptyMVar
forkIO $ ping >>= putMVar fin1
forkIO $ ping >>= putMVar fin2
takeMVar fin1
takeMVar fin2
{-# NOINLINE lock #-}
lock :: MVar ()
lock = unsafePerformIO $ newMVar ()
ping = do
() <- takeMVar lock
putMVar lock ()
```
I tested the program as follows:
```
> ghc --make -rtsopts -threaded Main.hs; while ./Main +RTS -N; do true; done
Main: thread blocked indefinitely in an MVar operation
```
I'm using ghc 7.2.1.
```
> ghc --info
[("Project name","The Glorious Glasgow Haskell Compilation System")
,("GCC extra via C opts"," -fwrapv")
,("C compiler command","/usr/bin/gcc")
,("C compiler flags"," -fno-stack-protector")
,("ar command","/usr/bin/ar")
,("ar flags","q")
,("ar supports at file","YES")
,("touch command","touch")
,("dllwrap command","/bin/false")
,("windres command","/bin/false")
,("perl command","/usr/bin/perl")
,("Project version","7.2.1")
,("Booter version","7.0.3")
,("Stage","2")
,("Build platform","x86_64-unknown-linux")
,("Host platform","x86_64-unknown-linux")
,("Target platform","x86_64-unknown-linux")
,("Have interpreter","YES")
,("Object splitting supported","YES")
,("Have native code generator","YES")
,("Support SMP","YES")
,("Unregisterised","NO")
,("Tables next to code","YES")
,("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","/opt/ghc-7.2.1/lib/ghc-7.2.1")
,("Global Package DB","/opt/ghc-7.2.1/lib/ghc-7.2.1/package.conf.d")
,("Gcc Linker flags","[]")
,("Ld Linker flags","[]")
]
```
`/proc/cpuinfo` lists 4 Intel(R) Core(TM) i7 CPU M 620 @ 2.67GHz cores.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.2.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Deadlock using unsafePerformIO to create a global MVar","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The following program occasionally terminates with a BlockedIndefinitelyOnMVar exception. This is unexpected.\r\n(According to SimonM, http://www.haskell.org/pipermail/glasgow-haskell-users/2011-October/021084.html)\r\n\r\n{{{\r\nimport Control.Concurrent\r\nimport Control.Exception\r\nimport Control.Monad\r\nimport System.IO.Unsafe\r\n\r\nmain :: IO ()\r\nmain = do\r\n -- evaluate lock -- adding this line fixes the problem\r\n\r\n fin1 <- newEmptyMVar\r\n fin2 <- newEmptyMVar\r\n\r\n forkIO $ ping >>= putMVar fin1\r\n forkIO $ ping >>= putMVar fin2\r\n\r\n takeMVar fin1\r\n takeMVar fin2\r\n\r\n{-# NOINLINE lock #-}\r\nlock :: MVar ()\r\nlock = unsafePerformIO $ newMVar ()\r\n\r\nping = do\r\n () <- takeMVar lock\r\n putMVar lock ()\r\n}}}\r\n\r\nI tested the program as follows:\r\n\r\n{{{\r\n> ghc --make -rtsopts -threaded Main.hs; while ./Main +RTS -N; do true; done\r\nMain: thread blocked indefinitely in an MVar operation\r\n}}}\r\n\r\nI'm using ghc 7.2.1.\r\n\r\n{{{\r\n> ghc --info\r\n [(\"Project name\",\"The Glorious Glasgow Haskell Compilation System\")\r\n ,(\"GCC extra via C opts\",\" -fwrapv\")\r\n ,(\"C compiler command\",\"/usr/bin/gcc\")\r\n ,(\"C compiler flags\",\" -fno-stack-protector\")\r\n ,(\"ar command\",\"/usr/bin/ar\")\r\n ,(\"ar flags\",\"q\")\r\n ,(\"ar supports at file\",\"YES\")\r\n ,(\"touch command\",\"touch\")\r\n ,(\"dllwrap command\",\"/bin/false\")\r\n ,(\"windres command\",\"/bin/false\")\r\n ,(\"perl command\",\"/usr/bin/perl\")\r\n ,(\"Project version\",\"7.2.1\")\r\n ,(\"Booter version\",\"7.0.3\")\r\n ,(\"Stage\",\"2\")\r\n ,(\"Build platform\",\"x86_64-unknown-linux\")\r\n ,(\"Host platform\",\"x86_64-unknown-linux\")\r\n ,(\"Target platform\",\"x86_64-unknown-linux\")\r\n ,(\"Have interpreter\",\"YES\")\r\n ,(\"Object splitting supported\",\"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 ,(\"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\",\"/opt/ghc-7.2.1/lib/ghc-7.2.1\")\r\n ,(\"Global Package DB\",\"/opt/ghc-7.2.1/lib/ghc-7.2.1/package.conf.d\")\r\n ,(\"Gcc Linker flags\",\"[]\")\r\n ,(\"Ld Linker flags\",\"[]\")\r\n ]\r\n}}}\r\n\r\n{{{/proc/cpuinfo}}} lists 4 Intel(R) Core(TM) i7 CPU M 620 @ 2.67GHz cores.","type_of_failure":"OtherFailure","blocking":[]} -->7.4.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/5557Code using seq has wrong strictness (too lazy)2019-07-07T18:54:45Zmichal.palkaCode using seq has wrong strictness (too lazy)Following snippet of code gets miscompiled regardless of optimisation level:
```
([seq (seq (tail ([]::[Int])) (\a -> error "aaa"))] !! 0) [1]
```
The result of printing the value is `[1]`, whereas the correct result should be throwing...Following snippet of code gets miscompiled regardless of optimisation level:
```
([seq (seq (tail ([]::[Int])) (\a -> error "aaa"))] !! 0) [1]
```
The result of printing the value is `[1]`, whereas the correct result should be throwing an error:
```
testModule: Prelude.tail: empty list
```
The same problem occurs if I try to run the code in GHCI.
Looking at the Core at -O0 suggests that the expression with two `seq`s gets transformed into the identity function, despite that `tail []` could (and will) crash. Since the problem is visible in Core, I mark this bug as independent of the architecture.
I tried it in GHC versions 7.2.1 and 7.3.20111013, which gave same wrong results.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.2.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Code using seq has wrong strictness (too lazy)","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.2.1","keywords":["lazy","seq","strict","strictness"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Following snippet of code gets miscompiled regardless of optimisation level:\r\n{{{\r\n([seq (seq (tail ([]::[Int])) (\\a -> error \"aaa\"))] !! 0) [1]\r\n}}}\r\n\r\nThe result of printing the value is `[1]`, whereas the correct result should be throwing an error:\r\n{{{\r\ntestModule: Prelude.tail: empty list\r\n}}}\r\n\r\nThe same problem occurs if I try to run the code in GHCI.\r\n\r\nLooking at the Core at -O0 suggests that the expression with two `seq`s gets transformed into the identity function, despite that `tail []` could (and will) crash. Since the problem is visible in Core, I mark this bug as independent of the architecture.\r\n\r\nI tried it in GHC versions 7.2.1 and 7.3.20111013, which gave same wrong results.","type_of_failure":"OtherFailure","blocking":[]} -->7.4.1https://gitlab.haskell.org/ghc/ghc/-/issues/5553sendWakeup error in simple test program with MVars and killThread2019-07-07T18:54:46ZbitsendWakeup error in simple test program with MVars and killThreadThe following test program causes a **sendWakeup** error to be printed. It happens rarely, not on every run of the program.
I'm running GHC 7.2.1 on a fairly old Linux 2.6.27 system.
Running it from the shell in a loop should cause it ...The following test program causes a **sendWakeup** error to be printed. It happens rarely, not on every run of the program.
I'm running GHC 7.2.1 on a fairly old Linux 2.6.27 system.
Running it from the shell in a loop should cause it to eventually display the error message. I found that by causing CPU activity (such as running "yes" in another terminal) while the shell loop below is running triggers the error.
```
$ ghc --make -Wall -O -threaded -rtsopts ghc_sendWakeup_bug.hs
$ while [ 1 ]; do ./ghc_sendWakeup_bug 40; done
ghc_sendWakeup_bug: sendWakeup: invalid argument (Bad file descriptor)
```
## ghc_sendWakeup_bug.hs
```
module Main
( startTest
, main
) where
import Control.Concurrent (ThreadId, forkIO, killThread, threadDelay)
import Control.Concurrent.MVar
import Control.Exception (finally, catch, SomeException, mask_)
import Control.Monad (when, replicateM_, forever)
import Prelude hiding (catch)
import System.Environment (getArgs, getProgName)
import System.Exit (exitFailure)
import System.IO (hPutStrLn, stderr)
startClient :: IO ()
startClient = threadDelay (1000 * 10)
startTest :: Int -> IO ()
startTest numClients = do
-- Code adapted from:
-- http://hackage.haskell.org/packages/archive/base/4.4.0.0/doc/html/Control-Concurrent.html#g:12
children <- newMVar [] :: IO (MVar [MVar ()])
let forkChild :: IO () -> IO ThreadId
forkChild io = do
mvar <- newEmptyMVar
mask_ $ do
modifyMVar_ children (return . (mvar:))
forkIO (io `finally` putMVar mvar ())
waitForChildren :: IO ()
waitForChildren = do
cs <- takeMVar children
case cs of
[] -> return ()
m:ms -> do
putMVar children ms
takeMVar m
waitForChildren
serverThread <- forkIO $ forever (threadDelay 1000000)
replicateM_ numClients (forkChild startClient)
catch waitForChildren (printException "waitForChildren")
catch (killThread serverThread) (printException "killThread")
printException :: String -> SomeException -> IO ()
printException place ex =
hPutStrLn stderr $ "Error in " ++ place ++ ": " ++ show ex
main :: IO ()
main = do
args <- getArgs
when (length args /= 1) $ do
prog <- getProgName
hPutStrLn stderr $ "Usage: " ++ prog ++ " <numClients>"
exitFailure
let numClients = read (args !! 0)
startTest numClients
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.2.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"sendWakeup error in simple test program with MVars and killThread","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The following test program causes a '''sendWakeup''' error to be printed. It happens rarely, not on every run of the program.\r\n\r\nI'm running GHC 7.2.1 on a fairly old Linux 2.6.27 system.\r\n\r\nRunning it from the shell in a loop should cause it to eventually display the error message. I found that by causing CPU activity (such as running \"yes\" in another terminal) while the shell loop below is running triggers the error.\r\n\r\n{{{\r\n\r\n$ ghc --make -Wall -O -threaded -rtsopts ghc_sendWakeup_bug.hs\r\n$ while [ 1 ]; do ./ghc_sendWakeup_bug 40; done\r\nghc_sendWakeup_bug: sendWakeup: invalid argument (Bad file descriptor)\r\n\r\n}}}\r\n\r\n\r\n== ghc_sendWakeup_bug.hs ==\r\n\r\n{{{\r\n\r\nmodule Main\r\n ( startTest\r\n , main\r\n ) where\r\n\r\nimport Control.Concurrent (ThreadId, forkIO, killThread, threadDelay)\r\nimport Control.Concurrent.MVar\r\nimport Control.Exception (finally, catch, SomeException, mask_)\r\nimport Control.Monad (when, replicateM_, forever)\r\nimport Prelude hiding (catch)\r\nimport System.Environment (getArgs, getProgName)\r\nimport System.Exit (exitFailure)\r\nimport System.IO (hPutStrLn, stderr)\r\n\r\nstartClient :: IO ()\r\nstartClient = threadDelay (1000 * 10)\r\n\r\nstartTest :: Int -> IO ()\r\nstartTest numClients = do\r\n -- Code adapted from:\r\n -- http://hackage.haskell.org/packages/archive/base/4.4.0.0/doc/html/Control-Concurrent.html#g:12\r\n children <- newMVar [] :: IO (MVar [MVar ()])\r\n\r\n let forkChild :: IO () -> IO ThreadId\r\n forkChild io = do\r\n mvar <- newEmptyMVar\r\n mask_ $ do\r\n modifyMVar_ children (return . (mvar:))\r\n forkIO (io `finally` putMVar mvar ())\r\n waitForChildren :: IO ()\r\n waitForChildren = do\r\n cs <- takeMVar children\r\n case cs of\r\n [] -> return ()\r\n m:ms -> do\r\n putMVar children ms\r\n takeMVar m\r\n waitForChildren\r\n\r\n serverThread <- forkIO $ forever (threadDelay 1000000)\r\n\r\n replicateM_ numClients (forkChild startClient)\r\n catch waitForChildren (printException \"waitForChildren\")\r\n catch (killThread serverThread) (printException \"killThread\")\r\n\r\nprintException :: String -> SomeException -> IO ()\r\nprintException place ex =\r\n hPutStrLn stderr $ \"Error in \" ++ place ++ \": \" ++ show ex\r\n\r\nmain :: IO ()\r\nmain = do\r\n args <- getArgs\r\n when (length args /= 1) $ do\r\n prog <- getProgName\r\n hPutStrLn stderr $ \"Usage: \" ++ prog ++ \" <numClients>\"\r\n exitFailure\r\n let numClients = read (args !! 0)\r\n startTest numClients\r\n\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.2.2tibbetibbehttps://gitlab.haskell.org/ghc/ghc/-/issues/5512UTF-16//ROUNDTRIP encoding behaves weirdly2019-07-07T18:54:57ZbatterseapowerUTF-16//ROUNDTRIP encoding behaves weirdlyTry this program:
```
module Main where
import System.IO
main = do
roundtrip_enc <- mkTextEncoding "UTF16//ROUNDTRIP"
h <- openFile "out.temp" WriteMode
hSetEncoding h roundtrip_enc
hPutStr h "Hi\xEFE8Hi"
```
It fails...Try this program:
```
module Main where
import System.IO
main = do
roundtrip_enc <- mkTextEncoding "UTF16//ROUNDTRIP"
h <- openFile "out.temp" WriteMode
hSetEncoding h roundtrip_enc
hPutStr h "Hi\xEFE8Hi"
```
It fails with:
```
hSetEncoding: invalid argument (Invalid argument)
```
If you change UTF16 to UTF-16 (so we use the builtin encoding rather than iconv) it works, but the output file only contains the first Hi.
I think part of what is going on here is that iconv does not generate EILSEQ for identity transformations such as that between a UTF-16 text file and our UTF-16 CharBuffers. Since we never get that exception, we can't fix up the lone surrogates we use to encode roundtrip characters.7.4.1https://gitlab.haskell.org/ghc/ghc/-/issues/5501randomR overflow2019-07-07T18:54:59Zdaniel.is.fischerrandomR overflowWhen given a large range, `randomR` overflows at `Double` etc.
`randomIvalDouble` has two problems: first, the calculation of the center, `(l+h)/2` overflows if the range is located near `±Infinity`; second, and that concerns also `rand...When given a large range, `randomR` overflows at `Double` etc.
`randomIvalDouble` has two problems: first, the calculation of the center, `(l+h)/2` overflows if the range is located near `±Infinity`; second, and that concerns also `randomRFloating`, the scaling factor `(h-l)` overflows if the range is large enough.
Both problems can be fixed "well enough" by multiplying the bounds by 0.5 before the calculations and scaling up at the end,
```
0.5*l + 0.5*h instead of (l+h)/2
(0.5*h - 0.5*l)/(0.5*realToFrac int32Count) in randomIvalDouble
2.0*(0.5*l + coef*(0.5*h - 0.5*l)) in randomRFloating
```
These transformations can introduce a small error when a subnormal number is involved, but I think we can ignore that (no sane person would have a \[nonzero\] subnormal number as a bound, and a correct-for-all-cases transformation would be somewhat convoluted).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 7.2.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/random |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"randomR overflow","status":"New","operating_system":"","component":"libraries/random","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When given a large range, `randomR` overflows at `Double` etc.\r\n\r\n`randomIvalDouble` has two problems: first, the calculation of the center, `(l+h)/2` overflows if the range is located near `±Infinity`; second, and that concerns also `randomRFloating`, the scaling factor `(h-l)` overflows if the range is large enough.\r\n\r\nBoth problems can be fixed \"well enough\" by multiplying the bounds by 0.5 before the calculations and scaling up at the end,\r\n{{{\r\n0.5*l + 0.5*h instead of (l+h)/2\r\n(0.5*h - 0.5*l)/(0.5*realToFrac int32Count) in randomIvalDouble\r\n2.0*(0.5*l + coef*(0.5*h - 0.5*l)) in randomRFloating\r\n}}}\r\nThese transformations can introduce a small error when a subnormal number is involved, but I think we can ignore that (no sane person would have a [nonzero] subnormal number as a bound, and a correct-for-all-cases transformation would be somewhat convoluted).\r\n","type_of_failure":"OtherFailure","blocking":[]} -->rrnewtonrrnewtonhttps://gitlab.haskell.org/ghc/ghc/-/issues/5477Missing space in Windows cmd.exe invocation breaks shell command invocation o...2019-07-07T18:55:06ZA1kmmMissing space in Windows cmd.exe invocation breaks shell command invocation on WineConsider this code example:
```
import System.Process
main = system "ghc --version"
```
When compiled and run on Wine, using process-1.1.0.0 or the latest version pushed to the git repository at the time of writing, the result is a cm...Consider this code example:
```
import System.Process
main = system "ghc --version"
```
When compiled and run on Wine, using process-1.1.0.0 or the latest version pushed to the git repository at the time of writing, the result is a cmd.exe prompt appears, rather than giving the current ghc version; the program exits when exit is typed into the shell without displaying the ghc version.
The reason for this is that System/Process/Internals.hs builds the command line like this: translate cmd ++ "/c " ++ string
The fact that there is no space between the path to cmd.exe and the /c argument causes Wine to ignore the /c flag (which would otherwise tell it to execute a command from the command line, rather than run in interactive mode).
I attach a patch which fixes this problem.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 7.2.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/process |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Missing space in Windows cmd.exe invocation breaks shell command invocation on Wine","status":"New","operating_system":"","component":"libraries/process","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Consider this code example:\r\n{{{\r\nimport System.Process\r\n\r\nmain = system \"ghc --version\"\r\n}}}\r\n\r\nWhen compiled and run on Wine, using process-1.1.0.0 or the latest version pushed to the git repository at the time of writing, the result is a cmd.exe prompt appears, rather than giving the current ghc version; the program exits when exit is typed into the shell without displaying the ghc version.\r\n\r\nThe reason for this is that System/Process/Internals.hs builds the command line like this: translate cmd ++ \"/c \" ++ string\r\n\r\nThe fact that there is no space between the path to cmd.exe and the /c argument causes Wine to ignore the /c flag (which would otherwise tell it to execute a command from the command line, rather than run in interactive mode).\r\n\r\nI attach a patch which fixes this problem.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/5440Unexpected SafeLang13 failure2019-07-07T18:55:15Zdaniel.is.fischerUnexpected SafeLang13 failureDuring a validate run, SafeLang13 unexpectedly failed with differing stdout:
```
H "Hello World"
G 1
+Should be 3 := 2
+G 2
Should be 3 := 3
-G 3
-Should be 3 := 4
```
Running the test alone afterwards passed repeatedly, so it looks...During a validate run, SafeLang13 unexpectedly failed with differing stdout:
```
H "Hello World"
G 1
+Should be 3 := 2
+G 2
Should be 3 := 3
-G 3
-Should be 3 := 4
```
Running the test alone afterwards passed repeatedly, so it looks like a weird interaction on a busy box.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.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":"Unexpected SafeLang13 failure","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"During a validate run, SafeLang13 unexpectedly failed with differing stdout:\r\n{{{\r\n H \"Hello World\"\r\n G 1\r\n+Should be 3 := 2\r\n+G 2\r\n Should be 3 := 3\r\n-G 3\r\n-Should be 3 := 4\r\n}}}\r\nRunning the test alone afterwards passed repeatedly, so it looks like a weird interaction on a busy box.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/5438Wrong result for element check2019-07-07T18:55:15Zdaniel.is.fischerWrong result for element checkOn the [beginners](http://haskell.org/pipermail/beginners/2011-August/008422.html) list, Luca Ciciriello reported that
```
{-# LANGUAGE PArr #-}
{-# OPTIONS -fdph-seq #-}
module Main where
import Control.Parallel
import GHC.PArr
parA...On the [beginners](http://haskell.org/pipermail/beginners/2011-August/008422.html) list, Luca Ciciriello reported that
```
{-# LANGUAGE PArr #-}
{-# OPTIONS -fdph-seq #-}
module Main where
import Control.Parallel
import GHC.PArr
parArr :: [:String:]
parArr = [: "1", "2", "3", "4" :]
isElement :: String -> Bool
isElement x = x `elemP` parArr
main :: IO ()
main = do
putStrLn $ (show . isElement) "5"
```
prints True. Obviously it should print False. I've replicated the behaviour with 7.0.4 and 6.10.4 on 64-bit linux (Luca tested on Mac and Windows).
As far as I can tell, elemP no longer exists in dph, so I had to modify to test with HEAD, and
```
{-# LANGUAGE ParallelArrays #-}
{-# OPTIONS -fdph-seq #-}
module Main where
import GHC.PArr
import Data.Array.Parallel
parArr :: [:String:]
parArr = [: "1", "2", "3", "4" :]
isElement :: String -> Bool
isElement x = x `elemP1` parArr
where
elemP1 :: Eq a => a -> [:a:] -> Bool
elemP1 v ar = lengthP (filterP (== v) ar) /= 0
main :: IO ()
main = do
putStrLn $ (show . isElement) "5"
```
also prints True with HEAD, but prints False with 6.10.4 and 7.0.4 (with the necessary modifications, !ParallelArrays -\> PArr, don't import Data.Array.Parallel).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | --------------------- |
| Version | 7.0.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Data Parallel Haskell |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Wrong result for element check","status":"New","operating_system":"","component":"Data Parallel Haskell","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"On the [http://haskell.org/pipermail/beginners/2011-August/008422.html beginners] list, Luca Ciciriello reported that\r\n{{{\r\n{-# LANGUAGE PArr #-}\r\n{-# OPTIONS -fdph-seq #-}\r\n\r\nmodule Main where\r\n\r\nimport Control.Parallel\r\nimport GHC.PArr\r\n\r\nparArr :: [:String:]\r\nparArr = [: \"1\", \"2\", \"3\", \"4\" :]\r\n\r\nisElement :: String -> Bool\r\nisElement x = x `elemP` parArr\r\n\r\nmain :: IO ()\r\nmain = do\r\n putStrLn $ (show . isElement) \"5\"\r\n}}}\r\nprints True. Obviously it should print False. I've replicated the behaviour with 7.0.4 and 6.10.4 on 64-bit linux (Luca tested on Mac and Windows).\r\n\r\nAs far as I can tell, elemP no longer exists in dph, so I had to modify to test with HEAD, and\r\n{{{\r\n{-# LANGUAGE ParallelArrays #-}\r\n{-# OPTIONS -fdph-seq #-}\r\n\r\nmodule Main where\r\n\r\nimport GHC.PArr\r\nimport Data.Array.Parallel\r\n\r\nparArr :: [:String:]\r\nparArr = [: \"1\", \"2\", \"3\", \"4\" :]\r\n\r\nisElement :: String -> Bool\r\nisElement x = x `elemP1` parArr\r\n where\r\n elemP1 :: Eq a => a -> [:a:] -> Bool\r\n elemP1 v ar = lengthP (filterP (== v) ar) /= 0\r\n\r\nmain :: IO ()\r\nmain = do\r\n putStrLn $ (show . isElement) \"5\"\r\n}}}\r\nalso prints True with HEAD, but prints False with 6.10.4 and 7.0.4 (with the necessary modifications, !ParallelArrays -> PArr, don't import Data.Array.Parallel).","type_of_failure":"OtherFailure","blocking":[]} -->7.4.1benlbenlhttps://gitlab.haskell.org/ghc/ghc/-/issues/5421<<loop>> in withMVar (reproducible, but with large test case)2019-07-07T18:55:26Zjmillikin<<loop>> in withMVar (reproducible, but with large test case)A user of one of my libraries is reporting that it fails with the message `<<loop>>` when compiled in GHC 7.2.1. The error is coming from `withMVar`, and is reproducible.
Unfortunately, the problem is \*very\* tricky to reproduce. Attem...A user of one of my libraries is reporting that it fails with the message `<<loop>>` when compiled in GHC 7.2.1. The error is coming from `withMVar`, and is reproducible.
Unfortunately, the problem is \*very\* tricky to reproduce. Attempting to debug it (such as adding print statements, re-ordering operations, or removing unrelated code) will cause it to vanish. Therefore, the test case I have attached is a full Cabal project with build instructions. Nearly every line of code is required, and changing or removing them hides the error again.
Changes which can hide the problem:
- Altering or removing the startup messages (even the version number).
- Removing unused attributes from types.
- Removing unused error checking.
- Using `_ <- char 'a'` instead of `void (char 'a')`.
- Moving a function from one module to another.
- Simplifying loops which only run over one element.
- Building it all at once with `--make`, and not a separate `cabal-dev install` step.
- Building 'Main' with `-O2`.7.4.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/5410Template Haskell - splicing quoted instance decls mangles names2019-07-07T18:55:29ZmokusTemplate Haskell - splicing quoted instance decls mangles namesWhen updating a library of mine (random-fu) to build on GHC 7.2.1, I found that TH-generated instance declarations were universally broken; they did not have any class functions implemented, where in earlier versions of GHC there has nev...When updating a library of mine (random-fu) to build on GHC 7.2.1, I found that TH-generated instance declarations were universally broken; they did not have any class functions implemented, where in earlier versions of GHC there has never been a problem. I was able to reduce it to a very trivial case which shows that quoting and splicing is not a no-op as it seems it should be.
The entire failing case consists of:
```
{-# LANGUAGE TemplateHaskell #-}
module GHC_7_2_1_bug where
$([d| instance Show (a -> b) where
showsPrec _ _ = showString "<function>"
|])
```
which generates the following splice:
```
instance Show (a_a1uB -> b_a1uC) where
{ showsPrec_a1uD _ _ = showString "<function>" }
```
As would be expected from looking at the splice, there is no showsPrec definition, and typing "id" at the GHCi prompt gives an infinite loop from the cyclic defaults.
BTW, there is no "version" entry in the ticket reporting interface for 7.2.1, so I've left that unspecified.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Template Haskell |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Template Haskell - splicing quoted instance decls mangles names","status":"New","operating_system":"","component":"Template Haskell","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When updating a library of mine (random-fu) to build on GHC 7.2.1, I found that TH-generated instance declarations were universally broken; they did not have any class functions implemented, where in earlier versions of GHC there has never been a problem. I was able to reduce it to a very trivial case which shows that quoting and splicing is not a no-op as it seems it should be.\r\n\r\nThe entire failing case consists of:\r\n\r\n{{{\r\n{-# LANGUAGE TemplateHaskell #-}\r\nmodule GHC_7_2_1_bug where\r\n\r\n$([d| instance Show (a -> b) where\r\n showsPrec _ _ = showString \"<function>\"\r\n |])\r\n\r\n}}}\r\n\r\nwhich generates the following splice:\r\n\r\n{{{\r\n instance Show (a_a1uB -> b_a1uC) where\r\n { showsPrec_a1uD _ _ = showString \"<function>\" }\r\n}}}\r\n\r\nAs would be expected from looking at the splice, there is no showsPrec definition, and typing \"id\" at the GHCi prompt gives an infinite loop from the cyclic defaults.\r\n\r\nBTW, there is no \"version\" entry in the ticket reporting interface for 7.2.1, so I've left that unspecified.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/5409Language.Haskell.TH.Syntax.tupleDataName wrong for unit2019-07-07T18:55:29ZNeil MitchellLanguage.Haskell.TH.Syntax.tupleDataName wrong for unit`tupleDataName 0` generates the name `GHC.Tuple.()`, but that's wrong, it should be `GHC.Unit.()` (even worse, the source code actually has `-- XXX Should it be GHC.Unit for 0 commas?` - which is a correct observation)
<details><summary...`tupleDataName 0` generates the name `GHC.Tuple.()`, but that's wrong, it should be `GHC.Unit.()` (even worse, the source code actually has `-- XXX Should it be GHC.Unit for 0 commas?` - which is a correct observation)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------------- |
| Version | 7.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Template Haskell |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ndmitchell@gmail.com |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Language.Haskell.TH.Syntax.tupleDataName wrong for unit","status":"New","operating_system":"","component":"Template Haskell","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ndmitchell@gmail.com"],"type":"Bug","description":"{{{tupleDataName 0}}} generates the name {{{GHC.Tuple.()}}}, but that's wrong, it should be {{{GHC.Unit.()}}} (even worse, the source code actually has {{{-- XXX Should it be GHC.Unit for 0 commas?}}} - which is a correct observation)","type_of_failure":"OtherFailure","blocking":[]} -->