Commits on Source (24)
-
The lazy structure (a list) in a strict field in `DmdType` is not fully forced which leads to a very large thunk build-up. It seems there is likely still more work to be done here as it seems we may be trading space usage for work done. For now, this is the right choice as rather than using all the memory on my computer, compilation just takes a little bit longer. See #25196
3a5bebf8 -
We need to ensure that when we convert an `InvisP` (invisible type pattern) to a `Pat`, we parenthesize it (at precedence `appPrec`) so that patterns such as `@(a :: k)` will parse correctly when roundtripped back through the parser. Fixes #25209.
c2525e9e -
Sjoerd Visscher authored
This flag makes sure to avoid recompilation of the code when generating documentation by only reading the .hi and .hie files, and throw an error if it can't find them.
Unverified1499764f -
This commit adds `isByteArrayWeaklyPinned#` and `isMutableByteArrayWeaklyPinned#` primops. These check if a bytearray is *weakly* pinned. Which means it can still be explicitly moved by the user via compaction but won't be moved by the RTS. This moves us one more stop closer to nailing down #22255.
768fe644 -
Fixes #25211 When linking bytecode for TH from interface core bindings with `-fprefer-byte-code`, foreign sources are loaded from the interface as well and compiled to object code in an ad-hoc manner. The results are then loaded by the interpreter, whose way may differ from the current build's target way. This patch ensures that foreign objects are compiled with the interpreter's way.
83e70b14 -
This patch fixes an error message in checkClosure() when the closure has already been evacuated. The previous logic was meant to print the evacuated closure's type in the error message, but it was completely wrong, given info was not really an info table, but a tagged pointer that points to the closure's new address.
0d3bc2fa -
GCC and CLang translate the built-in `atomic_thread_fence(memory_order_acquire)` to `dmb ishld`, which is a bit less restrictive than `dmb ish` (which also implies stores.)
fb0a4e5c -
Performance metrics collected via 'perf' can be more accurate for run-time performance than GHC's rts, due to the usage of hardware counters. We allow performance tests to also record PMU events according to 'perf list'.
a45f1488 -
ce61fca5
-
6dfb9471
-
This commit adds extra logic when looking up a record constructor. If GHC.Rename.Env.lookupOccRnConstr returns a TyCon (as it may, due to the logic explained in Note [Pattern to type (P2T) conversion]), we emit an error saying that the data constructor is not in scope. This avoids the compiler falling over shortly thereafter, in the call to 'lookupConstructorInfo' inside 'GHC.Rename.Env.lookupRecFieldOcc', because the record constructor would not have been a ConLike. Fixes #25056
da306610 -
When there are multiple threads they can race to create a temporary file, in some situations the thread will create ghc_1.c and in some it will create ghc_2.c. This filename ends up in the debug info for object files after compiling a C file, therefore contributes to object nondeterminism. In order to fix this we store a prefix in `TmpFs` which serves to namespace temporary files. The prefix is populated from the counter in TmpFs when the TmpFs is forked. Therefore the TmpFs must be forked outside the thread which consumes it, in a deterministic order, so each thread always receives a TmpFs with the same prefix. This assumes that after the initial TmpFs is created, all other TmpFs are created from forking the original TmpFs. Which should have been try anyway as otherwise there would be file collisions and non-determinism. Fixes #25224
9c354beb -
This is an unfortunate consequence of two mechanisms: * GHC provides (possibly-empty) lists of names * The functions that retrieve those names are not equipped to do error reporting, and thus accept these lists at face value. They will have to be attached an effect for error reporting in a later refactoring
59906975 -
There is one tricky aspect with wired-in packages where the boot package is built with `-this-unit-id ghc` but the dependency is reported as `-package-id ghc-9.6...`. This has never been fixed in GHC as the situation of loading wired-in packages into the multi-repl seems like quite a niche feature that is always just easier to workaround.
8afbab62 -
This seems to make a bit more sense than just loading `ghc` component (and dependencies).
6cac9eb8 -
There have recently been some determinism issues with the simplifier and documentation. We enable more things to test in the ABI test to check that we produce interface files deterministically.
7d84df86 -
Sylvain Henry authored
Before unarisation we may have code like: Test.foo :: Test.D [GblId, Unf=OtherCon []] = \u [] case (# |_| #) [GHC.Types.(##)] of sat_sAw [Occ=Once1] { __DEFAULT -> Test.D [GHC.Types.True sat_sAw]; }; After unarisation we get: Test.foo :: Test.D [GblId, Unf=OtherCon []] = {} \u [] Test.D [GHC.Types.True 2#]; Notice that it's still an Updatable closure for no reason anymore. This patch transforms appropriate StgRhsClosures into StgRhsCons after unarisation, allowing these closures to be statically allocated. Now we get the expected: Test.foo :: Test.D [GblId, Unf=OtherCon []] = Test.D! [GHC.Types.True 2#]; Fix #25166 To avoid duplicating code, this patch refactors the mk(Top)StgRhs functions and put them in a GHC.Stg.Make module alongside the new mk(Top)StgRhsCon_maybe functions.
5456e02e -
958b4518
-
Sven Tennie authored
This has likely been forgotten.
573f9833 -
20b0de7d
-
The JS backend doesn't support adjustors (I believe) and in any case if it ever supports them it will be a native support, not one via libffi.
03055c71 -
Alan Zimmerman authored
This just causes confusion.
db092e30
Showing
- .gitlab/ci.sh 3 additions, 3 deletions.gitlab/ci.sh
- .gitlab/generate-ci/gen_ci.hs 23 additions, 0 deletions.gitlab/generate-ci/gen_ci.hs
- .gitlab/jobs.yaml 63 additions, 0 deletions.gitlab/jobs.yaml
- compiler/GHC/Builtin/primops.txt.pp 19 additions, 1 deletioncompiler/GHC/Builtin/primops.txt.pp
- compiler/GHC/CmmToAsm/AArch64/CodeGen.hs 7 additions, 3 deletionscompiler/GHC/CmmToAsm/AArch64/CodeGen.hs
- compiler/GHC/CmmToAsm/AArch64/Instr.hs 22 additions, 6 deletionscompiler/GHC/CmmToAsm/AArch64/Instr.hs
- compiler/GHC/CmmToAsm/AArch64/Ppr.hs 2 additions, 1 deletioncompiler/GHC/CmmToAsm/AArch64/Ppr.hs
- compiler/GHC/CoreToStg.hs 22 additions, 173 deletionscompiler/GHC/CoreToStg.hs
- compiler/GHC/Driver/Config/Stg/Pipeline.hs 14 additions, 9 deletionscompiler/GHC/Driver/Config/Stg/Pipeline.hs
- compiler/GHC/Driver/Main.hs 26 additions, 5 deletionscompiler/GHC/Driver/Main.hs
- compiler/GHC/Driver/Make.hs 18 additions, 13 deletionscompiler/GHC/Driver/Make.hs
- compiler/GHC/Parser.y 5 additions, 5 deletionscompiler/GHC/Parser.y
- compiler/GHC/Parser/Annotation.hs 5 additions, 14 deletionscompiler/GHC/Parser/Annotation.hs
- compiler/GHC/Parser/PostProcess.hs 3 additions, 3 deletionscompiler/GHC/Parser/PostProcess.hs
- compiler/GHC/Rename/Env.hs 27 additions, 16 deletionscompiler/GHC/Rename/Env.hs
- compiler/GHC/Rename/Expr.hs 2 additions, 2 deletionscompiler/GHC/Rename/Expr.hs
- compiler/GHC/Stg/Make.hs 172 additions, 0 deletionscompiler/GHC/Stg/Make.hs
- compiler/GHC/Stg/Pipeline.hs 9 additions, 1 deletioncompiler/GHC/Stg/Pipeline.hs
- compiler/GHC/Stg/Stats.hs 3 additions, 0 deletionscompiler/GHC/Stg/Stats.hs
- compiler/GHC/Stg/Syntax.hs 16 additions, 54 deletionscompiler/GHC/Stg/Syntax.hs
compiler/GHC/Stg/Make.hs
0 → 100644