GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2022-04-08T14:00:08Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/15670FloatFnInverses seems to show some weird rounding/precision issues.2022-04-08T14:00:08ZTamar ChristinaFloatFnInverses seems to show some weird rounding/precision issues.There seems to be a rounding issue with math functions on Windows. We likely need a crt update to fix this. Or maybe check the round mode if it's being set correctly.
```
--- numeric/should_run/FloatFnInverses.run/FloatFnInverses.stdout...There seems to be a rounding issue with math functions on Windows. We likely need a crt update to fix this. Or maybe check the round mode if it's being set correctly.
```
--- numeric/should_run/FloatFnInverses.run/FloatFnInverses.stdout.normalised 2018-09-23 17:26:01.581150200 +0100
+++ numeric/should_run/FloatFnInverses.run/FloatFnInverses.run.stdout.normalised 2018-09-23 17:26:01.583146400 +0100
@@ -8,8 +8,8 @@
[0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0]
[0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0]
[0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0]
-[0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0]
-[0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0]
+[Infinity,Infinity,Infinity,Infinity,Infinity,Infinity,Infinity,Infinity,Infinity,Infinity,Infinity,Infinity,Infinity,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,-Infinity,-Infinity,-Infinity,-Infinity,-Infinity,-Infinity,-Infinity,-Infinity,-Infinity,-Infinity,-Infinity,-Infinity,-Infinity]
+[7.788445287802241e33,7.788445287802241e33,7.788445287802241e33,7.788445287802241e33,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,-7.788445287802241e33,-7.788445287802241e33,-7.788445287802241e33,-7.788445287802241e33,-7.788445287802241e33]
[0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0]
[0.0,0.0,0.0,0.0,0.0,0.0]
[0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0]
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.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":"FloatFnInverses seems to show some weird rounding/precision issues.","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"\r\nThere seems to be a rounding issue with math functions on Windows. We likely need a crt update to fix this. Or maybe check the round mode if it's being set correctly.\r\n\r\n{{{\r\n--- numeric/should_run/FloatFnInverses.run/FloatFnInverses.stdout.normalised 2018-09-23 17:26:01.581150200 +0100\r\n+++ numeric/should_run/FloatFnInverses.run/FloatFnInverses.run.stdout.normalised 2018-09-23 17:26:01.583146400 +0100\r\n@@ -8,8 +8,8 @@\r\n [0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0]\r\n [0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0]\r\n [0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0]\r\n-[0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0]\r\n-[0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0]\r\n+[Infinity,Infinity,Infinity,Infinity,Infinity,Infinity,Infinity,Infinity,Infinity,Infinity,Infinity,Infinity,Infinity,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,-Infinity,-Infinity,-Infinity,-Infinity,-Infinity,-Infinity,-Infinity,-Infinity,-Infinity,-Infinity,-Infinity,-Infinity,-Infinity]\r\n+[7.788445287802241e33,7.788445287802241e33,7.788445287802241e33,7.788445287802241e33,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,-7.788445287802241e33,-7.788445287802241e33,-7.788445287802241e33,-7.788445287802241e33,-7.788445287802241e33]\r\n [0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0]\r\n [0.0,0.0,0.0,0.0,0.0,0.0]\r\n [0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0,0.0]\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15668Allocations values for some compile tests are way too hight2019-07-07T18:03:31ZTamar ChristinaAllocations values for some compile tests are way too hightThese tests are failing on Windows (only), with way too high allocation counts. Quite when this started happening is not clear -- perhaps in the last couple of months.
```
bytes allocated value is too high:
Expected T12425(optasm...These tests are failing on Windows (only), with way too high allocation counts. Quite when this started happening is not clear -- perhaps in the last couple of months.
```
bytes allocated value is too high:
Expected T12425(optasm) bytes allocated: 139100464 +/-5%
Lower bound T12425(optasm) bytes allocated: 132145440
Upper bound T12425(optasm) bytes allocated: 146055488
Actual T12425(optasm) bytes allocated: 149370944
Deviation T12425(optasm) bytes allocated: 7.4 %
*** unexpected stat test failure for T12425(optasm)
bytes allocated value is too high:
Expected MultiLayerModules(normal) bytes allocated: 5619893176 +/-10%
Lower bound MultiLayerModules(normal) bytes allocated: 5057903858
Upper bound MultiLayerModules(normal) bytes allocated: 6181882494
Actual MultiLayerModules(normal) bytes allocated: 6693788656
Deviation MultiLayerModules(normal) bytes allocated: 19.1 %
*** unexpected stat test failure for MultiLayerModules(normal)
bytes allocated value is too high:
Expected T11303b(normal) bytes allocated: 54373936 +/-10%
Lower bound T11303b(normal) bytes allocated: 48936542
Upper bound T11303b(normal) bytes allocated: 59811330
Actual T11303b(normal) bytes allocated: 62015072
Deviation T11303b(normal) bytes allocated: 14.1 %
*** unexpected stat test failure for T11303b(normal)
bytes allocated value is too high:
Expected T12234(optasm) bytes allocated: 79889200 +/-5%
Lower bound T12234(optasm) bytes allocated: 75894740
Upper bound T12234(optasm) bytes allocated: 83883660
Actual T12234(optasm) bytes allocated: 91583520
Deviation T12234(optasm) bytes allocated: 14.6 %
*** unexpected stat test failure for T12234(optasm)
```
These are a bit too high for me to just blindly update them without knowing why.8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15574C wrappers for Haskell foreign exports don't have finalizers (causes memory l...2019-07-07T18:04:04ZValoisaC wrappers for Haskell foreign exports don't have finalizers (causes memory leak).For each foreign export RTS creates a static C wrapper, which is initialized on `DLL_PROCESS_ATTACH`, but it has no finalizer/destructor to be called during `DLL_PROCESS_DETACH`. So it will stay alive till the program termination. That's...For each foreign export RTS creates a static C wrapper, which is initialized on `DLL_PROCESS_ATTACH`, but it has no finalizer/destructor to be called during `DLL_PROCESS_DETACH`. So it will stay alive till the program termination. That's why if one uses a Haskell DLL in their C/C++ project, \*\*consumed memory is not fully released after freeing the library\*\*.
\[\[br\]\]\[\[br\]\]
There are four files attached to this ticket.
- \*\*HaskellExports.hs\*\* contains exact one foreign export function;
- \*\*CWrapper.cpp\*\* is supposed to contain wrappers to the Haskell functions, described in *HaskellExports.hs*, but it doesn't because they make no difference;
- \*\*main.cpp\*\*: here in an endless loop the DLL (built with the help of the script below) is loaded and freed at once. Launched program is crashed in a while (because it runs out of memory);
- \*\*build.sh\*\* is a script for building the library.
\[\[br\]\]
The main program was built with MSVC 2015.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (FFI) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"C wrappers for Haskell foreign exports don't have finalizers (causes memory leak).","status":"New","operating_system":"","component":"Compiler (FFI)","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"For each foreign export RTS creates a static C wrapper, which is initialized on {{{DLL_PROCESS_ATTACH}}}, but it has no finalizer/destructor to be called during {{{DLL_PROCESS_DETACH}}}. So it will stay alive till the program termination. That's why if one uses a Haskell DLL in their C/C++ project, **consumed memory is not fully released after freeing the library**.\r\n[[br]][[br]]\r\nThere are four files attached to this ticket. \r\n* **HaskellExports.hs** contains exact one foreign export function;\r\n* **CWrapper.cpp** is supposed to contain wrappers to the Haskell functions, described in ''HaskellExports.hs'', but it doesn't because they make no difference;\r\n* **main.cpp**: here in an endless loop the DLL (built with the help of the script below) is loaded and freed at once. Launched program is crashed in a while (because it runs out of memory);\r\n* **build.sh** is a script for building the library.\r\n[[br]]\r\nThe main program was built with MSVC 2015.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/14654Nofib: Strip called without .exe extension resulting in errors.2019-07-07T18:16:08ZAndreas KlebingerNofib: Strip called without .exe extension resulting in errors.```
...
==nofib== bernouilli: size of Main.o follows...
text data bss dec hex filename
8080 1632 0 9712 25f0 Main.o
==nofib== bernouilli: time to link bernouilli follows...
<<ghc: 27269080 bytes, 11 GC...```
...
==nofib== bernouilli: size of Main.o follows...
text data bss dec hex filename
8080 1632 0 9712 25f0 Main.o
==nofib== bernouilli: time to link bernouilli follows...
<<ghc: 27269080 bytes, 11 GCs, 471856/801256 avg/max bytes residency (2 samples), 32M in use, 0.000 INIT (0.000 elapsed), 0.016 MUT (1.134 elapsed), 0.016 GC (0.015 elapsed) :ghc>>
C:\ghc\msys64\mingw64\bin\strip.exe: 'bernouilli': No such file
make[2]: *** [../../mk/target.mk:96: size] Error 1
make[2]: Target 'all' not remade because of errors.
Finished making all in bernouilli: 0
...
```
I assume strip looks for a file, not an executable. And as such requires the full name "foo.exe" instead of just "foo".
Make sees this error and stops before the actual benchmark is run.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | --------------------- |
| Version | 8.2.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | NoFib benchmark suite |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Nofib: Strip called without .exe extension resulting in errors.","status":"New","operating_system":"","component":"NoFib benchmark suite","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":["nofib,","windows"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\n...\r\n==nofib== bernouilli: size of Main.o follows...\r\n text data bss dec hex filename\r\n 8080 1632 0 9712 25f0 Main.o\r\n==nofib== bernouilli: time to link bernouilli follows...\r\n<<ghc: 27269080 bytes, 11 GCs, 471856/801256 avg/max bytes residency (2 samples), 32M in use, 0.000 INIT (0.000 elapsed), 0.016 MUT (1.134 elapsed), 0.016 GC (0.015 elapsed) :ghc>>\r\nC:\\ghc\\msys64\\mingw64\\bin\\strip.exe: 'bernouilli': No such file\r\nmake[2]: *** [../../mk/target.mk:96: size] Error 1\r\nmake[2]: Target 'all' not remade because of errors.\r\nFinished making all in bernouilli: 0\r\n...\r\n}}}\r\n\r\nI assume strip looks for a file, not an executable. And as such requires the full name \"foo.exe\" instead of just \"foo\".\r\n\r\nMake sees this error and stops before the actual benchmark is run.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Andreas KlebingerAndreas Klebingerhttps://gitlab.haskell.org/ghc/ghc/-/issues/12714T9405 fails on Windows2022-04-08T14:00:09ZBen GamariT9405 fails on WindowsThe `T9405` testcase currently fails on Windows,
```
=====> T9405(normal) 8 of 14 [0, 1, 0]
cd "./rts/T9405.run" && $MAKE -s --no-print-directory T9405
Wrong exit code (expected 0 , actual 2 )
Stdout:
[1 of 1] Compiling Main ...The `T9405` testcase currently fails on Windows,
```
=====> T9405(normal) 8 of 14 [0, 1, 0]
cd "./rts/T9405.run" && $MAKE -s --no-print-directory T9405
Wrong exit code (expected 0 , actual 2 )
Stdout:
[1 of 1] Compiling Main ( T9405.hs, T9405.o )
Linking T9405.exe ...
Stderr:
make[1]: *** [Makefile:50: T9405] Error 1
```
Contrary to what was suggested in [ticket:12004\#comment:120267](https://gitlab.haskell.org//ghc/ghc/issues/12004#note_120267) it looks like the problem is that an empty `.ticky` file is produced. Even increasing the `sleep` time to 10 seconds (after bumping the sleep in `T9405.hs` accordingly) doesn't change this, so I suspect there is a runtime system bug here.8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/12498Support unconventionally named import libraries2019-07-07T18:26:21ZTamar ChristinaSupport unconventionally named import librariesGHC's import library support currently does not recognize import libraries which are named something other than `.dll.a`. This is because we're using the extension to determine the mode to use.
Instead we should look at the presence of ...GHC's import library support currently does not recognize import libraries which are named something other than `.dll.a`. This is because we're using the extension to determine the mode to use.
Instead we should look at the presence of certain patterns. e.g. .o files contain only `.idata` sections etc.
This would allow us to be able to support import libraries such as `gcc_s` and no longer need to hardcode the GCC library full name in cabal file.
This should add more compatibility with packages on hackage.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.0.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System (Linker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Support unconventionally named import libraries","status":"New","operating_system":"","component":"Runtime System (Linker)","related":[],"milestone":"8.2.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"GHC's import library support currently does not recognize import libraries which are named something other than `.dll.a`. This is because we're using the extension to determine the mode to use.\r\n\r\nInstead we should look at the presence of certain patterns. e.g. .o files contain only `.idata` sections etc.\r\n\r\nThis would allow us to be able to support import libraries such as `gcc_s` and no longer need to hardcode the GCC library full name in cabal file. \r\n\r\nThis should add more compatibility with packages on hackage.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Tamar ChristinaTamar Christina