GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2021-12-15T16:11:17Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/9390Inlining prevents evaluation of ignored parts of unboxed tuples2021-12-15T16:11:17ZMichael Snoymanmichael@snoyman.comInlining prevents evaluation of ignored parts of unboxed tuplesConsider the following code:
```hs
{-# LANGUAGE MagicHash, UnboxedTuples #-}
import GHC.IO (IO (..))
import GHC.Prim
writeB :: MutableArray# RealWorld Char -> IO ()
writeB arr# =
IO $ \s0# ->
(# writeArray# arr# 0# 'B' s0#,...Consider the following code:
```hs
{-# LANGUAGE MagicHash, UnboxedTuples #-}
import GHC.IO (IO (..))
import GHC.Prim
writeB :: MutableArray# RealWorld Char -> IO ()
writeB arr# =
IO $ \s0# ->
(# writeArray# arr# 0# 'B' s0#, () #)
inlineWriteB :: MutableArray# RealWorld Char -> ()
inlineWriteB arr# =
case f realWorld# of
(# _, x #) -> x
where
IO f = writeB arr#
test :: IO Char
test = IO $ \s0# ->
case newArray# 1# 'A' s0# of
(# s1#, arr# #) ->
case seq# (inlineWriteB arr#) s1# of
(# s2#, () #) ->
readArray# arr# 0# s2#
main :: IO ()
main = test >>= print
```
I would expect this code to output the letter 'B'. When compiled without optimizations, that's exactly what it does. However, with optimizations turned on, it seems that it decides that, in `inlineWriteB`, the state value does not need to be evaluated, which results in the `writeArray#` call never occurring.
This affected me when working with the vector and primitive packages. I believe I have a workaround in place (see https://github.com/haskell/primitive/pull/11), but this should probably be fixed in GHC as well.
<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":"Inlining prevents evaluation of ignored parts of unboxed tuples","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":"Consider the following code:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE MagicHash, UnboxedTuples #-}\r\nimport GHC.IO (IO (..))\r\nimport GHC.Prim\r\n\r\nwriteB :: MutableArray# RealWorld Char -> IO ()\r\nwriteB arr# =\r\n IO $ \\s0# ->\r\n (# writeArray# arr# 0# 'B' s0#, () #)\r\n\r\ninlineWriteB :: MutableArray# RealWorld Char -> ()\r\ninlineWriteB arr# =\r\n case f realWorld# of\r\n (# _, x #) -> x\r\n where\r\n IO f = writeB arr#\r\n\r\ntest :: IO Char\r\ntest = IO $ \\s0# ->\r\n case newArray# 1# 'A' s0# of\r\n (# s1#, arr# #) ->\r\n case seq# (inlineWriteB arr#) s1# of\r\n (# s2#, () #) ->\r\n readArray# arr# 0# s2#\r\n\r\nmain :: IO ()\r\nmain = test >>= print\r\n}}}\r\n\r\nI would expect this code to output the letter 'B'. When compiled without optimizations, that's exactly what it does. However, with optimizations turned on, it seems that it decides that, in `inlineWriteB`, the state value does not need to be evaluated, which results in the `writeArray#` call never occurring.\r\n\r\nThis affected me when working with the vector and primitive packages. I believe I have a workaround in place (see https://github.com/haskell/primitive/pull/11), but this should probably be fixed in GHC as well.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.4https://gitlab.haskell.org/ghc/ghc/-/issues/8849Unregisterised compiler: arithmetic failure2019-07-07T18:43:07ZPeter Trommlerptrommler@acm.orgUnregisterised compiler: arithmetic failureCompiling the following with RC2 on powerpc 64 downloaded from haskell.org:
```
main = putStr $ show (-1.0000000001 :: Double)
```
Setting `-O` yields:
```
0.0
```
Without optimization the correct result is displayed.
I prepared an ...Compiling the following with RC2 on powerpc 64 downloaded from haskell.org:
```
main = putStr $ show (-1.0000000001 :: Double)
```
Setting `-O` yields:
```
0.0
```
Without optimization the correct result is displayed.
I prepared an unregisterised compiler on amd64 and see the same issue and more arithmetic tests fail in testsuite. In fact I took the above from arith005.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 7.8.1-rc2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown/Multiple |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Unregisterised compiler: arithmetic failure","status":"New","operating_system":"Unknown/Multiple","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.1-rc2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Compiling the following with RC2 on powerpc 64 downloaded from haskell.org:\r\n{{{\r\nmain = putStr $ show (-1.0000000001 :: Double)\r\n}}}\r\nSetting {{{-O}}} yields:\r\n{{{\r\n0.0\r\n}}}\r\nWithout optimization the correct result is displayed.\r\n\r\nI prepared an unregisterised compiler on amd64 and see the same issue and more arithmetic tests fail in testsuite. In fact I took the above from arith005.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.4https://gitlab.haskell.org/ghc/ghc/-/issues/10078tcPluginStop of a type checker plugin is not called if an error occurs2019-07-07T18:37:39ZjbrackertcPluginStop of a type checker plugin is not called if an error occursWhen a module using a type checker plugin produces a compiler error the clean up function `tcPluginStop` of the plugin is not called.
I am not sure if this is intended, but according to the description of the wiki page (Plugins/TypeChec...When a module using a type checker plugin produces a compiler error the clean up function `tcPluginStop` of the plugin is not called.
I am not sure if this is intended, but according to the description of the wiki page (Plugins/TypeChecker) this should always be called.
### Test plugin
`MyPlugin.hs`:
```hs
module MyPlugin
( plugin ) where
import Plugins
import TcRnTypes
import TcPluginM
plugin :: Plugin
plugin = defaultPlugin
{ tcPlugin = \clos -> Just $ TcPlugin
{ tcPluginInit = tcPluginIO $ putStrLn ">>> Plugin Init"
, tcPluginSolve = \_ _ _ _ -> do
tcPluginIO $ putStrLn ">>> Plugin Solve"
return $ TcPluginOk [] []
, tcPluginStop = \_ -> tcPluginIO $ putStrLn ">>> Plugin Stop"
}
}
```
### Minimal example (with type error)
`Main.hs`:
```hs
{-# OPTIONS_GHC -fplugin MyPlugin #-}
module Main where
main :: (Monad m) => m ()
main = do
return 1
```
Compiling this will lead to the following output:
```
$ ~/ghc/inplace/bin/ghc-stage2 --make -package ghc-7.11.20150209 -dynamic Main.hs
[2 of 2] Compiling Main ( Main.hs, Main.o )
>>> Plugin Init
>>> Plugin Solve
>>> Plugin Solve
>>> Plugin Solve
Main.hs:6:10:
Could not deduce (Num ()) arising from the literal ‘1’
from the context: Monad m
bound by the type signature for: main :: Monad m => m ()
at Main.hs:4:9-25
In the first argument of ‘return’, namely ‘1’
In a stmt of a 'do' block: return 1
In the expression: do { return 1 }
```
Which means `tcPluginStop` was _not_ called.
### Minimal example (without type error)
`Main.hs`:
```hs
{-# OPTIONS_GHC -fplugin MyPlugin #-}
module Main where
main :: (Monad m) => m ()
main = do
return ()
```
Compiling this will lead to the following output:
```
$ ~/ghc/inplace/bin/ghc-stage2 --make -package ghc-7.11.20150209 -dynamic Main.hs
[2 of 2] Compiling Main ( Main.hs, Main.o ) [MyPlugin changed]
>>> Plugin Init
>>> Plugin Solve
>>> Plugin Solve
>>> Plugin Stop
Linking Main ...
```
Which means `tcPluginStop` _was_ called.
### Possible solution
As far as I can see, the solution to this should be to change the plugin code at the bottom of `typechecker/TcRnDriver.hs` from
```hs
withTcPlugins :: HscEnv -> TcM a -> TcM a
withTcPlugins hsc_env m =
do plugins <- liftIO (loadTcPlugins hsc_env)
case plugins of
[] -> m -- Common fast case
_ -> do (solvers,stops) <- unzip `fmap` mapM startPlugin plugins
res <- updGblEnv (\e -> e { tcg_tc_plugins = solvers }) m
mapM_ runTcPluginM stops
return res
where
startPlugin (TcPlugin start solve stop) =
do s <- runTcPluginM start
return (solve s, stop s)
```
to
```hs
withTcPlugins :: HscEnv -> TcM a -> TcM a
withTcPlugins hsc_env m =
do plugins <- liftIO (loadTcPlugins hsc_env)
case plugins of
[] -> m -- Common fast case
_ -> do (solvers,stops) <- unzip `fmap` mapM startPlugin plugins
eitherRes <- tryM $ do updGblEnv (\e -> e { tcg_tc_plugins = solvers }) m
mapM_ runTcPluginM stops
case eitherRes of
Left e -> failM
Right res -> return res
where
startPlugin (TcPlugin start solve stop) =
do s <- runTcPluginM start
return (solve s, stop s)
```
.
I have tried this. It compiles and my minimal example delivers the correct result.
Are there any arguments against this change? If not, I would try to commit a patch for this problem sometime this weekend.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.11 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | adamgundry |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"tcPluginStop of a type checker plugin is not called if an error occurs","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["adamgundry"],"type":"Bug","description":"When a module using a type checker plugin produces a compiler error the clean up function `tcPluginStop` of the plugin is not called.\r\n\r\nI am not sure if this is intended, but according to the description of the wiki page (Plugins/TypeChecker) this should always be called.\r\n\r\n=== Test plugin\r\n\r\n`MyPlugin.hs`:\r\n{{{#!hs\r\nmodule MyPlugin\r\n ( plugin ) where\r\n\r\nimport Plugins\r\nimport TcRnTypes\r\nimport TcPluginM\r\n\r\nplugin :: Plugin\r\nplugin = defaultPlugin \r\n { tcPlugin = \\clos -> Just $ TcPlugin \r\n { tcPluginInit = tcPluginIO $ putStrLn \">>> Plugin Init\"\r\n , tcPluginSolve = \\_ _ _ _ -> do\r\n tcPluginIO $ putStrLn \">>> Plugin Solve\"\r\n return $ TcPluginOk [] []\r\n , tcPluginStop = \\_ -> tcPluginIO $ putStrLn \">>> Plugin Stop\"\r\n }\r\n }\r\n}}}\r\n\r\n=== Minimal example (with type error)\r\n\r\n`Main.hs`:\r\n{{{#!hs\r\n{-# OPTIONS_GHC -fplugin MyPlugin #-}\r\nmodule Main where\r\n\r\nmain :: (Monad m) => m ()\r\nmain = do\r\n return 1\r\n}}}\r\n\r\nCompiling this will lead to the following output:\r\n{{{\r\n$ ~/ghc/inplace/bin/ghc-stage2 --make -package ghc-7.11.20150209 -dynamic Main.hs\r\n[2 of 2] Compiling Main ( Main.hs, Main.o )\r\n>>> Plugin Init\r\n>>> Plugin Solve\r\n>>> Plugin Solve\r\n>>> Plugin Solve\r\n\r\nMain.hs:6:10:\r\n Could not deduce (Num ()) arising from the literal ‘1’\r\n from the context: Monad m\r\n bound by the type signature for: main :: Monad m => m ()\r\n at Main.hs:4:9-25\r\n In the first argument of ‘return’, namely ‘1’\r\n In a stmt of a 'do' block: return 1\r\n In the expression: do { return 1 }\r\n}}}\r\nWhich means `tcPluginStop` was _not_ called.\r\n\r\n=== Minimal example (without type error)\r\n\r\n`Main.hs`:\r\n{{{#!hs\r\n{-# OPTIONS_GHC -fplugin MyPlugin #-}\r\nmodule Main where\r\n\r\nmain :: (Monad m) => m ()\r\nmain = do\r\n return ()\r\n}}}\r\n\r\nCompiling this will lead to the following output:\r\n{{{\r\n$ ~/ghc/inplace/bin/ghc-stage2 --make -package ghc-7.11.20150209 -dynamic Main.hs\r\n[2 of 2] Compiling Main ( Main.hs, Main.o ) [MyPlugin changed]\r\n>>> Plugin Init\r\n>>> Plugin Solve\r\n>>> Plugin Solve\r\n>>> Plugin Stop\r\nLinking Main ...\r\n}}}\r\nWhich means `tcPluginStop` _was_ called.\r\n\r\n=== Possible solution\r\n\r\nAs far as I can see, the solution to this should be to change the plugin code at the bottom of `typechecker/TcRnDriver.hs` from\r\n{{{#!hs\r\nwithTcPlugins :: HscEnv -> TcM a -> TcM a\r\nwithTcPlugins hsc_env m =\r\n do plugins <- liftIO (loadTcPlugins hsc_env)\r\n case plugins of\r\n [] -> m -- Common fast case\r\n _ -> do (solvers,stops) <- unzip `fmap` mapM startPlugin plugins\r\n res <- updGblEnv (\\e -> e { tcg_tc_plugins = solvers }) m\r\n mapM_ runTcPluginM stops\r\n return res\r\n where\r\n startPlugin (TcPlugin start solve stop) =\r\n do s <- runTcPluginM start\r\n return (solve s, stop s)\r\n}}}\r\nto\r\n{{{#!hs\r\nwithTcPlugins :: HscEnv -> TcM a -> TcM a\r\nwithTcPlugins hsc_env m =\r\n do plugins <- liftIO (loadTcPlugins hsc_env)\r\n case plugins of\r\n [] -> m -- Common fast case\r\n _ -> do (solvers,stops) <- unzip `fmap` mapM startPlugin plugins\r\n eitherRes <- tryM $ do updGblEnv (\\e -> e { tcg_tc_plugins = solvers }) m\r\n mapM_ runTcPluginM stops\r\n case eitherRes of\r\n Left e -> failM\r\n Right res -> return res\r\n where\r\n startPlugin (TcPlugin start solve stop) =\r\n do s <- runTcPluginM start\r\n return (solve s, stop s)\r\n}}}\r\n.\r\n\r\nI have tried this. It compiles and my minimal example delivers the correct result.\r\n\r\nAre there any arguments against this change? If not, I would try to commit a patch for this problem sometime this weekend.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1jbrackerjbrackerhttps://gitlab.haskell.org/ghc/ghc/-/issues/10017signal handlers are invoked multiple times when the threaded rts is used2019-07-07T18:37:55Zrednebsignal handlers are invoked multiple times when the threaded rts is usedWhen you install a custom signal handler and the threaded rts is being used, then the signal handler will be invoked multiple times. Here's a program that the demonstrates this:
```hs
import Control.Concurrent
import System.Posix.Signal...When you install a custom signal handler and the threaded rts is being used, then the signal handler will be invoked multiple times. Here's a program that the demonstrates this:
```hs
import Control.Concurrent
import System.Posix.Signals
main :: IO ()
main = do
_ <- flip (installHandler sig) Nothing $ Catch $
putStrLn $ "Received signal " ++ show sig
raiseSignal sig
threadDelay 100000
where
sig = sigUSR2
```
If you compile this with the `-threaded` flag and then run it with say `+RTS -N4` then it produces the following output:
```
Received signal 12
Received signal 12
Received signal 12
Received signal 12
Received signal 12
```
In general the signal handler is invoked `n_capabilities+1` times. This also happens with all other signals.
This regression was introduced by f9f89b7884ccc8ee5047cf4fffdf2b36df6832df (which was later \[changeset:4748f5936fe72d96edfa17b153dbfd84f2c4c053 reverted\] but then \[changeset:7e658bc14e2dd6baf208deebbdab9e1285ce4c72 re-added\]), a commit addressing #9423.
The cause of the problem is \[source:/rts/posix/Signals.c\@f44bbc83bab62f9a2d25e69d87c2b4af25318d52\#L256 this\] loop. I don't understand why we need to write an event about the signal received in the per capability control pipe introduced by the aforementioned commit. Aren't these control pipes supposed only to be used to shutdown the capabilities (which happens \[source:/rts/posix/Signals.c\@f44bbc83bab62f9a2d25e69d87c2b4af25318d52\#L183 here\])?
Removing the loop seems to solve the issue, but I don't know if it makes #9423 reappear. I cannot test this on a Mac OS X right now.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------------ |
| Version | 7.10.1-rc1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | AndreasVoellmy, simonmar |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"signal handlers are invoked multiple times when the threaded rts is used","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"simonmar"},"version":"7.10.1-rc1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["AndreasVoellmy","simonmar"],"type":"Bug","description":"When you install a custom signal handler and the threaded rts is being used, then the signal handler will be invoked multiple times. Here's a program that the demonstrates this:\r\n\r\n{{{#!hs\r\nimport Control.Concurrent\r\nimport System.Posix.Signals\r\n\r\nmain :: IO ()\r\nmain = do\r\n _ <- flip (installHandler sig) Nothing $ Catch $\r\n putStrLn $ \"Received signal \" ++ show sig\r\n raiseSignal sig\r\n threadDelay 100000\r\n where\r\n sig = sigUSR2\r\n}}}\r\n\r\nIf you compile this with the `-threaded` flag and then run it with say `+RTS -N4` then it produces the following output:\r\n\r\n{{{\r\nReceived signal 12\r\nReceived signal 12\r\nReceived signal 12\r\nReceived signal 12\r\nReceived signal 12\r\n}}}\r\n\r\nIn general the signal handler is invoked `n_capabilities+1` times. This also happens with all other signals.\r\n\r\nThis regression was introduced by f9f89b7884ccc8ee5047cf4fffdf2b36df6832df (which was later [changeset:4748f5936fe72d96edfa17b153dbfd84f2c4c053 reverted] but then [changeset:7e658bc14e2dd6baf208deebbdab9e1285ce4c72 re-added]), a commit addressing #9423.\r\n\r\nThe cause of the problem is [source:/rts/posix/Signals.c@f44bbc83bab62f9a2d25e69d87c2b4af25318d52#L256 this] loop. I don't understand why we need to write an event about the signal received in the per capability control pipe introduced by the aforementioned commit. Aren't these control pipes supposed only to be used to shutdown the capabilities (which happens [source:/rts/posix/Signals.c@f44bbc83bab62f9a2d25e69d87c2b4af25318d52#L183 here])?\r\n\r\nRemoving the loop seems to solve the issue, but I don't know if it makes #9423 reappear. I cannot test this on a Mac OS X right now.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1AndreasVoellmyAndreasVoellmyhttps://gitlab.haskell.org/ghc/ghc/-/issues/9955ghc-stage1 compiles with bootstrapping ghc package, not the built one2019-07-07T18:38:13ZEdward Z. Yangghc-stage1 compiles with bootstrapping ghc package, not the built oneSteps to reproduce: Build GHC using 7.10 as the bootstrapping compiler. Now check which GHC package stage 1 Main.hi was linked against, e.g. using `--show-iface`:
```
[ezyang@hs01 ghc-validate2]$ ../ghc-7.10/inplace/bin/ghc-stage2 --sho...Steps to reproduce: Build GHC using 7.10 as the bootstrapping compiler. Now check which GHC package stage 1 Main.hi was linked against, e.g. using `--show-iface`:
```
[ezyang@hs01 ghc-validate2]$ ../ghc-7.10/inplace/bin/ghc-stage2 --show-iface ghc/stage1/build/Main.hi
...
package dependencies: array-0.5.0.1 base-4.8.0.0 binary-0.7.2.3
bin-package-db-0.0.0.0 bytestring-0.10.6.0 containers-0.5.6.2
deepseq-1.4.0.0 directory-1.2.1.1 filepath-1.3.1.0
ghc-7.10.0.20141223 ghc-prim-0.3.1.0 hoopl-3.10.0.2 hpc-0.6.0.2
integer-gmp-1.0.0.0 process-1.2.1.0 time-1.5.0.1
transformers-0.4.2.0 unix-2.7.1.0
```
Bad news!
I think I introduced bug when I made GHC a wired in package: consequently when we ask GHC to link against a specific version of the GHC package, this flag is ignored. I don't actually know what the right way to fix this is, but we'll have to figure something out here.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.11 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ghc-stage1 compiles with bootstrapping ghc package, not the built one","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"7.10.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Steps to reproduce: Build GHC using 7.10 as the bootstrapping compiler. Now check which GHC package stage 1 Main.hi was linked against, e.g. using `--show-iface`:\r\n\r\n{{{\r\n[ezyang@hs01 ghc-validate2]$ ../ghc-7.10/inplace/bin/ghc-stage2 --show-iface ghc/stage1/build/Main.hi\r\n...\r\npackage dependencies: array-0.5.0.1 base-4.8.0.0 binary-0.7.2.3\r\n bin-package-db-0.0.0.0 bytestring-0.10.6.0 containers-0.5.6.2\r\n deepseq-1.4.0.0 directory-1.2.1.1 filepath-1.3.1.0\r\n ghc-7.10.0.20141223 ghc-prim-0.3.1.0 hoopl-3.10.0.2 hpc-0.6.0.2\r\n integer-gmp-1.0.0.0 process-1.2.1.0 time-1.5.0.1\r\n transformers-0.4.2.0 unix-2.7.1.0\r\n}}}\r\n\r\nBad news!\r\n\r\nI think I introduced bug when I made GHC a wired in package: consequently when we ask GHC to link against a specific version of the GHC package, this flag is ignored. I don't actually know what the right way to fix this is, but we'll have to figure something out here.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://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/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/9619HPC Code Coverage complains when two exactly the same mix files are on the path2019-07-07T18:39:47ZKasperHPC Code Coverage complains when two exactly the same mix files are on the pathCabal's --enable-library-coverage flag generates the .mix files in the dist/mix directory that cabal creates during compilation. I have two test suites, integration tests and unit tests. Those test suites calll tests for moduleA in modul...Cabal's --enable-library-coverage flag generates the .mix files in the dist/mix directory that cabal creates during compilation. I have two test suites, integration tests and unit tests. Those test suites calll tests for moduleA in moduleATest. Unfortunately, in a first version, the integration tests and unit tests for moduleA were both present in moduleATest. Therefore, the unit test suite (in UnitTests.hs) and the integration test suite (in IntegrationTests.hs) both 'use' the moduleATest by linking in tests from that module. This leads to cabal generating a directory integration-tests and a directory unit-tests with .mix files, but the moduleATest.mix file is present in both directories. When performing hpc sum and hpc markup to get the total result of the test runs I need to specify the directories where the mix files are present (so dist/hpc/mix/unit-tests and dist/hpc/mix/integration-tests) and it will then complain that it finds moduleATest.mix file twice.
This issue is not present when using the -fhpc flag, as the directory structure with integration-tests and unit-tests is not present in the .hpc directory at that moment. That being said, I don't think it's a cabal issue as it's more or less expected what they're doing, generating the mix files necessary to instrument integration-tests and unit-tests separately.
Priority put to lowest because I can work around it by diving moduleATest up in moduleATest and moduleAIntegrationTest, which is saner in the end anyway. But I guess somebody will come up with a use case where a split up isn't possible, in the future.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 7.8.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | lowest |
| Resolution | Unresolved |
| Component | Code Coverage |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"HPC Code Coverage complains when two exactly the same mix files are on the path","status":"New","operating_system":"","component":"Code Coverage","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Cabal's --enable-library-coverage flag generates the .mix files in the dist/mix directory that cabal creates during compilation. I have two test suites, integration tests and unit tests. Those test suites calll tests for moduleA in moduleATest. Unfortunately, in a first version, the integration tests and unit tests for moduleA were both present in moduleATest. Therefore, the unit test suite (in UnitTests.hs) and the integration test suite (in IntegrationTests.hs) both 'use' the moduleATest by linking in tests from that module. This leads to cabal generating a directory integration-tests and a directory unit-tests with .mix files, but the moduleATest.mix file is present in both directories. When performing hpc sum and hpc markup to get the total result of the test runs I need to specify the directories where the mix files are present (so dist/hpc/mix/unit-tests and dist/hpc/mix/integration-tests) and it will then complain that it finds moduleATest.mix file twice.\r\n\r\n\r\nThis issue is not present when using the -fhpc flag, as the directory structure with integration-tests and unit-tests is not present in the .hpc directory at that moment. That being said, I don't think it's a cabal issue as it's more or less expected what they're doing, generating the mix files necessary to instrument integration-tests and unit-tests separately. \r\n\r\nPriority put to lowest because I can work around it by diving moduleATest up in moduleATest and moduleAIntegrationTest, which is saner in the end anyway. But I guess somebody will come up with a use case where a split up isn't possible, in the future.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://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/9384setNumCapabilities call breaks eventlog events2019-07-07T18:40:37ZSergei TrofimovichsetNumCapabilities call breaks eventlog eventsThe problem was found when i tried to eventlog **ghc --make** itself.
I've missinterpreted is as a threadscope bug: https://github.com/haskell/ThreadScope/issues/37
Here is small program to reliably reproduce the bug:
```hs
module Main...The problem was found when i tried to eventlog **ghc --make** itself.
I've missinterpreted is as a threadscope bug: https://github.com/haskell/ThreadScope/issues/37
Here is small program to reliably reproduce the bug:
```hs
module Main where
import qualified Data.List as L
import qualified System.Environment as E
import Control.Monad
import qualified Control.Concurrent as CC
import qualified Control.Concurrent.MVar as CC
slow_and_silly :: Int -> IO Int
slow_and_silly i = return $ length $ L.foldl' (\a v -> a ++ [v]) [] [1..i]
-- build as:
-- $ ghc --make a -O2 -threaded -eventlog
-- valid eventlog:
-- $ ./a 2 7000 +RTS -ls -N2
-- $ ghc-events validate threads a.eventlog
-- Valid eventlog:
-- ...
-- invalid eventlog
-- $ ./a 2 7000 +RTS -ls
-- $ ghc-events validate threads a.eventlog
-- Invalid eventlog:
-- ...
main = do
[caps, count] <- E.getArgs
let n_caps :: Int
n_caps = read caps
max_n :: Int
max_n = read count
CC.setNumCapabilities n_caps
waits <- replicateM n_caps $ CC.newEmptyMVar
forM_ waits $ \w -> CC.forkIO $ do
slow_and_silly max_n >>= print
CC.putMVar w ()
forM_ waits $ \w -> CC.takeMVar w
```
How to reproduce (comments have **ghc-events** version):
```
$ ghc --make a -O2 -threaded -eventlog
$ ./a 2 7000 +RTS -ls -N2
$ threadscope a.eventlog # works
$ ./a 2 7000 +RTS -ls
$ threadscope a.eventlog # crashes
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Profiling |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"setNumCapabilities call breaks eventlog events","status":"New","operating_system":"","component":"Profiling","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The problem was found when i tried to eventlog '''ghc --make''' itself.\r\nI've missinterpreted is as a threadscope bug: https://github.com/haskell/ThreadScope/issues/37\r\n\r\nHere is small program to reliably reproduce the bug:\r\n\r\n{{{#!hs\r\nmodule Main where\r\n\r\nimport qualified Data.List as L\r\nimport qualified System.Environment as E\r\nimport Control.Monad\r\nimport qualified Control.Concurrent as CC\r\nimport qualified Control.Concurrent.MVar as CC\r\n\r\nslow_and_silly :: Int -> IO Int\r\nslow_and_silly i = return $ length $ L.foldl' (\\a v -> a ++ [v]) [] [1..i]\r\n\r\n-- build as:\r\n-- $ ghc --make a -O2 -threaded -eventlog\r\n\r\n-- valid eventlog:\r\n-- $ ./a 2 7000 +RTS -ls -N2\r\n-- $ ghc-events validate threads a.eventlog\r\n-- Valid eventlog:\r\n-- ...\r\n\r\n-- invalid eventlog\r\n-- $ ./a 2 7000 +RTS -ls\r\n-- $ ghc-events validate threads a.eventlog\r\n-- Invalid eventlog:\r\n-- ...\r\n\r\nmain = do\r\n [caps, count] <- E.getArgs\r\n let n_caps :: Int\r\n n_caps = read caps\r\n max_n :: Int\r\n max_n = read count\r\n\r\n CC.setNumCapabilities n_caps\r\n\r\n waits <- replicateM n_caps $ CC.newEmptyMVar\r\n\r\n forM_ waits $ \\w -> CC.forkIO $ do\r\n slow_and_silly max_n >>= print\r\n CC.putMVar w ()\r\n\r\n forM_ waits $ \\w -> CC.takeMVar w\r\n}}}\r\n\r\nHow to reproduce (comments have '''ghc-events''' version):\r\n{{{\r\n$ ghc --make a -O2 -threaded -eventlog\r\n$ ./a 2 7000 +RTS -ls -N2\r\n$ threadscope a.eventlog # works\r\n$ ./a 2 7000 +RTS -ls\r\n$ threadscope a.eventlog # crashes\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/9333Thread status decoded wrong in base library2019-07-07T18:40:51ZJost BertholdThread status decoded wrong in base libraryKyle Van Berendonck \<kvanberendonck\@gmail.com\> in [a message on ghc-devs](http://www.haskell.org/pipermail/ghc-devs/2014-July/005677.html) pointed to [base/GHC/Conc/Sync.lhs](https://github.com/ghc/ghc/blob/master/libraries/base/GHC/C...Kyle Van Berendonck \<kvanberendonck\@gmail.com\> in [a message on ghc-devs](http://www.haskell.org/pipermail/ghc-devs/2014-July/005677.html) pointed to [base/GHC/Conc/Sync.lhs](https://github.com/ghc/ghc/blob/master/libraries/base/GHC/Conc/Sync.lhs#L483) decoding thread block reasons from constants defined in includes/rts/Constants.h to a Haskell type.
The constants were modified in GHC-7.8.2, which created problems with eventlogs (ticket #9003), so the constants were reverted, but base was not adapted to the respective fix.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------------- |
| Version | 7.8.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ekmett, ezyang, hvr, simonmar |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Thread status decoded wrong in base library","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ekmett","ezyang","hvr","simonmar"],"type":"Bug","description":"Kyle Van Berendonck <kvanberendonck@gmail.com> in [http://www.haskell.org/pipermail/ghc-devs/2014-July/005677.html a message on ghc-devs] pointed to [https://github.com/ghc/ghc/blob/master/libraries/base/GHC/Conc/Sync.lhs#L483 base/GHC/Conc/Sync.lhs] decoding thread block reasons from constants defined in includes/rts/Constants.h to a Haskell type.\r\n\r\nThe constants were modified in GHC-7.8.2, which created problems with eventlogs (ticket #9003), so the constants were reverted, but base was not adapted to the respective fix.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1Jost BertholdJost Bertholdhttps://gitlab.haskell.org/ghc/ghc/-/issues/9086main :: IO Int does different things with runghc and when compiled2019-07-07T18:42:00ZNiklas Hambüchenmail@nh2.memain :: IO Int does different things with runghc and when compiledConsider
```
main :: IO Int
main = return 1
```
This does different things when compiled and when run with `runghc`/`runhaskell` (it prints an extra `1` with the latter).
For practical purposes, I think it is beneficial if either of t...Consider
```
main :: IO Int
main = return 1
```
This does different things when compiled and when run with `runghc`/`runhaskell` (it prints an extra `1` with the latter).
For practical purposes, I think it is beneficial if either of the two ways to run a Haskell program have the same output.
Or did somebody intend this to happen?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | mail@nh2.me |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"main :: IO Int does different things with runghc and when compiled","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"7.10.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["mail@nh2.me"],"type":"Bug","description":"Consider\r\n\r\n{{{\r\nmain :: IO Int\r\nmain = return 1\r\n}}}\r\n\r\nThis does different things when compiled and when run with `runghc`/`runhaskell` (it prints an extra `1` with the latter).\r\n\r\nFor practical purposes, I think it is beneficial if either of the two ways to run a Haskell program have the same output.\r\n\r\nOr did somebody intend this to happen?","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1gintasgintashttps://gitlab.haskell.org/ghc/ghc/-/issues/8838Allow running bash shell commands2019-07-07T18:43:09ZJan Stolarekjan.stolarek@ed.ac.ukAllow running bash shell commandsCurrent implementation of `process` library has limited usability. `CreateProcess` record stores `CmdSpec` field, which is either a `RawCommand` or `ShellCommand`. The problem is that:
- `RawCommand` command quotes and escapes the comma...Current implementation of `process` library has limited usability. `CreateProcess` record stores `CmdSpec` field, which is either a `RawCommand` or `ShellCommand`. The problem is that:
- `RawCommand` command quotes and escapes the command parameters
- `ShellCommand` does no escaping but it runs command in `sh` shell
Corollary: there is no way to run `bash` command with unescaped parameters. As a result there is no way to run this command (and many others):
```
diff <(echo $ENV_FOO) <(echo $ENV_BAR)
```
Running it as a `RawCommand` (using `proc` function) fails because command line parameters are escaped and become incorrect. Running it as `ShellCommand` (using `shell` function) fails because this is not valid `sh` syntax. I propose to create function that allows user to run `bash` commands without escaping the parameters (or even better, run any shell the user wants). In other words this program:
```
import System.Exit
import System.Process
main :: IO ()
main = do
(_, _, _, pid) <- createProcess (SOME_NEW_FUNCTION "diff" ["<(echo $FOO)", "<(echo $BAR)"] )
{ env = Just [("FOO","Foo"),("BAR","Bar")] }
ecode <- waitForProcess pid
case ecode of
ExitSuccess -> putStrLn "All’s right with the world!"
ExitFailure _ -> putStrLn ":-("
```
should produce:
```
1c1
< Foo
---
> Bar
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 7.8.1-rc2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/process |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Allow running bash shell commands","status":"New","operating_system":"","component":"libraries/process","related":[],"milestone":"7.10.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.1-rc2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Current implementation of `process` library has limited usability. `CreateProcess` record stores `CmdSpec` field, which is either a `RawCommand` or `ShellCommand`. The problem is that:\r\n\r\n * `RawCommand` command quotes and escapes the command parameters\r\n * `ShellCommand` does no escaping but it runs command in `sh` shell\r\n\r\nCorollary: there is no way to run `bash` command with unescaped parameters. As a result there is no way to run this command (and many others):\r\n\r\n{{{\r\ndiff <(echo $ENV_FOO) <(echo $ENV_BAR)\r\n}}}\r\n\r\nRunning it as a `RawCommand` (using `proc` function) fails because command line parameters are escaped and become incorrect. Running it as `ShellCommand` (using `shell` function) fails because this is not valid `sh` syntax. I propose to create function that allows user to run `bash` commands without escaping the parameters (or even better, run any shell the user wants). In other words this program:\r\n\r\n{{{\r\nimport System.Exit\r\nimport System.Process\r\n\r\nmain :: IO ()\r\nmain = do\r\n (_, _, _, pid) <- createProcess (SOME_NEW_FUNCTION \"diff\" [\"<(echo $FOO)\", \"<(echo $BAR)\"] )\r\n { env = Just [(\"FOO\",\"Foo\"),(\"BAR\",\"Bar\")] }\r\n ecode <- waitForProcess pid\r\n case ecode of\r\n ExitSuccess -> putStrLn \"All’s right with the world!\"\r\n ExitFailure _ -> putStrLn \":-(\"\r\n}}}\r\n\r\nshould produce:\r\n\r\n{{{\r\n1c1\r\n< Foo\r\n---\r\n> Bar\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/5280System.Random commits (rand `mod` base) error.2019-07-07T18:56:05ZrrnewtonSystem.Random commits (rand `mod` base) error.You have probably at some point come across the C code "`rand() % base`"'. It is very intuitive, but unfortunately creates non-uniform random numbers, which is easy to see if you imagine `rand()` producing numbers in say `[0,15)` and bas...You have probably at some point come across the C code "`rand() % base`"'. It is very intuitive, but unfortunately creates non-uniform random numbers, which is easy to see if you imagine `rand()` producing numbers in say `[0,15)` and base being `10`.
In the function `System.Random.randomIvalInteger` you can see the same thing happening.
The only way I know how to deal with it and generate uniform integers within a range is to artificially restrict the range of the source of randomness to be a multiple of the desired base. It can be done simply by throwing out some random results.
This strategy appears to be used by GMP's mpz_urandomm function:
> http://gmplib.org/manual/Integer-Random-Numbers.html\#Integer-Random-Numbers
The file `urandomm.c` has the code.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 7.0.3 |
| 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":"System.Random commits (rand `mod` base) error.","status":"New","operating_system":"","component":"libraries/random","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"rrnewton"},"version":"7.0.3","keywords":["base","mod","random"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"You have probably at some point come across the C code \"{{{rand() % base}}}\"'. It is very intuitive, but unfortunately creates non-uniform random numbers, which is easy to see if you imagine {{{rand()}}} producing numbers in say `[0,15)` and base being `10`.\r\n\r\nIn the function `System.Random.randomIvalInteger` you can see the same thing happening. \r\n\r\nThe only way I know how to deal with it and generate uniform integers within a range is to artificially restrict the range of the source of randomness to be a multiple of the desired base. It can be done simply by throwing out some random results.\r\n\r\nThis strategy appears to be used by GMP's mpz_urandomm function:\r\n\r\n http://gmplib.org/manual/Integer-Random-Numbers.html#Integer-Random-Numbers\r\n\r\nThe file `urandomm.c` has the code.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1rrnewtonrrnewtonhttps://gitlab.haskell.org/ghc/ghc/-/issues/10521Wrong results in strict Word8 storage on x642019-07-07T18:35:35ZVincentBerthoux2Wrong results in strict Word8 storage on x64The following snippet produce two different results in function of the compiler platform used:
```hs
import Data.Word( Word8 )
-- removing the bang patterns on V definition makes
-- the problem go away.
data V = V !Word8 !Word8 derivin...The following snippet produce two different results in function of the compiler platform used:
```hs
import Data.Word( Word8 )
-- removing the bang patterns on V definition makes
-- the problem go away.
data V = V !Word8 !Word8 deriving Show
toV :: Float -> V
toV d = V (truncate $ d * coeff) (fromIntegral $ exponent d + 128) where
coeff = significand d * 255.9999 / d
main :: IO ()
main =
print $ map toV [ 3.56158e-2, 0.7415215, 0.5383201, 0.1289829, 0.45520145 ]
```
On GHC 7.10.1 x86 (under windows and Linux) the output is:
```
[V 145 124,V 189 128,V 137 128,V 132 126,V 233 127]
```
On GHC 7.10.1 x64 (under windows and Linux), the (invalid) output is:
```
[V 0 124,V 0 128,V 0 128,V 0 126,V 0 127]
```
The bug appear at the following optimisation levels:
- `-O1`
- `-O2`
- `-O3`
the results are the same at `-O0`
This bug was discovered in a bug report in the library JuicyPixels [https://github.com/Twinside/Juicy.Pixels/issues/98](https://github.com/Twinside/Juicy.Pixels/issues/98).
The same problem has been seen with GHC 7.10.2 RC17.10.2rwbartonrwbartonhttps://gitlab.haskell.org/ghc/ghc/-/issues/10317Event manager: Multishot registrations only fire once2019-07-07T18:36:36ZBen GamariEvent manager: Multishot registrations only fire onceSince D347 the event manager has had support for multishot event registration semantics, allowing the user to receive multiple events on an fd without requiring re-registration.
Unfortunately the implementation drops the registration af...Since D347 the event manager has had support for multishot event registration semantics, allowing the user to receive multiple events on an fd without requiring re-registration.
Unfortunately the implementation drops the registration after it fires, resulting in only one callback invocation.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.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":"Event manager: Multishot registrations only fire once","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"7.10.2","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Since D347 the event manager has had support for multishot event registration semantics, allowing the user to receive multiple events on an fd without requiring re-registration.\r\n\r\nUnfortunately the implementation drops the registration after it fires, resulting in only one callback invocation.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.2https://gitlab.haskell.org/ghc/ghc/-/issues/10236DWARF unwind info is broken2019-07-07T18:36:57ZthoughtpoliceDWARF unwind info is brokenAs reported by `bitonic` and `petermw` on `#ghc` (April 2nd):
```
07:02 < bitonic> I'm trying to get a meaningful backtrace with DWARF, using
<https://ghc.haskell.org/trac/ghc/wiki/DWARF> as a guide. however, all I ge...As reported by `bitonic` and `petermw` on `#ghc` (April 2nd):
```
07:02 < bitonic> I'm trying to get a meaningful backtrace with DWARF, using
<https://ghc.haskell.org/trac/ghc/wiki/DWARF> as a guide. however, all I get is
`Backtrace stopped: previous frame identical to this frame (corrupt stack?)`
07:03 < bitonic> I've re-built GHC 7.10.1 using `GhcRtsHcOpts += -g` and `GhcLibHcOpts += -g`, even if
I'm not sure it's even necessary
07:04 < bitonic> are there any additional steps I should take? or any way to make sure that the binary
I'm generating is sane?
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------------- |
| Version | 7.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Compiler (Debugging) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | scpmw |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"DWARF unwind info is broken","status":"New","operating_system":"","component":"Compiler (Debugging)","related":[],"milestone":"7.10.2","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.1","keywords":["dwarf"],"differentials":[],"test_case":"","architecture":"","cc":["scpmw"],"type":"Bug","description":"As reported by `bitonic` and `petermw` on `#ghc` (April 2nd):\r\n\r\n{{{\r\n07:02 < bitonic> I'm trying to get a meaningful backtrace with DWARF, using \r\n <https://ghc.haskell.org/trac/ghc/wiki/DWARF> as a guide. however, all I get is \r\n `Backtrace stopped: previous frame identical to this frame (corrupt stack?)`\r\n07:03 < bitonic> I've re-built GHC 7.10.1 using `GhcRtsHcOpts += -g` and `GhcLibHcOpts += -g`, even if \r\n I'm not sure it's even necessary\r\n07:04 < bitonic> are there any additional steps I should take? or any way to make sure that the binary \r\n I'm generating is sane?\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->7.10.2https://gitlab.haskell.org/ghc/ghc/-/issues/10205On Windows ghc-pkg always reports cache out of date2019-07-07T18:37:05ZHoward B. GoldenOn Windows ghc-pkg always reports cache out of dateWhen I ran `ghc-pkg list` on Windows, it reported that the global and user caches were out of date. As instructed, I recached both caches. Despite this, I continued to get the same error message. It appears that the timestamp on the pack...When I ran `ghc-pkg list` on Windows, it reported that the global and user caches were out of date. As instructed, I recached both caches. Despite this, I continued to get the same error message. It appears that the timestamp on the package.conf.d directory is always a few milliseconds later than the timestamp of the package cache, even after recaching, as shown by the log excerpt below.
Original error:
```
C:\Users\hgolden\AppData\Roaming>ghc-pkg check
WARNING: cache is out of date: C:\Users\hgolden\AppData\Roaming\ghc\i386-mingw32-7.10.1\package.conf.d\package.cache
ghc will see an old view of this package db. Use 'ghc-pkg recache' to fix.
WARNING: cache is out of date: C:/Program Files/MinGHC-7.10.1/ghc-7.10.1\lib\package.conf.d\package.cache
ghc will see an old view of this package db. Use 'ghc-pkg recache' to fix.
[snip...]
```
Checking timestamps:
```
C:\Users\hgolden\AppData\Roaming>ghc-pkg -v2 list
Timestamp 2015-03-27 21:18:29.5247984 UTC for C:\Users\hgolden\AppData\Roaming\ghc\i386-mingw32-7.10.1\package.conf.d\pa
ckage.cache
Timestamp 2015-03-27 21:18:29.5277984 UTC for C:\Users\hgolden\AppData\Roaming\ghc\i386-mingw32-7.10.1\package.conf.d (N
EWER than cache)
WARNING: cache is out of date: C:\Users\hgolden\AppData\Roaming\ghc\i386-mingw32-7.10.1\package.conf.d\package.cache
ghc will see an old view of this package db. Use 'ghc-pkg recache' to fix.
[snip...]
Timestamp 2015-03-27 21:15:48.6285984 UTC for C:/Program Files/MinGHC-7.10.1/ghc-7.10.1\lib\package.conf.d\package.cache
Timestamp 2015-03-27 21:15:48.6835984 UTC for C:/Program Files/MinGHC-7.10.1/ghc-7.10.1\lib\package.conf.d (NEWER than c
ache)
WARNING: cache is out of date: C:/Program Files/MinGHC-7.10.1/ghc-7.10.1\lib\package.conf.d\package.cache
ghc will see an old view of this package db. Use 'ghc-pkg recache' to fix.
[snip...]
```
Recaching as instructed:
```
C:\Users\hgolden\AppData\Roaming>ghc-pkg -v2 recache --user
[snip...]
modifying: Just "C:\\Users\\hgolden\\AppData\\Roaming\\ghc\\i386-mingw32-7.10.1\\package.conf.d"
flag db stack: ["C:\\Users\\hgolden\\AppData\\Roaming\\ghc\\i386-mingw32-7.10.1\\package.conf.d"]
writing cache C:\Users\hgolden\AppData\Roaming\ghc\i386-mingw32-7.10.1\package.conf.d\package.cache
C:\Users\hgolden\AppData\Roaming>ghc-pkg -v2 recache --global
[snip...]
modifying: Just "C:/Program Files/MinGHC-7.10.1/ghc-7.10.1\\lib\\package.conf.d"
flag db stack: ["C:/Program Files/MinGHC-7.10.1/ghc-7.10.1\\lib\\package.conf.d"]
writing cache C:/Program Files/MinGHC-7.10.1/ghc-7.10.1\lib\package.conf.d\package.cache
```
Looking at timestamps after recaching:
```
C:\Users\hgolden\AppData\Roaming>ghc-pkg -v2 list
Timestamp 2015-03-27 21:21:50.3341984 UTC for C:\Users\hgolden\AppData\Roaming\ghc\i386-mingw32-7.10.1\package.conf.d\pa
ckage.cache
Timestamp 2015-03-27 21:21:50.3371984 UTC for C:\Users\hgolden\AppData\Roaming\ghc\i386-mingw32-7.10.1\package.conf.d (N
EWER than cache)
WARNING: cache is out of date: C:\Users\hgolden\AppData\Roaming\ghc\i386-mingw32-7.10.1\package.conf.d\package.cache
ghc will see an old view of this package db. Use 'ghc-pkg recache' to fix.
[snip...]
Timestamp 2015-03-27 21:23:05.4329984 UTC for C:/Program Files/MinGHC-7.10.1/ghc-7.10.1\lib\package.conf.d\package.cache
Timestamp 2015-03-27 21:23:05.4359984 UTC for C:/Program Files/MinGHC-7.10.1/ghc-7.10.1\lib\package.conf.d (NEWER than c
ache)
WARNING: cache is out of date: C:/Program Files/MinGHC-7.10.1/ghc-7.10.1\lib\package.conf.d\package.cache
ghc will see an old view of this package db. Use 'ghc-pkg recache' to fix.
C:\Users\hgolden\AppData\Roaming>
```
Timestamps have changed, but each directory's timestamp is still a few milliseconds after each cache file's timestamp.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | ghc-pkg |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | x86 |
</details>
<!-- {"blocked_by":[],"summary":"On Windows ghc-pkg always reports cache out of date","status":"New","operating_system":"","component":"ghc-pkg","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"x86","cc":[""],"type":"Bug","description":"When I ran {{{ghc-pkg list}}} on Windows, it reported that the global and user caches were out of date. As instructed, I recached both caches. Despite this, I continued to get the same error message. It appears that the timestamp on the package.conf.d directory is always a few milliseconds later than the timestamp of the package cache, even after recaching, as shown by the log excerpt below.\r\n\r\nOriginal error:\r\n{{{\r\nC:\\Users\\hgolden\\AppData\\Roaming>ghc-pkg check\r\nWARNING: cache is out of date: C:\\Users\\hgolden\\AppData\\Roaming\\ghc\\i386-mingw32-7.10.1\\package.conf.d\\package.cache\r\nghc will see an old view of this package db. Use 'ghc-pkg recache' to fix.\r\nWARNING: cache is out of date: C:/Program Files/MinGHC-7.10.1/ghc-7.10.1\\lib\\package.conf.d\\package.cache\r\nghc will see an old view of this package db. Use 'ghc-pkg recache' to fix.\r\n[snip...]\r\n}}}\r\nChecking timestamps:\r\n{{{\r\nC:\\Users\\hgolden\\AppData\\Roaming>ghc-pkg -v2 list\r\nTimestamp 2015-03-27 21:18:29.5247984 UTC for C:\\Users\\hgolden\\AppData\\Roaming\\ghc\\i386-mingw32-7.10.1\\package.conf.d\\pa\r\nckage.cache\r\nTimestamp 2015-03-27 21:18:29.5277984 UTC for C:\\Users\\hgolden\\AppData\\Roaming\\ghc\\i386-mingw32-7.10.1\\package.conf.d (N\r\nEWER than cache)\r\nWARNING: cache is out of date: C:\\Users\\hgolden\\AppData\\Roaming\\ghc\\i386-mingw32-7.10.1\\package.conf.d\\package.cache\r\nghc will see an old view of this package db. Use 'ghc-pkg recache' to fix.\r\n[snip...]\r\nTimestamp 2015-03-27 21:15:48.6285984 UTC for C:/Program Files/MinGHC-7.10.1/ghc-7.10.1\\lib\\package.conf.d\\package.cache\r\nTimestamp 2015-03-27 21:15:48.6835984 UTC for C:/Program Files/MinGHC-7.10.1/ghc-7.10.1\\lib\\package.conf.d (NEWER than c\r\nache)\r\nWARNING: cache is out of date: C:/Program Files/MinGHC-7.10.1/ghc-7.10.1\\lib\\package.conf.d\\package.cache\r\nghc will see an old view of this package db. Use 'ghc-pkg recache' to fix.\r\n[snip...]\r\n}}}\r\nRecaching as instructed:\r\n{{{\r\nC:\\Users\\hgolden\\AppData\\Roaming>ghc-pkg -v2 recache --user\r\n[snip...]\r\nmodifying: Just \"C:\\\\Users\\\\hgolden\\\\AppData\\\\Roaming\\\\ghc\\\\i386-mingw32-7.10.1\\\\package.conf.d\"\r\nflag db stack: [\"C:\\\\Users\\\\hgolden\\\\AppData\\\\Roaming\\\\ghc\\\\i386-mingw32-7.10.1\\\\package.conf.d\"]\r\nwriting cache C:\\Users\\hgolden\\AppData\\Roaming\\ghc\\i386-mingw32-7.10.1\\package.conf.d\\package.cache\r\nC:\\Users\\hgolden\\AppData\\Roaming>ghc-pkg -v2 recache --global\r\n[snip...]\r\nmodifying: Just \"C:/Program Files/MinGHC-7.10.1/ghc-7.10.1\\\\lib\\\\package.conf.d\"\r\nflag db stack: [\"C:/Program Files/MinGHC-7.10.1/ghc-7.10.1\\\\lib\\\\package.conf.d\"]\r\nwriting cache C:/Program Files/MinGHC-7.10.1/ghc-7.10.1\\lib\\package.conf.d\\package.cache\r\n}}}\r\nLooking at timestamps after recaching:\r\n{{{\r\nC:\\Users\\hgolden\\AppData\\Roaming>ghc-pkg -v2 list\r\nTimestamp 2015-03-27 21:21:50.3341984 UTC for C:\\Users\\hgolden\\AppData\\Roaming\\ghc\\i386-mingw32-7.10.1\\package.conf.d\\pa\r\nckage.cache\r\nTimestamp 2015-03-27 21:21:50.3371984 UTC for C:\\Users\\hgolden\\AppData\\Roaming\\ghc\\i386-mingw32-7.10.1\\package.conf.d (N\r\nEWER than cache)\r\nWARNING: cache is out of date: C:\\Users\\hgolden\\AppData\\Roaming\\ghc\\i386-mingw32-7.10.1\\package.conf.d\\package.cache\r\nghc will see an old view of this package db. Use 'ghc-pkg recache' to fix.\r\n[snip...]\r\nTimestamp 2015-03-27 21:23:05.4329984 UTC for C:/Program Files/MinGHC-7.10.1/ghc-7.10.1\\lib\\package.conf.d\\package.cache\r\nTimestamp 2015-03-27 21:23:05.4359984 UTC for C:/Program Files/MinGHC-7.10.1/ghc-7.10.1\\lib\\package.conf.d (NEWER than c\r\nache)\r\nWARNING: cache is out of date: C:/Program Files/MinGHC-7.10.1/ghc-7.10.1\\lib\\package.conf.d\\package.cache\r\nghc will see an old view of this package db. Use 'ghc-pkg recache' to fix.\r\nC:\\Users\\hgolden\\AppData\\Roaming>\r\n}}}\r\nTimestamps have changed, but each directory's timestamp is still a few milliseconds after each cache file's timestamp.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.2https://gitlab.haskell.org/ghc/ghc/-/issues/12202GHC 7.10.3 throws away callstack frames in some cases2019-07-07T18:27:11ZBen GamariGHC 7.10.3 throws away callstack frames in some casesIt was noticed that GHC 7.10.3 sometimes drops outer callers from IP callstacks. For instance,
```hs
{-# LANGUAGE ImplicitParams #-}
import GHC.Stack
import Control.Monad.Catch
newtype MyError = MyError CallStack
instance Exception My...It was noticed that GHC 7.10.3 sometimes drops outer callers from IP callstacks. For instance,
```hs
{-# LANGUAGE ImplicitParams #-}
import GHC.Stack
import Control.Monad.Catch
newtype MyError = MyError CallStack
instance Exception MyError
instance Show MyError where
show (MyError e) = show e
fromEvents :: (MonadThrow m, ?loc :: CallStack) => m (Maybe Int)
fromEvents = do
Just <$> require 42
where
-- require :: (MonadThrow m, ?loc :: CallStack) => Int -> m Int
require n -- line 17
| even n = throwM $ MyError ?loc
| otherwise = return n
main = do
putStrLn "Hello world"
fromEvents -- line 24
```
GHC 8.0.1 produces the correct output,
```
$ ./Hi
Hello world
Hi: [("fromEvents",SrcLoc {srcLocPackage = "main", srcLocModule = "Main", srcLocFile = "Hi.hs", srcLocStartLine = 24, srcLocStartCol = 5, srcLocEndLine = 24, srcLocEndCol = 15})]
```
GHC 7.10.3 produces only one
```hs
$ ./Hi
Hello world
Hi: CallStack {getCallStack = [("?loc",SrcLoc {srcLocPackage = "main", srcLocModule = "Main", srcLocFile = "Hi.hs", srcLocStartLine = 17, srcLocStartCol = 35, srcLocEndLine = 17, srcLocEndCol = 39})]}
```
Uncommenting the type signature for `require` however results in more-or-less the expected callstack with 7.10.3,
```hs
$ ./Hi
Hello world
Hi: CallStack {getCallStack = [("?loc",SrcLoc {srcLocPackage = "main", srcLocModule = "Main", srcLocFile = "Hi.hs", srcLocStartLine = 18, srcLocStartCol = 35, srcLocEndLine = 18, srcLocEndCol = 39}),("require",SrcLoc {srcLocPackage = "main", srcLocModule = "Main", srcLocFile = "Hi.hs", srcLocStartLine = 14, srcLocStartCol = 14, srcLocEndLine = 14, srcLocEndCol = 21}),("fromEvents",SrcLoc {srcLocPackage = "main", srcLocModule = "Main", srcLocFile = "Hi.hs", srcLocStartLine = 24, srcLocStartCol = 5, srcLocEndLine = 24, srcLocEndCol = 15})]}
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 7.10.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":"GHC 7.10.3 throws away callstack frames for outer","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"It was noticed that GHC 7.10.3 sometimes drops outer callers from IP callstacks. For instance,\r\n\r\n{{{#!hs\r\n{-# LANGUAGE ImplicitParams #-}\r\n\r\nimport GHC.Stack\r\nimport Control.Monad.Catch\r\n\r\nnewtype MyError = MyError CallStack\r\ninstance Exception MyError\r\n\r\ninstance Show MyError where\r\n show (MyError e) = show e\r\n\r\nfromEvents :: (MonadThrow m, ?loc :: CallStack) => m (Maybe Int)\r\nfromEvents = do\r\n Just <$> require 42\r\n where\r\n -- require :: (MonadThrow m, ?loc :: CallStack) => Int -> m Int\r\n require n -- line 17\r\n | even n = throwM $ MyError ?loc\r\n | otherwise = return n\r\n\r\n\r\nmain = do\r\n putStrLn \"Hello world\"\r\n fromEvents -- line 24\r\n}}}\r\n\r\n\r\nGHC 8.0.1 produces the correct output,\r\n{{{\r\n$ ./Hi\r\nHello world\r\nHi: [(\"fromEvents\",SrcLoc {srcLocPackage = \"main\", srcLocModule = \"Main\", srcLocFile = \"Hi.hs\", srcLocStartLine = 24, srcLocStartCol = 5, srcLocEndLine = 24, srcLocEndCol = 15})]\r\n}}}\r\n\r\nGHC 7.10.3 produces only one\r\n{{{#!hs\r\n$ ./Hi\r\nHello world\r\nHi: CallStack {getCallStack = [(\"?loc\",SrcLoc {srcLocPackage = \"main\", srcLocModule = \"Main\", srcLocFile = \"Hi.hs\", srcLocStartLine = 17, srcLocStartCol = 35, srcLocEndLine = 17, srcLocEndCol = 39})]}\r\n}}}\r\n\r\nUncommenting the type signature for `require` however results in more-or-less the expected callstack with 7.10.3,\r\n{{{#!hs\r\n$ ./Hi\r\nHello world\r\nHi: CallStack {getCallStack = [(\"?loc\",SrcLoc {srcLocPackage = \"main\", srcLocModule = \"Main\", srcLocFile = \"Hi.hs\", srcLocStartLine = 18, srcLocStartCol = 35, srcLocEndLine = 18, srcLocEndCol = 39}),(\"require\",SrcLoc {srcLocPackage = \"main\", srcLocModule = \"Main\", srcLocFile = \"Hi.hs\", srcLocStartLine = 14, srcLocStartCol = 14, srcLocEndLine = 14, srcLocEndCol = 21}),(\"fromEvents\",SrcLoc {srcLocPackage = \"main\", srcLocModule = \"Main\", srcLocFile = \"Hi.hs\", srcLocStartLine = 24, srcLocStartCol = 5, srcLocEndLine = 24, srcLocEndCol = 15})]}\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/11810Filtering of cost-center profiler output no longer works2019-07-07T18:28:26ZBen GamariFiltering of cost-center profiler output no longer worksWith the following testcase,
```hs
import Control.Monad (replicateM)
main :: IO ()
main = do
let xs = replicate 10000000 $ 42
print $ length xs
print $ sum xs
```
Running like this,
```
ghc -prof -auto-all Hi.hs && ./Hi +...With the following testcase,
```hs
import Control.Monad (replicateM)
main :: IO ()
main = do
let xs = replicate 10000000 $ 42
print $ length xs
print $ sum xs
```
Running like this,
```
ghc -prof -auto-all Hi.hs && ./Hi +RTS -hy[] -hc
```
with 7.10.3 produces a useful profile with the output one would expect. 8.0.1-rc2, on the other hand produces empty samples.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.1-rc3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | Profiling |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Filtering of cost-center profiler output no longer works","status":"New","operating_system":"","component":"Profiling","related":[],"milestone":"8.0.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1-rc3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"With the following testcase,\r\n{{{#!hs\r\nimport Control.Monad (replicateM)\r\n\r\nmain :: IO ()\r\nmain = do\r\n let xs = replicate 10000000 $ 42\r\n print $ length xs\r\n print $ sum xs\r\n}}}\r\n\r\nRunning like this,\r\n{{{\r\nghc -prof -auto-all Hi.hs && ./Hi +RTS -hy[] -hc\r\n}}}\r\nwith 7.10.3 produces a useful profile with the output one would expect. 8.0.1-rc2, on the other hand produces empty samples.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1