GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:22:08Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/13384Windows build thinks sqrt (-1) == -12019-07-07T18:22:08ZBen GamariWindows build thinks sqrt (-1) == -1As of 749740f9c3cb25ee95e04a21c1ef73e1bf96afb1,
{{{
$ inplace/bin/ghc-stage2 --interactive
GHCi, version 8.1.20170306: http://www.haskell.org/ghc/ :? for help
Prelude\> sqrt (-1) :: Double
-1.0
<details><summary>Trac metadata</summary>...As of 749740f9c3cb25ee95e04a21c1ef73e1bf96afb1,
{{{
$ inplace/bin/ghc-stage2 --interactive
GHCi, version 8.1.20170306: http://www.haskell.org/ghc/ :? for help
Prelude\> sqrt (-1) :: Double
-1.0
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown/Multiple |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Windows build thinks sqrt (-1) == -1","status":"New","operating_system":"Unknown/Multiple","component":"Compiler","related":[],"milestone":"8.2.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"As of 749740f9c3cb25ee95e04a21c1ef73e1bf96afb1,\r\n{{{\r\n$ inplace/bin/ghc-stage2 --interactive\r\nGHCi, version 8.1.20170306: http://www.haskell.org/ghc/ :? for help\r\nPrelude> sqrt (-1) :: Double\r\n-1.0\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1Tamar ChristinaTamar Christinahttps://gitlab.haskell.org/ghc/ghc/-/issues/12433GHCi produces incorrect results when evaluating with compiled code2022-08-05T10:27:28ZIavor S. DiatchkiGHCi produces incorrect results when evaluating with compiled codeWhen GHCi evaluates in non-interpreted mode, it sometimes produces incorrect results. The following example---extracted from a much larger program---illustrates the problem:
```hs
import Lex
num = 100000
txt1 = "aaa,aaa"
main :: IO (...When GHCi evaluates in non-interpreted mode, it sometimes produces incorrect results. The following example---extracted from a much larger program---illustrates the problem:
```hs
import Lex
num = 100000
txt1 = "aaa,aaa"
main :: IO ()
main = print $ sum $ map (length . haskellLex) $ replicate num txt1
```
This program lexes the same string 100000 times, and prints the total number of tokens. Since we are lexing the same string, we'd expect to always get the same result, but due to this bug, this is not the case! We repeat the process 100000 times so that we can encounter the bug somewhat reliably---the problem does not occur every time.
To reproduce the problem, we need to load `Lex` in compiled form, not interpreted and with some optimizations:
```
ghc -c -O1 -dynamic Lex.hs
```
The source code for the "lexer" is as follows:
```haskell
module Lex (haskellLex) where
cclass :: Char -> Int
cclass c =
case c of
'a' -> 10
',' -> 11
'A' -> 0
'B' -> 0
'C' -> 0
'D' -> 0
'E' -> 0
'F' -> 0
haskellLex :: String -> [()]
haskellLex [] = []
haskellLex (i:is) =
case cclass i of
10 -> haskellLex62 is
11 -> () : haskellLex is
haskellLex62 :: String -> [()]
haskellLex62 [] = [()]
haskellLex62 (i:is) =
case cclass i of
0 -> [()]
1 -> [()]
2 -> [()]
3 -> [()]
4 -> [()]
10 -> haskellLex62 is
11 -> () : haskellLex (i:is)
x -> error ("[GHC BUG] cclass returned: " ++ show (i,x)
```
This is a minimized version from a full lexer. As odd as it looks, removing pretty much anything seems to cause the bug to go away. This is what happens when we run the program:
```
runhaskell test.hs
test.hs: [GHC BUG] cclass returned: (',',-556)
CallStack (from HasCallStack):
error, called at Lex.hs:36:12 in main:Lex
```
The problem is that after many evaluations, the function `cclass` returned `-556` for character `,`, when it should have returned `11`.
I've been able to reproduce this on two Linux machines, both running 64-bit Ubuntu (16.04). The issue does not seem to happen on Mac OS.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.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":"GHCi produces incorrect results when evaluating with compiled code","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":["code","compiled","dynamic","ghci,","linking,"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When GHCi evaluates in non-interpreted mode, it sometimes produces incorrect results. The following example---extracted from a much larger program---illustrates the problem:\r\n{{{#!hs\r\nimport Lex\r\n\r\nnum = 100000\r\ntxt1 = \"aaa,aaa\"\r\n\r\nmain :: IO ()\r\nmain = print $ sum $ map (length . haskellLex) $ replicate num txt1\r\n}}}\r\n\r\nThis program lexes the same string 100000 times, and prints the total number of tokens. Since we are lexing the same string, we'd expect to always get the same result, but due to this bug, this is not the case! We repeat the process 100000 times so that we can encounter the bug somewhat reliably---the problem does not occur every time.\r\n\r\nTo reproduce the problem, we need to load `Lex` in compiled form, not interpreted and with some optimizations:\r\n{{{\r\nghc -c -O1 -dynamic Lex.hs\r\n}}}\r\n\r\nThe source code for the \"lexer\" is as follows:\r\n{{{#!haskell\r\nmodule Lex (haskellLex) where\r\n\r\ncclass :: Char -> Int\r\ncclass c =\r\n case c of\r\n 'a' -> 10\r\n ',' -> 11\r\n\r\n 'A' -> 0\r\n 'B' -> 0\r\n 'C' -> 0\r\n 'D' -> 0\r\n 'E' -> 0\r\n 'F' -> 0\r\n\r\nhaskellLex :: String -> [()]\r\nhaskellLex [] = []\r\nhaskellLex (i:is) =\r\n case cclass i of\r\n 10 -> haskellLex62 is\r\n 11 -> () : haskellLex is\r\n\r\nhaskellLex62 :: String -> [()]\r\nhaskellLex62 [] = [()]\r\nhaskellLex62 (i:is) =\r\n case cclass i of\r\n 0 -> [()]\r\n 1 -> [()]\r\n 2 -> [()]\r\n 3 -> [()]\r\n 4 -> [()]\r\n\r\n 10 -> haskellLex62 is\r\n 11 -> () : haskellLex (i:is)\r\n\r\n x -> error (\"[GHC BUG] cclass returned: \" ++ show (i,x)\r\n}}}\r\n\r\nThis is a minimized version from a full lexer. As odd as it looks, removing pretty much anything seems to cause the bug to go away. This is what happens when we run the program:\r\n{{{\r\nrunhaskell test.hs\r\ntest.hs: [GHC BUG] cclass returned: (',',-556)\r\nCallStack (from HasCallStack):\r\n error, called at Lex.hs:36:12 in main:Lex\r\n}}}\r\n\r\nThe problem is that after many evaluations, the function `cclass` returned `-556` for character `,`, when it should have returned `11`.\r\n\r\nI've been able to reproduce this on two Linux machines, both running 64-bit Ubuntu (16.04). The issue does not seem to happen on Mac OS.\r\n\r\n\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.0.2Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/11830Disabling idle GC leads to freeze2019-07-07T18:28:22ZNeil MitchellDisabling idle GC leads to freezeI'm currently getting a runtime freeze with a spinning CPU with the latest GHC 8.0.1 RC (8.0.0.20160411). Testing 2 months ago on whatever was the latest release candidate showed no problems. The reproduction steps are a bit long winded:...I'm currently getting a runtime freeze with a spinning CPU with the latest GHC 8.0.1 RC (8.0.0.20160411). Testing 2 months ago on whatever was the latest release candidate showed no problems. The reproduction steps are a bit long winded:
- All tested on Ubuntu Linux.
- Checkout Shake, https://github.com/ndmitchell/shake.git (currently at 75505baa5fc5d1b99a1162edae6ecf7669f00ed9).
- `cabal install`
- Checkout Ninja, https://github.com/ninja-build/ninja.git (currently at 78f548880e549c701bd77760e4b3f3a4ee147641).
- Change to the `ninja` directory.
- Run `./configure.py --bootstrap`
- Run `cp ninja nin`
- Run `./nin -t clean`
- Run `shake`
Observe that Shake fails to complete and starts spinning on 1 CPU.
If you modify `shake.cabal` to remove `-with-rtsopts=-I0 -qg -qb` then it works again and completes in \< 1 min. Adding back flags with `+RTS -I0 -RTS` shows that `-I0` alone is the culprit.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.0.1-rc3 |
| 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":"Disabling idle GC leads to freeze","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1-rc3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["simonmar"],"type":"Bug","description":"I'm currently getting a runtime freeze with a spinning CPU with the latest GHC 8.0.1 RC (8.0.0.20160411). Testing 2 months ago on whatever was the latest release candidate showed no problems. The reproduction steps are a bit long winded:\r\n\r\n* All tested on Ubuntu Linux.\r\n* Checkout Shake, https://github.com/ndmitchell/shake.git (currently at 75505baa5fc5d1b99a1162edae6ecf7669f00ed9).\r\n* {{{cabal install}}}\r\n* Checkout Ninja, https://github.com/ninja-build/ninja.git (currently at 78f548880e549c701bd77760e4b3f3a4ee147641).\r\n* Change to the {{{ninja}}} directory.\r\n* Run {{{./configure.py --bootstrap}}}\r\n* Run {{{cp ninja nin}}}\r\n* Run {{{./nin -t clean}}}\r\n* Run {{{shake}}}\r\n\r\nObserve that Shake fails to complete and starts spinning on 1 CPU.\r\n\r\nIf you modify {{{shake.cabal}}} to remove {{{-with-rtsopts=-I0 -qg -qb}}} then it works again and completes in < 1 min. Adding back flags with {{{+RTS -I0 -RTS}}} shows that {{{-I0}}} alone is the culprit.","type_of_failure":"OtherFailure","blocking":[]} -->8.2.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.1https://gitlab.haskell.org/ghc/ghc/-/issues/11702Constant folding on 'mod/Word' - incorrect result2019-07-07T18:29:02ZondrapConstant folding on 'mod/Word' - incorrect resultCompiling this with GHC 7.10.3 on both MacOS and Linux with '-O' producess results '5 0'.
```hs
module Main where
testfn :: Word -> IO ()
testfn wseq = do
print $ wseq `mod` 1
main = do
testfn 5
print $ (5 :: Word) `mod` 1
```
...Compiling this with GHC 7.10.3 on both MacOS and Linux with '-O' producess results '5 0'.
```hs
module Main where
testfn :: Word -> IO ()
testfn wseq = do
print $ wseq `mod` 1
main = do
testfn 5
print $ (5 :: Word) `mod` 1
```
Changing type to Int produces correct result. It has probably something to do with compiler/prelude/PrelRules.hs - the rules for Int and Word differ. It seems to me that it should be optimized the same way, but the culprit seems to be the 'rightIdentityDynFlags onew' - that seems to be a clear bug (if it does what I think it does).
```hs
primOpRules nm IntRemOp = mkPrimOpRule nm 2 [ nonZeroLit 1 >> binaryLit (intOp2 rem)
, leftZero zeroi
, do l <- getLiteral 1
dflags <- getDynFlags
guard (l == onei dflags)
retLit zeroi
, equalArgs >> retLit zeroi
, equalArgs >> retLit zeroi ]
primOpRules nm WordRemOp = mkPrimOpRule nm 2 [ nonZeroLit 1 >> binaryLit (wordOp2 rem)
, rightIdentityDynFlags onew ]
```
I found it in different code where lots of inlining reduced some branch of code into this and produced wrong result.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Prelude |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Constant folding on 'mod/Word' - incorrect result","status":"New","operating_system":"","component":"Prelude","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Compiling this with GHC 7.10.3 on both MacOS and Linux with '-O' producess results '5 0'. \r\n\r\n{{{#!hs\r\nmodule Main where\r\n\r\ntestfn :: Word -> IO ()\r\ntestfn wseq = do\r\n print $ wseq `mod` 1\r\n\r\nmain = do\r\n testfn 5\r\n print $ (5 :: Word) `mod` 1\r\n}}}\r\n\r\nChanging type to Int produces correct result. It has probably something to do with compiler/prelude/PrelRules.hs - the rules for Int and Word differ. It seems to me that it should be optimized the same way, but the culprit seems to be the 'rightIdentityDynFlags onew' - that seems to be a clear bug (if it does what I think it does).\r\n\r\n{{{#!hs\r\nprimOpRules nm IntRemOp = mkPrimOpRule nm 2 [ nonZeroLit 1 >> binaryLit (intOp2 rem)\r\n , leftZero zeroi\r\n , do l <- getLiteral 1\r\n dflags <- getDynFlags\r\n guard (l == onei dflags)\r\n retLit zeroi\r\n , equalArgs >> retLit zeroi\r\n , equalArgs >> retLit zeroi ]\r\nprimOpRules nm WordRemOp = mkPrimOpRule nm 2 [ nonZeroLit 1 >> binaryLit (wordOp2 rem)\r\n , rightIdentityDynFlags onew ]\r\n}}}\r\n\r\nI found it in different code where lots of inlining reduced some branch of code into this and produced wrong result.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/11555catch _|_ breaks at -O12020-04-02T11:39:30ZSergei Trofimovichcatch _|_ breaks at -O1Discovered on xmonad-0.12 test failure.
Happens on today's -HEAD and ghc-8.0.1-rc1,-rc2
Short example is (needs only base):
```hs
-- cat F.hs
module F where
import qualified Control.Exception as C
import System.IO.Unsafe
import qualif...Discovered on xmonad-0.12 test failure.
Happens on today's -HEAD and ghc-8.0.1-rc1,-rc2
Short example is (needs only base):
```hs
-- cat F.hs
module F where
import qualified Control.Exception as C
import System.IO.Unsafe
import qualified Data.List as L
abort :: String -> a
abort x = error $ "xmonad: StackSet: " ++ x
prop_abort x = unsafePerformIO $ C.catch (abort "fail")
(\(C.SomeException e) ->
return $ "xmonad: StackSet: fail" `L.isPrefixOf` show e )
where
_ = x :: Int
```
Session 1 \[ok\]:
```
$ ghci F.hs
GHCi, version 8.0.0.20160204: http://www.haskell.org/ghc/ :? for help
[1 of 1] Compiling F ( F.hs, interpreted )
Ok, modules loaded: F.
*F> prop_abort 1
True
```
Session 2 \[fails\]:
```
$ ghci -O1 -fobject-code F.hs
GHCi, version 8.0.0.20160204: http://www.haskell.org/ghc/ :? for help
[1 of 1] Compiling F ( F.hs, F.o )
Ok, modules loaded: F.
Prelude F> prop_abort 1
*** Exception: xmonad: StackSet: fail
CallStack (from HasCallStack):
error, called at F.hs:9:11 in main:F
```
I would expect exception to be caught on both cases.
Is it unreasonable expectation in light of unsafePerformIO?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.1-rc2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | simonpj |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"catch under unsafePerformIO breaks on -O1","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1-rc2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["simonpj"],"type":"Bug","description":"Discovered on xmonad-0.12 test failure.\r\nHappens on today's -HEAD and ghc-8.0.1-rc1,-rc2\r\n\r\nShort example is (needs only base):\r\n{{{#!hs\r\n-- cat F.hs\r\nmodule F where\r\n\r\nimport qualified Control.Exception as C\r\nimport System.IO.Unsafe\r\nimport qualified Data.List as L\r\n\r\nabort :: String -> a\r\nabort x = error $ \"xmonad: StackSet: \" ++ x\r\n\r\nprop_abort x = unsafePerformIO $ C.catch (abort \"fail\")\r\n (\\(C.SomeException e) ->\r\n return $ \"xmonad: StackSet: fail\" `L.isPrefixOf` show e )\r\n where\r\n _ = x :: Int\r\n}}}\r\n\r\nSession 1 [ok]:\r\n{{{\r\n$ ghci F.hs\r\n\r\nGHCi, version 8.0.0.20160204: http://www.haskell.org/ghc/ :? for help\r\n[1 of 1] Compiling F ( F.hs, interpreted )\r\nOk, modules loaded: F.\r\n\r\n*F> prop_abort 1\r\nTrue\r\n}}}\r\n\r\nSession 2 [fails]:\r\n{{{\r\n$ ghci -O1 -fobject-code F.hs\r\n\r\nGHCi, version 8.0.0.20160204: http://www.haskell.org/ghc/ :? for help\r\n[1 of 1] Compiling F ( F.hs, F.o )\r\nOk, modules loaded: F.\r\n\r\nPrelude F> prop_abort 1\r\n*** Exception: xmonad: StackSet: fail\r\nCallStack (from HasCallStack):\r\n error, called at F.hs:9:11 in main:F\r\n}}}\r\n\r\nI would expect exception to be caught on both cases.\r\nIs it unreasonable expectation in light of unsafePerformIO?\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://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/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/9839RTS options parser silently accepts invalid flags2019-07-07T18:38:49ZAdam GundryRTS options parser silently accepts invalid flagsRTS options that do not take arguments (such as `-T`) silently ignore anything that comes afterwards. For example, `+RTS -T,-s` or `+RTS -T-s` turns on collection of GC statistics (`-T`) but does not print out a summary (`-s`). Instead, ...RTS options that do not take arguments (such as `-T`) silently ignore anything that comes afterwards. For example, `+RTS -T,-s` or `+RTS -T-s` turns on collection of GC statistics (`-T`) but does not print out a summary (`-s`). Instead, this should produce an error message. Otherwise, users may mistakenly think that options have been applied.
(This has just bitten us in a production system.)
<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":"RTS options parser silently accepts invalid flags","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":"RTS options that do not take arguments (such as `-T`) silently ignore anything that comes afterwards. For example, `+RTS -T,-s` or `+RTS -T-s` turns on collection of GC statistics (`-T`) but does not print out a summary (`-s`). Instead, this should produce an error message. Otherwise, users may mistakenly think that options have been applied.\r\n\r\n(This has just bitten us in a production system.)","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1nkartashovnkartashovhttps://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/8726integer-gmp division regression2019-07-07T18:43:46Zerikdinteger-gmp division regressionWith ghc 7.6.3:
```
ghci> quotRem 0x10000000000000001 (-0x100000)
(-17592186044416,1)
ghci> quotRem 0x10000001 (-0x100000)
(-256,1)
```
with ghc 7.7
```
ghci> quotRem 0x10000000000000001 (-0x100000)
(-17592186044416,-1)
ghci> quotRem ...With ghc 7.6.3:
```
ghci> quotRem 0x10000000000000001 (-0x100000)
(-17592186044416,1)
ghci> quotRem 0x10000001 (-0x100000)
(-256,1)
```
with ghc 7.7
```
ghci> quotRem 0x10000000000000001 (-0x100000)
(-17592186044416,-1)
ghci> quotRem 0x10000001 (-0x100000)
(-256,1)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 7.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries (other) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"integer-gmp division regression","status":"New","operating_system":"","component":"libraries (other)","related":[],"milestone":"7.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.7","keywords":["Integer"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"With ghc 7.6.3:\r\n\r\n{{{\r\nghci> quotRem 0x10000000000000001 (-0x100000)\r\n(-17592186044416,1)\r\nghci> quotRem 0x10000001 (-0x100000)\r\n(-256,1)\r\n}}}\r\n\r\nwith ghc 7.7\r\n\r\n{{{\r\nghci> quotRem 0x10000000000000001 (-0x100000)\r\n(-17592186044416,-1)\r\nghci> quotRem 0x10000001 (-0x100000)\r\n(-256,1)\r\n}}}\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1Herbert Valerio Riedelhvr@gnu.orgHerbert Valerio Riedelhvr@gnu.orghttps://gitlab.haskell.org/ghc/ghc/-/issues/8291unloadObj doesn't work, unloaded_objects list keeps growing in size2019-07-07T18:45:42ZEdward Z. YangunloadObj doesn't work, unloaded_objects list keeps growing in sizeShows up as the linker_unload test going very slowly and triggering the timeout on my box. Verified by looking at the unloaded_objects list, which contains multiple copies of Test.o. I haven't investigated any further.
<details><summary...Shows up as the linker_unload test going very slowly and triggering the timeout on my box. Verified by looking at the unloaded_objects list, which contains multiple copies of Test.o. I haven't investigated any further.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | MacOS X |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"unloadObj doesn't work on Mac OS X","status":"New","operating_system":"MacOS X","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"simonmar"},"version":"7.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Shows up as the linker_unload test going very slowly and triggering the timeout on my box. Verified by looking at the unloaded_objects list, which contains multiple copies of Test.o. I haven't investigated any further.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/8083setNumCapabilities broken in HEAD2019-07-07T18:46:34ZparcssetNumCapabilities broken in HEAD```haskell
import GHC.Conc
import Control.Monad
main :: IO ()
main = do
n <- getNumCapabilities
when (n == 1) $ setNumCapabilities 2
print ()
```
One would expect this program to print () just once, but when compiled with -...```haskell
import GHC.Conc
import Control.Monad
main :: IO ()
main = do
n <- getNumCapabilities
when (n == 1) $ setNumCapabilities 2
print ()
```
One would expect this program to print () just once, but when compiled with -O or -O2 it prints () repeatedly and indefinitely!
This doesn't happen on GHC 7.6.2 or 7.4.1, only on HEAD.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.7 |
| 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":"setNumCapabilities broken in HEAD","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\n#!haskell\r\nimport GHC.Conc\r\nimport Control.Monad\r\n\r\nmain :: IO ()\r\nmain = do\r\n n <- getNumCapabilities\r\n when (n == 1) $ setNumCapabilities 2\r\n print ()\r\n}}}\r\n\r\nOne would expect this program to print () just once, but when compiled with -O or -O2 it prints () repeatedly and indefinitely!\r\n\r\nThis doesn't happen on GHC 7.6.2 or 7.4.1, only on HEAD.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/7493STM and TVar report incorrect results2019-07-07T18:49:30ZparcsSTM and TVar report incorrect resultsOn Haskell Cafe, I posted:
I'm getting strange behavior when using the 'many' combinator to read zero or more items off of a TQueue with readTQueue. The script that exhibits this behavior is as follows:
```
import Control.Concurrent.ST...On Haskell Cafe, I posted:
I'm getting strange behavior when using the 'many' combinator to read zero or more items off of a TQueue with readTQueue. The script that exhibits this behavior is as follows:
```
import Control.Concurrent.STM
import Control.Concurrent
import Control.Monad
import Control.Applicative
main = do
q <- newTQueueIO
atomically $ writeTQueue q True
atomically $ writeTQueue q False
forever $ do
xs <- atomically $ many $ readTQueue q
print xs
threadDelay 500000
```
I'd expect the output of the script to be:
```
[True,False]
[]
[]
...
```
However, that is not the case: the actual output of the script is:
```
[True,False]
[True,False]
[True,False]
...
```
If 1 element (say, True) is written into the TQueue instead of 2, then the output of the script is:
```
[True]
[]
[]
...
```
Which is expected behavior, but inconsistent with the behavior when the TQueue has 2 or more elements in it.
Is this considered a bug, or undocumented behavior of TQueue?
----
Bas vas Dijk noted that this may be a bug in STM, and provided a condensed test case which reproduces the behavior of my original script:
```
$ cat stmTest.hs
import Control.Concurrent.STM
main = do
x <- atomically $ do
t <- newTVar 1
writeTVar t 2
((readTVar t >> retry) `orElse` return ()) `orElse` return ()
readTVar t
print x
$ ghc --make stmTest.hs -fforce-recomp -threaded -o stmTest && ./stmTest
[1 of 1] Compiling Main ( stmTest.hs, stmTest.o )
Linking stmTest ...
1
```
The program prints 1 when it should print 2.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------------- |
| Version | 7.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | v.dijk.bas@gmail.com |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"STM and TVar report incorrect results","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["v.dijk.bas@gmail.com"],"type":"Bug","description":"On Haskell Cafe, I posted:\r\n\r\nI'm getting strange behavior when using the 'many' combinator to read zero or more items off of a TQueue with readTQueue. The script that exhibits this behavior is as follows:\r\n\r\n{{{\r\nimport Control.Concurrent.STM\r\nimport Control.Concurrent\r\nimport Control.Monad\r\nimport Control.Applicative\r\n\r\nmain = do\r\n q <- newTQueueIO\r\n atomically $ writeTQueue q True\r\n atomically $ writeTQueue q False\r\n forever $ do\r\n xs <- atomically $ many $ readTQueue q\r\n print xs\r\n threadDelay 500000\r\n}}}\r\n\r\nI'd expect the output of the script to be:\r\n{{{\r\n[True,False]\r\n[]\r\n[]\r\n...\r\n}}}\r\n\r\nHowever, that is not the case: the actual output of the script is:\r\n{{{\r\n[True,False]\r\n[True,False]\r\n[True,False]\r\n...\r\n}}}\r\n\r\nIf 1 element (say, True) is written into the TQueue instead of 2, then the output of the script is:\r\n{{{\r\n[True]\r\n[]\r\n[]\r\n...\r\n}}}\r\n\r\nWhich is expected behavior, but inconsistent with the behavior when the TQueue has 2 or more elements in it.\r\n\r\nIs this considered a bug, or undocumented behavior of TQueue?\r\n\r\n----\r\n\r\nBas vas Dijk noted that this may be a bug in STM, and provided a condensed test case which reproduces the behavior of my original script:\r\n\r\n{{{\r\n$ cat stmTest.hs\r\nimport Control.Concurrent.STM\r\nmain = do\r\n x <- atomically $ do\r\n t <- newTVar 1\r\n writeTVar t 2\r\n ((readTVar t >> retry) `orElse` return ()) `orElse` return ()\r\n readTVar t\r\n print x\r\n\r\n$ ghc --make stmTest.hs -fforce-recomp -threaded -o stmTest && ./stmTest\r\n[1 of 1] Compiling Main ( stmTest.hs, stmTest.o )\r\nLinking stmTest ...\r\n1\r\n}}}\r\n\r\nThe program prints 1 when it should print 2.","type_of_failure":"OtherFailure","blocking":[]} -->7.6.2https://gitlab.haskell.org/ghc/ghc/-/issues/7270Incorrect optimization with Data.ByteString.append2019-07-07T18:50:34ZocheronIncorrect optimization with Data.ByteString.appendThe following program does not give the same result with -O2 and without:
```
import qualified Data.ByteString as B
main = let a = B.singleton 65 in print (func a a)
func y z = B.append r s
where
r = B.map (succ) x
s = B.map...The following program does not give the same result with -O2 and without:
```
import qualified Data.ByteString as B
main = let a = B.singleton 65 in print (func a a)
func y z = B.append r s
where
r = B.map (succ) x
s = B.map (succ . succ) x
x = B.append y z
```
Result observed with GHC 7.6.1 (bytestring-0.10.0.0):
```
$ ghc --make test -fforce-recomp && ./test
[1 of 1] Compiling Main ( test.hs, test.o )
Linking test ...
"BBCC"
$ ghc --make test -fforce-recomp -O2 && ./test
[1 of 1] Compiling Main ( test.hs, test.o )
Linking test ...
"CCCC"
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 7.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries (other) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Incorrect optimization with Data.ByteString.append","status":"New","operating_system":"","component":"libraries (other)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The following program does not give the same result with -O2 and without:\r\n{{{\r\nimport qualified Data.ByteString as B\r\n\r\nmain = let a = B.singleton 65 in print (func a a)\r\n\r\nfunc y z = B.append r s\r\n where\r\n r = B.map (succ) x\r\n s = B.map (succ . succ) x\r\n x = B.append y z\r\n}}}\r\n\r\nResult observed with GHC 7.6.1 (bytestring-0.10.0.0):\r\n{{{\r\n$ ghc --make test -fforce-recomp && ./test\r\n[1 of 1] Compiling Main ( test.hs, test.o )\r\nLinking test ...\r\n\"BBCC\"\r\n$ ghc --make test -fforce-recomp -O2 && ./test\r\n[1 of 1] Compiling Main ( test.hs, test.o )\r\nLinking test ...\r\n\"CCCC\"\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.6.2duncanduncanhttps://gitlab.haskell.org/ghc/ghc/-/issues/7215miscompilation due to broken interface hash2019-07-07T18:50:50Ztakano-akiomiscompilation due to broken interface hashThe following script should print '!MyFalse !MyTrue' but it prints '!MyFalse !MyFalse'. (warning: it removes files in the current directory)
```
rm -f main main.o main.hi MyBool.hi MyBool.o Foo.hi Foo.o
ghc=ghc
echo 'module MyBool wher...The following script should print '!MyFalse !MyTrue' but it prints '!MyFalse !MyFalse'. (warning: it removes files in the current directory)
```
rm -f main main.o main.hi MyBool.hi MyBool.o Foo.hi Foo.o
ghc=ghc
echo 'module MyBool where data MyBool = MyFalse | MyTrue deriving Show' > MyBool.hs
echo 'module Foo where import MyBool; foo = MyFalse' > Foo.hs
echo 'import Foo; main = print foo' > main.hs
$ghc -c -O2 MyBool.hs
$ghc -c -O2 Foo.hs
$ghc -O2 main.hs
./main
echo 'module Foo where import MyBool; foo = MyTrue' > Foo.hs
$ghc -c -O2 Foo.hs
$ghc -O2 main.hs
./main
```
The issue seems to be that the second version of Foo.hs gets the same interface hash as the old one. This stops GHC from updating Foo.hi, which contains an outdated unfolding.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.4.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"miscompilation due to broken interface hash","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.4.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The following script should print '!MyFalse !MyTrue' but it prints '!MyFalse !MyFalse'. (warning: it removes files in the current directory)\r\n\r\n{{{\r\nrm -f main main.o main.hi MyBool.hi MyBool.o Foo.hi Foo.o\r\n\r\nghc=ghc\r\necho 'module MyBool where data MyBool = MyFalse | MyTrue deriving Show' > MyBool.hs\r\necho 'module Foo where import MyBool; foo = MyFalse' > Foo.hs\r\necho 'import Foo; main = print foo' > main.hs\r\n$ghc -c -O2 MyBool.hs\r\n$ghc -c -O2 Foo.hs\r\n$ghc -O2 main.hs\r\n./main\r\necho 'module Foo where import MyBool; foo = MyTrue' > Foo.hs\r\n$ghc -c -O2 Foo.hs\r\n$ghc -O2 main.hs\r\n./main\r\n}}}\r\n\r\nThe issue seems to be that the second version of Foo.hs gets the same interface hash as the old one. This stops GHC from updating Foo.hi, which contains an outdated unfolding.","type_of_failure":"OtherFailure","blocking":[]} -->7.6.2Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/7172GHCi :issafe command doesn't work2019-07-07T18:51:00ZdtereiGHCi :issafe command doesn't workIn HEAD and GHC 7.6 RC the ghci :issafe command simply doesn't report the correct result.
I will fix very soon (e.g. 48 hours) but wanted to have this bug be tracked and made a high priority so 7.6 isn't released before I fix it.
<deta...In HEAD and GHC 7.6 RC the ghci :issafe command simply doesn't report the correct result.
I will fix very soon (e.g. 48 hours) but wanted to have this bug be tracked and made a high priority so 7.6 isn't released before I fix it.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.6.1-rc1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHCi :issafe command doesn't work","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"dterei"},"version":"7.6.1-rc1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"In HEAD and GHC 7.6 RC the ghci :issafe command simply doesn't report the correct result.\r\n\r\nI will fix very soon (e.g. 48 hours) but wanted to have this bug be tracked and made a high priority so 7.6 isn't released before I fix it.","type_of_failure":"OtherFailure","blocking":[]} -->7.6.1dtereidtereihttps://gitlab.haskell.org/ghc/ghc/-/issues/7163nofib/real/gg is miscompiled at -O12019-07-07T18:51:03ZMichal Terepetanofib/real/gg is miscompiled at -O1I've noticed that ```nofib/real/gg``` fails (output mismatch) and after reducing
the problem I've got the following small example (the trace expressions can also
be removed):
```
module Main where
import Debug.Trace
main = d...I've noticed that ```nofib/real/gg``` fails (output mismatch) and after reducing
the problem I've got the following small example (the trace expressions can also
be removed):
```
module Main where
import Debug.Trace
main = do
putStrLn $ printFloat 100
printFloat :: Float -> String
printFloat x = f (show (round (x*10)))
where
f "0" = trace "case 0" "0"
f _ = trace "case _" $ show (round x)
}}}
compiling it with current HEAD:
{{{
> ~/dev/ghc-clean/inplace/bin/ghc-stage2 -fforce-recomp -O0 Test.hs
[1 of 1] Compiling Main ( Test.hs, Test.o )
Linking Test ...
> ./Test
case _
100
> ~/dev/ghc-clean/inplace/bin/ghc-stage2 -fforce-recomp -O1 Test.hs
[1 of 1] Compiling Main ( Test.hs, Test.o )
Linking Test ...
> ./Test
case _
1000
> ~/dev/ghc-clean/inplace/bin/ghc-stage2 -fforce-recomp -O2 Test.hs
[1 of 1] Compiling Main ( Test.hs, Test.o )
Linking Test ...
> ./Test
case _
100
}}}
Note that with ```-O1``` the output is 1000! It seems that the bug is either in
the old codegen or the new one does not trigger it:
{{{
> ~/dev/ghc-clean/inplace/bin/ghc-stage2 -fforce-recomp -O1 -fnew-codegen Test.hs
[1 of 1] Compiling Main ( Test.hs, Test.o )
Linking Test ...
> ./Test
case _
100
```
I've also looked at assembly and the only thing that I've noticed is that two
instructions are in different order when compiling with ```O1```:
```
Main.$wprintFloat_info:
_c28u:
leaq -40(%rbp),%rax
cmpq %r15,%rax
jb _c2aV
mulss _n2aX(%rip),%xmm1 <--- !
movss %xmm1,%xmm0 <--- !
subq $8,%rsp
movl $1,%eax
call rintFloat
addq $8,%rsp
movss %xmm1,-8(%rbp)
movss %xmm0,%xmm1
movq $s23Y_info,-16(%rbp)
addq $-16,%rbp
jmp stg_decodeFloat_Int#
_c2aV:
movl $Main.$wprintFloat_closure,%ebx
jmp *-8(%r13)
.size Main.$wprintFloat_info, .-Main.$wprintFloat_info
.section .rodata
.align 8
.align 4
}}}
and ```O2```:
{{{
Main.$wprintFloat_info:
_c28R:
leaq -40(%rbp),%rax
cmpq %r15,%rax
jb _c2aX
movss %xmm1,%xmm0 <--- !
mulss _n2aZ(%rip),%xmm0 <--- !
subq $8,%rsp
movl $1,%eax
call rintFloat
addq $8,%rsp
movss %xmm1,-8(%rbp)
movss %xmm0,%xmm1
movq $s24l_info,-16(%rbp)
addq $-16,%rbp
jmp stg_decodeFloat_Int#
_c2aX:
movl $Main.$wprintFloat_closure,%ebx
jmp *-8(%r13)
.size Main.$wprintFloat_info, .-Main.$wprintFloat_info
.section .rodata
.align 8
.align 4
}}}
If I read this right, in ```O1``` case the ```xmm1``` register will contain 1000
(1000 * 10) and this value will be stored on the stack, whereas the ```O2```
version first moves the value from ```xmm1``` to ```xmm0``` and only then
multiplies it (and also stores ```xmm1``` on the stack but this time it should
be equal to 100). So if the value stored on the stack is subsequently used, it
would explain the difference between the two programs.
For the record this is on x86_64 Linux and the GHC version used is:
{{{
> ~/dev/ghc-clean/inplace/bin/ghc-stage2 --version
The Glorious Glasgow Haskell Compilation System, version 7.7.20120816
```
Everything works as expected on GHC-7.4.2.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.7 |
| 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":"nofib/real/gg is miscompiled at -O1","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I've noticed that ```nofib/real/gg``` fails (output mismatch) and after reducing\r\nthe problem I've got the following small example (the trace expressions can also\r\nbe removed):\r\n{{{\r\n module Main where\r\n\r\n import Debug.Trace\r\n\r\n main = do\r\n putStrLn $ printFloat 100\r\n\r\n printFloat :: Float -> String\r\n printFloat x = f (show (round (x*10)))\r\n where\r\n f \"0\" = trace \"case 0\" \"0\"\r\n f _ = trace \"case _\" $ show (round x)\r\n }}}\r\ncompiling it with current HEAD:\r\n{{{\r\n > ~/dev/ghc-clean/inplace/bin/ghc-stage2 -fforce-recomp -O0 Test.hs\r\n [1 of 1] Compiling Main ( Test.hs, Test.o )\r\n Linking Test ...\r\n > ./Test\r\n case _\r\n 100\r\n > ~/dev/ghc-clean/inplace/bin/ghc-stage2 -fforce-recomp -O1 Test.hs\r\n [1 of 1] Compiling Main ( Test.hs, Test.o )\r\n Linking Test ...\r\n > ./Test\r\n case _\r\n 1000\r\n > ~/dev/ghc-clean/inplace/bin/ghc-stage2 -fforce-recomp -O2 Test.hs\r\n [1 of 1] Compiling Main ( Test.hs, Test.o )\r\n Linking Test ...\r\n > ./Test\r\n case _\r\n 100\r\n }}}\r\nNote that with ```-O1``` the output is 1000! It seems that the bug is either in\r\nthe old codegen or the new one does not trigger it:\r\n{{{\r\n > ~/dev/ghc-clean/inplace/bin/ghc-stage2 -fforce-recomp -O1 -fnew-codegen Test.hs\r\n [1 of 1] Compiling Main ( Test.hs, Test.o )\r\n Linking Test ...\r\n > ./Test\r\n case _\r\n 100\r\n}}}\r\nI've also looked at assembly and the only thing that I've noticed is that two\r\ninstructions are in different order when compiling with ```O1```:\r\n{{{\r\n Main.$wprintFloat_info:\r\n _c28u:\r\n leaq -40(%rbp),%rax\r\n cmpq %r15,%rax\r\n jb _c2aV\r\n mulss _n2aX(%rip),%xmm1 <--- !\r\n movss %xmm1,%xmm0 <--- !\r\n subq $8,%rsp\r\n movl $1,%eax\r\n call rintFloat\r\n addq $8,%rsp\r\n movss %xmm1,-8(%rbp)\r\n movss %xmm0,%xmm1\r\n movq $s23Y_info,-16(%rbp)\r\n addq $-16,%rbp\r\n jmp stg_decodeFloat_Int#\r\n _c2aV:\r\n movl $Main.$wprintFloat_closure,%ebx\r\n jmp *-8(%r13)\r\n .size Main.$wprintFloat_info, .-Main.$wprintFloat_info\r\n .section .rodata\r\n .align 8\r\n .align 4\r\n }}}\r\nand ```O2```:\r\n{{{\r\n Main.$wprintFloat_info:\r\n _c28R:\r\n leaq -40(%rbp),%rax\r\n cmpq %r15,%rax\r\n jb _c2aX\r\n movss %xmm1,%xmm0 <--- !\r\n mulss _n2aZ(%rip),%xmm0 <--- !\r\n subq $8,%rsp\r\n movl $1,%eax\r\n call rintFloat\r\n addq $8,%rsp\r\n movss %xmm1,-8(%rbp)\r\n movss %xmm0,%xmm1\r\n movq $s24l_info,-16(%rbp)\r\n addq $-16,%rbp\r\n jmp stg_decodeFloat_Int#\r\n _c2aX:\r\n movl $Main.$wprintFloat_closure,%ebx\r\n jmp *-8(%r13)\r\n .size Main.$wprintFloat_info, .-Main.$wprintFloat_info\r\n .section .rodata\r\n .align 8\r\n .align 4\r\n }}}\r\nIf I read this right, in ```O1``` case the ```xmm1``` register will contain 1000\r\n(1000 * 10) and this value will be stored on the stack, whereas the ```O2```\r\nversion first moves the value from ```xmm1``` to ```xmm0``` and only then\r\nmultiplies it (and also stores ```xmm1``` on the stack but this time it should\r\nbe equal to 100). So if the value stored on the stack is subsequently used, it\r\nwould explain the difference between the two programs.\r\n\r\nFor the record this is on x86_64 Linux and the GHC version used is:\r\n{{{\r\n> ~/dev/ghc-clean/inplace/bin/ghc-stage2 --version\r\nThe Glorious Glasgow Haskell Compilation System, version 7.7.20120816\r\n}}}\r\nEverything works as expected on GHC-7.4.2.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/7138GHCi does no respect -ignore-dot-ghci anymore2019-07-07T18:51:10ZSimon Hengelsol@typeful.netGHCi does no respect -ignore-dot-ghci anymoreSteps to reproduce:
```
$ echo foobar > .ghci
$ ghci -ignore-dot-ghci
```
Expected results: GHCi is started without any errors.
Actual result: GHCi reports "Not in scope: \`foobar'".
<details><summary>Trac metadata</summary>
| Trac ...Steps to reproduce:
```
$ echo foobar > .ghci
$ ghci -ignore-dot-ghci
```
Expected results: GHCi is started without any errors.
Actual result: GHCi reports "Not in scope: \`foobar'".
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.6.1-rc1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHCi does no respect -ignore-dot-ghci anymore","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.1-rc1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Steps to reproduce:\r\n\r\n{{{\r\n$ echo foobar > .ghci\r\n$ ghci -ignore-dot-ghci\r\n}}}\r\n\r\nExpected results: GHCi is started without any errors.\r\n\r\nActual result: GHCi reports \"Not in scope: `foobar'\".","type_of_failure":"OtherFailure","blocking":[]} -->7.6.1pcapriottipcapriottihttps://gitlab.haskell.org/ghc/ghc/-/issues/7117Data family constructors defined in GHCi are not in scope2019-07-07T18:51:18ZparcsData family constructors defined in GHCi are not in scopeThe following example explains the problem:
```
> data family Foo a
> data instance Foo Int = FooInt
> :t FooInt
<interactive>:1:1: Not in scope: data constructor `FooInt'
```
`FooInt` is defined, but `GHCi` doesn't recognize it.
<de...The following example explains the problem:
```
> data family Foo a
> data instance Foo Int = FooInt
> :t FooInt
<interactive>:1:1: Not in scope: data constructor `FooInt'
```
`FooInt` is defined, but `GHCi` doesn't recognize it.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.4.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Data family constructors defined in GHCi are not in scope","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.4.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The following example explains the problem:\r\n\r\n{{{\r\n> data family Foo a\r\n> data instance Foo Int = FooInt\r\n> :t FooInt\r\n\r\n<interactive>:1:1: Not in scope: data constructor `FooInt'\r\n}}}\r\n\r\n`FooInt` is defined, but `GHCi` doesn't recognize it.","type_of_failure":"OtherFailure","blocking":[]} -->7.6.1pcapriottipcapriotti