GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:42:00Zhttps://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/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/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/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/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/8981ghc-pkg complains about missing haddock interface files2022-07-07T15:20:45Zthoughtpoliceghc-pkg complains about missing haddock interface filesAs Conal reported on the mailing list\[1\], `ghc-pkg check` on Mavericks allegedly returns:
```
bash-3.2$ ghc-pkg check
Warning: haddock-interfaces: /Users/conal/.cabal/share/doc/x86_64-osx-ghc-7.8.1/uniplate-1.6.12/html/uniplate.ha...As Conal reported on the mailing list\[1\], `ghc-pkg check` on Mavericks allegedly returns:
```
bash-3.2$ ghc-pkg check
Warning: haddock-interfaces: /Users/conal/.cabal/share/doc/x86_64-osx-ghc-7.8.1/uniplate-1.6.12/html/uniplate.haddock doesn't exist or isn't a file
Warning: haddock-interfaces: /Users/conal/.cabal/share/doc/x86_64-osx-ghc-7.8.1/polyparse-1.9/html/polyparse.haddock doesn't exist or isn't a file
Warning: haddock-interfaces: /Users/conal/.cabal/share/doc/x86_64-osx-ghc-7.8.1/ghc-syb-utils-0.2.1.2/html/ghc-syb-utils.haddock doesn't exist or isn't a file
Warning: haddock-interfaces: /Users/conal/.cabal/share/doc/x86_64-osx-ghc-7.8.1/constraints-0.3.5/html/constraints.haddock doesn't exist or isn't a file
Warning: haddock-html: /Users/conal/.cabal/share/doc/x86_64-osx-ghc-7.8.1/constraints-0.3.5/html doesn't exist or isn't a directory
Warning: haddock-interfaces: /Users/conal/.cabal/share/doc/x86_64-osx-ghc-7.8.1/newtype-0.2/html/newtype.haddock doesn't exist or isn't a file
Warning: haddock-html: /Users/conal/.cabal/share/doc/x86_64-osx-ghc-7.8.1/newtype-0.2/html doesn't exist or isn't a directory
```
It's not fatal, but makes the output much more annoying. I figured this would have been caught by validate or somesuch, but apparently not.
Marking for 7.8.2. I'm looking into this soon.
\[1\]http://www.haskell.org/pipermail/glasgow-haskell-users/2014-April/024846.html
<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 | Fuuzetsu |
| Operating system | MacOS X |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ghc-pkg complains about missing haddock interface files","status":"New","operating_system":"MacOS X","component":"Compiler","related":[],"milestone":"7.8.2","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.1","keywords":["ghc-pkg"],"differentials":[],"test_case":"","architecture":"","cc":["Fuuzetsu"],"type":"Bug","description":"As Conal reported on the mailing list[1], `ghc-pkg check` on Mavericks allegedly returns:\r\n\r\n{{{\r\n\r\nbash-3.2$ ghc-pkg check\r\n Warning: haddock-interfaces: /Users/conal/.cabal/share/doc/x86_64-osx-ghc-7.8.1/uniplate-1.6.12/html/uniplate.haddock doesn't exist or isn't a file\r\n Warning: haddock-interfaces: /Users/conal/.cabal/share/doc/x86_64-osx-ghc-7.8.1/polyparse-1.9/html/polyparse.haddock doesn't exist or isn't a file\r\n Warning: haddock-interfaces: /Users/conal/.cabal/share/doc/x86_64-osx-ghc-7.8.1/ghc-syb-utils-0.2.1.2/html/ghc-syb-utils.haddock doesn't exist or isn't a file\r\n Warning: haddock-interfaces: /Users/conal/.cabal/share/doc/x86_64-osx-ghc-7.8.1/constraints-0.3.5/html/constraints.haddock doesn't exist or isn't a file\r\n Warning: haddock-html: /Users/conal/.cabal/share/doc/x86_64-osx-ghc-7.8.1/constraints-0.3.5/html doesn't exist or isn't a directory\r\n Warning: haddock-interfaces: /Users/conal/.cabal/share/doc/x86_64-osx-ghc-7.8.1/newtype-0.2/html/newtype.haddock doesn't exist or isn't a file\r\n Warning: haddock-html: /Users/conal/.cabal/share/doc/x86_64-osx-ghc-7.8.1/newtype-0.2/html doesn't exist or isn't a directory\r\n\r\n}}}\r\n\r\nIt's not fatal, but makes the output much more annoying. I figured this would have been caught by validate or somesuch, but apparently not.\r\n\r\nMarking for 7.8.2. I'm looking into this soon.\r\n\r\n[1]http://www.haskell.org/pipermail/glasgow-haskell-users/2014-April/024846.html","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://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/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/8862forkProcess does not play well with heap or time profiling2019-07-19T00:55:17ZbennofsforkProcess does not play well with heap or time profilingThis is similar to #4512. When doing heap or time profiling, the forked process and the parent process both write to the same `.hp` or `.prof` file. I think this also applies to program coverage using hpc (didn't test this).
I was able ...This is similar to #4512. When doing heap or time profiling, the forked process and the parent process both write to the same `.hp` or `.prof` file. I think this also applies to program coverage using hpc (didn't test this).
I was able to reproduce the bug with the attached source code, but some other people were not. Just run `space-profiling +RTS -h` and try to convert the generated heap profile using `hp2ps`, I get the following error message:
```
hp2ps: space-profiling.hp, line 186: integer must follow identifier
```
I attached the generated hp file.
<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":"forkProcess does not play well with heap or time profiling","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":"This is similar to #4512. When doing heap or time profiling, the forked process and the parent process both write to the same `.hp` or `.prof` file. I think this also applies to program coverage using hpc (didn't test this). \r\n\r\nI was able to reproduce the bug with the attached source code, but some other people were not. Just run `space-profiling +RTS -h` and try to convert the generated heap profile using `hp2ps`, I get the following error message:\r\n\r\n{{{ \r\nhp2ps: space-profiling.hp, line 186: integer must follow identifier\r\n}}}\r\n\r\nI attached the generated hp file. ","type_of_failure":"OtherFailure","blocking":[]} -->Simon MarlowSimon Marlowhttps://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/8847Int64 ^ Int64 broken by optimization on SPARC2022-02-26T17:45:12ZkgardasInt64 ^ Int64 broken by optimization on SPARCThe T7507 test is broken on SPARC NCG, I've more simplified it to
```
module Main where
import Data.Int
main = print ( ( 2 :: Int64 ) ^ ( 6 :: Int64 ) )
```
it does not matter if it's run with two Int64 or just with one:
```
main = ...The T7507 test is broken on SPARC NCG, I've more simplified it to
```
module Main where
import Data.Int
main = print ( ( 2 :: Int64 ) ^ ( 6 :: Int64 ) )
```
it does not matter if it's run with two Int64 or just with one:
```
main = print ( 2 ^ 6 :: Int64 )
```
the result with -O is still 0. The result without -O is correct.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (NCG) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | simonmar |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Int64 ^ Int64 broken by optimization on SPARC","status":"New","operating_system":"","component":"Compiler (NCG)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["simonmar"],"type":"Bug","description":"The T7507 test is broken on SPARC NCG, I've more simplified it to\r\n{{{\r\nmodule Main where\r\n\r\nimport Data.Int\r\n\r\nmain = print ( ( 2 :: Int64 ) ^ ( 6 :: Int64 ) )\r\n}}}\r\nit does not matter if it's run with two Int64 or just with one:\r\n{{{\r\nmain = print ( 2 ^ 6 :: Int64 ) \r\n}}}\r\nthe result with -O is still 0. The result without -O is correct.","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/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/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/8780abs for IEEE floating point is slightly wrong.2019-07-07T18:43:30Zlennart@augustsson.netabs for IEEE floating point is slightly wrong.Evaluating abs(-0) gives the answer -0. This unexpected since it breaks invariants like 1/(abs x) \>= 0. So abs(-0) should be 0. This is also the norm for other languages.
Together with this change, signum should also be changed so sign...Evaluating abs(-0) gives the answer -0. This unexpected since it breaks invariants like 1/(abs x) \>= 0. So abs(-0) should be 0. This is also the norm for other languages.
Together with this change, signum should also be changed so signum(-0) is -0. This maintains the invariant abs x \* signum x == x.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.6.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"abs for IEEE floating point is slightly wrong.","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":"Evaluating abs(-0) gives the answer -0. This unexpected since it breaks invariants like 1/(abs x) >= 0. So abs(-0) should be 0. This is also the norm for other languages.\r\n\r\nTogether with this change, signum should also be changed so signum(-0) is -0. This maintains the invariant abs x * signum x == x.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/8741`System.Directory.getPermissions` fails on read-only filesystem2019-07-07T18:43:42ZHerbert Valerio Riedelhvr@gnu.org`System.Directory.getPermissions` fails on read-only filesystemAlain O'Dea reports in an [email](http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/21078) that:
```
Prelude> System.Directory.getPermissions "/usr/bin/ld"
*** Exception: /usr/bin/ld: fileAccess: permission denied (Read-only ...Alain O'Dea reports in an [email](http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/21078) that:
```
Prelude> System.Directory.getPermissions "/usr/bin/ld"
*** Exception: /usr/bin/ld: fileAccess: permission denied (Read-only file system)
```
> That seems wrong.
>
> An `access(*, W_OK)` syscall by design should return `EROFS` on a read-only file system by specification.
>
> This breaks Cabal on SmartOS since `/usr` is read-only by design and Cabal calls `getPermissions "/usr/bin/ld"`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------- |
| Version | 7.6.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | libraries/directory |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"`System.Directory.getPermissions` fails on read-only filesystem","status":"New","operating_system":"","component":"libraries/directory","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Alain O'Dea reports in an [http://permalink.gmane.org/gmane.comp.lang.haskell.libraries/21078 email] that:\r\n\r\n{{{\r\nPrelude> System.Directory.getPermissions \"/usr/bin/ld\"\r\n*** Exception: /usr/bin/ld: fileAccess: permission denied (Read-only file system)\r\n}}}\r\n> That seems wrong.\r\n>\r\n> An `access(*, W_OK)` syscall by design should return `EROFS` on a read-only file system by specification.\r\n>\r\n> This breaks Cabal on SmartOS since `/usr` is read-only by design and Cabal calls `getPermissions \"/usr/bin/ld\"`.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1AlainODeaAlainODeahttps://gitlab.haskell.org/ghc/ghc/-/issues/8738msys2 fails cabal01 test2019-07-07T18:43:43ZEdward Z. Yangmsys2 fails cabal01 testmsys2 with 64-bit GHC has an odd failure here:
```
=====> cabal01(normal) 81 of 3859 [0, 0, 0]
cd ./cabal/cabal01 && $MAKE -s --no-print-directory cabal01 VANILLA=--enable-library-vanilla PROF=--disable-library-profiling DYN=--disable-s...msys2 with 64-bit GHC has an odd failure here:
```
=====> cabal01(normal) 81 of 3859 [0, 0, 0]
cd ./cabal/cabal01 && $MAKE -s --no-print-directory cabal01 VANILLA=--enable-library-vanilla PROF=--disable-library-profiling DYN=--disable-shared </dev/null >cabal01.run.stdout 2>cabal01.run.stderr
Actual stdout output differs from expected:
--- ./cabal/cabal01/cabal01.stdout-mingw32 2014-02-02 04:48:11.233000000 +0000
+++ ./cabal/cabal01/cabal01.run.stdout 2014-02-05 03:09:28.998400000 +0000
@@ -1,9 +1,9 @@
install1:
bin
-test-1.0
+x86_64-windows-ghc-7.9.20140205
install2:
bin
-test-1.0
+x86_64-windows-ghc-7.9.20140205
dist:
build
package.conf.inplace
```
This is because setup is selecting this directory as the location for the installation:
```
/inplace/bin/ghc-pkg.exe' --package-db=local.db'C:/msys64/home/Administrator/ghc
Configuring test-1.0...
Warning: No 'build-type' specified. If you do not need a custom Setup.hs or
./configure script then use 'build-type: Simple'.
Dependency base >=1.0: using base-4.7.0.0
"C:/msys64/home/Administrator/ghc/inplace/bin/ghc-stage2.exe" "--info"
Using Cabal-1.18.1.3 compiled by ghc-7.9
Using compiler: ghc-7.9.20140205
Using install prefix:
C:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install
Binaries installed in:
C:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\bin
Libraries installed in:
C:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\x86_64-windows-ghc-7.9.20140205\test-1.0
Private binaries installed in:
C:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\test-1.0
Data files installed in:
C:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\x86_64-windows-ghc-7.9.20140205\test-1.0
Documentation installed in:
C:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\doc\x86_64-windows-ghc-7.9.20140205\test-1.0
Configuration files installed in:
C:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\etc
Administrator@EZYANG-W2K8 ~/ghc/testsuite/tests/cabal/cabal01
$ ./setup.exe copy -v
directory dist\doc\html\test does exist: False
Installing library in
C:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\x86_64-windows-ghc-7.9.20140205\test-1.0
Installing executable(s) in
C:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\bin
Warning: The directory
C:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\bin is
not in the system search path.
creating
C:\msys64\home\Administrator\ghc\testsuite\tests\cabal\cabal01\install\x86_64-windows-ghc-7.9.20140205\test-1.0
creating
C:\msys64\home\Administrator\ghc\testsuite\tests\cabal\cabal01\install\x86_64-windows-ghc-7.9.20140205
creating
C:\msys64\home\Administrator\ghc\testsuite\tests\cabal\cabal01\install
creating
C:\msys64\home\Administrator\ghc\testsuite\tests\cabal\cabal01\install\x86_64-windows-ghc-7.9.20140205
creating
C:\msys64\home\Administrator\ghc\testsuite\tests\cabal\cabal01\install\x86_64-windows-ghc-7.9.20140205\test-1.0
creating
C:\msys64\home\Administrator\ghc\testsuite\tests\cabal\cabal01\install\x86_64-windows-ghc-7.9.20140205\test-1.0\B
Installing dist\build\A.hi to
C:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\x86_64-windows-ghc-7.9.20140205\test-1.0\A.hi
Installing dist\build\B\A.hi to
C:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\x86_64-windows-ghc-7.9.20140205\test-1.0\B\A.hi
creating
C:\msys64\home\Administrator\ghc\testsuite\tests\cabal\cabal01\install\x86_64-windows-ghc-7.9.20140205\test-1.0
Installing dist\build\libHStest-1.0.a to
C:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\x86_64-windows-ghc-7.9.20140205\test-1.0\libHStest-1.0.a
creating
C:\msys64\home\Administrator\ghc\testsuite\tests\cabal\cabal01\install\x86_64-windows-ghc-7.9.20140205\test-1.0
Installing dist\build\HStest-1.0.o to
C:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\x86_64-windows-ghc-7.9.20140205\test-1.0\HStest-1.0.o
creating
C:\msys64\home\Administrator\ghc\testsuite\tests\cabal\cabal01\install\bin
Installing executable dist\build\testA\testA.exe to
C:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\bin\testA.exe
C:\msys64\ghc-7.6.3\mingw\bin\strip.exe C:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\bin\testA.exe
creating
C:\msys64\home\Administrator\ghc\testsuite\tests\cabal\cabal01\install\bin
Installing executable dist\build\testB\testB.exe to
C:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\bin\testB.exe
C:\msys64\ghc-7.6.3\mingw\bin\strip.exe C:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\bin\testB.exe
```
Perhaps a cabal developer can stare at the relevant codepath and figure out why this directory name is being selected?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.1-rc1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | Test Suite |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"msys2 fails cabal01 test","status":"New","operating_system":"","component":"Test Suite","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.1-rc1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"msys2 with 64-bit GHC has an odd failure here:\r\n\r\n{{{\r\n=====> cabal01(normal) 81 of 3859 [0, 0, 0]\r\ncd ./cabal/cabal01 && $MAKE -s --no-print-directory cabal01 VANILLA=--enable-library-vanilla PROF=--disable-library-profiling DYN=--disable-shared </dev/null >cabal01.run.stdout 2>cabal01.run.stderr\r\nActual stdout output differs from expected:\r\n--- ./cabal/cabal01/cabal01.stdout-mingw32 2014-02-02 04:48:11.233000000 +0000\r\n+++ ./cabal/cabal01/cabal01.run.stdout 2014-02-05 03:09:28.998400000 +0000\r\n@@ -1,9 +1,9 @@\r\n install1:\r\n bin\r\n-test-1.0\r\n+x86_64-windows-ghc-7.9.20140205\r\n install2:\r\n bin\r\n-test-1.0\r\n+x86_64-windows-ghc-7.9.20140205\r\n dist:\r\n build\r\n package.conf.inplace\r\n\r\n}}}\r\n\r\nThis is because setup is selecting this directory as the location for the installation:\r\n\r\n{{{\r\n/inplace/bin/ghc-pkg.exe' --package-db=local.db'C:/msys64/home/Administrator/ghc\r\nConfiguring test-1.0...\r\nWarning: No 'build-type' specified. If you do not need a custom Setup.hs or\r\n./configure script then use 'build-type: Simple'.\r\nDependency base >=1.0: using base-4.7.0.0\r\n\"C:/msys64/home/Administrator/ghc/inplace/bin/ghc-stage2.exe\" \"--info\"\r\nUsing Cabal-1.18.1.3 compiled by ghc-7.9\r\nUsing compiler: ghc-7.9.20140205\r\nUsing install prefix:\r\nC:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\r\nBinaries installed in:\r\nC:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\\bin\r\nLibraries installed in:\r\nC:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\\x86_64-windows-ghc-7.9.20140205\\test-1.0\r\nPrivate binaries installed in:\r\nC:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\\test-1.0\r\nData files installed in:\r\nC:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\\x86_64-windows-ghc-7.9.20140205\\test-1.0\r\nDocumentation installed in:\r\nC:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\\doc\\x86_64-windows-ghc-7.9.20140205\\test-1.0\r\nConfiguration files installed in:\r\nC:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\\etc\r\n\r\nAdministrator@EZYANG-W2K8 ~/ghc/testsuite/tests/cabal/cabal01\r\n$ ./setup.exe copy -v\r\ndirectory dist\\doc\\html\\test does exist: False\r\nInstalling library in\r\nC:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\\x86_64-windows-ghc-7.9.20140205\\test-1.0\r\nInstalling executable(s) in\r\nC:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\\bin\r\nWarning: The directory\r\nC:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\\bin is\r\nnot in the system search path.\r\ncreating\r\nC:\\msys64\\home\\Administrator\\ghc\\testsuite\\tests\\cabal\\cabal01\\install\\x86_64-windows-ghc-7.9.20140205\\test-1.0\r\ncreating\r\nC:\\msys64\\home\\Administrator\\ghc\\testsuite\\tests\\cabal\\cabal01\\install\\x86_64-windows-ghc-7.9.20140205\r\ncreating\r\nC:\\msys64\\home\\Administrator\\ghc\\testsuite\\tests\\cabal\\cabal01\\install\r\ncreating\r\nC:\\msys64\\home\\Administrator\\ghc\\testsuite\\tests\\cabal\\cabal01\\install\\x86_64-windows-ghc-7.9.20140205\r\ncreating\r\nC:\\msys64\\home\\Administrator\\ghc\\testsuite\\tests\\cabal\\cabal01\\install\\x86_64-windows-ghc-7.9.20140205\\test-1.0\r\ncreating\r\nC:\\msys64\\home\\Administrator\\ghc\\testsuite\\tests\\cabal\\cabal01\\install\\x86_64-windows-ghc-7.9.20140205\\test-1.0\\B\r\nInstalling dist\\build\\A.hi to\r\nC:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\\x86_64-windows-ghc-7.9.20140205\\test-1.0\\A.hi\r\nInstalling dist\\build\\B\\A.hi to\r\nC:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\\x86_64-windows-ghc-7.9.20140205\\test-1.0\\B\\A.hi\r\ncreating\r\nC:\\msys64\\home\\Administrator\\ghc\\testsuite\\tests\\cabal\\cabal01\\install\\x86_64-windows-ghc-7.9.20140205\\test-1.0\r\nInstalling dist\\build\\libHStest-1.0.a to\r\nC:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\\x86_64-windows-ghc-7.9.20140205\\test-1.0\\libHStest-1.0.a\r\ncreating\r\nC:\\msys64\\home\\Administrator\\ghc\\testsuite\\tests\\cabal\\cabal01\\install\\x86_64-windows-ghc-7.9.20140205\\test-1.0\r\nInstalling dist\\build\\HStest-1.0.o to\r\nC:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\\x86_64-windows-ghc-7.9.20140205\\test-1.0\\HStest-1.0.o\r\ncreating\r\nC:\\msys64\\home\\Administrator\\ghc\\testsuite\\tests\\cabal\\cabal01\\install\\bin\r\nInstalling executable dist\\build\\testA\\testA.exe to\r\nC:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\\bin\\testA.exe\r\nC:\\msys64\\ghc-7.6.3\\mingw\\bin\\strip.exe C:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\\bin\\testA.exe\r\ncreating\r\nC:\\msys64\\home\\Administrator\\ghc\\testsuite\\tests\\cabal\\cabal01\\install\\bin\r\nInstalling executable dist\\build\\testB\\testB.exe to\r\nC:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\\bin\\testB.exe\r\nC:\\msys64\\ghc-7.6.3\\mingw\\bin\\strip.exe C:/msys64/home/Administrator/ghc/testsuite/tests/cabal/cabal01/install\\bin\\testB.exe\r\n}}}\r\n\r\nPerhaps a cabal developer can stare at the relevant codepath and figure out why this directory name is being selected?","type_of_failure":"OtherFailure","blocking":[]} -->refoldrefoldhttps://gitlab.haskell.org/ghc/ghc/-/issues/8737T5975a fails when using official Windows Python distribution2019-07-07T18:43:43ZEdward Z. YangT5975a fails when using official Windows Python distributionUsing the official MSYS2 instructions:
```
=====> T5975a(ghci) 988 of 3859 [0, 0, 0]
cd ./ghci/scripts && touch föøbàr1.hs
cd ./ghci/scripts && HC='C:/msys64/home/Administrator/ghc/inplace/bin/ghc-stage2.exe' HC_OPTS='-dcore-lint -dcmm-...Using the official MSYS2 instructions:
```
=====> T5975a(ghci) 988 of 3859 [0, 0, 0]
cd ./ghci/scripts && touch föøbàr1.hs
cd ./ghci/scripts && HC='C:/msys64/home/Administrator/ghc/inplace/bin/ghc-stage2.exe' HC_OPTS='-dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history ' 'C:/msys64/home/Administrator/ghc/inplace/bin/ghc-stage2.exe' --interactive -v0 -ignore-dot-ghci -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history <T5975a.script >T5975a.run.stdout 2>T5975a.run.stderr
Actual stderr output differs from expected:
--- /dev/null 2014-02-05 03:11:58.000000000 +0000
+++ ./ghci/scripts/T5975a.run.stderr 2014-02-05 03:11:58.103200000 +0000
@@ -0,0 +1,2 @@
+
+<no location info>: can't find file: föøbàr1.hs
*** unexpected failure for T5975a(ghci)
```
When we disable the cleanup hook and look at the directory listing, we see that Python has created the following file: "föøbà r1.hs". I think this is some sort of encoding problem, since we see similar behavior when running a simple Python script:
```
#coding=utf-8
open('föøbàr1.hs', 'w').write("")
```
Maybe this bug shows up in MSYS as well, but I haven't checked.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.1-rc1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | Test Suite |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"T5975a fails when using official Windows Python distribution","status":"New","operating_system":"","component":"Test Suite","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.1-rc1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Using the official MSYS2 instructions:\r\n\r\n{{{\r\n=====> T5975a(ghci) 988 of 3859 [0, 0, 0]\r\ncd ./ghci/scripts && touch föøbàr1.hs\r\ncd ./ghci/scripts && HC='C:/msys64/home/Administrator/ghc/inplace/bin/ghc-stage2.exe' HC_OPTS='-dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history ' 'C:/msys64/home/Administrator/ghc/inplace/bin/ghc-stage2.exe' --interactive -v0 -ignore-dot-ghci -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history <T5975a.script >T5975a.run.stdout 2>T5975a.run.stderr\r\nActual stderr output differs from expected:\r\n--- /dev/null 2014-02-05 03:11:58.000000000 +0000\r\n+++ ./ghci/scripts/T5975a.run.stderr 2014-02-05 03:11:58.103200000 +0000\r\n@@ -0,0 +1,2 @@\r\n+\r\n+<no location info>: can't find file: föøbàr1.hs\r\n*** unexpected failure for T5975a(ghci)\r\n}}}\r\n\r\nWhen we disable the cleanup hook and look at the directory listing, we see that Python has created the following file: \"föøbà r1.hs\". I think this is some sort of encoding problem, since we see similar behavior when running a simple Python script:\r\n\r\n{{{\r\n#coding=utf-8\r\nopen('föøbàr1.hs', 'w').write(\"\")\r\n}}}\r\n\r\nMaybe this bug shows up in MSYS as well, but I haven't checked.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/87347.8.1 rc1 ghci won't load compiled files2019-07-07T18:43:44Zgeorge.colpitts7.8.1 rc1 ghci won't load compiled files<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.1-rc1 |
| Type | Bug |
| TypeOfFailure |...<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.1-rc1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | hvr |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"7.8.1 rc1 ghci won't load compiled files","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"7.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.1-rc1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["hvr"],"type":"Bug","description":"","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://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.org