GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2023-03-21T12:06:34Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/15541package environment files and the GHC API2023-03-21T12:06:34Zlspitznerpackage environment files and the GHC APIThe GHC API respects package environment files, which is not documented and was not announced.
I consider this to be at least a severe documentation bug.
Afaik this goes back to ghc-8.0.
#15513 is a ticket that essentially asks for th...The GHC API respects package environment files, which is not documented and was not announced.
I consider this to be at least a severe documentation bug.
Afaik this goes back to ghc-8.0.
#15513 is a ticket that essentially asks for the corresponding entry in the migration guide.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | GHC API |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"package environment files and the GHC API","status":"New","operating_system":"","component":"GHC API","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":["environment","package"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The GHC API respects package environment files, which is not documented and was not announced.\r\n\r\nI consider this to be at least a severe documentation bug.\r\n\r\nAfaik this goes back to ghc-8.0.\r\n\r\n#15513 is a ticket that essentially asks for the corresponding entry in the migration guide.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/143468.2.1 regression: heap corruption after safe foreign calls2022-07-06T16:47:17Zandrewchen8.2.1 regression: heap corruption after safe foreign callsTest case: (compile with ghc 8.2.1 and -threaded option)
```haskell
module Main where
import Control.Concurrent
import Control.Monad
import Data.Word
import Foreign.Marshal.Alloc
import Foreign.Ptr
import Foreign.Storable
foreign impo...Test case: (compile with ghc 8.2.1 and -threaded option)
```haskell
module Main where
import Control.Concurrent
import Control.Monad
import Data.Word
import Foreign.Marshal.Alloc
import Foreign.Ptr
import Foreign.Storable
foreign import ccall safe "test"
c_test :: Ptr Word32 -> IO ()
main :: IO ()
main = do
replicateM_ 1000 $ threadDelay 1000
_ <- forkIO $ forever $ threadDelay 100
allocaBytes 4 $ \p -> forever $ do
c_test p
x <- peek p
unless (x == 0xDEADBEEF) $ putStrLn "value mismatch"
```
```c
void test(unsigned int *buf) {
*buf = 0xDEADBEEF;
}
```
On my machine, it detects a few value mismatches before crashing with sigsegv.
```
$ time ./.stack-work/install/x86_64-linux-nopie/nightly-2017-10-10/8.2.1/bin/bug
value mismatch
value mismatch
value mismatch
value mismatch
zsh: segmentation fault (core dumped) ./.stack-work/install/x86_64-linux-nopie/nightly-2017-10-10/8.2.1/bin/bug
./.stack-work/install/x86_64-linux-nopie/nightly-2017-10-10/8.2.1/bin/bug 2.11s user 0.25s system 66% cpu 3.543 total
```
I believe this is what is causing crashes in xmobar. See discussion: https://github.com/jaor/xmobar/issues/310. Note that the crash in xmobar still happens without -threaded option, while this example only breaks when compiled with -threaded.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.2.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"8.2.1 regression: heap corruption after safe foreign calls","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Test case: (compile with ghc 8.2.1 and -threaded option)\r\n{{{#!haskell\r\nmodule Main where\r\n\r\nimport Control.Concurrent\r\nimport Control.Monad\r\nimport Data.Word\r\nimport Foreign.Marshal.Alloc\r\nimport Foreign.Ptr\r\nimport Foreign.Storable\r\n\r\nforeign import ccall safe \"test\"\r\n c_test :: Ptr Word32 -> IO ()\r\n\r\nmain :: IO ()\r\nmain = do\r\n replicateM_ 1000 $ threadDelay 1000\r\n _ <- forkIO $ forever $ threadDelay 100\r\n allocaBytes 4 $ \\p -> forever $ do\r\n c_test p\r\n x <- peek p\r\n unless (x == 0xDEADBEEF) $ putStrLn \"value mismatch\"\r\n}}}\r\n{{{#!c\r\nvoid test(unsigned int *buf) {\r\n *buf = 0xDEADBEEF;\r\n}\r\n}}}\r\n\r\nOn my machine, it detects a few value mismatches before crashing with sigsegv.\r\n{{{\r\n$ time ./.stack-work/install/x86_64-linux-nopie/nightly-2017-10-10/8.2.1/bin/bug\r\nvalue mismatch\r\nvalue mismatch\r\nvalue mismatch\r\nvalue mismatch\r\nzsh: segmentation fault (core dumped) ./.stack-work/install/x86_64-linux-nopie/nightly-2017-10-10/8.2.1/bin/bug\r\n./.stack-work/install/x86_64-linux-nopie/nightly-2017-10-10/8.2.1/bin/bug 2.11s user 0.25s system 66% cpu 3.543 total\r\n}}}\r\n\r\nI believe this is what is causing crashes in xmobar. See discussion: https://github.com/jaor/xmobar/issues/310. Note that the crash in xmobar still happens without -threaded option, while this example only breaks when compiled with -threaded.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/15544Non-deterministic segmentation fault in cryptohash-sha256 testsuite2022-03-16T19:47:50ZBen GamariNon-deterministic segmentation fault in cryptohash-sha256 testsuite```
$ cabal get cryptohash-sha256-0.11.101.0
$ cd cryptohash-sha256-0.11.101.0
$ cabal new-run -w ghc-8.6.1 --enable-test --allow-newer="*:base,*:stm,*:tasty" test:test-sha256 -- -j 8 --quickcheck-tests 9999
```
Eventually the program w...```
$ cabal get cryptohash-sha256-0.11.101.0
$ cd cryptohash-sha256-0.11.101.0
$ cabal new-run -w ghc-8.6.1 --enable-test --allow-newer="*:base,*:stm,*:tasty" test:test-sha256 -- -j 8 --quickcheck-tests 9999
```
Eventually the program will start spamming stderr with `test-sha256: lost signal due to full pipe: 11` repeatedly. This apparently only started with 8.6.1.8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15112ghc 8.4.2 on OS X: clang: warning: argument unused during compilation: '-nopie'2021-10-03T00:49:22Zelaforgeghc 8.4.2 on OS X: clang: warning: argument unused during compilation: '-nopie'```
% cat Nopie.hs
module Nopie where
main :: IO ()
main = putStrLn "hi"
% ghc -fforce-recomp -c -fhpc Nopie.hs
clang: warning: argument unused during compilation: '-nopie' [-Wunused-command-line-argument]
clang: warning: argument unuse...```
% cat Nopie.hs
module Nopie where
main :: IO ()
main = putStrLn "hi"
% ghc -fforce-recomp -c -fhpc Nopie.hs
clang: warning: argument unused during compilation: '-nopie' [-Wunused-command-line-argument]
clang: warning: argument unused during compilation: '-nopie' [-Wunused-command-line-argument]
```
This happens for every source file when -fhpc is given, but also happens on links even when -fhpc isn't given. With -v, I see a call to gcc with -no-pie. When I run the same compile with ghc 8.4.1, I see the same call to gcc, only without that -no-pie flag, so this is new. It seems to be a harmless warning, but really clutters up the output.
Incidentally, it looks like the particular spelling of -no-pie was added to LLVM a year ago due to ghc: https://reviews.llvm.org/D35462 Not sure if that's relevant.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 8.4.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown/Multiple |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ghc 8.4.2 on OS X: clang: warning: argument unused during compilation: '-nopie'","status":"New","operating_system":"Unknown/Multiple","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"{{{\r\n% cat Nopie.hs\r\nmodule Nopie where\r\n\r\nmain :: IO ()\r\nmain = putStrLn \"hi\"\r\n% ghc -fforce-recomp -c -fhpc Nopie.hs\r\nclang: warning: argument unused during compilation: '-nopie' [-Wunused-command-line-argument]\r\nclang: warning: argument unused during compilation: '-nopie' [-Wunused-command-line-argument]\r\n}}}\r\n\r\nThis happens for every source file when -fhpc is given, but also happens on links even when -fhpc isn't given. With -v, I see a call to gcc with -no-pie. When I run the same compile with ghc 8.4.1, I see the same call to gcc, only without that -no-pie flag, so this is new. It seems to be a harmless warning, but really clutters up the output.\r\n\r\nIncidentally, it looks like the particular spelling of -no-pie was added to LLVM a year ago due to ghc: https://reviews.llvm.org/D35462 Not sure if that's relevant.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15164Slowdown in ghc compile times from GHC 8.0.2 to GHC 8.2.1 when doing Called a...2021-02-04T10:02:02ZPhilippeSlowdown in ghc compile times from GHC 8.0.2 to GHC 8.2.1 when doing Called arity analysisHello,
I have this program that compiles against packages of stack LTS-9.21. When i compile with GHC 8.0.2 (version of LTS-9.21) the compiling is fast.
```
72.01user 34.61system 0:52.98elapsed 201%CPU (0avgtext+0avgdata 600684maxreside...Hello,
I have this program that compiles against packages of stack LTS-9.21. When i compile with GHC 8.0.2 (version of LTS-9.21) the compiling is fast.
```
72.01user 34.61system 0:52.98elapsed 201%CPU (0avgtext+0avgdata 600684maxresident)k
```
When i upgrade to LTS-11.9 compiling gets slow. To test if it was a problem with new package or GHC (ghc gives some new packages too) i ran:
```
/usr/bin/time stack build --compiler ghc-8.2.1 --ghc-options="-v3 -j4 -O2 -fexcess-precision -optc-O3 -optc-ffast-math -rtsopts=none -no-rtsopts-suggestions"
```
with the old package of LTS-9.21 but with the newer GHC 8.2.1 compiler. Now the compile times are much higher:
```
2481.26user 663.66system 35:38.82elapsed 147%CPU (0avgtext+0avgdata 674732maxresident)k
```
I already took out parts of the grammar to get it even to compile. When i have the full grammar i can let my laptop compile 24 hours and it's still busy.
I was not sure how to further reduce the code. Maybe when a lot of effort i can cut out a few lines here and there. So i uploaded the entire project here https://github.com/flip111/parser-calledarityanalysis i already took out a lot of code. If anyone has suggestions on how to further reduce the code i can try.
Because i had debug info on (-v3 flag) i saw it was stuck for a long time at "Called arity analysis"
I prioritize this bug high because i think the slowdown is very problematic.8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15197Apparent missing dependency in ghc-heap2020-08-22T11:26:53ZBen GamariApparent missing dependency in ghc-heapThe `ghc-heap` library appears to be missing a dependency from `GHC.Exts.Heap.Closures` to `GHC.Exts.Heap.InfoTableProf`. This causes the vanilla build to fail (in particular when building the profiled way):
```
“inplace/bin/ghc-stage1”...The `ghc-heap` library appears to be missing a dependency from `GHC.Exts.Heap.Closures` to `GHC.Exts.Heap.InfoTableProf`. This causes the vanilla build to fail (in particular when building the profiled way):
```
“inplace/bin/ghc-stage1” -hisuf p_hi -osuf p_o -hcsuf p_hc -static -prof -eventlog -H32m -O -Wall -this-unit-id ghc-heap-8.5 -hide-all-packages -i -ilibraries/ghc-heap/. -ilibraries/ghc-heap/dist-install/build -Ilibraries/ghc-heap/dist-install/build -ilibraries/ghc-heap/dist-install/build/./autogen -Ilibraries/ghc-heap/dist-install/build/./autogen -Ilibraries/ghc-heap/. -optP-include -optPlibraries/ghc-heap/dist-install/build/./autogen/cabal_macros.h -package-id base-4.12.0.0 -package-id ghc-prim-0.5.3 -package-id rts -Wall -XHaskell2010 -O2 -no-user-package-db -rtsopts -Wno-deprecated-flags -Wnoncanonical-monad-instances -odir libraries/ghc-heap/dist-install/build -hidir libraries/ghc-heap/dist-install/build -stubdir libraries/ghc-heap/dist-install/build -c libraries/ghc-heap/./GHC/Exts/Heap/Closures.hs -o libraries/ghc-heap/dist-install/build/GHC/Exts/Heap/Closures.p_o -dyno libraries/ghc-heap/dist-install/build/GHC/Exts/Heap/Closures.dyn_olibraries/ghc-heap/GHC/Exts/Heap/Closures.hs:23:1: error:
Could not find module ‘GHC.Exts.Heap.InfoTableProf’
It is a member of the hidden package ‘ghc-heap-8.5’.
You can run ‘:set -package ghc-heap’ to expose it.
(Note: this unloads all the modules in the current scope.)
Use -v to see a list of the files searched for.
|
23 | import GHC.Exts.Heap.InfoTableProf
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
```
Building the `libraries/ghc-heap/dist-install/GHC/Exts/Heap/InfoTableProf.p_o` manually allows the build to proceed.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.4.3 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Apparent missing dependency in ghc-heap","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":"The `ghc-heap` library appears to be missing a dependency from `GHC.Exts.Heap.Closures` to `GHC.Exts.Heap.InfoTableProf`. This causes the vanilla build to fail (in particular when building the profiled way):\r\n{{{\r\n“inplace/bin/ghc-stage1” -hisuf p_hi -osuf p_o -hcsuf p_hc -static -prof -eventlog -H32m -O -Wall -this-unit-id ghc-heap-8.5 -hide-all-packages -i -ilibraries/ghc-heap/. -ilibraries/ghc-heap/dist-install/build -Ilibraries/ghc-heap/dist-install/build -ilibraries/ghc-heap/dist-install/build/./autogen -Ilibraries/ghc-heap/dist-install/build/./autogen -Ilibraries/ghc-heap/. -optP-include -optPlibraries/ghc-heap/dist-install/build/./autogen/cabal_macros.h -package-id base-4.12.0.0 -package-id ghc-prim-0.5.3 -package-id rts -Wall -XHaskell2010 -O2 -no-user-package-db -rtsopts -Wno-deprecated-flags -Wnoncanonical-monad-instances -odir libraries/ghc-heap/dist-install/build -hidir libraries/ghc-heap/dist-install/build -stubdir libraries/ghc-heap/dist-install/build -c libraries/ghc-heap/./GHC/Exts/Heap/Closures.hs -o libraries/ghc-heap/dist-install/build/GHC/Exts/Heap/Closures.p_o -dyno libraries/ghc-heap/dist-install/build/GHC/Exts/Heap/Closures.dyn_olibraries/ghc-heap/GHC/Exts/Heap/Closures.hs:23:1: error:\r\n Could not find module ‘GHC.Exts.Heap.InfoTableProf’\r\n It is a member of the hidden package ‘ghc-heap-8.5’.\r\n You can run ‘:set -package ghc-heap’ to expose it.\r\n (Note: this unloads all the modules in the current scope.)\r\n Use -v to see a list of the files searched for.\r\n |\r\n23 | import GHC.Exts.Heap.InfoTableProf\r\n | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\r\n}}}\r\n\r\nBuilding the `libraries/ghc-heap/dist-install/GHC/Exts/Heap/InfoTableProf.p_o` manually allows the build to proceed.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/11786Need -fno-print-explicit-runtime-reps to work on IfaceType, else RuntimeRep l...2020-03-16T15:44:12ZSimon Peyton JonesNeed -fno-print-explicit-runtime-reps to work on IfaceType, else RuntimeRep leaksAfter #11549, we are suppose not to show `RuntimeRep` to users, when `-fno-print-explicit-runtime-reps` is on. But we do:
```
:info ($)
Prelude> :i ($)
($) :: forall (r :: GHC.Types.RuntimeRep) a (b :: TYPE r).
(a -> b) -> a ->...After #11549, we are suppose not to show `RuntimeRep` to users, when `-fno-print-explicit-runtime-reps` is on. But we do:
```
:info ($)
Prelude> :i ($)
($) :: forall (r :: GHC.Types.RuntimeRep) a (b :: TYPE r).
(a -> b) -> a -> b
-- Defined in ‘GHC.Base’
```
This happens because the runtime-rep-suppression happens on `Type`, but for `:info` we use `pprInfo` which uses `tyThingToIfaceDecl` and then prints it. And `tyThingToIfaceDecl` doesn't know about the `-fprint-explicit-runtime-reps` flag; and I'd like to keep it that way.
We want to change `pprType` to convert to `IfaceType` and then print anyway.
I suppose that this means that the pretty-printer for `IfaceType` needs to know about this runtime-rep suppression. That's a bit tiresome, but not impossible, especially since there is no shadowing to worry about.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.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":"Need -fno-print-explicit-runtime-reps to work on IfaceType, else RuntimeRep leaks","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.3","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"After #11549, we are suppose not to show `RuntimeRep` to users, when `-fno-print-explicit-runtime-reps` is on. But we do:\r\n{{{\r\n:info ($)\r\nPrelude> :i ($)\r\n($) :: forall (r :: GHC.Types.RuntimeRep) a (b :: TYPE r).\r\n (a -> b) -> a -> b\r\n \t-- Defined in ‘GHC.Base’\r\n}}}\r\nThis happens because the runtime-rep-suppression happens on `Type`, but for `:info` we use `pprInfo` which uses `tyThingToIfaceDecl` and then prints it. And `tyThingToIfaceDecl` doesn't know about the `-fprint-explicit-runtime-reps` flag; and I'd like to keep it that way.\r\n\r\nWe want to change `pprType` to convert to `IfaceType` and then print anyway.\r\n\r\nI suppose that this means that the pretty-printer for `IfaceType` needs to know about this runtime-rep suppression. That's a bit tiresome, but not impossible, especially since there is no shadowing to worry about.\r\n\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Tao Hesighingnow@gmail.comTao Hesighingnow@gmail.comhttps://gitlab.haskell.org/ghc/ghc/-/issues/14737Improve performance of Simplify.simplCast2019-09-23T07:37:55ZTobias Dammerstdammers@gmail.comImprove performance of Simplify.simplCastSplitting off task 3 from #11735. When compiling [https://ghc.haskell.org/trac/ghc/attachment/ticket/14683/Grammar.hs](https://ghc.haskell.org/trac/ghc/attachment/ticket/14683/Grammar.hs), `simplCast` eats up more execution time than we ...Splitting off task 3 from #11735. When compiling [https://ghc.haskell.org/trac/ghc/attachment/ticket/14683/Grammar.hs](https://ghc.haskell.org/trac/ghc/attachment/ticket/14683/Grammar.hs), `simplCast` eats up more execution time than we think it should.
From [https://ghc.haskell.org/trac/ghc/ticket/11735\#comment:10](https://ghc.haskell.org/trac/ghc/ticket/11735#comment:10):
> Something is clearly wrong with `Simplify.simplCast`. I think I know what it is. Given
>
> ```
> (fun |> co) @t1 @t2 ... @tn
> ```
>
> we will call `pushCoTyArg` `n` times, and hence does `n` singleton substitutions, via the `n` calls to `piResultTy`.
>
> Solution: gather up those type arguments (easy) and define
>
> ```
> pushCoTyArgs :: Coercion -> [Type] -> Maybe ([Type], Coercion)
> ```
And [https://ghc.haskell.org/trac/ghc/ticket/11735\#comment:41](https://ghc.haskell.org/trac/ghc/ticket/11735#comment:41):
> OK. I looked at `pushCoTyArg` and friends, and I have a very simple solution: just move the `isReflexiveCo` case in `addCoerce` (a local function within `Simplify.simplCast`) to the top. That should do it. Then `pushCoTyArg` is never called with a reflexive coercion, and so the `piResultTy` case won't happen.
>
> Now, `pushCoArgs` might still call `pushCoTyArg` with a reflexive coercion, but it can be taught not to as well: Have `pushCoArgs` return a `Maybe ([CoreArg], Maybe Coercion)` and `pushCoArg` return a `Maybe (CoreArg, Maybe Coercion)`. If the second return values are `Nothing`, that means that there is no cast (i.e., that the cast would have been reflexive). The only client of `pushCoArg(s)` is `exprIsConApp_maybe`, which simply omits a cast if `pushCoArgs` returns `Nothing`. Then, we never have to bother creating the reflexive coercions.
>
> This should be an easy win all around.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | --------------------------- |
| Version | 8.2.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | goldfire, simonpj, tdammers |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Improve performance of Simplify.simplCast","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["goldfire","simonpj","tdammers"],"type":"Bug","description":"Splitting off task 3 from #11735. When compiling [https://ghc.haskell.org/trac/ghc/attachment/ticket/14683/Grammar.hs], `simplCast` eats up more execution time than we think it should.\r\n\r\nFrom [https://ghc.haskell.org/trac/ghc/ticket/11735#comment:10]:\r\n\r\n> Something is clearly wrong with `Simplify.simplCast`. I think I know what it is. Given\r\n> {{{\r\n> (fun |> co) @t1 @t2 ... @tn\r\n> }}}\r\n> we will call `pushCoTyArg` `n` times, and hence does `n` singleton substitutions, via the `n` calls to `piResultTy`.\r\n> \r\n> Solution: gather up those type arguments (easy) and define\r\n> {{{\r\n> pushCoTyArgs :: Coercion -> [Type] -> Maybe ([Type], Coercion)\r\n> }}}\r\n\r\nAnd [https://ghc.haskell.org/trac/ghc/ticket/11735#comment:41]:\r\n\r\n> OK. I looked at `pushCoTyArg` and friends, and I have a very simple solution: just move the `isReflexiveCo` case in `addCoerce` (a local function within `Simplify.simplCast`) to the top. That should do it. Then `pushCoTyArg` is never called with a reflexive coercion, and so the `piResultTy` case won't happen.\r\n> \r\n> Now, `pushCoArgs` might still call `pushCoTyArg` with a reflexive coercion, but it can be taught not to as well: Have `pushCoArgs` return a `Maybe ([CoreArg], Maybe Coercion)` and `pushCoArg` return a `Maybe (CoreArg, Maybe Coercion)`. If the second return values are `Nothing`, that means that there is no cast (i.e., that the cast would have been reflexive). The only client of `pushCoArg(s)` is `exprIsConApp_maybe`, which simply omits a cast if `pushCoArgs` returns `Nothing`. Then, we never have to bother creating the reflexive coercions.\r\n> \r\n> This should be an easy win all around.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Richard Eisenbergrae@richarde.devRichard Eisenbergrae@richarde.devhttps://gitlab.haskell.org/ghc/ghc/-/issues/13900Core lint in BuildFlavour=perf-llvm2019-07-07T18:19:35ZBen GamariCore lint in BuildFlavour=perf-llvmI found the following Core lint failure when compiling c9977385dca9536f18374242f713b1048a38dec5 with `BuildFlavour=perf-llvm` and `GhcStage2HcOpts += -dcore-lint -dcmm-lint`,
```
"inplace/bin/ghc-stage1" -hisuf dyn_hi -osuf dyn_o -hcsu...I found the following Core lint failure when compiling c9977385dca9536f18374242f713b1048a38dec5 with `BuildFlavour=perf-llvm` and `GhcStage2HcOpts += -dcore-lint -dcmm-lint`,
```
"inplace/bin/ghc-stage1" -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -O -H64m -fllvm -Wall -hide-all-packages -i -ighc/. -ighc/stage2/build -Ighc/stage2/build -ighc/stage2/build/ghc/autogen -Ighc/stage2/build/ghc/autogen -optP-DGHCI -optP-include -optPghc/stage2/build/ghc/autogen/cabal_macros.h -package-id base-4.10.0.0 -package-id array-0.5.1.2 -package-id bytestring-0.10.8.2 -package-id directory-1.3.0.2 -package-id process-1.6.0.0 -package-id filepath-1.4.1.2 -package-id ghc-boot-8.3 -package-id ghc-8.3 -package-id unix-2.7.2.2 -package-id containers-0.5.10.2 -package-id deepseq-1.4.3.0 -package-id ghci-8.3 -package-id haskeline-0.7.4.0 -package-id time-1.8.0.1 -package-id transformers-0.5.2.0 -Wall -fno-warn-name-shadowing -XHaskell2010 -O2 -dcore-lint -dcmm-lint -no-hs-main -threaded -no-user-package-db -rtsopts -Wnoncanonical-monad-instances -odir ghc/stage2/build -hidir ghc/stage2/build -stubdir ghc/stage2/build -c ghc/./GHCi/UI/Tags.hs -o ghc/stage2/build/GHCi/UI/Tags.dyn_o
*** Core Lint errors : in result of Simplifier ***
<no location info>: warning:
[RHS of $wgo_XtpE :: [Name]
-> Session
-> State# RealWorld
-> (# State# RealWorld, [[TagInfo]] #)]
Rule "SC:$wgo0": lhs type: (# State# RealWorld, [[TagInfo]] #)
rhs type: (# State# RealWorld, [Maybe TyThing] #)
*** Offending Program ***
(see attached)
```8.6.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/14416CI with CircleCI2019-07-07T18:17:07ZManuel M T ChakravartyCI with CircleCIMerging the PR with the new CircleCI per-commit builds for Linux/x86_64 and macOS/x86_64: https://github.com/ghc/ghc/pull/83
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- |...Merging the PR with the new CircleCI per-commit builds for Linux/x86_64 and macOS/x86_64: https://github.com/ghc/ghc/pull/83
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"CI with CircleCI","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"8.4.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Task","description":"Merging the PR with the new CircleCI per-commit builds for Linux/x86_64 and macOS/x86_64: https://github.com/ghc/ghc/pull/83","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/14808GHC HEAD regression: GADT constructors no longer quantify tyvars in topologic...2019-07-07T18:15:30ZRyan ScottGHC HEAD regression: GADT constructors no longer quantify tyvars in topological orderOriginally noticed in #14796. This program:
```hs
{-# LANGUAGE ConstraintKinds #-}
{-# LANGUAGE GADTs #-}
{-# LANGUAGE TypeApplications #-}
module Bug where
import Data.Kind
data ECC ctx f a where
ECC :: ctx => f a -> ECC ctx f a
f...Originally noticed in #14796. This program:
```hs
{-# LANGUAGE ConstraintKinds #-}
{-# LANGUAGE GADTs #-}
{-# LANGUAGE TypeApplications #-}
module Bug where
import Data.Kind
data ECC ctx f a where
ECC :: ctx => f a -> ECC ctx f a
f :: [()] -> ECC () [] ()
f = ECC @() @[] @()
```
Typechecks in GHC 8.2.2 and 8.4.1, but not in GHC HEAD:
```
$ ~/Software/ghc2/inplace/bin/ghc-stage2 Bug.hs
[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
Bug.hs:12:5: error:
• Couldn't match type ‘()’ with ‘[]’
Expected type: [()] -> ECC (() :: Constraint) [] ()
Actual type: () [] -> ECC (() :: Constraint) () []
• In the expression: ECC @() @[] @()
In an equation for ‘f’: f = ECC @() @[] @()
|
12 | f = ECC @() @[] @()
| ^^^^^^^^^^^^^^^
Bug.hs:12:10: error:
• Expected kind ‘* -> *’, but ‘()’ has kind ‘*’
• In the type ‘()’
In the expression: ECC @() @[] @()
In an equation for ‘f’: f = ECC @() @[] @()
|
12 | f = ECC @() @[] @()
| ^^
Bug.hs:12:14: error:
• Expecting one more argument to ‘[]’
Expected a type, but ‘[]’ has kind ‘* -> *’
• In the type ‘[]’
In the expression: ECC @() @[] @()
In an equation for ‘f’: f = ECC @() @[] @()
|
12 | f = ECC @() @[] @()
| ^^
```
This is because the order of type variables for `ECC` has changed between GHC 8.4.1 and HEAD. In 8.4.1, it's
```
$ /opt/ghc/8.4.1/bin/ghci Bug.hs -XTypeApplications -fprint-explicit-foralls
GHCi, version 8.4.0.20180209: http://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /home/rgscott/.ghci
[1 of 1] Compiling Bug ( Bug.hs, interpreted )
Ok, one module loaded.
λ> :type +v ECC
ECC
:: forall (ctx :: Constraint) (f :: * -> *) a.
ctx =>
f a -> ECC ctx f a
```
In GHC HEAD, however, it's:
```
$ ~/Software/ghc2/inplace/bin/ghc-stage2 --interactive Bug.hs -XTypeApplications -fprint-explicit-foralls
GHCi, version 8.5.20180213: http://www.haskell.org/ghc/ :? for help
Loaded GHCi configuration from /home/rgscott/.ghci
[1 of 1] Compiling Bug ( Bug.hs, interpreted )
Ok, one module loaded.
λ> :type +v ECC
ECC
:: forall (f :: * -> *) a (ctx :: Constraint).
ctx =>
f a -> ECC ctx f a
```
This regression was introduced in fa29df02a1b0b926afb2525a258172dcbf0ea460 (Refactor ConDecl: Trac #14529).
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.5 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | simonpj |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC HEAD regression: GADT constructors no longer quantify tyvars in topological order","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.5","keywords":["GADTs"],"differentials":[],"test_case":"","architecture":"","cc":["simonpj"],"type":"Bug","description":"Originally noticed in #14796. This program:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE ConstraintKinds #-}\r\n{-# LANGUAGE GADTs #-}\r\n{-# LANGUAGE TypeApplications #-}\r\nmodule Bug where\r\n\r\nimport Data.Kind\r\n\r\ndata ECC ctx f a where\r\n ECC :: ctx => f a -> ECC ctx f a\r\n\r\nf :: [()] -> ECC () [] ()\r\nf = ECC @() @[] @()\r\n}}}\r\n\r\nTypechecks in GHC 8.2.2 and 8.4.1, but not in GHC HEAD:\r\n\r\n{{{\r\n$ ~/Software/ghc2/inplace/bin/ghc-stage2 Bug.hs\r\n[1 of 1] Compiling Bug ( Bug.hs, Bug.o )\r\n\r\nBug.hs:12:5: error:\r\n • Couldn't match type ‘()’ with ‘[]’\r\n Expected type: [()] -> ECC (() :: Constraint) [] ()\r\n Actual type: () [] -> ECC (() :: Constraint) () []\r\n • In the expression: ECC @() @[] @()\r\n In an equation for ‘f’: f = ECC @() @[] @()\r\n |\r\n12 | f = ECC @() @[] @()\r\n | ^^^^^^^^^^^^^^^\r\n\r\nBug.hs:12:10: error:\r\n • Expected kind ‘* -> *’, but ‘()’ has kind ‘*’\r\n • In the type ‘()’\r\n In the expression: ECC @() @[] @()\r\n In an equation for ‘f’: f = ECC @() @[] @()\r\n |\r\n12 | f = ECC @() @[] @()\r\n | ^^\r\n\r\nBug.hs:12:14: error:\r\n • Expecting one more argument to ‘[]’\r\n Expected a type, but ‘[]’ has kind ‘* -> *’\r\n • In the type ‘[]’\r\n In the expression: ECC @() @[] @()\r\n In an equation for ‘f’: f = ECC @() @[] @()\r\n |\r\n12 | f = ECC @() @[] @()\r\n | ^^\r\n}}}\r\n\r\nThis is because the order of type variables for `ECC` has changed between GHC 8.4.1 and HEAD. In 8.4.1, it's\r\n\r\n{{{\r\n$ /opt/ghc/8.4.1/bin/ghci Bug.hs -XTypeApplications -fprint-explicit-foralls\r\nGHCi, version 8.4.0.20180209: http://www.haskell.org/ghc/ :? for help\r\nLoaded GHCi configuration from /home/rgscott/.ghci\r\n[1 of 1] Compiling Bug ( Bug.hs, interpreted )\r\nOk, one module loaded.\r\nλ> :type +v ECC\r\nECC\r\n :: forall (ctx :: Constraint) (f :: * -> *) a.\r\n ctx =>\r\n f a -> ECC ctx f a\r\n}}}\r\n\r\nIn GHC HEAD, however, it's:\r\n\r\n{{{\r\n$ ~/Software/ghc2/inplace/bin/ghc-stage2 --interactive Bug.hs -XTypeApplications -fprint-explicit-foralls\r\nGHCi, version 8.5.20180213: http://www.haskell.org/ghc/ :? for help\r\nLoaded GHCi configuration from /home/rgscott/.ghci\r\n[1 of 1] Compiling Bug ( Bug.hs, interpreted )\r\nOk, one module loaded.\r\nλ> :type +v ECC\r\nECC\r\n :: forall (f :: * -> *) a (ctx :: Constraint).\r\n ctx =>\r\n f a -> ECC ctx f a\r\n}}}\r\n\r\nThis regression was introduced in fa29df02a1b0b926afb2525a258172dcbf0ea460 (Refactor ConDecl: Trac #14529).","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Richard Eisenbergrae@richarde.devRichard Eisenbergrae@richarde.devhttps://gitlab.haskell.org/ghc/ghc/-/issues/15051-split-objs generates excessively many files on Windows2019-07-07T18:14:32Zkanetw-split-objs generates excessively many files on WindowsA BuildFlavour = perf build generated \~18k .S files for ghc-prim:GHC.Types, which caused it to basically get stuck compiling all those assembly files. Removing -split-objs (via SplitObjs = NO) significantly sped up compilation.
<detail...A BuildFlavour = perf build generated \~18k .S files for ghc-prim:GHC.Types, which caused it to basically get stuck compiling all those assembly files. Removing -split-objs (via SplitObjs = NO) significantly sped up compilation.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.2.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | x86_64 (amd64) |
</details>
<!-- {"blocked_by":[],"summary":"-split-objs generates excessively many files on Windows","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"x86_64 (amd64)","cc":[""],"type":"Bug","description":"A BuildFlavour = perf build generated ~18k .S files for ghc-prim:GHC.Types, which caused it to basically get stuck compiling all those assembly files. Removing -split-objs (via SplitObjs = NO) significantly sped up compilation.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Tamar ChristinaTamar Christinahttps://gitlab.haskell.org/ghc/ghc/-/issues/15061print022 testcase fails on i3862019-07-07T18:14:27ZBen Gamariprint022 testcase fails on i386CircleCI's i386 way is showing this failure of `print002` in the `ghci` way,
```
Actual stderr output differs from expected:
--- /dev/null 2018-04-18 16:05:23.479353000 +0000
+++ ./ghci.debugger/scripts/print022.run/print022.run.stderr....CircleCI's i386 way is showing this failure of `print002` in the `ghci` way,
```
Actual stderr output differs from expected:
--- /dev/null 2018-04-18 16:05:23.479353000 +0000
+++ ./ghci.debugger/scripts/print022.run/print022.run.stderr.normalised 2018-04-19 13:53:47.685662431 +0000
@@ -0,0 +1 @@
+*** Exception: Prelude.chr: bad argument: 1493110744
*** unexpected failure for print022(ghci)
```
This is a bit frightening as it suggests that there is memory unsafety here.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"print022 testcase fails on i386","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"CircleCI's i386 way is showing this failure of `print002` in the `ghci` way,\r\n{{{\r\nActual stderr output differs from expected:\r\n--- /dev/null\t2018-04-18 16:05:23.479353000 +0000\r\n+++ ./ghci.debugger/scripts/print022.run/print022.run.stderr.normalised\t2018-04-19 13:53:47.685662431 +0000\r\n@@ -0,0 +1 @@\r\n+*** Exception: Prelude.chr: bad argument: 1493110744\r\n*** unexpected failure for print022(ghci)\r\n}}}\r\n\r\nThis is a bit frightening as it suggests that there is memory unsafety here.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Ömer Sinan AğacanÖmer Sinan Ağacanhttps://gitlab.haskell.org/ghc/ghc/-/issues/15122GHC HEAD typechecker regression2019-07-07T18:14:10ZfmixingGHC HEAD typechecker regressionThis code, distilled from the `type-level-sets` library:
```hs
{-# LANGUAGE FlexibleInstances #-}
{-# LANGUAGE GADTs #-}
{-# LANGUAGE MultiParamTypeClasses #-}
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE TypeInType #-}
{-# LANGUAGE TypeO...This code, distilled from the `type-level-sets` library:
```hs
{-# LANGUAGE FlexibleInstances #-}
{-# LANGUAGE GADTs #-}
{-# LANGUAGE MultiParamTypeClasses #-}
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE TypeInType #-}
{-# LANGUAGE TypeOperators #-}
module Bug where
data Proxy (p :: k) = Proxy
data Set (n :: [k]) where
Empty :: Set '[]
Ext :: e -> Set s -> Set (e ': s)
type family (m :: [k]) :\ (x :: k) :: [k] where
'[] :\ x = '[]
(x ': xs) :\ x = xs
(y ': xs) :\ x = y ': (xs :\ x)
class Remove s t where
remove :: Set s -> Proxy t -> Set (s :\ t)
instance Remove '[] t where
remove Empty Proxy = Empty
instance {-# OVERLAPS #-} Remove (x ': xs) x where
remove (Ext _ xs) Proxy = xs
instance {-# OVERLAPPABLE #-} (((y : xs) :\ x) ~ (y : (xs :\ x)), Remove xs x)
=> Remove (y ': xs) x where
remove (Ext y xs) (x@Proxy) = Ext y (remove xs x)
```
Typechecks in GHC 8.4.2, but not in GHC HEAD:
```
$ /opt/ghc/head/bin/ghc Bug.hs
[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
Bug.hs:31:33: error:
• Could not deduce: ((e : s) :\ x) ~ (e : (s :\ x))
from the context: (((y : xs) :\ x) ~ (y : (xs :\ x)), Remove xs x)
bound by the instance declaration at Bug.hs:(29,31)-(30,27)
or from: (k ~ *, (y : xs :: [k]) ~~ (e : s :: [*]))
bound by a pattern with constructor:
Ext :: forall e (s :: [*]). e -> Set s -> Set (e : s),
in an equation for ‘remove’
at Bug.hs:31:11-18
Expected type: Set ((y : xs) :\ x)
Actual type: Set (e : (s :\ x))
• In the expression: Ext y (remove xs x)
In an equation for ‘remove’:
remove (Ext y xs) (x@Proxy) = Ext y (remove xs x)
In the instance declaration for ‘Remove (y : xs) x’
• Relevant bindings include
x :: Proxy x (bound at Bug.hs:31:22)
xs :: Set s (bound at Bug.hs:31:17)
y :: e (bound at Bug.hs:31:15)
remove :: Set (y : xs) -> Proxy x -> Set ((y : xs) :\ x)
(bound at Bug.hs:31:3)
|
31 | remove (Ext y xs) (x@Proxy) = Ext y (remove xs x)
| ^^^^^^^^^^^^^^^^^^^
```
This regression was introduced in commit e3dbb44f53b2f9403d20d84e27f187062755a089 (Fix #12919 by making the flattener homegeneous.).8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15136High CPU when asynchronous exception and unblocking retry on TVar raced2019-07-07T18:14:07ZnshimazaHigh CPU when asynchronous exception and unblocking retry on TVar racedDetail: https://github.com/nshimaza/race-tmvar-async-exception
Runtime falls into high CPU under racing condition between async exception and unblocking retry on TVar.
- Reproduces with +RTS -Nx where x \> 1
- Does NOT reproduce with +...Detail: https://github.com/nshimaza/race-tmvar-async-exception
Runtime falls into high CPU under racing condition between async exception and unblocking retry on TVar.
- Reproduces with +RTS -Nx where x \> 1
- Does NOT reproduce with +RTS -N1
- Program stalls at `killThread`
- High CPU based on given -Nx
- CPU won't be 100% if you gave x smaller than available hardware threads of your platform.
- Does NOT reproduce if TVar/retry is replaced by MVar
- Reproduced with GHC 8.4.2 (macOS High Sierra (10.13.4))
- Reproduced with GHC 8.4.2 (Docker for Mac Version 18.03.1-ce-mac65)
- Reproduced with ghc-8.5.20180506 (Docker for Mac Version 18.03.1-ce-mac65)
Minimal reproducing code here. (You can find more verbose code on the above github repo.)
```hs
main :: IO ()
main = do
let volume = 1000
forM_ [1..1000] $ \i -> do
putStrFlush $ show i ++ " "
-- Spawn massive number of threads.
threads <- replicateM volume $ do
trigger <- newTVarIO False
tid <- forkIO $ void $ atomically $ do
t <- readTVar trigger
if t then pure t else retry
pure (trigger, tid)
-- Make sure all threads are spawned.
threadDelay 30000
-- Let threads start to exit normally.
forkIO $ forM_ threads $ \(trigger, _) -> threadDelay 1 *> atomically (writeTVar trigger True)
-- Concurrently kill threads in order to create race.
-- TMVar operation and asynchronous exception can hit same thread simultaneously.
-- Adjust threadDelay if you don't reproduce very well.
threadDelay 1000
forM_ threads $ \(_, tid) -> do
putCharFlush 'A'
killThread tid -- When the issue reproduced, this killThread doesn't return.
putCharFlush '\b'
```
This program intentionally creates race condition between asynchronous exception
and unblocking operation of `retry` on TVar. From one side, a `writeTVar
trigger True` is attempted from external thread while target thread is blocking
at `retry` on the same `TVar`. On the other side, an asynchronous exception
`ThreadKilled` is thrown by yet another external thread to the same target
thread.
In other word, it attempts to kill a thread about to unblock.
I guess when the above two operation hit the same thread at the same time in
parallel in SMP environment, GHC runtime falls into high CPU.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 8.4.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"High CPU when asynchronous exception and unblocking retry on TVar raced","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Detail: https://github.com/nshimaza/race-tmvar-async-exception\r\n\r\nRuntime falls into high CPU under racing condition between async exception and unblocking retry on TVar.\r\n\r\n* Reproduces with +RTS -Nx where x > 1\r\n* Does NOT reproduce with +RTS -N1\r\n* Program stalls at `killThread`\r\n* High CPU based on given -Nx\r\n * CPU won't be 100% if you gave x smaller than available hardware threads of your platform.\r\n* Does NOT reproduce if TVar/retry is replaced by MVar\r\n* Reproduced with GHC 8.4.2 (macOS High Sierra (10.13.4))\r\n* Reproduced with GHC 8.4.2 (Docker for Mac Version 18.03.1-ce-mac65)\r\n* Reproduced with ghc-8.5.20180506 (Docker for Mac Version 18.03.1-ce-mac65)\r\n\r\n\r\nMinimal reproducing code here. (You can find more verbose code on the above github repo.)\r\n{{{#!hs\r\nmain :: IO ()\r\nmain = do\r\n let volume = 1000\r\n forM_ [1..1000] $ \\i -> do\r\n putStrFlush $ show i ++ \" \"\r\n\r\n -- Spawn massive number of threads.\r\n threads <- replicateM volume $ do\r\n trigger <- newTVarIO False\r\n tid <- forkIO $ void $ atomically $ do\r\n t <- readTVar trigger\r\n if t then pure t else retry\r\n pure (trigger, tid)\r\n\r\n -- Make sure all threads are spawned.\r\n threadDelay 30000\r\n\r\n -- Let threads start to exit normally.\r\n forkIO $ forM_ threads $ \\(trigger, _) -> threadDelay 1 *> atomically (writeTVar trigger True)\r\n\r\n -- Concurrently kill threads in order to create race.\r\n -- TMVar operation and asynchronous exception can hit same thread simultaneously.\r\n -- Adjust threadDelay if you don't reproduce very well.\r\n threadDelay 1000\r\n forM_ threads $ \\(_, tid) -> do\r\n putCharFlush 'A'\r\n killThread tid -- When the issue reproduced, this killThread doesn't return.\r\n putCharFlush '\\b'\r\n}}}\r\n\r\nThis program intentionally creates race condition between asynchronous exception\r\nand unblocking operation of `retry` on TVar. From one side, a `writeTVar\r\ntrigger True` is attempted from external thread while target thread is blocking\r\nat `retry` on the same `TVar`. On the other side, an asynchronous exception\r\n`ThreadKilled` is thrown by yet another external thread to the same target\r\nthread.\r\n\r\nIn other word, it attempts to kill a thread about to unblock.\r\n\r\nI guess when the above two operation hit the same thread at the same time in\r\nparallel in SMP environment, GHC runtime falls into high CPU.\r\n","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Ömer Sinan AğacanÖmer Sinan Ağacanhttps://gitlab.haskell.org/ghc/ghc/-/issues/15142GHC HEAD regression: tcTyVarDetails2019-07-07T18:14:05ZRyan ScottGHC HEAD regression: tcTyVarDetailsThis regression prevents the `generic-lens` library from building. Here is a minimized test case:
```hs
{-# LANGUAGE MultiParamTypeClasses #-}
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE TypeInType #-}
module Bug where
import Data.Kind
...This regression prevents the `generic-lens` library from building. Here is a minimized test case:
```hs
{-# LANGUAGE MultiParamTypeClasses #-}
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE TypeInType #-}
module Bug where
import Data.Kind
class ListTuple (tuple :: Type) (as :: [(k, Type)]) where
type ListToTuple as :: Type
```
On GHC 8.4.2, this compiles, but on GHC HEAD, it panics:
```
$ ~/Software/ghc/inplace/bin/ghc-stage2 Bug.hs[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
ghc-stage2: panic! (the 'impossible' happened)
(GHC version 8.5.20180511 for x86_64-unknown-linux):
tcTyVarDetails
co_aWx :: (k_aWt[tau:2] :: *) ~# (* :: *)
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/utils/Outputable.hs:1162:37 in ghc:Outputable
pprPanic, called at compiler/basicTypes/Var.hs:497:22 in ghc:Var
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 8.5 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | highest |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC HEAD regression: tcTyVarDetails","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.5","keywords":["TypeFamilies","TypeInType,"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"This regression prevents the `generic-lens` library from building. Here is a minimized test case:\r\n\r\n{{{#!hs\r\n{-# LANGUAGE MultiParamTypeClasses #-}\r\n{-# LANGUAGE TypeFamilies #-}\r\n{-# LANGUAGE TypeInType #-}\r\nmodule Bug where\r\n\r\nimport Data.Kind\r\n\r\nclass ListTuple (tuple :: Type) (as :: [(k, Type)]) where\r\n type ListToTuple as :: Type\r\n}}}\r\n\r\nOn GHC 8.4.2, this compiles, but on GHC HEAD, it panics:\r\n\r\n{{{\r\n$ ~/Software/ghc/inplace/bin/ghc-stage2 Bug.hs[1 of 1] Compiling Bug ( Bug.hs, Bug.o )\r\nghc-stage2: panic! (the 'impossible' happened)\r\n (GHC version 8.5.20180511 for x86_64-unknown-linux):\r\n tcTyVarDetails\r\n co_aWx :: (k_aWt[tau:2] :: *) ~# (* :: *)\r\n Call stack:\r\n CallStack (from HasCallStack):\r\n callStackDoc, called at compiler/utils/Outputable.hs:1162:37 in ghc:Outputable\r\n pprPanic, called at compiler/basicTypes/Var.hs:497:22 in ghc:Var\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1Richard Eisenbergrae@richarde.devRichard Eisenbergrae@richarde.devhttps://gitlab.haskell.org/ghc/ghc/-/issues/15154Segmentation fault of ghc-pkg.exe from 32-bit distribution of ghc-8.2.2 on Wi...2019-07-07T18:14:01Zki11men0wSegmentation fault of ghc-pkg.exe from 32-bit distribution of ghc-8.2.2 on Windows 7On `Windows 7` call of `ghc-pkg` utility from `32-bit` `ghc-8.2.2` distribution is always ended with `Segmentation fault` error.
With use of `Cygwin` the error can be reproduced this way: run `cmd.exe` and in the appeared console window...On `Windows 7` call of `ghc-pkg` utility from `32-bit` `ghc-8.2.2` distribution is always ended with `Segmentation fault` error.
With use of `Cygwin` the error can be reproduced this way: run `cmd.exe` and in the appeared console window execute the following commands
```bash
c:\Users\user.name\wrk> bash
$ mkdir ghc-pkg-check
$ cd ghc-pkg-check
$ curl https://downloads.haskell.org/~ghc/8.2.2/ghc-8.2.2-i386-unknown-mingw32.tar.xz > ghc-8.2.2-i386-unknown-mingw32.tar.xz
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 163M 100 163M 0 0 3669k 0 0:00:45 0:00:45 --:--:-- 4776k
$ xz -dc ghc-8.2.2-i386-unknown-mingw32.tar.xz | tar -xf -
$ cd ghc-8.2.2/bin/
$ ./ghc-pkg.exe --version
GHC package manager version 8.2.2
Segmentation fault
```
The error arises irrespective of how and with what arguments to call `ghc-pkg` utility. For example, firstly I has faced the problem using `stack` from Windows console:
```bat
> stack build --arch=i386 --resolver=11.9
```
I checked another distributions of GHC for presence of this bug on `Windows 7`. 64-bit version of ghc-8.2.2, 32-bit and 64-bit versions of ghc-8.0.2 and ghc-8.4.2 are free of the problem. I \*\*did not check\*\* the problem \*\*on another versions\*\* of MS Windows.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | ghc-pkg |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Segmentation fault of ghc-pkg.exe from 32-bit distribution of ghc-8.2.2 on Windows 7","status":"New","operating_system":"","component":"ghc-pkg","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"On `Windows 7` call of `ghc-pkg` utility from `32-bit` `ghc-8.2.2` distribution is always ended with `Segmentation fault` error.\r\n\r\nWith use of `Cygwin` the error can be reproduced this way: run `cmd.exe` and in the appeared console window execute the following commands\r\n{{{#!bash\r\nc:\\Users\\user.name\\wrk> bash\r\n$ mkdir ghc-pkg-check\r\n$ cd ghc-pkg-check\r\n$ curl https://downloads.haskell.org/~ghc/8.2.2/ghc-8.2.2-i386-unknown-mingw32.tar.xz > ghc-8.2.2-i386-unknown-mingw32.tar.xz\r\n % Total % Received % Xferd Average Speed Time Time Time Current\r\n Dload Upload Total Spent Left Speed\r\n100 163M 100 163M 0 0 3669k 0 0:00:45 0:00:45 --:--:-- 4776k\r\n\r\n$ xz -dc ghc-8.2.2-i386-unknown-mingw32.tar.xz | tar -xf -\r\n$ cd ghc-8.2.2/bin/\r\n$ ./ghc-pkg.exe --version\r\nGHC package manager version 8.2.2\r\nSegmentation fault\r\n}}}\r\n\r\nThe error arises irrespective of how and with what arguments to call `ghc-pkg` utility. For example, firstly I has faced the problem using `stack` from Windows console:\r\n{{{#!bat\r\n> stack build --arch=i386 --resolver=11.9\r\n}}}\r\n\r\nI checked another distributions of GHC for presence of this bug on `Windows 7`. 64-bit version of ghc-8.2.2, 32-bit and 64-bit versions of ghc-8.0.2 and ghc-8.4.2 are free of the problem. I **did not check** the problem **on another versions** of MS Windows.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15168GHC HEAD crashes on Windows 64 after the SRT overhaul (May 16, 2018 and newer)2019-07-07T18:13:57ZawsonGHC HEAD crashes on Windows 64 after the SRT overhaul (May 16, 2018 and newer)After the series of SRT overhaul patches GHC doesn't work on Windows 64-bit.
GHC executable crashes (AV) on any attempt to compile anything or even to start in interactive mode. When crashed it report crash address which may look not as...After the series of SRT overhaul patches GHC doesn't work on Windows 64-bit.
GHC executable crashes (AV) on any attempt to compile anything or even to start in interactive mode. When crashed it report crash address which may look not as a real address at all (e.g. 0x800 or 0xffffffffffffffff) and may report either reading from or executing such an address.
OTOH, when started with, e.g. `+RTS -A256m -RTS` it is able to compile some programs (`haddock` at least).
Reverting all related commits down to eb8e692cab7970c495681e14721d05ecadd21581 make things work again.
I have no proof that things went bad exactly at eb8e692cab7970c495681e14721d05ecadd21581. Perhaps, this happened later on, but I have a proof that things were good immediately before.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.5 |
| 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":"GHC HEAD crashes on Windows 64 after the SRT overhaul (May 16, 2018 and newer)","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.5","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"After the series of SRT overhaul patches GHC doesn't work on Windows 64-bit.\r\n\r\nGHC executable crashes (AV) on any attempt to compile anything or even to start in interactive mode. When crashed it report crash address which may look not as a real address at all (e.g. 0x800 or 0xffffffffffffffff) and may report either reading from or executing such an address.\r\n\r\nOTOH, when started with, e.g. `+RTS -A256m -RTS` it is able to compile some programs (`haddock` at least).\r\n\r\nReverting all related commits down to eb8e692cab7970c495681e14721d05ecadd21581 make things work again.\r\n\r\nI have no proof that things went bad exactly at eb8e692cab7970c495681e14721d05ecadd21581. Perhaps, this happened later on, but I have a proof that things were good immediately before.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15173Tests are failing with segfaults under CircleCI2019-07-07T18:13:56ZBen GamariTests are failing with segfaults under CircleCIIt seems something has regressed recently as `master` now fails to validate on CircleCI with some tests segfaulting. Namely,
```
T10508_api T6145 T8628 T8639_api T10052 T7478 parseTree comments listcomps literals T11430 dynCompileExpr p...It seems something has regressed recently as `master` now fails to validate on CircleCI with some tests segfaulting. Namely,
```
T10508_api T6145 T8628 T8639_api T10052 T7478 parseTree comments listcomps literals T11430 dynCompileExpr parsed
```
all in the `normal` way.
This may be due to the SRT rework.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.2.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Tests are failing with segfaults under CircleCI","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.2.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"It seems something has regressed recently as `master` now fails to validate on CircleCI with some tests segfaulting. Namely,\r\n{{{\r\nT10508_api T6145 T8628 T8639_api T10052 T7478 parseTree comments listcomps literals T11430 dynCompileExpr parsed\r\n}}}\r\nall in the `normal` way.\r\n\r\nThis may be due to the SRT rework.","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/15234WARNING in hptSomeThingsBelowUs when using a source plugin2019-07-07T18:13:41ZMatthew PickeringWARNING in hptSomeThingsBelowUs when using a source pluginWhen using a source plugin with a stage2 compiler built with the devel2 flavour, there are a fair few warnings about hptSomeThingsBelowUs.
```
WARNING in hptSomeThingsBelowUs
missing module CoercePlugin
Probable cause: out-of-date i...When using a source plugin with a stage2 compiler built with the devel2 flavour, there are a fair few warnings about hptSomeThingsBelowUs.
```
WARNING in hptSomeThingsBelowUs
missing module CoercePlugin
Probable cause: out-of-date interface files
```
I don't know if this just started happening or has been going on for a while. Is this warning cause for concern? Everything appears to work as expected despite this hiccup.
<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":"WARNING in hptSomeThingsBelowUs when using a source plugin","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"8.6.1","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.4.3","keywords":["SourcePlugins,","plugins"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When using a source plugin with a stage2 compiler built with the devel2 flavour, there are a fair few warnings about hptSomeThingsBelowUs.\r\n\r\n{{{\r\nWARNING in hptSomeThingsBelowUs\r\n missing module CoercePlugin\r\n Probable cause: out-of-date interface files\r\n}}}\r\n\r\nI don't know if this just started happening or has been going on for a while. Is this warning cause for concern? Everything appears to work as expected despite this hiccup. ","type_of_failure":"OtherFailure","blocking":[]} -->8.6.1