GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:57:04Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/5060iteratee: epollControl: permission denied (Operation not permitted)2019-07-07T18:57:04Zpacakiteratee: epollControl: permission denied (Operation not permitted)If you run this ticket as literate haskell program it works fine when
1. executed via ghci/runhaskell in ghc 6.12.3
1. executed as compiled file in both ghc 6.12.3 and 7.0.2/7.0.3
and it fails with a message " epollControl: permission ...If you run this ticket as literate haskell program it works fine when
1. executed via ghci/runhaskell in ghc 6.12.3
1. executed as compiled file in both ghc 6.12.3 and 7.0.2/7.0.3
and it fails with a message " epollControl: permission denied (Operation not permitted)" when executed via runhaskell in ghc 7.0.2/7.0.3
```
> import Data.Iteratee
> import Data.Iteratee.IO
> import Data.Iteratee.Char
> main = fileDriver printLines "/etc/passwd"
```
some logs are attached7.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/5058getProcessExitCode doesn't retry on EINTR2019-07-07T18:57:05ZsclvgetProcessExitCode doesn't retry on EINTRJust like the ticket says. The source uses throwErrnoIfMinus1, and I can't think why it shouldn't just use throwErrnoIfMinus1Retry. I think that this is an issue with a few other functions that should do the same thing, including waitFor...Just like the ticket says. The source uses throwErrnoIfMinus1, and I can't think why it shouldn't just use throwErrnoIfMinus1Retry. I think that this is an issue with a few other functions that should do the same thing, including waitForProcess and probably terminateProcess as well.
I also wonder if the same issue is in other core libraries, but that's beyond this ticket.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 7.0.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/process |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"getProcessExitCode doesn't retry on EINTR","status":"New","operating_system":"","component":"libraries/process","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Just like the ticket says. The source uses throwErrnoIfMinus1, and I can't think why it shouldn't just use throwErrnoIfMinus1Retry. I think that this is an issue with a few other functions that should do the same thing, including waitForProcess and probably terminateProcess as well.\r\n\r\nI also wonder if the same issue is in other core libraries, but that's beyond this ticket.","type_of_failure":"OtherFailure","blocking":[]} -->7.2.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/5048Wrong SrcSpan on AbsBinds2019-07-07T18:57:11ZJPMoresmauWrong SrcSpan on AbsBindsI have the following code:
```
{-# LANGUAGE RankNTypes #-}
module Folder1.ForAll where
import Data.Char
fun :: t -> [Char] -> [Char]
fun _=reverse . map toUpper
```
And the `TypecheckedSource` gives me something like (using the
`gh...I have the following code:
```
{-# LANGUAGE RankNTypes #-}
module Folder1.ForAll where
import Data.Char
fun :: t -> [Char] -> [Char]
fun _=reverse . map toUpper
```
And the `TypecheckedSource` gives me something like (using the
`ghc-syb-utils` package to dump it:)
```
{Bag(Located (HsBind Var)):
[
(L {src\Folder1\ForAll.hs:8:1-29}
(AbsBinds
[{Var: t}]
[]
[
((,,,)
[{Var: t}] {Var: Folder1.ForAll.fun} {Var: fun}
(SpecPrags
[]))]
({abstract:TcEvBinds}) {Bag(Located (HsBind Var)):
[
(L {src\Folder1\ForAll.hs:9:1-27}
(FunBind
(L {src\Folder1\ForAll.hs:9:1-3} {Var: fun})
(False)
(MatchGroup
```
The issue here is that the `AbsBinds` has a `SrcSpan` that only covers the type signature, and not the rest of the code, hence (I think) we never go down the contents, and Scion cannot resolve anything when a user asks it to.
If the type signature is not present, the problem doesn't occur: the
`AbsBinds` location covers all the source code.
If the type signature is present but without any type variable, there is no `AbsBinds` and no problem (the `FunBind` covers all the code).7.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/4970time002 and time004 (ghci) test failures on OS X 64 bit2019-07-07T18:57:32Zgwright@antiope.comtime002 and time004 (ghci) test failures on OS X 64 bitThe `time002` and `time004` tests fail for `ghci` on OS X 64 bit. The failure doesn't happen every time, but when it does, the failure is the same:
```
plumbbob-franklin> inplace/bin/ghc-stage2 --interactive time002.hs
GHCi, version 7.0...The `time002` and `time004` tests fail for `ghci` on OS X 64 bit. The failure doesn't happen every time, but when it does, the failure is the same:
```
plumbbob-franklin> inplace/bin/ghc-stage2 --interactive time002.hs
GHCi, version 7.0.1.20101221: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package ffi-1.0 ... linking ... done.
[1 of 1] Compiling Main ( time002.hs, interpreted )
Ok, modules loaded: Main.
*Main> main
Loading package array-0.3.0.2 ... linking ... done.
Loading package filepath-1.2.0.0 ... linking ... done.
Loading package old-locale-1.0.0.2 ... linking ... done.
Loading package old-time-1.0.0.6 ... linking ... done.
Loading package unix-2.4.1.0 ... linking ... done.
Loading package directory-1.1.0.0 ... linking ... done.
Loading package process-1.0.1.5 ... linking ... done.
Loading package time-1.2.0.3 ... linking ... done.
Loading package random-1.0.0.3 ... linking ... done.
Loading package haskell98-1.1.0.1 ... linking ... done.
Ok.
*Main> main
Ok.
*Main> main
Ok.
*Main> main
Ok.
*Main> main
Ok.
*Main> main
Ok.
*Main> main
Ok.
*Main> main
Ok.
*Main> main
Ok.
*Main> main
*** Exception: Time.toClockTime: picoseconds out of range
*Main> main
Ok.
*Main>
```
If I modify the test to print the results of `getClockTime` and `toCalendarTime`, I see
```
plumbbob-franklin> inplace/bin/ghc-stage2 --interactive time002.hs
GHCi, version 7.0.1.20101221: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package ffi-1.0 ... linking ... done.
[1 of 1] Compiling Main ( time002.hs, interpreted )
Ok, modules loaded: Main.
*Main> main
Loading package array-0.3.0.2 ... linking ... done.
Loading package filepath-1.2.0.0 ... linking ... done.
Loading package old-locale-1.0.0.2 ... linking ... done.
Loading package old-time-1.0.0.6 ... linking ... done.
Loading package unix-2.4.1.0 ... linking ... done.
Loading package directory-1.1.0.0 ... linking ... done.
Loading package process-1.0.1.5 ... linking ... done.
Loading package time-1.2.0.3 ... linking ... done.
Loading package random-1.0.0.3 ... linking ... done.
Loading package haskell98-1.1.0.1 ... linking ... done.
Sat Feb 19 10:12:35 EST 2011
CalendarTime {ctYear = 2011, ctMonth = February, ctDay = 19, ctHour = 10, ctMin = 12, ctSec = 35, ctPicosec = 112417000000, ctWDay = Saturday, ctYDay = 49, ctTZName = "EST", ctTZ = -18000, ctIsDST = False}
Ok.
*Main> main
Sat Feb 19 10:12:37 EST 2011
CalendarTime {ctYear = 2011, ctMonth = February, ctDay = 19, ctHour = 10, ctMin = 12, ctSec = 37, ctPicosec = 4295408225000000, ctWDay = Saturday, ctYDay = 49, ctTZName = "EST", ctTZ = -18000, ctIsDST = False}
*** Exception: Time.toClockTime: picoseconds out of range
*Main>
```
The `ctPicosec` field is too big.
The interesting thing is that if I dump the relocations for HSold-time-1.0.0.6.o, and grep for `ctPicosec`, I see
```
plumbbob-franklin> otool -rv HSold-time-1.0.0.6.o | grep ctPicosec
00023c5d False long True SUB False _oldzmtimezm1zi0zi0zi6_SystemziTime_ctPicosec_info_dsp
00023c5d False long True UNSIGND False _oldzmtimezm1zi0zi0zi6_SystemziTime_ctPicosec_info
00023c55 True long True SIGNED False _oldzmtimezm1zi0zi0zi6_SystemziTime_ctPicosec_closure
00001cf8 False quad True UNSIGND False _oldzmtimezm1zi0zi0zi6_SystemziTime_ctPicosec_info
```
The first relocation is an `X86_64_RELOC_SUBTRACTOR`. This is probably being done incorrectly. (It may be distantly related to #4013, which also seems to be a subtractor relocation gone awry, but in that case of x86. The details of the x86 and x86_64 cases are quite different, but the original code for both cases is from the same author.)
After the patch that fixed #4867, there between five and seven test failures that only involve `ghci`. I'm uncertain about two because I've been building unthreaded to simplify debugging and two tests require threads. I suspect linker bugs in all these cases.
I've found a convenient list of x86_64 relocation examples at [http://developer.apple.com/library/mac/\#documentation/DeveloperTools/Conceptual/MachOTopics/1-Articles/dynamic_code.html\#//apple_ref/doc/uid/TP40002528-SW1](http://developer.apple.com/library/mac/#documentation/DeveloperTools/Conceptual/MachOTopics/1-Articles/dynamic_code.html#//apple_ref/doc/uid/TP40002528-SW1). I'll check the OS X 64 bit linker in its current state against these. Unfortunately, the list does not seem to be exhaustive. For instance, it doesn't contain the inter-section relocation that was at issue in #4867.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"time002 and time004 (ghci) test failures on OS X 64 bit","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The `time002` and `time004` tests fail for `ghci` on OS X 64 bit. The failure doesn't happen every time, but when it does, the failure is the same:\r\n\r\n{{{\r\nplumbbob-franklin> inplace/bin/ghc-stage2 --interactive time002.hs\r\nGHCi, version 7.0.1.20101221: http://www.haskell.org/ghc/ :? for help\r\nLoading package ghc-prim ... linking ... done.\r\nLoading package integer-gmp ... linking ... done.\r\nLoading package base ... linking ... done.\r\nLoading package ffi-1.0 ... linking ... done.\r\n[1 of 1] Compiling Main ( time002.hs, interpreted )\r\nOk, modules loaded: Main.\r\n*Main> main\r\nLoading package array-0.3.0.2 ... linking ... done.\r\nLoading package filepath-1.2.0.0 ... linking ... done.\r\nLoading package old-locale-1.0.0.2 ... linking ... done.\r\nLoading package old-time-1.0.0.6 ... linking ... done.\r\nLoading package unix-2.4.1.0 ... linking ... done.\r\nLoading package directory-1.1.0.0 ... linking ... done.\r\nLoading package process-1.0.1.5 ... linking ... done.\r\nLoading package time-1.2.0.3 ... linking ... done.\r\nLoading package random-1.0.0.3 ... linking ... done.\r\nLoading package haskell98-1.1.0.1 ... linking ... done.\r\nOk.\r\n*Main> main\r\nOk.\r\n*Main> main\r\nOk.\r\n*Main> main\r\nOk.\r\n*Main> main\r\nOk.\r\n*Main> main\r\nOk.\r\n*Main> main\r\nOk.\r\n*Main> main\r\nOk.\r\n*Main> main\r\nOk.\r\n*Main> main\r\n*** Exception: Time.toClockTime: picoseconds out of range\r\n*Main> main\r\nOk.\r\n*Main> \r\n}}}\r\n\r\nIf I modify the test to print the results of `getClockTime` and `toCalendarTime`, I see\r\n{{{\r\nplumbbob-franklin> inplace/bin/ghc-stage2 --interactive time002.hs\r\nGHCi, version 7.0.1.20101221: http://www.haskell.org/ghc/ :? for help\r\nLoading package ghc-prim ... linking ... done.\r\nLoading package integer-gmp ... linking ... done.\r\nLoading package base ... linking ... done.\r\nLoading package ffi-1.0 ... linking ... done.\r\n[1 of 1] Compiling Main ( time002.hs, interpreted )\r\nOk, modules loaded: Main.\r\n*Main> main\r\nLoading package array-0.3.0.2 ... linking ... done.\r\nLoading package filepath-1.2.0.0 ... linking ... done.\r\nLoading package old-locale-1.0.0.2 ... linking ... done.\r\nLoading package old-time-1.0.0.6 ... linking ... done.\r\nLoading package unix-2.4.1.0 ... linking ... done.\r\nLoading package directory-1.1.0.0 ... linking ... done.\r\nLoading package process-1.0.1.5 ... linking ... done.\r\nLoading package time-1.2.0.3 ... linking ... done.\r\nLoading package random-1.0.0.3 ... linking ... done.\r\nLoading package haskell98-1.1.0.1 ... linking ... done.\r\nSat Feb 19 10:12:35 EST 2011\r\nCalendarTime {ctYear = 2011, ctMonth = February, ctDay = 19, ctHour = 10, ctMin = 12, ctSec = 35, ctPicosec = 112417000000, ctWDay = Saturday, ctYDay = 49, ctTZName = \"EST\", ctTZ = -18000, ctIsDST = False}\r\nOk.\r\n*Main> main\r\nSat Feb 19 10:12:37 EST 2011\r\nCalendarTime {ctYear = 2011, ctMonth = February, ctDay = 19, ctHour = 10, ctMin = 12, ctSec = 37, ctPicosec = 4295408225000000, ctWDay = Saturday, ctYDay = 49, ctTZName = \"EST\", ctTZ = -18000, ctIsDST = False}\r\n*** Exception: Time.toClockTime: picoseconds out of range\r\n*Main> \r\n}}}\r\nThe `ctPicosec` field is too big.\r\n\r\nThe interesting thing is that if I dump the relocations for HSold-time-1.0.0.6.o, and grep for `ctPicosec`, I see\r\n{{{\r\nplumbbob-franklin> otool -rv HSold-time-1.0.0.6.o | grep ctPicosec\r\n00023c5d False long True SUB False _oldzmtimezm1zi0zi0zi6_SystemziTime_ctPicosec_info_dsp\r\n00023c5d False long True UNSIGND False _oldzmtimezm1zi0zi0zi6_SystemziTime_ctPicosec_info\r\n00023c55 True long True SIGNED False _oldzmtimezm1zi0zi0zi6_SystemziTime_ctPicosec_closure\r\n00001cf8 False quad True UNSIGND False _oldzmtimezm1zi0zi0zi6_SystemziTime_ctPicosec_info\r\n}}}\r\nThe first relocation is an `X86_64_RELOC_SUBTRACTOR`. This is probably being done incorrectly. (It may be distantly related to #4013, which also seems to be a subtractor relocation gone awry, but in that case of x86. The details of the x86 and x86_64 cases are quite different, but the original code for both cases is from the same author.)\r\n\r\nAfter the patch that fixed #4867, there between five and seven test failures that only involve `ghci`. I'm uncertain about two because I've been building unthreaded to simplify debugging and two tests require threads. I suspect linker bugs in all these cases.\r\n\r\nI've found a convenient list of x86_64 relocation examples at [http://developer.apple.com/library/mac/#documentation/DeveloperTools/Conceptual/MachOTopics/1-Articles/dynamic_code.html#//apple_ref/doc/uid/TP40002528-SW1]. I'll check the OS X 64 bit linker in its current state against these. Unfortunately, the list does not seem to be exhaustive. For instance, it doesn't contain the inter-section relocation that was at issue in #4867.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.2.1Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/4968openTempFile fails on Windows if a directory exists with the file name it tries2019-07-07T18:57:34ZganeshopenTempFile fails on Windows if a directory exists with the file name it triesThe program below works on Linux but fails on Windows with "permission denied" from the second openTempFile.
I think the reason is that findTempName in the openTempFile source doesn't get eEXIST when a directory with the same name exist...The program below works on Linux but fails on Windows with "permission denied" from the second openTempFile.
I think the reason is that findTempName in the openTempFile source doesn't get eEXIST when a directory with the same name exists, so it fails instead of trying again.
The real use case behind this code is making temp directories on multiple threads simultaneously.
```
import Prelude
import System.IO
import System.Directory
main :: IO ()
main = do
dir <- getTemporaryDirectory
(npath1, handle1) <- openTempFile dir "tmp"
hClose handle1
removeFile npath1
createDirectory npath1
(npath2, handle2) <- openTempFile dir "tmp"
return ()
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | --------------- |
| Version | 7.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ganesh@earth.li |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"openTempFile fails on Windows if a directory exists with the file name it tries","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ganesh@earth.li"],"type":"Bug","description":"The program below works on Linux but fails on Windows with \"permission denied\" from the second openTempFile.\r\n\r\nI think the reason is that findTempName in the openTempFile source doesn't get eEXIST when a directory with the same name exists, so it fails instead of trying again.\r\n\r\nThe real use case behind this code is making temp directories on multiple threads simultaneously.\r\n\r\n\r\n{{{\r\nimport Prelude\r\nimport System.IO\r\nimport System.Directory\r\n\r\nmain :: IO ()\r\nmain = do\r\n dir <- getTemporaryDirectory\r\n (npath1, handle1) <- openTempFile dir \"tmp\"\r\n hClose handle1\r\n removeFile npath1\r\n createDirectory npath1\r\n (npath2, handle2) <- openTempFile dir \"tmp\"\r\n return ()\r\n\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.4.2pcapriottipcapriottihttps://gitlab.haskell.org/ghc/ghc/-/issues/4956threadDelay behavior 64-bit mac os x2019-07-07T18:57:37ZperikovthreadDelay behavior 64-bit mac os xthreadDelay 1000000
```
works as expected in 7.0.1-x86_64
return immediately in DEVELOPMENT 7.1.20110131
hangs eating CPU in STABLE 7.0.1.20110201, 7.0.1.20110211
```
to reproduce:
fire up ghci
```
import Control.Concurrent
threadDela...threadDelay 1000000
```
works as expected in 7.0.1-x86_64
return immediately in DEVELOPMENT 7.1.20110131
hangs eating CPU in STABLE 7.0.1.20110201, 7.0.1.20110211
```
to reproduce:
fire up ghci
```
import Control.Concurrent
threadDelay 1000000
```7.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/4942GHC.ConsoleHandler does not call back application when Close button is pressed2019-07-07T18:57:41ZAmaticGHC.ConsoleHandler does not call back application when Close button is pressedThe test program below is not called back by GHC.ConsoleHandler when the Close button is pressed during the threadDelay call. A message is written to console_event.log as expected when Ctrl-C or Ctrl-Break is pressed, but not when the Cl...The test program below is not called back by GHC.ConsoleHandler when the Close button is pressed during the threadDelay call. A message is written to console_event.log as expected when Ctrl-C or Ctrl-Break is pressed, but not when the Close button is pressed.
```
import Control.Concurrent (threadDelay)
import GHC.ConsoleHandler
import System.IO
onConsoleEventReceived :: ConsoleEvent -> IO ()
onConsoleEventReceived event = withFile "console_event.log" AppendMode $ \ file -> do
hPutStrLn file $ case event of
ControlC -> "Received Ctrl-C event"
Break -> "Received Ctrl-Break event"
Close -> "Received X button event"
_ -> "Received other console event"
hFlush file
main :: IO ()
main = installHandler (Catch onConsoleEventReceived) >> threadDelay (20*1000000)
```
The host OS is Windows XP SP3.
Please let me know if you need any more info.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.12.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHC API |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | lightwing15@hotmail.com |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC.ConsoleHandler does not call back application when Close button is pressed","status":"New","operating_system":"","component":"GHC API","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["lightwing15@hotmail.com"],"type":"Bug","description":"The test program below is not called back by GHC.ConsoleHandler when the Close button is pressed during the threadDelay call. A message is written to console_event.log as expected when Ctrl-C or Ctrl-Break is pressed, but not when the Close button is pressed.\r\n\r\n{{{\r\nimport Control.Concurrent (threadDelay)\r\nimport GHC.ConsoleHandler\r\nimport System.IO\r\n\r\nonConsoleEventReceived :: ConsoleEvent -> IO ()\r\nonConsoleEventReceived event = withFile \"console_event.log\" AppendMode $ \\ file -> do\r\n hPutStrLn file $ case event of\r\n ControlC -> \"Received Ctrl-C event\"\r\n Break -> \"Received Ctrl-Break event\"\r\n Close -> \"Received X button event\"\r\n _ -> \"Received other console event\"\r\n hFlush file\r\n \r\nmain :: IO ()\r\nmain = installHandler (Catch onConsoleEventReceived) >> threadDelay (20*1000000)\r\n}}}\r\n\r\nThe host OS is Windows XP SP3.\r\n\r\nPlease let me know if you need any more info.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/4914FPU initialization required again2019-07-07T18:57:56ZaruizFPU initialization required againI think that the bug [2724](http://hackage.haskell.org/trac/ghc/ticket/2724), fixed in ghc-6.10.x, has reappeared in ghc-7.0.1. When I run hmatrix tests I get the same kind of random errors, which disappear if I insert the asm finit call...I think that the bug [2724](http://hackage.haskell.org/trac/ghc/ticket/2724), fixed in ghc-6.10.x, has reappeared in ghc-7.0.1. When I run hmatrix tests I get the same kind of random errors, which disappear if I insert the asm finit call. I don't have a small test case without dependencies, but I hope that this problem can be easily reproduced as follows:
```
$ cabal update
$ cabal unpack hmatrix
$ cd hmatrix-0.11.0.0
$ cabal install [-f-vector] [-f-binary]
```
(these flags can be given to minimize dependencies)
```
$ cabal test
```
All tests must pass. Now we will try to produce the error:
Comment out line 172 of hmatrix.cabal to remove the workaround for ghc-7.0.1:
```
- cpp-options: -DFINIT
+ -- cpp-options: -DFINIT
```
```
$ cabal clean
$ cabal install [-f-vector] [-f-binary]
$ cabal test
```
Now we will probably get several errors.
Please let me know if you need more information. I hope I have not made some big mistake.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (NCG) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"FPU initialization required again","status":"New","operating_system":"","component":"Compiler (NCG)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I think that the bug [http://hackage.haskell.org/trac/ghc/ticket/2724 2724], fixed in ghc-6.10.x, has reappeared in ghc-7.0.1. When I run hmatrix tests I get the same kind of random errors, which disappear if I insert the asm finit call. I don't have a small test case without dependencies, but I hope that this problem can be easily reproduced as follows:\r\n\r\n\r\n{{{\r\n$ cabal update\r\n$ cabal unpack hmatrix\r\n$ cd hmatrix-0.11.0.0\r\n$ cabal install [-f-vector] [-f-binary]\r\n}}}\r\n\r\n\r\n(these flags can be given to minimize dependencies)\r\n\r\n\r\n{{{\r\n$ cabal test\r\n}}}\r\n\r\n\r\nAll tests must pass. Now we will try to produce the error:\r\n\r\nComment out line 172 of hmatrix.cabal to remove the workaround for ghc-7.0.1:\r\n\r\n\r\n{{{\r\n- cpp-options: -DFINIT\r\n+ -- cpp-options: -DFINIT\r\n}}}\r\n\r\n\r\n\r\n{{{\r\n$ cabal clean\r\n$ cabal install [-f-vector] [-f-binary]\r\n$ cabal test\r\n}}}\r\n\r\n\r\nNow we will probably get several errors.\r\n\r\nPlease let me know if you need more information. I hope I have not made some big mistake.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/4911GHC 7 does not process Handle correctly2019-07-07T18:57:57Zkazu-yamamotoGHC 7 does not process Handle correctlyCompile the following code:
```
module Main where
import qualified Data.ByteString.Lazy.Char8 as L
main :: IO ()
main = do
getLine >>= putStrLn
L.getContents >>= L.putStr
```
Let's call this binary "foo". If you compile this ...Compile the following code:
```
module Main where
import qualified Data.ByteString.Lazy.Char8 as L
main :: IO ()
main = do
getLine >>= putStrLn
L.getContents >>= L.putStr
```
Let's call this binary "foo". If you compile this with GHC 6.12.3, the following command work well. That is, the entire of "any-file" is displayed.
```
% foo < any-file
```
However, if you compile this with GHC 7.0.1 or later, the command displays only the first line of "any-file".
This can be re-produced on Linux.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.0.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":"GHC 7 does not process Handle correctly","status":"New","operating_system":"Linux","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Compile the following code:\r\n\r\n{{{\r\nmodule Main where\r\n\r\nimport qualified Data.ByteString.Lazy.Char8 as L\r\n\r\nmain :: IO ()\r\nmain = do\r\n getLine >>= putStrLn\r\n L.getContents >>= L.putStr\r\n}}}\r\n\r\nLet's call this binary \"foo\". If you compile this with GHC 6.12.3, the following command work well. That is, the entire of \"any-file\" is displayed.\r\n\r\n{{{\r\n% foo < any-file\r\n}}}\r\n\r\nHowever, if you compile this with GHC 7.0.1 or later, the command displays only the first line of \"any-file\".\r\n\r\nThis can be re-produced on Linux.\r\n\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/4910mkStdGen (-2^31) is ⊥2019-07-07T18:57:58Zion1mkStdGen (-2^31) is ⊥Quoting System/Random.hs:
```
mkStdGen32 :: Int32 -> StdGen
mkStdGen32 s
| s < 0 = mkStdGen32 (-s)
```
Alas, the fact that…
```
ghci> (minBound :: Data.Int.Int32) == negate minBound
True
```
…results in mkStdGen32 going into inf...Quoting System/Random.hs:
```
mkStdGen32 :: Int32 -> StdGen
mkStdGen32 s
| s < 0 = mkStdGen32 (-s)
```
Alas, the fact that…
```
ghci> (minBound :: Data.Int.Int32) == negate minBound
True
```
…results in mkStdGen32 going into infinite recursion when applied to the minBound of Int32.
The proposed patch should fix the issue.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/random |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"mkStdGen (-2^31) is ⊥","status":"New","operating_system":"","component":"libraries/random","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Quoting System/Random.hs:\r\n\r\n{{{\r\nmkStdGen32 :: Int32 -> StdGen\r\nmkStdGen32 s\r\n | s < 0 = mkStdGen32 (-s)\r\n}}}\r\n\r\nAlas, the fact that…\r\n\r\n{{{\r\nghci> (minBound :: Data.Int.Int32) == negate minBound\r\nTrue\r\n}}}\r\n\r\n…results in mkStdGen32 going into infinite recursion when applied to the minBound of Int32.\r\n\r\nThe proposed patch should fix the issue.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/4895hGetBufSome returns 0 when it should not2019-07-07T18:58:00ZguesthGetBufSome returns 0 when it should notIn the attached program hGetBufSome returns 0, but the handle contains more data to be read. This contradicts to the documentation.
-- Takano Akio
<details><summary>Trac metadata</summary>
| Trac field | Value |
|...In the attached program hGetBufSome returns 0, but the handle contains more data to be read. This contradicts to the documentation.
-- Takano Akio
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | aljee@hyper.cx |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"hGetBufSome returns 0 when it should not","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["aljee@hyper.cx"],"type":"Bug","description":"In the attached program hGetBufSome returns 0, but the handle contains more data to be read. This contradicts to the documentation.\r\n\r\n-- Takano Akio","type_of_failure":"OtherFailure","blocking":[]} -->7.0.2Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/4884registerPackage fails with multiple command line --package-conf= flags2019-07-07T18:58:04Zr6registerPackage fails with multiple command line --package-conf= flagsin registerPackage the database to operate on is filtered, whereas the databases to validate are \*truncated\*. The trucation can be seen in the code:
> let truncated_stack = dropWhile ((/= to_modify).location) db_stack
> -- truncate ...in registerPackage the database to operate on is filtered, whereas the databases to validate are \*truncated\*. The trucation can be seen in the code:
> let truncated_stack = dropWhile ((/= to_modify).location) db_stack
> -- truncate the stack for validation, because we don't allow
> -- packages lower in the stack to refer to those higher up.
> validatePackageConfig pkg truncated_stack auto_ghci_libs update force
notice the use of dropWhile instead of filter. The problem is that if I want to update a package with a command with multiple --package-conf= parameters, then these parameters get ignored during validation and if the package being installed depends on the packages in these databases, the installation will fail (unless --force is used). For example if you run the command
> ghc-pkg --package-conf=myPkg1 --package-conf=myPkg2 --package-conf=myPkg3 --global --user update newPkg.conf
then the command will fail with the error ""something" doesn't exist (use --force to override)" if newPkg.conf depends on something in on of myPkgs.
In fact, with the above command, the truncated_stack consists of only two packages: \[the-user-pkg,the-global-pkg\].
I think the fix is to use a filter instead of dropWhile, but maybe there is some purpose behind using dropWhile. In any case a bug does exist because the above ghc-pkg command should succeed.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.12.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | ghc-pkg |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"registerPackage fails with multiple command line --package-conf= flags","status":"New","operating_system":"","component":"ghc-pkg","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"in registerPackage the database to operate on is filtered, whereas the databases to validate are *truncated*. The trucation can be seen in the code:\r\n\r\n let truncated_stack = dropWhile ((/= to_modify).location) db_stack\r\n -- truncate the stack for validation, because we don't allow\r\n -- packages lower in the stack to refer to those higher up.\r\n validatePackageConfig pkg truncated_stack auto_ghci_libs update force\r\n\r\nnotice the use of dropWhile instead of filter. The problem is that if I want to update a package with a command with multiple --package-conf= parameters, then these parameters get ignored during validation and if the package being installed depends on the packages in these databases, the installation will fail (unless --force is used). For example if you run the command\r\n\r\n ghc-pkg --package-conf=myPkg1 --package-conf=myPkg2 --package-conf=myPkg3 --global --user update newPkg.conf\r\n\r\nthen the command will fail with the error \"\"something\" doesn't exist (use --force to override)\" if newPkg.conf depends on something in on of myPkgs.\r\n\r\nIn fact, with the above command, the truncated_stack consists of only two packages: [the-user-pkg,the-global-pkg].\r\n\r\nI think the fix is to use a filter instead of dropWhile, but maybe there is some purpose behind using dropWhile. In any case a bug does exist because the above ghc-pkg command should succeed.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/4876isEmptySampleVar returns False when threads are waiting on an empty SampleVar2019-07-07T18:58:06ZguestisEmptySampleVar returns False when threads are waiting on an empty SampleVarThe source code for Control.Concurrent.SampleVar.isEmptySampleVar:
```
isEmptySampleVar :: SampleVar a -> IO Bool
isEmptySampleVar (SampleVar svar) = do
(readers, _) <- readMVar svar
return (readers == 0)
```
should have readers ...The source code for Control.Concurrent.SampleVar.isEmptySampleVar:
```
isEmptySampleVar :: SampleVar a -> IO Bool
isEmptySampleVar (SampleVar svar) = do
(readers, _) <- readMVar svar
return (readers == 0)
```
should have readers \<= 0, as the state readers \< 0 is used to indicate the SampleVar is empty and has threads waiting on it.
As an example:
```
import System.Random
import Control.Concurrent.SampleVar
import Control.Concurrent
do_something = threadDelay 100000 -- 100 ms
loop body = body >> loop body
produce, consume :: SampleVar Int -> IO ()
produce svar = do
do_something
b <- isEmptySampleVar svar
if b then randomIO >>= writeSampleVar svar else return ()
consume svar = readSampleVar svar >>= print
main = do
svar <- newEmptySampleVar
forkIO $ loop $ produce svar
forkIO $ loop $ consume svar
threadDelay 1000000 -- one second
```
This code deadlocks instead of printing random numbers.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------------------------- |
| Version | 7.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | eric.stansifer+haskell@gmail.com |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"isEmptySampleVar returns False when threads are waiting on an empty SampleVar","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["eric.stansifer+haskell@gmail.com"],"type":"Bug","description":"The source code for Control.Concurrent.SampleVar.isEmptySampleVar:\r\n\r\n{{{\r\nisEmptySampleVar :: SampleVar a -> IO Bool\r\nisEmptySampleVar (SampleVar svar) = do\r\n (readers, _) <- readMVar svar\r\n return (readers == 0)\r\n}}}\r\n\r\nshould have readers <= 0, as the state readers < 0 is used to indicate the SampleVar is empty and has threads waiting on it.\r\n\r\nAs an example:\r\n\r\n{{{\r\nimport System.Random\r\nimport Control.Concurrent.SampleVar\r\nimport Control.Concurrent\r\n\r\ndo_something = threadDelay 100000 -- 100 ms\r\nloop body = body >> loop body\r\n\r\nproduce, consume :: SampleVar Int -> IO ()\r\nproduce svar = do\r\n do_something\r\n b <- isEmptySampleVar svar\r\n if b then randomIO >>= writeSampleVar svar else return ()\r\n\r\nconsume svar = readSampleVar svar >>= print\r\n\r\nmain = do\r\n svar <- newEmptySampleVar\r\n forkIO $ loop $ produce svar\r\n forkIO $ loop $ consume svar\r\n threadDelay 1000000 -- one second\r\n}}}\r\n\r\nThis code deadlocks instead of printing random numbers.","type_of_failure":"OtherFailure","blocking":[]} -->7.0.2Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/4869ghci command line option -l should accept either -llibrary or -l library (POS...2019-07-07T18:58:07ZHoward B. Goldenghci command line option -l should accept either -llibrary or -l library (POSIX requirement)According to POSIX, the -l option of GHCi should work with either the library name concatenated to the -l or as as separate argument immediately following the -l. At present it only works in the first case.
Examples of current behavior:...According to POSIX, the -l option of GHCi should work with either the library name concatenated to the -l or as as separate argument immediately following the -l. At present it only works in the first case.
Examples of current behavior:
```
# failure (library name separated from -l)
hgolden@hbg-srv3 ~ $ ghci -l pcre
GHCi, version 7.0.1: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package ffi-1.0 ... linking ... done.
Loading object (dynamic) ... failed.
<command line>: user specified .o/.so/.DLL could not be loaded (lib.so: cannot open shared object file: No such file or directory)
Whilst trying to load: (dynamic)
Additional directories searched: (none)
# success (library name concatenated with -l)
hgolden@hbg-srv3 ~ $ ghci -lpcre
GHCi, version 7.0.1: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package ffi-1.0 ... linking ... done.
Loading object (dynamic) pcre ... done
final link ... done
Prelude> :q
Leaving GHCi.
```
(This is a very minor bug with a trivial workaround. However, it should be easy to fix.)
Compare how GCC handles -l. While the -l library form is discouraged, it is accepted.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ghci command line option -l should accept either -llibrary or -l library (POSIX requirement)","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"According to POSIX, the -l option of GHCi should work with either the library name concatenated to the -l or as as separate argument immediately following the -l. At present it only works in the first case.\r\n\r\nExamples of current behavior:\r\n\r\n\r\n{{{\r\n# failure (library name separated from -l)\r\nhgolden@hbg-srv3 ~ $ ghci -l pcre\r\nGHCi, version 7.0.1: http://www.haskell.org/ghc/ :? for help\r\nLoading package ghc-prim ... linking ... done.\r\nLoading package integer-gmp ... linking ... done.\r\nLoading package base ... linking ... done.\r\nLoading package ffi-1.0 ... linking ... done.\r\nLoading object (dynamic) ... failed.\r\n<command line>: user specified .o/.so/.DLL could not be loaded (lib.so: cannot open shared object file: No such file or directory)\r\nWhilst trying to load: (dynamic) \r\nAdditional directories searched: (none)\r\n\r\n# success (library name concatenated with -l)\r\nhgolden@hbg-srv3 ~ $ ghci -lpcre\r\nGHCi, version 7.0.1: http://www.haskell.org/ghc/ :? for help\r\nLoading package ghc-prim ... linking ... done.\r\nLoading package integer-gmp ... linking ... done.\r\nLoading package base ... linking ... done.\r\nLoading package ffi-1.0 ... linking ... done.\r\nLoading object (dynamic) pcre ... done\r\nfinal link ... done\r\nPrelude> :q\r\nLeaving GHCi.\r\n}}}\r\n\r\n(This is a very minor bug with a trivial workaround. However, it should be easy to fix.)\r\n\r\nCompare how GCC handles -l. While the -l library form is discouraged, it is accepted.","type_of_failure":"OtherFailure","blocking":[]} -->7.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/4867ghci displays negative floats incorrectly (was: Incorrect result from trig fu...2019-07-07T18:58:08Zgwright@antiope.comghci displays negative floats incorrectly (was: Incorrect result from trig functions)Trigonometric functions give the wrong answer in some cases. I have verified this bug on ghc-7.0.1 and ghc-7.0.1-rc1 on OS X 10.6 64 bit. (The bug may be limited to 64 bit platforms; I've not been able to reproduce it on ghc-6.10.4/OS X ...Trigonometric functions give the wrong answer in some cases. I have verified this bug on ghc-7.0.1 and ghc-7.0.1-rc1 on OS X 10.6 64 bit. (The bug may be limited to 64 bit platforms; I've not been able to reproduce it on ghc-6.10.4/OS X 10.5/32 bit.)
Here's an example (ghc-7.0.2-rc1, OS X 10.6, 64 bit):
```
plumbbob-franklin> inplace/bin/ghc-stage2 --interactive
GHCi, version 7.0.1.20101221: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package ffi-1.0 ... linking ... done.
Prelude> tan (0.5 * pi + 0.01)
-4.563974029425858e214
Prelude> tan (0.5 * pi - 0.01)
99.99666664444354
Prelude>
```
The first result (`tan (0.5 * pi + 0.01)`) is wrong. The correct answer is close to -100.0. The `sin` and `cos` functions also give incorrect answers in some cases, e.g.,
```
Prelude> cos (3.0 * pi)
-3.666940035476786e76
```
At first glance, the bug seems related to the normalization of the argument (i.e., mapping the argument to the range `(-pi/2, pi/2)`).
This is a nasty one. It ought to be fixed before 7.0.2 goes out.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 7.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown/Multiple |
| Architecture | Unknown/Multiple |
</details>
<!-- {"blocked_by":[],"summary":"Incorrect result from trig functions","status":"New","operating_system":"Unknown/Multiple","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown/Multiple","cc":[""],"type":"Bug","description":"Trigonometric functions give the wrong answer in some cases. I have verified this bug on ghc-7.0.1 and ghc-7.0.1-rc1 on OS X 10.6 64 bit. (The bug may be limited to 64 bit platforms; I've not been able to reproduce it on ghc-6.10.4/OS X 10.5/32 bit.)\r\n\r\nHere's an example (ghc-7.0.2-rc1, OS X 10.6, 64 bit):\r\n{{{\r\nplumbbob-franklin> inplace/bin/ghc-stage2 --interactive\r\nGHCi, version 7.0.1.20101221: http://www.haskell.org/ghc/ :? for help\r\nLoading package ghc-prim ... linking ... done.\r\nLoading package integer-gmp ... linking ... done.\r\nLoading package base ... linking ... done.\r\nLoading package ffi-1.0 ... linking ... done.\r\nPrelude> tan (0.5 * pi + 0.01)\r\n-4.563974029425858e214\r\nPrelude> tan (0.5 * pi - 0.01)\r\n99.99666664444354\r\nPrelude> \r\n}}}\r\nThe first result (`tan (0.5 * pi + 0.01)`) is wrong. The correct answer is close to -100.0. The `sin` and `cos` functions also give incorrect answers in some cases, e.g.,\r\n{{{\r\nPrelude> cos (3.0 * pi)\r\n-3.666940035476786e76\r\n}}}\r\n\r\nAt first glance, the bug seems related to the normalization of the argument (i.e., mapping the argument to the range `(-pi/2, pi/2)`).\r\n\r\nThis is a nasty one. It ought to be fixed before 7.0.2 goes out.","type_of_failure":"OtherFailure","blocking":[]} -->7.0.2gwright@antiope.comgwright@antiope.comhttps://gitlab.haskell.org/ghc/ghc/-/issues/4855Debug.Trace.trace mangles Unicode strings2019-07-07T18:58:11ZAnders KaseorgDebug.Trace.trace mangles Unicode strings```
Prelude Debug.Trace> trace "Σὲ γνωρίζω ἀπὸ τὴν κόψη" ()
�r ����w��
()
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version |...```
Prelude Debug.Trace> trace "Σὲ γνωρίζω ἀπὸ τὴν κόψη" ()
�r ����w��
()
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Debug.Trace.trace mangles Unicode strings","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\nPrelude Debug.Trace> trace \"Σὲ γνωρίζω ἀπὸ τὴν κόψη\" ()\r\n�r ����w�� \r\n()\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/4844createDirectoryIfMissing fails to create directory if compiled2019-07-07T18:58:15ZNeil MitchellcreateDirectoryIfMissing fails to create directory if compiledI'm seeing really weird behaviour - that I'm sure used to work, and is even broken with older compilers. The fault may lie with my system, or some libraries somewhere, but it's easily checkable, and worth someone else trying.
Given the ...I'm seeing really weird behaviour - that I'm sure used to work, and is even broken with older compilers. The fault may lie with my system, or some libraries somewhere, but it's easily checkable, and worth someone else trying.
Given the code:
```
module Main where
import System.Directory
main = do
print 1
createDirectoryIfMissing True "hello"
print 2
createDirectoryIfMissing True "hello"
```
I can use `runhaskell`:
```
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.0.1.20101215
$ runhaskell Main
1
2
$ ghc --make Main
$ main
Main.exe: CreateDirectory "hello": invalid argument (Cannot create a file when that file already exists.)
```
I would expect the `runhaskell` behaviour both times. I have tried this with GHC 6.12.3, where I'm sure I used to rely on this behaviour, and it's broken there too. Is my system going crazy?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------- |
| Version | 7.0.1 |
| 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 fails to create directory if compiled","status":"New","operating_system":"","component":"libraries/directory","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I'm seeing really weird behaviour - that I'm sure used to work, and is even broken with older compilers. The fault may lie with my system, or some libraries somewhere, but it's easily checkable, and worth someone else trying.\r\n\r\nGiven the code:\r\n\r\n{{{\r\nmodule Main where\r\nimport System.Directory\r\nmain = do\r\n print 1\r\n createDirectoryIfMissing True \"hello\"\r\n print 2\r\n createDirectoryIfMissing True \"hello\"\r\n}}}\r\n\r\nI can use {{{runhaskell}}}:\r\n\r\n{{{\r\n$ ghc --version\r\nThe Glorious Glasgow Haskell Compilation System, version 7.0.1.20101215\r\n$ runhaskell Main\r\n1\r\n2\r\n$ ghc --make Main\r\n$ main\r\nMain.exe: CreateDirectory \"hello\": invalid argument (Cannot create a file when that file already exists.)\r\n}}}\r\n\r\nI would expect the {{{runhaskell}}} behaviour both times. I have tried this with GHC 6.12.3, where I'm sure I used to rely on this behaviour, and it's broken there too. Is my system going crazy?","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/4827Data.Array.IO.hPutArray/hGetArray ignore count argument2019-07-07T18:58:22Zdylan@dylex.netData.Array.IO.hPutArray/hGetArray ignore count argumentThe ghc versions of hGetArray and hPutArray in Data.Array.IO in the array library ignore their count arguments, and read or write the full array regardless. This was observed as a bug where extraneous garbage data was written to the end ...The ghc versions of hGetArray and hPutArray in Data.Array.IO in the array library ignore their count arguments, and read or write the full array regardless. This was observed as a bug where extraneous garbage data was written to the end of a file. The non-ghc versions (appear) correct.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 6.12.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries (other) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Linux |
| Architecture | x86_64 (amd64) |
</details>
<!-- {"blocked_by":[],"summary":"Data.Array.IO.hPutArray/hGetArray ignore count argument","status":"New","operating_system":"Linux","component":"libraries (other)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.3","keywords":[],"differentials":[],"test_case":"","architecture":"x86_64 (amd64)","cc":[""],"type":"Bug","description":"The ghc versions of hGetArray and hPutArray in Data.Array.IO in the array library ignore their count arguments, and read or write the full array regardless. This was observed as a bug where extraneous garbage data was written to the end of a file. The non-ghc versions (appear) correct.","type_of_failure":"OtherFailure","blocking":[]} -->batterseapowerbatterseapowerhttps://gitlab.haskell.org/ghc/ghc/-/issues/4809MonoLocalBinds and type classes cause infinite loop2019-07-07T18:58:27ZJeremyShawMonoLocalBinds and type classes cause infinite loopThe following program gets stuck in a loop and prints no output when run:
```
{-# LANGUAGE MonoLocalBinds #-}
module Main where
import IdentityT (IdentityT(..), XML, runIdentityT)
import XMLGenerator (XMLGenT(..), XMLGen(genElement), C...The following program gets stuck in a loop and prints no output when run:
```
{-# LANGUAGE MonoLocalBinds #-}
module Main where
import IdentityT (IdentityT(..), XML, runIdentityT)
import XMLGenerator (XMLGenT(..), XMLGen(genElement), Child, EmbedAsChild(..), unXMLGenT)
import System.IO (BufferMode(..), hSetBuffering, stdout)
page :: XMLGenT (IdentityT IO) XML
page = genElement (Nothing, "ul") [] [ asChild (asChild "foo")]
where
-- item :: XMLGenT (IdentityT IO) [Child (IdentityT IO)]
item = (asChild $ asChild (return "bar" :: XMLGenT (IdentityT IO) String))
main :: IO ()
main =
do hSetBuffering stdout LineBuffering
r <- runIdentityT (unXMLGenT page)
print r
```
I believe this is due to a compiler bug. There are five things you can do to make it run successfully (i.e., not loop) -- none of which ought to have an effect. Doing any one of the five works though.
Note that 'item' in the 'page' where clause is not actually used anywhere, but three of the five things involve changes to that clause.
1. remove the 'where' clause in 'page' entirely. After all it is not needed.
1. uncomment the type signature for 'item'
1. remove one of the calls to 'asChild' in item.
1. remove one of the calls to 'asChild' in page.
1. remove the MonoLocalBinds pragma.
I considered the possibility that the loop might be cause by asChild calls forming a loop depending on how the types are inferred. However, each call to asChild does a putStrLn. Since there is no output when the loop occurs, I believe that the execution is not even getting that far.
Doing --dump-ds, does show the loop. But I could figure out anything useful from seeing the loop in the desugared code.
The looping seems to occur whether compiled or using GHCi and at all optimization levels.
This bug prevents HSP, and therefore Happstack and SeeReason from moving to GHC 7.
I have attached 3 files. The above file, IdentityT.hs and XMLGenerator.hs. The latter two come from HSP/Happstack, but have been stripped down to the bare essentials.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"MonoLocalBinds and type classes cause infinite loop","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The following program gets stuck in a loop and prints no output when run:\r\n\r\n{{{\r\n\r\n{-# LANGUAGE MonoLocalBinds #-}\r\nmodule Main where\r\n\r\nimport IdentityT (IdentityT(..), XML, runIdentityT)\r\nimport XMLGenerator (XMLGenT(..), XMLGen(genElement), Child, EmbedAsChild(..), unXMLGenT)\r\nimport System.IO (BufferMode(..), hSetBuffering, stdout)\r\n\r\npage :: XMLGenT (IdentityT IO) XML\r\npage = genElement (Nothing, \"ul\") [] [ asChild (asChild \"foo\")]\r\n where\r\n-- item :: XMLGenT (IdentityT IO) [Child (IdentityT IO)] \r\n item = (asChild $ asChild (return \"bar\" :: XMLGenT (IdentityT IO) String))\r\n\r\nmain :: IO ()\r\nmain =\r\n do hSetBuffering stdout LineBuffering\r\n r <- runIdentityT (unXMLGenT page)\r\n print r\r\n}}}\r\n\r\nI believe this is due to a compiler bug. There are five things you can do to make it run successfully (i.e., not loop) -- none of which ought to have an effect. Doing any one of the five works though.\r\n\r\nNote that 'item' in the 'page' where clause is not actually used anywhere, but three of the five things involve changes to that clause.\r\n\r\n1. remove the 'where' clause in 'page' entirely. After all it is not needed.\r\n\r\n2. uncomment the type signature for 'item'\r\n\r\n3. remove one of the calls to 'asChild' in item.\r\n\r\n4. remove one of the calls to 'asChild' in page. \r\n\r\n5. remove the MonoLocalBinds pragma.\r\n\r\nI considered the possibility that the loop might be cause by asChild calls forming a loop depending on how the types are inferred. However, each call to asChild does a putStrLn. Since there is no output when the loop occurs, I believe that the execution is not even getting that far. \r\n\r\nDoing --dump-ds, does show the loop. But I could figure out anything useful from seeing the loop in the desugared code.\r\n\r\nThe looping seems to occur whether compiled or using GHCi and at all optimization levels.\r\n\r\nThis bug prevents HSP, and therefore Happstack and SeeReason from moving to GHC 7.\r\n\r\nI have attached 3 files. The above file, IdentityT.hs and XMLGenerator.hs. The latter two come from HSP/Happstack, but have been stripped down to the bare essentials.\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/4807Data instance for Data.Map is incomplete2019-07-07T18:58:27ZsclvData instance for Data.Map is incompleteThere's no dataCast1 defined for Data.Map. This makes the `ext1` family unusable with Maps, since `ext` is built on dataCast rather than gcast.
Observe:
```
Prelude Data.Data Data.Generics Data.Map> gcast1 (Just empty :: forall d. (Dat...There's no dataCast1 defined for Data.Map. This makes the `ext1` family unusable with Maps, since `ext` is built on dataCast rather than gcast.
Observe:
```
Prelude Data.Data Data.Generics Data.Map> gcast1 (Just empty :: forall d. (Data d) => Maybe (Map Int d)) :: Maybe (Maybe (Map Int Int))
Just (Just (fromList []))
Prelude Data.Data Data.Generics Data.Map> dataCast1 (Just empty :: forall d. (Data d) => Maybe (Map Int d)) :: Maybe (Maybe (Map Int Int))
Nothing
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Data instance for Data.Map is incomplete","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"There's no dataCast1 defined for Data.Map. This makes the `ext1` family unusable with Maps, since `ext` is built on dataCast rather than gcast.\r\n\r\nObserve: \r\n\r\n{{{\r\nPrelude Data.Data Data.Generics Data.Map> gcast1 (Just empty :: forall d. (Data d) => Maybe (Map Int d)) :: Maybe (Maybe (Map Int Int))\r\nJust (Just (fromList []))\r\nPrelude Data.Data Data.Generics Data.Map> dataCast1 (Just empty :: forall d. (Data d) => Maybe (Map Int d)) :: Maybe (Maybe (Map Int Int))\r\nNothing\r\n}}}\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->