GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:43:22Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/8804BlockedIndefinitelyOnMVar thrown for an MVar which is still weakly accessible...2019-07-07T18:43:22ZbholstBlockedIndefinitelyOnMVar thrown for an MVar which is still weakly accessible from another threadGHC's runtime system throws a BlockedIndefinatelyOnMVar exception
when the thread blocking an the MVar is the only one having a direct access to it. It assumes that there will be nothing written into the MVar in the future.
This would be...GHC's runtime system throws a BlockedIndefinatelyOnMVar exception
when the thread blocking an the MVar is the only one having a direct access to it. It assumes that there will be nothing written into the MVar in the future.
This would be the correct behaviour if there were no weak references.
The runtime system even throws the Exception when another thread still has a weak reference to the MVar. Consider the following example:
```
import Control.Concurrent
import System.Mem.Weak
import Data.Maybe
import Control.Monad
main = do
m <- newEmptyMVar
w <- mkWeakMVar m (return ())
forkIO $ do
threadDelay 1000000
n <- deRefWeak w
when (isJust n) $ putMVar (fromJust n) ()
takeMVar m
```
At the time of *takeMVar* the forked thread has a weak reference to
the MVar and it will put a value in it. However, the runtime system throws the Exception:
```
% ghc BlockingOnMVar.hs -threaded
Linking BlockingOnMVar ...
% ./BlockingOnMVar +RTS -N2
BlockingOnMVar: thread blocked indefinitely in an MVar operation
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.6.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":"BlockedIndefinitelyOnMVar thrown for an MVar which is still weakly accessible from another thread","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"simonmar"},"version":"7.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["simonmar"],"type":"Bug","description":"GHC's runtime system throws a BlockedIndefinatelyOnMVar exception\r\nwhen the thread blocking an the MVar is the only one having a direct access to it. It assumes that there will be nothing written into the MVar in the future.\r\nThis would be the correct behaviour if there were no weak references.\r\nThe runtime system even throws the Exception when another thread still has a weak reference to the MVar. Consider the following example:\r\n{{{\r\nimport Control.Concurrent\r\nimport System.Mem.Weak\r\nimport Data.Maybe\r\nimport Control.Monad\r\n\r\nmain = do\r\n m <- newEmptyMVar\r\n w <- mkWeakMVar m (return ())\r\n forkIO $ do\r\n threadDelay 1000000\r\n n <- deRefWeak w\r\n when (isJust n) $ putMVar (fromJust n) ()\r\n takeMVar m\r\n}}}\r\n\r\nAt the time of ''takeMVar'' the forked thread has a weak reference to\r\nthe MVar and it will put a value in it. However, the runtime system throws the Exception: \r\n\r\n{{{\r\n% ghc BlockingOnMVar.hs -threaded\r\nLinking BlockingOnMVar ...\r\n% ./BlockingOnMVar +RTS -N2 \r\nBlockingOnMVar: thread blocked indefinitely in an MVar operation\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/8823showFloat for higher precision types produces strange results for some values2019-07-07T18:43:14ZAlex MasonshowFloat for higher precision types produces strange results for some valuesI've written a library which is a quda-double type a la the QD C/C++ package, and showFloat does not behave correctly for numbers with such high precision.
My type has \~212 bits of precision, and when using showFloat from Numeric, I ge...I've written a library which is a quda-double type a la the QD C/C++ package, and showFloat does not behave correctly for numbers with such high precision.
My type has \~212 bits of precision, and when using showFloat from Numeric, I get strange results for integer values:
```
show (1 :: QDouble) = "0.00000000000000000000000000000000000000000000001e47"
show (1.1 :: QDouble) = "1.1"
show (1000 :: QDouble) = "0.00000000000000000000000000000000000000000000001e50"
-- These seems to suggest it happens for any number with only a
-- few high bits set to 1 in the result of decodeFloat
show (1.125 :: QDouble) = "0.00000000000000000000000000000000000000000000001125e47"
show (1.625 :: QDouble) = "0.00000000000000000000000000000000000000000000001625e47"
```
The problem seems to be related to the result of floatDigits, which starts causing problem when it's larger than 56 (floatDigits x, show x):
```
(56,"1.0")
(57,"01.0")
(60,"001.0")
(212,"0.00000000000000000000000000000000000000000000001e47")
```
My fix has been to use a modified version of showFloat from Numeric by changing the floatToDigits function to include a fix for times when large numbers of zeros are produced:
```
fixup2 (xs,k) = let (zs,ys) = span (==0) xs in (ys,k-length zs)
in
fixup2 (map fromIntegral (reverse rds), k)
```
This fixes the symptom but not the issue itself (though it seems like a reasonable thing to have any result returned by floatToDigits.
I have attached as minimal test case as I could come up with. Using floatToDigits from Numeric causes the strange behaviour, while floatToDigits' included in the test case does not.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.1-rc1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | Prelude |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"showFloat for higher precision types produces strange results for some values","status":"New","operating_system":"","component":"Prelude","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.1-rc1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I've written a library which is a quda-double type a la the QD C/C++ package, and showFloat does not behave correctly for numbers with such high precision.\r\n\r\nMy type has ~212 bits of precision, and when using showFloat from Numeric, I get strange results for integer values:\r\n\r\n{{{\r\nshow (1 :: QDouble) = \"0.00000000000000000000000000000000000000000000001e47\"\r\nshow (1.1 :: QDouble) = \"1.1\"\r\nshow (1000 :: QDouble) = \"0.00000000000000000000000000000000000000000000001e50\"\r\n-- These seems to suggest it happens for any number with only a\r\n-- few high bits set to 1 in the result of decodeFloat\r\nshow (1.125 :: QDouble) = \"0.00000000000000000000000000000000000000000000001125e47\"\r\nshow (1.625 :: QDouble) = \"0.00000000000000000000000000000000000000000000001625e47\"\r\n}}}\r\n\r\nThe problem seems to be related to the result of floatDigits, which starts causing problem when it's larger than 56 (floatDigits x, show x):\r\n{{{\r\n(56,\"1.0\")\r\n(57,\"01.0\")\r\n(60,\"001.0\")\r\n(212,\"0.00000000000000000000000000000000000000000000001e47\")\r\n}}}\r\n\r\nMy fix has been to use a modified version of showFloat from Numeric by changing the floatToDigits function to include a fix for times when large numbers of zeros are produced:\r\n\r\n{{{\r\n fixup2 (xs,k) = let (zs,ys) = span (==0) xs in (ys,k-length zs)\r\n in\r\n fixup2 (map fromIntegral (reverse rds), k)\r\n}}}\r\n\r\nThis fixes the symptom but not the issue itself (though it seems like a reasonable thing to have any result returned by floatToDigits.\r\n\r\nI have attached as minimal test case as I could come up with. Using floatToDigits from Numeric causes the strange behaviour, while floatToDigits' included in the test case does not.","type_of_failure":"OtherFailure","blocking":[]} -->https://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/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/8898Overall improvement for randomIvalInteger2019-07-07T18:42:54ZnovadenizenOverall improvement for randomIvalIntegerThe current `randomIvalInteger` implementation uses repeated `div` operations to approximate the size of the desired random output, then generates that number of random values from the given `RandomGen`. It does not compensate for the ``...The current `randomIvalInteger` implementation uses repeated `div` operations to approximate the size of the desired random output, then generates that number of random values from the given `RandomGen`. It does not compensate for the ``mod` base` uniformity problem. It also assumes that all `RandomGen` implementations produce the same range of random values as `StdGen`.
My new implementation addresses all these correctness issues, with potentially a slight performance improvement.
Instead of performing repeated div base operations to determine the size of the desired range, this uses faster `(* base)` operations. An equivalent set of intermediate `Integer`s is generated still.
To compensate for the ``mod` base` uniformity problem, the desired range size is multiplied by the *q* factor (1000 in my code). When *k* is the desired range and *b\^n\^* is the range of numbers generated, and *d = b\^n\^ div k*, some elements will have probability *d/b\^n\^* and others will have probability *(d+1)/b\^n\^*, resulting in significant non-uniformity when *d* is very small. When you extend the generated range beyond the minimum by a factor of *q*, you are guaranteed that *d* will be at least *q*, so the non-uniformity will be much less consequential.
This implementation also works with any `RandomGen`, even ones that produce as little as a single bit of entropy per next call or have a minimum bound other than zero.https://gitlab.haskell.org/ghc/ghc/-/issues/8952Bang patterns don't work as the specification says2019-07-07T18:42:39ZdolioBang patterns don't work as the specification saysIn investigating the behavior of bang patterns for an implementation of my own, I came across a discrepancy between the specification and GHC's implementation. Here is an example:
```
case Nothing of
!(~(Just x)) -> 5
Nothing -...In investigating the behavior of bang patterns for an implementation of my own, I came across a discrepancy between the specification and GHC's implementation. Here is an example:
```
case Nothing of
!(~(Just x)) -> 5
Nothing -> 12
```
This evaluates to 12. In other words, !(\~p) is equivalent to p. However, the bang patterns description says that this should be equivalent to:
```
Nothing `seq` case Nothing of
~(Just x) -> 5
Nothing -> 12
```
which evaluates to 5. So, one of either the description or the implementation must be incorrect. In fact, GHC is even a bit confused, as it issues a warning about overlapping patterns for the bang pattern case statement, even though the successful branch is the 'unreachable' one.
The description makes more sense to me, but I'm not terribly invested in the behavior of this; it is admittedly a pretty obscure corner case.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.6.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":"Bang patterns don't work as the specification says","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"In investigating the behavior of bang patterns for an implementation of my own, I came across a discrepancy between the specification and GHC's implementation. Here is an example:\r\n\r\n{{{\r\ncase Nothing of\r\n !(~(Just x)) -> 5\r\n Nothing -> 12\r\n}}}\r\n\r\nThis evaluates to 12. In other words, !(~p) is equivalent to p. However, the bang patterns description says that this should be equivalent to:\r\n\r\n{{{\r\nNothing `seq` case Nothing of\r\n ~(Just x) -> 5\r\n Nothing -> 12\r\n}}}\r\n\r\nwhich evaluates to 5. So, one of either the description or the implementation must be incorrect. In fact, GHC is even a bit confused, as it issues a warning about overlapping patterns for the bang pattern case statement, even though the successful branch is the 'unreachable' one.\r\n\r\nThe description makes more sense to me, but I'm not terribly invested in the behavior of this; it is admittedly a pretty obscure corner case.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/9035ghci sometimes displays Word32 as Word642019-07-07T18:42:12ZMikeIzbickighci sometimes displays Word32 as Word64Given this code:
```
module Main
where
import Data.Word
import Unsafe.Coerce
import System.IO
nanFloat :: Float
nanFloat = unsafeCoerce (maxBound :: Word32)
float2word32 :: Float -> Word32
float2word32 = unsafeCoerce
nanDouble :...Given this code:
```
module Main
where
import Data.Word
import Unsafe.Coerce
import System.IO
nanFloat :: Float
nanFloat = unsafeCoerce (maxBound :: Word32)
float2word32 :: Float -> Word32
float2word32 = unsafeCoerce
nanDouble :: Double
nanDouble = unsafeCoerce (maxBound :: Word64)
double2word64 :: Double -> Word64
double2word64 = unsafeCoerce
main = do
putStrLn $ "nanFloat = " ++ show (float2word32 nanFloat)
putStrLn $ "nanFloat = " ++ show (float2word32 $ nanFloat + 1)
putStrLn $ "nanDouble = " ++ show (double2word64 nanDouble)
putStrLn $ "nanDouble = " ++ show (double2word64 $ nanDouble + 1)
```
If we compile with GHC and run, we correctly output:
```
nanFloat = 4294967295
nanFloat = 4294967295
nanDouble = 18446744073709551615
nanDouble = 18446744073709551615
```
But if we instead load in ghci, we get the following output:
```
nanFloat = 4294967295
nanFloat = 140247862083583
nanDouble = 18446744073709551615
nanDouble = 18446744073709551615
```
For some reason, ghci is displaying (nanFloat+1) as having significantly more digits than can possibly stored in a Word32 value.
Test system: Intel Core 2 Duo running Debian with GHC 7.8.2
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | hvr |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ghci sometimes displays Word32 as Word64","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["hvr"],"type":"Bug","description":"Given this code:\r\n\r\n{{{\r\nmodule Main\r\n where\r\n\r\nimport Data.Word\r\nimport Unsafe.Coerce\r\nimport System.IO\r\n\r\nnanFloat :: Float\r\nnanFloat = unsafeCoerce (maxBound :: Word32)\r\n\r\nfloat2word32 :: Float -> Word32\r\nfloat2word32 = unsafeCoerce\r\n\r\nnanDouble :: Double\r\nnanDouble = unsafeCoerce (maxBound :: Word64)\r\n\r\ndouble2word64 :: Double -> Word64\r\ndouble2word64 = unsafeCoerce\r\n\r\nmain = do\r\n putStrLn $ \"nanFloat = \" ++ show (float2word32 nanFloat)\r\n putStrLn $ \"nanFloat = \" ++ show (float2word32 $ nanFloat + 1)\r\n putStrLn $ \"nanDouble = \" ++ show (double2word64 nanDouble)\r\n putStrLn $ \"nanDouble = \" ++ show (double2word64 $ nanDouble + 1)\r\n}}}\r\n\r\nIf we compile with GHC and run, we correctly output:\r\n\r\n{{{\r\nnanFloat = 4294967295\r\nnanFloat = 4294967295\r\nnanDouble = 18446744073709551615\r\nnanDouble = 18446744073709551615\r\n}}}\r\n\r\nBut if we instead load in ghci, we get the following output:\r\n\r\n{{{\r\nnanFloat = 4294967295\r\nnanFloat = 140247862083583\r\nnanDouble = 18446744073709551615\r\nnanDouble = 18446744073709551615\r\n}}}\r\n\r\nFor some reason, ghci is displaying (nanFloat+1) as having significantly more digits than can possibly stored in a Word32 value.\r\n\r\nTest system: Intel Core 2 Duo running Debian with GHC 7.8.2","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/9039Annotation reification from TH is not looking into HPT2019-07-07T18:42:11ZerrgeAnnotation reification from TH is not looking into HPTThe annotation reification code only looks into EPS and TCG while trying to find annotations. Unfortunately it forgets HPT, where the annotations for the currently compiling (via --make) package are.
The attached patch fixes this issue....The annotation reification code only looks into EPS and TCG while trying to find annotations. Unfortunately it forgets HPT, where the annotations for the currently compiling (via --make) package are.
The attached patch fixes this issue. Also, I added some test cases that I should have done a long time ago.
Sorry for the oversight :(
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 7.8.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Template Haskell |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Annotation reification from TH is not looking into HPT","status":"New","operating_system":"","component":"Template Haskell","related":[],"milestone":"7.8.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The annotation reification code only looks into EPS and TCG while trying to find annotations. Unfortunately it forgets HPT, where the annotations for the currently compiling (via --make) package are.\r\n\r\nThe attached patch fixes this issue. Also, I added some test cases that I should have done a long time ago.\r\n\r\nSorry for the oversight :(","type_of_failure":"OtherFailure","blocking":[]} -->7.8.3https://gitlab.haskell.org/ghc/ghc/-/issues/9044createDirectoryIfMissing does not fail on unwritable parent dir2019-07-07T18:42:10ZduncancreateDirectoryIfMissing does not fail on unwritable parent dirOn OSX, using `createDirectoryIfMissing` to create a new directory inside a directory for which we do not have write permissions does not throw any exception. Of course it should throw an exception, as it does under Linux.
```
$ mkdir u...On OSX, using `createDirectoryIfMissing` to create a new directory inside a directory for which we do not have write permissions does not throw any exception. Of course it should throw an exception, as it does under Linux.
```
$ mkdir unwritable
$ chmod ugo-w unwritable
$ ghci
> System.Directory.createDirectoryIfMissing True "unwritable/tst"
>
```
On OSX (10.9.2) this does not fail. Under Linux (albeit with 7.6.3) this does throw an exception as expected:
```
*** Exception: unwritable/tst: createDirectory: permission denied (Permission denied)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------- |
| Version | 7.8.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/directory |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"createDirectoryIfMissing does not fail on unwritable parent dir","status":"New","operating_system":"","component":"libraries/directory","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"On OSX, using `createDirectoryIfMissing` to create a new directory inside a directory for which we do not have write permissions does not throw any exception. Of course it should throw an exception, as it does under Linux.\r\n\r\n{{{\r\n$ mkdir unwritable\r\n$ chmod ugo-w unwritable\r\n$ ghci\r\n> System.Directory.createDirectoryIfMissing True \"unwritable/tst\"\r\n>\r\n}}}\r\n\r\nOn OSX (10.9.2) this does not fail. Under Linux (albeit with 7.6.3) this does throw an exception as expected:\r\n{{{\r\n*** Exception: unwritable/tst: createDirectory: permission denied (Permission denied)\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->Edward KmettEdward Kmetthttps://gitlab.haskell.org/ghc/ghc/-/issues/9068Don't uninstall signal handlers if none were installed2019-07-07T18:42:04ZtomgrDon't uninstall signal handlers if none were installedGHC 7.8.2 calls resetSignalHandlers even when --install-signal-handlers=no is specified. On windows this results in the call to SetConsoleCtrlHandler failing.
The attached patch only calls resetSignalHandlers when there are signal handl...GHC 7.8.2 calls resetSignalHandlers even when --install-signal-handlers=no is specified. On windows this results in the call to SetConsoleCtrlHandler failing.
The attached patch only calls resetSignalHandlers when there are signal handlers to remove (it mirrors the logic used when installing the handlers).
<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":"Don't uninstall signal handlers if none were installed","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":"GHC 7.8.2 calls resetSignalHandlers even when --install-signal-handlers=no is specified. On windows this results in the call to SetConsoleCtrlHandler failing.\r\n\r\nThe attached patch only calls resetSignalHandlers when there are signal handlers to remove (it mirrors the logic used when installing the handlers).\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.8.3Simon MarlowSimon Marlowhttps://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/9125int-to-float conversion broken on ARM2019-07-07T18:41:47ZAnsibleint-to-float conversion broken on ARMI compiled ghc on the raspberry pi. See this bug for more about that build of ghc: [8896](https://ghc.haskell.org/trac/ghc/ticket/8896).
A simple test program:
```
main = do
mapM_ (print . (fromInteger :: Integer -> Float)) [0..100]
...I compiled ghc on the raspberry pi. See this bug for more about that build of ghc: [8896](https://ghc.haskell.org/trac/ghc/ticket/8896).
A simple test program:
```
main = do
mapM_ (print . (fromInteger :: Integer -> Float)) [0..100]
```
And the result:
```
0.0
127.0
256.0
257.0
516.0
517.0
518.0
519.0
1040.0
1041.0
1042.0
1043.0
1044.0
1045.0
1046.0
1047.0
2096.0
2097.0
2098.0
2099.0
2100.0
2101.0
2102.0
2103.0
2104.0
2105.0
2106.0
2107.0
2108.0
2109.0
2110.0
2111.0
4224.0
4225.0
4226.0
4227.0
4228.0
4229.0
4230.0
4231.0
4232.0
4233.0
4234.0
4235.0
4236.0
4237.0
4238.0
4239.0
4240.0
4241.0
4242.0
4243.0
4244.0
4245.0
4246.0
4247.0
4248.0
4249.0
4250.0
4251.0
4252.0
4253.0
4254.0
4255.0
8512.0
8513.0
8514.0
8515.0
8516.0
8517.0
8518.0
8519.0
8520.0
8521.0
8522.0
8523.0
8524.0
8525.0
8526.0
8527.0
8528.0
8529.0
8530.0
8531.0
8532.0
8533.0
8534.0
8535.0
8536.0
8537.0
8538.0
8539.0
8540.0
8541.0
8542.0
8543.0
8544.0
8545.0
8546.0
8547.0
8548.0
8538.0
```
This code, however, works normally:
```
main = do
mapM_ (print . (fromInteger :: Integer -> Double)) [0..100]
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Linux |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"int-to-float conversion broken on ARM - 7.8.1-rc2","status":"New","operating_system":"Linux","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I compiled ghc on the raspberry pi. See this bug for more about that build of ghc: [https://ghc.haskell.org/trac/ghc/ticket/8896 8896].\r\n\r\nA simple test program:\r\n\r\n\r\n{{{\r\nmain = do\r\n mapM_ (print . (fromInteger :: Integer -> Float)) [0..100]\r\n\r\n}}}\r\n\r\nAnd the result:\r\n\r\n\r\n{{{\r\n0.0\r\n127.0\r\n256.0\r\n257.0\r\n516.0\r\n517.0\r\n518.0\r\n519.0\r\n1040.0\r\n1041.0\r\n1042.0\r\n1043.0\r\n1044.0\r\n1045.0\r\n1046.0\r\n1047.0\r\n2096.0\r\n2097.0\r\n2098.0\r\n2099.0\r\n2100.0\r\n2101.0\r\n2102.0\r\n2103.0\r\n2104.0\r\n2105.0\r\n2106.0\r\n2107.0\r\n2108.0\r\n2109.0\r\n2110.0\r\n2111.0\r\n4224.0\r\n4225.0\r\n4226.0\r\n4227.0\r\n4228.0\r\n4229.0\r\n4230.0\r\n4231.0\r\n4232.0\r\n4233.0\r\n4234.0\r\n4235.0\r\n4236.0\r\n4237.0\r\n4238.0\r\n4239.0\r\n4240.0\r\n4241.0\r\n4242.0\r\n4243.0\r\n4244.0\r\n4245.0\r\n4246.0\r\n4247.0\r\n4248.0\r\n4249.0\r\n4250.0\r\n4251.0\r\n4252.0\r\n4253.0\r\n4254.0\r\n4255.0\r\n8512.0\r\n8513.0\r\n8514.0\r\n8515.0\r\n8516.0\r\n8517.0\r\n8518.0\r\n8519.0\r\n8520.0\r\n8521.0\r\n8522.0\r\n8523.0\r\n8524.0\r\n8525.0\r\n8526.0\r\n8527.0\r\n8528.0\r\n8529.0\r\n8530.0\r\n8531.0\r\n8532.0\r\n8533.0\r\n8534.0\r\n8535.0\r\n8536.0\r\n8537.0\r\n8538.0\r\n8539.0\r\n8540.0\r\n8541.0\r\n8542.0\r\n8543.0\r\n8544.0\r\n8545.0\r\n8546.0\r\n8547.0\r\n8548.0\r\n8538.0\r\n\r\n}}}\r\n\r\nThis code, however, works normally:\r\n\r\n\r\n{{{\r\nmain = do\r\n mapM_ (print . (fromInteger :: Integer -> Double)) [0..100]\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/9145hp2ps produces odd negative sawtooth2019-07-07T18:41:41Zmwottonhp2ps produces odd negative sawtoothi'm profiling a process with about 22gb of usage before the OOMkiller gets it. the heap profile for it is very odd:
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | --------...i'm profiling a process with about 22gb of usage before the OOMkiller gets it. the heap profile for it is very odd:
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.2 |
| 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":"hp2ps produces odd negative sawtooth","status":"New","operating_system":"","component":"Profiling","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"i'm profiling a process with about 22gb of usage before the OOMkiller gets it. the heap profile for it is very odd:\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/9150libraries/time: parseTime barfs on leading space in format string2019-07-07T18:41:40Zmjolibraries/time: parseTime barfs on leading space in format stringThis used to work around 1.4.0, one of my test suites caught it:
```
module Main
where
import Data.Time.Clock
import Data.Time.Format
import System.Locale
main :: IO ()
main = do
putStrLn "Trailing space is handled:"
print $ (pars...This used to work around 1.4.0, one of my test suites caught it:
```
module Main
where
import Data.Time.Clock
import Data.Time.Format
import System.Locale
main :: IO ()
main = do
putStrLn "Trailing space is handled:"
print $ (parseTime defaultTimeLocale "%M " "15 " :: Maybe UTCTime)
putStrLn "\nBut leading space isn't:"
print $ (parseTime defaultTimeLocale " %M" " 15" :: Maybe UTCTime)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 7.8.2 |
| 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":"libraries/time: parseTime barfs on leading space in format string","status":"New","operating_system":"","component":"libraries (other)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This used to work around 1.4.0, one of my test suites caught it:\r\n\r\n{{{\r\nmodule Main\r\nwhere\r\n\r\nimport Data.Time.Clock\r\nimport Data.Time.Format\r\nimport System.Locale\r\n\r\nmain :: IO ()\r\nmain = do\r\n putStrLn \"Trailing space is handled:\"\r\n print $ (parseTime defaultTimeLocale \"%M \" \"15 \" :: Maybe UTCTime)\r\n\r\n putStrLn \"\\nBut leading space isn't:\"\r\n print $ (parseTime defaultTimeLocale \" %M\" \" 15\" :: Maybe UTCTime)\r\n}}}\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->Ashley YakeleyAshley Yakeleyhttps://gitlab.haskell.org/ghc/ghc/-/issues/9238Negative zero broken2019-07-07T18:41:14Zlennart@augustsson.netNegative zero brokenTry the following program
```
compareDouble :: Double -> Double -> Ordering
compareDouble x y =
case (isNaN x, isNaN y) of
(True, True) -> EQ
(True, False) -> LT
(False, True) -> GT
(False, False) ...Try the following program
```
compareDouble :: Double -> Double -> Ordering
compareDouble x y =
case (isNaN x, isNaN y) of
(True, True) -> EQ
(True, False) -> LT
(False, True) -> GT
(False, False) ->
-- Make -0 less than 0
case (x == 0, y == 0, isNegativeZero x, isNegativeZero y) of
(True, True, True, False) -> LT
(True, True, False, True) -> GT
_ -> x `compare` y
main = do
let l = [-0, 0]
print [ (x, y, compareDouble x y) | x <- l, y <- l ]
```
Compile and run with -O0
```
$ ghc -O0 -fforce-recomp D.hs
[1 of 1] Compiling Main ( D.hs, D.o )
Linking D.exe ...
$ ./D
[(-0.0,-0.0,EQ),(-0.0,0.0,LT),(0.0,-0.0,GT),(0.0,0.0,EQ)]
```
This is the correct output.
Compile and run with -O1
```
$ ghc -O1 -fforce-recomp D.hs
[1 of 1] Compiling Main ( D.hs, D.o )
Linking D.exe ...
$ ./D
[(-0.0,-0.0,LT),(-0.0,0.0,LT),(0.0,-0.0,EQ),(0.0,0.0,EQ)]
```
This is wrong.
Put a NOINLINE pragma on compareDouble:
```
$ ghc -O1 -fforce-recomp D.hs
[1 of 1] Compiling Main ( D.hs, D.o )
Linking D.exe ...
$ ./D
[(-0.0,-0.0,EQ),(-0.0,0.0,EQ),(0.0,-0.0,EQ),(0.0,0.0,EQ)]
```
This is wrong in a different way.7.10.3https://gitlab.haskell.org/ghc/ghc/-/issues/9239Program loops in syscall retries cancelled by rt_sigreturn signal2019-07-07T18:41:14ZKonstantine Rybnikovk-bx@k-bx.comProgram loops in syscall retries cancelled by rt_sigreturn signalSorry if this bug is not related to ghc, but it seems to me that it might be.
Originally I reported it against hedis package, you can find description in it's bug tracker https://github.com/informatikr/hedis/issues/15
Short recap: one ...Sorry if this bug is not related to ghc, but it seems to me that it might be.
Originally I reported it against hedis package, you can find description in it's bug tracker https://github.com/informatikr/hedis/issues/15
Short recap: one specific operation against redis database (zrangebyscoreLimit against big ZSET), program behaves differently. For me, most of the time it would hang, sometimes it succeeds, sometimes outputs "ConnectionLost" twice and dies. My environments are: Ubuntu 12.04/14.04, redis versions tested are 2.2 through 2.8 (latest in each even branch).
Under GHC 7.6 and profiling enabled, strace would end up showing an infinite loop of these operations:
```
--- SIGVTALRM {si_signo=SIGVTALRM, si_code=SI_TIMER, si_pid=0, si_uid=0, si_value=0} ---
rt_sigreturn() = -1 EINTR (Interrupted system call)
select(4, [3], [], NULL, NULL) = ? ERESTARTNOHAND (To be restarted if no handler)
```
Under 7.8.2 profiling enabled, it would also loop, but in few seconds it would hang, produring these last lines of output (plus result of Ctrl+C):
```
select(4, [3], [], NULL, NULL) = ? ERESTARTNOHAND (To be restarted if no handler)
--- SIGVTALRM {si_signo=SIGVTALRM, si_code=SI_TIMER, si_pid=0, si_uid=0, si_value=0} ---
timer_settime(0, 0, {it_interval={0, 0}, it_value={0, 0}}, NULL) = 0
rt_sigreturn() = -1 EINTR (Interrupted system call)
select(4, [3], [], NULL, NULL^CProcess 16483 detached
<detached ...>
```
With profiling disabled on 7.8.2 it would sometimes hang same way as with profiling, but sometimes it would finish with outputting "ConnectionLost" errors (you can find links to full strace output in github hedis issue page linked above).
Sorry again if it's not related to GHC, meanwhile I'll try to investigate further.
Thank you.
<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 | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Program loops in syscall retries cancelled by rt_sigreturn signal","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Sorry if this bug is not related to ghc, but it seems to me that it might be.\r\n\r\nOriginally I reported it against hedis package, you can find description in it's bug tracker https://github.com/informatikr/hedis/issues/15\r\n\r\nShort recap: one specific operation against redis database (zrangebyscoreLimit against big ZSET), program behaves differently. For me, most of the time it would hang, sometimes it succeeds, sometimes outputs \"ConnectionLost\" twice and dies. My environments are: Ubuntu 12.04/14.04, redis versions tested are 2.2 through 2.8 (latest in each even branch).\r\n\r\nUnder GHC 7.6 and profiling enabled, strace would end up showing an infinite loop of these operations:\r\n\r\n{{{\r\n--- SIGVTALRM {si_signo=SIGVTALRM, si_code=SI_TIMER, si_pid=0, si_uid=0, si_value=0} ---\r\nrt_sigreturn() = -1 EINTR (Interrupted system call)\r\nselect(4, [3], [], NULL, NULL) = ? ERESTARTNOHAND (To be restarted if no handler)\r\n}}}\r\n\r\nUnder 7.8.2 profiling enabled, it would also loop, but in few seconds it would hang, produring these last lines of output (plus result of Ctrl+C):\r\n\r\n{{{\r\nselect(4, [3], [], NULL, NULL) = ? ERESTARTNOHAND (To be restarted if no handler)\r\n--- SIGVTALRM {si_signo=SIGVTALRM, si_code=SI_TIMER, si_pid=0, si_uid=0, si_value=0} ---\r\ntimer_settime(0, 0, {it_interval={0, 0}, it_value={0, 0}}, NULL) = 0\r\nrt_sigreturn() = -1 EINTR (Interrupted system call)\r\nselect(4, [3], [], NULL, NULL^CProcess 16483 detached\r\n <detached ...>\r\n}}}\r\n\r\nWith profiling disabled on 7.8.2 it would sometimes hang same way as with profiling, but sometimes it would finish with outputting \"ConnectionLost\" errors (you can find links to full strace output in github hedis issue page linked above).\r\n\r\nSorry again if it's not related to GHC, meanwhile I'll try to investigate further.\r\n\r\nThank you.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/9250let makes function too much specific2019-07-07T18:41:11ZKommuSoftlet makes function too much specificSay you define a `myadd` function:
> let myadd x y = x + y
Then the type is `Num a => a -> a -> a`. If on the other hand, you define the method using currying:
> let myadd2 \\x -\> \\y -\> x + y
The type is more specific: `Integer ...Say you define a `myadd` function:
> let myadd x y = x + y
Then the type is `Num a => a -> a -> a`. If on the other hand, you define the method using currying:
> let myadd2 \\x -\> \\y -\> x + y
The type is more specific: `Integer -> Integer -> Integer`. Strangely enough `:t \x -> \y -> x + y` returns the more general form.
URL: http://stackoverflow.com/questions/24481024/why-does-currying-anonymous-functions-change-haskells-type-inference-from-num-thttps://gitlab.haskell.org/ghc/ghc/-/issues/9325mod73 output file needs to be reordered2019-07-07T18:40:53Zjrp2014mod73 output file needs to be reorderedThe correct output from the mod73 test needs to be reordered in HEAD:
```
=====> mod73(normal) 1610 of 4044 [0, 0, 0]
cd ./module && '/Users/jrp/Projects/ghc/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-outp...The correct output from the mod73 test needs to be reordered in HEAD:
```
=====> mod73(normal) 1610 of 4044 [0, 0, 0]
cd ./module && '/Users/jrp/Projects/ghc/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c mod73.hs >mod73.comp.stderr 2>&1
Actual stderr output differs from expected:
--- ./module/mod73.stderr 2014-07-16 21:21:57.000000000 +0100
+++ ./module/mod73.comp.stderr 2014-07-17 20:15:54.000000000 +0100
@@ -2,6 +2,6 @@
mod73.hs:3:7:
Not in scope: ‘Prelude.g’
Perhaps you meant one of these:
- data constructor ‘Prelude.LT’ (imported from Prelude),
+ data constructor ‘Prelude.GT’ (imported from Prelude),
data constructor ‘Prelude.EQ’ (imported from Prelude),
- data constructor ‘Prelude.GT’ (imported from Prelude)
+ data constructor ‘Prelude.LT’ (imported from Prelude)
*** unexpected failure for mod73(normal)
Unexpected results from:
TEST="mod73"
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Test Suite |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"mod73 output file needs to be reordered","status":"New","operating_system":"","component":"Test Suite","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.3","keywords":["mod73"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The correct output from the mod73 test needs to be reordered in HEAD:\r\n\r\n{{{\r\n\r\n=====> mod73(normal) 1610 of 4044 [0, 0, 0] \r\ncd ./module && '/Users/jrp/Projects/ghc/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c mod73.hs >mod73.comp.stderr 2>&1\r\nActual stderr output differs from expected:\r\n--- ./module/mod73.stderr\t2014-07-16 21:21:57.000000000 +0100\r\n+++ ./module/mod73.comp.stderr\t2014-07-17 20:15:54.000000000 +0100\r\n@@ -2,6 +2,6 @@\r\n mod73.hs:3:7:\r\n Not in scope: ‘Prelude.g’\r\n Perhaps you meant one of these:\r\n- data constructor ‘Prelude.LT’ (imported from Prelude),\r\n+ data constructor ‘Prelude.GT’ (imported from Prelude),\r\n data constructor ‘Prelude.EQ’ (imported from Prelude),\r\n- data constructor ‘Prelude.GT’ (imported from Prelude)\r\n+ data constructor ‘Prelude.LT’ (imported from Prelude)\r\n*** unexpected failure for mod73(normal)\r\n\r\nUnexpected results from:\r\nTEST=\"mod73\"\r\n\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://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/9380ghc generates seemingly incorrect code2019-07-07T18:40:38ZAlexander Vershilovghc generates seemingly incorrect codeGHC generates a wrong code for the case-match on GADT with polymorphic type,
here is a minimal example attached, expected results are 'A' in all test cases
(this is case for ghc-HEAD), however in:
test0 - result is missing as matches ar...GHC generates a wrong code for the case-match on GADT with polymorphic type,
here is a minimal example attached, expected results are 'A' in all test cases
(this is case for ghc-HEAD), however in:
test0 - result is missing as matches are removed from code (according to core)
test1 - returns A as expected
test2 - output 'o_O' without any checks
<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":"ghc generates seemingly incorrect code","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":"GHC generates a wrong code for the case-match on GADT with polymorphic type,\r\n\r\nhere is a minimal example attached, expected results are 'A' in all test cases\r\n(this is case for ghc-HEAD), however in:\r\ntest0 - result is missing as matches are removed from code (according to core)\r\ntest1 - returns A as expected\r\ntest2 - output 'o_O' without any checks","type_of_failure":"OtherFailure","blocking":[]} -->