GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2024-03-05T18:56:32Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/24499Replace mentions of return with pure in the compiler2024-03-05T18:56:32ZJadeReplace mentions of return with pure in the compilerWith the existence of `-Wnoncanonical-monad-instances` in `-Wcompat` and plans to deprecate `return` at *some point* in the future, I would expect to be moving towards eliminating `return` from compiler internals and replacing its uses w...With the existence of `-Wnoncanonical-monad-instances` in `-Wcompat` and plans to deprecate `return` at *some point* in the future, I would expect to be moving towards eliminating `return` from compiler internals and replacing its uses with `pure`.
It's not as straightforward as using a regex-replace `s/return/pure` because of comments, pragmas and strings. I'm also not sure if this would introduce breakages, but I hope not; If so, the tests should catch that.https://gitlab.haskell.org/ghc/ghc/-/issues/24498Increase default virtual memory2024-03-06T03:46:54Zrecursion-ninjaIncrease default virtual memory## Summary
GHC's virtual memory limit is capped at 1TiB. This has caused some significant and critical breakages when running scientific computations on a highly parallel,share memory computing environment. The issue was briefly discuss...## Summary
GHC's virtual memory limit is capped at 1TiB. This has caused some significant and critical breakages when running scientific computations on a highly parallel,share memory computing environment. The issue was briefly discussed here:
https://discourse.haskell.org/t/application-memory-limit-1tb/8449/9
It would be greatly appreciated if the virtual memory limit for GHC-9.10.1 was increased to a larger value.
If I might make some suggestions,
1. `16TiB` limit would defer the problem for a couple of years.
2. `512TiB` limit would defer this problem for a couple of decades.
Either would be more than suitable to remedy our immediate needs, I leave the risk assessment of breakage versus the benefit of longer deferment in your capable hands.
## Steps to reproduce
Compile and execute a program which requires more than 1TiB of resident memory while running.
## Expected behavior
The program should not abort if the computing environment actually has more than 1TiB of memory.
## Environment
* GHC version used: **GHC-9.8.1, GHC-9.6.4**
* Operating System: **Linux**
* System Architecture: **x86_64**9.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/24496x86_64: FMA primop generates wrong result2024-03-05T03:31:10Zarata, mizukix86_64: FMA primop generates wrong result## Summary
On x86, FMA primop generates wrong result with `-mfma -O1`.
## Steps to reproduce
Compile the following code with `ghc -fforce-recomp -O1 -mfma TwoProdFMA.hs`:
```haskell
{-# LANGUAGE MagicHash #-}
{-# LANGUAGE UnboxedTupl...## Summary
On x86, FMA primop generates wrong result with `-mfma -O1`.
## Steps to reproduce
Compile the following code with `ghc -fforce-recomp -O1 -mfma TwoProdFMA.hs`:
```haskell
{-# LANGUAGE MagicHash #-}
{-# LANGUAGE UnboxedTuples #-}
import GHC.Exts
twoProductFloat# :: Float# -> Float# -> (# Float#, Float# #)
twoProductFloat# x y = let !r = x `timesFloat#` y
in (# r, fmsubFloat# x y r #)
{-# NOINLINE twoProductFloat# #-}
twoProductDouble# :: Double# -> Double# -> (# Double#, Double# #)
twoProductDouble# x y = let !r = x *## y
in (# r, fmsubDouble# x y r #)
{-# NOINLINE twoProductDouble# #-}
main :: IO ()
main = do
print $ case twoProductFloat# 2.0# 3.0# of (# r, s #) -> (F# r, F# s)
print $ case twoProductDouble# 2.0## 3.0## of (# r, s #) -> (D# r, D# s)
```
The result is wrong:
```
$ ghc -fforce-recomp -mfma -O1 TwoProdFMA.hs
$ ./TwoProdFMA
(6.0,-2.0)
(6.0,-2.0)
```
## Expected behavior
The expected result is:
```
(6.0,0.0)
(6.0,0.0)
```
## Environment
* GHC version used: 9.8.2, master (b4cae4ecc8ab207c8180242b8fc062464fc70157)
* Operating System: Linux
* System Architecture: x86-649.10.2Andreas KlebingerAndreas Klebingerhttps://gitlab.haskell.org/ghc/ghc/-/issues/24493Module name in `module Hello where` is missing in the hieAst2024-03-09T14:39:42ZPatrickModule name in `module Hello where` is missing in the hieAst## Summary
ModuleName identifier is missing in the hieAst
## Steps to reproduce
hello.hs
```
module Hello where
go = "1"
```
ghc hello.hs -fno-code -fwrite-ide-info -fvalidate-ide-info -ddump-hie -fforce-recomp > result.txt
```
[1 of...## Summary
ModuleName identifier is missing in the hieAst
## Steps to reproduce
hello.hs
```
module Hello where
go = "1"
```
ghc hello.hs -fno-code -fwrite-ide-info -fvalidate-ide-info -ddump-hie -fforce-recomp > result.txt
```
[1 of 1] Compiling Hello ( hello.hs, nothing )
==================== HIE AST ====================
File: hello.hs
Node@hello.hs:3:1-8: Source: From source
{(annotations: {(FunBind, HsBindLR), (Match, Match),
(Module, Module), (XHsBindsLR, HsBindLR)}),
(types: [0]), (identifier info: {})}
Node@hello.hs:3:1-2: Source: From source
{(annotations: {}), (types: []),
(identifier info: {(name Hello.go, Details: Just 0 {LHS of a match group,
regular value bound with scope: ModuleScope bound at: hello.hs:3:1-8})})}
Node@hello.hs:3:4-8: Source: From source
{(annotations: {(GRHS, GRHS)}), (types: []),
(identifier info: {})}
Node@hello.hs:3:6-8: Source: From source
{(annotations: {(HsLit, HsExpr)}), (types: [0]),
(identifier info: {})}
```
## Expected behavior
Expect to get a node with an identifier moduleName `Hello`.
## Use case
The use case of this is in haskell language server when computing semantic tokens,
we are giving semantic token type to the identifier from the hieAst to enable
semantic highlighting.
Missing moduleName `Hello` introduce inconsistency when we generate semantic token type for module name.
See relevant discussion in https://github.com/haskell/haskell-language-server/discussions/4055#discussioncomment-85832909.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/24492nonmovingTidyWeaks segfaults if w->key is static data2024-03-06T18:39:19ZTeo CamarasunonmovingTidyWeaks segfaults if w->key is static data## Summary
`nonmovingTidyWeaks` has the following line:
https://gitlab.haskell.org/ghc/ghc/-/blob/d3a050d2a1eac0244f989badb3a2c75c84e0a160/rts/sm/NonMovingMark.c?page=3#L2014
```c
bool key_in_nonmoving = Bdescr((StgPtr) w->key)->flags &...## Summary
`nonmovingTidyWeaks` has the following line:
https://gitlab.haskell.org/ghc/ghc/-/blob/d3a050d2a1eac0244f989badb3a2c75c84e0a160/rts/sm/NonMovingMark.c?page=3#L2014
```c
bool key_in_nonmoving = Bdescr((StgPtr) w->key)->flags & BF_NONMOVING;
```
Here we check if the block descriptor of the key puts it in the nonmoving heap.
But if `w->key` is static data and lives in the executables .data section, we may get a segfault trying to look up the `Bdescr`.
I saw segfaults when testing my WIP branch for https://gitlab.haskell.org/ghc/ghc/-/issues/24150 using the `nonmoving_thr` way when running the GcStaticPointers test. I checked and it also happens with `master` but not with my boot compiler which is `ghc-9.6.2`.
## Steps to reproduce
Run the `GcStaticPointers` in the `nonmoving_thr` way.
I am using the `release+debug_info` flavour but I'm not sure if that's relevant.
It will segfault with this backtrace:
```
Thread 7 "nonmoving-mark" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffdffff6c0 (LWP 2028996)]
0x00000000004996ac in nonmovingTidyWeaks (queue=queue@entry=0x7fffb8000bc0) at rts/sm/NonMovingMark.c:2015
2015 if (!key_in_nonmoving || nonmovingIsNowAlive(w->key)) {
(gdb) bt
#0 0x00000000004996ac in nonmovingTidyWeaks (queue=queue@entry=0x7fffb8000bc0) at rts/sm/NonMovingMark.c:2015
#1 0x0000000000495cb5 in nonmovingMarkThreadsWeaks (mark_queue=0x7fffb8000bc0, budget=0x7fffdfffee70) at rts/sm/NonMoving.c:870
#2 nonmovingMark_ (mark_queue=mark_queue@entry=0x7fffb8000bc0, dead_weaks=dead_weaks@entry=0x7fffdfffeeb8, resurrected_threads=resurrected_threads@entry=0x7fffdfffeec0,
concurrent=concurrent@entry=true) at rts/sm/NonMoving.c:1077
#3 0x000000000049607d in nonmovingConcurrentMarkWorker (data=<optimized out>) at rts/sm/NonMoving.c:933
#4 nonmovingConcurrentMarkWorker (data=<optimized out>) at rts/sm/NonMoving.c:910
#5 0x00007ffff7cdee64 in start_thread () from /nix/store/9v5d40jyvmwgnq1nj8f19ji2rcc5dksd-glibc-2.37-45/lib/libc.so.6
#6 0x00007ffff7d609f0 in clone3 () from /nix/store/9v5d40jyvmwgnq1nj8f19ji2rcc5dksd-glibc-2.37-45/lib/libc.so.6
(gdb) p *w
$1 = {header = {info = 0x4a9810 <stg_WEAK_info>}, cfinalizers = 0x5101c8, key = 0x502570, value = 0x502570, finalizer = 0x502620, link = 0x4201868408}
(gdb) p Bdescr(w->key)
800
52688 18624 39240$2 = (bdescr *) 0x500080
```
And note that the address lies in the .data section of the executable.
## Expected behavior
Not segfault.
## Environment
* GHC version used: 9.9.20240221https://gitlab.haskell.org/ghc/ghc/-/issues/24490libraries/base/tests/AtomicModifyIORef is quite slow with N>12024-03-01T02:57:24ZTeo Camarasulibraries/base/tests/AtomicModifyIORef is quite slow with N>1This test case seems to be quite slow for me.
It spins up `10` threads and for each one it increments an IORef `10,000,000` times.
This takes 6 seconds to run on my computer with `-N1`. But once we introduce contention by setting at lea...This test case seems to be quite slow for me.
It spins up `10` threads and for each one it increments an IORef `10,000,000` times.
This takes 6 seconds to run on my computer with `-N1`. But once we introduce contention by setting at least `-N2`, it slows down a lot and runs in the order of minutes(!). Perhaps this is partly some sort of CPU thing. I imagine some CPUs will be better at this than others.
Maybe we can remove a few zeros from the increment count?
I noticed this while running some tests with the `nonmoving_thr` way, but it looks like this is just the case whenever we have multiple capabilities.https://gitlab.haskell.org/ghc/ghc/-/issues/24489In-scope assertion failure with unpacking + existential2024-02-29T09:14:25ZKrzysztof GogolewskiIn-scope assertion failure with unpacking + existentialCompiling `ghc -O M` causes an assertion failure in master (when assertions are enabled).
```hs
{-# LANGUAGE GADTs #-}
module A where
data Term where
BinaryTerm :: (Show tag) => {-# UNPACK #-} !Bool -> !tag -> Term
f :: Term -> Stri...Compiling `ghc -O M` causes an assertion failure in master (when assertions are enabled).
```hs
{-# LANGUAGE GADTs #-}
module A where
data Term where
BinaryTerm :: (Show tag) => {-# UNPACK #-} !Bool -> !tag -> Term
f :: Term -> String
f (BinaryTerm _ tag) = show tag
```
```
GHC version 9.9.20240217:
ASSERT failed!
in_scope InScope {}
tenv [X0 :-> tag_aEr]
tenvFVs {tag_aEr}
cenv []
cenvFVs {}
tys [(# (# #) | (# #) #)]
cos []
Call stack:
CallStack (from HasCallStack):
assertPpr, called at compiler/GHC/Core/TyCo/Subst.hs:686:5 in ghc-9.9-inplace:GHC.Core.TyCo.Subst
checkValidSubst, called at compiler/GHC/Core/TyCo/Subst.hs:718:29 in ghc-9.9-inplace:GHC.Core.TyCo.Subst
substTy, called at compiler/GHC/Types/Id/Make.hs:1407:59 in ghc-9.9-inplace:GHC.Types.Id.Make
CallStack (from HasCallStack):
panic, called at compiler/GHC/Utils/Error.hs:507:29 in ghc-9.9-inplace:GHC.Utils.Error
```
Reproduced using commit a75694958de. I found it when investigating #24463 but it should be independent.Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/24484Haddocks for base-4.19 has broken source links to ghc-prim2024-02-27T13:54:59ZAndreas AbelHaddocks for base-4.19 has broken source links to ghc-primWhen clicking on "Source" for `Symbol` here (1.) we get to a non-existing page (2.):
1. https://hackage.haskell.org/package/base-4.19.1.0/docs/GHC-TypeLits.html#t:Symbol
2. https://hackage.haskell.org/package/ghc-prim-0.11.0-dca4/docs/sr...When clicking on "Source" for `Symbol` here (1.) we get to a non-existing page (2.):
1. https://hackage.haskell.org/package/base-4.19.1.0/docs/GHC-TypeLits.html#t:Symbol
2. https://hackage.haskell.org/package/ghc-prim-0.11.0-dca4/docs/src/GHC.Types.html#Symbol
Note the somewhat fishy hash part `-dca4` in the link to `ghc-prim`.
When I remove this part, I get to the correct location:
- https://hackage.haskell.org/package/ghc-prim-0.11.0/docs/src/GHC.Types.html#Symbol
So I looks like the documentation for `base` uploaded with GHC 9.8.2 has been incorrectly generated.
The same problem exists for base-4.19.0.0:
1. https://hackage.haskell.org/package/base-4.19.0.0/docs/GHC-Exts.html#t:Symbol
2. https://hackage.haskell.org/package/ghc-prim-0.11.0-997e/docs/src/GHC.Types.html#Symbol
Maybe it is a bug in the tooling (`haddock`).
But a script could be run on the generated documentation to remove the stray hashes before uploading the docs to hackage...
This seems to be a new problem, base-4.18 does not suffer from it:
1. https://hackage.haskell.org/package/base-4.18.0.0/docs/GHC-Exts.html#t:Symbol
2. https://hackage.haskell.org/package/ghc-prim-0.10.0/docs/src/GHC.Types.html#Symbolhttps://gitlab.haskell.org/ghc/ghc/-/issues/24482Wrong release date for GHC 9.8.22024-02-26T09:21:08ZbitWrong release date for GHC 9.8.2The GHC 9.8.2 download page is located here: https://www.haskell.org/ghc/download_ghc_9_8_2.html
1. The release date in the heading is wrong. It says "released 23rd Feb 2023" but it should be "released 23rd Feb 2024".
2. The link URL f...The GHC 9.8.2 download page is located here: https://www.haskell.org/ghc/download_ghc_9_8_2.html
1. The release date in the heading is wrong. It says "released 23rd Feb 2023" but it should be "released 23rd Feb 2024".
2. The link URL for "Release Notes" is wrong. It links to the 9.8.1 release notes. It should link to the 9.8.2 release notes.
3. A bit unrelated: I noticed that there is a typo in the release date of GHC 8.10.4: https://www.haskell.org/ghc/download_ghc_8_10_4.html It says "Februrary" but it should be "February".
Thank youhttps://gitlab.haskell.org/ghc/ghc/-/issues/24479GHC.Wasm.Prim is only exposed via `ghc-internal`2024-02-25T00:12:10ZBen GamariGHC.Wasm.Prim is only exposed via `ghc-internal`In b89970800c16b287f46e4267de0622ea40bb8c17 @TerrorJack added documentation which suggests that `GHC.Wasm.Prim` is intended for use by end-users despite being available only from `ghc-internal`. This would be in violation of our agreemen...In b89970800c16b287f46e4267de0622ea40bb8c17 @TerrorJack added documentation which suggests that `GHC.Wasm.Prim` is intended for use by end-users despite being available only from `ghc-internal`. This would be in violation of our agreement with the CLC which stipulates that we shall not expect users to rely on things being exposed from `ghc-internal`. Instead, `GHC.Wasm.Prim` should be exposed either from `ghc-experimental` or `base`.Cheng ShaoCheng Shaohttps://gitlab.haskell.org/ghc/ghc/-/issues/24476Properly align cyclic module error2024-02-25T00:10:49ZJadeProperly align cyclic module errorThe "Module graph contains a cycle" error does some aligning to make it easier to parse what modules form a cyclic dependency. The first module is awkwardly misaligned, making it harder to parse what actually is happening:
```
Module gra...The "Module graph contains a cycle" error does some aligning to make it easier to parse what modules form a cyclic dependency. The first module is awkwardly misaligned, making it harder to parse what actually is happening:
```
Module graph contains a cycle:
module ‘Foo’ (Foo.hs)
imports module ‘Bar’ (Bar.hs)
which imports module ‘Baz’ (Baz.hs)
which imports module ‘Foo’ (Foo.hs)
```
I propose adding 8 spaces of indentation to the first item which aligns all the modules:
```
Module graph contains a cycle:
module ‘Foo’ (Foo.hs)
imports module ‘Bar’ (Bar.hs)
which imports module ‘Baz’ (Baz.hs)
which imports module ‘Foo’ (Foo.hs)
```JadeJadehttps://gitlab.haskell.org/ghc/ghc/-/issues/24465Man page missing from bindists2024-03-01T16:51:46ZBryan Rbryan@haskell.foundationMan page missing from bindistsAs noted at https://github.com/haskell/ghcup-hs/issues/990#issuecomment-1957326918
I can confirm there is a man page in ghc-9.8.1-x86_64-fedora33-linux.tar.lz, but **not** in ghc-9.8.1-x86_64-rocky8-linux.tar.lz.As noted at https://github.com/haskell/ghcup-hs/issues/990#issuecomment-1957326918
I can confirm there is a man page in ghc-9.8.1-x86_64-fedora33-linux.tar.lz, but **not** in ghc-9.8.1-x86_64-rocky8-linux.tar.lz.Matthew PickeringMatthew Pickeringhttps://gitlab.haskell.org/ghc/ghc/-/issues/24461Don't warn about an inaccessible `undefined`2024-02-22T11:21:39ZAndreas AbelDon't warn about an inaccessible `undefined`This is the "Hello world!" of dependent types (safe indexing) in GHC:
```haskell
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE GADTs #-}
data Nat where
Zero :: Nat
Suc :: Nat -> Nat
data Vec a n where
Nil :: Vec a Zero
Cons :: a -> ...This is the "Hello world!" of dependent types (safe indexing) in GHC:
```haskell
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE GADTs #-}
data Nat where
Zero :: Nat
Suc :: Nat -> Nat
data Vec a n where
Nil :: Vec a Zero
Cons :: a -> Vec a n -> Vec a (Suc n)
data Fin n where
FZero :: Fin (Suc n)
FSuc :: Fin n -> Fin (Suc n)
look :: Vec a n -> Fin n -> a
look (Cons x xs) FZero = x
look (Cons x xs) (FSuc i) = look xs i
look !_ !_ = undefined
```
The last clause indicates that the pattern matching is complete. Without it, I get an `incomplete-patterns` warning.
However, with it, I get:
```
warning: [-Woverlapping-patterns]
Pattern match has inaccessible right hand side
In an equation for ‘look’: look !_ !_ = ...
|
25 | look !_ !_ = undefined
| ^^^^^^^^^^^^^^^^^^^^^^
```
It would be nice if exception raisers like `undefined` or `error` as rhs would silence this warning.
I mean, the user indicates with a `undefined` rhs their awareness that this case is impossible.
The alternative would be a special syntax that allows to omit the rhs altogether in contradictory cases. (That's what Agda's absurd clauses do.) However, detecting `undefined` might be less invasive to the language.https://gitlab.haskell.org/ghc/ghc/-/issues/24456Exception when reading interface files2024-02-27T15:58:39ZArtin Ghasivandghasivand.artin@gmail.comException when reading interface files![Screenshot 2024-02-20 at 11.46.15 at night.jpg](/uploads/f360bec23daa21e30789471dc10459aa/Screenshot_2024-02-20_at_11.46.15_at_night.jpg)
I did a `cabal build` in one of my projects, and then I encountered this error. `cabal clean && ...![Screenshot 2024-02-20 at 11.46.15 at night.jpg](/uploads/f360bec23daa21e30789471dc10459aa/Screenshot_2024-02-20_at_11.46.15_at_night.jpg)
I did a `cabal build` in one of my projects, and then I encountered this error. `cabal clean && cabal build` fixed the issue.
GHC version: 9.8.1
Operating System: macOS 14.3.1
System Architecture: Armhttps://gitlab.haskell.org/ghc/ghc/-/issues/24449T23540 is fragile on i3862024-03-25T19:13:15ZCheng ShaoT23540 is fragile on i386Over the past few weeks, T23540 has been fragile on i386, failing on multiple MRs and relevant marge pipelines. An incomplete list of victims:
- https://gitlab.haskell.org/ghc/ghc/-/merge_requests/11530
- https://gitlab.haskell.org/ghc/...Over the past few weeks, T23540 has been fragile on i386, failing on multiple MRs and relevant marge pipelines. An incomplete list of victims:
- https://gitlab.haskell.org/ghc/ghc/-/merge_requests/11530
- https://gitlab.haskell.org/ghc/ghc/-/merge_requests/11973
- https://gitlab.haskell.org/ghc/ghc/-/merge_requests/11983
It is unclear at this point why T23540 worked on i386 in the past but starts failing only on i386 when you change some ghc frontend internals. It may be related to the unique fragility again (another instance of #24261), and while 615eb855416ce536e02ed935ecc5a6f25519ae16 was sufficient to prevent T23540 regression on !11530 !11973, it wasn't sufficient to prevent the error from surfacing in !11983.
This issue tracks the T23540 fragility on i386. To avoid blocking work on other fronts, while we look into it further, I'll land a patch that marks it fragile.https://gitlab.haskell.org/ghc/ghc/-/issues/24445Programs built with certain ghc flags, and run with certain RTS flags segfaul...2024-02-21T13:53:40ZAndreas KlebingerPrograms built with certain ghc flags, and run with certain RTS flags segfault immediately on startup.
## Steps to reproduce
```
echo "main = print 42" >> HelloWorld.hs
/opt/ghc-9.8.1/bin/ghc HelloWorld.hs -O -debug -threaded -rtsopts
./HelloWorld +RTS -N2 -l -Ds
Segmentation fault (core dumped)
```
## Environment
* GHC version used:...
## Steps to reproduce
```
echo "main = print 42" >> HelloWorld.hs
/opt/ghc-9.8.1/bin/ghc HelloWorld.hs -O -debug -threaded -rtsopts
./HelloWorld +RTS -N2 -l -Ds
Segmentation fault (core dumped)
```
## Environment
* GHC version used: 9.8/HEAD, works in 9.6
Optional:
* Operating System:
* System Architecture:Andreas KlebingerAndreas Klebingerhttps://gitlab.haskell.org/ghc/ghc/-/issues/24435Out of range index error when bytecode generation with profiled interpreter2024-02-15T17:10:39ZIan-Woo KimOut of range index error when bytecode generation with profiled interpreter## Summary
When using profiled_ghc flavoured GHC for a repl session for a big private project, I encountered this out of array index error when interpreting some modules:
```
ghci> :load (...)
[... of ...] Compiling ... ( src/....hs, in...## Summary
When using profiled_ghc flavoured GHC for a repl session for a big private project, I encountered this out of array index error when interpreting some modules:
```
ghci> :load (...)
[... of ...] Compiling ... ( src/....hs, interpreted )
<no location info>: error:
Ix{Int}.index: Index (52) out of range ((0,39))
```
Fortunately, I could patch `indexError` to show the stack trace in profiled mode:
```
<no location info>: error:
Ix{Int}.index: Index (52) out of range ((0,39))
CallStack (from HasCallStack):
error, called at libraries/base/src/GHC/Ix.hs:169:5 in base:GHC.Ix
CallStack (from -prof):
GHC.Stack.CCS.currentCallStack1 (<no location info>)
GHC.Stack.CCS.currentCallStack (libraries/base/src/GHC/Stack/CCS.hsc:126:1-16)
GHC.Exception.errorCallWithCallStackException (libraries/base/src/GHC/Exception.hs:102:1-31)
GHC.Err.error (libraries/base/src/GHC/Err.hs:36:1-5)
GHC.Ix.$w$sindexError (libraries/base/src/GHC/Ix.hs:168:1-10)
GHC.StgToByteCode.lvl295 (<no location info>)
GHC.StgToByteCode.schemeER_wrk (compiler/GHC/StgToByteCode.hs:(387,1)-(409,40))
GHC.StgToByteCode.thenBc (compiler/GHC/StgToByteCode.hs:(2210,1)-(2214,17))
GHC.StgToByteCode.$fApplicativeBcM7 (<no location info>)
GHC.StgToByteCode.schemeR_wrk (compiler/GHC/StgToByteCode.hs:(358,1)-(382,60))
GHC.StgToByteCode.schemeR (compiler/GHC/StgToByteCode.hs:(341,1)-(342,41))
GHC.StgToByteCode.$wschemeR (compiler/GHC/StgToByteCode.hs:341:1-7)
GHC.StgToByteCode.schemeTopBind (compiler/GHC/StgToByteCode.hs:(306,1)-(322,55))
GHC.StgToByteCode.c (<no location info>)
GHC.StgToByteCode.go11 (<no location info>)
GHC.StgToByteCode.runBc (compiler/GHC/StgToByteCode.hs:(2206,1)-(2207,63))
GHC.Utils.Error.$w$swithTiming' (<no location info>)
GHC.StgToByteCode.byteCodeGen (compiler/GHC/StgToByteCode.hs:(105,1)-(150,38))
GHC.StgToByteCode.byteCodeGen1 (<no location info>)
GHC.Driver.Main.hscInteractive (compiler/GHC/Driver/Main.hs:(1963,1)-(2004,49))
GHC.Driver.Main.generateByteCode2 (<no location info>)
GHC.Driver.Main.generateByteCode (compiler/GHC/Driver/Main.hs:(2010,1)-(2020,32))
GHC.Driver.Main.generateByteCode1 (<no location info>)
GHC.Driver.Main.generateFreshByteCode (compiler/GHC/Driver/Main.hs:(2027,1)-(2031,17))
GHC.Driver.Main.generateFreshByteCode1 (<no location info>)
GHC.Driver.Pipeline.Execute.$wrunHscBackendPhase (<no location info>)
GHC.Driver.Pipeline.Execute.runHscBackendPhase1 (<no location info>)
GHC.Driver.Pipeline.Execute.runPhase1 (<no location info>)
GHC.Driver.Pipeline.$w$shscGenBackendPipeline (<no location info>)
GHC.Driver.Pipeline.fullPipeline2 (<no location info>)
GHC.Driver.Pipeline.$w$shscPipeline (<no location info>)
GHC.Driver.Pipeline.$wcompileOne' (<no location info>)
GHC.Driver.Make.upsweep_mod (compiler/GHC/Driver/Make.hs:(1303,1)-(1315,12))
GHC.Driver.Make.executeCompileNode.\ (compiler/GHC/Driver/Make.hs:(2518,81)-(2531,16))
GHC.Driver.Make.withLoggerHsc.\ (compiler/GHC/Driver/Make.hs:(2481,35)-(2485,17))
GHC.Driver.Make.runSeqPipelines.env.\ (compiler/GHC/Driver/Make.hs:2871:44-47)
GHC.Driver.Make.runSeqPipelines.env (compiler/GHC/Driver/Make.hs:(2870,7)-(2875,21))
GHC.Driver.Make.lvl83 (<no location info>)
GHC.Driver.Make.withLoggerHsc (compiler/GHC/Driver/Make.hs:(2480,1)-(2485,17))
GHC.Driver.Make.executeCompileNode (compiler/GHC/Driver/Make.hs:(2515,1)-(2540,35))
GHC.Driver.Make.interpretBuildPlan.buildSingleModule.build_action (compiler/GHC/Driver/Make.hs:(1137,11)-(1161,42))
GHC.Driver.Make.interpretBuildPlan.buildSingleModule (compiler/GHC/Driver/Make.hs:(1127,5)-(1167,49))
GHC.Driver.Make.interpretBuildPlan.buildLoop (compiler/GHC/Driver/Make.hs:(1103,5)-(1121,50))
GHC.Driver.Make.interpretBuildPlan (compiler/GHC/Driver/Make.hs:(1085,1)-(1240,73))
GHC.Driver.Make.withLocalTmpFS.\ (compiler/GHC/Driver/Make.hs:2949:54-101)
Control.Monad.Catch.$fMonadMaskMaybeT_$cgeneralBracket (libraries/exceptions/src/Control/Monad/Catch.hs:659:3-16)
GHC.Driver.Make.withLocalTmpFS (compiler/GHC/Driver/Make.hs:(2938,1)-(2949,101))
GHC.Driver.Make.runLoop.run_pipeline (compiler/GHC/Driver/Make.hs:2980:7-51)
GHC.Driver.Make.runLoop.\ (compiler/GHC/Driver/Make.hs:(2972,30)-(2975,33))
GHC.Driver.Make.runAllPipelines.spawn_actions.\.\ (compiler/GHC/Driver/Make.hs:2957:78-86)
GHC.Driver.Make.runLoop (compiler/GHC/Driver/Make.hs:(2969,1)-(2980,51))
GHC.Driver.Make.$srunLoop (<no location info>)
GHC.Driver.Make.runAllPipelines.spawn_actions.\ (compiler/GHC/Driver/Make.hs:2957:55-96)
GHC.Driver.Make.runAllPipelines.spawn_actions (compiler/GHC/Driver/Make.hs:(2956,7)-(2958,46))
GHC.Driver.Make.runAllPipelines (compiler/GHC/Driver/Make.hs:(2953,1)-(2964,29))
GHC.Driver.Make.runAllPipelines (<no location info>)
GHC.Driver.Make.runSeqPipelines (compiler/GHC/Driver/Make.hs:(2869,1)-(2876,61))
GHC.Driver.Make.runPipelines (compiler/GHC/Driver/Make.hs:(2862,1)-(2866,79))
GHC.Driver.Make.upsweep (compiler/GHC/Driver/Make.hs:(1256,1)-(1272,42))
Control.Monad.IO.Class.liftIO (libraries/base/src/Control/Monad/IO/Class.hs:66:5-25)
GHCi.UI.Monad.$fApplicativeGHCi4 (<no location info>)
GHC.Base.<*> (libraries/base/src/GHC/Base.hs:841:5-37)
GHC.Driver.Make.load' (compiler/GHC/Driver/Make.hs:(690,1)-(781,31))
GHC.Driver.Make.load' (compiler/GHC/Driver/Make.hs:690:1-5)
GHCi.UI.Monad.$fMonadGHCi2 (<no location info>)
GHC.Driver.Make.loadWithCache (compiler/GHC/Driver/Make.hs:(494,1)-(500,51))
GHC.Driver.Make.loadWithCache (compiler/GHC/Driver/Make.hs:494:1-13)
GHCi.UI.$strySuccess (<no location info>)
GHCi.UI.lvl819 (<no location info>)
Control.Monad.Catch.$w$cgeneralBracket1 (<no location info>)
Control.Monad.Catch.$fMonadMaskIO1 (<no location info>)
Control.Monad.Catch.$fMonadMaskReaderT1 (<no location info>)
GHC.Driver.Monad.$fMonadMaskGhc1 (<no location info>)
Control.Monad.Catch.generalBracket (libraries/exceptions/src/Control/Monad/Catch.hs:(342,3)-(350,15))
Control.Monad.Catch.bracket (libraries/exceptions/src/Control/Monad/Catch.hs:890:1-7)
Control.Monad.Catch.finally (libraries/exceptions/src/Control/Monad/Catch.hs:902:1-7)
GHC.withCleanupSession (compiler/GHC.hs:(531,1)-(542,51))
GHC.Driver.Monad.$fMonadGhc_$s$fMonadReaderT_$c>>= (<no location info>)
GHC.Base.>>= (libraries/base/src/GHC/Base.hs:1031:5-55)
GHC.Utils.Panic.withSignalHandlers (compiler/GHC/Utils/Panic.hs:241:1-18)
GHC.runGhc (compiler/GHC.hs:(506,1)-(511,26))
GHC.runGhc1 (<no location info>)
Main.main2 (<no location info>)
GHC.IO.catch1 (<no location info>)
Control.Monad.Catch.$fMonadCatchIO1 (<no location info>)
Control.Monad.Catch.catch (libraries/exceptions/src/Control/Monad/Catch.hs:201:3-66)
GHC.defaultErrorHandler (compiler/GHC.hs:(443,1)-(478,7))
GHC.$wdefaultErrorHandler (compiler/GHC.hs:443:1-19)
Main.main1 (<no location info>)
GHC.TopHandler.runMainIO1 (<no location info>)
Main.main3 (<no location info>)
Main.main (ghc/Main.hs:117:1-4)
```
so the bug is here: GHC.StgToByteCode.schemeER_wrk (compiler/GHC/StgToByteCode.hs:(387,1)-(409,40))
https://gitlab.haskell.org/wavewave/ghc/-/blob/T24435/compiler/GHC/StgToByteCode.hs?ref_type=heads#L405
`tick_no` is out of range.
## Environment
* GHC version used: a custom GHC for prof+dyn flavour (i.e `--flavour=perf+profiled_ghc` ). https://gitlab.haskell.org/wavewave/ghc/-/tree/wavewave/ghc_p_dyn?ref_type=heads
it's based on GHC 9.9.20240131
* Operating System: macOS 14.3, Ubuntu 23.10
* System Architecture: Apple M1 Max, x86_64 linuxhttps://gitlab.haskell.org/ghc/ghc/-/issues/24428Check that GHC.Types.Builtin.Names builds unique Uniques2024-02-13T15:33:51ZSebastian GrafCheck that GHC.Types.Builtin.Names builds unique UniquesI was wary of duplicate occurrences of the same decimal number in GHC.Types.Builtin.Names, so I let ChatGPT help me in defining the following useful `awk` script:
```sh
$ awk '{
# Iterate over each field
for (i=1; i<=NF; i++) {
...I was wary of duplicate occurrences of the same decimal number in GHC.Types.Builtin.Names, so I let ChatGPT help me in defining the following useful `awk` script:
```sh
$ awk '{
# Iterate over each field
for (i=1; i<=NF; i++) {
# If the field is a decimal number, add it to the count
if ($i ~ /^[0-9]+$/) {
count[$(i-1)][$i]++
}
}
}
END {
# Print the decimal numbers and their counts
for (s in count) {
for (num in count[s]) {
if (count[s][num] > 1) { print s, num, count[s][num] }
}
}
}' compiler/GHC/Builtin/Names.hs
```
This will print out duplicate calls of the the form `mkPreludeMiscIdUnique 135`, e.g.,
```
mkPreludeMiscIdUnique 135 2
```
The last number is the number of occurrences. Perhaps that's helpful to someone or even worth a test in CI.https://gitlab.haskell.org/ghc/ghc/-/issues/24423Sporadic segfaults at pustCostCentre with prof+dyn GHC2024-02-28T00:32:14ZIan-Woo KimSporadic segfaults at pustCostCentre with prof+dyn GHC## Summary
On an experimental branch: https://gitlab.haskell.org/wavewave/ghc/-/tree/wavewave/ghc_p_dyn?ref_type=heads (both GHC and Cabal modified)
I am testing `profiled_ghc` flavour without `no_dynamic_ghc`, i.e. GHC with `p_dyn` fl...## Summary
On an experimental branch: https://gitlab.haskell.org/wavewave/ghc/-/tree/wavewave/ghc_p_dyn?ref_type=heads (both GHC and Cabal modified)
I am testing `profiled_ghc` flavour without `no_dynamic_ghc`, i.e. GHC with `p_dyn` flavour. and it was successful in building a private mega-project.
But sometimes, sporadically, segfaults happened with the following backtrace (from macOS diagnostics report). Until now, I experienced this only with `-j` option on, so it's probably a concurrency bug.
Note: The change made in the experimental branch is mainly about building and linking, and RTS is as is except GHC built with both profiling and dynamic on.
```
...
Thread 13 Crashed:: ghc_worker
0 ??? 0x103a7186c pushCostCentre + 56
1 ??? 0x103a7c8b4 schedule + 1164
2 ??? 0x103a7c8b4 schedule + 1164
3 libsystem_pthread.dylib 0x18be2ce3c thread_start + 8
...
Thread 13 crashed with ARM Thread State (64-bit):
x0: 0x00000070c576f800 x1: 0x000000010c0b74e0 x2: 0x0000007130520120 x3: 0x0000000000000000
x4: 0x0000000000000000 x5: 0x00000000000000a0 x6: 0x0000000000000000 x7: 0x0000007026f1e888
x8: 0x0000000000617265 x9: 0x0000000000000000 x10: 0x000000000000000a x11: 0x0000000000000000
x12: 0x0000000000000000 x13: 0x0000000000000000 x14: 0x0000000000000000 x15: 0x0000007026f1e9a2
x16: 0x0000000103a71834 x17: 0x000000010c0b74e0 x18: 0x0000000000000000 x19: 0x000000010c0b74e0
x20: 0x0000007115499e10 x21: 0x00000070c576f800 x22: 0x0000007026f1e9a2 x23: 0x00000070c576f8e0
x24: 0x0000000000000000 x25: 0x00000070021b8a99 x26: 0x00000070021b8a99 x27: 0x0000007122f80903
x28: 0x00000071154920d0 fp: 0x000000016d722d80 lr: 0x000000010af4a768
sp: 0x000000016d722d20 pc: 0x0000000103a7186c cpsr: 0x80001000
far: 0x0000000000617265 esr: 0x92000006 (Data Abort) byte read Translation fault
```
Although this is not a current GHC HEAD problem (as `p_dyn` is not supported), but it probably revealed a bug in profiling code and that may happen in static profiling, so I report it to track this issue.
## Steps to reproduce
Use https://gitlab.haskell.org/wavewave/ghc/-/tree/wavewave/ghc_p_dyn?ref_type=heads , build GHC with `--flavour=perf+profiled_ghc`
and build a big project and wait for this happening. The chances are not very high though, and probably correlated to the size of the target project.
I will update this if I can find a minimal example.
## Expected behavior
Segfault should not happen in any case.
## Environment
* GHC version used: custom GHC version (`wavewave/ghc_p_dyn` branch `50b4995`), on top of GHC 9.9.20240131 (38c3afb)
Optional:
* Operating System: macOS Sonoma 14.3
* System Architecture: Apple M1 Max9.10.1Ian-Woo KimIan-Woo Kimhttps://gitlab.haskell.org/ghc/ghc/-/issues/24421The user guide should specify which heap profiling flags need -prof2024-02-13T01:10:50ZTeo CamarasuThe user guide should specify which heap profiling flags need -profSome of the flags for restricting heap profiling censuses require `-prof` but that isn't stated in the documentation.
For instance the `-hc ⟨name⟩` flag restricts to a specific cost centre. That clearly requires `-prof` but it's missing...Some of the flags for restricting heap profiling censuses require `-prof` but that isn't stated in the documentation.
For instance the `-hc ⟨name⟩` flag restricts to a specific cost centre. That clearly requires `-prof` but it's missing the "requires -prof` annotation. We should add that annotation for all the flags in this section that require it.Teo CamarasuTeo Camarasu