GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:48:21Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/7739Testsuite failures for HPC way tests on Windows2019-07-07T18:48:21ZbtuttTestsuite failures for HPC way tests on WindowsHere's what happens on GHC-HEAD:
```
=====> annrun01(hpc) 15 of 3566 [0, 0, 6]
cd ./annotations/should_run && $MAKE -s --no-print-directory config
Creating Config.hs ...
cd ./annotations/should_run && 'd:/Dev/ghc/ghc/inplace/bin/ghc-sta...Here's what happens on GHC-HEAD:
```
=====> annrun01(hpc) 15 of 3566 [0, 0, 6]
cd ./annotations/should_run && $MAKE -s --no-print-directory config
Creating Config.hs ...
cd ./annotations/should_run && 'd:/Dev/ghc/ghc/inplace/bin/ghc-stage2.exe' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history --make -o annrun01 annrun01 -O -fhpc -hpcdir .hpc.annrun01 -package ghc >annrun01.comp.stderr 2>&1
cd ./annotations/should_run && ./annrun01 </dev/null >annrun01.run.stdout 2>annrun01.run.stderr
Wrong exit code (expected 0 , actual 1 )
Stdout:
Stderr:
in module 'Config'
Hpc failure: module mismatch with .tix/.mix file hash number
(perhaps remove annrun01.exe.tix file?)
*** unexpected failure for annrun01(hpc)
```
The cause appears to be due to not cleaning up .exe.tix files.
After deleting the files the tests pass again.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | |
| 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":"Testsuite failures for HPC way tests on Windows","status":"New","operating_system":"","component":"Test Suite","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Here's what happens on GHC-HEAD:\r\n\r\n{{{\r\n=====> annrun01(hpc) 15 of 3566 [0, 0, 6]\r\ncd ./annotations/should_run && $MAKE -s --no-print-directory config\r\nCreating Config.hs ...\r\ncd ./annotations/should_run && 'd:/Dev/ghc/ghc/inplace/bin/ghc-stage2.exe' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-ghci-history --make -o annrun01 annrun01 -O -fhpc -hpcdir .hpc.annrun01 -package ghc >annrun01.comp.stderr 2>&1\r\ncd ./annotations/should_run && ./annrun01 </dev/null >annrun01.run.stdout 2>annrun01.run.stderr\r\nWrong exit code (expected 0 , actual 1 )\r\nStdout:\r\n\r\nStderr:\r\nin module 'Config'\r\nHpc failure: module mismatch with .tix/.mix file hash number\r\n(perhaps remove annrun01.exe.tix file?)\r\n\r\n*** unexpected failure for annrun01(hpc)\r\n}}}\r\n\r\nThe cause appears to be due to not cleaning up .exe.tix files.\r\nAfter deleting the files the tests pass again.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/7738Testsuite failures for ghci tests normalising stderr output for .exe2019-07-07T18:48:21ZbtuttTestsuite failures for ghci tests normalising stderr output for .exeOn GHC-Head:
Tests getDirContents002 and process004 both specify normalise_exe in their options, but these both only generate expected error results on stderr.
Here's an example of what happens currently:
```
--- ./getDirContents002.s...On GHC-Head:
Tests getDirContents002 and process004 both specify normalise_exe in their options, but these both only generate expected error results on stderr.
Here's an example of what happens currently:
```
--- ./getDirContents002.stderr-mingw32 2013-02-09 21:09:27 -0500
+++ ./getDirContents002.run.stderr 2013-03-04 17:29:34 -0500
@@ -1 +1 @@
-getDirContents002.exe: nonexistent: getDirectoryContents: does not exist (The system cannot find the path specified.)
+getDirContents002: nonexistent: getDirectoryContents: does not exist (The system cannot find the path specified.)
*** unexpected failure for getDirContents002(ghci)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | |
| 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":"Testsuite failures for ghci tests normalising stderr output for .exe","status":"New","operating_system":"","component":"Test Suite","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"On GHC-Head:\r\n\r\nTests getDirContents002 and process004 both specify normalise_exe in their options, but these both only generate expected error results on stderr. \r\n\r\nHere's an example of what happens currently:\r\n{{{\r\n--- ./getDirContents002.stderr-mingw32 2013-02-09 21:09:27 -0500\r\n+++ ./getDirContents002.run.stderr 2013-03-04 17:29:34 -0500\r\n@@ -1 +1 @@\r\n-getDirContents002.exe: nonexistent: getDirectoryContents: does not exist (The system cannot find the path specified.)\r\n+getDirContents002: nonexistent: getDirectoryContents: does not exist (The system cannot find the path specified.)\r\n*** unexpected failure for getDirContents002(ghci)\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/7573Testsuite should easily be able to compile .cmm files.2019-07-07T18:49:10ZthoughtpoliceTestsuite should easily be able to compile .cmm files.While writing a test for #7571, I found it annoying to have to use multi_compile to just compile cmm code.
I have a patch that adds support for cmm_src modifier for tests. The test for #7571 will depend on this.
<details><summary>Trac ...While writing a test for #7571, I found it annoying to have to use multi_compile to just compile cmm code.
I have a patch that adds support for cmm_src modifier for tests. The test for #7571 will depend on this.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.7 |
| 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":"Testsuite should easily be able to compile .cmm files.","status":"New","operating_system":"","component":"Test Suite","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"thoughtpolice"},"version":"7.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"While writing a test for #7571, I found it annoying to have to use multi_compile to just compile cmm code.\r\n\r\nI have a patch that adds support for cmm_src modifier for tests. The test for #7571 will depend on this.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/7247Testsuite: Print stdout diff even if stderr diff already fails2019-07-07T18:50:42ZJoachim Breitnermail@joachim-breitner.deTestsuite: Print stdout diff even if stderr diff already failsWhen doing test-driven development I find it handy to see the diff of stdout even when stderr already fails to match. The attached patch implements that.
<details><summary>Trac metadata</summary>
| Trac field | Value ...When doing test-driven development I find it handy to see the diff of stdout even when stderr already fails to match. The attached patch implements that.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.6.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Test Suite |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Testsuite: Print stdout diff even if stderr diff already fails","status":"New","operating_system":"","component":"Test Suite","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"When doing test-driven development I find it handy to see the diff of stdout even when stderr already fails to match. The attached patch implements that.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/5233Support specifying the assembly that should be generated2019-07-07T18:56:18ZtibbeSupport specifying the assembly that should be generatedWe want to make sure that native code generator optimizations, like primop unrolling, always fire. We can do this by allowing the programmer to specify what assembly should be generated for a particular snippet of Cmm. The programmer giv...We want to make sure that native code generator optimizations, like primop unrolling, always fire. We can do this by allowing the programmer to specify what assembly should be generated for a particular snippet of Cmm. The programmer gives a snippet of Cmm:
```
#include "Cmm.h"
// Large memcpy's should lower to calls.
callMemcpy
{
W_ dst, src;
prim %memcpy(dst "ptr", src "ptr", 1024, 4) [];
}
```
and the expected assembly output:
```
callMemcpy:
movq ; Move arguments into place
movq
movl
movl
call memcpy
```
The expected output shouldn't mention specific register names as these are likely to change.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.0.3 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Test Suite |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Support specifying the assembly that should be generated","status":"New","operating_system":"","component":"Test Suite","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.0.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"We want to make sure that native code generator optimizations, like primop unrolling, always fire. We can do this by allowing the programmer to specify what assembly should be generated for a particular snippet of Cmm. The programmer gives a snippet of Cmm:\r\n\r\n{{{\r\n#include \"Cmm.h\"\r\n\r\n// Large memcpy's should lower to calls.\r\ncallMemcpy\r\n{\r\n W_ dst, src;\r\n prim %memcpy(dst \"ptr\", src \"ptr\", 1024, 4) [];\r\n}\r\n}}}\r\n\r\nand the expected assembly output:\r\n\r\n{{{\r\ncallMemcpy:\r\nmovq ; Move arguments into place\r\nmovq\r\nmovl\r\nmovl\r\ncall memcpy\r\n}}}\r\n\r\nThe expected output shouldn't mention specific register names as these are likely to change.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/10164Cleanup test framework string formatting2019-07-07T18:37:16ZThomas MiedemaCleanup test framework string formattingThis is a placeholder ticket for commits related to a cleanup of the testsuite and testsuite driver.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Versio...This is a placeholder ticket for commits related to a cleanup of the testsuite and testsuite driver.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.4 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Test Suite |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Cleanup test framework string formatting","status":"New","operating_system":"","component":"Test Suite","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"This is a placeholder ticket for commits related to a cleanup of the testsuite and testsuite driver.","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/9856Test suite regressions due to integer-gmp22019-07-07T18:38:45ZJoachim Breitnermail@joachim-breitner.deTest suite regressions due to integer-gmp2According to my performance builders, changeset:c774b28/ghc (Phab:D82) caused prof-doc-fib and linker_unload to fail on both performance builders (Ubuntu 13.10 and Ubuntu 14.04):
```
Wrong exit code (expected 0 , actual 2 )
Stdout:
Std...According to my performance builders, changeset:c774b28/ghc (Phab:D82) caused prof-doc-fib and linker_unload to fail on both performance builders (Ubuntu 13.10 and Ubuntu 14.04):
```
Wrong exit code (expected 0 , actual 2 )
Stdout:
Stderr:
linker_unload: /home/nomeata/logs/ghc-tmp-REV/libraries/integer-gmp2/dist-install/build/libHSinteg_21cuTlnn00eFNd4GMrxOMi.a: unknown symbol `__gmpn_rshift'
linker_unload: resolveObjs failed
make[3]: *** [linker_unload] Error 1
*** unexpected failure for linker_unload(normal)
```
and
```
Actual prof output differs from expected:
--- ./profiling/should_run/prof-doc-fib.prof.sample 2014-12-01 15:30:19.000000000 +0100
+++ ./profiling/should_run/prof-doc-fib.prof 2014-12-01 15:56:08.000000000 +0100
@@ -1,9 +1,9 @@
- Thu Oct 27 09:29 2011 Time and Allocation Profiling Report (Final)
+ Mon Dec 1 15:56 2014 Time and Allocation Profiling Report (Final)
- fib +RTS -p -RTS
+ prof-doc-fib +RTS -hc -p -RTS
- total time = 0.76 secs (38 ticks @ 20 ms)
- total alloc = 247,940,020 bytes (excludes profiling overheads)
+ total time = 0.14 secs (135 ticks @ 1000 us, 1 processor)
+ total alloc = 107,829,304 bytes (excludes profiling overheads)
COST CENTRE MODULE %time %alloc
@@ -13,13 +13,16 @@
individual inherited
COST CENTRE MODULE no. entries %time %alloc %time %alloc
-MAIN MAIN 102 0 0.0 0.0 100.0 100.0
- CAF Main 203 0 0.0 0.0 100.0 100.0
- main Main 204 1 0.0 0.0 100.0 100.0
- main.g Main 207 1 0.0 0.0 0.0 0.1
- fib Main 208 1973 0.0 0.1 0.0 0.1
- main.f Main 205 1 0.0 0.0 100.0 99.9
- fib Main 206 2692537 100.0 99.9 100.0 99.9
- CAF GHC.Conc.Signal 201 0 0.0 0.0 0.0 0.0
- CAF GHC.IO.Encoding.Iconv 191 0 0.0 0.0 0.0 0.0
- CAF GHC.IO.Handle.FD 183 0 0.0 0.0 0.0 0.0
+MAIN MAIN 45 0 0.0 0.0 100.0 100.0
+ main Main 91 0 0.0 0.0 0.0 0.0
+ CAF Main 89 0 0.0 0.0 100.0 100.0
+ main Main 90 1 0.0 0.0 100.0 100.0
+ main.f Main 94 1 0.0 0.0 100.0 99.9
+ fib Main 95 2692537 100.0 99.9 100.0 99.9
+ main.g Main 92 1 0.0 0.0 0.0 0.1
+ fib Main 93 1973 0.0 0.1 0.0 0.1
+ CAF GHC.IO.Handle.Text 86 0 0.0 0.0 0.0 0.0
+ CAF GHC.IO.Handle.FD 82 0 0.0 0.0 0.0 0.0
+ CAF GHC.Conc.Signal 78 0 0.0 0.0 0.0 0.0
+ CAF GHC.IO.Encoding 76 0 0.0 0.0 0.0 0.0
+ CAF GHC.IO.Encoding.Iconv 75 0 0.0 0.0 0.0 0.0
*** unexpected failure for prof-doc-fib(profasm)
```
The former is also observed by SPJ. The latter actually looks less like a regression, and more an improvement – maybe Herbert simply did not run a profiled version when updating test results?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.9 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | hvr |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Test suite regressions due to integer-gmp2","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.9","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["hvr"],"type":"Bug","description":"According to my performance builders, changeset:c774b28/ghc (Phab:D82) caused prof-doc-fib and linker_unload to fail on both performance builders (Ubuntu 13.10 and Ubuntu 14.04):\r\n\r\n{{{\r\nWrong exit code (expected 0 , actual 2 )\r\nStdout:\r\n\r\nStderr:\r\nlinker_unload: /home/nomeata/logs/ghc-tmp-REV/libraries/integer-gmp2/dist-install/build/libHSinteg_21cuTlnn00eFNd4GMrxOMi.a: unknown symbol `__gmpn_rshift'\r\nlinker_unload: resolveObjs failed\r\nmake[3]: *** [linker_unload] Error 1\r\n\r\n*** unexpected failure for linker_unload(normal)\r\n}}}\r\nand\r\n{{{\r\nActual prof output differs from expected:\r\n--- ./profiling/should_run/prof-doc-fib.prof.sample 2014-12-01 15:30:19.000000000 +0100\r\n+++ ./profiling/should_run/prof-doc-fib.prof 2014-12-01 15:56:08.000000000 +0100\r\n@@ -1,9 +1,9 @@\r\n- Thu Oct 27 09:29 2011 Time and Allocation Profiling Report (Final)\r\n+ Mon Dec 1 15:56 2014 Time and Allocation Profiling Report (Final)\r\n \r\n- fib +RTS -p -RTS\r\n+ prof-doc-fib +RTS -hc -p -RTS\r\n \r\n- total time = 0.76 secs (38 ticks @ 20 ms)\r\n- total alloc = 247,940,020 bytes (excludes profiling overheads)\r\n+ total time = 0.14 secs (135 ticks @ 1000 us, 1 processor)\r\n+ total alloc = 107,829,304 bytes (excludes profiling overheads)\r\n \r\n COST CENTRE MODULE %time %alloc\r\n \r\n@@ -13,13 +13,16 @@\r\n individual inherited\r\n COST CENTRE MODULE no. entries %time %alloc %time %alloc\r\n \r\n-MAIN MAIN 102 0 0.0 0.0 100.0 100.0\r\n- CAF Main 203 0 0.0 0.0 100.0 100.0\r\n- main Main 204 1 0.0 0.0 100.0 100.0\r\n- main.g Main 207 1 0.0 0.0 0.0 0.1\r\n- fib Main 208 1973 0.0 0.1 0.0 0.1\r\n- main.f Main 205 1 0.0 0.0 100.0 99.9\r\n- fib Main 206 2692537 100.0 99.9 100.0 99.9\r\n- CAF GHC.Conc.Signal 201 0 0.0 0.0 0.0 0.0\r\n- CAF GHC.IO.Encoding.Iconv 191 0 0.0 0.0 0.0 0.0\r\n- CAF GHC.IO.Handle.FD 183 0 0.0 0.0 0.0 0.0\r\n+MAIN MAIN 45 0 0.0 0.0 100.0 100.0\r\n+ main Main 91 0 0.0 0.0 0.0 0.0\r\n+ CAF Main 89 0 0.0 0.0 100.0 100.0\r\n+ main Main 90 1 0.0 0.0 100.0 100.0\r\n+ main.f Main 94 1 0.0 0.0 100.0 99.9\r\n+ fib Main 95 2692537 100.0 99.9 100.0 99.9\r\n+ main.g Main 92 1 0.0 0.0 0.0 0.1\r\n+ fib Main 93 1973 0.0 0.1 0.0 0.1\r\n+ CAF GHC.IO.Handle.Text 86 0 0.0 0.0 0.0 0.0\r\n+ CAF GHC.IO.Handle.FD 82 0 0.0 0.0 0.0 0.0\r\n+ CAF GHC.Conc.Signal 78 0 0.0 0.0 0.0 0.0\r\n+ CAF GHC.IO.Encoding 76 0 0.0 0.0 0.0 0.0\r\n+ CAF GHC.IO.Encoding.Iconv 75 0 0.0 0.0 0.0 0.0\r\n*** unexpected failure for prof-doc-fib(profasm)\r\n}}}\r\n\r\nThe former is also observed by SPJ. The latter actually looks less like a regression, and more an improvement – maybe Herbert simply did not run a profiled version when updating test results?","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/9535Remove max_bytes_used from haddock tests2019-07-07T18:40:07ZJoachim Breitnermail@joachim-breitner.deRemove max_bytes_used from haddock testsSimon M says: “I think we should probably remove the max_bytes_used limits
for the Haddock tests.”
(I plan to “fix” this in the HIW contributors talk, so please do _not_ fix it just now :-))
<details><summary>Trac metadata</summary>
|...Simon M says: “I think we should probably remove the max_bytes_used limits
for the Haddock tests.”
(I plan to “fix” this in the HIW contributors talk, so please do _not_ fix it just now :-))
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.8.2 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Test Suite |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Remove max_bytes_used from haddock tests","status":"New","operating_system":"","component":"Test Suite","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.8.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"Simon M says: “I think we should probably remove the max_bytes_used limits \r\nfor the Haddock tests.”\r\n\r\n(I plan to “fix” this in the HIW contributors talk, so please do _not_ fix it just now :-))","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/5608Fix T3807 for Mac OS X 10.52019-07-07T18:54:29ZthorkilnaurFix T3807 for Mac OS X 10.5Attached patch fixes (http://darcs.haskell.org/ghcBuilder/builders/tn23/479/11.html):
```
=====> T3807(normal) 591 of 3083 [0, 0, 1]
cd ./dynlibs && $MAKE --no-print-directory -s T3807 </dev/null >T3807.run.stdout 2>T3807.run.stderr
Wro...Attached patch fixes (http://darcs.haskell.org/ghcBuilder/builders/tn23/479/11.html):
```
=====> T3807(normal) 591 of 3083 [0, 0, 1]
cd ./dynlibs && $MAKE --no-print-directory -s T3807 </dev/null >T3807.run.stdout 2>T3807.run.stderr
Wrong exit code (expected 0 , actual 2 )
Stdout:
Failed to open shared library: dlopen(./T3807test.so, 10): Symbol not found: ___gmp_set_memory_functions
Referenced from: /Users/thorkilnaur/tn/builders/GHCBuilder/tn23/builder/tempbuild/build/bindisttest/install dir/lib/ghc-7.3.20111106/integer-gmp-0.3.0.0/libHSinteger-gmp-0.3.0.0-ghc7.3.20111106.dylib
Expected in: dynamic lookup
Stderr:
make[3]: *** [T3807] Error 1
*** unexpected failure for T3807(normal)
```
Validates on
```
$ uname -a
Darwin thorkil-naurs-intel-mac-mini.local 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.12.3
$
```
and
```
$ uname -a
Linux tn24 2.6.32-34-generic #77-Ubuntu SMP Tue Sep 13 19:40:53 UTC 2011 i686 GNU/Linux
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 6.12.3
$
```
Best regards
Thorkil
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.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":"Fix T3807 for Mac OS X 10.5","status":"New","operating_system":"","component":"Test Suite","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Attached patch fixes (http://darcs.haskell.org/ghcBuilder/builders/tn23/479/11.html):\r\n{{{\r\n=====> T3807(normal) 591 of 3083 [0, 0, 1]\r\ncd ./dynlibs && $MAKE --no-print-directory -s T3807 </dev/null >T3807.run.stdout 2>T3807.run.stderr\r\nWrong exit code (expected 0 , actual 2 )\r\nStdout:\r\nFailed to open shared library: dlopen(./T3807test.so, 10): Symbol not found: ___gmp_set_memory_functions\r\nReferenced from: /Users/thorkilnaur/tn/builders/GHCBuilder/tn23/builder/tempbuild/build/bindisttest/install dir/lib/ghc-7.3.20111106/integer-gmp-0.3.0.0/libHSinteger-gmp-0.3.0.0-ghc7.3.20111106.dylib\r\nExpected in: dynamic lookup\r\nStderr:\r\nmake[3]: *** [T3807] Error 1\r\n*** unexpected failure for T3807(normal)\r\n}}}\r\nValidates on\r\n{{{\r\n$ uname -a\r\nDarwin thorkil-naurs-intel-mac-mini.local 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386\r\n$ ghc --version\r\nThe Glorious Glasgow Haskell Compilation System, version 6.12.3\r\n$ \r\n}}}\r\nand\r\n{{{\r\n$ uname -a\r\nLinux tn24 2.6.32-34-generic #77-Ubuntu SMP Tue Sep 13 19:40:53 UTC 2011 i686 GNU/Linux\r\n$ ghc --version\r\nThe Glorious Glasgow Haskell Compilation System, version 6.12.3\r\n$ \r\n}}}\r\nBest regards\r\nThorkil","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/10449Out-of-tree tests broken on MinGW + native Python due to quoting of config.co...2019-07-07T18:35:52ZRufflewindOut-of-tree tests broken on MinGW + native Python due to quoting of config.compilerEver since commit 5258566ee5c89aa757b0cf1433169346319c018f it seems that out-of-tree tests will not run on MinGW anymore. Note that I am using MinGW tools with a native Windows build of Python, which is the main cause of the problem.
Th...Ever since commit 5258566ee5c89aa757b0cf1433169346319c018f it seems that out-of-tree tests will not run on MinGW anymore. Note that I am using MinGW tools with a native Windows build of Python, which is the main cause of the problem.
The apparent error is something along the lines of "cannot eval an empty string":
```
Traceback (most recent call last):
File "testsuite/driver/runtests.py", line 196, in <module>
get_compiler_info()
File "<string>", line 166, in get_compiler_info
File "<string>", line 0
^
SyntaxError: unexpected EOF while parsing
```
But this error is quite misleading. What really happened was that it tried to run GHC with the `--info` argument but failed silently and returned an empty string. If you apply D908, it becomes a lot more obvious: Python is failing to run `/c/programs/ghc/bin/ghc --info` because `/c/programs/ghc/bin/ghc` "does not exist" as Python does not understand MinGW-style paths.
The funny thing is that it worked just fine before 525856, so you have to wonder why quoting the paths caused this. It turns out that MinGW does some magic behind the scenes, automagically converting MinGW-style paths into ordinary Python paths when a native Windows program is invoked. In particular, it means running this in MinGW shell
```
python run-tests.py -e 'config.compiler=/c/programs/ghc/ghc'
```
will actually invoke Python with `config.compiler=C:/programs/ghc/ghc`. However, if it's explicitly quoted (*edit:* and also escaped with backslashes) like this
```
python run-tests.py -e 'config.compiler="\"/c/programs/ghc/ghc\""'
```
the magic doesn't work anymore.7.10.2https://gitlab.haskell.org/ghc/ghc/-/issues/10441msys native python testsuite support doesn't work in some situations2019-07-07T18:35:54ZEdward Z. Yangmsys native python testsuite support doesn't work in some situationsOn a vanilla Windows 8.1, msys2 GHC installation with only msys python installed, the testsuite driver is broken. I know of one other person whose testsuite is also not working. The usual error message is:
```
cd ./typecheck/should_comp...On a vanilla Windows 8.1, msys2 GHC installation with only msys python installed, the testsuite driver is broken. I know of one other person whose testsuite is also not working. The usual error message is:
```
cd ./typecheck/should_compile && "C:/msys64/home/ezy.exe" -c tc055.hs -fforce-recomp -dcore-lint -dcmm-lib -rtsopts -fno-warn-tabs -fno-ghci-history -fno-warnrr 2>&1
'..\timeout\install-inplace\bin\timeout.exe" "300" "cexternal command,
operable program or batch file.
Compile failed (status 256) errors were:
```
I have diagnosed the problem to the fact that we are passing a complex command string to cmd with adequately quoting it. In particular, when I inspect the command line that Python is attempting to invoke, it looks something like this:
```
cmd \c 'timeout.exe 300 "cd . && "inplace/ghc-stage2" -c blah blah"'
```
Notice, in particular, that the quoted GHC executable was not inside the timeout invocation is not double-quoted, so cmd does NOT parse the command the way you want it to.
Curiously enough, when I remove this fix (introduced by commit `101c62e26286353dd3fac1ef54323529b64c9902`), the msys Python runner works fine. So I don't even know what this commit was intended to fix; it seems to have done more harm than good
Here are some details about my configuration:
```
ezyang@cutlass MSYS ~/ghc-validate/testsuite
$ python2 --version
Python 2.7.9
ezyang@cutlass MSYS ~/ghc-validate/testsuite
$ bash --version
GNU bash, version 4.3.33(3)-release (x86_64-pc-msys)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.11 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Test Suite |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"msys native python testsuite support doesn't work in some situations","status":"New","operating_system":"","component":"Test Suite","related":[],"milestone":"7.12.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"On a vanilla Windows 8.1, msys2 GHC installation with only msys python installed, the testsuite driver is broken. I know of one other person whose testsuite is also not working. The usual error message is:\r\n\r\n{{{\r\ncd ./typecheck/should_compile && \"C:/msys64/home/ezy.exe\" -c tc055.hs -fforce-recomp -dcore-lint -dcmm-lib -rtsopts -fno-warn-tabs -fno-ghci-history -fno-warnrr 2>&1\r\n'..\\timeout\\install-inplace\\bin\\timeout.exe\" \"300\" \"cexternal command,\r\noperable program or batch file.\r\nCompile failed (status 256) errors were:\r\n}}}\r\n\r\nI have diagnosed the problem to the fact that we are passing a complex command string to cmd with adequately quoting it. In particular, when I inspect the command line that Python is attempting to invoke, it looks something like this:\r\n\r\n{{{\r\ncmd \\c 'timeout.exe 300 \"cd . && \"inplace/ghc-stage2\" -c blah blah\"'\r\n}}}\r\n\r\nNotice, in particular, that the quoted GHC executable was not inside the timeout invocation is not double-quoted, so cmd does NOT parse the command the way you want it to.\r\n\r\nCuriously enough, when I remove this fix (introduced by commit `101c62e26286353dd3fac1ef54323529b64c9902`), the msys Python runner works fine. So I don't even know what this commit was intended to fix; it seems to have done more harm than good\r\n\r\nHere are some details about my configuration:\r\n\r\n{{{\r\nezyang@cutlass MSYS ~/ghc-validate/testsuite\r\n$ python2 --version\r\nPython 2.7.9\r\n\r\nezyang@cutlass MSYS ~/ghc-validate/testsuite\r\n$ bash --version\r\nGNU bash, version 4.3.33(3)-release (x86_64-pc-msys)\r\nCopyright (C) 2013 Free Software Foundation, Inc.\r\nLicense GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>\r\n\r\n\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->7.10.2https://gitlab.haskell.org/ghc/ghc/-/issues/10126Test framework should not assume that GHC tools are in the same directory as ...2019-07-07T18:37:23ZRufflewindTest framework should not assume that GHC tools are in the same directory as GHC itselfThe GHC test framework assumes that the GHC tools (`ghc-pkg`, `runghc`, `hsc2hs`, etc) are always in the same directory as `ghc` itself
While this is probably a safe assumption for "in-tree" compilers, it's not necessarily true for "out...The GHC test framework assumes that the GHC tools (`ghc-pkg`, `runghc`, `hsc2hs`, etc) are always in the same directory as `ghc` itself
While this is probably a safe assumption for "in-tree" compilers, it's not necessarily true for "out-of-tree" compilers. For example, I currently have a thin wrapper of `ghc` in `$HOME/bin/ghc`, which causes the test framework to think that `ghc-pkg` is in `$HOME/bin/ghc-pkg`.
I think the restriction should be relaxed as long as `TEST_HC` is not specified and an out-of-tree compiler is used.
I suggest changing `testsuite/mk/boilerplate.mk` in the following way:
```patch
@@ -56,6 +56,7 @@ TEST_HC := $(STAGE2_GHC)
endif
else
+implicit_compiler = YES
IN_TREE_COMPILER = NO
TEST_HC := $(shell which ghc)
endif
@@ -87,24 +88,30 @@ endif
# containing spaces
BIN_ROOT = $(shell dirname '$(TEST_HC)')
+ifeq "$(implicit_compiler)" "YES"
+find_tool = $(shell which $(1))
+else
+find_tool = $(BIN_ROOT)/$(1)
+endif
+
ifeq "$(GHC_PKG)" ""
-GHC_PKG := $(BIN_ROOT)/ghc-pkg
+GHC_PKG := $(call find_tool,ghc-pkg)
endif
ifeq "$(RUNGHC)" ""
-RUNGHC := $(BIN_ROOT)/runghc
+RUNGHC := $(call find_tool,runghc)
endif
ifeq "$(HSC2HS)" ""
-HSC2HS := $(BIN_ROOT)/hsc2hs
+HSC2HS := $(call find_tool,hsc2hs)
endif
ifeq "$(HP2PS_ABS)" ""
-HP2PS_ABS := $(BIN_ROOT)/hp2ps
+HP2PS_ABS := $(call find_tool,hp2ps)
endif
ifeq "$(HPC)" ""
-HPC := $(BIN_ROOT)/hpc
+HPC := $(call find_tool,hpc)
endif
$(eval $(call canonicaliseExecutable,TEST_HC))
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.8.4 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Test Suite |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Test framework should not assume that GHC tools are in the same directory as GHC itself","status":"New","operating_system":"","component":"Test Suite","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"Rufflewind"},"version":"7.8.4","keywords":["framework","makefile","test"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"The GHC test framework assumes that the GHC tools (`ghc-pkg`, `runghc`, `hsc2hs`, etc) are always in the same directory as `ghc` itself\r\n\r\nWhile this is probably a safe assumption for \"in-tree\" compilers, it's not necessarily true for \"out-of-tree\" compilers. For example, I currently have a thin wrapper of `ghc` in `$HOME/bin/ghc`, which causes the test framework to think that `ghc-pkg` is in `$HOME/bin/ghc-pkg`.\r\n\r\nI think the restriction should be relaxed as long as `TEST_HC` is not specified and an out-of-tree compiler is used.\r\n\r\nI suggest changing `testsuite/mk/boilerplate.mk` in the following way:\r\n{{{#!patch\r\n@@ -56,6 +56,7 @@ TEST_HC := $(STAGE2_GHC)\r\n endif\r\n\r\n else\r\n+implicit_compiler = YES\r\n IN_TREE_COMPILER = NO\r\n TEST_HC := $(shell which ghc)\r\n endif\r\n@@ -87,24 +88,30 @@ endif\r\n # containing spaces\r\n BIN_ROOT = $(shell dirname '$(TEST_HC)')\r\n\r\n+ifeq \"$(implicit_compiler)\" \"YES\"\r\n+find_tool = $(shell which $(1))\r\n+else\r\n+find_tool = $(BIN_ROOT)/$(1)\r\n+endif\r\n+\r\n ifeq \"$(GHC_PKG)\" \"\"\r\n-GHC_PKG := $(BIN_ROOT)/ghc-pkg\r\n+GHC_PKG := $(call find_tool,ghc-pkg)\r\n endif\r\n\r\n ifeq \"$(RUNGHC)\" \"\"\r\n-RUNGHC := $(BIN_ROOT)/runghc\r\n+RUNGHC := $(call find_tool,runghc)\r\n endif\r\n\r\n ifeq \"$(HSC2HS)\" \"\"\r\n-HSC2HS := $(BIN_ROOT)/hsc2hs\r\n+HSC2HS := $(call find_tool,hsc2hs)\r\n endif\r\n\r\n ifeq \"$(HP2PS_ABS)\" \"\"\r\n-HP2PS_ABS := $(BIN_ROOT)/hp2ps\r\n+HP2PS_ABS := $(call find_tool,hp2ps)\r\n endif\r\n\r\n ifeq \"$(HPC)\" \"\"\r\n-HPC := $(BIN_ROOT)/hpc\r\n+HPC := $(call find_tool,hpc)\r\n endif\r\n\r\n $(eval $(call canonicaliseExecutable,TEST_HC))\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.10.2https://gitlab.haskell.org/ghc/ghc/-/issues/11521Test failures for the `profasm` way when BUILD_PROF_LIBS=YES2019-07-07T18:30:05ZThomas MiedemaTest failures for the `profasm` way when BUILD_PROF_LIBS=YESWhen running `validate --slow`, which also builds libraries the profiling way now (see #11496), a lot of tests are failing for test ways `profasm` and `profthreaded`.
To reproduce, set `BUILD_PROF_LIBS=YES` in `mk/build.mk` and run `mak...When running `validate --slow`, which also builds libraries the profiling way now (see #11496), a lot of tests are failing for test ways `profasm` and `profthreaded`.
To reproduce, set `BUILD_PROF_LIBS=YES` in `mk/build.mk` and run `make` in toplevel directory. Then run:
`make test CLEANUP=1 WAY=profasm TEST="T2552 cgrun045 T5626 cgrun051 cgrun016 cgrun059 T2120 T11193 T9078 overflow3 overflow2 overflow1 T10728 T7919 T11049 T5550 conc021 SplicesUsed T5654b-O1 T5654b-O0 T2552 Rules1 T3220 T7837 ColInference3 hpc_fork ffi008 fptrfail01 TH_spliceViewPat overloadedrecfldsrun04 overloadedlabelsrun04 arr004 arr007 arr008 arr003 assert T8089 readFloat stm060 T5628 tough T7411 qq007 qq008 qq009"`
(some of the above tests might be failing for other reasons, but most should be about this issue)
Here is an example failure:
```
--- ./codeGen/should_run/cgrun045.stderr.normalised 2016-01-31 16:34:03.831816885 +0100
+++ ./codeGen/should_run/cgrun045.run.stderr.normalised 2016-01-31 16:34:03.831816885 +0100
@@ -1,3 +1,6 @@
cgrun045: hello world!
CallStack (from HasCallStack):
error, called at cgrun045.hs:<line>:<column> in <package-id>:Main
\ No newline at end of file
+CallStack (from -prof):
+ Main.main (cgrun045.hs:6:1-52)
+ Main.CAF (<entire-module>)
\ No newline at end of file
*** unexpected failure for cgrun045(profasm)
```
Is this expected behavior? The double callstacks look a little weird to me.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.11 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Test Suite |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | gridaphobe |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Test failures for the `profasm` way when BUILD_PROF_LIBS=YES","status":"New","operating_system":"","component":"Test Suite","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["gridaphobe"],"type":"Bug","description":"When running `validate --slow`, which also builds libraries the profiling way now (see #11496), a lot of tests are failing for test ways `profasm` and `profthreaded`.\r\n\r\nTo reproduce, set `BUILD_PROF_LIBS=YES` in `mk/build.mk` and run `make` in toplevel directory. Then run:\r\n\r\n`make test CLEANUP=1 WAY=profasm TEST=\"T2552 cgrun045 T5626 cgrun051 cgrun016 cgrun059 T2120 T11193 T9078 overflow3 overflow2 overflow1 T10728 T7919 T11049 T5550 conc021 SplicesUsed T5654b-O1 T5654b-O0 T2552 Rules1 T3220 T7837 ColInference3 hpc_fork ffi008 fptrfail01 TH_spliceViewPat overloadedrecfldsrun04 overloadedlabelsrun04 arr004 arr007 arr008 arr003 assert T8089 readFloat stm060 T5628 tough T7411 qq007 qq008 qq009\"`\r\n\r\n(some of the above tests might be failing for other reasons, but most should be about this issue)\r\n\r\nHere is an example failure:\r\n{{{\r\n--- ./codeGen/should_run/cgrun045.stderr.normalised\t2016-01-31 16:34:03.831816885 +0100\r\n+++ ./codeGen/should_run/cgrun045.run.stderr.normalised\t2016-01-31 16:34:03.831816885 +0100\r\n@@ -1,3 +1,6 @@\r\n cgrun045: hello world!\r\n CallStack (from HasCallStack):\r\n error, called at cgrun045.hs:<line>:<column> in <package-id>:Main\r\n\\ No newline at end of file\r\n+CallStack (from -prof):\r\n+ Main.main (cgrun045.hs:6:1-52)\r\n+ Main.CAF (<entire-module>)\r\n\\ No newline at end of file\r\n*** unexpected failure for cgrun045(profasm)\r\n}}}\r\n\r\nIs this expected behavior? The double callstacks look a little weird to me.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/11060Failing tests on 32 bit platforms2019-07-07T18:32:20ZerikdFailing tests on 32 bit platformsOn 32 bit PowerPC and Arm I've been getting about 20 new test failures (starting about a week ago).
For example:
```
--- ./simplCore/should_compile/T8274.stdout.normalised
+++ ./simplCore/should_compile/T8274.run.stdout.normalised
@@ ...On 32 bit PowerPC and Arm I've been getting about 20 new test failures (starting about a week ago).
For example:
```
--- ./simplCore/should_compile/T8274.stdout.normalised
+++ ./simplCore/should_compile/T8274.run.stdout.normalised
@@ -1,10 +1,10 @@
T8274.$trModule2 = TrNameS "main"#
T8274.$trModule1 = TrNameS "T8274"#
T8274.$tcP1 = TrNameS "P"#
- 11095028091707994303##
- 9476557054198009608##
+ 11095028091707994303L##
+ 9476557054198009608L##
T8274.$tcN1 = TrNameS "N"#
- 7479687563082171902##
- 17616649989360543185##
+ 7479687563082171902L##
+ 17616649989360543185L##
p = T8274.Positives 42# 4.23# 4.23## '4'# 4##
n = T8274.Negatives -4# -4.0# -4.0##
\ No newline at end of file
*** unexpected failure for T8274(normal)
```
This is simply a matter of a difference between the expected output `123##` vs `123L##`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.11 |
| 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":"Failing tests on 32 bit platforms","status":"New","operating_system":"","component":"Test Suite","related":[],"milestone":"8.0.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"On 32 bit PowerPC and Arm I've been getting about 20 new test failures (starting about a week ago).\r\n\r\nFor example:\r\n\r\n{{{\r\n--- ./simplCore/should_compile/T8274.stdout.normalised \r\n+++ ./simplCore/should_compile/T8274.run.stdout.normalised\r\n@@ -1,10 +1,10 @@\r\n T8274.$trModule2 = TrNameS \"main\"#\r\n T8274.$trModule1 = TrNameS \"T8274\"#\r\n T8274.$tcP1 = TrNameS \"P\"#\r\n- 11095028091707994303##\r\n- 9476557054198009608##\r\n+ 11095028091707994303L##\r\n+ 9476557054198009608L##\r\n T8274.$tcN1 = TrNameS \"N\"#\r\n- 7479687563082171902##\r\n- 17616649989360543185##\r\n+ 7479687563082171902L##\r\n+ 17616649989360543185L##\r\n p = T8274.Positives 42# 4.23# 4.23## '4'# 4##\r\n n = T8274.Negatives -4# -4.0# -4.0##\r\n\\ No newline at end of file\r\n*** unexpected failure for T8274(normal)\r\n}}}\r\n\r\nThis is simply a matter of a difference between the expected output `123##` vs `123L##`.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/10994GHCi segfaults when built with DYNAMIC_GHC_PROGRAMS = NO2019-07-07T18:32:45ZerikdGHCi segfaults when built with DYNAMIC_GHC_PROGRAMS = NOCurrent git HEAD has failing tests after [D975](https://phabricator.haskell.org/D975) when compiling with `DYNAMIC_GHC_PROGRAMS = NO`.
```
Unexpected failures:
ghci.debugger/scripts break001 [bad exit code] (ghci)
ghci.debugger/s...Current git HEAD has failing tests after [D975](https://phabricator.haskell.org/D975) when compiling with `DYNAMIC_GHC_PROGRAMS = NO`.
```
Unexpected failures:
ghci.debugger/scripts break001 [bad exit code] (ghci)
ghci.debugger/scripts break005 [bad exit code] (ghci)
ghci.debugger/scripts break006 [bad exit code] (ghci)
ghci.debugger/scripts break011 [bad exit code] (ghci)
ghci.debugger/scripts break017 [bad exit code] (ghci)
ghci.debugger/scripts dynbrk007 [bad exit code] (ghci)
ghci.debugger/scripts hist001 [bad exit code] (ghci)
ghci.debugger/scripts print001 [bad exit code] (ghci)
ghci.debugger/scripts print002 [bad exit code] (ghci)
ghci.debugger/scripts print003 [bad exit code] (ghci)
ghci.debugger/scripts print004 [bad exit code] (ghci)
ghci.debugger/scripts print005 [bad exit code] (ghci)
ghci.debugger/scripts print006 [bad exit code] (ghci)
ghci.debugger/scripts print008 [bad exit code] (ghci)
ghci.debugger/scripts print010 [bad exit code] (ghci)
ghci.debugger/scripts print011 [bad exit code] (ghci)
ghci.debugger/scripts print012 [bad exit code] (ghci)
ghci.debugger/scripts print013 [bad exit code] (ghci)
ghci.debugger/scripts print016 [bad exit code] (ghci)
ghci.debugger/scripts print017 [bad exit code] (ghci)
ghci.debugger/scripts print019 [bad exit code] (ghci)
ghci.debugger/scripts print020 [bad exit code] (ghci)
ghci.debugger/scripts print023 [bad exit code] (ghci)
ghci.debugger/scripts print024 [bad exit code] (ghci)
ghci.debugger/scripts print026 [bad exit code] (ghci)
ghci.debugger/scripts print028 [bad exit code] (ghci)
ghci.debugger/scripts print031 [bad exit code] (ghci)
ghci.debugger/scripts print032 [bad exit code] (ghci)
ghci.debugger/scripts print034 [bad exit code] (ghci)
ghci/scripts T2976 [bad exit code] (ghci)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.11 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Test Suite |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Test failing with DYNAMIC_GHC_PROGRAMS = NO","status":"New","operating_system":"","component":"Test Suite","related":[],"milestone":"8.0.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Current git HEAD has failing tests after Phab:D975 when compiling with `DYNAMIC_GHC_PROGRAMS = NO`.\r\n\r\n{{{\r\nUnexpected failures:\r\n ghci.debugger/scripts break001 [bad exit code] (ghci)\r\n ghci.debugger/scripts break005 [bad exit code] (ghci)\r\n ghci.debugger/scripts break006 [bad exit code] (ghci)\r\n ghci.debugger/scripts break011 [bad exit code] (ghci)\r\n ghci.debugger/scripts break017 [bad exit code] (ghci)\r\n ghci.debugger/scripts dynbrk007 [bad exit code] (ghci)\r\n ghci.debugger/scripts hist001 [bad exit code] (ghci)\r\n ghci.debugger/scripts print001 [bad exit code] (ghci)\r\n ghci.debugger/scripts print002 [bad exit code] (ghci)\r\n ghci.debugger/scripts print003 [bad exit code] (ghci)\r\n ghci.debugger/scripts print004 [bad exit code] (ghci)\r\n ghci.debugger/scripts print005 [bad exit code] (ghci)\r\n ghci.debugger/scripts print006 [bad exit code] (ghci)\r\n ghci.debugger/scripts print008 [bad exit code] (ghci)\r\n ghci.debugger/scripts print010 [bad exit code] (ghci)\r\n ghci.debugger/scripts print011 [bad exit code] (ghci)\r\n ghci.debugger/scripts print012 [bad exit code] (ghci)\r\n ghci.debugger/scripts print013 [bad exit code] (ghci)\r\n ghci.debugger/scripts print016 [bad exit code] (ghci)\r\n ghci.debugger/scripts print017 [bad exit code] (ghci)\r\n ghci.debugger/scripts print019 [bad exit code] (ghci)\r\n ghci.debugger/scripts print020 [bad exit code] (ghci)\r\n ghci.debugger/scripts print023 [bad exit code] (ghci)\r\n ghci.debugger/scripts print024 [bad exit code] (ghci)\r\n ghci.debugger/scripts print026 [bad exit code] (ghci)\r\n ghci.debugger/scripts print028 [bad exit code] (ghci)\r\n ghci.debugger/scripts print031 [bad exit code] (ghci)\r\n ghci.debugger/scripts print032 [bad exit code] (ghci)\r\n ghci.debugger/scripts print034 [bad exit code] (ghci)\r\n ghci/scripts T2976 [bad exit code] (ghci)\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/10834Test suite: Resistance against CallStack line number changes2019-07-07T18:33:38ZJoachim Breitnermail@joachim-breitner.deTest suite: Resistance against CallStack line number changesHi,
I just got this:
```
Actual stderr output differs from expected:
--- ./ghci/scripts/T10501.stderr.normalised 2015-09-03 00:20:22.622940998 +0000
+++ ./ghci/scripts/T10501.run.stderr.normalised 2015-09-03 00:20:22.622940998 +0000
@@...Hi,
I just got this:
```
Actual stderr output differs from expected:
--- ./ghci/scripts/T10501.stderr.normalised 2015-09-03 00:20:22.622940998 +0000
+++ ./ghci/scripts/T10501.run.stderr.normalised 2015-09-03 00:20:22.622940998 +0000
@@ -1,6 +1,6 @@
*** Exception: Prelude.head: empty list
CallStack:
- error, called at libraries/base/GHC/List.hs:1009:3 in base:GHC.List
+ error, called at libraries/base/GHC/List.hs:1011:3 in base:GHC.List
*** Exception: Prelude.undefined
CallStack:
error, called at libraries/base/GHC/Err.hs:42:14 in base:GHC.Err
*** unexpected failure for T10501(ghci)
```
Having the test suite so fragile is annoying. Would it be possible to ignore line number differences in call stacks?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.2 |
| 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":"Test suite: Resistance against CallStack line number changes","status":"New","operating_system":"","component":"Test Suite","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Hi,\r\n\r\nI just got this:\r\n\r\n{{{\r\nActual stderr output differs from expected:\r\n--- ./ghci/scripts/T10501.stderr.normalised\t2015-09-03 00:20:22.622940998 +0000\r\n+++ ./ghci/scripts/T10501.run.stderr.normalised\t2015-09-03 00:20:22.622940998 +0000\r\n@@ -1,6 +1,6 @@\r\n *** Exception: Prelude.head: empty list\r\n CallStack:\r\n- error, called at libraries/base/GHC/List.hs:1009:3 in base:GHC.List\r\n+ error, called at libraries/base/GHC/List.hs:1011:3 in base:GHC.List\r\n *** Exception: Prelude.undefined\r\n CallStack:\r\n error, called at libraries/base/GHC/Err.hs:42:14 in base:GHC.Err\r\n*** unexpected failure for T10501(ghci)\r\n}}}\r\n\r\nHaving the test suite so fragile is annoying. Would it be possible to ignore line number differences in call stacks?","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/10557Use `+RTS -G1` for more stable residency measurements2019-07-07T18:35:19ZThomas MiedemaUse `+RTS -G1` for more stable residency measurementsTests that measure `peak_megabytes_allocated` and `max_bytes_used` can be very sensitive to small changes in, well, just about anything: order of command line flags, what should be irrelevant compiler patches, minor changes in the test f...Tests that measure `peak_megabytes_allocated` and `max_bytes_used` can be very sensitive to small changes in, well, just about anything: order of command line flags, what should be irrelevant compiler patches, minor changes in the test file to compile.
From `Note [residency]` in `testsuite/tests/perf/compiler/all.T`:
```
# Residency (peak_megabytes_allocated and max_bytes_used) is sensitive
# to when the major GC runs, which makes it inherently inaccurate.
# Sometime an innocuous change somewhere can shift things around such
# that the samples occur at a different time, and the residency
# appears to change (up or down) when the underlying profile hasn't
# really changed.
```
I propose setting `+RTS -G1` for these tests. This seems to make them more robust to small changes, as can be seen in the following two graphs, adapted from the test for #9675:
https://ghc.haskell.org/trac/ghc/attachment/ticket/9675/T9675-peak_megabytes_allocated.png
https://ghc.haskell.org/trac/ghc/attachment/ticket/9675/T9675-max_bytes_used.png
This shows the `peak_megabytes_allocated` and `max_bytes_used` as a function of the number fields when compiling a single record:
```
data Foo = Foo
{ field1 :: Int -> Int
, field2 :: Int -> Int
...
```
The default `GHC -O` line is wiggling up and down, while the `GHC -O +RTS -G1` line is nice and smooth, which is what we want.
I don't know if making this change defeats the purpose of some tests, which is why I'm opening this ticket.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | --------------------- |
| Version | 7.10.1 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Test Suite |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ezyang, thoughtpolice |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Use `+RTS -G1` for more stable residency measurements","status":"New","operating_system":"","component":"Test Suite","related":[],"milestone":"7.12.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ezyang","thoughtpolice"],"type":"Task","description":"Tests that measure `peak_megabytes_allocated` and `max_bytes_used` can be very sensitive to small changes in, well, just about anything: order of command line flags, what should be irrelevant compiler patches, minor changes in the test file to compile.\r\n\r\nFrom `Note [residency]` in `testsuite/tests/perf/compiler/all.T`:\r\n{{{\r\n# Residency (peak_megabytes_allocated and max_bytes_used) is sensitive\r\n# to when the major GC runs, which makes it inherently inaccurate.\r\n# Sometime an innocuous change somewhere can shift things around such\r\n# that the samples occur at a different time, and the residency\r\n# appears to change (up or down) when the underlying profile hasn't\r\n# really changed.\r\n}}}\r\n\r\nI propose setting `+RTS -G1` for these tests. This seems to make them more robust to small changes, as can be seen in the following two graphs, adapted from the test for #9675:\r\n\r\nhttps://ghc.haskell.org/trac/ghc/attachment/ticket/9675/T9675-peak_megabytes_allocated.png\r\nhttps://ghc.haskell.org/trac/ghc/attachment/ticket/9675/T9675-max_bytes_used.png\r\n\r\nThis shows the `peak_megabytes_allocated` and `max_bytes_used` as a function of the number fields when compiling a single record:\r\n{{{\r\ndata Foo = Foo\r\n { field1 :: Int -> Int\r\n , field2 :: Int -> Int\r\n ...\r\n}}}\r\n\r\nThe default `GHC -O` line is wiggling up and down, while the `GHC -O +RTS -G1` line is nice and smooth, which is what we want.\r\n\r\nI don't know if making this change defeats the purpose of some tests, which is why I'm opening this ticket.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/10345Testsuite timeout_multiplier setting does not work as expected2019-07-07T18:36:29ZJan Stolarekjan.stolarek@ed.ac.ukTestsuite timeout_multiplier setting does not work as expectedI have a test case that - if failed - sends GHC into an infinite loop. The test case is small so I don't want to wait for default timeout (currently that's 5 minutes). The testsuite provides `timeout_multiplier` function to modify the de...I have a test case that - if failed - sends GHC into an infinite loop. The test case is small so I don't want to wait for default timeout (currently that's 5 minutes). The testsuite provides `timeout_multiplier` function to modify the default timeout but that setting seems to be ignored and the test is killed only after the default timeout time. I added my test to `all.T` file like this:
```
test('tc265', timeout_multiplier(0.01), compile, [''])
```
I also tried putting timeout setting into an array (`[timeout_multiplier(0.01)]`) but with no result.
Merijn reports having same problems and bypassing them by writing a test that forks itself and kills the child process after a given timeout - see \[\[GhcFile(libraries/base/tests/T8089.hs)\]\].
I am adding a note on \[[wiki:Building/RunningTests/Adding\#Thesetupfield](wiki:Building/RunningTests/Adding#Thesetupfield)\] that this field does not work currently. Once this bug is fixed we need to remove that note.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.11 |
| 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":"Testsuite timeout_multiplier setting does not work as expected","status":"New","operating_system":"","component":"Test Suite","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I have a test case that - if failed - sends GHC into an infinite loop. The test case is small so I don't want to wait for default timeout (currently that's 5 minutes). The testsuite provides `timeout_multiplier` function to modify the default timeout but that setting seems to be ignored and the test is killed only after the default timeout time. I added my test to `all.T` file like this:\r\n\r\n{{{\r\ntest('tc265', timeout_multiplier(0.01), compile, [''])\r\n}}}\r\n\r\nI also tried putting timeout setting into an array (`[timeout_multiplier(0.01)]`) but with no result.\r\n\r\nMerijn reports having same problems and bypassing them by writing a test that forks itself and kills the child process after a given timeout - see [[GhcFile(libraries/base/tests/T8089.hs)]].\r\n\r\nI am adding a note on [[wiki:Building/RunningTests/Adding#Thesetupfield]] that this field does not work currently. Once this bug is fixed we need to remove that note.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/10239Fragile CPP test for big endian in T76002019-07-07T18:36:56ZPeter Trommlerptrommler@acm.orgFragile CPP test for big endian in T7600In test T7600 the C pre-processor test for big endian is broken in older versions of glibc.
I have a patch that replaces the fragile CPP test with an integer read, which will always be the correct endianness.
<details><summary>Trac met...In test T7600 the C pre-processor test for big endian is broken in older versions of glibc.
I have a patch that replaces the fragile CPP test with an integer read, which will always be the correct endianness.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.1 |
| 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":"Fragile CPP test for big endian in T7600","status":"New","operating_system":"","component":"Test Suite","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"In test T7600 the C pre-processor test for big endian is broken in older versions of glibc.\r\n\r\nI have a patch that replaces the fragile CPP test with an integer read, which will always be the correct endianness.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1Peter Trommlerptrommler@acm.orgPeter Trommlerptrommler@acm.orghttps://gitlab.haskell.org/ghc/ghc/-/issues/10212The testsuite cleans up hpc files, even if they are part of a test.2019-07-07T18:37:04ZDave LaingThe testsuite cleans up hpc files, even if they are part of a test.Multiple validate runs start to fail hpc/T10138, since the .tix file and .hpc directory get cleaned up.
It seems there are two options here - we could make the test generate the .tix file and .hpc directory as it runs, or we could add a...Multiple validate runs start to fail hpc/T10138, since the .tix file and .hpc directory get cleaned up.
It seems there are two options here - we could make the test generate the .tix file and .hpc directory as it runs, or we could add an option to the test driver to not clean those files up for certain tests.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.11 |
| 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":"The testsuite cleans up hpc files, even if they are part of a test.","status":"New","operating_system":"","component":"Test Suite","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.11","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Multiple validate runs start to fail hpc/T10138, since the .tix file and .hpc directory get cleaned up.\r\n\r\nIt seems there are two options here - we could make the test generate the .tix file and .hpc directory as it runs, or we could add an option to the test driver to not clean those files up for certain tests.","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1Dave LaingDave Laing