GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2020-02-17T11:34:32Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/13786GHCi linker is dependent upon object file order2020-02-17T11:34:32ZppelletiGHCi linker is dependent upon object file orderUsing [this package](https://github.com/ppelleti/hs-mercury-api), I tried doing "stack repl" with GHC 8.0.2:
```
whiteandnerdy:hs-mercury-api ppelleti$ stack repl
The following GHC options are incompatible with GHCi and have not been pa...Using [this package](https://github.com/ppelleti/hs-mercury-api), I tried doing "stack repl" with GHC 8.0.2:
```
whiteandnerdy:hs-mercury-api ppelleti$ stack repl
The following GHC options are incompatible with GHCi and have not been passed to it: -threaded
* * * * * * * *
The main module to load is ambiguous. Candidates are:
1. Package `mercury-api' component exe:tmr-firmware with main-is file: /Users/ppelleti/programming/haskell/hs-mercury-api/examples/tmr-firmware.hs
2. Package `mercury-api' component exe:tmr-gpio with main-is file: /Users/ppelleti/programming/haskell/hs-mercury-api/examples/tmr-gpio.hs
3. Package `mercury-api' component exe:tmr-lock with main-is file: /Users/ppelleti/programming/haskell/hs-mercury-api/examples/tmr-lock.hs
4. Package `mercury-api' component exe:tmr-params with main-is file: /Users/ppelleti/programming/haskell/hs-mercury-api/examples/tmr-params.hs
5. Package `mercury-api' component exe:tmr-read with main-is file: /Users/ppelleti/programming/haskell/hs-mercury-api/examples/tmr-read.hs
6. Package `mercury-api' component exe:tmr-write with main-is file: /Users/ppelleti/programming/haskell/hs-mercury-api/examples/tmr-write.hs
You can specify which one to pick by:
* Specifying targets to stack ghci e.g. stack ghci mercury-api:exe:tmr-firmware
* Specifying what the main is e.g. stack ghci --main-is mercury-api:exe:tmr-firmware
* Choosing from the candidate above [1..6]
* * * * * * * *
Specify main module to use (press enter to load none): 4
Loading main module from cadidate 4, --main-is /Users/ppelleti/programming/haskell/hs-mercury-api/examples/tmr-params.hs
Configuring GHCi with the following packages: mercury-api
GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help
ghc: panic! (the 'impossible' happened)
(GHC version 8.0.2 for x86_64-apple-darwin):
Loading temp shared object failed: dlopen(/var/folders/d1/v9ptqpx12mdcxj77509440rc0000gn/T/ghc91859_0/libghc_5.dylib, 5): Symbol not found: _TMR_SR_cmdStopReading
Referenced from: /var/folders/d1/v9ptqpx12mdcxj77509440rc0000gn/T/ghc91859_0/libghc_5.dylib
Expected in: flat namespace
in /var/folders/d1/v9ptqpx12mdcxj77509440rc0000gn/T/ghc91859_0/libghc_5.dylib
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
This bug appears to have been around a while, because it also happens with GHC 7.8.3:
```
whiteandnerdy:hs-mercury-api ppelleti$ cabal repl
Preprocessing library mercury-api-0.1.0.0...
GHCi, version 7.8.3: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Loading package array-0.5.0.0 ... linking ... done.
Loading package deepseq-1.3.0.2 ... linking ... done.
Loading package bytestring-0.10.4.0 ... linking ... done.
Loading package containers-0.5.5.1 ... linking ... done.
Loading package binary-0.7.1.0 ... linking ... done.
Loading package text-1.2.2.1 ... linking ... done.
Loading package hashable-1.2.6.0 ... linking ... done.
Loading package unordered-containers-0.2.8.0 ... linking ... done.
Loading package clock-0.7.2 ... linking ... done.
Loading package old-locale-1.0.0.6 ... linking ... done.
Loading package time-1.4.2 ... linking ... done.
Loading package unix-2.7.0.1 ... linking ... done.
Loading package ansi-terminal-0.6.2.3 ... linking ... done.
Loading object (static) dist/build/cbits/api/tmr_strerror.o ... done
Loading object (static) dist/build/cbits/api/tmr_param.o ... done
Loading object (static) dist/build/cbits/api/hex_bytes.o ... done
Loading object (static) dist/build/cbits/api/tm_reader.o ... ghc: panic! (the 'impossible' happened)
(GHC version 7.8.3 for x86_64-apple-darwin):
Loading temp shared object failed: dlopen(/var/folders/d1/v9ptqpx12mdcxj77509440rc0000gn/T/ghc91576_0/ghc91576_4.dylib, 9): Symbol not found: _TMR_SR_SerialTransportNativeInit
Referenced from: /var/folders/d1/v9ptqpx12mdcxj77509440rc0000gn/T/ghc91576_0/ghc91576_4.dylib
Expected in: flat namespace
in /var/folders/d1/v9ptqpx12mdcxj77509440rc0000gn/T/ghc91576_0/ghc91576_4.dylib
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
I'm using Mac OS X 10.9.5:
```
whiteandnerdy:hs-mercury-api ppelleti$ uname -a
Darwin whiteandnerdy.lan 13.4.0 Darwin Kernel Version 13.4.0: Mon Jan 11 18:17:34 PST 2016; root:xnu-2422.115.15~1/RELEASE_X86_64 x86_64
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.0.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | MacOS X |
| Architecture | x86_64 (amd64) |
</details>
<!-- {"blocked_by":[],"summary":"GHC panic on Mac OS X with \"cabal repl\" / \"stack repl\" on GHC 8.0.2 and 7.8.3","status":"New","operating_system":"MacOS X","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.2","keywords":[],"differentials":[],"test_case":"","architecture":"x86_64 (amd64)","cc":[""],"type":"Bug","description":"Using [https://github.com/ppelleti/hs-mercury-api this package], I tried doing \"stack repl\" with GHC 8.0.2:\r\n\r\n{{{\r\nwhiteandnerdy:hs-mercury-api ppelleti$ stack repl\r\nThe following GHC options are incompatible with GHCi and have not been passed to it: -threaded\r\n\r\n* * * * * * * *\r\nThe main module to load is ambiguous. Candidates are: \r\n1. Package `mercury-api' component exe:tmr-firmware with main-is file: /Users/ppelleti/programming/haskell/hs-mercury-api/examples/tmr-firmware.hs\r\n2. Package `mercury-api' component exe:tmr-gpio with main-is file: /Users/ppelleti/programming/haskell/hs-mercury-api/examples/tmr-gpio.hs\r\n3. Package `mercury-api' component exe:tmr-lock with main-is file: /Users/ppelleti/programming/haskell/hs-mercury-api/examples/tmr-lock.hs\r\n4. Package `mercury-api' component exe:tmr-params with main-is file: /Users/ppelleti/programming/haskell/hs-mercury-api/examples/tmr-params.hs\r\n5. Package `mercury-api' component exe:tmr-read with main-is file: /Users/ppelleti/programming/haskell/hs-mercury-api/examples/tmr-read.hs\r\n6. Package `mercury-api' component exe:tmr-write with main-is file: /Users/ppelleti/programming/haskell/hs-mercury-api/examples/tmr-write.hs\r\nYou can specify which one to pick by: \r\n * Specifying targets to stack ghci e.g. stack ghci mercury-api:exe:tmr-firmware\r\n * Specifying what the main is e.g. stack ghci --main-is mercury-api:exe:tmr-firmware\r\n * Choosing from the candidate above [1..6]\r\n* * * * * * * *\r\n\r\nSpecify main module to use (press enter to load none): 4\r\nLoading main module from cadidate 4, --main-is /Users/ppelleti/programming/haskell/hs-mercury-api/examples/tmr-params.hs\r\n\r\nConfiguring GHCi with the following packages: mercury-api\r\nGHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 8.0.2 for x86_64-apple-darwin):\r\n\tLoading temp shared object failed: dlopen(/var/folders/d1/v9ptqpx12mdcxj77509440rc0000gn/T/ghc91859_0/libghc_5.dylib, 5): Symbol not found: _TMR_SR_cmdStopReading\r\n Referenced from: /var/folders/d1/v9ptqpx12mdcxj77509440rc0000gn/T/ghc91859_0/libghc_5.dylib\r\n Expected in: flat namespace\r\n in /var/folders/d1/v9ptqpx12mdcxj77509440rc0000gn/T/ghc91859_0/libghc_5.dylib\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\nThis bug appears to have been around a while, because it also happens with GHC 7.8.3:\r\n\r\n{{{\r\nwhiteandnerdy:hs-mercury-api ppelleti$ cabal repl\r\nPreprocessing library mercury-api-0.1.0.0...\r\nGHCi, version 7.8.3: http://www.haskell.org/ghc/ :? for help\r\nLoading package ghc-prim ... linking ... done.\r\nLoading package integer-gmp ... linking ... done.\r\nLoading package base ... linking ... done.\r\nLoading package array-0.5.0.0 ... linking ... done.\r\nLoading package deepseq-1.3.0.2 ... linking ... done.\r\nLoading package bytestring-0.10.4.0 ... linking ... done.\r\nLoading package containers-0.5.5.1 ... linking ... done.\r\nLoading package binary-0.7.1.0 ... linking ... done.\r\nLoading package text-1.2.2.1 ... linking ... done.\r\nLoading package hashable-1.2.6.0 ... linking ... done.\r\nLoading package unordered-containers-0.2.8.0 ... linking ... done.\r\nLoading package clock-0.7.2 ... linking ... done.\r\nLoading package old-locale-1.0.0.6 ... linking ... done.\r\nLoading package time-1.4.2 ... linking ... done.\r\nLoading package unix-2.7.0.1 ... linking ... done.\r\nLoading package ansi-terminal-0.6.2.3 ... linking ... done.\r\nLoading object (static) dist/build/cbits/api/tmr_strerror.o ... done\r\nLoading object (static) dist/build/cbits/api/tmr_param.o ... done\r\nLoading object (static) dist/build/cbits/api/hex_bytes.o ... done\r\nLoading object (static) dist/build/cbits/api/tm_reader.o ... ghc: panic! (the 'impossible' happened)\r\n (GHC version 7.8.3 for x86_64-apple-darwin):\r\n\tLoading temp shared object failed: dlopen(/var/folders/d1/v9ptqpx12mdcxj77509440rc0000gn/T/ghc91576_0/ghc91576_4.dylib, 9): Symbol not found: _TMR_SR_SerialTransportNativeInit\r\n Referenced from: /var/folders/d1/v9ptqpx12mdcxj77509440rc0000gn/T/ghc91576_0/ghc91576_4.dylib\r\n Expected in: flat namespace\r\n in /var/folders/d1/v9ptqpx12mdcxj77509440rc0000gn/T/ghc91576_0/ghc91576_4.dylib\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\nI'm using Mac OS X 10.9.5:\r\n\r\n{{{\r\nwhiteandnerdy:hs-mercury-api ppelleti$ uname -a\r\nDarwin whiteandnerdy.lan 13.4.0 Darwin Kernel Version 13.4.0: Mon Jan 11 18:17:34 PST 2016; root:xnu-2422.115.15~1/RELEASE_X86_64 x86_64\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/15208GHC 8.4 fails to build on Debian armel (softfloat)2020-04-11T01:10:23ZclintGHC 8.4 fails to build on Debian armel (softfloat)This seems intentional but on the other hand the error message says "Please report this as a GHC bug"
```
"inplace/bin/ghc-stage1" -static -H32m -O -lffi -optl-pthread -optl-B/usr/bin/ld.gold -Wall -Iincludes -Iincludes/dist -Iinclud...This seems intentional but on the other hand the error message says "Please report this as a GHC bug"
```
"inplace/bin/ghc-stage1" -static -H32m -O -lffi -optl-pthread -optl-B/usr/bin/ld.gold -Wall -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -optc-DNOSMP -dcmm-lint -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 -Wcpp-undef -Wnoncanonical-monad-instances -c rts/StgStartup.cmm -o rts/dist/build/StgStartup.o
"inplace/bin/ghc-stage1" -static -H32m -O -lffi -optl-pthread -optl-B/usr/bin/ld.gold -Wall -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -optc-DNOSMP -dcmm-lint -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 -Wcpp-undef -Wnoncanonical-monad-instances -c rts/PrimOps.cmm -o rts/dist/build/PrimOps.o
"inplace/bin/ghc-stage1" -static -H32m -O -lffi -optl-pthread -optl-B/usr/bin/ld.gold -Wall -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -optc-DNOSMP -dcmm-lint -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 -Wcpp-undef -Wnoncanonical-monad-instances -c rts/Updates.cmm -o rts/dist/build/Updates.o
ghc-stage1: panic! (the 'impossible' happened)
(GHC version 8.4.3 for arm-unknown-linux):
Failed to lookup the datalayout for armv7l-unknown-linux-gnueabi; 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","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"]
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
rts/ghc.mk:295: recipe for target 'rts/dist/build/StgStartup.o' failed
make[3]: *** [rts/dist/build/StgStartup.o] Error 1
make[3]: *** Waiting for unfinished jobs....
ghc-stage1: panic! (the 'impossible' happened)
(GHC version 8.4.3 for arm-unknown-linux):
Failed to lookup the datalayout for armv7l-unknown-linux-gnueabi; 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","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"]
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
rts/ghc.mk:295: recipe for target 'rts/dist/build/Updates.o' failed
make[3]: *** [rts/dist/build/Updates.o] Error 1
ghc-stage1: panic! (the 'impossible' happened)
(GHC version 8.4.3 for arm-unknown-linux):
Failed to lookup the datalayout for armv7l-unknown-linux-gnueabi; 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","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"]
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
rts/ghc.mk:295: recipe for target 'rts/dist/build/PrimOps.o' failed
```
https://buildd.debian.org/status/fetch.php?pkg=ghc&arch=armel&ver=8.4.3-1&stamp=1527769922&raw=0
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC 8.4 fails to build on Debian armel (softfloat)","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":"This seems intentional but on the other hand the error message says \"Please report this as a GHC bug\"\r\n\r\n{{{\r\n\"inplace/bin/ghc-stage1\" -static -H32m -O -lffi -optl-pthread -optl-B/usr/bin/ld.gold -Wall -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -optc-DNOSMP -dcmm-lint -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 -Wcpp-undef -Wnoncanonical-monad-instances -c rts/StgStartup.cmm -o rts/dist/build/StgStartup.o\r\n\"inplace/bin/ghc-stage1\" -static -H32m -O -lffi -optl-pthread -optl-B/usr/bin/ld.gold -Wall -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -optc-DNOSMP -dcmm-lint -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 -Wcpp-undef -Wnoncanonical-monad-instances -c rts/PrimOps.cmm -o rts/dist/build/PrimOps.o\r\n\"inplace/bin/ghc-stage1\" -static -H32m -O -lffi -optl-pthread -optl-B/usr/bin/ld.gold -Wall -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -optc-DNOSMP -dcmm-lint -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 -Wcpp-undef -Wnoncanonical-monad-instances -c rts/Updates.cmm -o rts/dist/build/Updates.o\r\nghc-stage1: panic! (the 'impossible' happened)\r\n (GHC version 8.4.3 for arm-unknown-linux):\r\n\tFailed to lookup the datalayout for armv7l-unknown-linux-gnueabi; 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\",\"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\"]\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\nrts/ghc.mk:295: recipe for target 'rts/dist/build/StgStartup.o' failed\r\nmake[3]: *** [rts/dist/build/StgStartup.o] Error 1\r\nmake[3]: *** Waiting for unfinished jobs....\r\nghc-stage1: panic! (the 'impossible' happened)\r\n (GHC version 8.4.3 for arm-unknown-linux):\r\n\tFailed to lookup the datalayout for armv7l-unknown-linux-gnueabi; 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\",\"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\"]\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\nrts/ghc.mk:295: recipe for target 'rts/dist/build/Updates.o' failed\r\nmake[3]: *** [rts/dist/build/Updates.o] Error 1\r\nghc-stage1: panic! (the 'impossible' happened)\r\n (GHC version 8.4.3 for arm-unknown-linux):\r\n\tFailed to lookup the datalayout for armv7l-unknown-linux-gnueabi; 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\",\"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\"]\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\nrts/ghc.mk:295: recipe for target 'rts/dist/build/PrimOps.o' failed\r\n\r\n}}}\r\n\r\nhttps://buildd.debian.org/status/fetch.php?pkg=ghc&arch=armel&ver=8.4.3-1&stamp=1527769922&raw=0","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 Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/15293Set up staging branch2019-07-07T18:13:24ZBen GamariSet up staging branchGoal: Keep commits that would break CI out of `master`.
Approach: Introduce a staging branch where commits will first land to go through the full CI workup. When a commit passes on `staging`, merge it into `master`.
<details><summary>T...Goal: Keep commits that would break CI out of `master`.
Approach: Introduce a staging branch where commits will first land to go through the full CI workup. When a commit passes on `staging`, merge it into `master`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------------- |
| Version | 8.4.3 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | Continuous Integration |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Set up staging branch","status":"New","operating_system":"","component":"Continuous Integration","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"bgamari"},"version":"8.4.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"Goal: Keep commits that would break CI out of `master`.\r\n\r\nApproach: Introduce a staging branch where commits will first land to go through the full CI workup. When a commit passes on `staging`, merge it into `master`.","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1Ben GamariBen Gamarihttps://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/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/16398Missing documentation in Windows bindist tarball2019-09-12T22:55:30ZBen GamariMissing documentation in Windows bindist tarballTakenobu noticed the following omissions from the 8.6.4 bindist tarball:
> Perhaps you may know, but the following html documents are not included in
> the windows tarball \[1\]:
>
> - doc/html/index.html
> - doc/html/users_guide/index....Takenobu noticed the following omissions from the 8.6.4 bindist tarball:
> Perhaps you may know, but the following html documents are not included in
> the windows tarball \[1\]:
>
> - doc/html/index.html
> - doc/html/users_guide/index.html
> - doc/html/libraries/index.html
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 8.6.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | Documentation |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Missing documentation in Windows bindist tarball","status":"New","operating_system":"","component":"Documentation","related":[],"milestone":"8.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.6.4","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Takenobu noticed the following omissions from the 8.6.4 bindist tarball:\r\n\r\n> Perhaps you may know, but the following html documents are not included in\r\n> the windows tarball [1]:\r\n>\r\n> * doc/html/index.html\r\n> * doc/html/users_guide/index.html\r\n> * doc/html/libraries/index.html\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.8.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/16690Update 8.8 libraries2019-07-20T02:56:47ZOleg GrenrusUpdate 8.8 librariesIn current 8.8 tip 334dd6da47326f47ba3425376728feda6245c7c1, these libraries don't point to a release tag (or old release):
- `binary`: currently at 0.8.6.0 + commits
- `bytestring` 13 commits since 0.10.8.2
- `containers` 10 commits sin...In current 8.8 tip 334dd6da47326f47ba3425376728feda6245c7c1, these libraries don't point to a release tag (or old release):
- `binary`: currently at 0.8.6.0 + commits
- `bytestring` 13 commits since 0.10.8.2
- `containers` 10 commits since 0.6.0.1
- `deepseq` 1 commit since 1.4.4.0
- `directory` 1 commit since 1.3.3.2
- `haskeline` 1 commit since 0.7.5.0
- `parallel`4 commits since 3.2.2.0
- `parsec` 6 commits since 3.1.13.0
- `process` 5 commits since 1.6.5.0
- `stm` 4 commits since 2.5.0.0
- `terminfo` points to commit which looks like `0.4.1.4` but isn't the actual tagged commit. https://github.com/judah/terminfo/issues/34
- `text` 4 commits since 1.2.3.1
- `time` is at 1.9.2, but there is 1.9.3
- `unix` 5 commits since 2.7.2.2
- And as a bonus `Cabal`, which is partly tracked by https://gitlab.haskell.org/ghc/ghc/issues/16637
IMHO it would be clearer if each boot library had a PATCH release, so `git submodule foreach git describe --always` would tell which versions are there. Currently some of the packages have some not-essential `.travis.yml` churn; some have a little of metadata change (e.g. relaxed base, time etc bounds), or actual unreleased changes (e.g. binary and text at least).
---
From https://gitlab.haskell.org/ghc/ghc/issues/16602
> In general, actionable things like bumping Cabal should have a ticket otherwise they are destined to fall through the cracks. It looks like in this case I failed to open one and no one else did so either.8.8.1Ben GamariHerbert Valerio Riedelhvr@gnu.orgBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/16751Cabal-3.0.0.0 breaks cabal012019-06-07T14:33:21ZBen GamariCabal-3.0.0.0 breaks cabal01When bumping cabal for %8.8.1 I found that the `cabal01` testcase broke. Tracked upstream as https://github.com/haskell/cabal/issues/6068.When bumping cabal for %8.8.1 I found that the `cabal01` testcase broke. Tracked upstream as https://github.com/haskell/cabal/issues/6068.8.8.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/16784PLT is mapped in too far from code2019-06-12T12:48:01ZBen GamariPLT is mapped in too far from codeThe procedure linkage table (PLT) is mapped too far from code on AArch64. This is the cause of #16776.
It should be using similar logic to that which is used on x86-64, where we take particular care to feed `mmap` an unmapped hint addre...The procedure linkage table (PLT) is mapped too far from code on AArch64. This is the cause of #16776.
It should be using similar logic to that which is used on x86-64, where we take particular care to feed `mmap` an unmapped hint address in the lower 2GB of address space.8.8.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/16825[hadrian] stack dependencies build broken2019-08-10T10:43:49ZShayne Fletchershayne@shaynefletcher.org[hadrian] stack dependencies build brokenCommit `381c3ae31b68019177f1cd20cb4da2f9d3b7d6c6` "bump Cabal submodule" breaks the stack/hadrian build.
Steps to reproduce:
```bash
git clone https://gitlab.haskell.org/ghc/ghc.git
cd ghc
git submodule update --init --recursive
stack bu...Commit `381c3ae31b68019177f1cd20cb4da2f9d3b7d6c6` "bump Cabal submodule" breaks the stack/hadrian build.
Steps to reproduce:
```bash
git clone https://gitlab.haskell.org/ghc/ghc.git
cd ghc
git submodule update --init --recursive
stack build --stack-yaml=hadrian/stack.yaml --only-dependencies
```
The error produced reads:
```
Setup.lhs:48:22: error:
Variable not in scope:
rawSystemProgramConf
:: Distribution.Verbosity.Verbosity -> t -> ProgramDb -> t1
|
48 | let runProgram p = rawSystemProgramConf (fromFlagOrDefault normal (buildVerbosity flags))
| ^^^^^^^^^^^^^^^^^^^^
```8.8.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/16842References to unloaded CAFs due to stale static flag field2019-06-26T17:46:37ZBen GamariReferences to unloaded CAFs due to stale static flag fieldThis issues is the first item described by @lolotp here: https://gitlab.haskell.org/ghc/ghc/issues/16525#note_192087:
> There are still references to CAFs in the unloaded object code, but these CAFs were put on the revertible caf list (...This issues is the first item described by @lolotp here: https://gitlab.haskell.org/ghc/ghc/issues/16525#note_192087:
> There are still references to CAFs in the unloaded object code, but these CAFs were put on the revertible caf list (which set the static link field to 3) and thus were ignored by GC. Because of that, during the next GC, checkUnload determined that these ObjectCode struct can be freed despite the references into those ObjectCodes still existing. Next GC cycle would trigger crash while GC is trying to evacuate the mentioned CAFs.8.8.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/16968Packaging error: GHC 8.8.1-rc1 doesn't contain any source code2019-08-10T10:37:08Zofrytim4job@bmail.ruPackaging error: GHC 8.8.1-rc1 doesn't contain any source code## Summary
GHC 8.8.1-rc1 doesn't contain any source code
## Steps to reproduce
https://downloads.haskell.org/ghc/8.8.1-rc1/ghc-8.8.0.20190721-src.tar.xz doesn't contain any source.
## Expected behavior
There should be source code.
...## Summary
GHC 8.8.1-rc1 doesn't contain any source code
## Steps to reproduce
https://downloads.haskell.org/ghc/8.8.1-rc1/ghc-8.8.0.20190721-src.tar.xz doesn't contain any source.
## Expected behavior
There should be source code.
## Environment
* GHC version used: 8.8.1-rc1
Optional:
* Operating System:
* System Architecture:8.8.1Ben GamariBen Gamari