GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:55:44Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/5365Finalizer running prematurely in ghci2019-07-07T18:55:44ZEdward KmettFinalizer running prematurely in ghciI have been building a library for doing hash consing, but it seemed to incorrectly finalize references to live entries in the hash cons table when I use it from ghci.
I've distilled the problem to the following test case.
```
Prelude ...I have been building a library for doing hash consing, but it seemed to incorrectly finalize references to live entries in the hash cons table when I use it from ghci.
I've distilled the problem to the following test case.
```
Prelude System.Mem.Weak GHC.IO> let x = let y = "foo" in (unsafePerformIO $ addFinalizer y (putStrLn "deleted")) `seq` y
Prelude System.Mem.Weak GHC.IO> x
"foo"
deleted
Prelude System.Mem.Weak GHC.IO> x
"foo"
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.0.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":"Finalizer running prematurely in ghci","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.3","keywords":["finalizers"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I have been building a library for doing hash consing, but it seemed to incorrectly finalize references to live entries in the hash cons table when I use it from ghci. \r\n\r\nI've distilled the problem to the following test case.\r\n\r\n{{{\r\nPrelude System.Mem.Weak GHC.IO> let x = let y = \"foo\" in (unsafePerformIO $ addFinalizer y (putStrLn \"deleted\")) `seq` y\r\nPrelude System.Mem.Weak GHC.IO> x\r\n\"foo\"\r\ndeleted\r\nPrelude System.Mem.Weak GHC.IO> x\r\n\"foo\"\r\n}}}\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/5363optimized profiled version of a program incorectly compiles $!2019-07-07T18:55:44Zphercekoptimized profiled version of a program incorectly compiles $!Here is a test program (file name prgSrc.hs):
```
import Data.Array.Unboxed
main = do
let l1 = [1..10] :: [Int]
let l2 = [ map (i+) l1 | i <- [1..5000000] ]
let l3 = map (\l -> listArray (1,length l) l) l2 :: [UArray Int Int]
p...Here is a test program (file name prgSrc.hs):
```
import Data.Array.Unboxed
main = do
let l1 = [1..10] :: [Int]
let l2 = [ map (i+) l1 | i <- [1..5000000] ]
let l3 = map (\l -> listArray (1,length l) l) l2 :: [UArray Int Int]
print $ accumulate l3 0
accumulate [] rv = rv
accumulate (h:t) rv =
let nextRv = (rv + sum (elems h)) in
accumulate t $! nextRv
```
I used ghc 7.0.3-2 on archlinux, 64 bit version.
I created it only to check how much memory short unboxed arrays consume.
Thanks to the "$!" call at the last line of the "accumulate" function there should not be any stack overflow.
When I compile with these options:\[\[BR\]\]
*ghc --make prgSrc.hs\[\[BR\]\]
ghc -O2 --make prgSrc.hs\[\[BR\]\]
ghc -prof -auto-all -caf-all --make prgSrc.hs\[\[BR\]\]*
then there is no problem.
But when I compile with these options:\[\[BR\]\]
*ghc -O2 -prof -auto-all -caf-all --make prgSrc.hs\[\[BR\]\]*
then the program runs out of stack.
This indicates that there is a bug while compiling "$!" in an optimized profiling version of this program.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.0.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":"optimized profiled version of a program incorectly compiles $!","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.3","keywords":["optimization","profiling","stricness"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Here is a test program (file name prgSrc.hs):\r\n\r\n{{{\r\nimport Data.Array.Unboxed\r\n\r\nmain = do\r\n let l1 = [1..10] :: [Int]\r\n let l2 = [ map (i+) l1 | i <- [1..5000000] ]\r\n let l3 = map (\\l -> listArray (1,length l) l) l2 :: [UArray Int Int]\r\n print $ accumulate l3 0\r\n\r\naccumulate [] rv = rv\r\naccumulate (h:t) rv =\r\n let nextRv = (rv + sum (elems h)) in\r\n accumulate t $! nextRv\r\n}}}\r\n\r\nI used ghc 7.0.3-2 on archlinux, 64 bit version.\r\nI created it only to check how much memory short unboxed arrays consume.\r\nThanks to the \"$!\" call at the last line of the \"accumulate\" function there should not be any stack overflow.\r\n\r\nWhen I compile with these options:[[BR]]\r\n''ghc --make prgSrc.hs[[BR]]\r\nghc -O2 --make prgSrc.hs[[BR]]\r\nghc -prof -auto-all -caf-all --make prgSrc.hs[[BR]]''\r\nthen there is no problem.\r\n\r\nBut when I compile with these options:[[BR]]\r\n''ghc -O2 -prof -auto-all -caf-all --make prgSrc.hs[[BR]]''\r\nthen the program runs out of stack.\r\n\r\nThis indicates that there is a bug while compiling \"$!\" in an optimized profiling version of this program.","type_of_failure":"OtherFailure","blocking":[]} -->7.4.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/5319MacOS X + executeFile + -threaded = "Operation not supported"2019-07-07T18:55:54ZPHOMacOS X + executeFile + -threaded = "Operation not supported"http://uninformed.org/index.cgi?v=1&a=1&p=16
http://lists.apple.com/archives/cocoa-dev/2005/Oct/msg00836.html
Mac OS X has an undocumented behavior concerning 'execve(2)' inside a
threaded process. If a process tries to call 'execve(2)'...http://uninformed.org/index.cgi?v=1&a=1&p=16
http://lists.apple.com/archives/cocoa-dev/2005/Oct/msg00836.html
Mac OS X has an undocumented behavior concerning 'execve(2)' inside a
threaded process. If a process tries to call 'execve(2)' and has more
than one native thread, the kernel returns 'EOPNOTSUPP'. This prevents
'executeFile' from working when the threaded runtime is used.
```
% ghci
GHCi, version 7.0.3: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package ffi-1.0 ... linking ... done.
Prelude> System.Posix.Process.executeFile "/bin/sh" False [] Nothing
Loading package unix-2.4.2.0 ... linking ... done.
*** Exception: /bin/sh: executeFile: failed (Operation not supported)
Prelude>
Leaving GHCi.
% uname
Darwin
```
To work around this, we have to 'fork(2)' before calling 'execve(2)',
to make sure there is only a single active thread.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.0.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/unix |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"MacOS X + executeFile + -threaded = \"Operation not supported\"","status":"New","operating_system":"","component":"libraries/unix","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.3","keywords":["exec","thread,"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"http://uninformed.org/index.cgi?v=1&a=1&p=16\r\nhttp://lists.apple.com/archives/cocoa-dev/2005/Oct/msg00836.html\r\n\r\nMac OS X has an undocumented behavior concerning 'execve(2)' inside a\r\nthreaded process. If a process tries to call 'execve(2)' and has more\r\nthan one native thread, the kernel returns 'EOPNOTSUPP'. This prevents\r\n'executeFile' from working when the threaded runtime is used.\r\n\r\n{{{\r\n% ghci\r\nGHCi, version 7.0.3: http://www.haskell.org/ghc/ :? for help\r\nLoading package ghc-prim ... linking ... done.\r\nLoading package integer-gmp ... linking ... done.\r\nLoading package base ... linking ... done.\r\nLoading package ffi-1.0 ... linking ... done.\r\nPrelude> System.Posix.Process.executeFile \"/bin/sh\" False [] Nothing\r\nLoading package unix-2.4.2.0 ... linking ... done.\r\n*** Exception: /bin/sh: executeFile: failed (Operation not supported)\r\nPrelude> \r\nLeaving GHCi.\r\n% uname\r\nDarwin\r\n}}}\r\n\r\nTo work around this, we have to 'fork(2)' before calling 'execve(2)',\r\nto make sure there is only a single active thread.","type_of_failure":"OtherFailure","blocking":[]} -->7.4.1https://gitlab.haskell.org/ghc/ghc/-/issues/5282Bizarre results from -P profiler on OS X2019-07-07T18:56:04ZbosBizarre results from -P profiler on OS XI'm trying to use the profiler to understand the performance of an application on OS X. I have a smallish benchmark that prints a lot of lines of text to `stdout`, and the numbers reported when I use `+RTS -P` are very different from wha...I'm trying to use the profiler to understand the performance of an application on OS X. I have a smallish benchmark that prints a lot of lines of text to `stdout`, and the numbers reported when I use `+RTS -P` are very different from what I see with my eyes.
The benchmark itself is quite simple:
https://github.com/mailrank/text-format/blob/master/benchmarks/Simple.hs
When I run it on the command line, it produces simple enough output:
```
$ time ./Simple one 500000 +RTS -P >/dev/null
500000 iterations in 2.6 secs (191.7 thousand/sec)
real 0m2.626s
user 0m2.586s
sys 0m0.030s
```
The time measured within the app and the wallclock time are both in agreement.
However, if I look at the `Simple.prof` file left behind afterwards, its numbers seem bizarre:
```
Mon Jun 27 11:35 2011 Time and Allocation Profiling Report (Final)
Simple +RTS -P -RTS one 500000
total time = 0.28 secs (14 ticks @ 20 ms)
total alloc = 2,200,395,720 bytes (excludes profiling overheads)
```
It reports a time of just 0.28 seconds, and the number of ticks it counts arithmetically agree with this.
I have other programs that suffer from the same discrepancy between wallclock measurement and what the profiler reports to me, such that I don't feel like I can trust the profiler at all here. I'm at a loss for what to do about this, though.
<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 | MacOS X |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Bizarre results from -P profiler on OS X","status":"New","operating_system":"MacOS X","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I'm trying to use the profiler to understand the performance of an application on OS X. I have a smallish benchmark that prints a lot of lines of text to `stdout`, and the numbers reported when I use `+RTS -P` are very different from what I see with my eyes.\r\n\r\nThe benchmark itself is quite simple:\r\n\r\nhttps://github.com/mailrank/text-format/blob/master/benchmarks/Simple.hs\r\n\r\nWhen I run it on the command line, it produces simple enough output:\r\n\r\n{{{\r\n$ time ./Simple one 500000 +RTS -P >/dev/null\r\n500000 iterations in 2.6 secs (191.7 thousand/sec)\r\n\r\nreal\t0m2.626s\r\nuser\t0m2.586s\r\nsys\t0m0.030s\r\n}}}\r\n\r\nThe time measured within the app and the wallclock time are both in agreement.\r\n\r\nHowever, if I look at the `Simple.prof` file left behind afterwards, its numbers seem bizarre:\r\n\r\n{{{\r\n Mon Jun 27 11:35 2011 Time and Allocation Profiling Report (Final)\r\n\r\n Simple +RTS -P -RTS one 500000\r\n\r\n total time = 0.28 secs (14 ticks @ 20 ms)\r\n total alloc = 2,200,395,720 bytes (excludes profiling overheads)\r\n}}}\r\n\r\nIt reports a time of just 0.28 seconds, and the number of ticks it counts arithmetically agree with this.\r\n\r\nI have other programs that suffer from the same discrepancy between wallclock measurement and what the profiler reports to me, such that I don't feel like I can trust the profiler at all here. I'm at a loss for what to do about this, though.","type_of_failure":"OtherFailure","blocking":[]} -->7.4.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/5280System.Random commits (rand `mod` base) error.2019-07-07T18:56:05ZrrnewtonSystem.Random commits (rand `mod` base) error.You have probably at some point come across the C code "`rand() % base`"'. It is very intuitive, but unfortunately creates non-uniform random numbers, which is easy to see if you imagine `rand()` producing numbers in say `[0,15)` and bas...You have probably at some point come across the C code "`rand() % base`"'. It is very intuitive, but unfortunately creates non-uniform random numbers, which is easy to see if you imagine `rand()` producing numbers in say `[0,15)` and base being `10`.
In the function `System.Random.randomIvalInteger` you can see the same thing happening.
The only way I know how to deal with it and generate uniform integers within a range is to artificially restrict the range of the source of randomness to be a multiple of the desired base. It can be done simply by throwing out some random results.
This strategy appears to be used by GMP's mpz_urandomm function:
> http://gmplib.org/manual/Integer-Random-Numbers.html\#Integer-Random-Numbers
The file `urandomm.c` has the code.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 7.0.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/random |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"System.Random commits (rand `mod` base) error.","status":"New","operating_system":"","component":"libraries/random","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"rrnewton"},"version":"7.0.3","keywords":["base","mod","random"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"You have probably at some point come across the C code \"{{{rand() % base}}}\"'. It is very intuitive, but unfortunately creates non-uniform random numbers, which is easy to see if you imagine {{{rand()}}} producing numbers in say `[0,15)` and base being `10`.\r\n\r\nIn the function `System.Random.randomIvalInteger` you can see the same thing happening. \r\n\r\nThe only way I know how to deal with it and generate uniform integers within a range is to artificially restrict the range of the source of randomness to be a multiple of the desired base. It can be done simply by throwing out some random results.\r\n\r\nThis strategy appears to be used by GMP's mpz_urandomm function:\r\n\r\n http://gmplib.org/manual/Integer-Random-Numbers.html#Integer-Random-Numbers\r\n\r\nThe file `urandomm.c` has the code.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1rrnewtonrrnewtonhttps://gitlab.haskell.org/ghc/ghc/-/issues/5279numericEnumFromThen breaks standard behaviour in presence of ⊥2019-07-07T18:56:05ZehirdnumericEnumFromThen breaks standard behaviour in presence of ⊥Haskell 2010 (and, for what it's worth, 98) require the following behaviour for `numericEnumFromThen`:
```
numericEnumFromThen n m = iterate (+(m-n)) n
```
but GHC has:
```
numericEnumFromThen n m = n `seq` m `seq` (n : numericEnumFr...Haskell 2010 (and, for what it's worth, 98) require the following behaviour for `numericEnumFromThen`:
```
numericEnumFromThen n m = iterate (+(m-n)) n
```
but GHC has:
```
numericEnumFromThen n m = n `seq` m `seq` (n : numericEnumFromThen m (m+m-n))
```
The standard evaluation of `numericEnumFromThen 0.0 undefined` is equivalent to `0.0 : repeat undefined`, but GHC evaluates it as `undefined`:
```
> Prelude> [0.0, undefined..]
*** Exception: Prelude.undefined
```
So unfortunately, this optimisation changes semantics in violation of the Report.
`numericEnumFrom` also suffers from this issue; the evaluation of `numericEnumFrom undefined` should be equivalent to `repeat undefined`, but GHC evaluates it as `undefined`. This is a more minor issue, however. :)
(Tested with 7.0.3 and whatever version lambdabot uses on freenode.)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.0.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":"numericEnumFromThen breaks standard behaviour in presence of ⊥","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Haskell 2010 (and, for what it's worth, 98) require the following behaviour for `numericEnumFromThen`:\r\n\r\n{{{\r\nnumericEnumFromThen n m = iterate (+(m-n)) n\r\n}}}\r\n\r\nbut GHC has:\r\n\r\n{{{\r\nnumericEnumFromThen n m = n `seq` m `seq` (n : numericEnumFromThen m (m+m-n))\r\n}}}\r\n\r\nThe standard evaluation of `numericEnumFromThen 0.0 undefined` is equivalent to `0.0 : repeat undefined`, but GHC evaluates it as `undefined`:\r\n\r\n{{{\r\n> Prelude> [0.0, undefined..]\r\n*** Exception: Prelude.undefined\r\n}}}\r\n\r\nSo unfortunately, this optimisation changes semantics in violation of the Report.\r\n\r\n`numericEnumFrom` also suffers from this issue; the evaluation of `numericEnumFrom undefined` should be equivalent to `repeat undefined`, but GHC evaluates it as `undefined`. This is a more minor issue, however. :)\r\n\r\n(Tested with 7.0.3 and whatever version lambdabot uses on freenode.)","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/5278System.Random.randomIvalInteger makes invalid assumptions about RandomGen2019-07-07T18:56:05ZrrnewtonSystem.Random.randomIvalInteger makes invalid assumptions about RandomGenThe existing API for `System.Random.RandomGen` allows a random number generator (RNG) to produce Ints within an arbitrary range specified by `genRange`.
For example, the following `RandomGen` produces only zeros and ones, but should be ...The existing API for `System.Random.RandomGen` allows a random number generator (RNG) to produce Ints within an arbitrary range specified by `genRange`.
For example, the following `RandomGen` produces only zeros and ones, but should be legitimate:
```
import System.Random
data BinRNG = BinRNG StdGen
instance RandomGen BinRNG where
next (BinRNG g) = (x `mod` 2, BinRNG g')
where (x,g') = next g
split (BinRNG g) = (BinRNG g1, BinRNG g2)
where (g1,g2) = split g
genRange _ = (0,1)
ls :: [Int]
ls = randoms (BinRNG$ mkStdGen 38388)
main = print $ take 20 ls
```
But `System.Random.randomIvalInteger` makes invalid assumptions about the amount of randomness produced by `next`. (Specifically, assuming that it creates the same amount as `StdGen`.) Thus, the above program will create an output with only a couple of unique ints (rather than 2\^64).
For example:
```
[4611734781337924537,4611734781337924537,-9223323645458902796,
-9223323645458902797,4611734783485408099,4611734783485408098,
-9223323645458902796,-9223323647606386357,4611734781337924538,
-9223323645458902796,-9223323645458902797,
-9223323647606386357,4611734783485408098,4611734783485408098,
-9223323647606386357,4611734781337924538,4611734781337924537,
-9223323645458902796,4611734783485408099,4611734781337924538]
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 7.0.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/random |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"System.Random.randomIvalInteger makes invalid assumptions about RandomGen","status":"New","operating_system":"","component":"libraries/random","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"rrnewton"},"version":"7.0.3","keywords":["assumption","incorrect"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The existing API for `System.Random.RandomGen` allows a random number generator (RNG) to produce Ints within an arbitrary range specified by `genRange`. \r\n\r\nFor example, the following `RandomGen` produces only zeros and ones, but should be legitimate:\r\n\r\n{{{\r\nimport System.Random\r\n\r\ndata BinRNG = BinRNG StdGen\r\ninstance RandomGen BinRNG where \r\n next (BinRNG g) = (x `mod` 2, BinRNG g')\r\n where (x,g') = next g\r\n split (BinRNG g) = (BinRNG g1, BinRNG g2)\r\n where (g1,g2) = split g\r\n genRange _ = (0,1)\r\n\r\nls :: [Int]\r\nls = randoms (BinRNG$ mkStdGen 38388)\r\n\r\nmain = print $ take 20 ls\r\n}}}\r\n\r\nBut `System.Random.randomIvalInteger` makes invalid assumptions about the amount of randomness produced by `next`. (Specifically, assuming that it creates the same amount as `StdGen`.) Thus, the above program will create an output with only a couple of unique ints (rather than 2^64). \r\n\r\nFor example:\r\n\r\n{{{\r\n[4611734781337924537,4611734781337924537,-9223323645458902796,\r\n-9223323645458902797,4611734783485408099,4611734783485408098,\r\n-9223323645458902796,-9223323647606386357,4611734781337924538,\r\n-9223323645458902796,-9223323645458902797,\r\n-9223323647606386357,4611734783485408098,4611734783485408098,\r\n-9223323647606386357,4611734781337924538,4611734781337924537,\r\n-9223323645458902796,4611734783485408099,4611734781337924538]\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->Edward KmettEdward Kmetthttps://gitlab.haskell.org/ghc/ghc/-/issues/5262Compiling with -O makes some expressions too lazy and causes space leaks2022-10-24T16:34:06Zmichal.palkaCompiling with -O makes some expressions too lazy and causes space leaksHere are some expressions that are executed in a too lazy way when optimisation is turned on in GHC. GHC is known to make some expressions too lazy when full laziness is turned on (as in #917), and indeed some of these expressions execut...Here are some expressions that are executed in a too lazy way when optimisation is turned on in GHC. GHC is known to make some expressions too lazy when full laziness is turned on (as in #917), and indeed some of these expressions execute correctly when you add -fno-full-laziness. However, some of them are compiled too lazy even if -fno-full-laziness is present.
Here are terms that get compiled too lazy with -O only when full strictness is on:
```
seq (id (\a -> seq a (\b -> (undefined::Int))) (undefined::Bool))
\a -> seq (seq a (\b -> seq b null) (undefined::([] ([] Int)) -> [] Int)) (\b -> ([]::[] Int)) length
\a -> seq (id (\b -> seq b (\c -> seq)) (length a)) ([]::[] Int)
```
Here are terms which are compiled too lazy with -O regardless of full strictness:
```
seq (seq (odd (undefined::Int)) (\a -> (undefined::[] (Int -> Bool))))
foldr (\a -> seq) id ((:) True (undefined::[] Bool))
\a -> foldr (\b -> \c -> seq c (\d -> ([]::[] Int))) (undefined::Bool -> [] Int) a False
\a -> (\b -> map (seq b id) (seq b ([]::[] Int))) (seq a (\b -> (undefined::([] Bool))))
map (seq (seq (seq 0 (undefined::Bool)) (\a -> \b -> (undefined::Bool)) (undefined::Int)))
map (seq (seq (id (\a -> (undefined::Int)) ([]::[] Int)) (\a -> undefined::Bool)))
\a -> (\b -> (:) (seq b 2) (b (undefined::Int) 0)) (seq a (\b -> (undefined::Int -> [] Int)))
```
To discover the differences, just run the terms (whose types are \[Int\] -\> \[Int\]) on some partially or fully-defined small lists.
It is possible to construct programs which exhibit space leaks only when optimisation is turned on using some of these terms (examples attached).
All programs have been tested with a pre-built GHC 7.1.20110606 on linux x86-64.
Is this a bug? Well, full laziness comes with a disclaimer that some expressions will get too lazy, but this happens even when we turn off full laziness, so it might be a legitimate bug.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------------ |
| Version | 7.1 |
| Type | Bug |
| TypeOfFailure | IncorrectResultAtRuntime |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Compiling with -O makes some expressions too lazy and causes space leaks","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.1","keywords":["laziness,","leak","space","strictness,"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Here are some expressions that are executed in a too lazy way when optimisation is turned on in GHC. GHC is known to make some expressions too lazy when full laziness is turned on (as in #917), and indeed some of these expressions execute correctly when you add -fno-full-laziness. However, some of them are compiled too lazy even if -fno-full-laziness is present.\r\n\r\nHere are terms that get compiled too lazy with -O only when full strictness is on:\r\n{{{\r\nseq (id (\\a -> seq a (\\b -> (undefined::Int))) (undefined::Bool))\r\n\\a -> seq (seq a (\\b -> seq b null) (undefined::([] ([] Int)) -> [] Int)) (\\b -> ([]::[] Int)) length\r\n\\a -> seq (id (\\b -> seq b (\\c -> seq)) (length a)) ([]::[] Int)\r\n}}}\r\n\r\nHere are terms which are compiled too lazy with -O regardless of full strictness:\r\n{{{\r\nseq (seq (odd (undefined::Int)) (\\a -> (undefined::[] (Int -> Bool))))\r\nfoldr (\\a -> seq) id ((:) True (undefined::[] Bool))\r\n\\a -> foldr (\\b -> \\c -> seq c (\\d -> ([]::[] Int))) (undefined::Bool -> [] Int) a False\r\n\\a -> (\\b -> map (seq b id) (seq b ([]::[] Int))) (seq a (\\b -> (undefined::([] Bool))))\r\nmap (seq (seq (seq 0 (undefined::Bool)) (\\a -> \\b -> (undefined::Bool)) (undefined::Int)))\r\nmap (seq (seq (id (\\a -> (undefined::Int)) ([]::[] Int)) (\\a -> undefined::Bool)))\r\n\\a -> (\\b -> (:) (seq b 2) (b (undefined::Int) 0)) (seq a (\\b -> (undefined::Int -> [] Int)))\r\n}}}\r\n\r\nTo discover the differences, just run the terms (whose types are [Int] -> [Int]) on some partially or fully-defined small lists.\r\n\r\nIt is possible to construct programs which exhibit space leaks only when optimisation is turned on using some of these terms (examples attached).\r\n\r\nAll programs have been tested with a pre-built GHC 7.1.20110606 on linux x86-64.\r\n\r\nIs this a bug? Well, full laziness comes with a disclaimer that some expressions will get too lazy, but this happens even when we turn off full laziness, so it might be a legitimate bug.","type_of_failure":"IncorrectResultAtRuntime","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/5257Calling fail on a UTF-8 encoded string (in file) causes garbage to be printed2019-07-07T18:56:10Zanthony.de.almeida.lopesCalling fail on a UTF-8 encoded string (in file) causes garbage to be printedFor example,
```
guerrilla@delta:/tmp/foo$ cat Test.hs
module Main where
main :: IO ()
main =
do
putStrLn "μ"
fail "μ"
guerrilla@delta:/tmp/foo$ ./Test
μ
Test: user error (�)
guerrilla@delta:/tmp/foo$ ./Test 2>&1 ...For example,
```
guerrilla@delta:/tmp/foo$ cat Test.hs
module Main where
main :: IO ()
main =
do
putStrLn "μ"
fail "μ"
guerrilla@delta:/tmp/foo$ ./Test
μ
Test: user error (�)
guerrilla@delta:/tmp/foo$ ./Test 2>&1 | xxd
0000000: cebc 0a54 6573 743a 2075 7365 7220 6572 ...Test: user er
0000010: 726f 7220 28bc 290a ror (.).
```
Using either encodeString or writing it in escaped hexidecimal does work.7.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/5212waitForProcess: does not exist (No child processes)2019-07-07T18:56:24ZChris DonewaitForProcess: does not exist (No child processes)I have this error when launching a program on our REHL prod machine.
```
waitForProcess: does not exist (No child processes)
```
This is called inside `readProcess`. I am unable to reproduce it on our REHL dev machine, and my local Ubu...I have this error when launching a program on our REHL prod machine.
```
waitForProcess: does not exist (No child processes)
```
This is called inside `readProcess`. I am unable to reproduce it on our REHL dev machine, and my local Ubuntu machine. If I re-implement `readProcess` with the same source but remove `waitForProcess` line, I do get standard output. Launching the program is successful.
The problem stems from `waitForProcess` expecting a process and somehow there isn't one. I didn't think this would be a problem, because `waitForProcess` itself doesn't throw such an exception, and it \*does\* handle the process having ended (of course), which is trivial to confirm locally:
```
λ> (inh,outh,_,pid) <- createProcess (proc "date" [])
Tue May 24 11:19:59 CEST 2011
λ> waitForProcess pid
ExitSuccess
λ>
```
So perhaps it's in `withProcessHandle`, which I don't have access to in the Haddock docs. I don't really know what would cause this error. Ideas?
We're using GHC 6.12.3 (I know, not recent). I'd provide a test-case but I can't even reproduce it on my own machine. I don't have direct shell access to the prod machine. The test-case would essentially be "use readProcess", anyway.
I can assign this to me and I'll see if the problem persists when we upgrade to GHC7. FWIW if you want to reproduce the exact case I tried, here it is:
```
readProcess "pdfinfo" ["--help"] ""
```
```
$ pdfinfo -v
pdfinfo version 3.00
Copyright 1996-2004 Glyph & Cog, LLC
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.12.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHC API |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"waitForProcess: does not exist (No child processes)","status":"New","operating_system":"","component":"GHC API","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"chrisdone"},"version":"6.12.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I have this error when launching a program on our REHL prod machine.\r\n\r\n{{{\r\nwaitForProcess: does not exist (No child processes)\r\n}}}\r\n\r\nThis is called inside `readProcess`. I am unable to reproduce it on our REHL dev machine, and my local Ubuntu machine. If I re-implement `readProcess` with the same source but remove `waitForProcess` line, I do get standard output. Launching the program is successful.\r\n\r\nThe problem stems from `waitForProcess` expecting a process and somehow there isn't one. I didn't think this would be a problem, because `waitForProcess` itself doesn't throw such an exception, and it *does* handle the process having ended (of course), which is trivial to confirm locally:\r\n\r\n{{{\r\nλ> (inh,outh,_,pid) <- createProcess (proc \"date\" [])\r\nTue May 24 11:19:59 CEST 2011\r\nλ> waitForProcess pid\r\nExitSuccess\r\nλ>\r\n}}}\r\n\r\nSo perhaps it's in `withProcessHandle`, which I don't have access to in the Haddock docs. I don't really know what would cause this error. Ideas?\r\n\r\nWe're using GHC 6.12.3 (I know, not recent). I'd provide a test-case but I can't even reproduce it on my own machine. I don't have direct shell access to the prod machine. The test-case would essentially be \"use readProcess\", anyway.\r\n\r\nI can assign this to me and I'll see if the problem persists when we upgrade to GHC7. FWIW if you want to reproduce the exact case I tried, here it is:\r\n\r\n{{{\r\nreadProcess \"pdfinfo\" [\"--help\"] \"\"\r\n}}}\r\n\r\n{{{\r\n$ pdfinfo -v\r\npdfinfo version 3.00\r\nCopyright 1996-2004 Glyph & Cog, LLC\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/5184createDirectory does not retry on EINTR (interrupted)2019-07-07T18:56:31ZCoreyOConnorcreateDirectory does not retry on EINTR (interrupted)With GHC 7.0.3 on Mac OS X 32bit the createDirectory call does not retry if the call is interrupted. I would expect the call to be retried.
Unfortunately, I have not determined a small test program for this bug.
This is the output from ...With GHC 7.0.3 on Mac OS X 32bit the createDirectory call does not retry if the call is interrupted. I would expect the call to be retried.
Unfortunately, I have not determined a small test program for this bug.
This is the output from when this issue occurs:
```
/home/coconnor/Development/dev-system: createDirectory: interrupted (Interrupted system call)
```
Interestingly the directory indicated by this output does not match the directory requested to be created. The program calls:
```
createDirectoryIfMissing True "/home/coconnor/Development/dev-system/build/"
```
And it is known, at the time, that the directory "/home/coconnor/Development/dev-system" exists. Perhaps the method checking for if a directory exists is also receiving EINTR?
This same program works as expected on linux 32bit & 64bit using GHC 7.0.3.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.0.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/unix |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"createDirectory does not retry on EINTR (interrupted)","status":"New","operating_system":"","component":"libraries/unix","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"With GHC 7.0.3 on Mac OS X 32bit the createDirectory call does not retry if the call is interrupted. I would expect the call to be retried.\r\n\r\nUnfortunately, I have not determined a small test program for this bug. \r\nThis is the output from when this issue occurs:\r\n{{{\r\n/home/coconnor/Development/dev-system: createDirectory: interrupted (Interrupted system call)\r\n}}}\r\n\r\nInterestingly the directory indicated by this output does not match the directory requested to be created. The program calls:\r\n\r\n{{{\r\ncreateDirectoryIfMissing True \"/home/coconnor/Development/dev-system/build/\"\r\n}}}\r\n\r\nAnd it is known, at the time, that the directory \"/home/coconnor/Development/dev-system\" exists. Perhaps the method checking for if a directory exists is also receiving EINTR?\r\n\r\nThis same program works as expected on linux 32bit & 64bit using GHC 7.0.3. \r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.2.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/5178RULES "minusFloat x x" and "timesFloat 0.0 x" break IEEE-754 compatibility2019-07-07T18:56:33ZliyangRULES "minusFloat x x" and "timesFloat 0.0 x" break IEEE-754 compatibilityIn GHC/Base.lhs, a comment around line \~778 notes that the following rules for Doubles give the wrong answer for NaN:
```
"minusDouble x x" forall x#. (-##) x# x# = 0.0##
"timesDouble 0.0 x" forall x#. (*##) 0.0## x# = 0.0...In GHC/Base.lhs, a comment around line \~778 notes that the following rules for Doubles give the wrong answer for NaN:
```
"minusDouble x x" forall x#. (-##) x# x# = 0.0##
"timesDouble 0.0 x" forall x#. (*##) 0.0## x# = 0.0##
"timesDouble x 0.0" forall x#. (*##) x# 0.0## = 0.0##
```
However, immediately above are corresponding rules for Floats:
```
"minusFloat x x" forall x#. minusFloat# x# x# = 0.0#
"timesFloat x 0.0" forall x#. timesFloat# x# 0.0# = 0.0#
"timesFloat0.0 x" forall x#. timesFloat# 0.0# x# = 0.0#
```
These should probably be removed.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.0.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":"RULES \"minusFloat x x\" and \"timesFloat 0.0 x\" break IEEE-754 compatibility","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"In GHC/Base.lhs, a comment around line ~778 notes that the following rules for Doubles give the wrong answer for NaN:\r\n{{{\r\n\"minusDouble x x\" forall x#. (-##) x# x# = 0.0##\r\n\"timesDouble 0.0 x\" forall x#. (*##) 0.0## x# = 0.0##\r\n\"timesDouble x 0.0\" forall x#. (*##) x# 0.0## = 0.0##\r\n}}}\r\nHowever, immediately above are corresponding rules for Floats:\r\n{{{\r\n\"minusFloat x x\" forall x#. minusFloat# x# x# = 0.0#\r\n\"timesFloat x 0.0\" forall x#. timesFloat# x# 0.0# = 0.0#\r\n\"timesFloat0.0 x\" forall x#. timesFloat# 0.0# x# = 0.0#\r\n}}}\r\nThese should probably be removed.","type_of_failure":"OtherFailure","blocking":[]} -->7.2.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/5166Wrong calculation with Int642019-07-07T18:56:37ZmalphunctionWrong calculation with Int64Let's multiply 1524503639859200000 on 13:
```
$ ghci
Prelude> import Data.Int
Prelude Data.Int> 1524503639859200000 * 13
19818547318169600000 -- that's OK!
Prelude Data.Int> (1524503639859200000::Int64)*(13::Int64)
1371803244460048384 -...Let's multiply 1524503639859200000 on 13:
```
$ ghci
Prelude> import Data.Int
Prelude Data.Int> 1524503639859200000 * 13
19818547318169600000 -- that's OK!
Prelude Data.Int> (1524503639859200000::Int64)*(13::Int64)
1371803244460048384 -- FAIL!!!!!
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.12.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":"Wrong calculation with Int64","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Let's multiply 1524503639859200000 on 13:\r\n\r\n{{{\r\n$ ghci\r\nPrelude> import Data.Int\r\nPrelude Data.Int> 1524503639859200000 * 13\r\n19818547318169600000 -- that's OK!\r\nPrelude Data.Int> (1524503639859200000::Int64)*(13::Int64)\r\n1371803244460048384 -- FAIL!!!!!\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/5165GHC doesn't optimize FP excess precision properly2020-09-26T19:15:02ZEdward Z. YangGHC doesn't optimize FP excess precision properlyjmcarthur helped in constructing the test case. Consider the following program:
```
module Main where
{-# NOINLINE x #-}
{-# NOINLINE y #-}
x, y :: Double
x = 3
y = 7
main = print $ x/y == (3/7 :: Double)
```
When run on 32-bit Linux...jmcarthur helped in constructing the test case. Consider the following program:
```
module Main where
{-# NOINLINE x #-}
{-# NOINLINE y #-}
x, y :: Double
x = 3
y = 7
main = print $ x/y == (3/7 :: Double)
```
When run on 32-bit Linux, we get the following results:
```
ezyang@javelin:~$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.0.3
ezyang@javelin:~$ ghc --make Bar.hs -o Bar -O0 -fforce-recomp && ./Bar
[1 of 1] Compiling Main ( Bar.hs, Bar.o )
Linking Bar ...
True
ezyang@javelin:~$ ghc --make Bar.hs -o Bar -O -fforce-recomp && ./Bar
[1 of 1] Compiling Main ( Bar.hs, Bar.o )
Linking Bar ...
False
```
The second result should be True (and only false if `-fexcess-precision` is specified). I also tested on a devel2 build of GHC HEAD and got similar results.
This appears to be a regression from 6.12.1:
```
ezyang@javelin:~$ /usr/bin/ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.12.1
ezyang@javelin:~$ /usr/bin/ghc --make Bar.hs -o Bar -O && ./Bar
True
```
I also kind of suspect `-fexcess-precision` doesn't do anything for the native codegen (based on source code surfing), but it's hard to tell with this current bug.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.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":"GHC doesn't optimize FP excess precision properly","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"jmcarthur helped in constructing the test case. Consider the following program:\r\n\r\n{{{\r\nmodule Main where\r\n\r\n{-# NOINLINE x #-}\r\n{-# NOINLINE y #-}\r\nx, y :: Double\r\nx = 3\r\ny = 7\r\n\r\nmain = print $ x/y == (3/7 :: Double)\r\n}}}\r\n\r\nWhen run on 32-bit Linux, we get the following results:\r\n\r\n{{{\r\nezyang@javelin:~$ ghc --version\r\nThe Glorious Glasgow Haskell Compilation System, version 7.0.3\r\nezyang@javelin:~$ ghc --make Bar.hs -o Bar -O0 -fforce-recomp && ./Bar\r\n[1 of 1] Compiling Main ( Bar.hs, Bar.o )\r\nLinking Bar ...\r\nTrue\r\nezyang@javelin:~$ ghc --make Bar.hs -o Bar -O -fforce-recomp && ./Bar\r\n[1 of 1] Compiling Main ( Bar.hs, Bar.o )\r\nLinking Bar ...\r\nFalse\r\n}}}\r\n\r\nThe second result should be True (and only false if `-fexcess-precision` is specified). I also tested on a devel2 build of GHC HEAD and got similar results.\r\n\r\nThis appears to be a regression from 6.12.1:\r\n\r\n{{{\r\nezyang@javelin:~$ /usr/bin/ghc --version\r\nThe Glorious Glasgow Haskell Compilation System, version 6.12.1\r\nezyang@javelin:~$ /usr/bin/ghc --make Bar.hs -o Bar -O && ./Bar\r\nTrue\r\n}}}\r\n\r\nI also kind of suspect `-fexcess-precision` doesn't do anything for the native codegen (based on source code surfing), but it's hard to tell with this current bug.","type_of_failure":"OtherFailure","blocking":[]} -->7.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/5149NaNs produced by sorting mutable Double vectors2019-07-07T18:56:41Zdaniel.is.fischerNaNs produced by sorting mutable Double vectorsUnder some circumstances, sorting vectors introduces !NaNs into them when compiled with optimisations. This does not happen when compiled with -msse2 and apparently only on 32-bit systems. 7.0.2 and earlier didn't introduce !NaNs either,...Under some circumstances, sorting vectors introduces !NaNs into them when compiled with optimisations. This does not happen when compiled with -msse2 and apparently only on 32-bit systems. 7.0.2 and earlier didn't introduce !NaNs either, and for the attached programme (requires vector and vector-algorithms), the only difference in the assembly produced by 7.0.2 and 7.0.3 (apart from different unique names) is the presence of some FPU-freeings in 7.0.3's which 7.0.2 didn't produce, likely caused by the fix to #4914.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.0.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":"NaNs produced by sorting mutable Double vectors","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Under some circumstances, sorting vectors introduces !NaNs into them when compiled with optimisations. This does not happen when compiled with -msse2 and apparently only on 32-bit systems. 7.0.2 and earlier didn't introduce !NaNs either, and for the attached programme (requires vector and vector-algorithms), the only difference in the assembly produced by 7.0.2 and 7.0.3 (apart from different unique names) is the presence of some FPU-freeings in 7.0.3's which 7.0.2 didn't produce, likely caused by the fix to #4914.","type_of_failure":"OtherFailure","blocking":[]} -->7.0.4https://gitlab.haskell.org/ghc/ghc/-/issues/5129"evaluate" optimized away2023-12-15T20:11:41Zdons"evaluate" optimized awayReported on Stackoverflow: http://stackoverflow.com/questions/5697159/testing-for-error-calls-in-hunit
With optimizations on, the following program, which normally succeeds (correctly generating an exception), instead fails, and the exc...Reported on Stackoverflow: http://stackoverflow.com/questions/5697159/testing-for-error-calls-in-hunit
With optimizations on, the following program, which normally succeeds (correctly generating an exception), instead fails, and the exception is optimized away.
```
import Control.Exception
import Test.HUnit
throwIfNegative :: Int -> String
throwIfNegative n | n < 0 = error "negative"
| otherwise = "no worries"
{-# NOINLINE throwIfNegative #-}
case_negative =
handleJust errorCalls (const $ return ()) $ do
evaluate $ throwIfNegative (-1)
assertFailure "must throw when given a negative number"
where errorCalls (ErrorCall _) = Just ()
main = runTestTT $ TestCase case_negative
```
Looking at the core, after a few iterations, the call to `throwIfNegative` is dropped as dead code.
Using seq instead of evaluate is happy enough:
```
case_negative =
handleJust errorCalls (const $ return ()) $ do
throwIfNegative (-1) `seq` assertFailure "must throw when given a negative number"
where errorCalls (ErrorCall _) = Just ()
```
or a bang pattern:
```
case_negative =
handleJust errorCalls (const $ return ()) $ do
let !x = throwIfNegative (-1)
assertFailure "must throw when given a negative number"
where errorCalls (ErrorCall _) = Just ()
```
Possibly related to #2273
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.0.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":"\"evaluate\" optimized away","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.3","keywords":["evaluate","seq,"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Reported on Stackoverflow: http://stackoverflow.com/questions/5697159/testing-for-error-calls-in-hunit\r\n\r\nWith optimizations on, the following program, which normally succeeds (correctly generating an exception), instead fails, and the exception is optimized away.\r\n\r\n{{{\r\nimport Control.Exception\r\nimport Test.HUnit\r\n\r\nthrowIfNegative :: Int -> String\r\nthrowIfNegative n | n < 0 = error \"negative\"\r\n | otherwise = \"no worries\"\r\n{-# NOINLINE throwIfNegative #-}\r\n\r\ncase_negative =\r\n handleJust errorCalls (const $ return ()) $ do\r\n evaluate $ throwIfNegative (-1)\r\n assertFailure \"must throw when given a negative number\"\r\n where errorCalls (ErrorCall _) = Just ()\r\n\r\nmain = runTestTT $ TestCase case_negative\r\n}}}\r\n\r\nLooking at the core, after a few iterations, the call to `throwIfNegative` is dropped as dead code.\r\n\r\nUsing seq instead of evaluate is happy enough:\r\n\r\n{{{\r\ncase_negative =\r\n handleJust errorCalls (const $ return ()) $ do\r\n throwIfNegative (-1) `seq` assertFailure \"must throw when given a negative number\"\r\n where errorCalls (ErrorCall _) = Just ()\r\n}}}\r\n\r\nor a bang pattern:\r\n\r\n{{{\r\ncase_negative =\r\n handleJust errorCalls (const $ return ()) $ do\r\n let !x = throwIfNegative (-1)\r\n assertFailure \"must throw when given a negative number\"\r\n where errorCalls (ErrorCall _) = Just ()\r\n}}}\r\n\r\nPossibly related to #2273","type_of_failure":"OtherFailure","blocking":[]} -->8.4.2Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/5118Numeric.floatToDigits fails for large floatRange2019-07-07T18:56:50ZClaudiusMaximusNumeric.floatToDigits fails for large floatRangeI tried to write some high precision floating point datatype like this (corresponding to encodeFloat and decodeFloat format):
```
data HugeFloat = HugeFloat Integer Int
```
Mainly as an exercise to see how much slower it would be, but ...I tried to write some high precision floating point datatype like this (corresponding to encodeFloat and decodeFloat format):
```
data HugeFloat = HugeFloat Integer Int
```
Mainly as an exercise to see how much slower it would be, but got failures trying to print the values (ghci would consume all available memory and be rather unresponsive w.r.t. ctrl-C input).
Changing this line in my RealFloat instance from:
```
floatRange _ = (minBound, maxBound) -- fails
```
to:
```
floatRange _ = (minBound `div` 2, maxBound `div` 2) -- works
```
made the non-termination failures seemingly disappear.
With attached code, ghci fails if I type:
```
> 771 :: F1
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------------------- |
| Version | 6.12.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | claudiusmaximus@goto10.org |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Numeric.floatToDigits fails for large floatRange","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.12.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["claudiusmaximus@goto10.org"],"type":"Bug","description":"I tried to write some high precision floating point datatype like this (corresponding to encodeFloat and decodeFloat format):\r\n{{{\r\ndata HugeFloat = HugeFloat Integer Int\r\n}}}\r\nMainly as an exercise to see how much slower it would be, but got failures trying to print the values (ghci would consume all available memory and be rather unresponsive w.r.t. ctrl-C input).\r\n\r\nChanging this line in my RealFloat instance from:\r\n{{{\r\n floatRange _ = (minBound, maxBound) -- fails\r\n}}}\r\nto:\r\n{{{\r\n floatRange _ = (minBound `div` 2, maxBound `div` 2) -- works\r\n}}}\r\nmade the non-termination failures seemingly disappear.\r\n\r\nWith attached code, ghci fails if I type:\r\n{{{\r\n > 771 :: F1\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/5114-with-rtsopts, ghc_rts_opts not honoured2019-07-07T18:56:50Zguest-with-rtsopts, ghc_rts_opts not honouredusing -with-rtsopts or ghc_rts_opts to build a program, the program subsequently aborts with "Most RTS options are disabled. Link with -rtsopts to enable them." I don't have the environment variable GHCRTS.
```
$ echo 'main = print (fol...using -with-rtsopts or ghc_rts_opts to build a program, the program subsequently aborts with "Most RTS options are disabled. Link with -rtsopts to enable them." I don't have the environment variable GHCRTS.
```
$ echo 'main = print (foldl1 (+) [1..100000])' > main.hs
$ ghc --make -with-rtsopts='-K1m' main.hs
$ ./main
main: Most RTS options are disabled. Link with -rtsopts to enable them.
```
```
$ rm main main.hi main.o
$ echo 'char *ghc_rts_opts = "-K1m";' > ro.c
$ ghc --make main.hs ro.c
$ ./main
main: Most RTS options are disabled. Link with -rtsopts to enable them.
```
I obtained ghc from the generic binary tarball for linux x86 32-bit.
This is present in both 7.0.2 and 7.0.3. I don't know about 7.0.1.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.0.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | trebla@vex.net |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"-with-rtsopts, ghc_rts_opts not honoured","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["trebla@vex.net"],"type":"Bug","description":"using -with-rtsopts or ghc_rts_opts to build a program, the program subsequently aborts with \"Most RTS options are disabled. Link with -rtsopts to enable them.\" I don't have the environment variable GHCRTS.\r\n\r\n{{{\r\n$ echo 'main = print (foldl1 (+) [1..100000])' > main.hs\r\n$ ghc --make -with-rtsopts='-K1m' main.hs\r\n$ ./main\r\nmain: Most RTS options are disabled. Link with -rtsopts to enable them.\r\n}}}\r\n\r\n{{{\r\n$ rm main main.hi main.o\r\n$ echo 'char *ghc_rts_opts = \"-K1m\";' > ro.c\r\n$ ghc --make main.hs ro.c\r\n$ ./main\r\nmain: Most RTS options are disabled. Link with -rtsopts to enable them.\r\n}}}\r\n\r\nI obtained ghc from the generic binary tarball for linux x86 32-bit.\r\n\r\nThis is present in both 7.0.2 and 7.0.3. I don't know about 7.0.1.","type_of_failure":"OtherFailure","blocking":[]} -->7.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/5088TextEncoding iconv instances are shared between threads2019-07-07T18:56:57ZbatterseapowerTextEncoding iconv instances are shared between threadsThe icon_t pointers returned from iconv_open should only be while processing a single text stream, because in general they may contain some state about the text being processed.
However, we currently don't take any measures to prevent t...The icon_t pointers returned from iconv_open should only be while processing a single text stream, because in general they may contain some state about the text being processed.
However, we currently don't take any measures to prevent this from happening, as GHC.IO.Encoding.Iconv.mkTextEncoding shares one pointer amongst all use sites of that TextEncoding in future -- even if those uses occur on different threads!
This could lead to arbitrarily strange heisenbugs depending on the iconv implementation.
Either we should:
1. Make it clear that the user should recreate a TextEncoding anew for every use site
1. (Better), elaborate the TextEncoding interface so that we can call iconv_open/iconv_close at the start and end of processing a particular text block, and ensure that the token doesn't escape so it can be accessed from multiple threads simultaneously
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.0.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":"TextEncoding iconv instances are shared between threads","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The icon_t pointers returned from iconv_open should only be while processing a single text stream, because in general they may contain some state about the text being processed.\r\n\r\nHowever, we currently don't take any measures to prevent this from happening, as GHC.IO.Encoding.Iconv.mkTextEncoding shares one pointer amongst all use sites of that TextEncoding in future -- even if those uses occur on different threads!\r\n\r\nThis could lead to arbitrarily strange heisenbugs depending on the iconv implementation.\r\n\r\nEither we should:\r\n\r\n 1. Make it clear that the user should recreate a TextEncoding anew for every use site\r\n\r\n 2. (Better), elaborate the TextEncoding interface so that we can call iconv_open/iconv_close at the start and end of processing a particular text block, and ensure that the token doesn't escape so it can be accessed from multiple threads simultaneously\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/5070dph and new code generator don't play nicely with each other2019-07-07T18:57:01ZEdward Z. Yangdph and new code generator don't play nicely with each otherI'm looking at the current failure of DPH with the new code generator,
which is a bit different from what I've dealt with before. The bug appears
to be in the compiled libraries code, and I can tickle it with the
following minimized exam...I'm looking at the current failure of DPH with the new code generator,
which is a bit different from what I've dealt with before. The bug appears
to be in the compiled libraries code, and I can tickle it with the
following minimized example:
```
{-# LANGUAGE ParallelArrays #-}
{-# OPTIONS -fvectorise #-}
module PrimesVect where
import Data.Array.Parallel.Prelude
import qualified Prelude
f :: PArray Bool
f = toPArrayP f'
f' :: [:Bool:]
f' = [: True | _ <- singletonP True, g emptyP:]
g :: [:Bool:] -> Bool
g ps = andP [: True | _ <- ps:]
```
and a runner:
```
import qualified Data.Array.Parallel.PArray as P
import PrimesVect
main = print (P.toList f)
```
I expect to get \[True\], but instead I get:
```
dph-primespj-fast: libraries/vector/Data/Vector/Generic.hs:369 (slice): invalid slice (0,1,0)
dph-primespj-fast: thread blocked indefinitely in an MVar operation
```
Now, in the situation that the library code is broken, I'd usually try to inline
all of the library code and then pare that down into something manageable. Unfortunately,
DPH is pretty closely tied to the compiler, so I don't see an easy way to do that.
So I'm not really sure how to go about debugging this.
Note that we can't work on this bug until #5065 is resolved, since these tests are currently failing for unrelated reasons.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | --------------------- |
| Version | 7.0.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Data Parallel Haskell |
| Test case | |
| Differential revisions | |
| BlockedBy | #5065 |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[5065],"summary":"dph and new code generator don't play nicely with each other","status":"New","operating_system":"","component":"Data Parallel Haskell","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I'm looking at the current failure of DPH with the new code generator,\r\nwhich is a bit different from what I've dealt with before. The bug appears\r\nto be in the compiled libraries code, and I can tickle it with the\r\nfollowing minimized example:\r\n\r\n{{{\r\n {-# LANGUAGE ParallelArrays #-}\r\n {-# OPTIONS -fvectorise #-}\r\n module PrimesVect where\r\n\r\n import Data.Array.Parallel.Prelude\r\n import qualified Prelude \r\n \r\n f :: PArray Bool \r\n f = toPArrayP f'\r\n\r\n f' :: [:Bool:]\r\n f' = [: True | _ <- singletonP True, g emptyP:]\r\n\r\n g :: [:Bool:] -> Bool\r\n g ps = andP [: True | _ <- ps:]\r\n}}}\r\n\r\nand a runner:\r\n\r\n{{{\r\n import qualified Data.Array.Parallel.PArray as P\r\n import PrimesVect\r\n\r\n main = print (P.toList f)\r\n}}}\r\n\r\nI expect to get [True], but instead I get:\r\n\r\n{{{\r\n dph-primespj-fast: libraries/vector/Data/Vector/Generic.hs:369 (slice): invalid slice (0,1,0)\r\n dph-primespj-fast: thread blocked indefinitely in an MVar operation\r\n}}}\r\n\r\nNow, in the situation that the library code is broken, I'd usually try to inline\r\nall of the library code and then pare that down into something manageable. Unfortunately,\r\nDPH is pretty closely tied to the compiler, so I don't see an easy way to do that.\r\nSo I'm not really sure how to go about debugging this.\r\n\r\nNote that we can't work on this bug until #5065 is resolved, since these tests are currently failing for unrelated reasons.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1benlbenl