GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T18:45:37Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/8307iOS patch: fix hangs in threaded runtime2019-07-07T18:45:37ZlukexiiOS patch: fix hangs in threaded runtimeExtends two darwin_HOST_OS cases in libraries/base/GHC/Event/Manager.hs to cover iOS as well. This fixes hangs occurring on iOS with the threaded runtime.
<details><summary>Trac metadata</summary>
| Trac field | Value ...Extends two darwin_HOST_OS cases in libraries/base/GHC/Event/Manager.hs to cover iOS as well. This fixes hangs occurring on iOS with the threaded runtime.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | thoughtpolice |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"iOS patch: fix hangs in threaded runtime","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"7.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["thoughtpolice"],"type":"Bug","description":"Extends two darwin_HOST_OS cases in libraries/base/GHC/Event/Manager.hs to cover iOS as well. This fixes hangs occurring on iOS with the threaded runtime.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/8305ghci macros override built-ins for command expansion2019-10-23T09:59:13Zrwbartonghci macros override built-ins for command expansionI have a ghci macro `:tsu` from the ghc-vis package, which I installed a long time ago. In HEAD ghci (since the patch for #8113) this causes `:t` to expand to `:tsu`, rather than `:type`. That happened to result in a weird error the firs...I have a ghci macro `:tsu` from the ghc-vis package, which I installed a long time ago. In HEAD ghci (since the patch for #8113) this causes `:t` to expand to `:tsu`, rather than `:type`. That happened to result in a weird error the first time I tried to use `:t` (something like `Prelude.read: no parse`), and it took me a while to diagnose that my `.ghci` file was the issue!
I don't like this new behavior because it forces me to either change my ghci habits (start using `:type` instead of `:t`) or avoid macros starting with any letter that I currently use as a single-letter ghci command. I set this ticket priority to highest because in any event this new behavior shouldn't sneak in to a GHC release unnoticed.
Below is my proposal for how `:commands` should be interpreted now that built-in commands can be overridden (#8113), copied from a comment I made recently on that ticket.
----
I suppose what I specifically want to happen when I enter a `:command` is an algorithm like this.
If the name I entered is an exact match for a macro or built-in, use that name.
Otherwise, try to complete the name to the name of a *built-in* in the traditional way. If this succeeds, use the resulting name.
Otherwise, try to complete the name to the name of a macro, and use the resulting name if that succeeds, otherwise give up.
In all cases where we got a name, use the *macro* of that name if there is one, and otherwise use the built-in. (Obviously, for `::command`, ignore macros entirely.)
In other words, built-ins should take precedence over macros for the purpose of name *completion*, but macros should take precedence over built-ins for the purpose of name *lookup*. This is backwards-compatible from the perspective of the user who is not aware of the change—`:t` will always mean `:type`, as long as the user has no macro named `:t`, just like in previous versions of ghci—while still allowing the aware user to redefine exactly what `:type` means. And it's flexible enough in that if the user really wants `:t` to complete to some other macro `:test` that they've written, they can always define another macro `:t` to expand to `:test`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.6.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | #8113 |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ghci macros override built-ins for command expansion","status":"New","operating_system":"","component":"GHCi","related":[8113],"milestone":"7.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I have a ghci macro `:tsu` from the ghc-vis package, which I installed a long time ago. In HEAD ghci (since the patch for #8113) this causes `:t` to expand to `:tsu`, rather than `:type`. That happened to result in a weird error the first time I tried to use `:t` (something like `Prelude.read: no parse`), and it took me a while to diagnose that my `.ghci` file was the issue!\r\n\r\nI don't like this new behavior because it forces me to either change my ghci habits (start using `:type` instead of `:t`) or avoid macros starting with any letter that I currently use as a single-letter ghci command. I set this ticket priority to highest because in any event this new behavior shouldn't sneak in to a GHC release unnoticed.\r\n\r\nBelow is my proposal for how `:commands` should be interpreted now that built-in commands can be overridden (#8113), copied from a comment I made recently on that ticket.\r\n\r\n----\r\n\r\nI suppose what I specifically want to happen when I enter a `:command` is an algorithm like this.\r\n\r\nIf the name I entered is an exact match for a macro or built-in, use that name.\r\n\r\nOtherwise, try to complete the name to the name of a ''built-in'' in the traditional way. If this succeeds, use the resulting name.\r\n\r\nOtherwise, try to complete the name to the name of a macro, and use the resulting name if that succeeds, otherwise give up.\r\n\r\nIn all cases where we got a name, use the ''macro'' of that name if there is one, and otherwise use the built-in. (Obviously, for `::command`, ignore macros entirely.)\r\n\r\nIn other words, built-ins should take precedence over macros for the purpose of name ''completion'', but macros should take precedence over built-ins for the purpose of name ''lookup''. This is backwards-compatible from the perspective of the user who is not aware of the change—`:t` will always mean `:type`, as long as the user has no macro named `:t`, just like in previous versions of ghci—while still allowing the aware user to redefine exactly what `:type` means. And it's flexible enough in that if the user really wants `:t` to complete to some other macro `:test` that they've written, they can always define another macro `:t` to expand to `:test`.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1rwbartonrwbartonhttps://gitlab.haskell.org/ghc/ghc/-/issues/8302Add 'bool' to Data.Bool2019-07-07T18:45:39ZOllie CharlesAdd 'bool' to Data.BoolAs mentioned in http://www.haskell.org/pipermail/libraries/2013-September/020492.html I propose we add the 'bool' function to 'Data.Bool'.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| --------...As mentioned in http://www.haskell.org/pipermail/libraries/2013-September/020492.html I propose we add the 'bool' function to 'Data.Bool'.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.6.3 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Add 'bool' to Data.Bool","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"7.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"As mentioned in http://www.haskell.org/pipermail/libraries/2013-September/020492.html I propose we add the 'bool' function to 'Data.Bool'.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/8301error BaseReg must be in a register for THREADED_RTS2019-07-07T18:45:39Zerikderror BaseReg must be in a register for THREADED_RTSCompiling git HEAD on powerpc64-linux. This was working as recently as two weeks ago. Now getting:
```
"inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static
-H32m -O -Werror -Wall -H64m -O0 -package-name ghc-7.7.20130914
...Compiling git HEAD on powerpc64-linux. This was working as recently as two weeks ago. Now getting:
```
"inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static
-H32m -O -Werror -Wall -H64m -O0 -package-name ghc-7.7.20130914
-hide-all-packages -i -icompiler/basicTypes -icompiler/cmm
-icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar
-icompiler/ghci -icompiler/hsSyn -icompiler/iface -icompiler/llvmGen
-icompiler/main -icompiler/nativeGen -icompiler/parser -icompiler/prelude
-icompiler/profiling -icompiler/rename -icompiler/simplCore
-icompiler/simplStg -icompiler/specialise -icompiler/stgSyn
-icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils
-icompiler/vectorise -icompiler/stage2/build -icompiler/stage2/build/autogen
-Icompiler/stage2/build -Icompiler/stage2/build/autogen -Icompiler/.
-Icompiler/parser -Icompiler/utils -Icompiler/stage2 -optP-include
-optPcompiler/stage2/build/autogen/cabal_macros.h -package Cabal-1.18.1
-package array-0.4.0.2 -package base-4.7.0.0
-package bin-package-db-0.0.0.0 -package bytestring-0.10.3.0
-package containers-0.5.3.1 -package directory-1.2.0.1
-package filepath-1.3.0.2 -package hoopl-3.10.0.0 -package hpc-0.6.0.1
-package process-1.2.0.0 -package time-1.4.1 -package transformers-0.3.0.0
-package unix-2.7.0.0 -Wall -fno-warn-name-shadowing -XHaskell98 -XCPP
-XMagicHash -XUnboxedTuples -XPatternGuards -XForeignFunctionInterface
-XEmptyDataDecls -XTypeSynonymInstances -XMultiParamTypeClasses
-XFlexibleInstances -XRankNTypes -XScopedTypeVariables
-XDeriveDataTypeable -XBangPatterns -XNondecreasingIndentation -DNO_REGS
-optc-DTHREADED_RTS -DSTAGE=2 -O2 -fwarn-tabs -fno-warn-amp -O
-dcore-lint -no-user-package-db -rtsopts -odir compiler/stage2/build
-hidir compiler/stage2/build -stubdir compiler/stage2/build
-c compiler/utils/Platform.hs -o compiler/stage2/build/Platform.o
In file included from /home/erikd/PPC64/ghc-ppc64/includes/Stg.h:232:0:
0,
from /tmp/ghc10950_0/ghc10950_2.hc:3:
/home/erikd/PPC64/ghc-ppc64/includes/stg/Regs.h:359:2:
error: #error BaseReg must be in a register for THREADED_RTS
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | powerpc64 |
</details>
<!-- {"blocked_by":[],"summary":"error BaseReg must be in a register for THREADED_RTS","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.7","keywords":[],"differentials":[],"test_case":"","architecture":"powerpc64","cc":[""],"type":"Bug","description":"Compiling git HEAD on powerpc64-linux. This was working as recently as two weeks ago. Now getting:\r\n\r\n{{{\r\n\"inplace/bin/ghc-stage1\" -hisuf hi -osuf o -hcsuf hc -static \r\n -H32m -O -Werror -Wall -H64m -O0 -package-name ghc-7.7.20130914\r\n -hide-all-packages -i -icompiler/basicTypes -icompiler/cmm\r\n -icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar\r\n -icompiler/ghci -icompiler/hsSyn -icompiler/iface -icompiler/llvmGen\r\n -icompiler/main -icompiler/nativeGen -icompiler/parser -icompiler/prelude\r\n -icompiler/profiling -icompiler/rename -icompiler/simplCore\r\n -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn\r\n -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils\r\n -icompiler/vectorise -icompiler/stage2/build -icompiler/stage2/build/autogen\r\n -Icompiler/stage2/build -Icompiler/stage2/build/autogen -Icompiler/.\r\n -Icompiler/parser -Icompiler/utils -Icompiler/stage2 -optP-include\r\n -optPcompiler/stage2/build/autogen/cabal_macros.h -package Cabal-1.18.1\r\n -package array-0.4.0.2 -package base-4.7.0.0\r\n -package bin-package-db-0.0.0.0 -package bytestring-0.10.3.0\r\n -package containers-0.5.3.1 -package directory-1.2.0.1\r\n -package filepath-1.3.0.2 -package hoopl-3.10.0.0 -package hpc-0.6.0.1\r\n -package process-1.2.0.0 -package time-1.4.1 -package transformers-0.3.0.0\r\n -package unix-2.7.0.0 -Wall -fno-warn-name-shadowing -XHaskell98 -XCPP\r\n -XMagicHash -XUnboxedTuples -XPatternGuards -XForeignFunctionInterface\r\n -XEmptyDataDecls -XTypeSynonymInstances -XMultiParamTypeClasses\r\n -XFlexibleInstances -XRankNTypes -XScopedTypeVariables\r\n -XDeriveDataTypeable -XBangPatterns -XNondecreasingIndentation -DNO_REGS\r\n -optc-DTHREADED_RTS -DSTAGE=2 -O2 -fwarn-tabs -fno-warn-amp -O\r\n -dcore-lint -no-user-package-db -rtsopts -odir compiler/stage2/build\r\n -hidir compiler/stage2/build -stubdir compiler/stage2/build\r\n -c compiler/utils/Platform.hs -o compiler/stage2/build/Platform.o\r\n\r\nIn file included from /home/erikd/PPC64/ghc-ppc64/includes/Stg.h:232:0:\r\n 0,\r\n from /tmp/ghc10950_0/ghc10950_2.hc:3:\r\n\r\n/home/erikd/PPC64/ghc-ppc64/includes/stg/Regs.h:359:2:\r\n error: #error BaseReg must be in a register for THREADED_RTS\r\n\r\n}}}\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/8291unloadObj doesn't work, unloaded_objects list keeps growing in size2019-07-07T18:45:42ZEdward Z. YangunloadObj doesn't work, unloaded_objects list keeps growing in sizeShows up as the linker_unload test going very slowly and triggering the timeout on my box. Verified by looking at the unloaded_objects list, which contains multiple copies of Test.o. I haven't investigated any further.
<details><summary...Shows up as the linker_unload test going very slowly and triggering the timeout on my box. Verified by looking at the unloaded_objects list, which contains multiple copies of Test.o. I haven't investigated any further.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | MacOS X |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"unloadObj doesn't work on Mac OS X","status":"New","operating_system":"MacOS X","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"simonmar"},"version":"7.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Shows up as the linker_unload test going very slowly and triggering the timeout on my box. Verified by looking at the unloaded_objects list, which contains multiple copies of Test.o. I haven't investigated any further.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/8280Deriving Show for Word#2019-07-07T18:45:44ZKrzysztof GogolewskiDeriving Show for Word#```
{-# LANGUAGE MagicHash #-}
import GHC.Prim
data A = A Word# deriving Show
```
This works in 7.6.3, but 7.7 gives
```
Can't find interface-file declaration for data constructor GHC.Types.W#
Probable cause: bug in .hi-boot ...```
{-# LANGUAGE MagicHash #-}
import GHC.Prim
data A = A Word# deriving Show
```
This works in 7.6.3, but 7.7 gives
```
Can't find interface-file declaration for data constructor GHC.Types.W#
Probable cause: bug in .hi-boot file, or inconsistent .hi file
Use -ddump-if-trace to get an idea of which file caused the error
```
The same file works if Word\# is replaced by Int\#.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.6.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":"Deriving Show for Word#","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\n{-# LANGUAGE MagicHash #-}\r\nimport GHC.Prim\r\ndata A = A Word# deriving Show\r\n}}}\r\n\r\nThis works in 7.6.3, but 7.7 gives\r\n\r\n{{{\r\n Can't find interface-file declaration for data constructor GHC.Types.W#\r\n Probable cause: bug in .hi-boot file, or inconsistent .hi file\r\n Use -ddump-if-trace to get an idea of which file caused the error\r\n}}}\r\n\r\nThe same file works if Word# is replaced by Int#.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/8275Loopification breaks profiling2019-07-07T18:45:46ZJan Stolarekjan.stolarek@ed.ac.ukLoopification breaks profilingProfiling is currently broken in HEAD. Setting `BuildFlavour = prof` in `build.mk` leads to a segfault during build. After reverting d61c3ac186c94021c851f7a2a6d20631e35fc1ba (loopification performed in the code generator) everything buil...Profiling is currently broken in HEAD. Setting `BuildFlavour = prof` in `build.mk` leads to a segfault during build. After reverting d61c3ac186c94021c851f7a2a6d20631e35fc1ba (loopification performed in the code generator) everything builds without problems.
I am going to lower the priority since loopification is now no longer by default, and it looks like loopification by default will not make it to GHC 7.8.7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/8266Dynamic linking on Mac2019-07-07T18:45:48Zkazu-yamamotoDynamic linking on MacMany dynamic libraries refer to the build tree.
(1) Every ".dylib" installed with GHC head refers to itself in its build directory. E.g.
```
% otool -L libHSbase-4.7.0.0-ghc7.7.20130909.dylib | grep base
libHSbase-4.7.0.0-ghc7.7.201309...Many dynamic libraries refer to the build tree.
(1) Every ".dylib" installed with GHC head refers to itself in its build directory. E.g.
```
% otool -L libHSbase-4.7.0.0-ghc7.7.20130909.dylib | grep base
libHSbase-4.7.0.0-ghc7.7.20130909.dylib:
/Users/kazu/work/ghc/libraries/base/dist-install/build/libHSbase-4.7.0.0-ghc7.7.20130909.dylib (compatibility version 0.0.0, current version 0.0.0)
```
(2) Some ".dylib" installed with GHC head refers to other libraries in their build directories. E.g.
```
% otool -L libHSvector-0.9.1-ghc7.7.20130909.dylib | grep /Users
/Users/kazu/work/ghc/libraries/vector/dist-install/build/libHSvector-0.9.1-ghc7.7.20130909.dylib (compatibility version 0.0.0, current version 0.0.0)
/Users/kazu/work/ghc/libraries/primitive/dist-install/build/libHSprimitive-0.4.0.1-ghc7.7.20130909.dylib (compatibility version 0.0.0, current version 0.0.0)
```
(3) All user installed libraries by cabal-install refer to other libraries in their build directories. E.g.
```
% otool -L libHSghc-paths-0.1.0.9-ghc7.7.20130909.dylib| grep Users
/Users/kazu/Library/Haskell/ghc-7.7.20130909/lib/ghc-paths-0.1.0.9/lib/libHSghc-paths-0.1.0.9-ghc7.7.20130909.dylib (compatibility version 0.0.0, current version 0.0.0)
/Users/kazu/work/ghc/libraries/base/dist-install/build/libHSbase-4.7.0.0-ghc7.7.20130909.dylib (compatibility version 0.0.0, current version 0.0.0)
/Users/kazu/work/ghc/libraries/integer-gmp/dist-install/build/libHSinteger-gmp-0.5.1.0-ghc7.7.20130909.dylib (compatibility version 0.0.0, current version 0.0.0)
/Users/kazu/work/ghc/libraries/ghc-prim/dist-install/build/libHSghc-prim-0.3.1.0-ghc7.7.20130909.dylib (compatibility version 0.0.0, current version 0.0.0)
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Dynamic linking on Mac","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Many dynamic libraries refer to the build tree.\r\n\r\n(1) Every \".dylib\" installed with GHC head refers to itself in its build directory. E.g.\r\n\r\n{{{\r\n% otool -L libHSbase-4.7.0.0-ghc7.7.20130909.dylib | grep base\r\nlibHSbase-4.7.0.0-ghc7.7.20130909.dylib:\r\n\t/Users/kazu/work/ghc/libraries/base/dist-install/build/libHSbase-4.7.0.0-ghc7.7.20130909.dylib (compatibility version 0.0.0, current version 0.0.0)\r\n}}}\r\n\r\n(2) Some \".dylib\" installed with GHC head refers to other libraries in their build directories. E.g.\r\n\r\n{{{\r\n% otool -L libHSvector-0.9.1-ghc7.7.20130909.dylib | grep /Users\r\n\t/Users/kazu/work/ghc/libraries/vector/dist-install/build/libHSvector-0.9.1-ghc7.7.20130909.dylib (compatibility version 0.0.0, current version 0.0.0)\r\n\t/Users/kazu/work/ghc/libraries/primitive/dist-install/build/libHSprimitive-0.4.0.1-ghc7.7.20130909.dylib (compatibility version 0.0.0, current version 0.0.0)\r\n}}}\r\n\r\n(3) All user installed libraries by cabal-install refer to other libraries in their build directories. E.g.\r\n\r\n{{{\r\n% otool -L libHSghc-paths-0.1.0.9-ghc7.7.20130909.dylib| grep Users\r\n\t/Users/kazu/Library/Haskell/ghc-7.7.20130909/lib/ghc-paths-0.1.0.9/lib/libHSghc-paths-0.1.0.9-ghc7.7.20130909.dylib (compatibility version 0.0.0, current version 0.0.0)\r\n\t/Users/kazu/work/ghc/libraries/base/dist-install/build/libHSbase-4.7.0.0-ghc7.7.20130909.dylib (compatibility version 0.0.0, current version 0.0.0)\r\n\t/Users/kazu/work/ghc/libraries/integer-gmp/dist-install/build/libHSinteger-gmp-0.5.1.0-ghc7.7.20130909.dylib (compatibility version 0.0.0, current version 0.0.0)\r\n\t/Users/kazu/work/ghc/libraries/ghc-prim/dist-install/build/libHSghc-prim-0.3.1.0-ghc7.7.20130909.dylib (compatibility version 0.0.0, current version 0.0.0)\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/8257System.Mem: Expose performMinorGC2019-07-07T18:45:51ZNiklas Hambüchenmail@nh2.meSystem.Mem: Expose performMinorGCWe already have
```
performGC
```
which triggers a major garbage collection.
In many cases, it is useful to trigger a minor one; exposing it is as simple as Simon Marlow suggested in https://groups.google.com/d/msg/fa.haskell/-q6sINVa...We already have
```
performGC
```
which triggers a major garbage collection.
In many cases, it is useful to trigger a minor one; exposing it is as simple as Simon Marlow suggested in https://groups.google.com/d/msg/fa.haskell/-q6sINValu8/_Z7odE6O5PsJ.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.6.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | mail@nh2.me |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"System.Mem: Expose performMinorGC","status":"New","operating_system":"","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["mail@nh2.me"],"type":"Bug","description":"We already have\r\n\r\n{{{\r\nperformGC\r\n}}}\r\n\r\nwhich triggers a major garbage collection.\r\n\r\nIn many cases, it is useful to trigger a minor one; exposing it is as simple as Simon Marlow suggested in https://groups.google.com/d/msg/fa.haskell/-q6sINValu8/_Z7odE6O5PsJ.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/8256adding locality levels to prefetch# and friends2021-12-23T22:37:26ZCarter Schonwaldadding locality levels to prefetch# and friendscurrently in HEAD / 7.7, the prefetch primop only does the equivalent of __builtin_prefetch(ptr,0,3)
(0 here denoting a read prefetch, 3 denoting "high locality, keep this in cache for a while")
On modern hardware, we can do better! For...currently in HEAD / 7.7, the prefetch primop only does the equivalent of __builtin_prefetch(ptr,0,3)
(0 here denoting a read prefetch, 3 denoting "high locality, keep this in cache for a while")
On modern hardware, we can do better! For many natural use case of prefetch in haskell, we have a streaming workload, so we want a prefetch to also hint that "once we've worked on a piece of memory, no need to keep it around for any period of time, don't pollute our memory with it"
the attached patch takes each prefetchBlah\# operation (where blah=ByteArray,MutableByteArray, or Addr) and replaces it with prefetchBlah0\# through prefetchBlah3\#, and passes the integer information through into the code generators.
To make the engineering reasonable, I enriched MO_Prefetch_Data with an Int parameter (which must be a value between ranging 0-3). Theres probably a better way to model the locality paramter, but that maps directly to how its used in llvm code gen.
This patch does not include a test case yet. (interestingly, currently the test suite doesn't have any tests for the prefetch primops as yet!). So that needs to be added.
Also, theres no good reason for the prefetch ops to be LLVM only.
worst case we could just treat them as noop's and drop them. But at least for x86, should be easy to add the support (though if anyone wants to add support for the ppc and sparc stuff, or help me do that, that'd be awesome too!) . I"ll look into doing that in a few days.
theres probably some other things i'm overlooking.
anyways, i'll attach a preliminary patch for feedback now
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.7 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"adding locality levels to prefetch# and friends","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"7.8.1","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"carter"},"version":"7.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"currently in HEAD / 7.7, the prefetch primop only does the equivalent of __builtin_prefetch(ptr,0,3)\r\n(0 here denoting a read prefetch, 3 denoting \"high locality, keep this in cache for a while\")\r\n\r\nOn modern hardware, we can do better! For many natural use case of prefetch in haskell, we have a streaming workload, so we want a prefetch to also hint that \"once we've worked on a piece of memory, no need to keep it around for any period of time, don't pollute our memory with it\"\r\n\r\nthe attached patch takes each prefetchBlah# operation (where blah=ByteArray,MutableByteArray, or Addr) and replaces it with prefetchBlah0# through prefetchBlah3#, and passes the integer information through into the code generators. \r\n\r\nTo make the engineering reasonable, I enriched MO_Prefetch_Data with an Int parameter (which must be a value between ranging 0-3). Theres probably a better way to model the locality paramter, but that maps directly to how its used in llvm code gen.\r\n\r\nThis patch does not include a test case yet. (interestingly, currently the test suite doesn't have any tests for the prefetch primops as yet!). So that needs to be added.\r\n\r\nAlso, theres no good reason for the prefetch ops to be LLVM only. \r\n\r\nworst case we could just treat them as noop's and drop them. But at least for x86, should be easy to add the support (though if anyone wants to add support for the ppc and sparc stuff, or help me do that, that'd be awesome too!) . I\"ll look into doing that in a few days.\r\n\r\ntheres probably some other things i'm overlooking.\r\n\r\nanyways, i'll attach a preliminary patch for feedback now","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/8254confusing comment on allocate()2019-07-07T18:45:52Zrwbartonconfusing comment on allocate()```
/* -----------------------------------------------------------------------------
allocate()
This allocates memory in the current thread - it is intended for
use primarily from STG-land where we have a Capability. It is
...```
/* -----------------------------------------------------------------------------
allocate()
This allocates memory in the current thread - it is intended for
use primarily from STG-land where we have a Capability. It is
better than allocate() because it doesn't require taking the
sm_mutex lock in the common case.
Memory is allocated directly from the nursery if possible (but not
from the current nursery block, so as not to interfere with
Hp/HpLim).
-------------------------------------------------------------------------- */
```
Not sure what, if anything, `allocate()` is better than, but it's not `allocate()`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"confusing comment on allocate()","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\n/* -----------------------------------------------------------------------------\r\n allocate()\r\n\r\n This allocates memory in the current thread - it is intended for\r\n use primarily from STG-land where we have a Capability. It is\r\n better than allocate() because it doesn't require taking the\r\n sm_mutex lock in the common case.\r\n\r\n Memory is allocated directly from the nursery if possible (but not\r\n from the current nursery block, so as not to interfere with\r\n Hp/HpLim).\r\n -------------------------------------------------------------------------- */\r\n}}}\r\n\r\nNot sure what, if anything, `allocate()` is better than, but it's not `allocate()`.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/8247Dependency tracking (--make) broken for re-exported modules2019-07-07T18:45:53ZGabor GreifDependency tracking (--make) broken for re-exported modulesSay, I re-export a module, from which I hide some bindings:
```
module B (module A) where
import A hiding (a1)
```
where `A` is defined thus:
```
module A where
a1 = 5
a2 = 42
a3 = 113
```
I use `B` from `C`:
```
module C where
impo...Say, I re-export a module, from which I hide some bindings:
```
module B (module A) where
import A hiding (a1)
```
where `A` is defined thus:
```
module A where
a1 = 5
a2 = 42
a3 = 113
```
I use `B` from `C`:
```
module C where
import B
a2 = 142
```
Build `C`, with `ghc --make C.hs`, observing redefinition error (of `a2`).
Now hide also `a2` in `B` like this (by editing `B.hs`):
```
module B (module A) where
import A hiding (a1, a2)
```
Build `C` again, and observe that the error persists, because `B` has not been rebuilt, and its interface file not regenerated.
Deleting `B.hi` and recompiling resolves the situation.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.7 |
| 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":"Dependency tracking (--make) broken for re-exported modules","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Say, I re-export a module, from which I hide some bindings:\r\n{{{\r\nmodule B (module A) where\r\nimport A hiding (a1)\r\n}}}\r\nwhere `A` is defined thus:\r\n{{{\r\nmodule A where\r\na1 = 5\r\na2 = 42\r\na3 = 113\r\n}}}\r\n\r\nI use `B` from `C`:\r\n{{{\r\nmodule C where\r\nimport B\r\na2 = 142\r\n}}}\r\n\r\nBuild `C`, with `ghc --make C.hs`, observing redefinition error (of `a2`).\r\n\r\nNow hide also `a2` in `B` like this (by editing `B.hs`):\r\n{{{\r\nmodule B (module A) where\r\nimport A hiding (a1, a2)\r\n}}}\r\n\r\nBuild `C` again, and observe that the error persists, because `B` has not been rebuilt, and its interface file not regenerated.\r\n\r\nDeleting `B.hi` and recompiling resolves the situation.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/8245ghc-pkg list --simple-output prints packages in non-alphabetical order2019-07-07T18:45:54ZNiklas Hambüchenmail@nh2.meghc-pkg list --simple-output prints packages in non-alphabetical orderInstead, it prints the ones with the smallest version first.
That does not make much sense.
I will attach a patch.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------...Instead, it prints the ones with the smallest version first.
That does not make much sense.
I will attach a patch.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.6.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-pkg list prints packages in non-alphabetical order","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.6.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Instead, it prints the ones with the smallest version first.\r\n\r\nThat does not make much sense.\r\n\r\nI will attach a patch.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/8237checkProddableBlock: invalid fixup in runtime linker (Windows)2019-07-07T18:45:56ZEdward Z. YangcheckProddableBlock: invalid fixup in runtime linker (Windows)I attempted to load a very simple C file into GHC using the linker and got this error. The C file is:
```
#include <stdio.h>
static void f(void); // __attribute__((constructor));
static void f(void)
{
printf("Hooray!");
}
```
...I attempted to load a very simple C file into GHC using the linker and got this error. The C file is:
```
#include <stdio.h>
static void f(void); // __attribute__((constructor));
static void f(void)
{
printf("Hooray!");
}
```
and the test program:
```
{-# LANGUAGE ForeignFunctionInterface #-}
import Foreign.C.String
main = do
initLinker
withCWString "test.o" $ \s -> loadObj s
resolveObjs
foreign import ccall "initLinker" initLinker :: IO ()
foreign import ccall "loadObj" loadObj :: CWString -> IO Int
foreign import ccall "resolveObjs" resolveObjs :: IO ()
```
Test is run as:
```
bash.exe-3.1$ gcc -c test.c
bash.exe-3.1$ ../ghc-init/inplace/bin/ghc-stage2 --make foo.hs -debug -fforce-recomp
[1 of 1] Compiling Main ( foo.hs, foo.o )
Linking foo.exe ...
bash.exe-3.1$ ./foo
foo.exe: Unknown PEi386 section name `.eh_frame' (while processing: test.o)
foo.exe: internal error: checkProddableBlock: invalid fixup in runtime linker: 002c0154
(GHC version 7.7.20130905 for i386_unknown_mingw32)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
```
More useful info:
```
bash.exe-3.1$ objdump -s -j .text test.o
test.o: file format pe-i386
Contents of section .text:
0000 5589e583 ec18c704 24000000 00e80000 U.......$.......
0010 0000c9c3 ....
bash.exe-3.1$ objdump -r -j .text test.o
test.o: file format pe-i386
RELOCATION RECORDS FOR [.text]:
OFFSET TYPE VALUE
00000009 dir32 .rdata
0000000e DISP32 _printf
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"checkProddableBlock: invalid fixup in runtime linker (Windows)","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"7.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I attempted to load a very simple C file into GHC using the linker and got this error. The C file is:\r\n\r\n{{{\r\n#include <stdio.h> \r\nstatic void f(void); // __attribute__((constructor));\r\nstatic void f(void) \r\n{\r\n printf(\"Hooray!\");\r\n}\r\n}}}\r\n\r\nand the test program:\r\n\r\n{{{\r\n{-# LANGUAGE ForeignFunctionInterface #-}\r\nimport Foreign.C.String\r\n\r\nmain = do\r\n initLinker\r\n withCWString \"test.o\" $ \\s -> loadObj s\r\n resolveObjs\r\n\r\nforeign import ccall \"initLinker\" initLinker :: IO ()\r\nforeign import ccall \"loadObj\" loadObj :: CWString -> IO Int\r\nforeign import ccall \"resolveObjs\" resolveObjs :: IO ()\r\n}}}\r\n\r\nTest is run as:\r\n\r\n{{{\r\nbash.exe-3.1$ gcc -c test.c \r\nbash.exe-3.1$ ../ghc-init/inplace/bin/ghc-stage2 --make foo.hs -debug -fforce-recomp \r\n[1 of 1] Compiling Main ( foo.hs, foo.o ) \r\nLinking foo.exe ... \r\nbash.exe-3.1$ ./foo \r\nfoo.exe: Unknown PEi386 section name `.eh_frame' (while processing: test.o) \r\nfoo.exe: internal error: checkProddableBlock: invalid fixup in runtime linker: 002c0154 \r\n (GHC version 7.7.20130905 for i386_unknown_mingw32) \r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug \r\n \r\nThis application has requested the Runtime to terminate it in an unusual way. \r\nPlease contact the application's support team for more information. \r\n}}}\r\n\r\nMore useful info:\r\n\r\n{{{\r\nbash.exe-3.1$ objdump -s -j .text test.o \r\n \r\ntest.o: file format pe-i386 \r\n \r\nContents of section .text: \r\n 0000 5589e583 ec18c704 24000000 00e80000 U.......$....... \r\n 0010 0000c9c3 ....\r\n\r\nbash.exe-3.1$ objdump -r -j .text test.o \r\n \r\ntest.o: file format pe-i386 \r\n \r\nRELOCATION RECORDS FOR [.text]: \r\nOFFSET TYPE VALUE \r\n00000009 dir32 .rdata \r\n0000000e DISP32 _printf \r\n \r\n\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/8236Assertion failure of MarkWeak2019-07-07T18:45:56Zkazu-yamamotoAssertion failure of MarkWeakRunning a web server compiled with GHC head specifying "-debug" got the following error:
```
mighty-20130905: internal error: ASSERTION FAILED: file rts/sm/MarkWeak.c, line 371
(GHC version 7.7.20130901 for i386_unknown_linux)
...Running a web server compiled with GHC head specifying "-debug" got the following error:
```
mighty-20130905: internal error: ASSERTION FAILED: file rts/sm/MarkWeak.c, line 371
(GHC version 7.7.20130901 for i386_unknown_linux)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
Here is Akio's guess:
I wonder if this issue could have been introduced by the commit:
https://github.com/ghc/ghc/commit/6770663f764db76dbb7138ccb3aea0527d194151
It looks like after the commit, addCFinalizerToWeak\# can call into the GC
with the closure lock held. This means the info pointer points to
stg_WHITEHOLE_info, breaking the asserted invariant. I haven't done any
testing to confirm this, however.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------------------------- |
| Version | 7.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | AndreasVoellmy, akio, simonmar, tibbe |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Assertion failure of MarkWeak","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"7.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["AndreasVoellmy","akio","simonmar","tibbe"],"type":"Bug","description":"Running a web server compiled with GHC head specifying \"-debug\" got the following error:\r\n\r\n{{{\r\nmighty-20130905: internal error: ASSERTION FAILED: file rts/sm/MarkWeak.c, line 371 \r\n\r\n (GHC version 7.7.20130901 for i386_unknown_linux)\r\n Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\nHere is Akio's guess:\r\n\r\nI wonder if this issue could have been introduced by the commit:\r\n\r\nhttps://github.com/ghc/ghc/commit/6770663f764db76dbb7138ccb3aea0527d194151\r\n\r\nIt looks like after the commit, addCFinalizerToWeak# can call into the GC\r\nwith the closure lock held. This means the info pointer points to\r\nstg_WHITEHOLE_info, breaking the asserted invariant. I haven't done any\r\ntesting to confirm this, however.\r\n\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/8221Type checker hangs2019-07-07T18:45:59ZmaxsType checker hangsThe following program gets GHC stuck in Renamer/typechecker. This compiles correctly in 7.6.3.
```
{-# LANGUAGE DeriveDataTypeable #-}
module Type.Type where
import Data.Data
import qualified Data.UnionFind.IO as UF
data SrcSpan = Sp...The following program gets GHC stuck in Renamer/typechecker. This compiles correctly in 7.6.3.
```
{-# LANGUAGE DeriveDataTypeable #-}
module Type.Type where
import Data.Data
import qualified Data.UnionFind.IO as UF
data SrcSpan = Span String | NoSpan String
deriving (Eq, Ord, Data, Typeable)
data Located e = L SrcSpan e
deriving (Eq, Ord, Data, Typeable)
```
Removing either the:
```
import qualified Data.UnionFind.IO as UF
```
or
```
data Located e = L SrcSpan e
deriving (Eq, Ord, Data, Typeable)
```
or
Removing the Eq Ord from Located:
```
data Located e = L SrcSpan e
deriving (Data, Typeable)
```
will allow it to terminate.
ddump-tc-trace shows it is related to the derived typeable instance.
The log is attached.
I am compiling with:
```
arm-apple-darwin10-ghc -staticlib -ddump-tc-trace Type/Type.hs -v -threaded
```
I don't have a x86 build of HEAD handy, I think if someone could try this program in HEAD then we will know if it is ARM / GHC iOS / stage1 specific or not.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | MacOS X |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Type checker hangs","status":"New","operating_system":"MacOS X","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.7","keywords":["hangs"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The following program gets GHC stuck in Renamer/typechecker. This compiles correctly in 7.6.3.\r\n\r\n{{{\r\n{-# LANGUAGE DeriveDataTypeable #-}\r\n\r\nmodule Type.Type where\r\n\r\nimport Data.Data\r\nimport qualified Data.UnionFind.IO as UF\r\n\r\ndata SrcSpan = Span String | NoSpan String\r\n deriving (Eq, Ord, Data, Typeable)\r\n\r\ndata Located e = L SrcSpan e\r\n deriving (Eq, Ord, Data, Typeable)\r\n}}}\r\n\r\nRemoving either the:\r\n\r\n{{{\r\nimport qualified Data.UnionFind.IO as UF\r\n}}}\r\n\r\nor\r\n\r\n{{{\r\ndata Located e = L SrcSpan e\r\n deriving (Eq, Ord, Data, Typeable)\r\n}}}\r\n\r\nor\r\n\r\nRemoving the Eq Ord from Located:\r\n{{{\r\ndata Located e = L SrcSpan e\r\n deriving (Data, Typeable)\r\n}}}\r\n\r\nwill allow it to terminate.\r\n\r\nddump-tc-trace shows it is related to the derived typeable instance.\r\n\r\nThe log is attached.\r\n\r\nI am compiling with:\r\n\r\n{{{\r\narm-apple-darwin10-ghc -staticlib -ddump-tc-trace Type/Type.hs -v -threaded\r\n}}}\r\n\r\nI don't have a x86 build of HEAD handy, I think if someone could try this program in HEAD then we will know if it is ARM / GHC iOS / stage1 specific or not.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1dreixeldreixelhttps://gitlab.haskell.org/ghc/ghc/-/issues/8209Race condition in setNumCapabilities2019-07-07T18:46:02Ztakano-akioRace condition in setNumCapabilitiesIn HEAD, the following program sometimes deadlocks (about 1/10 of the time).
```
import Control.Concurrent
import Control.Monad
import GHC.Conc
main = do
mainTid <- myThreadId
labelThread mainTid "main"
forM_ [0..0] $ \i -> forkI...In HEAD, the following program sometimes deadlocks (about 1/10 of the time).
```
import Control.Concurrent
import Control.Monad
import GHC.Conc
main = do
mainTid <- myThreadId
labelThread mainTid "main"
forM_ [0..0] $ \i -> forkIO $ do
subTid <- myThreadId
labelThread subTid $ "sub " ++ show i
forM_ [0..100000000] $ \j -> putStrLn $ "sub " ++ show i ++ ": " ++ show j
yield
setNumCapabilities 2
```
The problem seems to be that there is a race condition between setNumCapabilites and a Task returning from a foreign call. Specifically, a sequence of events like the following can happen:
1. Task 0 makes a foreign call.
1. Task 1 calls setNumCapabilities()
1. The call on task 0 returns; it reads task-\>cap from the memory.
1. Task 1 moves the Capabilities, invalidating all pointers to them.
1. Task 0 takes over the invalidated Capability.
The attached patch adds an ASSERT to the RTS to demonstrate the problem (it does not fix the problem).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Race condition in setNumCapabilities","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"In HEAD, the following program sometimes deadlocks (about 1/10 of the time).\r\n\r\n{{{\r\nimport Control.Concurrent\r\nimport Control.Monad\r\nimport GHC.Conc\r\n\r\nmain = do\r\n mainTid <- myThreadId\r\n labelThread mainTid \"main\"\r\n forM_ [0..0] $ \\i -> forkIO $ do\r\n subTid <- myThreadId\r\n labelThread subTid $ \"sub \" ++ show i\r\n forM_ [0..100000000] $ \\j -> putStrLn $ \"sub \" ++ show i ++ \": \" ++ show j\r\n yield\r\n setNumCapabilities 2\r\n}}}\r\n\r\nThe problem seems to be that there is a race condition between setNumCapabilites and a Task returning from a foreign call. Specifically, a sequence of events like the following can happen:\r\n\r\n1. Task 0 makes a foreign call.\r\n2. Task 1 calls setNumCapabilities()\r\n3. The call on task 0 returns; it reads task->cap from the memory.\r\n4. Task 1 moves the Capabilities, invalidating all pointers to them.\r\n5. Task 0 takes over the invalidated Capability.\r\n\r\nThe attached patch adds an ASSERT to the RTS to demonstrate the problem (it does not fix the problem).","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/8208iOS patch: Fix linker warnings2019-07-07T18:46:02ZlukexiiOS patch: Fix linker warningsThis (very small) patch generalizes some fixes already used on OS X to silence some harmless warnings from ld, and fixes a spurious "Couldn't figure out linker information!" warning.
<details><summary>Trac metadata</summary>
| Trac fie...This (very small) patch generalizes some fixes already used on OS X to silence some harmless warnings from ld, and fixes a spurious "Couldn't figure out linker information!" warning.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.7 |
| 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":"iOS patch: Fix linker warnings","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This (very small) patch generalizes some fixes already used on OS X to silence some harmless warnings from ld, and fixes a spurious \"Couldn't figure out linker information!\" warning.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/8194make install (at git ef01794) still fails2019-07-07T18:46:06Zguestmake install (at git ef01794) still failsI think the last time `make install` worked for me was sometime in
February or March 2013. The build succeeds but `make install` fails.
mk/build.mk:
```
BuildFlavour = perf
V = 0
```
Steps to reproduce:
```
$ perl boot
$ ./configure ...I think the last time `make install` worked for me was sometime in
February or March 2013. The build succeeds but `make install` fails.
mk/build.mk:
```
BuildFlavour = perf
V = 0
```
Steps to reproduce:
```
$ perl boot
$ ./configure --prefix=/tmp/ghc/7.7.20130827
$ make
$ make install
[...]
Installing library in
/tmp/ghc/7.7.20130827/lib/ghc-7.7.20130827/haskell2010-1.1.1.0
"/tmp/ghc/7.7.20130827/lib/ghc-7.7.20130827/bin/ghc-pkg" --force
--global-package-db
"/tmp/ghc/7.7.20130827/lib/ghc-7.7.20130827/package.conf.d" update
rts/dist/package.conf.install
/tmp/ghc/7.7.20130827/lib/ghc-7.7.20130827/bin/ghc-pkg: error while
loading shared libraries:
libHSbin-package-db-0.0.0.0-ghc7.7.20130827.so: cannot open shared
object file: No such file or directory
make[1]: *** [install_packages] Error 127
make: *** [install] Error 2
```
Related mailing list threads:
- http://www.haskell.org/pipermail/ghc-devs/2013-August/002167.html
- http://www.haskell.org/pipermail/ghc-devs/2013-April/000995.html
- http://www.haskell.org/pipermail/ghc-devs/2013-March/000822.html
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"make install (at git ef01794) still fails","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"7.8.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I think the last time `make install` worked for me was sometime in\r\nFebruary or March 2013. The build succeeds but `make install` fails.\r\n\r\n\r\nmk/build.mk:\r\n{{{\r\nBuildFlavour = perf\r\nV = 0\r\n}}}\r\n\r\nSteps to reproduce:\r\n{{{\r\n$ perl boot\r\n$ ./configure --prefix=/tmp/ghc/7.7.20130827\r\n$ make\r\n$ make install\r\n[...]\r\nInstalling library in\r\n/tmp/ghc/7.7.20130827/lib/ghc-7.7.20130827/haskell2010-1.1.1.0\r\n\"/tmp/ghc/7.7.20130827/lib/ghc-7.7.20130827/bin/ghc-pkg\" --force\r\n--global-package-db\r\n\"/tmp/ghc/7.7.20130827/lib/ghc-7.7.20130827/package.conf.d\" update\r\nrts/dist/package.conf.install\r\n/tmp/ghc/7.7.20130827/lib/ghc-7.7.20130827/bin/ghc-pkg: error while\r\nloading shared libraries:\r\nlibHSbin-package-db-0.0.0.0-ghc7.7.20130827.so: cannot open shared\r\nobject file: No such file or directory\r\n\r\nmake[1]: *** [install_packages] Error 127\r\nmake: *** [install] Error 2\r\n}}}\r\n\r\nRelated mailing list threads:\r\n\r\n* http://www.haskell.org/pipermail/ghc-devs/2013-August/002167.html\r\n* http://www.haskell.org/pipermail/ghc-devs/2013-April/000995.html\r\n* http://www.haskell.org/pipermail/ghc-devs/2013-March/000822.html","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1bosboshttps://gitlab.haskell.org/ghc/ghc/-/issues/8193document :kind! in ghci built-in help2019-07-07T18:46:06Zrwbartondocument :kind! in ghci built-in helpPatch attached.
I have the wording as:
```
:kind[!] <type> show the kind of <type>
(!: also show the normalised type)
```
could use some tweaking perhaps.
<details><summary>Trac metadata<...Patch attached.
I have the wording as:
```
:kind[!] <type> show the kind of <type>
(!: also show the normalised type)
```
could use some tweaking perhaps.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.4.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"document :kind! in ghci built-in help","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.4.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Patch attached.\r\n\r\nI have the wording as:\r\n{{{\r\n :kind[!] <type> show the kind of <type>\r\n (!: also show the normalised type)\r\n}}}\r\ncould use some tweaking perhaps.","type_of_failure":"OtherFailure","blocking":[]} -->7.8.1