Duncan Coutts pushed to branch wip/dcoutts/capability-yield at Glasgow Haskell Compiler / GHC Commits: ed09895d by Andreas Klebinger at 2026-07-08T16:53:27-04:00 Fix a profiling race condition resulting in segfaults. StgToCmm: Don't assume tagged FUN closures in closureCodeBody. When entering a closure the self/node pointer might not be tagged in some situations when a thunk is evaluated by multiple threads. So we most AND away the tag bits rather than subtracting an expected tag. Apply.cmm: Fix a race condition occuring when a thunk is mutated during GC. In stg_ap_0_fast when might need to run GC before entering a thunk. If this happens another thread or the GC itself might mutate the closure making entering it no longer valid. We now check for this. Add test and changelog for #27123 fixes. - - - - - 67c03eb2 by Cheng Shao at 2026-07-08T16:54:09-04:00 ghc-heap: fix invalid srtlen returned by peekItbl when no-TNTC This patch fixes the no-TNTC code path of `peekItbl` so that it looks at the right memory address when reading the `srt` field from the `StgInfoTable_` struct. Also adds a `T27465` regression test that reproduces the bug on no-TNTC builds before the fix. Fixes #27465. Co-authored-by: Codex <codex@openai.com> - - - - - 2ecabb4f by Zubin Duggal at 2026-07-09T09:23:25-04:00 hadrian: binary-dist-dir should not be the default target Revert behaviour to pre 23c9b6c392f52ec9d7a8618b204ff6b885f5fba2 In 23c9b6c392f52ec9d7a8618b204ff6b885f5fba2, we applied the following behaviour change: ``` hadrian: Build stage 2 cross compilers ... * hadrian: Make binary-dist-dir the default build target. This allows us to have the logic in one place about which libraries/stages to build with cross compilers. Fixes #24192 ``` This is a major regression to development experience, a plain hadrian/build --freeze1 now takes ages because we rebuild all docs (which need to go in the binary dist dir). `binary-dist-dir` is the wrong default target for regular GHC development work Fixes #27445 - - - - - e16388e3 by Zubin Duggal at 2026-07-09T09:23:25-04:00 .gitignore: Add the hadrian system.config introduced by commit 23c9b6c392f52ec9d7a8618b204ff6b885f5fba2 Since commit 23c9b6c392f52ec9d7a8618b204ff6b885f5fba2 Author: Matthew Pickering <matthewtpickering@gmail.com> Date: Thu Dec 21 16:17:41 2023 +0000 hadrian: Build stage 2 cross compilers ./configure produces /hadrian/cfg/system.config.{host,target} Add these to .gitignore - - - - - 7e8abf41 by Alan Zimmerman at 2026-07-09T09:24:12-04:00 EPA: Replace AnnListItem with simply [TrailingAnn] Remove the unnecessary wrapper around a single field. - - - - - 29032f17 by Zubin Duggal at 2026-07-09T09:24:58-04:00 testsuite: Keep real reason for fragile test failures - - - - - c34e03a7 by Zubin Duggal at 2026-07-09T09:24:58-04:00 testsuite: Fall back to the failure reason for empty JUnit bodies - - - - - 409d40f0 by Zubin Duggal at 2026-07-09T09:24:58-04:00 testsuite: Show output diffs in JUnit output Also refactor compare_outputs to return essentially a `Maybe Diff` (`CompareOutput`) instead of a bool, but more pythonic. This allows us to pass the diff through nice. - - - - - 06fee1ab by Zubin Duggal at 2026-07-09T09:24:58-04:00 perf notes: include stat deviation and acceptance window in notes so they show up in gitlab - - - - - 57c0f32c by mangoiv at 2026-07-10T11:08:38-04:00 driver: enable -finter-module-far-jumps by default this fixes a compatibility bug with certain binutils/gcc versions where we were seeing jump offset overflow errors. This commit can probably reverted if we stop supporting the problematic binutils/gcc verions (2.44 and 14.2, respectively) Reolves #26994 - - - - - 4396a6f2 by Andrea Vezzosi at 2026-07-10T11:09:25-04:00 [Fix #27287] preserve ModBreaks in ModIface - - - - - ed261a7e by Cheng Shao at 2026-07-14T17:59:38-04:00 hadrian: fix HLS support This patch fixes hadrian's HLS support so one can rely on HLS when working on the hadrian codebase. Fixes #27480. Not building/linking shared libraries for hadrian is a severely premature optimization; this top-level setting in `cabal.project` only affects home packages while the dependencies in the cabal store are built with vanilla/dynamic anyway, and even adding dynamic builds to home packages would not be costly due to cabal's usage of `-dynamic-too`. - - - - - eee8ec5b by Cheng Shao at 2026-07-14T18:00:20-04:00 compiler: fix miscompiled %load_relaxed, add missing %store_relaxed This patch fixes the %load_relaxed cmm primop compilation logic to correctly use relaxed memory ordering, and adds the missing %store_relaxed primop. Parsing logic of %load/%store with explicit ordering is covered in the AtomicFetch test case. Fixes #27483. Co-authored-by: Codex <codex@openai.com> - - - - - 1718230f by Alan Zimmerman at 2026-07-14T18:01:06-04:00 EPA: Keep binds and sigs together in HsValBindsLR We combine them into a single list for GhcPs, wrapped in the ValBind data type, which is the bind equivalent of ValD, having constructors for binds and sigs. This simplifies exact print processing, especially when using it to update the contents of local binds, as we no longer need AnnSortKey BindTag - - - - - 6bd1ad2a by Andreas Klebinger at 2026-07-14T18:01:49-04:00 Bump nofib submodule to account for MonoLocalBinds. New versions of GHC enable MonoLocalBinds by default. This breaks some of the benchmarks. I've fixed this and this bump pulls in that fix. - - - - - 7eb0f1c9 by Cheng Shao at 2026-07-14T18:02:31-04:00 testsuite: fix bytecodeIPE test under +ipe flavours This patch fixes the bytecodeIPE test under +ipe flavours. It used to fail under +ipe because the RTS is built with IPE info, then stg_AP_info in RTS carries IPE info, so whereFrom wouldn't return Nothing. Now the test checks IPE info of a datacon in the ghci-loaded module which is not affected by whether the RTS is built with IPE info or not. Fixes #27498. Co-authored-by: Codex <codex@openai.com> - - - - - ef038aae by cydparser at 2026-07-15T04:35:41-04:00 Reduce bytes allocated for `capabilities` in RTS (fixes #27487) In rts/Capability.c, `capabilities` is an array of pointers, but it was allocated as if it were an array of Capability's. - - - - - d377e83e by Cheng Shao at 2026-07-15T04:36:27-04:00 rts: fix missing UNTAG in stg_readTVarIOzh This patch fixes missing UNTAG on the current value closure read from StgTVar. UNTAG is a no-op when it's stg_TREC_HEADER_info which is word aligned; it may be a tagged closure, and reading info table from the tagged address is an unaligned load which may cause issues on platforms with strict alignment requirements. Co-authored-by: Codex <codex@openai.com> - - - - - 8ed03842 by Cheng Shao at 2026-07-15T04:36:27-04:00 rts: fix missing UNTAG in stg_control0zh_ll This patch fixes missing UNTAG on the cont closure returned by captureContinuationAndAbort. In case it's not NULL, captureContinuationAndAbort returns a tagged StgContinuation closure, in which case it must be untagged before accessing the apply_mask_frame field. In the past it worked out of luck: when apply_mask_frame was NULL then mask_frame_offset is also 0 so the control flow didn't diverge to a wrong path. Still, this is horribly wrong and will crash once StgContinuation struct is refactored and fields are shuffled around. Co-authored-by: Codex <codex@openai.com> - - - - - 5aa7000a by Cheng Shao at 2026-07-15T04:37:08-04:00 compiler: fix redundant AP thunk codegen when not using -ticky-ap-thunk This patch fixes a double negation confusion in !7525 that results in some redundant AP thunk code generation when not using -ticky-ap-thunk. Now, we use `stgToCmmUseStdApThunk` to indicate whether precomputed AP thunks in the RTS should be used, which defaults to `True`, unless `-ticky-ap-thunk` is passed. `-finfo-table-map` now also implies `-ticky-ap-thunk`, since when doing IPE profiling we want the generated AP thunks to be unique. Fixes #27502. ------------------------- Metric Decrease: T3064 ------------------------- Co-authored-by: Codex <codex@openai.com> - - - - - d43a7b7a by Brian McKenna at 2026-07-15T20:10:04+02:00 Strip ticks when desugaring bool guards The special `considerAccessible` pattern was broken when compiling with debug info. Compiling with debug info wraps expressions with `SourceNote` ticks, which broke the internals of the `desugarBoolGuard` function. Ticks are now ignored within this function. Fixes #27360 - - - - - ede4b17b by Ben Gamari at 2026-07-15T22:59:53-04:00 base: Display ExceptionContext in WhileHandling's textual description As originally-implemented the implementation for `WhileHandling(displayExceptionAnnotation)` would display the `ExceptionContext` of the exception which it carries (as this was the behavior of `displayException`, in terms of which `displayExceptionAnnotation` was implemented). However, in 284ffab3 the definition of `SomeException(displayException)` was changed to exclude the `ExceptionContext`. This means that `WhileHandling(displayExceptionAnnotation)` fails to describe the provenance of the exception which it captures, greatly limiting its utility. Return the implementation to its originally-specified behavior by implementing `WhileHandling(displayExceptionAnnotation)` in terms of `displayExceptionWithInfo`. Fixes #27456. - - - - - d3fb1588 by Duncan Coutts at 2026-07-16T12:20:41+01:00 Minor doc & comment improvements to releaseCapability_ - - - - - 0d5a6987 by Duncan Coutts at 2026-07-16T12:20:41+01:00 Remove redundant USED_IF_THREADS attribute on Capability utilities - - - - - 9e097dcb by Duncan Coutts at 2026-07-16T12:20:41+01:00 Move several Capability utils from Schedule.{c,h} to Capability.{c,h} They probably should have been there all along. This means all the pending_sync functionality is within Capability.{c,h}. We only expose pending_sync for the purpose of inline header functions. - - - - - 897972c0 by Duncan Coutts at 2026-07-16T12:20:41+01:00 Shuffle the pending sync type declarations for better readability Move them together into the section with the related functions that use them. Also drop the legacy use of the C 'volatile' modifier on the pending_sync variable. We use C atomics for such access, not volatile. - - - - - d64f590b by Duncan Coutts at 2026-07-16T12:20:42+01:00 Rename returning task queue helpers Follows a naming convention elsewhere. It also gives us suitable names to distinguish appending vs prepending to the queue, and we're about to add a prepend operation. - - - - - 77259fa8 by Duncan Coutts at 2026-07-16T12:20:42+01:00 Add a prepend operation for the returning task queue With a pending sync (e.g. for GC), we really want to be able to prioritise the task waiting on the sync over all other returning tasks. To do that we will need to prepend to the queue rather than append. - - - - - 5acee491 by Duncan Coutts at 2026-07-16T12:21:19+01:00 Introduce waitForCapability_ with additional priority arg Split waitForCapability into a wrapper with the existing type (since it is exported via the RTS API) and a worker with an extra argument. The new high_priority argument controls whether the task is appended or prepended to the returing task queue. The default, used by the waitForCapability wrapper, is false, meaning append to the end of the queue. This gives fairness. - - - - - 25abd1ea by Duncan Coutts at 2026-07-16T12:21:19+01:00 Make acquireAllCapabilities use high_priority on waitForCapability_ As discussed in issue #27473, a sync of all capabilities is something that needs to happen promptly (but often doesn't). One source of delay is that acquireAllCapabilities using waitForCapability would put the task trying to acquire each capability at the _end_ of the returning task queue. This gave every other returing task a full timeslice to run. Meanwhile, several other capabilities are blocked waiting for the sync to complete, leading to a loss of throughput. We use the new high_priority arg to waitForCapability_ to ensure that the requesting task is put on the front of the returing task queue. This will ensure that releaseCapability_ will prioritise giving the capability to the task requesting the sync. - - - - - 45e34877 by Duncan Coutts at 2026-07-16T12:21:19+01:00 In releaseCapability_ make the pending_sync case self-contained Previously the pending_sync case had to be checked _after_ the returning tasks case, since one of the possibilities (indeed the more likely possibility) is that the task calling waitForCapability will have enqueued itself as a returning task. Now we make the pending_sync case self-contained. We note in a comment the two possibilities: either the task calling waitForCapability has enqueued itself already and is waiting, or it's not got there yet. We can handle the first case by giving the capability to the task at the head of the returning tasks queue, and the second case by leaving the capability free. Another way to look at this, is that we move a special case of handling of the returning task case into the pending_sync case. That special case being a returing task during a pending sync. This makes the order of handling returning tasks vs pending sync independent. This is good, because really they're in the wrong priority order and we want to flip them around. - - - - - eef104e8 by Duncan Coutts at 2026-07-16T12:21:19+01:00 In releaseCapability_ prioritise pending sync over returning tasks Fixes issue #27460 As explained in the issue, a pending sync (e.g. for GC) should be dealt with promptly. Returning tasks are a lower priority. Historically however we had to check returning tasks first, because the synchronisation mechanism mixed up the task doing a sync with the tasks returning from safe FFI calls. The task performing the sync was very likely to be queued on the returning task list (and historically it was at the _end_ of this list!). We have now arranged that the task performing the sync is at the front of the returning task list, and in the pending sync case we now check the returning task list and run the first task from there if it there is one. This is by no means perfect, but it is better. See issue #27473 for a more general issue of cleaning up the design of the pending sync. - - - - - 89709edc by Duncan Coutts at 2026-07-16T12:21:19+01:00 Extend releaseCapability_ with an extra wakeup_worker modifier Document within releaseCapability_ the basic approach of looking for a series of conditions in priority order and acting on them. Explain the existing modifier within that understanding. Then add a new modifier, wakeup_worker and explain it in similar terms. What it does is skip two of the conditions in the priority list, with the effect that we prioritise waking up a worker task over a returning task or bound task. This feature is not yet used in this commit, but it will be used as part of a scheme to allow in-RTS I/O managers in the threaded RTS. This scheme will make use of being able to start a background worker thread, and that will use this feature to start it promptly. Also correct the yieldCapability docs to cover all the conditions, and in priority order for consistency. - - - - - 457d5a4c by Duncan Coutts at 2026-07-16T12:21:19+01:00 Move enqueueWorker next to where it is used. It's not general purpose at all. It's very specifically crafted to work with it's only caller: yieldCapability. It does very suprising things like releaseCapability_, release locks and terminate threads. This logic would be much clearer if done within yieldCapability. - - - - - a110ec95 by Duncan Coutts at 2026-07-16T12:21:19+01:00 Move code out of enqueueWorker and into releaseCapability_ Instead of directly releasing locks and terminating tasks, have it return whether the enqueue was successful or not. In the latter case, releaseCapability_ itself will release locks and terminate the task. This makes the logic of releaseCapability_ a lot clearer. Fiddling with tasks is what releaseCapability_ does, so it's better not to try and encapsulate this within a helper function. - - - - - f92cb931 by Duncan Coutts at 2026-07-16T12:21:19+01:00 Clarify the logic and control flow in yieldCapability yieldCapability is unfortunately a bit complicated. This change restructures things slightly but should keep the behaviour the same. Previously after calling releaseCapability_ we had a bunch of alternatives, where in each branch we would use RELEASE_LOCK(cap->lock) and do various things before/after the lock is released. This was a bit hard to follow, or to extend (which we need to do). So now we have unconditional acquire and release of the cap->lock, so it's clear where that happens, with releaseCapability_ in between. Then in between these steps we have the various other pre/post actions. Some before releaseCapability_, some after while holing the lock, and some after having released the lock. We explain this structure in a longer comment, and refer back to the structure from the code. - - - - - 129 changed files: - .gitignore - + changelog.d/T27123.md - + changelog.d/T27360 - + changelog.d/T27456 - + changelog.d/fix-cmm-atomic-load-store - + changelog.d/fix-peekitbl-no-tntc - + changelog.d/fix-use-std-ap-thunk - + changelog.d/inter-module-far-jumps-aarch64-default - compiler/GHC/ByteCode/Breakpoints.hs - compiler/GHC/ByteCode/Types.hs - compiler/GHC/Cmm/Parser.y - compiler/GHC/Driver/Config/StgToCmm.hs - compiler/GHC/Driver/DynFlags.hs - compiler/GHC/Driver/Flags.hs - compiler/GHC/Driver/Main/Compile.hs - compiler/GHC/Driver/Main/Hsc.hs - compiler/GHC/Driver/Main/Passes.hs - compiler/GHC/Hs/Binds.hs - compiler/GHC/Hs/Dump.hs - compiler/GHC/Hs/Instances.hs - compiler/GHC/Hs/Utils.hs - compiler/GHC/HsToCore/Breakpoints.hs - + compiler/GHC/HsToCore/Breakpoints/Types.hs - compiler/GHC/HsToCore/Pmc/Desugar.hs - compiler/GHC/HsToCore/Quote.hs - compiler/GHC/HsToCore/Ticks.hs - compiler/GHC/Iface/Ext/Ast.hs - compiler/GHC/Iface/Load.hs - compiler/GHC/Iface/Make.hs - compiler/GHC/Iface/Recomp.hs - compiler/GHC/Parser.y - compiler/GHC/Parser/Annotation.hs - compiler/GHC/Parser/PostProcess.hs - compiler/GHC/Platform/Ways.hs - compiler/GHC/Rename/Bind.hs - compiler/GHC/Rename/Expr.hs - compiler/GHC/Rename/Module.hs - compiler/GHC/Rename/Names.hs - compiler/GHC/Rename/Utils.hs - compiler/GHC/Runtime/Eval.hs - compiler/GHC/StgToCmm/Bind.hs - compiler/GHC/StgToCmm/Config.hs - compiler/GHC/Tc/Deriv.hs - compiler/GHC/Tc/Gen/Head.hs - compiler/GHC/ThToHs.hs - compiler/GHC/Unit/Module/ModGuts.hs - compiler/GHC/Unit/Module/ModIface.hs - compiler/GHC/Unit/Module/WholeCoreBindings.hs - compiler/GHC/Utils/Binary.hs - compiler/Language/Haskell/Syntax/Binds.hs - compiler/Language/Haskell/Syntax/Extension.hs - compiler/ghc.cabal.in - docs/users_guide/using-optimisation.rst - ghc/GHCi/UI.hs - hadrian/cabal.project - hadrian/src/Rules.hs - hadrian/src/Rules/BinaryDist.hs - libraries/base/changelog.md - libraries/base/tests/T15349.stderr - + libraries/ghc-heap/tests/T27465.hs - + libraries/ghc-heap/tests/T27465.stdout - libraries/ghc-heap/tests/all.T - libraries/ghc-internal/src/GHC/Internal/Exception/Type.hs - libraries/ghc-internal/src/GHC/Internal/Heap/InfoTable.hsc - libraries/ghc-internal/src/GHC/Internal/Heap/InfoTableProf.hsc - libraries/ghc-internal/tests/backtraces/T14532b.stdout - nofib - rts/Apply.cmm - rts/Capability.c - rts/Capability.h - rts/ContinuationOps.cmm - rts/Messages.c - rts/PrimOps.cmm - rts/RtsAPI.c - rts/Schedule.c - rts/Schedule.h - testsuite/driver/junit.py - testsuite/driver/perf_notes.py - testsuite/driver/testglobals.py - testsuite/driver/testlib.py - testsuite/driver/testutil.py - testsuite/tests/cmm/should_run/AtomicFetch.hs - testsuite/tests/cmm/should_run/AtomicFetch_cmm.cmm - testsuite/tests/codeGen/should_run/cgrun025.stderr - testsuite/tests/count-deps/CountDepsParser.stdout - testsuite/tests/exceptions/T26759.stderr - testsuite/tests/ghc-api/T25121_status.stdout - testsuite/tests/ghc-api/exactprint/T22919.stderr - testsuite/tests/ghc-api/exactprint/Test20239.stderr - testsuite/tests/ghc-api/exactprint/ZeroWidthSemi.stderr - testsuite/tests/ghc-e/should_fail/T18441fail7.stderr - testsuite/tests/ghci/scripts/bytecodeIPE.hs - testsuite/tests/ghci/should_run/Makefile - + testsuite/tests/ghci/should_run/T27287.hs - + testsuite/tests/ghci/should_run/T27287.stdout - testsuite/tests/ghci/should_run/all.T - testsuite/tests/haddock/should_compile_flag_haddock/T17544.stderr - testsuite/tests/haddock/should_compile_flag_haddock/T17544_kw.stderr - testsuite/tests/haddock/should_compile_flag_haddock/T24221.stderr - testsuite/tests/mdo/should_fail/mdofail006.stderr - testsuite/tests/module/mod185.stderr - testsuite/tests/parser/should_compile/DumpParsedAst.stderr - testsuite/tests/parser/should_compile/DumpParsedAstComments.stderr - testsuite/tests/parser/should_compile/DumpRenamedAst.stderr - testsuite/tests/parser/should_compile/DumpSemis.stderr - testsuite/tests/parser/should_compile/DumpTypecheckedAst.stderr - testsuite/tests/parser/should_compile/KindSigs.stderr - testsuite/tests/parser/should_compile/T14189.stderr - testsuite/tests/parser/should_compile/T15323.stderr - testsuite/tests/parser/should_compile/T20452.stderr - testsuite/tests/parser/should_compile/T20718.stderr - testsuite/tests/parser/should_compile/T20718b.stderr - testsuite/tests/parser/should_compile/T20846.stderr - testsuite/tests/parser/should_compile/T23315/T23315.stderr - + testsuite/tests/pmcheck/should_compile/T27360.hs - testsuite/tests/pmcheck/should_compile/all.T - testsuite/tests/printer/AnnotationNoListTuplePuns.stdout - testsuite/tests/printer/T18791.stderr - testsuite/tests/printer/Test20297.stdout - testsuite/tests/printer/Test24533.stdout - + testsuite/tests/rts/T27123.hs - testsuite/tests/rts/all.T - testsuite/tests/runghc/T7859.stderr-mingw32 - testsuite/tests/typecheck/should_compile/T15242.stderr - testsuite/tests/typecheck/should_compile/all.T - utils/check-exact/ExactPrint.hs - utils/check-exact/Main.hs - utils/check-exact/Transform.hs - utils/check-exact/Utils.hs The diff was not included because it is too large. View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/70d06f73492820ccdd30f0e27ca7d43... -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/70d06f73492820ccdd30f0e27ca7d43... You're receiving this email because of your account on gitlab.haskell.org. Manage all notifications: https://gitlab.haskell.org/-/profile/notifications | Help: https://gitlab.haskell.org/help