GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2024-03-01T02:57:24Zhttps://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/24488TypeAbstractions example produces a parse error2024-03-09T17:48:33ZJkensikTypeAbstractions example produces a parse error## Summary
The example from the documentation
`
f5 :: [forall a. a -> a -> a]
f5 = [ \ @a x _ -> x :: a,
\ @a _ y -> y :: a ]
`
gives the error
error: [GHC-58481] parse error on input ‘@’
|
26 | f5 = [ \ @a x _ -> x :: a,
...## Summary
The example from the documentation
`
f5 :: [forall a. a -> a -> a]
f5 = [ \ @a x _ -> x :: a,
\ @a _ y -> y :: a ]
`
gives the error
error: [GHC-58481] parse error on input ‘@’
|
26 | f5 = [ \ @a x _ -> x :: a,
## Environment
GHC9.8.2Vladislav ZavialovVladislav Zavialovhttps://gitlab.haskell.org/ghc/ghc/-/issues/24487regression with 9.6/9.8, observed as heap usage but could be due to behavior ...2024-03-13T19:35:39Zquarkregression with 9.6/9.8, observed as heap usage but could be due to behavior change## Summary
The [Bluespec Compiler (bsc)](github.com/b-lang-org/bsc) is compiled with GHC and we have observed a regression in our testsuite when using GHC 9.6 and 9.8 (including recent 9.8.2), that was not a failure with GHC 9.4 and ear...## Summary
The [Bluespec Compiler (bsc)](github.com/b-lang-org/bsc) is compiled with GHC and we have observed a regression in our testsuite when using GHC 9.6 and 9.8 (including recent 9.8.2), that was not a failure with GHC 9.4 and earlier.
Specifically, in the BSC repo, in directory `/testsuite/bsc.bugs/bluespec_inc/b1490/`, there are two tests which exhaust the heap when set with `-M256` but execute fine when it is increased with `+RTS -M260` and `+RTS -M265`. However, with earlier versions of GHC (such as 9.4.8), the heap size can be reduced dramatically and it still executes without exhausting the heap, even down to `-M4K`!
Something clearly changed in GHC, but I don't think it's necessarily directly related to heap usage; I would guess that maybe a code optimization has changed the behavior, and it is resulted in BSC using more heap. I say that because BSC is itself a compiler, and the test cases which are now failing are tests that involve a for-loop in the Bluespec design being compiled, and the tests are checking that BSC is able to unroll the loops and properly prune the growing structure so that it doesn't explode. The heap usage could be because BSC is now failing to properly prune, as a result of a behavior change resulting from a change in GHC.
However, I don't know how to diagnose this. Are there RTS flags that can dump information about heap usage, that I can compare between GHC versions? I can use `+RTS -s`, but it doesn't show max heap usage, and the info that it does show isn't significantly different between GHC 9.8 and 9.4.
I assume that a binary search of the GHC commits might find the point where the issue was introduced, but each iteration would take a while.
Any advice you can provide on how to investigate this would be appreciated.
## Steps to reproduce
BSC is a large program, but if you want to reproduce, you can do this:
```
git clone --recursive https://github.com/B-Lang-org/bsc
cd bsc
make install-src
cd testsuite/bsc.bugs/bluespec_inc/b1490/
../../../../inst/bin/bsc -verilog Bug1490MyUnion.bsv +RTS -M256M
```
The result of running BSC in the last line is (when compiled with 9.8 or 9.6):
```
bsc: Heap exhausted;
bsc: Current maximum heap size is 268435456 bytes (256 MB).
bsc: Use `+RTS -M<size>' to increase it.
```
## Expected behavior
I expect BSC to run to completion and output a message like this (which is what you get with GHC 9.4.8 and earlier version):
```
Verilog file created: module_arbitrate_myunion.v
```
In fact, with GHC 9.4.8 (and presumably earlier), the heap can be reduced significantly and BSC still executes fine:
```
../../../../inst/bin/bsc -verilog Bug1490MyUnion.bsv +RTS -M4K
```
With GHC 9.6 and 9.8, the heap needs to be increased to around 260 or 265, for it to compile. This difference between essentially nothing (4K) and 260M seems significant, and so I felt it was worth reporting (particularly if the heap is just a sympton and that it's due to a bug in behavior).
## Environment
* GHC versions that fail: 9.8.2, 9.8.1, 9.6.4, 9.6.2
* GHC versions that work: 9.4.8 (and many earlier versions)
* Operating System: My results reported here are on macOS 11, but the same failures were seen on GitHub VMs for Ubuntu 22.04 and macOS 12
* System Architecture: x86_64
We have been using various versions of GHC in our CI over the last few years and had not noticed an issue up through 9.4.x (on various Ubuntu and macOS VMs). We then tested with 9.8.1 (on Ubuntu 22.04 and macOS 12) and saw the error. Today, on my macOS 11 system, I confirmed that 9.8.1 fails and that the recently released 9.8.2 also fails, and I checked 9.6.2 and 9.6.4 and saw that they also failed. So I would guess that the issue was introduced in 9.6. I confirm that we currently do not observe the failure when using 9.4.8 (on Ubuntu 20.04 and 22.04 and macOS 11, 12, and 13).https://gitlab.haskell.org/ghc/ghc/-/issues/24486ignored unrecognised input when compiling with a plugin2024-03-05T14:33:15ZMarcin Szamotulskiignored unrecognised input when compiling with a plugin## Summary
When I compile a package with `ghc-tags-plugin` enabled, e.g. passing the following options (one will need to modify it depending on your system):
```
package io-classes
ghc-options: -package-db=/home/coot/.local/state/caba...## Summary
When I compile a package with `ghc-tags-plugin` enabled, e.g. passing the following options (one will need to modify it depending on your system):
```
package io-classes
ghc-options: -package-db=/home/coot/.local/state/cabal/store/ghc-9.6.4/package.db/
-plugin-package=ghc-tags-plugin-0.6.1.0
-fplugin=Plugin.GhcTags
-fplugin-opt=Plugin.GhcTags:../tags
```
I am getting the following warnings:
```
Warning: ignoring unrecognised input `/home/coot/clients/iog/io-sim/dist-newstyle/build/x86_64-linux/ghc-9.6.4/io-classes-1.4.1.0/build/Control/Concurrent/Class/M
onadMVar.dyn_o'
...
```
It doesn't really matter what package I try to compile; I haven't tried to use any other plugin, but I don't get that warning when I disable the `ghc-tags-plugin`.
## Steps to reproduce
Given above. To install `ghc-tags-plugin` follow instruction in the [readme](https://github.com/coot/ghc-tags-plugin/)
## Expected behavior
No warning.
## Environment
* GHC version used: `ghc-9.6.4`
Optional:
* Operating System: Linux
* System Architecture: x86_649.10.2ZubinZubinhttps://gitlab.haskell.org/ghc/ghc/-/issues/24485Sort out haddock hyperlinked-sources links2024-03-26T17:46:45ZBen GamariSort out haddock hyperlinked-sources linksCurrently Haddock's hyperlinked sources [fails to account](https://github.com/haskell/haddock/issues/1628) for declaration reexports correctly. This needs to be addressed for 9.10.1 to avoid compromising `base` documentation due to the `...Currently Haddock's hyperlinked sources [fails to account](https://github.com/haskell/haddock/issues/1628) for declaration reexports correctly. This needs to be addressed for 9.10.1 to avoid compromising `base` documentation due to the `ghc-internal` split.9.10.1Ben GamariBen Gamarihttps://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/24483Can't re-export duplicate field names from identical constructor names2024-02-27T15:47:53ZTom EllisCan't re-export duplicate field names from identical constructor namesThis is a new ticket to track [an issue explained by @adamgundry](https://gitlab.haskell.org/ghc/ghc/-/issues/13352#note_294968) in a prior (closed) ticket. That is, the following code leads to the following error. The error is still pr...This is a new ticket to track [an issue explained by @adamgundry](https://gitlab.haskell.org/ghc/ghc/-/issues/13352#note_294968) in a prior (closed) ticket. That is, the following code leads to the following error. The error is still present as of GHC 9.8. It seems like an artificial limitation and it would be great if it could be lifted. This is particularly annoying if we want to create a custom `Prelude`. It makes it impossible to create a custom `Prelude` containing two different fields with the same name, if their constructors also share the same name.
```
{-# LANGUAGE DuplicateRecordFields #-}
module A where
data S = C { foo :: Int }
{-# LANGUAGE DuplicateRecordFields #-}
module B where
data T = C { foo :: Int }
{-# LANGUAGE DuplicateRecordFields #-}
module C (S(foo), T(foo)) where
import A (S(..))
import B (T(..))
```
```
Conflicting exports for ‘foo’:
‘S(foo)’ exports ‘foo’
imported from ‘A’ at C.hs:5:28-32
(and originally defined at A.hs:3:16-18)
‘T(foo)’ exports ‘foo’
imported from ‘B’ at C.hs:6:28-32
(and originally defined at B.hs:5:14-16)
```
----
It's also an interesting puzzle to try to imagine the implementation details that allow both `foo`s to be used within the same module but not re-exported from the same module! I haven't been able to work it out ...
EDIT: Ah, I think I have an explanation: in a given module, duplicate field names are disambiguated by the module they were imported from plus the constructor name.https://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/24481Support NoFieldSelectors as a datatype and field annotation2024-02-26T09:45:21ZAdam GundrySupport NoFieldSelectors as a datatype and field annotationThe GHC Steering Committee has accepted [proposal 512: NoFieldSelectors as a datatype and field annotation](https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0512-nofieldselectors-per-datatype.md). This makes it possib...The GHC Steering Committee has accepted [proposal 512: NoFieldSelectors as a datatype and field annotation](https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0512-nofieldselectors-per-datatype.md). This makes it possible to annotate individual datatypes or fields as to whether they should use `FieldSelectors` or `NoFieldSelectors`.https://gitlab.haskell.org/ghc/ghc/-/issues/24480cannot bootstrap ghc-9.8.2 with ghc-9.8.12024-02-27T15:46:55Zjwaldmanncannot bootstrap ghc-9.8.2 with ghc-9.8.1## Summary
Failure to build 9.8.2 from source (tarball from https://downloads.haskell.org/ghc/9.8.2/) with 9.8.1 as the bootstrap compiler. Failure because of versions of dependencies for building hadrian.
Don't know if it's supposed t...## Summary
Failure to build 9.8.2 from source (tarball from https://downloads.haskell.org/ghc/9.8.2/) with 9.8.1 as the bootstrap compiler. Failure because of versions of dependencies for building hadrian.
Don't know if it's supposed to work. Probably not, as the same thing happens when bootstrapping 9.8.1 with itself.
Building 9.8.2 with 9.6.4 looks good.
## Steps to reproduce
```
$ ./configure
$ ./hadrian/build -j binary-dist-dir --docs=no-sphinx
Warning: Requested index-state 2023-03-30T10:00:00Z is newer than
'hackage.haskell.org'! Falling back to older state (2023-03-30T08:23:24Z).
Resolving dependencies...
Error: cabal: Could not resolve dependencies:
[__0] trying: hadrian-0.1.0.0 (user goal)
[__1] trying: hadrian:+selftest
[__2] trying: QuickCheck-2.14.2 (dependency of hadrian +selftest)
[__3] trying: splitmix-0.1.0.4 (dependency of QuickCheck)
[__4] next goal: base (dependency of hadrian)
[__4] rejecting: base-4.19.0.0/installed-inplace (conflict: splitmix =>
base>=4.3 && <4.19)
...
[__4] fail (backjumping, conflict set: base, hadrian, splitmix)
After searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: base, QuickCheck, splitmix, hadrian,
hadrian:selftest
```
## Environment
```
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 9.8.1
$ cabal --version
cabal-install version 3.10.2.1
compiled using version 3.10.1.0 of the Cabal library
$ uname -a
Linux ...... 6.1.0-17-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.69-1 (2023-12-30) x86_64 GNU/Linux
```Ben GamariBen Gamarihttps://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/24478Move command line flags out of `GHC.Driver.Session`2024-02-27T15:45:53ZJadeMove command line flags out of `GHC.Driver.Session`Related to #24477:
Move flag specific stuff out of `GHC.Driver.Session`
This enables importing constants (such as the implied extensions) without needing to resolve import cycles.Related to #24477:
Move flag specific stuff out of `GHC.Driver.Session`
This enables importing constants (such as the implied extensions) without needing to resolve import cycles.https://gitlab.haskell.org/ghc/ghc/-/issues/24477When suggesting Language Extensions, also suggest Extensions which imply them2024-03-27T21:54:17ZJadeWhen suggesting Language Extensions, also suggest Extensions which imply themGHC sometimes suggests enabling language extensions. In some cases, the user might not have wanted just that extension, but an extension which implies it.
So far, this is done more-or-less when suggesting `forall` without `-XExplicitFo...GHC sometimes suggests enabling language extensions. In some cases, the user might not have wanted just that extension, but an extension which implies it.
So far, this is done more-or-less when suggesting `forall` without `-XExplicitForAll`. Here the suggested fix is:
```
Perhaps you intended to use RankNTypes
or a similar language extension to enable explicit-forall syntax: forall <tvs>. <type>
```
!12112 seeks to improve this and instead suggest
```
Use ExplicitForAll (implied by RankNTypes and ScopedTypeVariables)
to enable syntax: forall <tvs>. <type>
```
I think it could make sense to add this in general whenever a language extension is suggested that has others that imply it. This would for example, when suggesting `ExplicitNamespaces` add `(implied by TypeFamilies and TypeOperators)`.
As for the implementation of this change there are problems, specifically that importing `GHC.Driver.Session(impliedXFlags)` from `GHC.Types.Hint.Ppr` leads to various module dependency cycles.
@bgamari suggested to move flags from `GHC.Driver.Session`: #24478JadeJadehttps://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/24475byte-code-and-object-code unnecessarily generate interface objects in interpr...2024-03-05T11:27:03ZIan-Woo Kimbyte-code-and-object-code unnecessarily generate interface objects in interpreter mode## Summary
if GHCi is invoked with -fbyte-code-and-object-code only, this option does not have any effect from the user's perspective. Byte code objects are already generated as the necessary GHCi operation, but additional interface obj...## Summary
if GHCi is invoked with -fbyte-code-and-object-code only, this option does not have any effect from the user's perspective. Byte code objects are already generated as the necessary GHCi operation, but additional interface objects are generated and held in memory. This should be regarded as feature misalignment and we need to turn that operation off if GHC mode is the interpreter mode.
A repl session without `-fbyte-code-and-object-code`
heap profile:
![Screenshot_2024-02-23_at_8.52.50_AM](/uploads/a5a09a8b333c2d1722da386eb28a4e0a/Screenshot_2024-02-23_at_8.52.50_AM.png)
detailed:
![Screenshot_2024-02-23_at_8.55.21_AM](/uploads/1c8040f972f3779ecd733bd681e68270/Screenshot_2024-02-23_at_8.55.21_AM.png)
The same repl session with `-fbyte-code-and-object-code`
heap profile:
![Screenshot_2024-02-23_at_8.54.25_AM](/uploads/e95ad4ce60f08e347fd8d3978f1bb8cf/Screenshot_2024-02-23_at_8.54.25_AM.png)
detailed:
![Screenshot_2024-02-23_at_8.56.44_AM](/uploads/aae9b42a1a4302851ebafc2368c81c34/Screenshot_2024-02-23_at_8.56.44_AM.png)
## Steps to reproduce
Take a big project for the build of which GHC memory footprint is large.
Open a GHCi repl session with and without `-fbyte-code-and-object-code` and compare the memory usage.
## Expected behavior
The flag which does not have any impact should not give different resource usage.
## Environment
* GHC version used: 9.6.3
Optional:
* Operating System: macOS Sonoma 14.3
* System Architecture: Apple M1 MaxZubinZubinhttps://gitlab.haskell.org/ghc/ghc/-/issues/24474Passing -g3 to GHC causes Cmm lexer errors2024-02-27T19:13:31ZArsen ArsenovićPassing -g3 to GHC causes Cmm lexer errors## Summary
On a GCC system, if building a Cmm file with `-optc-g3`, the build fails with a lexer error on defines emitted by `cc -E` due to having a debug level higher than two. A related issue was reported as https://gitlab.haskell.or...## Summary
On a GCC system, if building a Cmm file with `-optc-g3`, the build fails with a lexer error on defines emitted by `cc -E` due to having a debug level higher than two. A related issue was reported as https://gitlab.haskell.org/ghc/ghc/-/issues/18996
Some triage was already done on IRC and we concluded that `cc -E` emits defines when the debug-level is greater than two, which trips up the Cmm compiler. The purpose of this is to generate debug info. As this is unnecessary when simply preprocessing Cmm files we've concluded that we could just pass `-g0` (and indeed adding `-optc-g0` suppresses the error) whenever this kind of preprocessing is needed. This'd require a `configure`-time check for the availability of `-g0`.
We've also noticed that `-optp` flags appear not to be passed to the Cmm preprocessing step, and we concluded that this happens because `cppUseCc` is set to `True` in the `CmmCpp` phase. To address this, @alt-romes was considering passing preprocessor flags to CC when it is used as the preprocessor, but was worried that this might be dangerous (if cpp and cc differ in supported flags). If GHC was to do that, then adding `-g0` if supported to preprocessor flags would cover both cases.
All things considered, it seems reasonable to me to pass `-g0` if supported individually to both `cpp` and `cc -E` (so, configure-testing both and passing both).
## Steps to reproduce
1. Create an empty Test.cmm
2. Run `ghc` with `-optc-g3`
```
~$ >Test.cmm
~$ ghc -c -odir f/ Test.cmm -optc-g3
<built-in>:0:2: error: Cmm lexical error
~ 1 $
```
## Expected behavior
Produce a `Test.o` without error
## Environment
* GHC version used: The Glorious Glasgow Haskell Compilation System, version 9.2.8
Optional:
* Operating System: Gentoo GNU/Linux
* System Architecture: x86_64-pc-linux-gnuhttps://gitlab.haskell.org/ghc/ghc/-/issues/24473wasm cross-compiler doesn't compile with `+werror`2024-02-27T15:39:08ZBen Gamariwasm cross-compiler doesn't compile with `+werror`It appears that the Wasm backend isn't `-Werror` clean. Specifically, this fails:
```
$ nix develop ghc.nix#devShells.x86_64-linux.wasi-cross
$ ./boot
$ configure_ghc
$ hadrian/build --flavour=default+werror
```
The first errors that are...It appears that the Wasm backend isn't `-Werror` clean. Specifically, this fails:
```
$ nix develop ghc.nix#devShells.x86_64-linux.wasi-cross
$ ./boot
$ configure_ghc
$ hadrian/build --flavour=default+werror
```
The first errors that are encountered are a number of RTS warnings.Cheng ShaoCheng Shaohttps://gitlab.haskell.org/ghc/ghc/-/issues/24472Eliminate string-y Id lookups in Wasm backend2024-02-25T00:10:49ZBen GamariEliminate string-y Id lookups in Wasm backendIt appears that the Wasm backend has a rather atypical way of referring to `base` declarations. For instance, `GHC.HsToCore.Foreign.Wasm` has many mentions like:
```haskell
unsafeDupablePerformIO_id <-
lookupGhcInternalVarId
...It appears that the Wasm backend has a rather atypical way of referring to `base` declarations. For instance, `GHC.HsToCore.Foreign.Wasm` has many mentions like:
```haskell
unsafeDupablePerformIO_id <-
lookupGhcInternalVarId
"GHC.Internal.IO.Unsafe"
"unsafeDupablePerformIO"
```
This is very brittle and inconsistent with how similar references occur elsewhere in GHC. Specifically, this sort of reference should be realized by giving the declaration a known-key name (c.f. `GHC.Builtin.Names`) and using `dsLookupGlobalId` to lookup the identifier.Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/24471Float out can take quadratic time2024-03-06T19:19:35ZJaro ReindersFloat out can take quadratic time## Summary
I've written a simple Template Haskell program that produces nested expressions. If these programs get large then it can take very long to compile them.
## Steps to reproduce
```haskell
{-# LANGUAGE TemplateHaskell #-}
modu...## Summary
I've written a simple Template Haskell program that produces nested expressions. If these programs get large then it can take very long to compile them.
## Steps to reproduce
```haskell
{-# LANGUAGE TemplateHaskell #-}
module Common where
data List_ a f = Nil_ | Cons_ a f deriving Functor
between alg a b
| a == b = [|| $$alg Nil_ ||]
| otherwise = [|| $$alg (Cons_ a $$(between alg (a + 1) b)) ||]
```
```haskell
{-# LANGUAGE TemplateHaskell #-}
module Foo where
import Common
foo :: (List_ Int a -> a) -> a
foo alg = $$(between [|| alg ||] 0 1000)
```
If we compile this with `ghc -O Foo.hs -ddump-timings` we will see the float out timings. If I change the third argument of between from 1000 we can see how it scales:
| size | 2nd float-out time (ms) |
| ------: | ------: |
| 1000 | 601 |
| 2000 | 2595 |
| 3000 | 5862 |
| 4000 | 10944 |
| 5000 | 18825 |
| 6000 | 25289 |
| 7000 | 34933 |
| 8000 | 49785 |
| 9000 | 61680 |
| 10000 | 76162 |
So it seems float-out takes quadratic time in this case.
In particular, I'm looking at the second float out pass, which looks like this in the dump:
```
*** Float out(FOS {Lam = Just 0,
Consts = True,
OverSatApps = True}) [Foo]:
Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = True}) [Foo]: alloc=205141562384 time=76162.434
```
Also the remaining timings do seem to scale linearly. With code generation taking the most time besides that second float out pass.
## Expected behavior
Compile faster.
## Environment
* GHC version used: 9.8.1Jaro ReindersJaro Reinders