GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2020-05-29T05:40:02Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/16846RTS STM Segmentation fault on Linux/MacOS2020-05-29T05:40:02ZPhilip KamenarskyRTS STM Segmentation fault on Linux/MacOS# Summary
[stm-bug.tar.gz](/uploads/f391344d67b7de42182ba9cbe672b968/stm-bug.tar.gz)
Compiling and running the attached project segfaults on both Linux and MacOs on GHC 8.0 through 8.6. I tried minimising the code as much as possible, ...# Summary
[stm-bug.tar.gz](/uploads/f391344d67b7de42182ba9cbe672b968/stm-bug.tar.gz)
Compiling and running the attached project segfaults on both Linux and MacOs on GHC 8.0 through 8.6. I tried minimising the code as much as possible, but I've reached a point where even inlining terms masks the segfault. Also, not using STM `retry` masks the segfault. Also, the code has to be spread across two modules, the segfault doesn't occur if everything is in e.g. Main.hs.
Sometimes, the RTS manages to shut down before a hard crash, i.e.:
```
stm-bug-0.1.0.0: unregistering (local file changes: src/Lib.hs)
stm-bug-0.1.0.0: build (lib + exe)
Preprocessing library for stm-bug-0.1.0.0..
Building library for stm-bug-0.1.0.0..
[2 of 2] Compiling Lib ( src/Lib.hs, .stack-work/dist/x86_64-linux/Cabal-2.4.0.1/build/Lib.o )
Preprocessing executable 'stm-bug-exe' for stm-bug-0.1.0.0..
Building executable 'stm-bug-exe' for stm-bug-0.1.0.0..
[1 of 2] Compiling Main ( app/Main.hs, .stack-work/dist/x86_64-linux/Cabal-2.4.0.1/build/stm-bug-exe/stm-bug-exe-tmp/Main.o ) [Lib changed]
Linking .stack-work/dist/x86_64-linux/Cabal-2.4.0.1/build/stm-bug-exe/stm-bug-exe ...
stm-bug-0.1.0.0: copy/register
Installing library in /home/phil/Projects/stm-bug/.stack-work/install/x86_64-linux/lts-13.26/8.6.5/lib/x86_64-linux-ghc-8.6.5/stm-bug-0.1.0.0-FnTyJxtuwWMDN9Vt5S3LQp
Installing executable stm-bug-exe in /home/phil/Projects/stm-bug/.stack-work/install/x86_64-linux/lts-13.26/8.6.5/bin
Registering library for stm-bug-0.1.0.0..
stm-bug-exe: internal error: evacuate: strange closure type 9435472
(GHC version 8.6.5 for x86_64_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
Aborted (core dumped)
```
Other error messages while isolating the test case where included references to `strange closure type 4325519`, `stg_ap_p_ret`, and `stg_END_STM_WATCH_QUEUE_closure`.
# Steps to reproduce
```
stack build && stack exec stm-bug-exe
```
# Expected behavior
Not segfault.
# Environment
* GHC version used: 8.0.* - 8.6.* (didn't test with 7.*)
* gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.10), Apple LLVM version 10.0.0 (clang-1000.11.45.5)
# Optional:
* Operating System: Linux, MacOS, maybe Windows
* System Architecture:8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/16195Program with trivial polymorphism leads to out of scope dictionary2019-07-07T18:01:00ZMatthew PickeringProgram with trivial polymorphism leads to out of scope dictionaryAlmost certainly due to c2455e647501c5a382861196b64df3dd05b620a2
A trivial program now causes a core lint error due to an out-of-scope dictionary.
```
module A where
foo :: Code (IO ())
foo = [|| return () ||]
```
```
module B where
...Almost certainly due to c2455e647501c5a382861196b64df3dd05b620a2
A trivial program now causes a core lint error due to an out-of-scope dictionary.
```
module A where
foo :: Code (IO ())
foo = [|| return () ||]
```
```
module B where
main :: IO ()
main = $$foo
```
```
*** Core Lint errors : in result of Desugar (before optimization) ***
<no location info>: warning:
In the expression: return @ IO $dMonad_a4od @ () ()
Out of scope: $dMonad_a4od :: Monad m_a4oc[tau:0]
[LclId]
*** Offending Program ***
Rec {
$trModule :: Module
[LclIdX]
$trModule = Module (TrNameS "main"#) (TrNameS "B"#)
main :: IO ()
[LclIdX]
main = return @ IO $dMonad_a4od @ () ()
end Rec }
*** End of Offense ***
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.7 |
| 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":"Program with trivial polymorphism leads to out of scope dictionary","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.7","keywords":["TypedTemplateHaskell"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Almost certainly due to c2455e647501c5a382861196b64df3dd05b620a2\r\n\r\nA trivial program now causes a core lint error due to an out-of-scope dictionary. \r\n\r\n{{{\r\nmodule A where\r\n\r\nfoo :: Code (IO ())\r\nfoo = [|| return () ||]\r\n}}}\r\n\r\n{{{\r\nmodule B where\r\n\r\nmain :: IO ()\r\nmain = $$foo\r\n}}}\r\n\r\n{{{\r\n*** Core Lint errors : in result of Desugar (before optimization) ***\r\n<no location info>: warning:\r\n In the expression: return @ IO $dMonad_a4od @ () ()\r\n Out of scope: $dMonad_a4od :: Monad m_a4oc[tau:0]\r\n [LclId]\r\n*** Offending Program ***\r\nRec {\r\n$trModule :: Module\r\n[LclIdX]\r\n$trModule = Module (TrNameS \"main\"#) (TrNameS \"B\"#)\r\n\r\nmain :: IO ()\r\n[LclIdX]\r\nmain = return @ IO $dMonad_a4od @ () ()\r\nend Rec }\r\n\r\n*** End of Offense ***\r\n}}}\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/16113T14740 fails in debugged compiler2019-07-07T18:01:24ZBen GamariT14740 fails in debugged compiler```patch
--- parser/should_fail/T14740.run/T14740.stderr.normalised 2018-12-30 16:06:27.120170052 +0000
+++ parser/should_fail/T14740.run/T14740.comp.stderr.normalised 2018-12-30 16:06:27.120170052 +0000
@@ -1,4 +1,5 @@
+ghc: panic! (the...```patch
--- parser/should_fail/T14740.run/T14740.stderr.normalised 2018-12-30 16:06:27.120170052 +0000
+++ parser/should_fail/T14740.run/T14740.comp.stderr.normalised 2018-12-30 16:06:27.120170052 +0000
@@ -1,4 +1,5 @@
+ghc: panic! (the 'impossible' happened)
+ (GHC version 8.7.20181230 for x86_64-unknown-linux):
+ ASSERT failed! file compiler/types/TyCoRep.hs, line 911
-T14740.hs:5:7:
- Expecting a lifted type, but ‘(# #)’ is unlifted
- In the type signature: x :: ((# #)) => ()
+Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.6.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | goldfire, simonpj |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"T14740 fails in debugged compiler","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"8.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["goldfire","simonpj"],"type":"Bug","description":"{{{#!patch\r\n--- parser/should_fail/T14740.run/T14740.stderr.normalised\t2018-12-30 16:06:27.120170052 +0000\r\n+++ parser/should_fail/T14740.run/T14740.comp.stderr.normalised\t2018-12-30 16:06:27.120170052 +0000\r\n@@ -1,4 +1,5 @@\r\n+ghc: panic! (the 'impossible' happened)\r\n+ (GHC version 8.7.20181230 for x86_64-unknown-linux):\r\n+\tASSERT failed! file compiler/types/TyCoRep.hs, line 911\r\n \r\n-T14740.hs:5:7:\r\n- Expecting a lifted type, but ‘(# #)’ is unlifted\r\n- In the type signature: x :: ((# #)) => ()\r\n+Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/16073Hadrian build fails on Windows2019-07-07T18:01:38ZBen GamariHadrian build fails on Windows```
/---------------------------------------------------\
| Successfully built library 'rts' (Stage1, way v). |
| Library: _build/stage1/rts/build/libHSrts-1.0.a |
\---------------------------------------------------/
| Run Ld Stage1: ...```
/---------------------------------------------------\
| Successfully built library 'rts' (Stage1, way v). |
| Library: _build/stage1/rts/build/libHSrts-1.0.a |
\---------------------------------------------------/
| Run Ld Stage1: _build/stage1/rts/build/c/Adjustor.o (and 117 more) => _build/stage1/rts/build/HSrts-1.0.o
copyFile: does not exist (The system cannot find the file specified.)
shakeArgsWith 0.001s 0%
Function shake 0.017s 0%
Database read 0.337s 0%
With database 0.033s 0%
Running rules 4047.874s 99% =========================
Total 4048.261s 100%
Error when running Shake build system:
at src/Main.hs:58:30-42:
* Depends on: binary-dist
at src/Rules/BinaryDist.hs:97:9-21:
* Depends on: _build/stage1/lib/package.conf.d/rts-1.0.conf
* Raised the exception:
ExitFailure 1
```
See https://gitlab.haskell.org/ghc/ghc/-/jobs/2838.8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/16056Hadrian failure: Values have changed since being depended upon2019-07-07T18:01:41ZBen GamariHadrian failure: Values have changed since being depended uponThe Hadrian build on Windows appears to fail with:
```
/--------------------------------------------------------------------------\
| Successfully built program 'haddock' (Stage2). |
| Executable: _build/stage2...The Hadrian build on Windows appears to fail with:
```
/--------------------------------------------------------------------------\
| Successfully built program 'haddock' (Stage2). |
| Executable: _build/stage2/bin/haddock.exe |
| Program synopsis: A documentation-generation tool for Haskell libraries. |
\--------------------------------------------------------------------------/
shakeArgsWith 0.002s 0%
Function shake 0.035s 0%
Database read 0.003s 0%
With database 0.001s 0%
Running rules 2815.075s 99% =========================
Pool finished (9025 threads, 8 max) 0.001s 0%
Lint checking 0.641s 0%
Total 2815.758s 100%
Lint checking error - 520 values have changed since being depended upon:
Key: _build/stage1/gmp/objs/zero_p.o
Old: (Just File {mod=0x88773CC6,size=0x2EA,digest=0xACFF03E6},"")
New: File {mod=0x8C6CE092,size=0x2EA,digest=0xACFF03E6}
Key: _build/stage1/gmp/objs/zero.o
Old: (Just File {mod=0x88DC1816,size=0x2F8,digest=0x586B32DC},"")
New: File {mod=0x8CA46DC3,size=0x2F8,digest=0x586B32DC}
Key: _build/stage1/gmp/objs/xor_n.o
Old: (Just File {mod=0x88D86EC7,size=0x1DF,digest=0xFBB5353},"")
New: File {mod=0x8CA1D672,size=0x1DF,digest=0xFBB5353}
...
```
All paths listed are in `_build/stage1/gmp` and all changed only in their mtime.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------------- |
| Version | 8.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Build System (Hadrian) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Hadrian failure: Values have changed since being depended upon","status":"New","operating_system":"","component":"Build System (Hadrian)","related":[],"milestone":"8.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The Hadrian build on Windows appears to fail with:\r\n{{{\r\n/--------------------------------------------------------------------------\\\r\n| Successfully built program 'haddock' (Stage2). |\r\n| Executable: _build/stage2/bin/haddock.exe |\r\n| Program synopsis: A documentation-generation tool for Haskell libraries. |\r\n\\--------------------------------------------------------------------------/\r\nshakeArgsWith 0.002s 0% \r\nFunction shake 0.035s 0% \r\nDatabase read 0.003s 0% \r\nWith database 0.001s 0% \r\nRunning rules 2815.075s 99% =========================\r\nPool finished (9025 threads, 8 max) 0.001s 0% \r\nLint checking 0.641s 0% \r\nTotal 2815.758s 100% \r\nLint checking error - 520 values have changed since being depended upon:\r\n Key: _build/stage1/gmp/objs/zero_p.o\r\n Old: (Just File {mod=0x88773CC6,size=0x2EA,digest=0xACFF03E6},\"\")\r\n New: File {mod=0x8C6CE092,size=0x2EA,digest=0xACFF03E6}\r\n \r\n Key: _build/stage1/gmp/objs/zero.o\r\n Old: (Just File {mod=0x88DC1816,size=0x2F8,digest=0x586B32DC},\"\")\r\n New: File {mod=0x8CA46DC3,size=0x2F8,digest=0x586B32DC}\r\n \r\n Key: _build/stage1/gmp/objs/xor_n.o\r\n Old: (Just File {mod=0x88D86EC7,size=0x1DF,digest=0xFBB5353},\"\")\r\n New: File {mod=0x8CA1D672,size=0x1DF,digest=0xFBB5353}\r\n\r\n...\r\n}}}\r\n\r\nAll paths listed are in `_build/stage1/gmp` and all changed only in their mtime.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/16026No way to run a subset of the testsuite2019-07-07T18:01:58ZBen GamariNo way to run a subset of the testsuiteCurrently Hadrian lacks an analogue of the `TEST=...` variables in the `make` build system's `test` target. In other words, it's not possible to run a subset of the testsuite.
<details><summary>Trac metadata</summary>
| Trac field ...Currently Hadrian lacks an analogue of the `TEST=...` variables in the `make` build system's `test` target. In other words, it's not possible to run a subset of the testsuite.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------------- |
| Version | 8.6.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Build System (Hadrian) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"No way to run a subset of the testsuite","status":"New","operating_system":"","component":"Build System (Hadrian)","related":[],"milestone":"8.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"Currently Hadrian lacks an analogue of the `TEST=...` variables in the `make` build system's `test` target. In other words, it's not possible to run a subset of the testsuite.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1Alp MestanogullariAlp Mestanogullarihttps://gitlab.haskell.org/ghc/ghc/-/issues/15982Hadrian's `--configure` flag is broken on Windows2019-09-20T23:34:40ZAndrey MokhovHadrian's `--configure` flag is broken on WindowsFor some reason I can no longer use Hadrian's `--configure` flag. When I use it, the configuration step fails with the following obscure error:
```
rm: cannot remove '.MTREE': No such file or directory
```
This is certainly caused by t...For some reason I can no longer use Hadrian's `--configure` flag. When I use it, the configuration step fails with the following obscure error:
```
rm: cannot remove '.MTREE': No such file or directory
```
This is certainly caused by this line in `configure.ac`:
https://github.com/ghc/ghc/blob/93e86d6103757b43017535c92bc6970e9e2315a5/configure.ac\#L358
It's unclear what should be done in this case.
Here is the command line I use to invoke Hadrian:
```
hadrian\build --configure -j --flavour=quickest --integer-simple
```
When I run the configure script manually from the MinGW shell, it works fine.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------------- |
| Version | 8.6.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Build System (Hadrian) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown/Multiple |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Hadrian's `--configure` flag is broken on Windows","status":"New","operating_system":"Unknown/Multiple","component":"Build System (Hadrian)","related":[],"milestone":"8.6.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"For some reason I can no longer use Hadrian's `--configure` flag. When I use it, the configuration step fails with the following obscure error:\r\n\r\n{{{\r\nrm: cannot remove '.MTREE': No such file or directory\r\n}}}\r\n\r\nThis is certainly caused by this line in `configure.ac`:\r\n\r\nhttps://github.com/ghc/ghc/blob/93e86d6103757b43017535c92bc6970e9e2315a5/configure.ac#L358\r\n\r\nIt's unclear what should be done in this case.\r\n\r\n\r\nHere is the command line I use to invoke Hadrian:\r\n\r\n{{{\r\nhadrian\\build --configure -j --flavour=quickest --integer-simple\r\n}}}\r\n\r\nWhen I run the configure script manually from the MinGW shell, it works fine.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/15971Hadrian fails Shake's linter on Windows2020-02-28T10:49:42ZBen GamariHadrian fails Shake's linter on WindowsWhile trying to bring up a Hadrian builder on Windows I found the [following](https://gitlab.staging.haskell.org/ghc/ghc/-/jobs/440/raw); excerpting:
```
shakeArgsWith 0.001s 0%
Funct...While trying to bring up a Hadrian builder on Windows I found the [following](https://gitlab.staging.haskell.org/ghc/ghc/-/jobs/440/raw); excerpting:
```
shakeArgsWith 0.001s 0%
Function shake 0.407s 0%
Database read 0.001s 0%
With database 0.000s 0%
Running rules 3065.940s 99% =========================
Pool finished (2932 threads, 4 max) 0.002s 0%
Lint checking 1.810s 0%
Total 3068.160s 100%
Lint checking error - 520 values have changed since being depended upon:
Key: _build/stage1/gmp/objs/zero_p.o
Old: (Just File {mod=0x6D312A39,size=0x2EA,digest=0xACFF03E6} recomputed,"")
New: File {mod=0x7475B8F5,size=0x2EA,digest=0xACFF03E6}
Key: _build/stage1/gmp/objs/zero.o
Old: (Just File {mod=0x6DA1AAD9,size=0x2F8,digest=0x586B32DC} recomputed,"")
New: File {mod=0x74B61957,size=0x2F8,digest=0x586B32DC}
Key: _build/stage1/gmp/objs/xor_n.o
Old: (Just File {mod=0x6D9D3378,size=0x1DF,digest=0xFBB5353} recomputed,"")
New: File {mod=0x74B2AAEC,size=0x1DF,digest=0xFBB5353}
```
It looks like all of the gmp objects were somehow touched during the build, but their contents are unchanged. Strangely, none of these filenames appear elsewhere in the log, so it's unclear when they could have been touched.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.7 |
| 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":"Hadrian fails Shake's linter on Windows","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"While trying to bring up a Hadrian builder on Windows I found the [[https://gitlab.staging.haskell.org/ghc/ghc/-/jobs/440/raw|following]]; excerpting:\r\n{{{\r\nshakeArgsWith 0.001s 0% \r\nFunction shake 0.407s 0% \r\nDatabase read 0.001s 0% \r\nWith database 0.000s 0% \r\nRunning rules 3065.940s 99% =========================\r\nPool finished (2932 threads, 4 max) 0.002s 0% \r\nLint checking 1.810s 0% \r\nTotal 3068.160s 100% \r\nLint checking error - 520 values have changed since being depended upon:\r\n Key: _build/stage1/gmp/objs/zero_p.o\r\n Old: (Just File {mod=0x6D312A39,size=0x2EA,digest=0xACFF03E6} recomputed,\"\")\r\n New: File {mod=0x7475B8F5,size=0x2EA,digest=0xACFF03E6}\r\n \r\n Key: _build/stage1/gmp/objs/zero.o\r\n Old: (Just File {mod=0x6DA1AAD9,size=0x2F8,digest=0x586B32DC} recomputed,\"\")\r\n New: File {mod=0x74B61957,size=0x2F8,digest=0x586B32DC}\r\n \r\n Key: _build/stage1/gmp/objs/xor_n.o\r\n Old: (Just File {mod=0x6D9D3378,size=0x1DF,digest=0xFBB5353} recomputed,\"\")\r\n New: File {mod=0x74B2AAEC,size=0x1DF,digest=0xFBB5353}\r\n}}}\r\n\r\nIt looks like all of the gmp objects were somehow touched during the build, but their contents are unchanged. Strangely, none of these filenames appear elsewhere in the log, so it's unclear when they could have been touched.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/15950Hadrian build fails on Windows2019-07-07T18:02:19ZBen GamariHadrian build fails on WindowsAs of 509d5be69c7507ba5d0a5f39ffd1613a59e73eea,
```
$ hadrian/build.cabal.sh -j5 --flavour=Quick
...
$ hadrian/build.cabal.sh -j5 --flavour=Quick
| ContextData oracle: resolving data for 'iserv' (Stage1, v)...
| Configure package 'iser...As of 509d5be69c7507ba5d0a5f39ffd1613a59e73eea,
```
$ hadrian/build.cabal.sh -j5 --flavour=Quick
...
$ hadrian/build.cabal.sh -j5 --flavour=Quick
| ContextData oracle: resolving data for 'iserv' (Stage1, v)...
| Configure package 'iserv'
Configuring iserv-8.7.1...
creating
C:\msys64\home\ben\ghc\builds\0\project-0\_build\stage1\utils\iserv\build
"C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage0/bin/ghc.exe" "--numeric-version"
]0;1s (99%)C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage0/bin/ghc.exe is version
8.7.20181126
"C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage0/bin/ghc-pkg.exe" "--version"
C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage0/bin/ghc-pkg.exe is
version 8.7.20181126
"C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage0/bin/ghc.exe" "--supported-languages"
"C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage0/bin/ghc.exe" "--info"
Reading installed packages...
"C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage0/bin/ghc-pkg.exe" "dump" "--global" "-v0" "--global-package-db=C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage1/lib/package.conf.d"
"C:/msys64/home/ben/ghc/builds/0/project-0/_build/stage0/bin/ghc.exe" "--print-libdir" "-ghcversion-file=C:/msys64/home/ben/ghc/builds/0/project-0/_build/generated/ghcversion.h"
CallStack (from HasCallStack):
die', called at .\Distribution\Simple\Configure.hs:969:20 in Cabal-2.5.0.0-inplace:Distribution.Simple.Configure
configureFinalizedPackage, called at .\Distribution\Simple\Configure.hs:467:12 in Cabal-2.5.0.0-inplace:Distribution.Simple.Configure
configure, called at .\Distribution\Simple.hs:596:20 in Cabal-2.5.0.0-inplace:Distribution.Simple
confHook, called at .\Distribution\Simple\UserHooks.hs:67:5 in Cabal-2.5.0.0-inplace:Distribution.Simple.UserHooks
configureAction, called at .\Distribution\Simple.hs:178:19 in Cabal-2.5.0.0-inplace:Distribution.Simple
defaultMainHelper, called at .\Distribution\Simple.hs:148:3 in Cabal-2.5.0.0-inplace:Distribution.Simple
defaultMainWithHooksNoReadArgs, called at src\Hadrian\Haskell\Cabal\Parse.hs:145:14 in main:Hadrian.Haskell.Cabal.Parse
hadrian.exe: Encountered missing dependencies:
libiserv ==8.7.*
]0;FinishedshakeArgsWith 0.003s 0%
Function shake 0.442s 2%
Database read 0.851s 3% =
With database 0.033s 0%
Running rules 20.749s 93% =========================
Total 22.079s 100%
Error when running Shake build system:
at src/Main.hs:58:30-42:
* Depends on: test
at src/Rules/Test.hs:109:5-9:
* Depends on: _build/stage1/lib/bin/ghc-iserv.exe
at src/Development/Shake/Internal/Rules/Oracle.hs:157:43-68:
* Depends on: OracleQ (ContextDataKey (Context {stage = Stage1, package = Package {pkgType = Program, pkgName = "iserv", pkgPath = "utils/iserv"}, way = v}))
at src/Hadrian/Haskell/Cabal/Parse.hs:202:5-36:
* Depends on: _build/stage1/utils/iserv/setup-config
* Raised the exception:
ExitFailure 1
```
(Ignore garbage characters due to Window's broken ANSI console support).
This seems to only be reproducible on Windows.8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/15938Hadrian's recompilation check is extremely slow2019-07-07T18:02:22ZBen GamariHadrian's recompilation check is extremely slowI just Ctrl-C'd hadrian while it was building `libraries/base`, having noticed that I forgot to start it with `-j`. I then immediately restarted it and noticed that Hadrian needed to think for 45 seconds before it started even a single b...I just Ctrl-C'd hadrian while it was building `libraries/base`, having noticed that I forgot to start it with `-j`. I then immediately restarted it and noticed that Hadrian needed to think for 45 seconds before it started even a single build. This is orders of magnitude worse than `make` so something must be wrong.
I'm setting this at high priority since 45 seconds is longer than many complete `make` rebuilds.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------------- |
| Version | 8.6.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Build System (Hadrian) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Hadrian's recompilation check is extremely slow","status":"New","operating_system":"","component":"Build System (Hadrian)","related":[],"milestone":"8.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I just Ctrl-C'd hadrian while it was building `libraries/base`, having noticed that I forgot to start it with `-j`. I then immediately restarted it and noticed that Hadrian needed to think for 45 seconds before it started even a single build. This is orders of magnitude worse than `make` so something must be wrong.\r\n\r\nI'm setting this at high priority since 45 seconds is longer than many complete `make` rebuilds.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1Alp MestanogullariAlp Mestanogullarihttps://gitlab.haskell.org/ghc/ghc/-/issues/15920Implement a flag which disables safe Haskell2019-07-07T18:02:27ZMatthew PickeringImplement a flag which disables safe HaskellWhen adding a plugin to a module, it marks the module as unsafe. If I automatically run a plugin on every module I build then all the modules are therefore marked unsafe.
This means that libraries start failing to compile as the safety ...When adding a plugin to a module, it marks the module as unsafe. If I automatically run a plugin on every module I build then all the modules are therefore marked unsafe.
This means that libraries start failing to compile as the safety properties change. However, I don't care about safe haskell and want to turn off this error but there appears to be no way to do so.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Implement a flag which disables safe Haskell","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.3","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When adding a plugin to a module, it marks the module as unsafe. If I automatically run a plugin on every module I build then all the modules are therefore marked unsafe.\r\n\r\nThis means that libraries start failing to compile as the safety properties change. However, I don't care about safe haskell and want to turn off this error but there appears to be no way to do so.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/15915Add CI for integer-simple2019-07-07T18:02:28ZBen GamariAdd CI for integer-simpleWe should make sure that the `integer-simple` build gets tested occasionally. It is apparently currently broken.We should make sure that the `integer-simple` build gets tested occasionally. It is apparently currently broken.8.8.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/15873move to llvm 7 for 8.8.12019-07-07T18:02:37Zgeorge.colpittsmove to llvm 7 for 8.8.1<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.2 |
| Type | Task |
| TypeOfFailure |...<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.2 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"move to llvm 7 for 8.8.1","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/15853Unregisterised GHC panics when building test cgrun0182019-07-07T18:02:43ZIlias TsitsimpisUnregisterised GHC panics when building test cgrun018An unregisterised ghc-8.4 on amd64 panics when building test cgrun018.
```
Compile failed (exit code 1) errors were:
[1 of 1] Compiling Main ( cgrun018.hs, cgrun018.o )
ghc-stage2: panic! (the 'impossible' happened)
(GHC v...An unregisterised ghc-8.4 on amd64 panics when building test cgrun018.
```
Compile failed (exit code 1) errors were:
[1 of 1] Compiling Main ( cgrun018.hs, cgrun018.o )
ghc-stage2: panic! (the 'impossible' happened)
(GHC version 8.4.4 for x86_64-unknown-linux):
pprStatics: float
F32
F32
F32
F32
F32
F32
F32
F32
F32
F32
F32
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable
pprPanic, called at compiler/cmm/PprC.hs:525:5 in ghc:PprC
```
We have seen this error while building packages for Debian on 64-bit architectures where GHC is unregisterised (e.g., mips64el, s390x):
[gloss on mips64el](https://buildd.debian.org/status/fetch.php?pkg=haskell-gloss&arch=mips64el&ver=1.13.0.1-1&stamp=1540810998&raw=0),
[juicypixels on s390x](https://buildd.debian.org/status/fetch.php?pkg=haskell-juicypixels&arch=s390x&ver=3.2.9.5-3&stamp=1540808360&raw=0)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------ |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Compiler (CodeGen) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Unregisterised GHC panics when building test cgrun018","status":"New","operating_system":"","component":"Compiler (CodeGen)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"An unregisterised ghc-8.4 on amd64 panics when building test cgrun018.\r\n\r\n{{{\r\nCompile failed (exit code 1) errors were:\r\n[1 of 1] Compiling Main ( cgrun018.hs, cgrun018.o )\r\nghc-stage2: panic! (the 'impossible' happened)\r\n (GHC version 8.4.4 for x86_64-unknown-linux):\r\n pprStatics: float\r\n F32\r\n F32\r\n F32\r\n F32\r\n F32\r\n F32\r\n F32\r\n F32\r\n F32\r\n F32\r\n F32\r\n Call stack:\r\n CallStack (from HasCallStack):\r\n callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable\r\n pprPanic, called at compiler/cmm/PprC.hs:525:5 in ghc:PprC\r\n}}}\r\n\r\nWe have seen this error while building packages for Debian on 64-bit architectures where GHC is unregisterised (e.g., mips64el, s390x):\r\n[https://buildd.debian.org/status/fetch.php?pkg=haskell-gloss&arch=mips64el&ver=1.13.0.1-1&stamp=1540810998&raw=0 gloss on mips64el],\r\n[https://buildd.debian.org/status/fetch.php?pkg=haskell-juicypixels&arch=s390x&ver=3.2.9.5-3&stamp=1540808360&raw=0 juicypixels on s390x]","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/15721Command `:show bindings` throws exception for bindings without `let`2019-07-07T18:03:18ZTao Hesighingnow@gmail.comCommand `:show bindings` throws exception for bindings without `let`The command `:show bindings` works for `let a = 1`:
```hs
Prelude> let a = 1
Prelude> :show bindings
a :: Num p => p = _
```
But not for `a = 1`:
```hs
Prelude> a = 1
Prelude> :show bindings
ghc-stage2.exe: ^^ Could not load 'interact...The command `:show bindings` works for `let a = 1`:
```hs
Prelude> let a = 1
Prelude> :show bindings
a :: Num p => p = _
```
But not for `a = 1`:
```hs
Prelude> a = 1
Prelude> :show bindings
ghc-stage2.exe: ^^ Could not load 'interactive_Ghci1_zdtrModule2_closure', dependency unresolved. See top entry above.
ghc-stage2.exe: ^^ Could not load 'interactive_Ghci1_zdtrModule4_closure', dependency unresolved. See top entry above.
$trModule :: GHC.Types.Module = _
$trModule1 :: GHC.Types.TrName = _
$trModule2 ::
GHC.Prim.Addr# = *** Exception:
ByteCodeLink.lookupCE
During interactive linking, GHCi couldn't find the following symbol:
interactive_Ghci1_zdtrModule2_closure
This may be due to you not asking GHCi to load extra object files,
archives or DLLs needed by your current session. Restart GHCi, specifying
the missing library using the -L/path/to/object/dir and -lmissinglibname
flags, or simply by naming the relevant files on the GHCi command line.
Alternatively, this link failure might indicate a bug in GHCi.
If you suspect the latter, please send a bug report to:
glasgow-haskell-bugs@haskell.org
$trModule3 :: GHC.Types.TrName = _
$trModule4 ::
GHC.Prim.Addr# = *** Exception:
ByteCodeLink.lookupCE
During interactive linking, GHCi couldn't find the following symbol:
interactive_Ghci1_zdtrModule4_closure
This may be due to you not asking GHCi to load extra object files,
archives or DLLs needed by your current session. Restart GHCi, specifying
the missing library using the -L/path/to/object/dir and -lmissinglibname
flags, or simply by naming the relevant files on the GHCi command line.
Alternatively, this link failure might indicate a bug in GHCi.
If you suspect the latter, please send a bug report to:
glasgow-haskell-bugs@haskell.org
a :: Num p => p = _
a1 :: Integer = _
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Command `:show bindings` throws exception for bindings without `let`","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The command `:show bindings` works for `let a = 1`:\r\n\r\n{{{#!hs\r\nPrelude> let a = 1\r\nPrelude> :show bindings\r\na :: Num p => p = _\r\n}}}\r\n\r\nBut not for `a = 1`:\r\n\r\n{{{#!hs\r\nPrelude> a = 1\r\nPrelude> :show bindings\r\nghc-stage2.exe: ^^ Could not load 'interactive_Ghci1_zdtrModule2_closure', dependency unresolved. See top entry above.\r\n\r\nghc-stage2.exe: ^^ Could not load 'interactive_Ghci1_zdtrModule4_closure', dependency unresolved. See top entry above.\r\n\r\n$trModule :: GHC.Types.Module = _\r\n$trModule1 :: GHC.Types.TrName = _\r\n$trModule2 ::\r\n GHC.Prim.Addr# = *** Exception:\r\nByteCodeLink.lookupCE\r\nDuring interactive linking, GHCi couldn't find the following symbol:\r\n interactive_Ghci1_zdtrModule2_closure\r\nThis may be due to you not asking GHCi to load extra object files,\r\narchives or DLLs needed by your current session. Restart GHCi, specifying\r\nthe missing library using the -L/path/to/object/dir and -lmissinglibname\r\nflags, or simply by naming the relevant files on the GHCi command line.\r\nAlternatively, this link failure might indicate a bug in GHCi.\r\nIf you suspect the latter, please send a bug report to:\r\n glasgow-haskell-bugs@haskell.org\r\n\r\n$trModule3 :: GHC.Types.TrName = _\r\n$trModule4 ::\r\n GHC.Prim.Addr# = *** Exception:\r\nByteCodeLink.lookupCE\r\nDuring interactive linking, GHCi couldn't find the following symbol:\r\n interactive_Ghci1_zdtrModule4_closure\r\nThis may be due to you not asking GHCi to load extra object files,\r\narchives or DLLs needed by your current session. Restart GHCi, specifying\r\nthe missing library using the -L/path/to/object/dir and -lmissinglibname\r\nflags, or simply by naming the relevant files on the GHCi command line.\r\nAlternatively, this link failure might indicate a bug in GHCi.\r\nIf you suspect the latter, please send a bug report to:\r\n glasgow-haskell-bugs@haskell.org\r\n\r\na :: Num p => p = _\r\na1 :: Integer = _\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/15718Build panic on ghc-8.6.1 under FreeBSD when using -fllvm2022-07-11T05:56:05Zgwright@antiope.comBuild panic on ghc-8.6.1 under FreeBSD when using -fllvmThis looks like a straightforward oversight. I am building my pure haskell LU solver under FreeBSD. I use the -fllvm compiler option because I need extra numerical performance.
When I build, I get (this is the output from GitLab CI, whi...This looks like a straightforward oversight. I am building my pure haskell LU solver under FreeBSD. I use the -fllvm compiler option because I need extra numerical performance.
When I build, I get (this is the output from GitLab CI, which is in turn running 'stack build')
```
Running with gitlab-runner 11.2.0 (35e8515d)
on stacker.18clay.com a2111f63
Using Shell executor...
Running on stacker.18clay.com...
Fetching changes...
Removing .stack-work/
HEAD is now at f8fe3b4 Use llvm60 on FreeBSD.
From https://gitlab.18clay.com/software/luSolve
f8fe3b4..c993a26 streamlined -> origin/streamlined
Checking out c993a262 as streamlined...
Skipping Git submodules setup
$ stack build --pedantic
luSolve-0.5: configure (lib)
Configuring luSolve-0.5...
luSolve-0.5: build (lib)
Preprocessing library for luSolve-0.5..
Building library for luSolve-0.5..
[1 of 1] Compiling Numeric.LinearAlgebra.LUSolve ( src/Numeric/LinearAlgebra/LUSolve.hs, .stack-work/dist/x86_64-freebsd/Cabal-2.4.0.1/build/Numeric/LinearAlgebra/LUSolve.o )
ghc: panic! (the 'impossible' happened)
(GHC version 8.6.1 for x86_64-portbld-freebsd):
Failed to lookup the datalayout for x86_64-unknown-freebsd; available targets: ["i386-unknown-windows","i686-unknown-windows","x86_64-unknown-windows","arm-unknown-linux-gnueabihf","armv6-unknown-linux-gnueabihf","armv6l-unknown-linux-gnueabihf","armv7-unknown-linux-gnueabihf","armv7a-unknown-linux-gnueabi","armv7l-unknown-linux-gnueabihf","aarch64-unknown-linux-gnu","aarch64-unknown-linux","i386-unknown-linux-gnu","i386-unknown-linux","x86_64-unknown-linux-gnu","x86_64-unknown-linux","armv7-unknown-linux-androideabi","aarch64-unknown-linux-android","powerpc64le-unknown-linux","amd64-portbld-freebsd","arm-unknown-nto-qnx-eabi","i386-apple-darwin","x86_64-apple-darwin","armv7-apple-ios","aarch64-apple-ios","i386-apple-ios","x86_64-apple-ios","aarch64-unknown-freebsd","armv6-unknown-freebsd-gnueabihf","armv7-unknown-freebsd-gnueabihf"]
CallStack (from HasCallStack):
error, called at compiler/llvmGen/LlvmCodeGen.hs:96:24 in ghc:LlvmCodeGen
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
-- While building custom Setup.hs for package luSolve-0.5 using:
/home/gitlab-runner/.stack/setup-exe-cache/x86_64-freebsd/Cabal-simple_mPHDZzAJ_2.4.0.1_ghc-8.6.1 --builddir=.stack-work/dist/x86_64-freebsd/Cabal-2.4.0.1 build lib:luSolve --ghc-options " -ddump-hi -ddump-to-file"
Process exited with code: ExitFailure 1
ERROR: Job failed: exit status 1
```
The bug seems simple. The compiler is looking for the datalayout for x86_64-unknown-freebsd; but what is available is amd64-portbld-freebsd. Is this just a simple naming error? The stack resolver was the cutting-edge nightly-2018-10-6; if it is a problem in their packaging rather than ghc itself I will file a report with them (though ghc did panic here, and as the breath ebbed from its ASTs and light faded from the code generator, it pleaded that a bug report be filed).
I've attached the .cabal file in case it helps.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.6.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Build panic on ghc-8.6.1 under FreeBSD when using -fllvm","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This looks like a straightforward oversight. I am building my pure haskell LU solver under FreeBSD. I use the -fllvm compiler option because I need extra numerical performance.\r\n\r\nWhen I build, I get (this is the output from GitLab CI, which is in turn running 'stack build')\r\n\r\n{{{\r\nRunning with gitlab-runner 11.2.0 (35e8515d)\r\n on stacker.18clay.com a2111f63\r\nUsing Shell executor...\r\nRunning on stacker.18clay.com...\r\nFetching changes...\r\nRemoving .stack-work/\r\nHEAD is now at f8fe3b4 Use llvm60 on FreeBSD.\r\nFrom https://gitlab.18clay.com/software/luSolve\r\n f8fe3b4..c993a26 streamlined -> origin/streamlined\r\nChecking out c993a262 as streamlined...\r\nSkipping Git submodules setup\r\n$ stack build --pedantic\r\nluSolve-0.5: configure (lib)\r\nConfiguring luSolve-0.5...\r\nluSolve-0.5: build (lib)\r\nPreprocessing library for luSolve-0.5..\r\nBuilding library for luSolve-0.5..\r\n[1 of 1] Compiling Numeric.LinearAlgebra.LUSolve ( src/Numeric/LinearAlgebra/LUSolve.hs, .stack-work/dist/x86_64-freebsd/Cabal-2.4.0.1/build/Numeric/LinearAlgebra/LUSolve.o )\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 8.6.1 for x86_64-portbld-freebsd):\r\n\tFailed to lookup the datalayout for x86_64-unknown-freebsd; available targets: [\"i386-unknown-windows\",\"i686-unknown-windows\",\"x86_64-unknown-windows\",\"arm-unknown-linux-gnueabihf\",\"armv6-unknown-linux-gnueabihf\",\"armv6l-unknown-linux-gnueabihf\",\"armv7-unknown-linux-gnueabihf\",\"armv7a-unknown-linux-gnueabi\",\"armv7l-unknown-linux-gnueabihf\",\"aarch64-unknown-linux-gnu\",\"aarch64-unknown-linux\",\"i386-unknown-linux-gnu\",\"i386-unknown-linux\",\"x86_64-unknown-linux-gnu\",\"x86_64-unknown-linux\",\"armv7-unknown-linux-androideabi\",\"aarch64-unknown-linux-android\",\"powerpc64le-unknown-linux\",\"amd64-portbld-freebsd\",\"arm-unknown-nto-qnx-eabi\",\"i386-apple-darwin\",\"x86_64-apple-darwin\",\"armv7-apple-ios\",\"aarch64-apple-ios\",\"i386-apple-ios\",\"x86_64-apple-ios\",\"aarch64-unknown-freebsd\",\"armv6-unknown-freebsd-gnueabihf\",\"armv7-unknown-freebsd-gnueabihf\"]\r\nCallStack (from HasCallStack):\r\n error, called at compiler/llvmGen/LlvmCodeGen.hs:96:24 in ghc:LlvmCodeGen\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\n\r\n-- While building custom Setup.hs for package luSolve-0.5 using:\r\n /home/gitlab-runner/.stack/setup-exe-cache/x86_64-freebsd/Cabal-simple_mPHDZzAJ_2.4.0.1_ghc-8.6.1 --builddir=.stack-work/dist/x86_64-freebsd/Cabal-2.4.0.1 build lib:luSolve --ghc-options \" -ddump-hi -ddump-to-file\"\r\n Process exited with code: ExitFailure 1\r\nERROR: Job failed: exit status 1\r\n}}}\r\n\r\nThe bug seems simple. The compiler is looking for the datalayout for x86_64-unknown-freebsd; but what is available is amd64-portbld-freebsd. Is this just a simple naming error? The stack resolver was the cutting-edge nightly-2018-10-6; if it is a problem in their packaging rather than ghc itself I will file a report with them (though ghc did panic here, and as the breath ebbed from its ASTs and light faded from the code generator, it pleaded that a bug report be filed).\r\n\r\nI've attached the .cabal file in case it helps.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/15669T7040_ghci has a suspicious testcase failure2019-07-07T18:03:30ZTamar ChristinaT7040_ghci has a suspicious testcase failureT7040_ghci has a weird failure. This looks like BSS initialization issue in the linker maybe?
```
+++ rts/T7040_ghci.run/T7040_ghci.run.stdout.normalised 2018-09-23 17:26:01.197146900 +0100
@@ -1,2 +1,2 @@
-x: 0
+x: 493156
x: 1
```
Lu...T7040_ghci has a weird failure. This looks like BSS initialization issue in the linker maybe?
```
+++ rts/T7040_ghci.run/T7040_ghci.run.stdout.normalised 2018-09-23 17:26:01.197146900 +0100
@@ -1,2 +1,2 @@
-x: 0
+x: 493156
x: 1
```
Luckily the value seems to mutate correctly. So it may just be a simple missing `memset`.
<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":"T7040_ghci has a suspicious testcase failure","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":"T7040_ghci has a weird failure. This looks like BSS initialization issue in the linker maybe?\r\n\r\n{{{\r\n+++ rts/T7040_ghci.run/T7040_ghci.run.stdout.normalised 2018-09-23 17:26:01.197146900 +0100\r\n@@ -1,2 +1,2 @@\r\n-x: 0\r\n+x: 493156\r\n x: 1\r\n}}}\r\n\r\nLuckily the value seems to mutate correctly. So it may just be a simple missing `memset`.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/15442GhcStage3HcOpts passed to ghc-stage12019-07-07T18:04:52ZBen GamariGhcStage3HcOpts passed to ghc-stage1When building a stage3 compiler the build system passes `GhcStage3HcOpts` to `inplace/bin/ghc-stage1` while building dependency lists:
```
$ make stage=3 GhcStage3HcOpts='+RTS -xn -RTS
"inplace/bin/ghc-stage1" -M -fPIC -dynamic -H32m -...When building a stage3 compiler the build system passes `GhcStage3HcOpts` to `inplace/bin/ghc-stage1` while building dependency lists:
```
$ make stage=3 GhcStage3HcOpts='+RTS -xn -RTS
"inplace/bin/ghc-stage1" -M -fPIC -dynamic -H32m -O -Wall -hide-all-packages -i -ighc/. -ighc/stage3/build -Ighc/stage3/build -ighc/stage3/build/ghc/autogen -Ighc/stage3/build/ghc/autogen -optP-DGHCI -optP-include -optPghc/stage3/build/ghc/autogen/cabal_macros.h -package-id array-0.5.2.0 -package-id base-4.12.0.0 -package-id bytestring-0.10.8.2 -package-id containers-0.6.0.1 -package-id deepseq-1.4.4.0 -package-id directory-1.3.2.3 -package-id filepath-1.4.2 -package-id ghc-8.7 -package-id ghc-boot-8.7 -package-id ghci-8.7 -package-id haskeline-0.7.4.2 -package-id process-1.6.3.0 -package-id time-1.8.0.2 -package-id transformers-0.5.5.0 -package-id unix-2.8.0.0 -Wall -Wnoncanonical-monad-instances -Wnoncanonical-monadfail-instances -Wnoncanonical-monoid-instances -fno-warn-name-shadowing -XHaskell2010 -O2 +RTS -xn -RTS -no-hs-main -threaded -no-user-package-db -rtsopts -Wnoncanonical-monad-instances -odir ghc/stage3/build -hidir ghc/stage3/build -stubdir ghc/stage3/build -dep-makefile ghc/stage3/build/.depend.haskell.tmp -dep-suffix "dyn_" -include-pkg-deps ghc/./Main.hs ghc/./GHCi/Leak.hs ghc/./GHCi/UI.hs ghc/./GHCi/UI/Info.hs ghc/./GHCi/UI/Monad.hs ghc/./GHCi/UI/Tags.hs
ghc-stage1: unknown RTS option: -xn
...
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GhcStage3HcOpts passed to ghc-stage1","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When building a stage3 compiler the build system passes `GhcStage3HcOpts` to `inplace/bin/ghc-stage1` while building dependency lists:\r\n{{{\r\n$ make stage=3 GhcStage3HcOpts='+RTS -xn -RTS\r\n\"inplace/bin/ghc-stage1\" -M -fPIC -dynamic -H32m -O -Wall -hide-all-packages -i -ighc/. -ighc/stage3/build -Ighc/stage3/build -ighc/stage3/build/ghc/autogen -Ighc/stage3/build/ghc/autogen -optP-DGHCI -optP-include -optPghc/stage3/build/ghc/autogen/cabal_macros.h -package-id array-0.5.2.0 -package-id base-4.12.0.0 -package-id bytestring-0.10.8.2 -package-id containers-0.6.0.1 -package-id deepseq-1.4.4.0 -package-id directory-1.3.2.3 -package-id filepath-1.4.2 -package-id ghc-8.7 -package-id ghc-boot-8.7 -package-id ghci-8.7 -package-id haskeline-0.7.4.2 -package-id process-1.6.3.0 -package-id time-1.8.0.2 -package-id transformers-0.5.5.0 -package-id unix-2.8.0.0 -Wall -Wnoncanonical-monad-instances -Wnoncanonical-monadfail-instances -Wnoncanonical-monoid-instances -fno-warn-name-shadowing -XHaskell2010 -O2 +RTS -xn -RTS -no-hs-main -threaded -no-user-package-db -rtsopts -Wnoncanonical-monad-instances -odir ghc/stage3/build -hidir ghc/stage3/build -stubdir ghc/stage3/build -dep-makefile ghc/stage3/build/.depend.haskell.tmp -dep-suffix \"dyn_\" -include-pkg-deps ghc/./Main.hs ghc/./GHCi/Leak.hs ghc/./GHCi/UI.hs ghc/./GHCi/UI/Info.hs ghc/./GHCi/UI/Monad.hs ghc/./GHCi/UI/Tags.hs\r\nghc-stage1: unknown RTS option: -xn\r\n...\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/15316Regarding coherence and implication loops in presence of QuantifiedConstraints2020-10-03T12:38:44ZmniipRegarding coherence and implication loops in presence of QuantifiedConstraintsFirst of all this piece of code:
```hs
{-# LANGUAGE RankNTypes, QuantifiedConstraints #-}
-- NB: disabling these if enabled:
{-# LANGUAGE NoUndecidableInstances, NoUndecidableSuperClasses #-}
import Data.Proxy
class Class a where
me...First of all this piece of code:
```hs
{-# LANGUAGE RankNTypes, QuantifiedConstraints #-}
-- NB: disabling these if enabled:
{-# LANGUAGE NoUndecidableInstances, NoUndecidableSuperClasses #-}
import Data.Proxy
class Class a where
method :: a
subsume :: (Class a => Class b) => Proxy a -> Proxy b -> ((Class a => Class b) => r) -> r
subsume _ _ x = x
value :: Proxy a -> a
value p = subsume p p method
```
This produces a nonterminating `value` even though nothing warranting recursion was used.
Adding:
```hs
value' :: Class a => Proxy a -> a
value' p = subsume p p method
```
Produces a `value'` that is legitimately equivalent to `method` in that it equals to the value in the dictionary whenever an instance exists (and doesn't typecheck otherwise). Thus two identical expressions in different instance contexts end up having different values (violating coherence?)
If we add:
```hs
joinSubsume :: Proxy a -> ((Class a => Class a) => r) -> r
joinSubsume p x = subsume p p x
```
The fact that this typechecks suggests that GHC is able to infer `Class a => Class a` at will, which doesn't seem wrong. However, the fact that `Class a` is solved from `Class a => Class a` via an infinite loop of implication constraints is questionable. Probably even outright wrong in absence of `UndecidableInstances`.
Another issue is the following:
```hs
{-# LANGUAGE ConstraintKinds #-}
subsume' :: Proxy c -> ((c => c) => r) -> r
subsume' _ x = x
```
```
• Reduction stack overflow; size = 201
When simplifying the following type: c
Use -freduction-depth=0 to disable this check
(any upper bound you could choose might fail unpredictably with
minor updates to GHC, so disabling the check is recommended if
you're sure that type checking should terminate)
• In the type signature:
subsume' :: Proxy c -> ((c => c) => r) -> r
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Regarding coherence and implication loops in presence of QuantifiedConstraints","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":["QuantifiedConstraints"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"First of all this piece of code:\r\n{{{#!hs\r\n{-# LANGUAGE RankNTypes, QuantifiedConstraints #-}\r\n-- NB: disabling these if enabled:\r\n{-# LANGUAGE NoUndecidableInstances, NoUndecidableSuperClasses #-}\r\n\r\nimport Data.Proxy\r\n\r\nclass Class a where\r\n\t method :: a\r\n\r\nsubsume :: (Class a => Class b) => Proxy a -> Proxy b -> ((Class a => Class b) => r) -> r\r\nsubsume _ _ x = x\r\n\r\nvalue :: Proxy a -> a\r\nvalue p = subsume p p method\r\n}}}\r\n\r\nThis produces a nonterminating `value` even though nothing warranting recursion was used.\r\n\r\nAdding:\r\n{{{#!hs\r\nvalue' :: Class a => Proxy a -> a\r\nvalue' p = subsume p p method\r\n}}}\r\nProduces a `value'` that is legitimately equivalent to `method` in that it equals to the value in the dictionary whenever an instance exists (and doesn't typecheck otherwise). Thus two identical expressions in different instance contexts end up having different values (violating coherence?)\r\n\r\nIf we add:\r\n{{{#!hs\r\njoinSubsume :: Proxy a -> ((Class a => Class a) => r) -> r\r\njoinSubsume p x = subsume p p x\r\n}}}\r\nThe fact that this typechecks suggests that GHC is able to infer `Class a => Class a` at will, which doesn't seem wrong. However, the fact that `Class a` is solved from `Class a => Class a` via an infinite loop of implication constraints is questionable. Probably even outright wrong in absence of `UndecidableInstances`.\r\n\r\nAnother issue is the following:\r\n{{{#!hs\r\n{-# LANGUAGE ConstraintKinds #-}\r\nsubsume' :: Proxy c -> ((c => c) => r) -> r\r\nsubsume' _ x = x\r\n}}}\r\n{{{\r\n • Reduction stack overflow; size = 201\r\n When simplifying the following type: c\r\n Use -freduction-depth=0 to disable this check\r\n (any upper bound you could choose might fail unpredictably with\r\n minor updates to GHC, so disabling the check is recommended if\r\n you're sure that type checking should terminate)\r\n • In the type signature:\r\n subsume' :: Proxy c -> ((c => c) => r) -> r\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/15216plugins10 broken2019-07-07T18:13:45ZBen Gamariplugins10 broken`plugins10` from [D4342](https://phabricator.haskell.org/D4342) is broken, but I am merging regardless and will sort it out later.
```
=====> plugins10(normal) 7 of 22 [0, 1, 0]
cd "./plugins/plugins10.run" && $MAKE -...`plugins10` from [D4342](https://phabricator.haskell.org/D4342) is broken, but I am merging regardless and will sort it out later.
```
=====> plugins10(normal) 7 of 22 [0, 1, 0]
cd "./plugins/plugins10.run" && $MAKE -s --no-print-directory -C simple-plugin package.plugins10 TOP=/mnt/work/ghc/ghc/testsuite
cd "./plugins/plugins10.run" && $MAKE -s --no-print-directory plugins10
Wrong exit code for plugins10()(expected 0 , actual 2 )
Stdout ( plugins10 ):
parsePlugin()
interfacePlugin: Prelude
interfacePlugin: Language.Haskell.TH
interfacePlugin: Language.Haskell.TH.Quote
interfacePlugin: GHC.Float
interfacePlugin: GHC.Base
interfacePlugin: Language.Haskell.TH.Syntax
interfacePlugin: GHC.Types
typeCheckPlugin (rn)
typeCheckPlugin (tc)
interfacePlugin: GHC.Integer.Type
parsePlugin(a)
interfacePlugin: Language.Haskell.TH.Lib.Internal
metaPlugin: return []
metaPlugin: quoteExp stringify "x"
interfacePlugin: GHC.CString
Stderr ( plugins10 ):
plugins10.hs:9:5: fatal:
cannot find object file for module ‘Simple.SourcePlugin’
while linking an interpreted expression
make[2]: *** [Makefile:30: plugins10] Error 1
*** unexpected failure for plugins10(normal)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| 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":"plugins10 broken","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":"`plugins10` from Phab:D4342 is broken, but I am merging regardless and will sort it out later.\r\n\r\n{{{\r\n=====> plugins10(normal) 7 of 22 [0, 1, 0] \r\ncd \"./plugins/plugins10.run\" && $MAKE -s --no-print-directory -C simple-plugin package.plugins10 TOP=/mnt/work/ghc/ghc/testsuite\r\ncd \"./plugins/plugins10.run\" && $MAKE -s --no-print-directory plugins10\r\nWrong exit code for plugins10()(expected 0 , actual 2 ) \r\nStdout ( plugins10 ): \r\nparsePlugin() \r\ninterfacePlugin: Prelude \r\ninterfacePlugin: Language.Haskell.TH \r\ninterfacePlugin: Language.Haskell.TH.Quote \r\ninterfacePlugin: GHC.Float \r\ninterfacePlugin: GHC.Base \r\ninterfacePlugin: Language.Haskell.TH.Syntax \r\ninterfacePlugin: GHC.Types \r\ntypeCheckPlugin (rn) \r\ntypeCheckPlugin (tc)\r\ninterfacePlugin: GHC.Integer.Type \r\nparsePlugin(a) \r\ninterfacePlugin: Language.Haskell.TH.Lib.Internal\r\nmetaPlugin: return [] \r\nmetaPlugin: quoteExp stringify \"x\"\r\ninterfacePlugin: GHC.CString \r\nStderr ( plugins10 ): \r\nplugins10.hs:9:5: fatal: \r\n cannot find object file for module ‘Simple.SourcePlugin’\r\n while linking an interpreted expression \r\nmake[2]: *** [Makefile:30: plugins10] Error 1 \r\n*** unexpected failure for plugins10(normal) \r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1Ben GamariBen Gamari