GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:39:34Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/9668Unicode info is out of date2019-07-07T18:39:34ZDavid FeuerUnicode info is out of dateThe automatically generated `WCsubst.c` was last generated in 2011. The Unicode standard has been updated several times since then. I would like to try to replace that whole mechanism with something a little more cache-friendly, but at t...The automatically generated `WCsubst.c` was last generated in 2011. The Unicode standard has been updated several times since then. I would like to try to replace that whole mechanism with something a little more cache-friendly, but at the very least the tables need to be right. Unfortunately, the script that generates this file gives no information about its input format, or just where a file with the right format is supposed to come from.7.10.1Edward KmettEdward Kmetthttps://gitlab.haskell.org/ghc/ghc/-/issues/9619HPC Code Coverage complains when two exactly the same mix files are on the path2019-07-07T18:39:47ZKasperHPC Code Coverage complains when two exactly the same mix files are on the pathCabal's --enable-library-coverage flag generates the .mix files in the dist/mix directory that cabal creates during compilation. I have two test suites, integration tests and unit tests. Those test suites calll tests for moduleA in modul...Cabal's --enable-library-coverage flag generates the .mix files in the dist/mix directory that cabal creates during compilation. I have two test suites, integration tests and unit tests. Those test suites calll tests for moduleA in moduleATest. Unfortunately, in a first version, the integration tests and unit tests for moduleA were both present in moduleATest. Therefore, the unit test suite (in UnitTests.hs) and the integration test suite (in IntegrationTests.hs) both 'use' the moduleATest by linking in tests from that module. This leads to cabal generating a directory integration-tests and a directory unit-tests with .mix files, but the moduleATest.mix file is present in both directories. When performing hpc sum and hpc markup to get the total result of the test runs I need to specify the directories where the mix files are present (so dist/hpc/mix/unit-tests and dist/hpc/mix/integration-tests) and it will then complain that it finds moduleATest.mix file twice.
This issue is not present when using the -fhpc flag, as the directory structure with integration-tests and unit-tests is not present in the .hpc directory at that moment. That being said, I don't think it's a cabal issue as it's more or less expected what they're doing, generating the mix files necessary to instrument integration-tests and unit-tests separately.
Priority put to lowest because I can work around it by diving moduleATest up in moduleATest and moduleAIntegrationTest, which is saner in the end anyway. But I guess somebody will come up with a use case where a split up isn't possible, in the future.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 7.8.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | lowest |
| Resolution | Unresolved |
| Component | Code Coverage |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"HPC Code Coverage complains when two exactly the same mix files are on the path","status":"New","operating_system":"","component":"Code Coverage","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Cabal's --enable-library-coverage flag generates the .mix files in the dist/mix directory that cabal creates during compilation. I have two test suites, integration tests and unit tests. Those test suites calll tests for moduleA in moduleATest. Unfortunately, in a first version, the integration tests and unit tests for moduleA were both present in moduleATest. Therefore, the unit test suite (in UnitTests.hs) and the integration test suite (in IntegrationTests.hs) both 'use' the moduleATest by linking in tests from that module. This leads to cabal generating a directory integration-tests and a directory unit-tests with .mix files, but the moduleATest.mix file is present in both directories. When performing hpc sum and hpc markup to get the total result of the test runs I need to specify the directories where the mix files are present (so dist/hpc/mix/unit-tests and dist/hpc/mix/integration-tests) and it will then complain that it finds moduleATest.mix file twice.\r\n\r\n\r\nThis issue is not present when using the -fhpc flag, as the directory structure with integration-tests and unit-tests is not present in the .hpc directory at that moment. That being said, I don't think it's a cabal issue as it's more or less expected what they're doing, generating the mix files necessary to instrument integration-tests and unit-tests separately. \r\n\r\nPriority put to lowest because I can work around it by diving moduleATest up in moduleATest and moduleAIntegrationTest, which is saner in the end anyway. But I guess somebody will come up with a use case where a split up isn't possible, in the future.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/9616Incorrect numbers from HpcMarkup.markup_plugin2019-07-07T18:39:48ZDavid FeuerIncorrect numbers from HpcMarkup.markup_plugin`showBigNum` in the `openTick` function accidentally puts 0s in the wrong place when formatting large numbers. 12345 will be formatted as 120,345 instead of 012,345. The correct answer is probably to add some locale-specific numeric form...`showBigNum` in the `openTick` function accidentally puts 0s in the wrong place when formatting large numbers. 12345 will be formatted as 120,345 instead of 012,345. The correct answer is probably to add some locale-specific numeric formatting stuff somewhere, but until then, I'll just fix this.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 7.9 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Code Coverage |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Incorrect numbers from HpcMarkup.markup_plugin","status":"New","operating_system":"","component":"Code Coverage","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.9","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"`showBigNum` in the `openTick` function accidentally puts 0s in the wrong place when formatting large numbers. 12345 will be formatted as 120,345 instead of 012,345. The correct answer is probably to add some locale-specific numeric formatting stuff somewhere, but until then, I'll just fix this.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/9603getArgs path transformation is broken on Windows2019-07-07T18:39:51ZgintasgetArgs path transformation is broken on WindowsIt looks like System.Environment.getArgs is trying to be smart on Windows and to transform arguments drive paths to environment-local paths (e.g., 'C:/' =\> 'C:\\msys64', but it messes up the mangling somewhere if the path is not at the ...It looks like System.Environment.getArgs is trying to be smart on Windows and to transform arguments drive paths to environment-local paths (e.g., 'C:/' =\> 'C:\\msys64', but it messes up the mangling somewhere if the path is not at the beginning of the argument:
$ args "C:/"
\["C:/"\]
$ /tmp/args " C:/"
\[" C;C:\\\\msys64"\]
Note the leading "C;" which makes no sense.
$ uname -s
MINGW64_NT-6.3
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.9 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ekmett, hvr |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"getArgs path transformation is broken on Windows","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.9","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ekmett","hvr"],"type":"Bug","description":"It looks like System.Environment.getArgs is trying to be smart on Windows and to transform arguments drive paths to environment-local paths (e.g., 'C:/' => 'C:\\msys64', but it messes up the mangling somewhere if the path is not at the beginning of the argument:\r\n\r\n$ args \"C:/\"\r\n[\"C:/\"]\r\n\r\n$ /tmp/args \" C:/\"\r\n[\" C;C:\\\\msys64\"]\r\n\r\nNote the leading \"C;\" which makes no sense.\r\n\r\n$ uname -s\r\nMINGW64_NT-6.3\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/9564Floating point subnormals overrounded on output2019-07-07T18:40:00Zjrp2014Floating point subnormals overrounded on outputThe following test suggests that GHC is overrounding Float subnormals, when printing them out
```
Prelude> 2**(-149)
1.401298464324817e-45
Prelude> 2**(-149) :: Float
1.0e-45
Prelude> isDenormalized it
True
Prelude>
Prelude> 2**(-149) *...The following test suggests that GHC is overrounding Float subnormals, when printing them out
```
Prelude> 2**(-149)
1.401298464324817e-45
Prelude> 2**(-149) :: Float
1.0e-45
Prelude> isDenormalized it
True
Prelude>
Prelude> 2**(-149) * 2**(100) * 2**(49) :: Float
1.0
```
By comparison
```
#include <stdio.h>
#include <stdlib.h>
int main (void)
{
float clang_dec, clang_hex, libc_dec, libc_hex;
clang_dec = 1.401298464324817e-45;
clang_hex = 0x0.000002P-126;
printf("clang (from decimal) = %a\n",clang_dec);
printf("clang (from decimal) = %g\n",clang_dec);
printf("clang (from hex) = %a\n",clang_hex);
printf("clang (from hex) = %g\n",clang_hex);
libc_dec = strtod("1.401298464324817e-45",NULL);
libc_hex = strtod("0x0.000002P-126",NULL);
printf("libc (from decimal) = %a\n",libc_dec);
printf("libc (from decimal) = %g\n",libc_dec);
printf("libc (from hex) = %a\n",libc_hex);
printf("libc (from hex) = %g\n",libc_hex);
}
```
produces
```
clang (from decimal) = 0x1p-149
clang (from decimal) = 1.4013e-45
clang (from hex) = 0x1p-149
clang (from hex) = 1.4013e-45
libc (from decimal) = 0x1p-149
libc (from decimal) = 1.4013e-45
libc (from hex) = 0x1p-149
libc (from hex) = 1.4013e-45
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.8.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | simonmar |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Floating point subnormals overrounded on output","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"simonmar"},"version":"7.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["simonmar"],"type":"Bug","description":"The following test suggests that GHC is overrounding Float subnormals, when printing them out\r\n{{{\r\nPrelude> 2**(-149)\r\n1.401298464324817e-45\r\nPrelude> 2**(-149) :: Float\r\n1.0e-45\r\nPrelude> isDenormalized it\r\nTrue\r\nPrelude>\r\nPrelude> 2**(-149) * 2**(100) * 2**(49) :: Float\r\n1.0\r\n}}}\r\n\r\n\r\nBy comparison\r\n\r\n\r\n{{{\r\n#include <stdio.h>\r\n#include <stdlib.h>\r\n\r\nint main (void)\r\n{\r\n float clang_dec, clang_hex, libc_dec, libc_hex;\r\n\r\n clang_dec = 1.401298464324817e-45;\r\n clang_hex = 0x0.000002P-126;\r\n printf(\"clang (from decimal) = %a\\n\",clang_dec);\r\n printf(\"clang (from decimal) = %g\\n\",clang_dec);\r\n printf(\"clang (from hex) = %a\\n\",clang_hex);\r\n printf(\"clang (from hex) = %g\\n\",clang_hex);\r\n\r\n libc_dec = strtod(\"1.401298464324817e-45\",NULL);\r\n libc_hex = strtod(\"0x0.000002P-126\",NULL);\r\n printf(\"libc (from decimal) = %a\\n\",libc_dec);\r\n printf(\"libc (from decimal) = %g\\n\",libc_dec);\r\n printf(\"libc (from hex) = %a\\n\",libc_hex);\r\n printf(\"libc (from hex) = %g\\n\",libc_hex);\r\n}\r\n\r\n}}}\r\n\r\nproduces\r\n\r\n\r\n{{{\r\nclang (from decimal) = 0x1p-149\r\nclang (from decimal) = 1.4013e-45\r\nclang (from hex) = 0x1p-149\r\nclang (from hex) = 1.4013e-45\r\nlibc (from decimal) = 0x1p-149\r\nlibc (from decimal) = 1.4013e-45\r\nlibc (from hex) = 0x1p-149\r\nlibc (from hex) = 1.4013e-45\r\n\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/9533Signed/unsigned integer difference between compiled and interpreted code2019-07-07T18:40:08ZMichaelBurgeSigned/unsigned integer difference between compiled and interpreted codeThe following code outputs "A".
```hs
import Data.Word
x :: Word
x = 10
y :: Word
y = 11
test = case x - y of
-1 -> "A"
_ -> "B"
main = putStrLn $ show test
```
However, adding a new case that isn't matched causes...The following code outputs "A".
```hs
import Data.Word
x :: Word
x = 10
y :: Word
y = 11
test = case x - y of
-1 -> "A"
_ -> "B"
main = putStrLn $ show test
```
However, adding a new case that isn't matched causes the output to change:
```hs
import Data.Word
x :: Word
x = 10
y :: Word
y = 11
test = case x - y of
5 -> "C"
-1 -> "A"
_ -> "B"
main = putStrLn $ show test
```
With the extra '5 -\> "C"' line in the case, the output is "B".
It gets weirder - interpreted code actually continues to match the -1 case. With the second example in a file 'T.hs', here is a GHCi session:
```
Prelude Main> :l *T.hs
[1 of 1] Compiling Main ( T.hs, interpreted )
Ok, modules loaded: Main.
*Main> main
"A"
*Main> :l T.hs
Ok, modules loaded: Main.
Prelude Main> main
"B"
Prelude Main>
```
These examples suggest to me at least 3 improvements:
- Issue a warning when a negative number is used in a case statement in unsigned context
- Interpreted code should give the same result as compiled code
- Adding a case that isn't matched shouldn't change which other patterns get matched
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Windows |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Signed/unsigned integer difference between compiled and interpreted code","status":"New","operating_system":"Windows","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The following code outputs \"A\".\r\n{{{#!hs\r\nimport Data.Word\r\n\r\nx :: Word\r\nx = 10\r\n\r\ny :: Word\r\ny = 11\r\n\r\ntest = case x - y of\r\n -1 -> \"A\"\r\n _ -> \"B\"\r\nmain = putStrLn $ show test\r\n}}}\r\n\r\nHowever, adding a new case that isn't matched causes the output to change:\r\n{{{#!hs\r\nimport Data.Word\r\n\r\nx :: Word\r\nx = 10\r\n\r\ny :: Word\r\ny = 11\r\n\r\ntest = case x - y of\r\n 5 -> \"C\"\r\n -1 -> \"A\"\r\n _ -> \"B\"\r\nmain = putStrLn $ show test\r\n}}}\r\n\r\nWith the extra '5 -> \"C\"' line in the case, the output is \"B\".\r\n\r\nIt gets weirder - interpreted code actually continues to match the -1 case. With the second example in a file 'T.hs', here is a GHCi session:\r\n{{{\r\nPrelude Main> :l *T.hs\r\n[1 of 1] Compiling Main ( T.hs, interpreted )\r\nOk, modules loaded: Main.\r\n*Main> main\r\n\"A\"\r\n*Main> :l T.hs\r\nOk, modules loaded: Main.\r\nPrelude Main> main\r\n\"B\"\r\nPrelude Main>\r\n}}}\r\n\r\nThese examples suggest to me at least 3 improvements:\r\n* Issue a warning when a negative number is used in a case statement in unsigned context\r\n* Interpreted code should give the same result as compiled code\r\n* Adding a case that isn't matched shouldn't change which other patterns get matched","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/9530min / max do not always return the other argument when one of the arguments i...2019-07-07T18:40:08Zjrp2014min / max do not always return the other argument when one of the arguments is NaNI assume that this is well-known, but it tripped me up:
```
Prelude> let inf = 1/0
Prelude> let nan = 0/0
Prelude> min nan inf
Infinity
Prelude> min inf nan
NaN
Prelude> min 3 nan
NaN
Prelude> min nan 3
3.0
Prelude> max nan inf
NaN
Pre...I assume that this is well-known, but it tripped me up:
```
Prelude> let inf = 1/0
Prelude> let nan = 0/0
Prelude> min nan inf
Infinity
Prelude> min inf nan
NaN
Prelude> min 3 nan
NaN
Prelude> min nan 3
3.0
Prelude> max nan inf
NaN
Prelude> max inf nan
Infinity
Prelude> max 3 nan
3.0
Prelude> max nan 3
NaN
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Prelude |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"min / max do not always return a NaN when one of the arguments is NaN","status":"New","operating_system":"","component":"Prelude","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I assume that this is well-known, but it tripped me up:\r\n\r\n{{{\r\nPrelude> let inf = 1/0\r\nPrelude> let nan = 0/0\r\nPrelude> min nan inf\r\nInfinity\r\nPrelude> min inf nan\r\nNaN\r\nPrelude> min 3 nan\r\nNaN\r\nPrelude> min nan 3\r\n3.0\r\nPrelude> max nan inf\r\nNaN\r\nPrelude> max inf nan\r\nInfinity\r\nPrelude> max 3 nan\r\n3.0\r\nPrelude> max nan 3\r\nNaN\r\n\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/9525+RTS -xc stack trace sometimes reported twice2019-07-07T18:40:10ZÖmer Sinan Ağacan+RTS -xc stack trace sometimes reported twiceNot sure if really a bug but just wanted to show. If this is a bug I'm hoping to fix this myself but I may need some guidance.
Stack trace reported by `+RTS -xc` is sometimes printed twice. This program reports it only once, as expected...Not sure if really a bug but just wanted to show. If this is a bug I'm hoping to fix this myself but I may need some guidance.
Stack trace reported by `+RTS -xc` is sometimes printed twice. This program reports it only once, as expected:
```haskell
f :: Int -> Int
f = error "hello"
main = print (f 20)
```
```
➜ ghc_patch ./error +RTS -xc
*** Exception (reporting due to +RTS -xc): (THUNK_1_0), stack trace:
Main.f,
called from Main.CAF
--> evaluated by: Main.main,
called from Main.CAF
error: hello
```
But if I change it to this:
```haskell
f :: Int -> Int
f x =
let x = x + 20
in x
main = print (f 20)
```
Stack trace is reported twice:
```
➜ ghc_patch ./error +RTS -xc
*** Exception (reporting due to +RTS -xc): (THUNK_STATIC), stack trace:
Main.f.x,
called from Main.f,
called from Main.main,
called from Main.CAF
*** Exception (reporting due to +RTS -xc): (THUNK_STATIC), stack trace:
Main.f.x,
called from Main.f,
called from Main.main,
called from Main.CAF
error: <<loop>>
```
Can anyone confirm that this is really a bug?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.8.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | simonmar |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"+RTS -xc stack trace sometimes reported twice","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"osa1"},"version":"7.8.3","keywords":["error","profiling,","stack","trace,"],"differentials":[],"test_case":"","architecture":"","cc":["simonmar"],"type":"Bug","description":"Not sure if really a bug but just wanted to show. If this is a bug I'm hoping to fix this myself but I may need some guidance.\r\n\r\nStack trace reported by `+RTS -xc` is sometimes printed twice. This program reports it only once, as expected:\r\n\r\n{{{#!haskell\r\nf :: Int -> Int\r\nf = error \"hello\"\r\n\r\nmain = print (f 20)\r\n}}}\r\n\r\n{{{\r\n➜ ghc_patch ./error +RTS -xc \r\n*** Exception (reporting due to +RTS -xc): (THUNK_1_0), stack trace: \r\n Main.f,\r\n called from Main.CAF\r\n --> evaluated by: Main.main,\r\n called from Main.CAF\r\nerror: hello\r\n}}}\r\n\r\nBut if I change it to this:\r\n\r\n{{{#!haskell\r\nf :: Int -> Int\r\nf x =\r\n let x = x + 20\r\n in x\r\n\r\nmain = print (f 20)\r\n}}}\r\n\r\nStack trace is reported twice:\r\n\r\n{{{\r\n➜ ghc_patch ./error +RTS -xc \r\n*** Exception (reporting due to +RTS -xc): (THUNK_STATIC), stack trace: \r\n Main.f.x,\r\n called from Main.f,\r\n called from Main.main,\r\n called from Main.CAF\r\n*** Exception (reporting due to +RTS -xc): (THUNK_STATIC), stack trace: \r\n Main.f.x,\r\n called from Main.f,\r\n called from Main.main,\r\n called from Main.CAF\r\nerror: <<loop>>\r\n}}}\r\n\r\nCan anyone confirm that this is really a bug?","type_of_failure":"OtherFailure","blocking":[]} -->Ömer Sinan AğacanÖmer Sinan Ağacanhttps://gitlab.haskell.org/ghc/ghc/-/issues/9504LLVM backend TBAA is too aggressive2019-07-07T18:40:15ZrwbartonLLVM backend TBAA is too aggressiveAt https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/Backends/LLVM/Alias\#HowtoTrackTBAAinformation there is written
> It \[a memory load/store\] is very rarely of the form:
>
> ```
> x = Sp + 8
> I64[x] = ...
> ```
>
> And when...At https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/Backends/LLVM/Alias\#HowtoTrackTBAAinformation there is written
> It \[a memory load/store\] is very rarely of the form:
>
> ```
> x = Sp + 8
> I64[x] = ...
> ```
>
> And when it is, 'it is' (unconfirmed) always deriving a "heap" pointer, "stack" pointers are always of the in-line variety.
In fact commit e10589a505b44f4f0394500c6a0d2db5baa7f3f4 treats any memory access through a Cmm local variable as having the "other" type, which cannot alias any non-"other" address.
But it turns out that a Cmm local might be either an offset from Sp (#9125, though TBAA doesn't seem to have been the cause of the bad code there) or an offset from a Cmm global variable (#9308). In general, we don't know anything about what it might be so we should conservatively use the "top" "type".
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | --------------- |
| Version | 7.8.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (LLVM) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"LLVM backend TBAA is too aggressive","status":"New","operating_system":"","component":"Compiler (LLVM)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"At https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/Backends/LLVM/Alias#HowtoTrackTBAAinformation there is written\r\n\r\n> It [a memory load/store] is very rarely of the form:\r\n> {{{\r\n> x = Sp + 8\r\n> I64[x] = ...\r\n> }}}\r\n> And when it is, 'it is' (unconfirmed) always deriving a \"heap\" pointer, \"stack\" pointers are always of the in-line variety.\r\n\r\nIn fact commit e10589a505b44f4f0394500c6a0d2db5baa7f3f4 treats any memory access through a Cmm local variable as having the \"other\" type, which cannot alias any non-\"other\" address.\r\n\r\nBut it turns out that a Cmm local might be either an offset from Sp (#9125, though TBAA doesn't seem to have been the cause of the bad code there) or an offset from a Cmm global variable (#9308). In general, we don't know anything about what it might be so we should conservatively use the \"top\" \"type\".","type_of_failure":"OtherFailure","blocking":[]} -->8.2.1https://gitlab.haskell.org/ghc/ghc/-/issues/9494Probable data corruption with GHCi 7.8.* and Zlib2019-07-07T18:40:17Znominolo@gmail.comProbable data corruption with GHCi 7.8.* and ZlibThe following program causes Zlib data corruption errors when run from inside GHCi. It launches two threads which then concurrently read a file, compress it, and immediately decompress it. You need libraries `zlib`, `SHA`, and `async`.
...The following program causes Zlib data corruption errors when run from inside GHCi. It launches two threads which then concurrently read a file, compress it, and immediately decompress it. You need libraries `zlib`, `SHA`, and `async`.
```
module Main where
import qualified Codec.Compression.Zlib as Zlib
import qualified Data.ByteString.Lazy as BL
import qualified Data.ByteString.Internal as BI
import Control.Exception (bracket)
import Control.Concurrent
import Control.Monad
import Control.Exception ( evaluate)
import Data.Digest.Pure.SHA ( sha1) -- from the 'SHA' package
import Control.Concurrent.Async ( mapConcurrently)
import System.Mem ( performGC )
import Debug.Trace
test :: Int -> IO String
test _ = do
tid <- myThreadId
-- testdata is: dd if=/dev/urandom of=/tmp/testdata bs=100k count=100
-- Could also be replaced by: (BL.take (10^7) "/dev/urandom")
dat <- BL.readFile "/tmp/testdata"
let cbuf = Zlib.compress $ traceChunks tid $ dat
s <- evaluate $ sha1 $ Zlib.decompress $ cbuf
return $ show s
where
-- We used this to check whether buffers were reused by different threads, but that
-- doesn't seem to be the case. Removing the call to traceChunks, however, makes it
-- harder to reproduce possibly because of scheduler effects. In a much larger program
-- it could be reproduced more easily without the trace, but in this small example
-- tracing seems to cause the right amount of nondeterminism.
traceChunks tid bs =
BL.fromChunks
$ zipWith (\n x -> trace (show tid ++ ":" ++ showBS x) x) [1..]
$ BL.toChunks bs
showBS (BI.PS ptr off len) = show ptr
main = do
r <- withGCThread $ mapConcurrently (test) ([1..2] :: [Int])
putStrLn $ show $ r
where
-- Regularly forcing the GC makes the test-case more reproducible.
withGCThread io =
bracket (forkIO $ forever $ performGC >> threadDelay 1000)
killThread
(const io)
```
The output should be something like:
```
...
ThreadId 51:0x00000001091ee010
ThreadId 49:0x00000001091a7010
...
ThreadId 49:0x000000010986f010
zlib-test-case.hs: user error (Codec.Compression.Zlib: incorrect data check)
```
You'll get different Zlib errors, depending on where it detects the inconsistency. Sometimes Zlib doesn't throw an error, but the checksums are different.
So far we've only been able to reproduce this using GHCi 7.8.3 on both Linux (NixOS) and Mac. We haven't been able to trigger it with a compiled executable, nor with GHCi 7.6.3. It **was** reproducable with HEAD from Jan 30 (I had that lying around somewhere).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | hvr |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Probable data corruption with GHCi 7.8.* and Zlib","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["hvr"],"type":"Bug","description":"The following program causes Zlib data corruption errors when run from inside GHCi. It launches two threads which then concurrently read a file, compress it, and immediately decompress it. You need libraries `zlib`, `SHA`, and `async`.\r\n\r\n{{{\r\nmodule Main where\r\n\r\nimport qualified Codec.Compression.Zlib as Zlib\r\nimport qualified Data.ByteString.Lazy as BL\r\nimport qualified Data.ByteString.Internal as BI\r\n\r\nimport Control.Exception (bracket)\r\nimport Control.Concurrent\r\nimport Control.Monad\r\nimport Control.Exception ( evaluate)\r\nimport Data.Digest.Pure.SHA ( sha1) -- from the 'SHA' package\r\nimport Control.Concurrent.Async ( mapConcurrently)\r\nimport System.Mem ( performGC )\r\n\r\nimport Debug.Trace\r\n\r\ntest :: Int -> IO String\r\ntest _ = do\r\n tid <- myThreadId\r\n\r\n -- testdata is: dd if=/dev/urandom of=/tmp/testdata bs=100k count=100\r\n -- Could also be replaced by: (BL.take (10^7) \"/dev/urandom\")\r\n dat <- BL.readFile \"/tmp/testdata\"\r\n\r\n let cbuf = Zlib.compress $ traceChunks tid $ dat\r\n s <- evaluate $ sha1 $ Zlib.decompress $ cbuf\r\n return $ show s\r\n where\r\n -- We used this to check whether buffers were reused by different threads, but that\r\n -- doesn't seem to be the case. Removing the call to traceChunks, however, makes it\r\n -- harder to reproduce possibly because of scheduler effects. In a much larger program\r\n -- it could be reproduced more easily without the trace, but in this small example\r\n -- tracing seems to cause the right amount of nondeterminism.\r\n traceChunks tid bs =\r\n BL.fromChunks\r\n $ zipWith (\\n x -> trace (show tid ++ \":\" ++ showBS x) x) [1..]\r\n $ BL.toChunks bs\r\n\r\n showBS (BI.PS ptr off len) = show ptr\r\n\r\n\r\nmain = do\r\n r <- withGCThread $ mapConcurrently (test) ([1..2] :: [Int])\r\n putStrLn $ show $ r\r\n where\r\n -- Regularly forcing the GC makes the test-case more reproducible.\r\n withGCThread io =\r\n bracket (forkIO $ forever $ performGC >> threadDelay 1000)\r\n killThread\r\n (const io)\r\n}}}\r\n\r\nThe output should be something like:\r\n{{{\r\n...\r\nThreadId 51:0x00000001091ee010\r\nThreadId 49:0x00000001091a7010\r\n...\r\nThreadId 49:0x000000010986f010\r\nzlib-test-case.hs: user error (Codec.Compression.Zlib: incorrect data check)\r\n}}}\r\n\r\nYou'll get different Zlib errors, depending on where it detects the inconsistency. Sometimes Zlib doesn't throw an error, but the checksums are different.\r\n\r\nSo far we've only been able to reproduce this using GHCi 7.8.3 on both Linux (NixOS) and Mac. We haven't been able to trigger it with a compiled executable, nor with GHCi 7.6.3. It '''was''' reproducable with HEAD from Jan 30 (I had that lying around somewhere).\r\n","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/9454Unregisterized builds failing due to multiple uniques assigned to same FastSt...2019-07-07T18:40:20ZEdward Z. YangUnregisterized builds failing due to multiple uniques assigned to same FastStringWhen compiling with `--enable-unregisterised`, we get this failure:
```
"inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -this-package-key conta_4P4
dHnD3A89EkvERxmaFmd -hide-all-packages -i -ilibraries/contain...When compiling with `--enable-unregisterised`, we get this failure:
```
"inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -this-package-key conta_4P4
dHnD3A89EkvERxmaFmd -hide-all-packages -i -ilibraries/containers/. -ilibraries/containers/dist-install
/build -ilibraries/containers/dist-install/build/autogen -Ilibraries/containers/dist-install/build -Il
ibraries/containers/dist-install/build/autogen -Ilibraries/containers/include -optP-include -optPli
braries/containers/dist-install/build/autogen/cabal_macros.h -package-key array_H3W2D8UaI9TKGEhUuQHax2
-package-key base_DiPQ1siqG3SBjHauL3L03p -package-key deeps_L0rJEVU1Zgn8x0Qs5aTOsU -package-key ghcpr
_BE58KUgBe9ELCsPXiJ1Q2r -O2 -Wall -XHaskell98 -XRoleAnnotations -O2 -no-user-package-db -rtsopts
-odir libraries/containers/dist-install/build -hidir libraries/containers/dist-install/build -stubdir
libraries/containers/dist-install/build -dynamic-too -c libraries/containers/./Data/StrictPair.hs -o
libraries/containers/dist-install/build/Data/StrictPair.o -dyno libraries/containers/dist-install/bui
ld/Data/StrictPair.dyn_o
<command line>: unknown package: deepseq-1.3.0.2
```
The reason why GHC is unable to find the package is because, as it turns out, the Unique that was used to store the key in a map is different from the Unique associated with the FastString that we're doing the lookup with.
The bug only shows up with ghc-stage1 is compiled with optimizations.
Bisecting revealed that this commit was to blame:
```
commit 66218d15b7c27a4a38992003bd761f60bae84b1f
Author: Edward Z. Yang <ezyang@cs.stanford.edu>
Date: Fri Jul 18 14:48:47 2014 +0100
Package keys (for linking/type equality) separated from package IDs.
```
However, looking at the commit, there is nothing that would obviously cause this problem, so maybe it is tickling a preexisting bug.
Bisection script:
{{{
\#!/bin/sh
make clean
git submodule update
perl boot
1. /configure --enable-unregisterised
make -j11 libraries/containers/dist-install/build/Data/StrictPair.o
}}}
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.9 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Unregisterized builds failing due to multiple uniques assigned to same FastString","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"ezyang"},"version":"7.9","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When compiling with `--enable-unregisterised`, we get this failure:\r\n\r\n{{{\r\n\"inplace/bin/ghc-stage1\" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -this-package-key conta_4P4\r\ndHnD3A89EkvERxmaFmd -hide-all-packages -i -ilibraries/containers/. -ilibraries/containers/dist-install\r\n/build -ilibraries/containers/dist-install/build/autogen -Ilibraries/containers/dist-install/build -Il\r\nibraries/containers/dist-install/build/autogen -Ilibraries/containers/include -optP-include -optPli\r\nbraries/containers/dist-install/build/autogen/cabal_macros.h -package-key array_H3W2D8UaI9TKGEhUuQHax2\r\n -package-key base_DiPQ1siqG3SBjHauL3L03p -package-key deeps_L0rJEVU1Zgn8x0Qs5aTOsU -package-key ghcpr\r\n_BE58KUgBe9ELCsPXiJ1Q2r -O2 -Wall -XHaskell98 -XRoleAnnotations -O2 -no-user-package-db -rtsopts \r\n -odir libraries/containers/dist-install/build -hidir libraries/containers/dist-install/build -stubdir\r\n libraries/containers/dist-install/build -dynamic-too -c libraries/containers/./Data/StrictPair.hs -o\r\n libraries/containers/dist-install/build/Data/StrictPair.o -dyno libraries/containers/dist-install/bui\r\nld/Data/StrictPair.dyn_o\r\n<command line>: unknown package: deepseq-1.3.0.2\r\n}}}\r\n\r\nThe reason why GHC is unable to find the package is because, as it turns out, the Unique that was used to store the key in a map is different from the Unique associated with the FastString that we're doing the lookup with.\r\n\r\nThe bug only shows up with ghc-stage1 is compiled with optimizations.\r\n\r\nBisecting revealed that this commit was to blame:\r\n\r\n{{{\r\ncommit 66218d15b7c27a4a38992003bd761f60bae84b1f\r\nAuthor: Edward Z. Yang <ezyang@cs.stanford.edu>\r\nDate: Fri Jul 18 14:48:47 2014 +0100\r\n\r\n Package keys (for linking/type equality) separated from package IDs.\r\n}}}\r\n\r\nHowever, looking at the commit, there is nothing that would obviously cause this problem, so maybe it is tickling a preexisting bug.\r\n\r\nBisection script:\r\n\r\n{{{\r\n#!/bin/sh\r\nmake clean\r\ngit submodule update\r\nperl boot\r\n./configure --enable-unregisterised\r\nmake -j11 libraries/containers/dist-install/build/Data/StrictPair.o\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->Edward Z. YangEdward Z. Yanghttps://gitlab.haskell.org/ghc/ghc/-/issues/9451Incorrect optimizations involving negative zero2019-07-07T18:40:21ZmanzyukIncorrect optimizations involving negative zeroThe program
```hs
main = print $ if negativeZero == 0.0 then 1 / negativeZero else 0.0
where
negativeZero = negate 0.0
```
outputs `-Infinity` when compiled with GHC 7.6.3 and `Infinity` when compiled with GHC 7.8.3 and the optim...The program
```hs
main = print $ if negativeZero == 0.0 then 1 / negativeZero else 0.0
where
negativeZero = negate 0.0
```
outputs `-Infinity` when compiled with GHC 7.6.3 and `Infinity` when compiled with GHC 7.8.3 and the optimization level -O2. The relevant pieces of Core:
```
-- GHC 7.6.3
Main.main2 =
case GHC.Prim.==## (GHC.Prim.negateDouble# 0.0) 0.0 of _ {
GHC.Types.False -> Main.main3 (GHC.Types.[] @ GHC.Types.Char);
GHC.Types.True ->
case GHC.Prim./## 1.0 (GHC.Prim.negateDouble# 0.0)
of wild2_aK6 { __DEFAULT ->
GHC.Float.$w$sshowSignedFloat
GHC.Float.$fShowDouble_$sshowFloat
GHC.Show.shows26
wild2_aK6
(GHC.Types.[] @ GHC.Types.Char)
}
}
```
```
-- GHC 7.8.3
Main.main2 =
case GHC.Prim.negateDouble# 0.0 of _ [Occ=Dead] {
__DEFAULT -> Main.main3 (GHC.Types.[] @ GHC.Types.Char);
0.0 ->
case GHC.Prim./## 1.0 0.0 of wild2_a1NU { __DEFAULT ->
GHC.Float.$w$sshowSignedFloat
GHC.Float.$fShowDouble_$sshowFloat
GHC.Show.shows27
wild2_a1NU
(GHC.Types.[] @ GHC.Types.Char)
}
}
```
I don't think this problem is operating system/architecture dependent, but for the sake of completeness I'm on a 32-bit Linux, and this issue was first discovered on 64-bit Windows running in a virtual machine.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.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":"Incorrect optimizations involving negative zero","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The program\r\n\r\n{{{#!hs\r\nmain = print $ if negativeZero == 0.0 then 1 / negativeZero else 0.0\r\n where\r\n negativeZero = negate 0.0\r\n}}}\r\n\r\noutputs `-Infinity` when compiled with GHC 7.6.3 and `Infinity` when compiled with GHC 7.8.3 and the optimization level -O2. The relevant pieces of Core:\r\n\r\n{{{\r\n-- GHC 7.6.3\r\nMain.main2 =\r\n case GHC.Prim.==## (GHC.Prim.negateDouble# 0.0) 0.0 of _ {\r\n GHC.Types.False -> Main.main3 (GHC.Types.[] @ GHC.Types.Char);\r\n GHC.Types.True ->\r\n case GHC.Prim./## 1.0 (GHC.Prim.negateDouble# 0.0)\r\n of wild2_aK6 { __DEFAULT ->\r\n GHC.Float.$w$sshowSignedFloat\r\n GHC.Float.$fShowDouble_$sshowFloat\r\n GHC.Show.shows26\r\n wild2_aK6\r\n (GHC.Types.[] @ GHC.Types.Char)\r\n }\r\n }\r\n}}}\r\n\r\n{{{\r\n-- GHC 7.8.3\r\nMain.main2 =\r\n case GHC.Prim.negateDouble# 0.0 of _ [Occ=Dead] {\r\n __DEFAULT -> Main.main3 (GHC.Types.[] @ GHC.Types.Char);\r\n 0.0 ->\r\n case GHC.Prim./## 1.0 0.0 of wild2_a1NU { __DEFAULT ->\r\n GHC.Float.$w$sshowSignedFloat\r\n GHC.Float.$fShowDouble_$sshowFloat\r\n GHC.Show.shows27\r\n wild2_a1NU\r\n (GHC.Types.[] @ GHC.Types.Char)\r\n }\r\n }\r\n}}}\r\n\r\nI don't think this problem is operating system/architecture dependent, but for the sake of completeness I'm on a 32-bit Linux, and this issue was first discovered on 64-bit Windows running in a virtual machine.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/9435x86 sse4.2 popCnt16# needs to zero-extend its result2019-07-07T18:40:24Zrwbartonx86 sse4.2 popCnt16# needs to zero-extend its result`make TEST=cgrun071 EXTRA_HC_OPTS=-msse42` fails for me in all the non-ghci non-llvm ways.
For `popCnt16#` we emit `popcnt %ax,%ax` which doesn't clear the high 48 bits of the result.
Patch incoming.
<details><summary>Trac metadata</s...`make TEST=cgrun071 EXTRA_HC_OPTS=-msse42` fails for me in all the non-ghci non-llvm ways.
For `popCnt16#` we emit `popcnt %ax,%ax` which doesn't clear the high 48 bits of the result.
Patch incoming.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | --------------- |
| Version | 7.9 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (NCG) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | simonmar, tibbe |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"x86 sse4.2 popCnt16# needs to zero-extend its result","status":"New","operating_system":"","component":"Compiler (NCG)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.9","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["simonmar","tibbe"],"type":"Bug","description":"`make TEST=cgrun071 EXTRA_HC_OPTS=-msse42` fails for me in all the non-ghci non-llvm ways.\r\n\r\nFor `popCnt16#` we emit `popcnt %ax,%ax` which doesn't clear the high 48 bits of the result.\r\n\r\nPatch incoming.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.4https://gitlab.haskell.org/ghc/ghc/-/issues/9423shutdownCapability sometimes loops indefinitely on OSX after hs_exit()2019-07-07T18:40:28ZAndreasVoellmyshutdownCapability sometimes loops indefinitely on OSX after hs_exit()Issue #9284 relates to `forkProcess`, which previously invoked the same code that is invoked by `hs_exit` and uncovered this problem. The resolution of #9284 is to not invoke the equivalent of `hs_exit` (for reasons that you can see in #...Issue #9284 relates to `forkProcess`, which previously invoked the same code that is invoked by `hs_exit` and uncovered this problem. The resolution of #9284 is to not invoke the equivalent of `hs_exit` (for reasons that you can see in #9284). However, `hs_exit` can be called by programs that explicitly create and teardown a Haskell runtime, so the problem displayed by #9284 can still occur for those programs.
The problem has only been observed on OS X, though it probably could occur on Linux OSes as well.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.8.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | simonmar |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"shutdownCapability sometimes loops indefinitely on OSX after hs_exit()","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"simonmar"},"version":"7.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["simonmar"],"type":"Bug","description":"Issue #9284 relates to `forkProcess`, which previously invoked the same code that is invoked by `hs_exit` and uncovered this problem. The resolution of #9284 is to not invoke the equivalent of `hs_exit` (for reasons that you can see in #9284). However, `hs_exit` can be called by programs that explicitly create and teardown a Haskell runtime, so the problem displayed by #9284 can still occur for those programs.\r\n\r\nThe problem has only been observed on OS X, though it probably could occur on Linux OSes as well.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/9407Program produces different output when compiled with -O2019-07-07T18:40:30ZarotenbergProgram produces different output when compiled with -OWhen compiled and run as
```
ghc Subtlety.hs
Subtlety
```
the attached program generates the correct output of
```
Just (Vec3 0.0 0.0 1.0)
```
but when compiled and run using
```
ghc -O Subtlety.hs
Subtlety
```
the program's output...When compiled and run as
```
ghc Subtlety.hs
Subtlety
```
the attached program generates the correct output of
```
Just (Vec3 0.0 0.0 1.0)
```
but when compiled and run using
```
ghc -O Subtlety.hs
Subtlety
```
the program's output is
```
Just (Vec3 0.0 0.9805806756909202 0.19611613513818404)
```
Furthermore, subtle changes to the source code (like removing the strictness on the `Vec3` type's fields) can alter the behavior of the compiled program.
I am using GHC 7.8.3 x86-64 from Haskell Platform 2014.2.0.0 RC2 on Windows 8.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.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":"Program produces different output when compiled with -O","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When compiled and run as\r\n{{{\r\nghc Subtlety.hs\r\nSubtlety\r\n}}}\r\nthe attached program generates the correct output of\r\n{{{\r\nJust (Vec3 0.0 0.0 1.0)\r\n}}}\r\nbut when compiled and run using\r\n{{{\r\nghc -O Subtlety.hs\r\nSubtlety\r\n}}}\r\nthe program's output is\r\n{{{\r\nJust (Vec3 0.0 0.9805806756909202 0.19611613513818404)\r\n}}}\r\nFurthermore, subtle changes to the source code (like removing the strictness on the `Vec3` type's fields) can alter the behavior of the compiled program.\r\n\r\nI am using GHC 7.8.3 x86-64 from Haskell Platform 2014.2.0.0 RC2 on Windows 8.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/9401MVar deadlock exceptions cause exceptions in later MVar ops2019-07-07T18:40:33ZMichael Snoymanmichael@snoyman.comMVar deadlock exceptions cause exceptions in later MVar opsTake the following code:
```hs
import Control.Concurrent
import Control.Concurrent.MVar
import Control.Exception
main :: IO ()
main = do
var <- newEmptyMVar
_ <- forkIO $ do
res <- try $ newEmptyMVar >>= takeMVar
...Take the following code:
```hs
import Control.Concurrent
import Control.Concurrent.MVar
import Control.Exception
main :: IO ()
main = do
var <- newEmptyMVar
_ <- forkIO $ do
res <- try $ newEmptyMVar >>= takeMVar
putMVar var res
putStrLn "Successfully filled var"
res <- readMVar var `onException` do
putStrLn "Received exception, delaying..."
threadDelay 1000000
res <- readMVar var
putStrLn $ "After delay, res is: " ++ show res
print (res :: Either SomeException Int)
putStrLn "Exiting..."
```
On line 9, an MVar deadlock exception is thrown, which is caught by `try`. That result is then put into the var MVar. On line 13, I `readMVar` to get this value. I would expect it to return the exception previously thrown, as a `Left` value. Instead, a __new__ exception is thrown. I say new, because if I switch over to using STM instead of an MVar, I get a different exception (STM transaction instead of MVar deadlock).
With the program as above, my output is:
```
Successfully filled var
Received exception, delaying...
After delay, res is: Left thread blocked indefinitely in an MVar operation
async14.hs: thread blocked indefinitely in an MVar operation
```
I originally filed this as an issue against the async package: https://github.com/simonmar/async/issues/14
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.8.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | simonmar |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"MVar deadlock exceptions cause exceptions in later MVar ops","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"simonmar"},"version":"7.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["simonmar"],"type":"Bug","description":"Take the following code:\r\n\r\n{{{#!hs\r\nimport Control.Concurrent\r\nimport Control.Concurrent.MVar\r\nimport Control.Exception\r\n\r\nmain :: IO ()\r\nmain = do\r\n var <- newEmptyMVar\r\n _ <- forkIO $ do\r\n res <- try $ newEmptyMVar >>= takeMVar\r\n putMVar var res\r\n putStrLn \"Successfully filled var\"\r\n\r\n res <- readMVar var `onException` do\r\n putStrLn \"Received exception, delaying...\"\r\n threadDelay 1000000\r\n res <- readMVar var\r\n putStrLn $ \"After delay, res is: \" ++ show res\r\n\r\n print (res :: Either SomeException Int)\r\n putStrLn \"Exiting...\"\r\n}}}\r\n\r\nOn line 9, an MVar deadlock exception is thrown, which is caught by `try`. That result is then put into the var MVar. On line 13, I `readMVar` to get this value. I would expect it to return the exception previously thrown, as a `Left` value. Instead, a __new__ exception is thrown. I say new, because if I switch over to using STM instead of an MVar, I get a different exception (STM transaction instead of MVar deadlock).\r\n\r\nWith the program as above, my output is:\r\n\r\n{{{\r\nSuccessfully filled var\r\nReceived exception, delaying...\r\nAfter delay, res is: Left thread blocked indefinitely in an MVar operation\r\nasync14.hs: thread blocked indefinitely in an MVar operation\r\n}}}\r\n\r\nI originally filed this as an issue against the async package: https://github.com/simonmar/async/issues/14","type_of_failure":"OtherFailure","blocking":[]} -->Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/9384setNumCapabilities call breaks eventlog events2019-07-07T18:40:37ZSergei TrofimovichsetNumCapabilities call breaks eventlog eventsThe problem was found when i tried to eventlog **ghc --make** itself.
I've missinterpreted is as a threadscope bug: https://github.com/haskell/ThreadScope/issues/37
Here is small program to reliably reproduce the bug:
```hs
module Main...The problem was found when i tried to eventlog **ghc --make** itself.
I've missinterpreted is as a threadscope bug: https://github.com/haskell/ThreadScope/issues/37
Here is small program to reliably reproduce the bug:
```hs
module Main where
import qualified Data.List as L
import qualified System.Environment as E
import Control.Monad
import qualified Control.Concurrent as CC
import qualified Control.Concurrent.MVar as CC
slow_and_silly :: Int -> IO Int
slow_and_silly i = return $ length $ L.foldl' (\a v -> a ++ [v]) [] [1..i]
-- build as:
-- $ ghc --make a -O2 -threaded -eventlog
-- valid eventlog:
-- $ ./a 2 7000 +RTS -ls -N2
-- $ ghc-events validate threads a.eventlog
-- Valid eventlog:
-- ...
-- invalid eventlog
-- $ ./a 2 7000 +RTS -ls
-- $ ghc-events validate threads a.eventlog
-- Invalid eventlog:
-- ...
main = do
[caps, count] <- E.getArgs
let n_caps :: Int
n_caps = read caps
max_n :: Int
max_n = read count
CC.setNumCapabilities n_caps
waits <- replicateM n_caps $ CC.newEmptyMVar
forM_ waits $ \w -> CC.forkIO $ do
slow_and_silly max_n >>= print
CC.putMVar w ()
forM_ waits $ \w -> CC.takeMVar w
```
How to reproduce (comments have **ghc-events** version):
```
$ ghc --make a -O2 -threaded -eventlog
$ ./a 2 7000 +RTS -ls -N2
$ threadscope a.eventlog # works
$ ./a 2 7000 +RTS -ls
$ threadscope a.eventlog # crashes
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Profiling |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"setNumCapabilities call breaks eventlog events","status":"New","operating_system":"","component":"Profiling","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The problem was found when i tried to eventlog '''ghc --make''' itself.\r\nI've missinterpreted is as a threadscope bug: https://github.com/haskell/ThreadScope/issues/37\r\n\r\nHere is small program to reliably reproduce the bug:\r\n\r\n{{{#!hs\r\nmodule Main where\r\n\r\nimport qualified Data.List as L\r\nimport qualified System.Environment as E\r\nimport Control.Monad\r\nimport qualified Control.Concurrent as CC\r\nimport qualified Control.Concurrent.MVar as CC\r\n\r\nslow_and_silly :: Int -> IO Int\r\nslow_and_silly i = return $ length $ L.foldl' (\\a v -> a ++ [v]) [] [1..i]\r\n\r\n-- build as:\r\n-- $ ghc --make a -O2 -threaded -eventlog\r\n\r\n-- valid eventlog:\r\n-- $ ./a 2 7000 +RTS -ls -N2\r\n-- $ ghc-events validate threads a.eventlog\r\n-- Valid eventlog:\r\n-- ...\r\n\r\n-- invalid eventlog\r\n-- $ ./a 2 7000 +RTS -ls\r\n-- $ ghc-events validate threads a.eventlog\r\n-- Invalid eventlog:\r\n-- ...\r\n\r\nmain = do\r\n [caps, count] <- E.getArgs\r\n let n_caps :: Int\r\n n_caps = read caps\r\n max_n :: Int\r\n max_n = read count\r\n\r\n CC.setNumCapabilities n_caps\r\n\r\n waits <- replicateM n_caps $ CC.newEmptyMVar\r\n\r\n forM_ waits $ \\w -> CC.forkIO $ do\r\n slow_and_silly max_n >>= print\r\n CC.putMVar w ()\r\n\r\n forM_ waits $ \\w -> CC.takeMVar w\r\n}}}\r\n\r\nHow to reproduce (comments have '''ghc-events''' version):\r\n{{{\r\n$ ghc --make a -O2 -threaded -eventlog\r\n$ ./a 2 7000 +RTS -ls -N2\r\n$ threadscope a.eventlog # works\r\n$ ./a 2 7000 +RTS -ls\r\n$ threadscope a.eventlog # crashes\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/9380ghc generates seemingly incorrect code2019-07-07T18:40:38ZAlexander Vershilovghc generates seemingly incorrect codeGHC generates a wrong code for the case-match on GADT with polymorphic type,
here is a minimal example attached, expected results are 'A' in all test cases
(this is case for ghc-HEAD), however in:
test0 - result is missing as matches ar...GHC generates a wrong code for the case-match on GADT with polymorphic type,
here is a minimal example attached, expected results are 'A' in all test cases
(this is case for ghc-HEAD), however in:
test0 - result is missing as matches are removed from code (according to core)
test1 - returns A as expected
test2 - output 'o_O' without any checks
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.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":"ghc generates seemingly incorrect code","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"GHC generates a wrong code for the case-match on GADT with polymorphic type,\r\n\r\nhere is a minimal example attached, expected results are 'A' in all test cases\r\n(this is case for ghc-HEAD), however in:\r\ntest0 - result is missing as matches are removed from code (according to core)\r\ntest1 - returns A as expected\r\ntest2 - output 'o_O' without any checks","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/9333Thread status decoded wrong in base library2019-07-07T18:40:51ZJost BertholdThread status decoded wrong in base libraryKyle Van Berendonck \<kvanberendonck\@gmail.com\> in [a message on ghc-devs](http://www.haskell.org/pipermail/ghc-devs/2014-July/005677.html) pointed to [base/GHC/Conc/Sync.lhs](https://github.com/ghc/ghc/blob/master/libraries/base/GHC/C...Kyle Van Berendonck \<kvanberendonck\@gmail.com\> in [a message on ghc-devs](http://www.haskell.org/pipermail/ghc-devs/2014-July/005677.html) pointed to [base/GHC/Conc/Sync.lhs](https://github.com/ghc/ghc/blob/master/libraries/base/GHC/Conc/Sync.lhs#L483) decoding thread block reasons from constants defined in includes/rts/Constants.h to a Haskell type.
The constants were modified in GHC-7.8.2, which created problems with eventlogs (ticket #9003), so the constants were reverted, but base was not adapted to the respective fix.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------------- |
| Version | 7.8.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ekmett, ezyang, hvr, simonmar |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Thread status decoded wrong in base library","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ekmett","ezyang","hvr","simonmar"],"type":"Bug","description":"Kyle Van Berendonck <kvanberendonck@gmail.com> in [http://www.haskell.org/pipermail/ghc-devs/2014-July/005677.html a message on ghc-devs] pointed to [https://github.com/ghc/ghc/blob/master/libraries/base/GHC/Conc/Sync.lhs#L483 base/GHC/Conc/Sync.lhs] decoding thread block reasons from constants defined in includes/rts/Constants.h to a Haskell type.\r\n\r\nThe constants were modified in GHC-7.8.2, which created problems with eventlogs (ticket #9003), so the constants were reverted, but base was not adapted to the respective fix.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1Jost BertholdJost Bertholdhttps://gitlab.haskell.org/ghc/ghc/-/issues/9325mod73 output file needs to be reordered2019-07-07T18:40:53Zjrp2014mod73 output file needs to be reorderedThe correct output from the mod73 test needs to be reordered in HEAD:
```
=====> mod73(normal) 1610 of 4044 [0, 0, 0]
cd ./module && '/Users/jrp/Projects/ghc/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-outp...The correct output from the mod73 test needs to be reordered in HEAD:
```
=====> mod73(normal) 1610 of 4044 [0, 0, 0]
cd ./module && '/Users/jrp/Projects/ghc/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c mod73.hs >mod73.comp.stderr 2>&1
Actual stderr output differs from expected:
--- ./module/mod73.stderr 2014-07-16 21:21:57.000000000 +0100
+++ ./module/mod73.comp.stderr 2014-07-17 20:15:54.000000000 +0100
@@ -2,6 +2,6 @@
mod73.hs:3:7:
Not in scope: ‘Prelude.g’
Perhaps you meant one of these:
- data constructor ‘Prelude.LT’ (imported from Prelude),
+ data constructor ‘Prelude.GT’ (imported from Prelude),
data constructor ‘Prelude.EQ’ (imported from Prelude),
- data constructor ‘Prelude.GT’ (imported from Prelude)
+ data constructor ‘Prelude.LT’ (imported from Prelude)
*** unexpected failure for mod73(normal)
Unexpected results from:
TEST="mod73"
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Test Suite |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"mod73 output file needs to be reordered","status":"New","operating_system":"","component":"Test Suite","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.3","keywords":["mod73"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The correct output from the mod73 test needs to be reordered in HEAD:\r\n\r\n{{{\r\n\r\n=====> mod73(normal) 1610 of 4044 [0, 0, 0] \r\ncd ./module && '/Users/jrp/Projects/ghc/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history -c mod73.hs >mod73.comp.stderr 2>&1\r\nActual stderr output differs from expected:\r\n--- ./module/mod73.stderr\t2014-07-16 21:21:57.000000000 +0100\r\n+++ ./module/mod73.comp.stderr\t2014-07-17 20:15:54.000000000 +0100\r\n@@ -2,6 +2,6 @@\r\n mod73.hs:3:7:\r\n Not in scope: ‘Prelude.g’\r\n Perhaps you meant one of these:\r\n- data constructor ‘Prelude.LT’ (imported from Prelude),\r\n+ data constructor ‘Prelude.GT’ (imported from Prelude),\r\n data constructor ‘Prelude.EQ’ (imported from Prelude),\r\n- data constructor ‘Prelude.GT’ (imported from Prelude)\r\n+ data constructor ‘Prelude.LT’ (imported from Prelude)\r\n*** unexpected failure for mod73(normal)\r\n\r\nUnexpected results from:\r\nTEST=\"mod73\"\r\n\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->