GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2024-03-25T19:13:14Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/24542Windows binary distribution `settings` contain references to build environmen...2024-03-25T19:13:14ZBen GamariWindows binary distribution `settings` contain references to build environment pathsBinary distributions on Windows contain references to the source distribution build root. For instance, the Windows binary distribution from the most recent 9.10.1-alpha1 candidate (https://gitlab.haskell.org/ghc/ghc/-/pipelines/91514) h...Binary distributions on Windows contain references to the source distribution build root. For instance, the Windows binary distribution from the most recent 9.10.1-alpha1 candidate (https://gitlab.haskell.org/ghc/ghc/-/pipelines/91514) has the following in its `settings` file:
```
[("C compiler command", "C:/GitLabRunner/builds/1/1807575/_build/bindist/ghc-9.10.0.20240313-x86_64-unknown-mingw32/mingw//bin/clang.exe")
...
```Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/24538Windows binary distributions ship with empty package database2024-03-19T19:22:46ZBen GamariWindows binary distributions ship with empty package databaseThe `ghcup` validation job for my most recent 9.10.1-alpha1 candidate (https://gitlab.haskell.org/ghc/ghcup-ci/-/jobs/1807133) reveals that Windows binary distributions are unserviceable, failing to find any of the boot packages during c...The `ghcup` validation job for my most recent 9.10.1-alpha1 candidate (https://gitlab.haskell.org/ghc/ghcup-ci/-/jobs/1807133) reveals that Windows binary distributions are unserviceable, failing to find any of the boot packages during compilation due to all of the package registration files being empty:
```
Unpacking to acme-box-0.0.0.0\
+ cd acme-box-0.0.0.0/
+ ghc Setup.hs
[1 of 2] Compiling Main ( Setup.hs, Setup.o )
Setup.hs:1:1: error: [GHC-87110]
Could not find module `Prelude'.
Use -v to see a list of the files searched for.
|
1 | import Distribution.Simple
| ^
Setup.hs:1:1: error: [GHC-87110]
Could not find module `Distribution.Simple'.
Use -v to see a list of the files searched for.
|
1 | import Distribution.Simple
| ^^^^^^^^^^^^^^^^^^^^^^^^^^
```Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/24536`configure --disable-tables-next-to-code` + `default+debug_info` = linking er...2024-03-12T16:14:55Zdoyougnujmy6342@gmail.com`configure --disable-tables-next-to-code` + `default+debug_info` = linking errorsIf I run:
```
./boot
./configure --disable-tables-next-to-code
hadrian/build --flavour=default+debug_info
```
I get:
```
/tmp/ghc452698_0/ghc_3.s: Assembler messages:
/tmp/ghc452698_0/ghc_3.s:193:0: error:
Error: symbol `.Lck_end...If I run:
```
./boot
./configure --disable-tables-next-to-code
hadrian/build --flavour=default+debug_info
```
I get:
```
/tmp/ghc452698_0/ghc_3.s: Assembler messages:
/tmp/ghc452698_0/ghc_3.s:193:0: error:
Error: symbol `.Lck_end' is already defined
|
193 | .Lck_end:
| ^
/tmp/ghc452698_0/ghc_3.s:194:0: error:
Error: symbol `.Lck_proc_end' is already defined
|
194 | .Lck_proc_end:
| ^
`cc' failed in phase `Assembler'. (Exit code: 1)
Command failed
Build failed.
```
Whereas I expect a compiler with DWARF enabled and no tables next to code. Why does this matter? Because I was trying to re-assess the performance of TNTC and I want DWARF symbols so that in perf I can gen annotated assembly.
...or...is this just expected behavior?https://gitlab.haskell.org/ghc/ghc/-/issues/245339.10.1-alpha1 regression: certain comments missing from AST2024-03-25T19:13:15Zamesgen9.10.1-alpha1 regression: certain comments missing from AST## Summary
In GHC 9.10.1-alpha1, certain comments do no longer occur in the AST compared to previous GHCs.
I noticed this while upgrading the Ormolu code formatter to GHC 9.10.1-alpha1 (for early integration) as it relies on this.
## ...## Summary
In GHC 9.10.1-alpha1, certain comments do no longer occur in the AST compared to previous GHCs.
I noticed this while upgrading the Ormolu code formatter to GHC 9.10.1-alpha1 (for early integration) as it relies on this.
## Steps to reproduce
Compile eg this code with `-ddump-parsed-ast -dkeep-comments`
```haskell
instance
( Read a, -- Weird
Read b
) =>
Read (a, b)
```
with GHC 9.10.1-alpha1, and note that the substring `Weird` does not occur in the output, in contrast to previous GHCs.
## Expected behavior
The pre-9.10.1-alpha1 behavior should be restored.
## Additional information
Bisecting points to !11716 introducing this. cc @alanz
## Environment
* GHC version used: 9.10.1-alpha19.10.1Alan ZimmermanAlan Zimmermanhttps://gitlab.haskell.org/ghc/ghc/-/issues/24532ghc -M fails to account for TemplateHaskell dependencies2024-03-12T15:17:25ZBen Gamarighc -M fails to account for TemplateHaskell dependenciesIn !12220 I found that `time`'s new dependency on `TemplateHaskell` results in Hadrian build failures. The reason appears to be that the implicit dependency on `Language.Haskell.TH.Lib.Internal` when `TemplateHaskell` is used is not acco...In !12220 I found that `time`'s new dependency on `TemplateHaskell` results in Hadrian build failures. The reason appears to be that the implicit dependency on `Language.Haskell.TH.Lib.Internal` when `TemplateHaskell` is used is not accounted for in `ghc -M` output.https://gitlab.haskell.org/ghc/ghc/-/issues/24530Remove duplication of `IfaceTyConInfo` when writing bytecode to .hi files2024-03-20T09:09:08ZHannes SiebenhandlRemove duplication of `IfaceTyConInfo` when writing bytecode to .hi filesIn heap analysis, we noticed there is a high amount of duplication of `IfaceTyConInfo` constructors when we persist `mi_extra_decls` to the respective `ModIface`. Note, this duplication only occurs when you write `mi_extra_decls` to the ...In heap analysis, we noticed there is a high amount of duplication of `IfaceTyConInfo` constructors when we persist `mi_extra_decls` to the respective `ModIface`. Note, this duplication only occurs when you write `mi_extra_decls` to the interface files.
On the agda codebase, with a ghc compiled with `--flavour=perf+ipe`, we gathered the following numbers with ghc-debug (census2LevelClosureType):
```
key; total; count; max; avg
ghc-9.9-inplace:GHC.Iface.Type:IfaceTyCon[ghc-9.9-inplace:GHC.Types.Name:Name,ghc-9.9-inplace:GHC.Iface.Type:IfaceTyConInfo]:206635176:8609799:24:24.0
ghc-9.9-inplace:GHC.Iface.Type:IfaceTyConInfo[ghc-9.9-inplace:Language.Haskell.Syntax.Type:NotPromoted,ghc-9.9-inplace:GHC.Iface.Type:IfaceNormalTyCon];141466584;5894441;24;24.0
ghc-9.9-inplace:GHC.Iface.Type:IfaceTyConInfo[ghc-9.9-inplace:Language.Haskell.Syntax.Type:IsPromoted,ghc-9.9-inplace:GHC.Iface.Type:IfaceNormalTyCon];64949568;2706232;24;24.0
```
We omitted several other lines to focus on the duplication of `IfaceTyConInfo`.
There are 5894441 occurrences of `IfaceTyConInfo NotPromoted IfaceNormalTyCon` and 2706232 instances of `IfaceTyConInfo IsPromoted IfaceNormalTyCon`, resulting in an 200MB overhead.
Note, this duplication does not occur if the `mi_extra_decls` are read from `ModIface`. However, in #24516, we identify a different issue with `IfaceTyConInfo`.Hannes SiebenhandlHannes Siebenhandlhttps://gitlab.haskell.org/ghc/ghc/-/issues/24529Binary distribution build on Windows fails2024-03-25T17:40:32ZBen GamariBinary distribution build on Windows failsIt appears that the `reloc-binary-dist` target is broken in at least some situations on Windows. Specifically, the `configure` invocation performed by `Rules.BinaryDist.installTo` fails to find the in-place mingw toolchain, causing `ghc-...It appears that the `reloc-binary-dist` target is broken in at least some situations on Windows. Specifically, the `configure` invocation performed by `Rules.BinaryDist.installTo` fails to find the in-place mingw toolchain, causing `ghc-toolchain` to conclude that there is no valid object merging tool available:
```
[Error {errorMessage = "Neither a object-merging tool (e.g. ld -r) nor an ar that supports -L is available", errorLogContexts = []}]
```
What is perplexing is that this appears to work in CI: the build system manages to produce a binary distribution, albeit a broken one for unrelated reasons (#24525).https://gitlab.haskell.org/ghc/ghc/-/issues/245279.10.1-alpha1 is missing -src.tar.lz2024-03-12T15:29:10Zjwaldmann9.10.1-alpha1 is missing -src.tar.lzin directory https://downloads.haskell.org/ghc/9.10.0.20240310/ , there is ghc-9.10.0.20240310-src.tar.xz but I was also expecting .lz (e.g., 9.8.2 has both)in directory https://downloads.haskell.org/ghc/9.10.0.20240310/ , there is ghc-9.10.0.20240310-src.tar.xz but I was also expecting .lz (e.g., 9.8.2 has both)https://gitlab.haskell.org/ghc/ghc/-/issues/24526read "500." :: Double fails2024-03-10T23:26:32ZDavid Foxread "500." :: Double fails## Summary
A common rendering of floating point numbers is not recognized by the Read instance.
## Steps to reproduce
```plaintext
Prelude> read "500.0" :: Double
500.0
Prelude> read "500" :: Double
500.0
Prelude> read "500." :: Doubl...## Summary
A common rendering of floating point numbers is not recognized by the Read instance.
## Steps to reproduce
```plaintext
Prelude> read "500.0" :: Double
500.0
Prelude> read "500" :: Double
500.0
Prelude> read "500." :: Double
*** Exception: Prelude.read: no parse
```
## Expected behavior
```plaintext
Prelude> read "500." :: Double
500.0
```
## Environment
* GHC version used: 8.6.5https://gitlab.haskell.org/ghc/ghc/-/issues/24525Windows bindists are quite broken2024-03-20T10:46:50ZBen GamariWindows bindists are quite brokenmingw32 binary distributions are currently quite broken:
```bash
$ wget https://gitlab.haskell.org/ghc/ghc/-/jobs/1805153/artifacts/raw/ghc-x86_64-windows-release.tar.xz
$ tar -xf ../ghc-x86_64-windows-release.tar.xz
$ cd ghc-9.10.0.2024...mingw32 binary distributions are currently quite broken:
```bash
$ wget https://gitlab.haskell.org/ghc/ghc/-/jobs/1805153/artifacts/raw/ghc-x86_64-windows-release.tar.xz
$ tar -xf ../ghc-x86_64-windows-release.tar.xz
$ cd ghc-9.10.0.20240310-x86_64-unknown-mingw32/
$ bin/ghc --info
ghc-9.10.0.20240310.exe: could not detect mingw toolchain in the following paths: ["C:\\msys64\\home\\ben\\tmp\\ghc-9.10.0.20240310-x86_64-unknown-mingw32\\lib\\..\\mingw","C:\\msys64\\home\\ben\\tmp\\ghc-9.10.0.20240310-x86_64-unknown-mingw32\\lib\\..\\..\\mingw","C:\\msys64\\home\\ben\\tmp\\ghc-9.10.0.20240310-x86_64-unknown-mingw32\\lib\\..\\..\\..\\mingw"]
```
It appears that many things that should be in the root of the binary distribution are instead now in `lib` (including `mingw/`):
```bash
$ ls lib/
a.exe config.guess config.status default.host.target.in doc ghc-usage.txt install-sh llvm-targets mk README x86_64-windows-ghc-9.10.0.20240310
bin config.log config.sub default.target docs-utils html latex Makefile package.conf.d settings
build.mk config.mk configure default.target.ghc-toolchain ghc-interp.js include lib manpage post-link.mjs template-hsc.h
completion config.mk.in default.host.target default.target.in ghci-usage.txt INSTALL llvm-passes mingw prelude.js wrappers
```
Moving `lib/mingw` to the root of the distribution appears to be sufficient to make the compiler functional.9.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/24522Incomplete inferred types showed for type holes since GHC 9.82024-03-11T09:00:52ZJan HrčekIncomplete inferred types showed for type holes since GHC 9.8## Summary
Since ghc 9.8 the inferred types of wildcards (sometimes?) don't contains type class constraints.
## Steps to reproduce
Consider this code:
```
$ cat A.hs
f :: _
f x y = x + y
```
When compiled with GHC 9.6, I get this err...## Summary
Since ghc 9.8 the inferred types of wildcards (sometimes?) don't contains type class constraints.
## Steps to reproduce
Consider this code:
```
$ cat A.hs
f :: _
f x y = x + y
```
When compiled with GHC 9.6, I get this error:
```
A.hs:1:6: error: [GHC-88464]
• Found type wildcard ‘_’
standing for ‘Integer -> Integer -> Integer’
To use the inferred type, enable PartialTypeSignatures
• In the type signature: f :: _
|
1 | f :: _
| ^
```
But when compiled with GHC 9.8.2 I get this (notice the inferred type doesn't contain Num a constraint):
```
A.hs:1:6: error: [GHC-88464]
• Found type wildcard ‘_’ standing for ‘a -> a -> a’
Where: ‘a’ is a rigid type variable bound by
the inferred type of f :: a -> a -> a
at A.hs:2:1-13
To use the inferred type, enable PartialTypeSignatures
• In the type signature: f :: _
|
1 | f :: _
| ^
A.hs:2:11: error: [GHC-39999]
• No instance for ‘Num a’ arising from a use of ‘+’
Possible fix:
add (Num a) to the context of the inferred type of f :: a -> a -> a
• In the expression: x + y
In an equation for ‘f’: f x y = x + y
|
2 | f x y = x + y
| ^
```
## Expected behavior
I would expect that if I use the inferred type, I will get code that type checks (e.g. `Num a => a -> a -> a` or `Integer -> Integer -> Integer`).
This is breaking haskell-language-server functionality, which uses the type displayed in the warning (`a -> a -> a`) in that it leads it to creation of code actions (small popups you can use to locally "fix" your code) that break user's code as in this example:
![Screenshot_from_2024-03-09_14-47-41](/uploads/e333c4313f2c558260e9958b4462d4fa/Screenshot_from_2024-03-09_14-47-41.png)
See this "broken" test case for illustration: https://github.com/haskell/haskell-language-server/blob/c50a0e118b8570b2bd405de6ff5be6a54926aa5d/plugins/hls-refactor-plugin/test/Main.hs#L665-L673
## Environment
* GHC version used: 9.8.2
Optional:
* Operating System: Fedora Linux 39
* System Architecture: x86_64https://gitlab.haskell.org/ghc/ghc/-/issues/24521Some Addr#, (Mutable)ByteArray# primops do not note mutability expectations2024-03-14T21:44:21ZBen OrchardSome Addr#, (Mutable)ByteArray# primops do not note mutability expectationsOne group of primops exported by GHC.Exts are the `index<primty>OffAddr# :: Addr# -> Int# -> <primty>` functions.
Their type signatures were somewhat surprising to me-- how are we to read from an address without some sort of state tracki...One group of primops exported by GHC.Exts are the `index<primty>OffAddr# :: Addr# -> Int# -> <primty>` functions.
Their type signatures were somewhat surprising to me-- how are we to read from an address without some sort of state tracking?
The Haddock docstrings state "Read a (pretty type description); offset in (type size in bytes) words."
This docstring is shared with the associated `read<primty>OffAddr# :: Addr# -> Int# -> State# d -> (# State# d, <primty> #)` function.
These primops are for reading from immutable non-GC-managed addresses. I eventually gathered so from some documentation in GHC.Prim,
which explains what the index, read and write primops do in the context of `ByteArray#`s. On a closer look, there are notes on whether a given primop works with immutable or mutable memory, but these are inconsistently applied, and no `Addr#` primops make any reference.
I think primops that access the contents of some pointer (`Addr#`, `MutableByteArray#` or `ByteArray#`) should note the mutability of the memory they're accessing. This is potentially "obvious" for the latter two, but easily confusing for `Addr#` access primops which aren't explained purely by their type signatures.
This is fairly easily accomplished by editing some `desc` fields in `utils/genprimopcode/AccessOps.hs`.https://gitlab.haskell.org/ghc/ghc/-/issues/24516Thunks in `IfaceTyCon` retain a large amount of memory2024-03-20T09:09:45ZHannes SiebenhandlThunks in `IfaceTyCon` retain a large amount of memory## Summary
In heap analysis, the `IfaceTyCon` constructor in `mi_extra_decls` retains a thunk to `IfaceTyConInfo`. This added indirection seems to defeat sharing for the two most common instances of `IfaceTyConInfo` which aims to reduce...## Summary
In heap analysis, the `IfaceTyCon` constructor in `mi_extra_decls` retains a thunk to `IfaceTyConInfo`. This added indirection seems to defeat sharing for the two most common instances of `IfaceTyConInfo` which aims to reduce memory usage quite considerably.
All numbers and pictures have been obtained running `ghci -fbyte-code-and-object-code` using `ghc-debug` and `-hT` profiling. GHC itself has been compiled with the flavour `perf+ipe`.
In a two-level census heap traversal, we have the following lines (just an excerpt):
```
key;total;count;max;avg
ghc-9.9-inplace:GHC.Iface.Type:IfaceTyConInfo[ghc-9.9-inplace:Language.Haskell.Syntax.Type:NotPromoted,ghc-9.9-inplace:GHC.Iface.Type:IfaceNormalTyCon];141466584;5894441;24;24.0
ghc-9.9-inplace:GHC.Iface.Type:IfaceTyConInfo[ghc-9.9-inplace:Language.Haskell.Syntax.Type:IsPromoted,ghc-9.9-inplace:GHC.Iface.Type:IfaceNormalTyCon];64949568;2706232;24;24.0
```
Which hints that we have 5894441 occurrences of `IfaceTyConInfo NotPromoted IfaceNormalTyCon` and 2706232 of `IfaceTyConInfo IsPromoted IfaceNormalTyCon` on the heap.
Further, we can observe the thunk existing in `ghc-debug-brick`.
![image](/uploads/a33a234c35f4dba307143a9dc6799c23/image.png)
For reference, this the space behaviour of loading agda into ghci, where the bytecode has been serialised into the interface file:
![image](/uploads/014ee4373bbfc7c5b7f892312cf51929/image.png)
and `ghci +RTS -s -i0.1`
```
5,839,944,688 bytes allocated in the heap
7,203,898,048 bytes copied during GC
1,963,423,488 bytes maximum residency (12 sample(s))
14,932,224 bytes maximum slop
3786 MiB total memory in use (0 MiB lost due to fragmentation)
Tot time (elapsed) Avg pause Max pause
Gen 0 275 colls, 0 par 3.503s 3.514s 0.0128s 0.2590s
Gen 1 12 colls, 0 par 4.976s 4.995s 0.4162s 2.4095s
TASKS: 6 (1 bound, 5 peak workers (5 total), using -N1)
SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled)
INIT time 0.009s ( 0.009s elapsed)
MUT time 3.265s ( 5.421s elapsed)
GC time 8.479s ( 8.509s elapsed)
EXIT time 0.001s ( 0.000s elapsed)
Total time 11.754s ( 13.940s elapsed)
Alloc rate 1,788,578,842 bytes per MUT second
Productivity 27.8% of total user, 38.9% of total elapsed
```
While it is a little bit unclear why only this field is a thunk, adding the bangs to `IfaceTyCon`
```haskell
data IfaceTyCon = IfaceTyCon { ifaceTyConName :: !IfExtName
, ifaceTyConInfo :: !IfaceTyConInfo }
```
gives the following results for the two level census:
```
key;total;count;max;avg
ghc-9.9-inplace:GHC.Iface.Type:IfaceTyConInfo[ghc-9.9-inplace:Language.Haskell.Syntax.Type:IsPromoted,ghc-9.9-inplace:GHC.Iface.Type:IfaceNormalTyCon];24;1;24;24.0
ghc-9.9-inplace:GHC.Iface.Type:IfaceTyConInfo[ghc-9.9-inplace:Language.Haskell.Syntax.Type:NotPromoted,ghc-9.9-inplace:GHC.Iface.Type:IfaceNormalTyCon];24;1;24;24.0
```
This indicates that we now have only exactly one instance for the two common cases.
and more importantly:
![image](/uploads/0ced1a2bf8318273600e426d734574f5/image.png)
``ghci +RTS -s -i0.1`` output:
```
6,114,619,032 bytes allocated in the heap
6,458,988,440 bytes copied during GC
1,330,672,456 bytes maximum residency (12 sample(s))
10,910,904 bytes maximum slop
2689 MiB total memory in use (0 MiB lost due to fragmentation)
Tot time (elapsed) Avg pause Max pause
Gen 0 275 colls, 0 par 3.933s 3.945s 0.0143s 0.2844s
Gen 1 12 colls, 0 par 3.840s 3.854s 0.3212s 1.6629s
TASKS: 6 (1 bound, 5 peak workers (5 total), using -N1)
SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled)
INIT time 0.010s ( 0.010s elapsed)
MUT time 3.235s ( 3.728s elapsed)
GC time 7.773s ( 7.799s elapsed)
EXIT time 0.000s ( 0.000s elapsed)
Total time 11.018s ( 11.537s elapsed)
Alloc rate 1,890,406,998 bytes per MUT second
Productivity 29.4% of total user, 32.3% of total elapsed
```
## Environment
* GHC version used: HEAD
Optional:
* Operating System: Arch Linux
* System Architecture: x86_64Hannes SiebenhandlHannes Siebenhandlhttps://gitlab.haskell.org/ghc/ghc/-/issues/24515Many profiling tests broken on Windows2024-03-09T14:39:42ZBen GamariMany profiling tests broken on WindowsIn the 9.10.1-alpha1 release job I found that many profiling-related tests are broken on Windows (see https://gitlab.haskell.org/ghc/ghc/-/jobs/1800492, https://gitlab.haskell.org/ghc/ghc/-/jobs/1800548):
```
Unexpected failures:
C:/G...In the 9.10.1-alpha1 release job I found that many profiling-related tests are broken on Windows (see https://gitlab.haskell.org/ghc/ghc/-/jobs/1800492, https://gitlab.haskell.org/ghc/ghc/-/jobs/1800548):
```
Unexpected failures:
C:/GitLabRunner/builds/0/1800548/tmp/ghctest-m0rwyh7h/test spaces/testsuite/tests/profiling/should_run/caller-cc/CallerCc1.run CallerCc1 [bad profile] (prof)
C:/GitLabRunner/builds/0/1800548/tmp/ghctest-m0rwyh7h/test spaces/testsuite/tests/profiling/should_run/caller-cc/CallerCc1.run CallerCc1 [bad profile] (profasm)
C:/GitLabRunner/builds/0/1800548/tmp/ghctest-m0rwyh7h/test spaces/testsuite/tests/profiling/should_run/caller-cc/CallerCc2.run CallerCc2 [bad profile] (prof)
C:/GitLabRunner/builds/0/1800548/tmp/ghctest-m0rwyh7h/test spaces/testsuite/tests/profiling/should_run/caller-cc/CallerCc2.run CallerCc2 [bad profile] (profasm)
C:/GitLabRunner/builds/0/1800548/tmp/ghctest-m0rwyh7h/test spaces/testsuite/tests/profiling/should_run/caller-cc/CallerCc3.run CallerCc3 [bad profile] (prof)
C:/GitLabRunner/builds/0/1800548/tmp/ghctest-m0rwyh7h/test spaces/testsuite/tests/profiling/should_run/caller-cc/CallerCc3.run CallerCc3 [bad profile] (profasm)
C:/GitLabRunner/builds/0/1800548/tmp/ghctest-m0rwyh7h/test spaces/testsuite/tests/profiling/should_run/ignore_scc.run ignore_scc [bad profile] (prof)
C:/GitLabRunner/builds/0/1800548/tmp/ghctest-m0rwyh7h/test spaces/testsuite/tests/profiling/should_run/ignore_scc.run ignore_scc [bad profile] (profasm)
C:/GitLabRunner/builds/0/1800548/tmp/ghctest-m0rwyh7h/test spaces/testsuite/tests/profiling/should_run/ioprof.run ioprof [bad profile] (prof)
C:/GitLabRunner/builds/0/1800548/tmp/ghctest-m0rwyh7h/test spaces/testsuite/tests/profiling/should_run/ioprof.run ioprof [bad profile] (profasm)
C:/GitLabRunner/builds/0/1800548/tmp/ghctest-m0rwyh7h/test spaces/testsuite/tests/profiling/should_run/prof-doc-fib.run prof-doc-fib [bad profile] (prof)
C:/GitLabRunner/builds/0/1800548/tmp/ghctest-m0rwyh7h/test spaces/testsuite/tests/profiling/should_run/prof-doc-fib.run prof-doc-fib [bad profile] (profasm)
C:/GitLabRunner/builds/0/1800548/tmp/ghctest-m0rwyh7h/test spaces/testsuite/tests/profiling/should_run/prof-doc-last.run prof-doc-last [bad profile] (prof)
C:/GitLabRunner/builds/0/1800548/tmp/ghctest-m0rwyh7h/test spaces/testsuite/tests/profiling/should_run/prof-doc-last.run prof-doc-last [bad profile] (profasm)
C:/GitLabRunner/builds/0/1800548/tmp/ghctest-m0rwyh7h/test spaces/testsuite/tests/profiling/should_run/profinline001.run profinline001 [bad profile] (prof)
C:/GitLabRunner/builds/0/1800548/tmp/ghctest-m0rwyh7h/test spaces/testsuite/tests/profiling/should_run/profinline001.run profinline001 [bad profile] (profasm)
C:/GitLabRunner/builds/0/1800548/tmp/ghctest-m0rwyh7h/test spaces/testsuite/tests/profiling/should_run/scc-prof-overloaded-calls001.run scc-prof-overloaded-calls001 [bad profile] (prof)
C:/GitLabRunner/builds/0/1800548/tmp/ghctest-m0rwyh7h/test spaces/testsuite/tests/profiling/should_run/scc-prof-overloaded-calls001.run scc-prof-overloaded-calls001 [bad profile] (profasm)
C:/GitLabRunner/builds/0/1800548/tmp/ghctest-m0rwyh7h/test spaces/testsuite/tests/profiling/should_run/scc-prof-overloaded-calls002.run scc-prof-overloaded-calls002 [bad profile] (prof)
C:/GitLabRunner/builds/0/1800548/tmp/ghctest-m0rwyh7h/test spaces/testsuite/tests/profiling/should_run/scc-prof-overloaded-calls002.run scc-prof-overloaded-calls002 [bad profile] (profasm)
C:/GitLabRunner/builds/0/1800548/tmp/ghctest-m0rwyh7h/test spaces/testsuite/tests/profiling/should_run/scc-prof-overloaded001.run scc-prof-overloaded001 [bad profile] (prof)
C:/GitLabRunner/builds/0/1800548/tmp/ghctest-m0rwyh7h/test spaces/testsuite/tests/profiling/should_run/scc-prof-overloaded001.run scc-prof-overloaded001 [bad profile] (profasm)
C:/GitLabRunner/builds/0/1800548/tmp/ghctest-m0rwyh7h/test spaces/testsuite/tests/profiling/should_run/scc-prof-overloaded002.run scc-prof-overloaded002 [bad profile] (prof)
C:/GitLabRunner/builds/0/1800548/tmp/ghctest-m0rwyh7h/test spaces/testsuite/tests/profiling/should_run/scc-prof-overloaded002.run scc-prof-overloaded002 [bad profile] (profasm)
C:/GitLabRunner/builds/0/1800548/tmp/ghctest-m0rwyh7h/test spaces/testsuite/tests/profiling/should_run/scc001.run scc001 [bad profile] (prof)
C:/GitLabRunner/builds/0/1800548/tmp/ghctest-m0rwyh7h/test spaces/testsuite/tests/profiling/should_run/scc002.run scc002 [bad profile] (prof)
C:/GitLabRunner/builds/0/1800548/tmp/ghctest-m0rwyh7h/test spaces/testsuite/tests/profiling/should_run/scc002.run scc002 [bad profile] (profasm)
C:/GitLabRunner/builds/0/1800548/tmp/ghctest-m0rwyh7h/test spaces/testsuite/tests/profiling/should_run/scc003.run scc003 [bad profile] (prof)
C:/GitLabRunner/builds/0/1800548/tmp/ghctest-m0rwyh7h/test spaces/testsuite/tests/profiling/should_run/scc003.run scc003 [bad profile] (profasm)
C:/GitLabRunner/builds/0/1800548/tmp/ghctest-m0rwyh7h/test spaces/testsuite/tests/profiling/should_run/scc005.run scc005 [bad profile] (prof)
C:/GitLabRunner/builds/0/1800548/tmp/ghctest-m0rwyh7h/test spaces/testsuite/tests/profiling/should_run/scc005.run scc005 [bad profile] (profasm)
C:/GitLabRunner/builds/0/1800548/tmp/ghctest-m0rwyh7h/test spaces/testsuite/tests/profiling/should_run/T12962.run T12962 [bad profile] (prof)
C:/GitLabRunner/builds/0/1800548/tmp/ghctest-m0rwyh7h/test spaces/testsuite/tests/profiling/should_run/T12962.run T12962 [bad profile] (profasm)
C:/GitLabRunner/builds/0/1800548/tmp/ghctest-m0rwyh7h/test spaces/testsuite/tests/profiling/should_run/T2552.run T2552 [bad profile] (prof)
C:/GitLabRunner/builds/0/1800548/tmp/ghctest-m0rwyh7h/test spaces/testsuite/tests/profiling/should_run/T2552.run T2552 [bad profile] (profasm)
C:/GitLabRunner/builds/0/1800548/tmp/ghctest-m0rwyh7h/test spaces/testsuite/tests/profiling/should_run/T5654-O0.run T5654-O0 [bad profile] (prof)
C:/GitLabRunner/builds/0/1800548/tmp/ghctest-m0rwyh7h/test spaces/testsuite/tests/profiling/should_run/T5654-O1.run T5654-O1 [bad profile] (profasm)
C:/GitLabRunner/builds/0/1800548/tmp/ghctest-m0rwyh7h/test spaces/testsuite/tests/profiling/should_run/T5654b-O0.run T5654b-O0 [bad profile] (prof)
C:/GitLabRunner/builds/0/1800548/tmp/ghctest-m0rwyh7h/test spaces/testsuite/tests/profiling/should_run/T5654b-O1.run T5654b-O1 [bad profile] (profasm)
C:/GitLabRunner/builds/0/1800548/tmp/ghctest-m0rwyh7h/test spaces/testsuite/tests/profiling/should_run/T680.run T680 [bad profile] (prof)
C:/GitLabRunner/builds/0/1800548/tmp/ghctest-m0rwyh7h/test spaces/testsuite/tests/profiling/should_run/T680.run T680 [bad profile] (profasm)
C:/GitLabRunner/builds/0/1800548/tmp/ghctest-m0rwyh7h/test spaces/testsuite/tests/profiling/should_run/toplevel_scc_1.run toplevel_scc_1 [bad profile] (prof_no_auto)
```
It appears that the profile wasn't created in most of these cases, failing with output of the form:
```
*** unexpected failure for profinline001(profasm)
C:/GitLabRunner/builds/0/1800548/tmp/ghctest-m0rwyh7h/test spaces/testsuite/tests/profiling/should_run/profinline001.run/profinline001.exe.prof does not exist
```Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/24513T11627a crashes on x86-64 Debian 9 in release flavour2024-03-12T14:16:45ZBen GamariT11627a crashes on x86-64 Debian 9 in release flavourSee https://gitlab.haskell.org/ghc/ghc/-/jobs/1800484.See https://gitlab.haskell.org/ghc/ghc/-/jobs/1800484.Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/24512T24171 is broken on AArch64 in the release flavour2024-03-12T14:16:45ZBen GamariT24171 is broken on AArch64 in the release flavourThis test appears to segfault on AArch64/Linux when building in the `release` flavour. This happens even with `+no_split_sections`.
See https://gitlab.haskell.org/ghc/ghc/-/jobs/1800471#L6567.This test appears to segfault on AArch64/Linux when building in the `release` flavour. This happens even with `+no_split_sections`.
See https://gitlab.haskell.org/ghc/ghc/-/jobs/1800471#L6567.9.10.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/24507Unsound optimization breaks pattern matching on sum type2024-03-23T22:14:54ZStefano DebenedettiUnsound optimization breaks pattern matching on sum type## Summary
Enabling `-O2` makes a case expression pattern match pick the 7th constructor of a sum type also when called with any constructor from the 2nd to the 6th.
The following factors seem to concur in triggering this behaviour (se...## Summary
Enabling `-O2` makes a case expression pattern match pick the 7th constructor of a sum type also when called with any constructor from the 2nd to the 6th.
The following factors seem to concur in triggering this behaviour (see the Expected behaviour section below for more details):
* `-O2`
* usage of the `streamly-core` library (I could not reproduce without it)
* a strictness annotation on the type used to hold the constructor to pass to the buggy function
* splitting the code into separate modules
On the other hand, using `Debug.Trace.trace` to examine the constructor before feeding it into the case expression fixes the issue, making it a Heisenbug.
## Steps to reproduce
```
$ git clone https://github.com/demaledetti/test-bug
$ cd test-bug
$ cabal clean && cabal build --ghc-options -v > cabal.log.ko 2>&1 && for i in {A..J}; do cabal run testbug -- $i; done
parser: A
testbug: src/TestBug/Parser.hs:(15,18)-(25,34): Non-exhaustive patterns in case
parser: B
testbug: Prelude.undefined
CallStack (from HasCallStack):
undefined, called at src/TestBug/Parser.hs:23:10 in test-bug-0.1.0.0-inplace:TestBug.Parser
parser: C
testbug: Prelude.undefined
CallStack (from HasCallStack):
undefined, called at src/TestBug/Parser.hs:23:10 in test-bug-0.1.0.0-inplace:TestBug.Parser
parser: D
testbug: Prelude.undefined
CallStack (from HasCallStack):
undefined, called at src/TestBug/Parser.hs:23:10 in test-bug-0.1.0.0-inplace:TestBug.Parser
parser: E
testbug: Prelude.undefined
CallStack (from HasCallStack):
undefined, called at src/TestBug/Parser.hs:23:10 in test-bug-0.1.0.0-inplace:TestBug.Parser
parser: F
testbug: Prelude.undefined
CallStack (from HasCallStack):
undefined, called at src/TestBug/Parser.hs:23:10 in test-bug-0.1.0.0-inplace:TestBug.Parser
parser: G
testbug: Prelude.undefined
CallStack (from HasCallStack):
undefined, called at src/TestBug/Parser.hs:23:10 in test-bug-0.1.0.0-inplace:TestBug.Parser
parser: H
OK
parser: I
OK
parser: J
testbug: src/TestBug/Parser.hs:(15,18)-(25,34): Non-exhaustive patterns in case
```
## Expected behaviour
With `-O1`:
```
$ cabal clean && cabal build -O1 --ghc-options -v > cabal.log.ok 2>&1 && for i in {A..J}; do cabal run -O1 testbug -- $i; done
parser: A
testbug: src/TestBug/Parser.hs:(15,18)-(25,34): Non-exhaustive patterns in case
parser: B
OK
parser: C
OK
parser: D
OK
parser: E
OK
parser: F
OK
parser: G
testbug: Prelude.undefined
CallStack (from HasCallStack):
undefined, called at src/TestBug/Parser.hs:23:10 in test-bug-0.1.0.0-inplace:TestBug.Parser
parser: H
OK
parser: I
OK
parser: J
testbug: src/TestBug/Parser.hs:(15,18)-(25,34): Non-exhaustive patterns in case
```
For other ways to get the correct behaviour without lowering the optimization level, including the ones mentioned in the Summary section above, see these comments in the source code:
```
$ grep -rnI "the bug" src/ testbug/
src/TestBug/Data.hs:12: -- simplifying it away makes the bug disappear
src/TestBug/Parser.hs:5:-- makes the bug go away (making it a Heisenbug)
src/TestBug/Parser.hs:16: -- uncommenting the next line makes the bug disappear
src/TestBug/Parser.hs:26: -- uncommenting the next line makes the bug disappear
testbug/Main.hs:13:-- makes the bug go away
```
## Environment
* GHC version used: 9.8.2
Optional:
* Operating System:
* System Architecture:
```
$ uname -a
Linux eppere 6.7.5-gentoo #1 SMP Mon Feb 19 15:51:31 CET 2024 x86_64 Intel(R) Core(TM) i7-1065G7 CPU @ 1.30GHz GenuineIntel GNU/Linux
```
Logs mentioned above:
[cabal.log.ko](/uploads/5c86dcaaac0efe1a297a3534d2e6b3a4/cabal.log.ko)
[cabal.log.ok](/uploads/aa5c0a45405cbf6e9fad05b1219dcd07/cabal.log.ok)
Log of build with `-O2` but removing the strictness annotation in `Main.hs` (commenting line 14, uncommenting line 15):
[cabal.log.lazy](/uploads/b63f0ae3c422538bb04ed7b623c49c50/cabal.log.lazy)
(easier to diff vs cabal.log.ko)9.8.3Andreas KlebingerAndreas Klebingerhttps://gitlab.haskell.org/ghc/ghc/-/issues/24502Store relative path to package database in settings file2024-03-19T19:22:46ZMatthew PickeringStore relative path to package database in settings fileMR: !12163
cc @hsyl20
Before this patch, the global package database was always assumed to be
in libdir </> package.conf.d.
This causes issues in GHC's build system because there are sometimes
situations where the package databa...MR: !12163
cc @hsyl20
Before this patch, the global package database was always assumed to be
in libdir </> package.conf.d.
This causes issues in GHC's build system because there are sometimes
situations where the package database you need to use is not located in
the same place as the settings file.
* The stage1 compiler needs to use stage2 libraries, so we should set
"Global Package DB" for the stage1 compiler to the stage2 package
database.
* Stage 2 cross compilers need to use stage2 libraries, so likewise, we
should set the package database to point to `_build/stage2/lib`.
* When installing we have rearranged everything so that the settings
file and package database line up properly, so then everything should
continue to work as before. (So we just set the package path to "package.conf.d", so things work the same as before).
* ghc-pkg needs to be modified as well to look in the settings file for
the package database rather than assuming the global package database
location relative to the lib folder. This just seems like an improvement to me.
* Cabal/cabal-install will work correctly because they query the global
package database using `--print-global-package-db`.
A reasonable question is why not generate the "right" settings files in
the right places in GHC's build system. In order to do this you would
need to engineer wrappers for all executables to point to a specific
libdir. There are also situations where the same package db is used by
two different compilers with two different settings files (think stage2
cross compiler and stage3 compiler).
Note that this patch then allows us to also delete the stage1 wrappers, so you can run
the stage1 executable normally and it will work and look in the right package database.
In short, this 10 line patch allows for some reasonable simplifications
in Hadrian at very little cost to anything else.Matthew PickeringMatthew Pickeringhttps://gitlab.haskell.org/ghc/ghc/-/issues/24500Automatic cost center insertion on overloaded bindings and overloaded call sites2024-03-05T00:58:53ZFinley McIlwaineAutomatic cost center insertion on overloaded bindings and overloaded call sites## Motivation
It should be possible to automatically add cost centers to overloaded bindings and overloaded call sites, after optimization. This would enable easier detection of overloaded calls that "survive" optimization. It could als...## Motivation
It should be possible to automatically add cost centers to overloaded bindings and overloaded call sites, after optimization. This would enable easier detection of overloaded calls that "survive" optimization. It could also help users determine which overloaded calls are most expensive, obviating candidates for specialization.
## Proposal
Add two new cost center insertion methods enabled via `-fprof-late-overloaded` and `-fprof-late-overloaded-calls`. The former adding cost centers to top-level overloaded bindings, the latter adding cost centers to call sites involving dictionary arguments.Finley McIlwaineFinley McIlwainehttps://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.