GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:54:23Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/5611Asynchronous exception discarded after safe FFI call2019-07-07T18:54:23ZjoeyadamsAsynchronous exception discarded after safe FFI call**Note:** This bug appears to be fixed already, as it does not appear with GHC 7.2.1 . I'm submitting a bug report anyway, to document its presence.
The bug is: when an asynchronous exception is thrown to a thread making a (safe) foreig...**Note:** This bug appears to be fixed already, as it does not appear with GHC 7.2.1 . I'm submitting a bug report anyway, to document its presence.
The bug is: when an asynchronous exception is thrown to a thread making a (safe) foreign call, the thread throwing the exception blocks like it should, but then the exception isn't actually delivered. For example:
```haskell
{-# LANGUAGE ForeignFunctionInterface #-}
import Control.Concurrent
import Foreign.C
import System.IO
foreign import ccall safe "unistd.h sleep"
sleep :: CUInt -> IO CUInt
main :: IO ()
main = do
hSetBuffering stdout LineBuffering
tid <- forkIO $ do
putStrLn "child: Sleeping"
_ <- sleep 1
-- The following lines should not happen after the killThread from the
-- parent thread completes. However, they do...
putStrLn "child: Done sleeping"
threadDelay 1000000
putStrLn "child: Done waiting"
threadDelay 100000
putStrLn $ "parent: Throwing exception to thread " ++ show tid
throwTo tid $ userError "Exception delivered successfully"
putStrLn "parent: Done throwing exception"
threadDelay 2000000
```
When the bug is present, the program prints:
```
child: Sleeping
parent: Throwing exception to thread ThreadId 4
child: Done sleeping
parent: Done throwing exception
child: Done waiting
```
"child: Done waiting" should not be printed after completion of the throwTo, and the exception message should appear. On GHC 7.2.1, the program prints:
```
child: Sleeping
parent: Throwing exception to thread ThreadId 4
parent: Done throwing exception
ffi-sleep: user error (Exception delivered successfully)
```
This bug has been reproduced in GHC 7.0.3, on both Linux and Windows. It has also been reproduced on GHC 7.0.4.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.0.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Asynchronous exception discarded after safe FFI call","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.3","keywords":["FFI,","exception"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"'''Note:''' This bug appears to be fixed already, as it does not appear with GHC 7.2.1 . I'm submitting a bug report anyway, to document its presence.\r\n\r\nThe bug is: when an asynchronous exception is thrown to a thread making a (safe) foreign call, the thread throwing the exception blocks like it should, but then the exception isn't actually delivered. For example:\r\n\r\n{{{\r\n\r\n{-# LANGUAGE ForeignFunctionInterface #-}\r\n\r\nimport Control.Concurrent\r\nimport Foreign.C\r\nimport System.IO\r\n\r\nforeign import ccall safe \"unistd.h sleep\"\r\n sleep :: CUInt -> IO CUInt\r\n\r\nmain :: IO ()\r\nmain = do\r\n hSetBuffering stdout LineBuffering\r\n\r\n tid <- forkIO $ do\r\n putStrLn \"child: Sleeping\"\r\n _ <- sleep 1\r\n\r\n -- The following lines should not happen after the killThread from the\r\n -- parent thread completes. However, they do...\r\n putStrLn \"child: Done sleeping\"\r\n threadDelay 1000000\r\n putStrLn \"child: Done waiting\"\r\n\r\n threadDelay 100000\r\n putStrLn $ \"parent: Throwing exception to thread \" ++ show tid\r\n throwTo tid $ userError \"Exception delivered successfully\"\r\n putStrLn \"parent: Done throwing exception\"\r\n\r\n threadDelay 2000000\r\n}}}\r\n\r\nWhen the bug is present, the program prints:\r\n\r\n{{{\r\nchild: Sleeping\r\nparent: Throwing exception to thread ThreadId 4\r\nchild: Done sleeping\r\nparent: Done throwing exception\r\nchild: Done waiting\r\n}}}\r\n\r\n\"child: Done waiting\" should not be printed after completion of the throwTo, and the exception message should appear. On GHC 7.2.1, the program prints:\r\n\r\n{{{\r\nchild: Sleeping\r\nparent: Throwing exception to thread ThreadId 4\r\nparent: Done throwing exception\r\nffi-sleep: user error (Exception delivered successfully)\r\n}}}\r\n\r\nThis bug has been reproduced in GHC 7.0.3, on both Linux and Windows. It has also been reproduced on GHC 7.0.4.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/12012Socket operations on Windows check errno instead of calling WSAGetLastError()2019-07-07T18:27:59ZenolanSocket operations on Windows check errno instead of calling WSAGetLastError()Winsock doesn't set errno, but it is checked in `blockingReadRawBufferPtr` and `blockingWriteRawBufferPtr` (both are in `GHC.IO.FD`). I the same thing happens in the non threaded RTS too, but that's in terms of primops and I don't unders...Winsock doesn't set errno, but it is checked in `blockingReadRawBufferPtr` and `blockingWriteRawBufferPtr` (both are in `GHC.IO.FD`). I the same thing happens in the non threaded RTS too, but that's in terms of primops and I don't understand it very well.
The upshot here is that every error message originating from Winsock is wrong. Nobody noticed since any error used to just crash your program (#12010).
Here's some MinGW documentation http://oldwiki.mingw.org/index.php/sockets and something from MSDN https://msdn.microsoft.com/en-us/library/windows/desktop/ms740121%28v=vs.85%29.aspx
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Core Libraries |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ekmett |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Socket operations on Windows check errno instead of calling WSAGetLastError()","status":"New","operating_system":"","component":"Core Libraries","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ekmett"],"type":"Bug","description":"Winsock doesn't set errno, but it is checked in `blockingReadRawBufferPtr` and `blockingWriteRawBufferPtr` (both are in `GHC.IO.FD`). I the same thing happens in the non threaded RTS too, but that's in terms of primops and I don't understand it very well.\r\n\r\nThe upshot here is that every error message originating from Winsock is wrong. Nobody noticed since any error used to just crash your program (#12010).\r\n\r\nHere's some MinGW documentation http://oldwiki.mingw.org/index.php/sockets and something from MSDN https://msdn.microsoft.com/en-us/library/windows/desktop/ms740121%28v=vs.85%29.aspx","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1AzelAzelhttps://gitlab.haskell.org/ghc/ghc/-/issues/14238`:kind` suppresses visible dependent quantifiers by default in GHCi 8.2.12019-07-07T18:17:49ZRyan Scott`:kind` suppresses visible dependent quantifiers by default in GHCi 8.2.1Load this program into GHCi on 8.2.1 or later:
```hs
{-# LANGUAGE GADTs #-}
{-# LANGUAGE TypeInType #-}
import Data.Kind
data Foo (k :: Type) :: k -> Type where
MkFoo :: Foo (k1 -> k2) f -> Foo k1 a -> Foo k2 (f a)
```
And ask it w...Load this program into GHCi on 8.2.1 or later:
```hs
{-# LANGUAGE GADTs #-}
{-# LANGUAGE TypeInType #-}
import Data.Kind
data Foo (k :: Type) :: k -> Type where
MkFoo :: Foo (k1 -> k2) f -> Foo k1 a -> Foo k2 (f a)
```
And ask it what the kind of `Foo` is:
```
GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /home/rgscott/.ghci
[1 of 1] Compiling Main ( Bug.hs, interpreted )
Ok, 1 module loaded.
λ> :k Foo
Foo :: k -> *
```
This is just plain wrong: the actual kind of `Foo` should be `forall k -> k -> *`. Normally, one can omit `forall`s from a kind signature, but this is a special case where we're using a //visible// forall. In other words, `forall k -> k -> *` is not the same as `k -> *`, as the former takes two arguments, whereas the latter takes one.
A workaround is to force GHCi to come to its senses by explicitly enabling `-fprint-explicit-foralls`:
```
λ> :set -fprint-explicit-foralls
λ> :k Foo
Foo :: forall k -> k -> *
```
This is actually a regression since GHC 8.0.2, since GHCi did the right thing by default then:
```
GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /home/rgscott/.ghci
[1 of 1] Compiling Main ( Bug.hs, interpreted )
Ok, modules loaded: Main.
λ> :k Foo
Foo :: forall k -> k -> Type
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.2.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"`:kind` suppresses visible dependent quantifiers by default in GHCi 8.2.1","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1","keywords":["TypeInType"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Load this program into GHCi on 8.2.1 or later:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE GADTs #-}\r\n{-# LANGUAGE TypeInType #-}\r\n\r\nimport Data.Kind\r\n\r\ndata Foo (k :: Type) :: k -> Type where\r\n MkFoo :: Foo (k1 -> k2) f -> Foo k1 a -> Foo k2 (f a)\r\n}}}\r\n\r\nAnd ask it what the kind of `Foo` is:\r\n\r\n{{{\r\nGHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help\r\nLoaded GHCi configuration from /home/rgscott/.ghci\r\n[1 of 1] Compiling Main ( Bug.hs, interpreted )\r\nOk, 1 module loaded.\r\nλ> :k Foo\r\nFoo :: k -> *\r\n}}}\r\n\r\nThis is just plain wrong: the actual kind of `Foo` should be `forall k -> k -> *`. Normally, one can omit `forall`s from a kind signature, but this is a special case where we're using a //visible// forall. In other words, `forall k -> k -> *` is not the same as `k -> *`, as the former takes two arguments, whereas the latter takes one.\r\n\r\nA workaround is to force GHCi to come to its senses by explicitly enabling `-fprint-explicit-foralls`:\r\n\r\n{{{\r\nλ> :set -fprint-explicit-foralls \r\nλ> :k Foo\r\nFoo :: forall k -> k -> *\r\n}}}\r\n\r\nThis is actually a regression since GHC 8.0.2, since GHCi did the right thing by default then:\r\n\r\n{{{\r\nGHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help\r\nLoaded GHCi configuration from /home/rgscott/.ghci\r\n[1 of 1] Compiling Main ( Bug.hs, interpreted )\r\nOk, modules loaded: Main.\r\nλ> :k Foo\r\nFoo :: forall k -> k -> Type\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/14970GHC.Err.errorWithoutStackTrace produces stack trace when profiling enabled2019-07-07T18:14:51ZrotaerkGHC.Err.errorWithoutStackTrace produces stack trace when profiling enabledWhen you run 'error', it shows the usual stack trace. When you enable profiling with the -prof flag to ghc, and you run 'error', it shows the usual stack trace plus an additional prof-specific stack trace.
When you run 'errorWithoutStac...When you run 'error', it shows the usual stack trace. When you enable profiling with the -prof flag to ghc, and you run 'error', it shows the usual stack trace plus an additional prof-specific stack trace.
When you run 'errorWithoutStackTrace' with profiling enabled, it strips the usual stack trace of 'error', but still displays the prof-specific stack trace.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.2.2 |
| 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":"GHC.Err.errorWithoutStackTrace produces stack trace when profiling enabled","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When you run 'error', it shows the usual stack trace. When you enable profiling with the -prof flag to ghc, and you run 'error', it shows the usual stack trace plus an additional prof-specific stack trace.\r\n\r\nWhen you run 'errorWithoutStackTrace' with profiling enabled, it strips the usual stack trace of 'error', but still displays the prof-specific stack trace.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/15158T8089 failing with ghci, threaded1, threaded2, profthreaded2019-07-07T18:14:00ZAlp MestanogullariT8089 failing with ghci, threaded1, threaded2, profthreaded```
=====> T8089(ghci) 17 of 17 [2, 16, 0]
cd "/run/user/1001/ghctest-m_wu2f4i/test spaces/../../libraries/base/tests/T8089.run" && "/home/alp/WT/ghc-slow-validate/bindisttest/install dir/bin/ghc" T8089.hs -dcore-lint -dcmm-lint -no-...```
=====> T8089(ghci) 17 of 17 [2, 16, 0]
cd "/run/user/1001/ghctest-m_wu2f4i/test spaces/../../libraries/base/tests/T8089.run" && "/home/alp/WT/ghc-slow-validate/bindisttest/install dir/bin/ghc" T8089.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output --interactive -v0 -ignore-dot-ghci -fno-ghci-history +RTS -I0.1 -RTS < T8089.genscript
Wrong exit code for T8089(ghci) (expected 99 , actual 0 )
*** unexpected failure for T8089(ghci)
=====> T8089(threaded1) 17 of 17 [2, 17, 0]
cd "/run/user/1001/ghctest-m_wu2f4i/test spaces/../../libraries/base/tests/T8089.run" && "/home/alp/WT/ghc-slow-validate/bindisttest/install dir/bin/ghc" -o T8089 T8089.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -threaded -debug
cd "/run/user/1001/ghctest-m_wu2f4i/test spaces/../../libraries/base/tests/T8089.run" && ./T8089
Wrong exit code for T8089(threaded1)(expected 99 , actual 0 )
*** unexpected failure for T8089(threaded1)
=====> T8089(threaded2) 17 of 17 [2, 18, 0]
cd "/run/user/1001/ghctest-m_wu2f4i/test spaces/../../libraries/base/tests/T8089.run" && "/home/alp/WT/ghc-slow-validate/bindisttest/install dir/bin/ghc" -o T8089 T8089.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -O -threaded -eventlog
cd "/run/user/1001/ghctest-m_wu2f4i/test spaces/../../libraries/base/tests/T8089.run" && ./T8089 +RTS -N2 -ls -RTS
Wrong exit code for T8089(threaded2)(expected 99 , actual 0 )
*** unexpected failure for T8089(threaded2)
=====> T8089(profthreaded) 17 of 17 [2, 19, 0]
cd "/run/user/1001/ghctest-m_wu2f4i/test spaces/../../libraries/base/tests/T8089.run" && "/home/alp/WT/ghc-slow-validate/bindisttest/install dir/bin/ghc" -o T8089 T8089.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -O -prof -static -fprof-auto -threaded
cd "/run/user/1001/ghctest-m_wu2f4i/test spaces/../../libraries/base/tests/T8089.run" && ./T8089 +RTS -p -RTS
Wrong exit code for T8089(profthreaded)(expected 99 , actual 0 )
*** unexpected failure for T8089(profthreaded)
```
I'm going to write a patch to expect the test to be broken in these ways, but it seems really wrong that the exit code we get is not the same accross all ways.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.5 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | #8089 |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"T8089 failing with ghci, threaded1, threaded2, profthreaded","status":"New","operating_system":"","component":"libraries/base","related":[8089],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.5","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\n=====> T8089(ghci) 17 of 17 [2, 16, 0]\r\ncd \"/run/user/1001/ghctest-m_wu2f4i/test spaces/../../libraries/base/tests/T8089.run\" && \"/home/alp/WT/ghc-slow-validate/bindisttest/install dir/bin/ghc\" T8089.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output --interactive -v0 -ignore-dot-ghci -fno-ghci-history +RTS -I0.1 -RTS < T8089.genscript\r\nWrong exit code for T8089(ghci) (expected 99 , actual 0 )\r\n*** unexpected failure for T8089(ghci)\r\n=====> T8089(threaded1) 17 of 17 [2, 17, 0]\r\ncd \"/run/user/1001/ghctest-m_wu2f4i/test spaces/../../libraries/base/tests/T8089.run\" && \"/home/alp/WT/ghc-slow-validate/bindisttest/install dir/bin/ghc\" -o T8089 T8089.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -threaded -debug \r\ncd \"/run/user/1001/ghctest-m_wu2f4i/test spaces/../../libraries/base/tests/T8089.run\" && ./T8089 \r\nWrong exit code for T8089(threaded1)(expected 99 , actual 0 )\r\n*** unexpected failure for T8089(threaded1)\r\n=====> T8089(threaded2) 17 of 17 [2, 18, 0]\r\ncd \"/run/user/1001/ghctest-m_wu2f4i/test spaces/../../libraries/base/tests/T8089.run\" && \"/home/alp/WT/ghc-slow-validate/bindisttest/install dir/bin/ghc\" -o T8089 T8089.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -O -threaded -eventlog \r\ncd \"/run/user/1001/ghctest-m_wu2f4i/test spaces/../../libraries/base/tests/T8089.run\" && ./T8089 +RTS -N2 -ls -RTS \r\nWrong exit code for T8089(threaded2)(expected 99 , actual 0 )\r\n*** unexpected failure for T8089(threaded2) \r\n=====> T8089(profthreaded) 17 of 17 [2, 19, 0]\r\ncd \"/run/user/1001/ghctest-m_wu2f4i/test spaces/../../libraries/base/tests/T8089.run\" && \"/home/alp/WT/ghc-slow-validate/bindisttest/install dir/bin/ghc\" -o T8089 T8089.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output -O -prof -static -fprof-auto -threaded \r\ncd \"/run/user/1001/ghctest-m_wu2f4i/test spaces/../../libraries/base/tests/T8089.run\" && ./T8089 +RTS -p -RTS \r\nWrong exit code for T8089(profthreaded)(expected 99 , actual 0 )\r\n*** unexpected failure for T8089(profthreaded)\r\n}}}\r\n\r\nI'm going to write a patch to expect the test to be broken in these ways, but it seems really wrong that the exit code we get is not the same accross all ways.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15225`-fno-state-hack` produces incorrect results in nofib2019-07-07T18:13:43ZTobias Dammerstdammers@gmail.com`-fno-state-hack` produces incorrect results in nofibWhile investigating #7411, I found that nofib fails with incorrect output from the `fasta` test.
A vanilla `prof` build behaves normally; however, with the following modifications, `nofib` fails:
- Compile GHC from scratch with:
> `
>...While investigating #7411, I found that nofib fails with incorrect output from the `fasta` test.
A vanilla `prof` build behaves normally; however, with the following modifications, `nofib` fails:
- Compile GHC from scratch with:
> `
> GhcStage2HcOpts = -O -fno-state-hack
> GhcLibHcOpts = -O -fno-state-hack
> `
- Run nofib with `EXTRA_HC_OPTS=-fno-state-hack`
Doing this, the nofib test output is:
```
------------------------------------------------------------------------
== make all --no-print-directory;
in /home/tobias/well-typed/devel/ghc/HEAD/nofib/shootout/fasta
------------------------------------------------------------------------
HC = /home/tobias/well-typed/devel/ghc/HEAD/inplace/bin/ghc-stage2
HC_OPTS = -O2 -Rghc-timing -H32m -hisuf hi -fno-state-hack -O2 -rtsopts -O2 -XBangPatterns -XOverloadedStrings -package bytestring
RUNTEST_OPTS = -ghc-timing
==nofib== fasta: time to compile Main follows...
/home/tobias/well-typed/devel/ghc/HEAD/inplace/bin/ghc-stage2 -O2 -Rghc-timing -H32m -hisuf hi -fno-state-hack -O2 -rtsopts -O2 -XBangPatterns -XOverloadedStrings -package bytestring -c Main.hs -o Main.o
Main.hs:30:1: warning: [-Wtabs]
Tab character found here, and in 13 further locations.
Please use spaces instead.
|
30 | let !k = min modulus (floor (fromIntegral modulus * (p::Float) + 1))
| ^^^^^^^^
<<ghc: 401958512 bytes, 72 GCs, 10720054/28796976 avg/max bytes residency (6 samples), 61M in use, 0.001 INIT (0.001 elapsed), 0.342 MUT (0.420 elapsed), 0.240 GC (0.238 elapsed) :ghc>>
==nofib== fasta: size of Main.o follows...
text data bss dec hex filename
7245 2624 0 9869 268d Main.o
==nofib== fasta: time to link fasta follows...
<<ghc: 49626024 bytes, 45 GCs, 1356153/2672728 avg/max bytes residency (5 samples), 8M in use, 0.001 INIT (0.001 elapsed), 0.025 MUT (0.468 elapsed), 0.060 GC (0.060 elapsed) :ghc>>
==nofib== fasta: size of fasta follows...
text data bss dec hex filename
708996 127712 16232 852940 d03cc fasta
==nofib== fasta: time to run fasta follows...
../../runstdtest/runstdtest ./fasta -o1 fasta.stdout -o1 fasta.stdout -ghc-timing 2500000; ../../runstdtest/runstdtest ./fasta -o1 fasta.stdout -o1 fasta.stdout -ghc-timing 2500000; ../../runstdtest/runstdtest ./fasta -o1 fasta.stdout -o1 fasta.stdout -ghc-timing 2500000; ../../runstdtest/runstdtest ./fasta -o1 fasta.stdout -o1 fasta.stdout -ghc-timing 2500000; ../../runstdtest/runstdtest ./fasta -o1 fasta.stdout -o1 fasta.stdout -ghc-timing 2500000;
0.43user 0.02system 0:00.45elapsed 99%CPU (0avgtext+0avgdata 4824maxresident)k
0inputs+49656outputs (0major+608minor)pagefaults 0swaps
././fasta 2500000 < /dev/null
expected stdout not matched by reality
--- fasta.stdout 2018-06-02 03:00:43.887025433 +0200
+++ /tmp/runtest4673.1 2018-06-02 03:09:19.651755697 +0200
@@ -83337,333335 +83337,333335 @@
cttBtatcatatgctaKggNcataaaSatgtaaaDcDRtBggDtctttataattcBgtcg
-tactDtDagcctatttSVHtHttKtgtHMaSattgWaHKHttttagacatWatgtRgaaa
-NtactMcSMtYtcMgRtacttctWBacgaaatatagScDtttgaagacacatagtVgYgt
-cattHWtMMWcStgttaggKtSgaYaaccWStcgBttgcgaMttBYatcWtgacaYcaga
-gtaBDtRacttttcWatMttDBcatWtatcttactaBgaYtcttgttttttttYaaScYa
-HgtgttNtSatcMtcVaaaStccRcctDaataataStcYtRDSaMtDttgttSagtRRca
#### ~3.1 million similar lines follow ####
-taatataagctgcgccaggggatttttccagatcatctggcctgtgtatatgttcaaatc
+gacgaatatattagttatagtttactatccaaataaattaagcgaatcgaaataaactgt
+gacgaatatattagttatagtttactatccaaataaattaagcgaatcgaaataaactgt
+gacgaatatattagttatagtttactatccaaataaattaagcgaatcgaaataaactgt
#### ~208k identical lines follow
+gacgaatatattagttatagtttactatccaaataaattaagcgaatcgaaataaactgt
taatagccgagagaaattac
../../mk/target.mk:101: recipe for target 'runtests' failed
make[2]: *** [runtests] Error 1
Failed making all in fasta: 1
../mk/ghc-recurse.mk:65: recipe for target 'all' failed
make[1]: *** [all] Error 1
Failed making all in shootout: 1
mk/ghc-recurse.mk:65: recipe for target 'all' failed
make: *** [all] Error 1
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.5 |
| 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":"`-fno-state-hack` produces incorrect results in nofib","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.5","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"While investigating #7411, I found that nofib fails with incorrect output from the `fasta` test.\r\n\r\nA vanilla `prof` build behaves normally; however, with the following modifications, `nofib` fails:\r\n\r\n- Compile GHC from scratch with:\r\n {{{\r\n GhcStage2HcOpts = -O -fno-state-hack\r\n GhcLibHcOpts = -O -fno-state-hack\r\n }}}\r\n- Run nofib with `EXTRA_HC_OPTS=-fno-state-hack`\r\n\r\nDoing this, the nofib test output is:\r\n{{{\r\n------------------------------------------------------------------------\r\n== make all --no-print-directory;\r\n in /home/tobias/well-typed/devel/ghc/HEAD/nofib/shootout/fasta\r\n------------------------------------------------------------------------\r\nHC = /home/tobias/well-typed/devel/ghc/HEAD/inplace/bin/ghc-stage2\r\nHC_OPTS = -O2 -Rghc-timing -H32m -hisuf hi -fno-state-hack -O2 -rtsopts -O2 -XBangPatterns -XOverloadedStrings -package bytestring\r\nRUNTEST_OPTS = -ghc-timing\r\n==nofib== fasta: time to compile Main follows...\r\n/home/tobias/well-typed/devel/ghc/HEAD/inplace/bin/ghc-stage2 -O2 -Rghc-timing -H32m -hisuf hi -fno-state-hack -O2 -rtsopts -O2 -XBangPatterns -XOverloadedStrings -package bytestring -c Main.hs -o Main.o\r\n\r\nMain.hs:30:1: warning: [-Wtabs]\r\n Tab character found here, and in 13 further locations.\r\n Please use spaces instead.\r\n |\r\n30 | let !k = min modulus (floor (fromIntegral modulus * (p::Float) + 1))\r\n | ^^^^^^^^\r\n<<ghc: 401958512 bytes, 72 GCs, 10720054/28796976 avg/max bytes residency (6 samples), 61M in use, 0.001 INIT (0.001 elapsed), 0.342 MUT (0.420 elapsed), 0.240 GC (0.238 elapsed) :ghc>>\r\n==nofib== fasta: size of Main.o follows...\r\n text\t data\t bss\t dec\t hex\tfilename\r\n 7245\t 2624\t 0\t 9869\t 268d\tMain.o\r\n==nofib== fasta: time to link fasta follows...\r\n<<ghc: 49626024 bytes, 45 GCs, 1356153/2672728 avg/max bytes residency (5 samples), 8M in use, 0.001 INIT (0.001 elapsed), 0.025 MUT (0.468 elapsed), 0.060 GC (0.060 elapsed) :ghc>>\r\n==nofib== fasta: size of fasta follows...\r\n text\t data\t bss\t dec\t hex\tfilename\r\n 708996\t 127712\t 16232\t 852940\t d03cc\tfasta\r\n==nofib== fasta: time to run fasta follows...\r\n../../runstdtest/runstdtest ./fasta -o1 fasta.stdout -o1 fasta.stdout -ghc-timing 2500000; ../../runstdtest/runstdtest ./fasta -o1 fasta.stdout -o1 fasta.stdout -ghc-timing 2500000; ../../runstdtest/runstdtest ./fasta -o1 fasta.stdout -o1 fasta.stdout -ghc-timing 2500000; ../../runstdtest/runstdtest ./fasta -o1 fasta.stdout -o1 fasta.stdout -ghc-timing 2500000; ../../runstdtest/runstdtest ./fasta -o1 fasta.stdout -o1 fasta.stdout -ghc-timing 2500000;\r\n0.43user 0.02system 0:00.45elapsed 99%CPU (0avgtext+0avgdata 4824maxresident)k\r\n0inputs+49656outputs (0major+608minor)pagefaults 0swaps\r\n././fasta 2500000 < /dev/null\r\nexpected stdout not matched by reality\r\n--- fasta.stdout\t2018-06-02 03:00:43.887025433 +0200\r\n+++ /tmp/runtest4673.1\t2018-06-02 03:09:19.651755697 +0200\r\n@@ -83337,333335 +83337,333335 @@\r\n cttBtatcatatgctaKggNcataaaSatgtaaaDcDRtBggDtctttataattcBgtcg\r\n-tactDtDagcctatttSVHtHttKtgtHMaSattgWaHKHttttagacatWatgtRgaaa\r\n-NtactMcSMtYtcMgRtacttctWBacgaaatatagScDtttgaagacacatagtVgYgt\r\n-cattHWtMMWcStgttaggKtSgaYaaccWStcgBttgcgaMttBYatcWtgacaYcaga\r\n-gtaBDtRacttttcWatMttDBcatWtatcttactaBgaYtcttgttttttttYaaScYa\r\n-HgtgttNtSatcMtcVaaaStccRcctDaataataStcYtRDSaMtDttgttSagtRRca\r\n#### ~3.1 million similar lines follow ####\r\n-taatataagctgcgccaggggatttttccagatcatctggcctgtgtatatgttcaaatc\r\n+gacgaatatattagttatagtttactatccaaataaattaagcgaatcgaaataaactgt\r\n+gacgaatatattagttatagtttactatccaaataaattaagcgaatcgaaataaactgt\r\n+gacgaatatattagttatagtttactatccaaataaattaagcgaatcgaaataaactgt\r\n#### ~208k identical lines follow\r\n+gacgaatatattagttatagtttactatccaaataaattaagcgaatcgaaataaactgt\r\n taatagccgagagaaattac\r\n../../mk/target.mk:101: recipe for target 'runtests' failed\r\nmake[2]: *** [runtests] Error 1\r\nFailed making all in fasta: 1\r\n../mk/ghc-recurse.mk:65: recipe for target 'all' failed\r\nmake[1]: *** [all] Error 1\r\nFailed making all in shootout: 1\r\nmk/ghc-recurse.mk:65: recipe for target 'all' failed\r\nmake: *** [all] Error 1\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Tobias Dammerstdammers@gmail.comTobias Dammerstdammers@gmail.comhttps://gitlab.haskell.org/ghc/ghc/-/issues/15301Regression in Natural desugaring2019-07-07T18:13:22ZSylvain HenryRegression in Natural desugaringMy recent merged patch "Built-in Natural literals in Core" https://phabricator.haskell.org/rGHCfe770c211631e7b4c9b0b1e88ef9b6046c6585ef introduced a regression when desugaring large numbers.
Patch coming.
<details><summary>Trac metadat...My recent merged patch "Built-in Natural literals in Core" https://phabricator.haskell.org/rGHCfe770c211631e7b4c9b0b1e88ef9b6046c6585ef introduced a regression when desugaring large numbers.
Patch coming.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Regression in Natural desugaring","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"My recent merged patch \"Built-in Natural literals in Core\" https://phabricator.haskell.org/rGHCfe770c211631e7b4c9b0b1e88ef9b6046c6585ef introduced a regression when desugaring large numbers.\r\n\r\nPatch coming.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15349fixST is a bit wrong2019-07-07T18:13:03ZDavid FeuerfixST is a bit wrongLazy blackholing lets some `ST` calculations complete that shouldn't.
```hs
import Control.Monad.ST.Strict
import Control.Monad.Fix
import Data.STRef
foo :: ST s Int
foo = do
ref <- newSTRef True
mfix $ \res -> do
x <- readSTRe...Lazy blackholing lets some `ST` calculations complete that shouldn't.
```hs
import Control.Monad.ST.Strict
import Control.Monad.Fix
import Data.STRef
foo :: ST s Int
foo = do
ref <- newSTRef True
mfix $ \res -> do
x <- readSTRef ref
if x
then do
writeSTRef ref False
return $! (res + 5)
else return 10
main = print $ runST foo
```
When this is compiled with `-O -feager-blackholing`, it produces a `<<loop>>` exception as expected. When it's compiled with `-O0` or with `-fno-eager-blackholing`, it prints `15`.
Should we reimplement `fixST` to do something like what `fixIO` does? Or should we consider this sometimes-lost bottom tolerable?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.5 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Core Libraries |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | simonmar |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"fixST is a bit wrong","status":"New","operating_system":"","component":"Core Libraries","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.5","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["simonmar"],"type":"Bug","description":"Lazy blackholing lets some `ST` calculations complete that shouldn't.\r\n\r\n{{{#!hs\r\nimport Control.Monad.ST.Strict\r\nimport Control.Monad.Fix\r\nimport Data.STRef\r\n\r\nfoo :: ST s Int\r\nfoo = do\r\n ref <- newSTRef True\r\n mfix $ \\res -> do\r\n x <- readSTRef ref\r\n if x\r\n then do\r\n writeSTRef ref False\r\n return $! (res + 5)\r\n else return 10\r\n\r\nmain = print $ runST foo\r\n}}}\r\n\r\nWhen this is compiled with `-O -feager-blackholing`, it produces a `<<loop>>` exception as expected. When it's compiled with `-O0` or with `-fno-eager-blackholing`, it prints `15`.\r\n\r\nShould we reimplement `fixST` to do something like what `fixIO` does? Or should we consider this sometimes-lost bottom tolerable?","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1David FeuerDavid Feuerhttps://gitlab.haskell.org/ghc/ghc/-/issues/15553GHC.IO.Encoding not flushing partially converted input2019-07-07T18:04:10ZMasahiro SakaiGHC.IO.Encoding not flushing partially converted inputConversion by `GHC.IO.Encoding` produces incomplete output for some encodings because it does not flush *partially converted input* at the end of the string.
[iconv(3)](https://manpages.debian.org/stretch/manpages-dev/iconv.3) provides ...Conversion by `GHC.IO.Encoding` produces incomplete output for some encodings because it does not flush *partially converted input* at the end of the string.
[iconv(3)](https://manpages.debian.org/stretch/manpages-dev/iconv.3) provides API for the flushing.
> In each series of calls to iconv(), the last should be one with inbuf or \*inbuf equal to NULL, in order to flush out any partially converted input.
But `GHC.IO.Encoding` does not perform the flushing properly and it can cause incomplete conversion result.
I found two cases that it actually produces incomplete output, but there might be more cases.
# Case 1: EUC-JISX0213
For example, the following code is expected to output two bytes 0xa4 0xb1, but it outputs none.
```hs
enc <- mkTextEncoding "EUC-JISX0213"
withFile "test.txt" WriteMode $ \h -> hSetEncoding h enc >> hPutStr h "\x3051"
```
The problem happens because of the following mapping between Unicode and EUC-JISX0213.
<table><tr><td>Unicode</td>
<td>EUC-JISX0213</td></tr>
<tr><td>U+3051 U+309A</td>
<td>0xa4 0xfa</td></tr>
<tr><td>U+3051</td>
<td>0xa4 0xb1</td></tr></table>
After seeing the codepoint U+3051, the converter is unable to determine which of the two byte sequence to output until it sees the next character or *the end of the string*. But `GHC.IO.Encoding` does not call the above mentioned *flushing* API, therefore the converter is unable to recognize the end of the string.
# Case 2: ISO-2022-JP
Similarly, following code is expected to output byte sequence `0x1b 0x24 0x42` `0x24 0x22` `0x1b 0x28 0x42` but the last three bytes `0x1b 0x28 0x42` is not produced.
```hs
enc <- mkTextEncoding "ISO-2022-JP"
withFile "test.txt" WriteMode $ \h -> hSetEncoding h enc >> hPutStr h "\x3042"
```
ISO-2022-JP is a stateful encoding and [RFC 1468](https://www.ietf.org/rfc/rfc1468.txt) requires the state is reset to initial state at the end of the string. The missing three bytes `0x1b 0x28 0x42` are the escape sequence for that purpose. But again `GHC.IO.Encoding` does not call the above mentioned`flushing` API, therefore the converter cannot recognize the end of the string and cannot reset the state.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Core Libraries |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC.IO.Encoding not flushing partially converted input","status":"New","operating_system":"","component":"Core Libraries","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Conversion by `GHC.IO.Encoding` produces incomplete output for some encodings because it does not flush ''partially converted input'' at the end of the string.\r\n\r\n[https://manpages.debian.org/stretch/manpages-dev/iconv.3 iconv(3)] provides API for the flushing.\r\n\r\n> In each series of calls to iconv(), the last should be one with inbuf or *inbuf equal to NULL, in order to flush out any partially converted input.\r\n\r\nBut `GHC.IO.Encoding` does not perform the flushing properly and it can cause incomplete conversion result.\r\nI found two cases that it actually produces incomplete output, but there might be more cases.\r\n\r\n= Case 1: EUC-JISX0213\r\n\r\nFor example, the following code is expected to output two bytes 0xa4 0xb1, but it outputs none.\r\n\r\n{{{#!hs\r\nenc <- mkTextEncoding \"EUC-JISX0213\"\r\nwithFile \"test.txt\" WriteMode $ \\h -> hSetEncoding h enc >> hPutStr h \"\\x3051\"\r\n}}}\r\n\r\nThe problem happens because of the following mapping between Unicode and EUC-JISX0213. \r\n\r\n||Unicode||EUC-JISX0213||\r\n||U+3051 U+309A||0xa4 0xfa||\r\n||U+3051||0xa4 0xb1||\r\n\r\nAfter seeing the codepoint U+3051, the converter is unable to determine which of the two byte sequence to output until it sees the next character or ''the end of the string''. But `GHC.IO.Encoding` does not call the above mentioned ''flushing'' API, therefore the converter is unable to recognize the end of the string.\r\n\r\n= Case 2: ISO-2022-JP\r\n\r\nSimilarly, following code is expected to output byte sequence `0x1b 0x24 0x42` `0x24 0x22` `0x1b 0x28 0x42` but the last three bytes `0x1b 0x28 0x42` is not produced. \r\n\r\n{{{#!hs\r\nenc <- mkTextEncoding \"ISO-2022-JP\"\r\nwithFile \"test.txt\" WriteMode $ \\h -> hSetEncoding h enc >> hPutStr h \"\\x3042\"\r\n}}}\r\n\r\nISO-2022-JP is a stateful encoding and [https://www.ietf.org/rfc/rfc1468.txt RFC 1468] requires the state is reset to initial state at the end of the string. The missing three bytes `0x1b 0x28 0x42` are the escape sequence for that purpose. But again `GHC.IO.Encoding` does not call the above mentioned`flushing` API, therefore the converter cannot recognize the end of the string and cannot reset the state.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1