GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:47:23Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/7934usleep hangs, no threads2019-07-07T18:47:23Zgelisamusleep hangs, no threadsimport System.Posix.Unistd
main = flip mapM_ \[0..\] $ \\i -\> do
usleep 100000
> print i
###
The above program hangs after a variable number of iterations (usually around 120, sometimes up to 200, often before the first call to pr...import System.Posix.Unistd
main = flip mapM_ \[0..\] $ \\i -\> do
usleep 100000
> print i
###
The above program hangs after a variable number of iterations (usually around 120, sometimes up to 200, often before the first call to print).
The documentation for usleep warns about bad interactions with threads, but the above program doesn't use any.
The problem also occurs with nanosleep, but not with threadDelay.
#1156 sounds related, but this time the problem also occurs without -threaded.
###
workaround: use threadDelay.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.4.2 |
| 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":"usleep hangs, no threads","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.4.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"import System.Posix.Unistd\r\nmain = flip mapM_ [0..] $ \\i -> do\r\n usleep 100000\r\n print i\r\n\r\n===\r\n\r\nThe above program hangs after a variable number of iterations (usually around 120, sometimes up to 200, often before the first call to print).\r\n\r\nThe documentation for usleep warns about bad interactions with threads, but the above program doesn't use any.\r\n\r\nThe problem also occurs with nanosleep, but not with threadDelay.\r\n\r\n#1156 sounds related, but this time the problem also occurs without -threaded.\r\n\r\n===\r\n\r\nworkaround: use threadDelay.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/7930Nested STM Invariants are lost2019-07-07T18:47:24ZRyan YatesNested STM Invariants are lostInvariants from a successful nested transaction should be merged with the parent.
```
import Control.Concurrent
import Control.Concurrent.STM
main = do
x <- atomically $
do a <- newTVar True
(always (readTVar a) ...Invariants from a successful nested transaction should be merged with the parent.
```
import Control.Concurrent
import Control.Concurrent.STM
main = do
x <- atomically $
do a <- newTVar True
(always (readTVar a) >> retry) `orElse` return ()
return a
atomically (writeTVar x False) -- Should not and does not fail
y <- atomically $
do a <- newTVar True
always (readTVar a) `orElse` return ()
return a
atomically (writeTVar y False) -- Should fail, but does not!
putStrLn "Ahhh!"
z <- atomically $
do a <- newTVar True
always (readTVar a)
return a
atomically (writeTVar z False) -- should and does fail
```
I know how to fix this. I'll have a patch with some tests and a fix soon.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.6.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Nested STM Invariants are lost","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"fryguybob"},"version":"7.6.3","keywords":["STM"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Invariants from a successful nested transaction should be merged with the parent.\r\n\r\n{{{\r\nimport Control.Concurrent\r\nimport Control.Concurrent.STM\r\n\r\nmain = do\r\n x <- atomically $\r\n do a <- newTVar True\r\n (always (readTVar a) >> retry) `orElse` return ()\r\n return a\r\n atomically (writeTVar x False) -- Should not and does not fail\r\n\r\n y <- atomically $\r\n do a <- newTVar True\r\n always (readTVar a) `orElse` return ()\r\n return a\r\n atomically (writeTVar y False) -- Should fail, but does not!\r\n\r\n putStrLn \"Ahhh!\"\r\n\r\n z <- atomically $\r\n do a <- newTVar True\r\n always (readTVar a)\r\n return a\r\n atomically (writeTVar z False) -- should and does fail\r\n}}}\r\n\r\nI know how to fix this. I'll have a patch with some tests and a fix soon.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1Ryan YatesRyan Yateshttps://gitlab.haskell.org/ghc/ghc/-/issues/7910ConstraintKinds and reifyInstances2019-07-07T18:47:32ZtrevorConstraintKinds and reifyInstancesreifyInstances doesn't appear to know how to deal with a constraint that is just an alias. For example, the following prints (True,False):
```
{-# LANGUAGE ConstraintKinds #-}
{-# LANGUAGE TemplateHaskell #-}
import Language.Haskell.TH...reifyInstances doesn't appear to know how to deal with a constraint that is just an alias. For example, the following prints (True,False):
```
{-# LANGUAGE ConstraintKinds #-}
{-# LANGUAGE TemplateHaskell #-}
import Language.Haskell.TH
import Language.Haskell.TH.Syntax
class C a
instance C Int
type D a = C a
main = print $(
do isCInst <- isInstance ''C [ConT ''Int]
isDInst <- isInstance ''D [ConT ''Int]
lift (isCInst,isDInst))
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.6.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ConstraintKinds and reifyInstances","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.3","keywords":["ConstraintKinds,","TemplateHaskell"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"reifyInstances doesn't appear to know how to deal with a constraint that is just an alias. For example, the following prints (True,False):\r\n\r\n\r\n{{{\r\n{-# LANGUAGE ConstraintKinds #-}\r\n{-# LANGUAGE TemplateHaskell #-}\r\n\r\nimport Language.Haskell.TH\r\nimport Language.Haskell.TH.Syntax\r\n\r\nclass C a\r\ninstance C Int\r\n\r\ntype D a = C a\r\n\r\nmain = print $(\r\n do isCInst <- isInstance ''C [ConT ''Int]\r\n isDInst <- isInstance ''D [ConT ''Int]\r\n lift (isCInst,isDInst))\r\n\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/7899Strange behavior of -ddump-minimal-imports2019-07-07T18:47:37ZdsfStrange behavior of -ddump-minimal-importsThe following two line module:
```
import System.Exit
main = undefined >>= undefined
```
when compiled with `ghc -c -ddump-minimal-imports Test.hs` produces the following in Main.imports:
```
import System.Exit ( (>>=), undefined )
``...The following two line module:
```
import System.Exit
main = undefined >>= undefined
```
when compiled with `ghc -c -ddump-minimal-imports Test.hs` produces the following in Main.imports:
```
import System.Exit ( (>>=), undefined )
```
Those symbols are not exported by System.Exit.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.6.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Strange behavior of -ddump-minimal-imports","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The following two line module:\r\n\r\n{{{\r\nimport System.Exit\r\nmain = undefined >>= undefined\r\n}}}\r\n\r\nwhen compiled with {{{ghc -c -ddump-minimal-imports Test.hs}}} produces the following in Main.imports:\r\n{{{\r\nimport System.Exit ( (>>=), undefined )\r\n}}}\r\nThose symbols are not exported by System.Exit.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/7877hSetBuffering002(ghci) and hSetBuffering004(ghci) fail on OS X2019-07-07T18:47:43ZnfrisbyhSetBuffering002(ghci) and hSetBuffering004(ghci) fail on OS X```
$ make TESTS="hSetBuffering002 hSetBuffering004"
# ... snip ...
Unexpected failures:
../../libraries/base/tests/IO hSetBuffering002 [bad exit code] (ghci)
../../libraries/base/tests/IO hSetBuffering004 [bad stdout or stderr] ...```
$ make TESTS="hSetBuffering002 hSetBuffering004"
# ... snip ...
Unexpected failures:
../../libraries/base/tests/IO hSetBuffering002 [bad exit code] (ghci)
../../libraries/base/tests/IO hSetBuffering004 [bad stdout or stderr] (ghci)
```
For 002, there's a stderror message: `<stdin>: hGetLine: illegal operation (handle is closed)`
For 004, it seems like ghci is trying to parse the part of the .genscript file that the program is supposed to use as stdin.
I'm on OS X 10.7.5
```
ghc : ade1ae97ed52c493ec415c1601dace39b64071dd
testsuite : 743cab5865ae0b9820dadc33a692511e0e467b9b
base : b3387abfbc94b69e977c232386acad4dde7597e8
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.6.3 |
| 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":"hSetBuffering002(ghci) and hSetBuffering004(ghci) fail on OS X","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\n$ make TESTS=\"hSetBuffering002 hSetBuffering004\"\r\n# ... snip ...\r\nUnexpected failures:\r\n ../../libraries/base/tests/IO hSetBuffering002 [bad exit code] (ghci)\r\n ../../libraries/base/tests/IO hSetBuffering004 [bad stdout or stderr] (ghci)\r\n}}}\r\n\r\nFor 002, there's a stderror message: `<stdin>: hGetLine: illegal operation (handle is closed)`\r\n\r\nFor 004, it seems like ghci is trying to parse the part of the .genscript file that the program is supposed to use as stdin.\r\n\r\nI'm on OS X 10.7.5\r\n\r\n{{{\r\nghc : ade1ae97ed52c493ec415c1601dace39b64071dd\r\ntestsuite : 743cab5865ae0b9820dadc33a692511e0e467b9b\r\nbase : b3387abfbc94b69e977c232386acad4dde7597e8\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/7876hClose002 for ghci hangs on Mac OS X2019-07-07T18:47:43ZnfrisbyhClose002 for ghci hangs on Mac OS XI'm on OS X 10.7.5
```
ghc : ade1ae97ed52c493ec415c1601dace39b64071dd
testsuite : 743cab5865ae0b9820dadc33a692511e0e467b9b
base : b3387abfbc94b69e977c232386acad4dde7597e8
```
hClose002 fails with these three ways:
```
$ make TESTS=hCl...I'm on OS X 10.7.5
```
ghc : ade1ae97ed52c493ec415c1601dace39b64071dd
testsuite : 743cab5865ae0b9820dadc33a692511e0e467b9b
base : b3387abfbc94b69e977c232386acad4dde7597e8
```
hClose002 fails with these three ways:
```
$ make TESTS=hClose002
# ... snip ...
Unexpected failures:
../../libraries/base/tests/IO hClose002 [bad exit code] (ghci,threaded1,threaded2)
```
The test opens a file in !WriteMode, closes it "without telling the IO library", then hCloses it twice. Then it does that again in !ReadMode. Thus there are four hClose calls in total. It is the third one that hangs.https://gitlab.haskell.org/ghc/ghc/-/issues/7866floor (0/0) :: Int is different with -O0 and -O12019-07-07T18:47:45ZAlex Langfloor (0/0) :: Int is different with -O0 and -O1This program:
```
main = print (floor (0/0) :: Int)
```
prints a different result with -O0:
```
0
```
and -O1:
```
-9223372036854775808
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ----...This program:
```
main = print (floor (0/0) :: Int)
```
prints a different result with -O0:
```
0
```
and -O1:
```
-9223372036854775808
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.6.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"floor (0/0) :: Int is different with -O0 and -O1","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This program:\r\n{{{\r\nmain = print (floor (0/0) :: Int)\r\n}}}\r\n\r\nprints a different result with -O0:\r\n{{{\r\n0\r\n}}}\r\nand -O1:\r\n{{{\r\n-9223372036854775808\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/7853UTF encodings do not detect overlong forms2019-07-07T18:47:48ZbatterseapowerUTF encodings do not detect overlong formsOverlong UTF-{8,16} sequences can have security implications (http://www.cl.cam.ac.uk/\~mgk25/unicode.html). Decoders for these encodings should detect them and flag them as invalid characters. GHC's implementations of these decoders do ...Overlong UTF-{8,16} sequences can have security implications (http://www.cl.cam.ac.uk/\~mgk25/unicode.html). Decoders for these encodings should detect them and flag them as invalid characters. GHC's implementations of these decoders do not do so!
This problem has additional implications for GHC since as we are not rejecting overlong sequences, trying to roundtrip 0xC0 0xB1 through UTF-8//ROUNDTRIP results in 0x31 rather than the expected sequence. The roundtripping fails because the overlong sequence is not flagged up by the UTF-8 encoder and so the surrogate escape mechanism never gets a chance to work.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.6.3 |
| 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":"UTF encodings do not detect overlong forms","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Overlong UTF-{8,16} sequences can have security implications (http://www.cl.cam.ac.uk/~mgk25/unicode.html). Decoders for these encodings should detect them and flag them as invalid characters. GHC's implementations of these decoders do not do so!\r\n\r\nThis problem has additional implications for GHC since as we are not rejecting overlong sequences, trying to roundtrip 0xC0 0xB1 through UTF-8//ROUNDTRIP results in 0x31 rather than the expected sequence. The roundtripping fails because the overlong sequence is not flagged up by the UTF-8 encoder and so the surrogate escape mechanism never gets a chance to work.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/7839After forkIO'ing on Intel Mac, putStrLn (presumably) reports "hPutChar: faile...2019-07-07T18:47:52ZthorkilnaurAfter forkIO'ing on Intel Mac, putStrLn (presumably) reports "hPutChar: failed (Operation not supported)"Investigating #7715 on the tn23 builder, which is
```
$ uname -a
Darwin thorkil-naurs-intel-mac-mini.local 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386
$
```
I ran into:
```
...Investigating #7715 on the tn23 builder, which is
```
$ uname -a
Darwin thorkil-naurs-intel-mac-mini.local 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386
$
```
I ran into:
```
$ cat T7715O.hs
import Control.Monad
import Control.Concurrent
import System.IO
import System.Environment
main' c d2 = do
replicateM_ c $ forkIO $ do
putStrLn "Hello, world!"
threadDelay d2
mainArgsInterpret [cS,d2S] = main' (read cS) (read d2S)
main :: IO ()
main
= do
hSetBuffering stdout NoBuffering
hSetBuffering stderr NoBuffering
args <- getArgs
mainArgsInterpret args
$ /Users/thorkilnaur/tn/builders/GHCBuilder/tn23/builder/tempbuild/build/inplace/bin/ghc-stage2 --make T7715O.hs -threaded -debug -rtsopts
[1 of 1] Compiling Main ( T7715O.hs, T7715O.o )
Linking T7715O ...
$ ./T7715O 25 10000000
Hello, world!
Hello, world!
Hello, world!
Hello, world!
Hello, world!
Hello, world!
Hello, world!
Hello, world!
Hello, world!
Hello, world!
Hello, world!
Hello, world!
Hello, world!
Hello, world!
Hello, world!
Hello, world!
Hello, world!
Hello, world!
Hello, world!
Hello, world!
Hello, world!
Hello, world!
Hello, world!
HeT7715O: <stdout>: hPutChar: failed (Operation not supported)
T7715O: <stdout>: hPutChar: failed (Operation not supported)
$
```
This doesn't happen on
```
$ uname -a
Linux tn24 3.2.0-39-generic #62-Ubuntu SMP Wed Feb 27 22:05:17 UTC 2013 i686 i686 i386 GNU/Linux
$
```
Best regards
Thorkil
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"After forkIO'ing on Intel Mac, putStrLn (presumably) reports \"hPutChar: failed (Operation not supported)\"","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Investigating #7715 on the tn23 builder, which is\r\n{{{\r\n$ uname -a\r\nDarwin thorkil-naurs-intel-mac-mini.local 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386\r\n$ \r\n}}}\r\nI ran into:\r\n{{{\r\n$ cat T7715O.hs \r\nimport Control.Monad\r\nimport Control.Concurrent\r\nimport System.IO\r\nimport System.Environment\r\n\r\nmain' c d2 = do\r\n replicateM_ c $ forkIO $ do\r\n putStrLn \"Hello, world!\"\r\n threadDelay d2\r\n\r\nmainArgsInterpret [cS,d2S] = main' (read cS) (read d2S)\r\n\r\nmain :: IO ()\r\nmain\r\n = do\r\n hSetBuffering stdout NoBuffering\r\n hSetBuffering stderr NoBuffering\r\n args <- getArgs\r\n mainArgsInterpret args\r\n$ /Users/thorkilnaur/tn/builders/GHCBuilder/tn23/builder/tempbuild/build/inplace/bin/ghc-stage2 --make T7715O.hs -threaded -debug -rtsopts \r\n[1 of 1] Compiling Main ( T7715O.hs, T7715O.o )\r\nLinking T7715O ...\r\n$ ./T7715O 25 10000000 \r\nHello, world!\r\nHello, world!\r\nHello, world!\r\nHello, world!\r\nHello, world!\r\nHello, world!\r\nHello, world!\r\nHello, world!\r\nHello, world!\r\nHello, world!\r\nHello, world!\r\nHello, world!\r\nHello, world!\r\nHello, world!\r\nHello, world!\r\nHello, world!\r\nHello, world!\r\nHello, world!\r\nHello, world!\r\nHello, world!\r\nHello, world!\r\nHello, world!\r\nHello, world!\r\nHeT7715O: <stdout>: hPutChar: failed (Operation not supported)\r\nT7715O: <stdout>: hPutChar: failed (Operation not supported)\r\n$\r\n}}}\r\nThis doesn't happen on\r\n{{{\r\n$ uname -a\r\nLinux tn24 3.2.0-39-generic #62-Ubuntu SMP Wed Feb 27 22:05:17 UTC 2013 i686 i686 i386 GNU/Linux\r\n$ \r\n}}}\r\nBest regards\r\nThorkil\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/7815STM fails to validate read.2020-01-29T16:18:56ZRyan YatesSTM fails to validate read.This issue was brought up by napping in `#haskell` with this paste:
[http://hpaste.org/85134](http://hpaste.org/85134) (the first paste in particular)
The code is:
```
import Control.Concurrent.STM
import Control.Concurrent
import Con...This issue was brought up by napping in `#haskell` with this paste:
[http://hpaste.org/85134](http://hpaste.org/85134) (the first paste in particular)
The code is:
```
import Control.Concurrent.STM
import Control.Concurrent
import Control.Monad
main = do
dog <- newTVarIO False
cat <- newTVarIO False
let unset = do
d <- readTVar dog
c <- readTVar cat
if (d || c) then retry else return ()
setDog = unset >> writeTVar dog True
setCat = unset >> writeTVar cat True
oops = do
d <- readTVar dog
c <- readTVar cat
guard (d && c)
reset = do
writeTVar dog False
writeTVar cat False
reset' = do
d <- readTVar dog
c <- readTVar cat
guard (d || c)
reset
forkIO (atomically oops >> putStrLn "Oh Noes!")
forever (do
forkIO (atomically setDog)
forkIO (atomically setCat)
atomically reset'
atomically reset')
```
When run it produces:
```
$ ghc --make test.hs -threaded -rtsopts
$ ./test +RTS -N2
Oh Noes!
test: thread blocked indefinitely in an STM transaction
```
The second message is just a consequence of entering an unexpected state. The first message indicates that both the transactions `cat` and `dog` committed at the same time.
It does this for HEAD and 7.6.
I've sketched out an interleaving that leads to this. TRec entries
are in the first and third column and TVar's are in the second column. Each entry has a TVar name and the expected value followed
by the new value and then a number of updates if it has been read. TVars list their value and their number of updates.
```
A TRec TVar B TRec
-- Transactions start
cat F F cat F 0 cat F F -- Initial reads.
dog F F dog F 0 dog F F
cat F T dog F T -- Local writes in TRec's
-- Validation:
cat F F 0 -- B reads num_updates from cat (with
^ -- consistency check with value)
cat F T cat A 0 | -- A acquires lock for cat (atomic cas)
dog F F 0 ^ | -- A reads num_updates from dog (with
^ | | -- consistency check with value)
| dog B 0 dog F T | -- B acquires lock for dog (atomic cas)
| | ^ |
| | | |
Success 0 | 0 | -- read check for A
Success 0 0 -- read check for B
cat A 1 -- Increment version
cat T 1 -- Unlock with new value
dog B 1 -- Increment version
dog B T -- Unlock with new value
```
What is clear here is that the version number is not enough to check
in `check_read_only` because there is a gap between locking and
incrementing the version. We need to know atomically that the TVar is not locked and it's version number is the same.
I need to read through the right parts of Keir Fraser's thesis carefully, but it seems like the read phase here is only helpful in preventing a commit that writes back the exact value we have already seen while we are in the middle of committing.
The code for `check_read_only` is here:
```c
static StgBool check_read_only(StgTRecHeader *trec STG_UNUSED) {
StgBool result = TRUE;
ASSERT (config_use_read_phase);
IF_STM_FG_LOCKS({
FOR_EACH_ENTRY(trec, e, {
StgTVar *s;
s = e -> tvar;
if (entry_is_read_only(e)) {
TRACE("%p : check_read_only for TVar %p, saw %ld", trec, s, e -> num_updates);
if (s -> num_updates != e -> num_updates) {
// ||s -> current_value != e -> expected_value) {
TRACE("%p : mismatch", trec);
result = FALSE;
BREAK_FOR_EACH;
}
}
});
});
return result;
}
```
If I restore the commented out line (which appears commented out in the first commit of this code that I can find) I can't reproduce the issue, but I think there is still a problem due to the ordering of
those checks: we could observe the version as the same, while it
is locked, have the TVar unlock, then observe the value the same.
Switching the order we can only observe the TVar unlocked if the
update has been incremented (as long as we are on an architecture
that ensures this such as x86).
Does this seem right? One issue is that given the interleaving that above with this added check *both* transactions could fail to commit. I think the algorithms from Fraser avoid this, but I think it always involves invalidating another transaction (i.e. killing off any other transactions observed to be in the read check phase with an overlapping TVar in a way that results in only one winner (see page 21 section 4.4 in *Concurrent Programming Without Locks*)).
As a side note, the issue can be avoided by ensuring that the reads become writes and avoiding the read only check. But you can only
become a write if the values do not have matching pointers, switching to Ints instead of Bools gets you there.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"STM fails to validate read.","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.7","keywords":["STM"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This issue was brought up by napping in {{{#haskell}}} with this paste:\r\n\r\n[http://hpaste.org/85134] (the first paste in particular)\r\n\r\nThe code is:\r\n\r\n{{{\r\nimport Control.Concurrent.STM\r\nimport Control.Concurrent\r\nimport Control.Monad\r\n\r\nmain = do\r\n dog <- newTVarIO False\r\n cat <- newTVarIO False\r\n let unset = do\r\n d <- readTVar dog\r\n c <- readTVar cat\r\n if (d || c) then retry else return ()\r\n setDog = unset >> writeTVar dog True\r\n setCat = unset >> writeTVar cat True\r\n oops = do\r\n d <- readTVar dog\r\n c <- readTVar cat\r\n guard (d && c)\r\n reset = do\r\n writeTVar dog False\r\n writeTVar cat False\r\n reset' = do\r\n d <- readTVar dog\r\n c <- readTVar cat\r\n guard (d || c)\r\n reset\r\n\r\n forkIO (atomically oops >> putStrLn \"Oh Noes!\")\r\n forever (do\r\n forkIO (atomically setDog)\r\n forkIO (atomically setCat)\r\n atomically reset'\r\n atomically reset')\r\n}}}\r\n\r\nWhen run it produces:\r\n\r\n{{{\r\n$ ghc --make test.hs -threaded -rtsopts\r\n$ ./test +RTS -N2\r\nOh Noes!\r\ntest: thread blocked indefinitely in an STM transaction\r\n}}}\r\n\r\nThe second message is just a consequence of entering an unexpected state. The first message indicates that both the transactions {{{cat}}} and {{{dog}}} committed at the same time.\r\n\r\nIt does this for HEAD and 7.6.\r\n\r\nI've sketched out an interleaving that leads to this. TRec entries\r\nare in the first and third column and TVar's are in the second column. Each entry has a TVar name and the expected value followed\r\nby the new value and then a number of updates if it has been read. TVars list their value and their number of updates.\r\n\r\n{{{\r\n A TRec TVar B TRec\r\n -- Transactions start\r\ncat F F cat F 0 cat F F -- Initial reads.\r\ndog F F dog F 0 dog F F \r\n\r\ncat F T dog F T -- Local writes in TRec's\r\n \r\n -- Validation:\r\n\r\n cat F F 0 -- B reads num_updates from cat (with\r\n ^ -- consistency check with value)\r\ncat F T cat A 0 | -- A acquires lock for cat (atomic cas)\r\ndog F F 0 ^ | -- A reads num_updates from dog (with\r\n ^ | | -- consistency check with value)\r\n | dog B 0 dog F T | -- B acquires lock for dog (atomic cas)\r\n | | ^ | \r\n | | | |\r\nSuccess 0 | 0 | -- read check for A\r\nSuccess 0 0 -- read check for B\r\n\r\n cat A 1 -- Increment version\r\n cat T 1 -- Unlock with new value\r\n dog B 1 -- Increment version\r\n dog B T -- Unlock with new value\r\n}}}\r\n\r\nWhat is clear here is that the version number is not enough to check\r\nin {{{check_read_only}}} because there is a gap between locking and \r\nincrementing the version. We need to know atomically that the TVar is not locked and it's version number is the same.\r\n\r\nI need to read through the right parts of Keir Fraser's thesis carefully, but it seems like the read phase here is only helpful in preventing a commit that writes back the exact value we have already seen while we are in the middle of committing. \r\n\r\nThe code for {{{check_read_only}}} is here:\r\n\r\n{{{\r\n#!c\r\nstatic StgBool check_read_only(StgTRecHeader *trec STG_UNUSED) {\r\n StgBool result = TRUE;\r\n\r\n ASSERT (config_use_read_phase);\r\n IF_STM_FG_LOCKS({\r\n FOR_EACH_ENTRY(trec, e, {\r\n StgTVar *s;\r\n s = e -> tvar;\r\n if (entry_is_read_only(e)) {\r\n TRACE(\"%p : check_read_only for TVar %p, saw %ld\", trec, s, e -> num_updates);\r\n if (s -> num_updates != e -> num_updates) {\r\n // ||s -> current_value != e -> expected_value) {\r\n TRACE(\"%p : mismatch\", trec);\r\n result = FALSE;\r\n BREAK_FOR_EACH;\r\n }\r\n }\r\n });\r\n });\r\n\r\n return result;\r\n}\r\n}}}\r\n\r\nIf I restore the commented out line (which appears commented out in the first commit of this code that I can find) I can't reproduce the issue, but I think there is still a problem due to the ordering of\r\nthose checks: we could observe the version as the same, while it \r\nis locked, have the TVar unlock, then observe the value the same. \r\n\r\nSwitching the order we can only observe the TVar unlocked if the\r\nupdate has been incremented (as long as we are on an architecture\r\nthat ensures this such as x86).\r\n\r\nDoes this seem right? One issue is that given the interleaving that above with this added check ''both'' transactions could fail to commit. I think the algorithms from Fraser avoid this, but I think it always involves invalidating another transaction (i.e. killing off any other transactions observed to be in the read check phase with an overlapping TVar in a way that results in only one winner (see page 21 section 4.4 in ''Concurrent Programming Without Locks'')).\r\n\r\nAs a side note, the issue can be avoided by ensuring that the reads become writes and avoiding the read only check. But you can only \r\nbecome a write if the values do not have matching pointers, switching to Ints instead of Bools gets you there.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/7788Recursive type family causes <<loop>>2019-07-07T18:48:09ZshachafRecursive type family causes <<loop>>This file:
```
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE UndecidableInstances #-}
data Proxy a = Proxy
foo :: Proxy (F (Fix Id)) -> ()
foo = undefined
newtype Fix a = Fix (a (Fix a))
newtype Id a = Id a
type family F a
type instanc...This file:
```
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE UndecidableInstances #-}
data Proxy a = Proxy
foo :: Proxy (F (Fix Id)) -> ()
foo = undefined
newtype Fix a = Fix (a (Fix a))
newtype Id a = Id a
type family F a
type instance F (Fix a) = F (a (Fix a))
type instance F (Id a) = F a
main :: IO ()
main = print $ foo Proxy
```
Dies with `<<loop>>`. The type family is recursive, of course:
```
*Main> :kind! F (Fix Id)
F (Fix Id) :: *^CInterrupted.
```
But `<<loop>>` is still not the behavior I'd expect. The actual value is just `undefined`.
In the file that this example came up, the situation was even worse -- there was a situation where
```
moldMapOf l f = runAccessor . l (Accessor . f)
main = print $ (flip appEndo [] . moldMapOf (ix 3) (Endo . (:)) $ testVal :: [Int]) -- <<loop>>
main = print $ (flip appEndo [] . runAccessor . (ix 3) (Accessor . Endo . (:)) $ testVal :: [Int]) -- undefined
```
I.e. substitution can turn one program (which happens to be ⊥ here, admittedly, but that's not fundamental) into another (`<<loop>>`). This makes it very tricky to track down the recursive type family. If necessary I can hunt down a working test case and post it here -- it's a bit tricky to get working, though.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.6.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Recursive type family causes <<loop>>","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This file:\r\n\r\n{{{\r\n{-# LANGUAGE TypeFamilies #-}\r\n{-# LANGUAGE UndecidableInstances #-}\r\n\r\ndata Proxy a = Proxy\r\n\r\nfoo :: Proxy (F (Fix Id)) -> ()\r\nfoo = undefined\r\n\r\nnewtype Fix a = Fix (a (Fix a))\r\nnewtype Id a = Id a\r\n\r\ntype family F a\r\ntype instance F (Fix a) = F (a (Fix a))\r\ntype instance F (Id a) = F a\r\n\r\nmain :: IO ()\r\nmain = print $ foo Proxy\r\n}}}\r\n\r\nDies with `<<loop>>`. The type family is recursive, of course:\r\n\r\n{{{\r\n*Main> :kind! F (Fix Id)\r\nF (Fix Id) :: *^CInterrupted.\r\n}}}\r\n\r\nBut `<<loop>>` is still not the behavior I'd expect. The actual value is just `undefined`.\r\n\r\nIn the file that this example came up, the situation was even worse -- there was a situation where\r\n\r\n{{{\r\nmoldMapOf l f = runAccessor . l (Accessor . f)\r\nmain = print $ (flip appEndo [] . moldMapOf (ix 3) (Endo . (:)) $ testVal :: [Int]) -- <<loop>>\r\nmain = print $ (flip appEndo [] . runAccessor . (ix 3) (Accessor . Endo . (:)) $ testVal :: [Int]) -- undefined\r\n}}}\r\n\r\nI.e. substitution can turn one program (which happens to be ⊥ here, admittedly, but that's not fundamental) into another (`<<loop>>`). This makes it very tricky to track down the recursive type family. If necessary I can hunt down a working test case and post it here -- it's a bit tricky to get working, though.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1Richard Eisenbergrae@richarde.devRichard Eisenbergrae@richarde.devhttps://gitlab.haskell.org/ghc/ghc/-/issues/7773Waiting on non-kqueue supported files on OS X2019-07-07T18:48:12ZAndreasVoellmyWaiting on non-kqueue supported files on OS XNeither the old IO manager nor the new "parallel" IO manager properly handle waiting on files on Mac OS X when kqueue does not support the device type. PHO reported this on ghc-devs: http://www.haskell.org/pipermail/ghc-devs/2013-March/0...Neither the old IO manager nor the new "parallel" IO manager properly handle waiting on files on Mac OS X when kqueue does not support the device type. PHO reported this on ghc-devs: http://www.haskell.org/pipermail/ghc-devs/2013-March/000798.html.
Here is the gist of it: the IO manager uses kqueue to wait on files on OS X. kqueue does not support all files. For example, on older versions of OS X (10.5.8) it cannot wait on tty devices and on even on 10.8.2 it cannot wait on /dev/random.
Both the old and parallel IO managers suffered from the problem, but the consequences were slightly different. With the old IO manager the situation was treated as the file being ready, which would just cause the waiting thread to run again. The parallel IO manager changed things slightly and now it just throws an exception and terminates the program. So the behavior when this happens in the parallel IO manager is not acceptable.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.7 |
| 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":"Waiting on non-kqueue supported files on OS X","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Neither the old IO manager nor the new \"parallel\" IO manager properly handle waiting on files on Mac OS X when kqueue does not support the device type. PHO reported this on ghc-devs: http://www.haskell.org/pipermail/ghc-devs/2013-March/000798.html.\r\n\r\nHere is the gist of it: the IO manager uses kqueue to wait on files on OS X. kqueue does not support all files. For example, on older versions of OS X (10.5.8) it cannot wait on tty devices and on even on 10.8.2 it cannot wait on /dev/random. \r\n\r\nBoth the old and parallel IO managers suffered from the problem, but the consequences were slightly different. With the old IO manager the situation was treated as the file being ready, which would just cause the waiting thread to run again. The parallel IO manager changed things slightly and now it just throws an exception and terminates the program. So the behavior when this happens in the parallel IO manager is not acceptable.\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1AndreasVoellmyAndreasVoellmyhttps://gitlab.haskell.org/ghc/ghc/-/issues/7716ZonedTime read instance failing to parse what show returns2019-07-07T18:48:26Zmercer92ZonedTime read instance failing to parse what show returnsTest case:
```
import Data.Time
main = do
time <- getZonedTime
let string = show time
print string
print $ (read string :: ZonedTime)
```
This gives me:
```
*Main> main
"2013-02-24 14:51:56.453125 Central European Standard Ti...Test case:
```
import Data.Time
main = do
time <- getZonedTime
let string = show time
print string
print $ (read string :: ZonedTime)
```
This gives me:
```
*Main> main
"2013-02-24 14:51:56.453125 Central European Standard Time"
*** Exception: Prelude.read: no parse
```
Reportedly this works with (some) other timezones, so be sure to also test it with mine (show time =\> "2013-02-24 14:51:56.453125 Central European Standard Time").
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 7.4.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries (other) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Zonetime read instance failing to parse what show returns","status":"New","operating_system":"","component":"libraries (other)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.4.2","keywords":["ZoneTime","read","show"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Test case:\r\n{{{\r\nimport Data.Time\r\n\r\nmain = do\r\n time <- getZonedTime\r\n let string = show time\r\n print string\r\n print $ (read string :: ZonedTime)\r\n}}}\r\n\r\nThis gives me:\r\n\r\n\r\n{{{\r\n*Main> main\r\n\"2013-02-24 14:51:56.453125 Central European Standard Time\"\r\n*** Exception: Prelude.read: no parse\r\n}}}\r\n\r\nReportedly this works with (some) other timezones, so be sure to also test it with mine (show time => \"2013-02-24 14:51:56.453125 Central European Standard Time\").","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/7613readSigned consumes too much input2019-07-07T18:48:59ZliyangreadSigned consumes too much input```
> reads "0.1" :: [(Int, String)]
[]
```
I would have expected `[(0, ".1")]`. The Report specifies that `reads` for `Int` ought to essentially be `readSigned readDec`, and indeed `readDec` gives the expected result:
```
> readDec "0...```
> reads "0.1" :: [(Int, String)]
[]
```
I would have expected `[(0, ".1")]`. The Report specifies that `reads` for `Int` ought to essentially be `readSigned readDec`, and indeed `readDec` gives the expected result:
```
> readDec "0.1"
[(0,".1")]
```
I think the bug is due to the use of `lex` in `readSigned`, which consumes the entire "0.1" string, such that readDec no longer gives a clean parse.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.6.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":"readSigned consumes too much input","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\n> reads \"0.1\" :: [(Int, String)]\r\n[]\r\n}}}\r\n\r\nI would have expected {{{[(0, \".1\")]}}}. The Report specifies that {{{reads}}} for {{{Int}}} ought to essentially be {{{readSigned readDec}}}, and indeed {{{readDec}}} gives the expected result:\r\n{{{\r\n> readDec \"0.1\"\r\n[(0,\".1\")]\r\n}}}\r\n\r\nI think the bug is due to the use of {{{lex}}} in {{{readSigned}}}, which consumes the entire \"0.1\" string, such that readDec no longer gives a clean parse.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/7599timeout does not behave as expected2019-07-07T18:49:03Ziquetimeout does not behave as expectedIn trying to debug an error I found using the MongoDB package (it was refusing connections) I found what I believe is a bug with System.Timeout.
When connecting with connectTo I immediately get a handle, wrapped in timeout with a positi...In trying to debug an error I found using the MongoDB package (it was refusing connections) I found what I believe is a bug with System.Timeout.
When connecting with connectTo I immediately get a handle, wrapped in timeout with a positive timeout, it instantly returns Nothing. When using a negative timeout (wait indefinitely) it instantly returns the proper Handle.
Below is a minimal test-case that I ran in ghci.
Import System.Timeout
Import Network
timeout (-1) $ connectTo "127.0.0.1" (PortNumber 27017)
-- This returns: Just {handle: \<socket: 9\>}
timeout 1000000 $ connectTo "127.0.0.1" (PortNumber 27017)
-- This returns Nothing
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.6.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":"timeout does not behave as expected","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.1","keywords":["System.Timeout","base-4.6","timeout"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"In trying to debug an error I found using the MongoDB package (it was refusing connections) I found what I believe is a bug with System.Timeout.\r\n\r\nWhen connecting with connectTo I immediately get a handle, wrapped in timeout with a positive timeout, it instantly returns Nothing. When using a negative timeout (wait indefinitely) it instantly returns the proper Handle.\r\n\r\nBelow is a minimal test-case that I ran in ghci.\r\n\r\nImport System.Timeout\r\n\r\nImport Network\r\n\r\ntimeout (-1) $ connectTo \"127.0.0.1\" (PortNumber 27017)\r\n -- This returns: Just {handle: <socket: 9>}\r\n\r\ntimeout 1000000 $ connectTo \"127.0.0.1\" (PortNumber 27017)\r\n -- This returns Nothing","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/7589LLVM 3.2 Support2019-07-07T18:49:06ZdtereiLLVM 3.2 SupportLLVM 3.2 is out as of mid December. We need to update the backend to support it.
There seems to be a number of new bugs due to the change.
With LLVM 3.1 we get the following testsuite failures:
```
OVERALL SUMMARY for test run started...LLVM 3.2 is out as of mid December. We need to update the backend to support it.
There seems to be a number of new bugs due to the change.
With LLVM 3.1 we get the following testsuite failures:
```
OVERALL SUMMARY for test run started at Mon Jan 14 21:42:32 PST 2013
3552 total tests, which gave rise to
13164 test cases, of which
0 caused framework failures
11606 were skipped
1515 expected passes
23 had missing libraries
15 expected failures
0 unexpected passes
5 unexpected failures
Unexpected failures:
* codeGen/should_run cgrun044 [exit code non-0] (optllvm)
* concurrent/should_run 367_letnoescape [bad exit code] (optllvm)
* numeric/should_run arith005 [bad stdout] (optllvm)
typecheck/should_compile tc226 [exit code non-0] (optllvm)
typecheck/should_compile tc235 [exit code non-0] (optllvm)
```
Where the failures marked with '\*' are unique to the LLVM backend.
With LLVM 3.2 we get the following:
```
OVERALL SUMMARY for test run started at Tue Jan 15 16:02:01 PST 2013
3552 total tests, which gave rise to
13164 test cases, of which
0 caused framework failures
11606 were skipped
1512 expected passes
23 had missing libraries
15 expected failures
0 unexpected passes
8 unexpected failures
Unexpected failures:
** codeGen/should_compile 1916 [exit code non-0] (optllvm)
** codeGen/should_run cgrun028 [exit code non-0] (optllvm)
* codeGen/should_run cgrun044 [exit code non-0] (optllvm)
* concurrent/should_run 367_letnoescape [bad exit code] (optllvm)
* numeric/should_run arith005 [bad stdout] (optllvm)
** numeric/should_run numrun012 [exit code non-0] (optllvm)
typecheck/should_compile tc226 [exit code non-0] (optllvm)
typecheck/should_compile tc235 [exit code non-0] (optllvm)
```
Where failures marked with '\*' are unique to the LLVM backend and failures marked with '\*\*' are unique to LLVM 3.2 relative to 3.1.
I believe bootstrapping with LLVM also fails now. However, that may be due to the change to the new-code-generator, and not of LLVM 3.1 -\> 3.2. I'll create a separate ticket for that.
**NOTE**: These test suite results were all generated on **Mac OS X 10.8**.dtereidtereihttps://gitlab.haskell.org/ghc/ghc/-/issues/7583IO reordering2019-07-07T18:49:08ZHeimdellIO reorderingI have a simple test program:
```
main = do putStr "> "
line <- getLine
putStrLn line
```
In ghci, it writes "\> " before receiving input:
```
Prelude Main> main
> WHAT
WHAT
```
But being compiled by ghc it writes...I have a simple test program:
```
main = do putStr "> "
line <- getLine
putStrLn line
```
In ghci, it writes "\> " before receiving input:
```
Prelude Main> main
> WHAT
WHAT
```
But being compiled by ghc it writes "\> " just after receiving input.
```
maelstrom@ubuntu:~/vault$ ./test
WHAT
> WHAT
```
That is not the behavior I expect.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.4.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":"IO reordering","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.4.1","keywords":["IO,","evaluation","invalid","order"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I have a simple test program:\r\n\r\n{{{\r\nmain = do putStr \"> \"\r\n line <- getLine\r\n putStrLn line\r\n}}}\r\n\r\nIn ghci, it writes \"> \" before receiving input:\r\n\r\n{{{\r\nPrelude Main> main\r\n> WHAT\r\nWHAT\r\n}}}\r\n\r\nBut being compiled by ghc it writes \"> \" just after receiving input.\r\n\r\n{{{\r\nmaelstrom@ubuntu:~/vault$ ./test \r\nWHAT\r\n> WHAT\r\n}}}\r\n\r\nThat is not the behavior I expect.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/7537[PATCH] Incorrect Haskell type for ino_t on MacOS X 10.52019-07-07T18:49:19ZPHO[PATCH] Incorrect Haskell type for ino_t on MacOS X 10.5I found a strange problem that `System.Posix.Internals.fdStat` reporting `st_ino == 0` for any file. That was because `__hscore_st_ino` was assuming `ino_t` to be `uint64_t` while `CIno` being inferred to be `Word32`.
Here is my [patch]...I found a strange problem that `System.Posix.Internals.fdStat` reporting `st_ino == 0` for any file. That was because `__hscore_st_ino` was assuming `ino_t` to be `uint64_t` while `CIno` being inferred to be `Word32`.
Here is my [patch](https://github.com/phonohawk/packages-base/commit/7ccbbb4e9e9b9617eb698eb92ef20a1052af38b9) to fix this:
```
git fetch git://github.com/phonohawk/packages-base.git darwin-htype-ino_t
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.7 |
| 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":"[PATCH] Incorrect Haskell type for ino_t on MacOS X 10.5","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I found a strange problem that `System.Posix.Internals.fdStat` reporting `st_ino == 0` for any file. That was because `__hscore_st_ino` was assuming `ino_t` to be `uint64_t` while `CIno` being inferred to be `Word32`.\r\n\r\nHere is my [https://github.com/phonohawk/packages-base/commit/7ccbbb4e9e9b9617eb698eb92ef20a1052af38b9 patch] to fix this:\r\n{{{\r\ngit fetch git://github.com/phonohawk/packages-base.git darwin-htype-ino_t\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/7528Non terminating thunk resolution blocks world, even in the case of forkOS2019-07-07T18:49:20ZtimthelionNon terminating thunk resolution blocks world, even in the case of forkOSPlease see:
http://comments.gmane.org/gmane.comp.lang.haskell.cafe/102479
> {-\# LANGUAGE ScopedTypeVariables \#-}
> import Control.Concurrent
> main = do
> putStrLn "Hello"
> forkOS neverEnds
> putStrLn "Bye bye" --We never get here(o...Please see:
http://comments.gmane.org/gmane.comp.lang.haskell.cafe/102479
> {-\# LANGUAGE ScopedTypeVariables \#-}
> import Control.Concurrent
> main = do
> putStrLn "Hello"
> forkOS neverEnds
> putStrLn "Bye bye" --We never get here(or at least I don't).
> neverEnds = do
> let (a::String) = a
> putStrLn a
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.4.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | x86_64 (amd64) |
</details>
<!-- {"blocked_by":[],"summary":"Non terminating thunk resolution blocks world, even in the case of forkOS","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.4.2","keywords":["Concurrent","forkOS","thunk"],"differentials":[],"test_case":"","architecture":"x86_64 (amd64)","cc":[""],"type":"Bug","description":"Please see:\r\nhttp://comments.gmane.org/gmane.comp.lang.haskell.cafe/102479\r\n\r\n>{-# LANGUAGE ScopedTypeVariables #-}\r\n>import Control.Concurrent\r\n\r\n>main = do\r\n> putStrLn \"Hello\"\r\n> forkOS neverEnds\r\n> putStrLn \"Bye bye\" --We never get here(or at least I don't).\r\n\r\n>neverEnds = do\r\n> let (a::String) = a\r\n> putStrLn a","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/7491getNumCapabilities uses n_capabilities instead of enabled_capabilities2019-07-07T18:49:31ZYurasgetNumCapabilities uses n_capabilities instead of enabled_capabilitiessetNumCapabilities newer removes capabilities, it just disables them when new value is less the the current one. In that case getNumCapabilities returns wrong result.
<details><summary>Trac metadata</summary>
| Trac field |...setNumCapabilities newer removes capabilities, it just disables them when new value is less the the current one. In that case getNumCapabilities returns wrong result.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------------- |
| Version | 7.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | shumovichy@gmail.com |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"getNumCapabilities uses n_capabilities instead of enabled_capabilities","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["shumovichy@gmail.com"],"type":"Bug","description":"setNumCapabilities newer removes capabilities, it just disables them when new value is less the the current one. In that case getNumCapabilities returns wrong result.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1