GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:43:07Zhttps://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/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/9435x86 sse4.2 popCnt16# needs to zero-extend its result2019-07-07T18:40:24Zrwbartonx86 sse4.2 popCnt16# needs to zero-extend its result`make TEST=cgrun071 EXTRA_HC_OPTS=-msse42` fails for me in all the non-ghci non-llvm ways.
For `popCnt16#` we emit `popcnt %ax,%ax` which doesn't clear the high 48 bits of the result.
Patch incoming.
<details><summary>Trac metadata</s...`make TEST=cgrun071 EXTRA_HC_OPTS=-msse42` fails for me in all the non-ghci non-llvm ways.
For `popCnt16#` we emit `popcnt %ax,%ax` which doesn't clear the high 48 bits of the result.
Patch incoming.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | --------------- |
| Version | 7.9 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (NCG) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | simonmar, tibbe |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"x86 sse4.2 popCnt16# needs to zero-extend its result","status":"New","operating_system":"","component":"Compiler (NCG)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.9","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["simonmar","tibbe"],"type":"Bug","description":"`make TEST=cgrun071 EXTRA_HC_OPTS=-msse42` fails for me in all the non-ghci non-llvm ways.\r\n\r\nFor `popCnt16#` we emit `popcnt %ax,%ax` which doesn't clear the high 48 bits of the result.\r\n\r\nPatch incoming.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.4https://gitlab.haskell.org/ghc/ghc/-/issues/9817signal handlers in unix are passed garbage when using the signle threaded rts2023-09-09T22:39:58Zrednebsignal handlers in unix are passed garbage when using the signle threaded rtsWhen a signal handler (registered with `GHC.Conc.Signal.setHandler`) is called upon the receipt of the relevant signal, it is passed a memory buffer in the form of a `ForeignPtr Word8`. This buffer contains a copy of the `siginfo_t` stru...When a signal handler (registered with `GHC.Conc.Signal.setHandler`) is called upon the receipt of the relevant signal, it is passed a memory buffer in the form of a `ForeignPtr Word8`. This buffer contains a copy of the `siginfo_t` struct that was originally passed to the underlying os signal handler. Unfortunately, this only seems to work correctly in the threaded rts. In the single-threaded rts, the buffer contains garbage. This can be demonstrated by the following program:
```hs
import Control.Concurrent
import System.Posix.Signals
main :: IO ()
main = do
wait <- newEmptyMVar
_ <- flip (installHandler sig) Nothing $ CatchInfo $ \info -> do
putStrLn $ "Received a signal " ++ show (siginfoSignal info)
putMVar wait ()
raiseSignal sig
putStrLn $ "Sending myself a signal " ++ show sig
takeMVar wait
where
sig = sigUSR2
```
If you compile the program with the `-threaded` flag then everything works just fine:
```
Sending myself a signal 12
Received a signal 12
```
but without it, the signal handler will print a totaly random signal number:
```
Sending myself a signal 12
Received a signal 138644296
```
I was able to track this down to the function `startSignalHandlers` in `rts/posix/Signals.c`. This function (which is only used by the single threaded rts) allocates a buffer and copies the `siginfo_t` struct to it and then schedules `GHC.Conc.Signal.runHandlers` to be run in a new thread. The problem is that while `GHC.Conc.Signal.runHandlers` expects a `ForeignPtr Word8`, here it is given a `Ptr Word8`. This has two implications: the signal handler is given invalid data, and nobody is deallocating the buffer so we are leaking memory every time a signal is received that has a custom handler.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.8.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | simonmar |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"signal handlers in unix are passed garbage when using the signle threaded rts","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"simonmar"},"version":"7.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["simonmar"],"type":"Bug","description":"When a signal handler (registered with `GHC.Conc.Signal.setHandler`) is called upon the receipt of the relevant signal, it is passed a memory buffer in the form of a `ForeignPtr Word8`. This buffer contains a copy of the `siginfo_t` struct that was originally passed to the underlying os signal handler. Unfortunately, this only seems to work correctly in the threaded rts. In the single-threaded rts, the buffer contains garbage. This can be demonstrated by the following program:\r\n\r\n{{{#!hs\r\nimport Control.Concurrent\r\nimport System.Posix.Signals\r\n\r\nmain :: IO ()\r\nmain = do\r\n wait <- newEmptyMVar\r\n _ <- flip (installHandler sig) Nothing $ CatchInfo $ \\info -> do\r\n putStrLn $ \"Received a signal \" ++ show (siginfoSignal info)\r\n putMVar wait ()\r\n raiseSignal sig\r\n putStrLn $ \"Sending myself a signal \" ++ show sig\r\n takeMVar wait\r\n where\r\n sig = sigUSR2\r\n}}}\r\n\r\nIf you compile the program with the `-threaded` flag then everything works just fine:\r\n{{{\r\nSending myself a signal 12\r\nReceived a signal 12\r\n}}}\r\nbut without it, the signal handler will print a totaly random signal number:\r\n{{{\r\nSending myself a signal 12\r\nReceived a signal 138644296\r\n}}}\r\n\r\nI was able to track this down to the function `startSignalHandlers` in `rts/posix/Signals.c`. This function (which is only used by the single threaded rts) allocates a buffer and copies the `siginfo_t` struct to it and then schedules `GHC.Conc.Signal.runHandlers` to be run in a new thread. The problem is that while `GHC.Conc.Signal.runHandlers` expects a `ForeignPtr Word8`, here it is given a `Ptr Word8`. This has two implications: the signal handler is given invalid data, and nobody is deallocating the buffer so we are leaking memory every time a signal is received that has a custom handler.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.4Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/9860Package flags not command line completable in 7.82019-07-07T18:38:44Zkolmodin@dtek.chalmers.sePackage flags not command line completable in 7.8Passing `--show-options` to ghc shows all the flags that ghc understands.
Unfortunately `--show-options` does not list the package flags, `-package-db -package-id` etc.
Requires a 1 line fix in `ghc/Main.hs`.
<details><summary>Trac me...Passing `--show-options` to ghc shows all the flags that ghc understands.
Unfortunately `--show-options` does not list the package flags, `-package-db -package-id` etc.
Requires a 1 line fix in `ghc/Main.hs`.
<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":"Package flags not command line completable in 7.8","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"7.8.4","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Passing `--show-options` to ghc shows all the flags that ghc understands.\r\n\r\nUnfortunately `--show-options` does not list the package flags, `-package-db -package-id` etc.\r\n\r\nRequires a 1 line fix in `ghc/Main.hs`.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.4kolmodin@dtek.chalmers.sekolmodin@dtek.chalmers.se