- ghc-commits - Haskell.org

[Git][ghc/ghc][wip/zip-them-all] 26 commits: testsuite: detect fast bignum via ghc-internal, not removed ghc-bignum
by Bodigrim (＠Bodigrim) 14 Jun '26

14 Jun '26

Bodigrim pushed to branch wip/zip-them-all at Glasgow Haskell Compiler / GHC Commits: 2f3cc9ff by Simon Jakobi at 2026-06-08T07:55:49-04:00 testsuite: detect fast bignum via ghc-internal, not removed ghc-bignum The ghc-bignum package was merged into ghc-internal, so the BIGNUM_GMP probe in test.mk ran `ghc-pkg field ghc-bignum exposed-modules`, which fails with "cannot find package ghc-bignum". That error went to stderr and leaked into the captured stderr of every makefile_test, causing spurious [bad stderr] failures across the suite. The probe also silently returned empty, so config.have_fast_bignum was wrongly False even on GMP builds. Probe ghc-internal's extra-libraries for the gmp library instead: the GMP backend module is an other-module (not exposed), but GMP_LIBS adds gmp to extra-libraries only on a GMP build, so this distinguishes the backends. Redirect stderr to keep any future missing-package error off the harness's stderr. This also removes a stale comment as per suggestion from hsyl20. Co-Authored-By: Claude Opus 4.7 <noreply(a)anthropic.com> - - - - - eb3bf6e7 by Alan Zimmerman at 2026-06-08T07:56:32-04:00 EPA: Rename Transform.anchorEof to addModuleCommentOrigDeltas This now matches what it actually does. - - - - - 498bb21a by David Eichmann at 2026-06-09T18:02:39-04:00 Hadrian: avoid response files when command line is short enough This replaces the logic of always using response files on Windows. With the new condition based on command line lenght, reponse files can be avoided in many more cases (on windows). Now that response files are only used in a small number of cases, response files are always kept and the -r / --keep-response-files command line options have been removed The response file paths are nolonger randomized. They are placed in the `_build/rsp` directory. This ensures they are ignored by git and we that Hadrian reuses response file paths when rebuilding rather than leaving stale response files around. Update user guide putting response files in its own section - - - - - 87f510a5 by Simon Hengel at 2026-06-09T18:03:25-04:00 Don't use non-breaking spaces - - - - - 41a19379 by David Eichmann at 2026-06-09T18:04:11-04:00 Hadrian: remove unused wrapper scripts from windows bindist These wrapper scripts are only installed on non-relocatable builds which are not generally supported on windows. - - - - - ce01ccb6 by sheaf at 2026-06-10T05:08:48-04:00 Don't drop ticks around variables of type `IO ()` GHC.Core.Utils.mkTick is responsible for placing a tick on a Core expression. It contains logic for dropping SCCs (non-counting profiling ticks) around non-function variables, as such variables cannot meaningfully contribute to profiles. However, the logic for what counts as a function was incorrect: it used `isFunTy` which returns 'False' for types such as 'IO ()' where the function arrow is hidden under a newtype. We now use 'mightBeFunTy' instead of 'isFunTy'. This ensures we don't drop ticks in cases we aren't sure. On the way, we improve the documentation of 'isFunTy', 'isPiTy' and 'mightBeFunTy', and update the latter's implementation to consistently handle unary classes. Fixes #27225 ------------------------- Metric Decrease: T5642 ------------------------- - - - - - d311c4f1 by Simon Jakobi at 2026-06-10T05:09:32-04:00 testsuite: Add regression test for #4081 Check that a strict constructor field is unboxed once outside an enclosing loop, not re-inspected each iteration (the float-out case-floating from 9cb20b488). Uses simonpj's `data T a = T !a` example from the ticket; T4081.stderr captures the expected Core. Co-Authored-By: Claude Opus 4.7 <noreply(a)anthropic.com> - - - - - 333df444 by sheaf at 2026-06-10T05:10:25-04:00 Check for cabal-install >= 3.12 upfront Starting with commit 8cb99552f607f6bc4000e45ab32532d50c8bb996, Hadrian requires cabal-install >= 3.12 in order to use the 'cabal path' command that was introduced in version 3.12, as per https://github.com/haskell/cabal/blob/a51c4ee1556d816ad86e90db7e6330dd51b0b… This was not reflected in the Hadrian build script, causing a delayed build failure instead of enforcing the version requirement upfront, which this patch does. Fixes #27317 - - - - - 98c20394 by sheaf at 2026-06-10T05:11:09-04:00 Fix crash in Data.Data instance for HsCtxt The Data.Data instance for HsCtxt contained an error for the 'toConstr' method, which could trigger for example when looking at -ddump-tc-ast traces. Replace it with the 'abstractConstr' pattern used in the rest of the codebase. - - - - - 5ac9ce7d by Zubin Duggal at 2026-06-10T21:26:32+05:30 hadrian: Remove old package.conf files when generating new ones Old package.conf files might exists with different hashes, causing issues like #26661 Fixes #26661 - - - - - c9015f09 by sheaf at 2026-06-11T12:40:28-04:00 Fix AArch64 clobbering bug for MUL2 On AArch64, the code generator could clobber one of the input operands when computing the lower bits of a MUL2 operation. This rendered invalid the subsequent computation of the high bits. This commit fixes that by using a temporary register. The register allocator can remove the redundant move in the common case when the registers do not conflict. Fixes #27046 - - - - - 7ab90288 by Rodrigo Mesquita at 2026-06-11T12:41:11-04:00 fix: make T27131 less flaky It seems that T27131 fails flakily in a race where we check the flag before the capability had the chance to process the mailbox which sets the flag. This seemingly should only happen if the capability ends up being the same for setting and checking the flag. - - - - - 8965cb76 by Marc Scholten at 2026-06-12T04:53:22-04:00 haddock: render modules concurrently - - - - - 8cc0b64a by Duncan Coutts at 2026-06-12T04:54:06-04:00 Promote HAVE_PREEMPTION from Timer.c to OSThreads.h We will want to know about HAVE_PREEMPTION in more places. HAVE_PREEMPTION tells us that we do have OS threads available, irrespective of whether THREADED is defined. In particular, HAVE_PREEMPTION is defined on all proper OSs, but not on WASM (and hyopthetically may not be true on some other platforms like micro-controllers, RTOSs, VM hypervisors etc). - - - - - cce574ed by Duncan Coutts at 2026-06-12T04:54:06-04:00 Define ACQUIRE_LOCK_ALWAYS and friends Fix issue #27335 Like the atomic _ALWAYS variants, these lock actions are always defined, rather than being dependent on whether we are in the THREADED case. All the "normal" LOCK macros are defined to be no-ops when !THREADED. The use case for the _ALWAYS variants is where we are using OS threads even in the non-threaded RTS. This includes everything to do with the timer/ticker thread, which is used in the non-threaded RTS too. In particular, we will want to use this for eventlog things, because the timer thread performs eventlogging concurrently with the main capability, even in the non-threaded RTS. - - - - - 1f28d1f6 by Duncan Coutts at 2026-06-12T04:54:06-04:00 Use ACQUIRE/RELEASE_LOCK_ALWAYS with eventBufMutex Even in the non-threaded RTS the eventBufMutex is needed by both the main capability and the timer/ticker thread, so always use the mutex. This should fix #25165 which is about the main capability and the timer thread posting events to the eventlog buffer concurrently and thereby corrupting the buffer data. - - - - - 0ff29782 by Duncan Coutts at 2026-06-12T04:54:06-04:00 Expose eventBufMutex in the EventLog interface/header We will need it in forkProcess to ensure we don't write to the global eventlog buffer concurrently with trying to flush eventlog buffers and do the fork(). - - - - - 7a688395 by Duncan Coutts at 2026-06-12T04:54:07-04:00 Split flushAllCapsEventsBufs into safe and unlocked version Following the convention that unlocked versions have a trailing _ underscore in their name. This one requires the caller to hold the eventlog global buffer mutex. We will need this in forkProcess. - - - - - 341ed474 by Duncan Coutts at 2026-06-12T04:54:07-04:00 Remove redundant use of stopTimer in setNumCapabilities Historically, the comment here was: We must stop the interval timer while we are changing the capabilities array lest handle_tick may try to context switch an old capability. See #17289. and We must disable the timer while we do this since the tick handler may call contextSwitchAllCapabilities, which may see the capabilities array as we free it. What this refers to is that historically, when changing the number of capabilities, the array of capabilities was reallocated to a new size, allocating new ones and freeing the old ones, thus invalidating all existing capbility pointers. Strangely, for good measure the code used to call stopTimer twice (hence the two similar comments above). However, since commit a3eccf06292dd666b24606251a52da2b466a9612, the capabilities array is no longer reallocated. Instead the array is allcoated once on RTS startup to the maximum size it could ever be allowed to be, and then capabilities get enabled/disabled at runtime. So the capability pointers never become invalid anymore. At worst, they may point to capabilities that are disabled. Thus we no longer need to stop the timer (twice) while we change the number of enabled capabilities. This also partially solves issue #27105, which notes that stopTimer is being used as if it were synchronous, when it is not. At least for this case, the solution is that stopTimer is not needed at all! - - - - - 674858e3 by Duncan Coutts at 2026-06-12T04:54:07-04:00 Remove redundant use of stopTimer in forkProcess but replace it with taking the eventlog buffer lock during the fork. Fixes issue #27105 The original reason to block the timer during a fork was that historically the timer was implemented using a periodic timer signal, and the signal itself would interrupt the fork system call (returning EINTR). For large processes (where fork() takes a while) this could permanently livelock: the timer always would go off before the fork could complete, which got retried in a loop forever. The timer is no longer implemented as a unix signal, but uses threads. Thus the original problem no longer exists. The only remaining reason to block the timer tick is to prevent actions taken by the tick from interfering with the delicate process involved in fork (taking a load of locks and pausing everything). The only thing we need to do is to prevent the eventlog from being written to or flushed while the fork is taking place. To achieve this all we need to do is hold the mutex for the global eventlog buffer. This removes the last use of stopTimer that expects stopTimer to work synchronously (which it was not) and thus solves issue #27105. To be clear, we solve issue #27105 not by making stopTimer synchronous, but by eliminating the use sites that expected it to be synchronous. - - - - - 40764930 by sheaf at 2026-06-12T14:54:43-04:00 Add type family performance test for #26426 Some GHC versions produced large numbers of coercions after typechecking and desugaring when compiling the program in #26426: Version | Typechecker time | Typechecker allocations | Coercions -------:|-----------------:|------------------------:|---------: 9.6 | 47 ms | 48 MB | 110k 9.8 | 1000 ms | 486 MB | 10,437k 9.10 | 922 ms | 489 MB | 10,436k 9.12 | 906 ms | 482 MB | 10,437k 9.14 | 63 ms | 55 MB | 333k 10.0 | 47 ms | 64 MB | 35k The improvement 9.12 -> 9.14 was due to commit 22d11fa818fae2c95c494fc0fac1f8cb4c6e7cb6, while the improvement 9.14 -> 10.0 was due to commit 0b7df6db9e46df40e86fbff1a66dc10440b99db5. As the behaviour of GHC seems better than it's ever been on this program, we declare victory, adding this performance test to ensure we don't regress on this program. On the way, we update Note [Combining equalities] in GHC.Tc.SolveR.Equality with the explanation of the 9.12 -> 9.14 improvement (getting rid of an exponential blowup in coercion sizes), and we update Note [Exploiting closed type families] in GHC.Tc.Solver.FunDeps with the explanation of the 9.14 -> 10.0 improvement (bringing down coercion size growth from cubic to quadratic). - - - - - 0f3d0a71 by Zubin Duggal at 2026-06-12T14:55:30-04:00 compiler: mark tool messages as errors/warnings depending on the exit code Fixes #27370 - - - - - d9ea2d76 by mangoiv at 2026-06-13T04:41:51-04:00 libraries/process: bump submodule to v1.6.30.0 - bump the submodule to the appropriate tag - suppress benign warning resulting from the change - - - - - 6ebaaba3 by David Eichmann at 2026-06-13T04:42:37-04:00 ghc-toolchain: don't throw when candidate executables are not found Fixes #27369 - - - - - 6c65e1e1 by David Eichmann at 2026-06-13T04:43:23-04:00 CI: lint-changelog checks for no-changelog label in script instead of rules - - - - - 5395f5ae by Andrew Lelechenko at 2026-06-14T18:46:59+01:00 base: more NonEmpty zips CLC proposal: https://github.com/haskell/core-libraries-committee/issues/409 - - - - - 81 changed files: - .gitlab-ci.yml - + changelog.d/T27046 - + changelog.d/T27225 - + changelog.d/T27317 - + changelog.d/T27359 - changelog.d/hadrian-response-files.md - + changelog.d/hadrian-stale-package-confs-26661 - + changelog.d/tool-messages-27370 - compiler/GHC/CmmToAsm/AArch64/CodeGen.hs - compiler/GHC/Core/Type.hs - compiler/GHC/Core/Utils.hs - compiler/GHC/Data/List/NonEmpty.hs - compiler/GHC/Driver/Backend.hs - compiler/GHC/Hs/Instances.hs - compiler/GHC/Parser/PostProcess/Haddock.hs - compiler/GHC/Runtime/Debugger/Breakpoints.hs - compiler/GHC/Runtime/Eval/Types.hs - compiler/GHC/Runtime/Heap/Inspect.hs - compiler/GHC/SysTools/Process.hs - compiler/GHC/Tc/Solver/Equality.hs - compiler/GHC/Tc/Solver/FunDeps.hs - compiler/GHC/Types/RepType.hs - compiler/GHC/Utils/Logger.hs - docs/users_guide/using.rst - hadrian/build-cabal - hadrian/src/Builder.hs - hadrian/src/CommandLine.hs - hadrian/src/Hadrian/Builder/Ar.hs - hadrian/src/Hadrian/Haskell/Cabal/Parse.hs - hadrian/src/Hadrian/Utilities.hs - hadrian/src/Rules/BinaryDist.hs - libraries/base/changelog.md - libraries/base/src/Data/List/NonEmpty.hs - libraries/ghc-internal/src/GHC/Internal/Lexeme.hs - libraries/process - rts/Capability.c - rts/Schedule.c - rts/Timer.c - rts/eventlog/EventLog.c - rts/eventlog/EventLog.h - rts/include/rts/OSThreads.h - testsuite/driver/testlib.py - testsuite/mk/test.mk - + testsuite/tests/codeGen/should_run/T27046.hs - + testsuite/tests/codeGen/should_run/T27046_cmm.cmm - testsuite/tests/codeGen/should_run/all.T - testsuite/tests/count-deps/CountDepsAst.stdout - testsuite/tests/count-deps/CountDepsParser.stdout - + testsuite/tests/driver/T27370/Makefile - + testsuite/tests/driver/T27370/T27370.hs - + testsuite/tests/driver/T27370/T27370.pp - + testsuite/tests/driver/T27370/T27370.stderr - + testsuite/tests/driver/T27370/all.T - testsuite/tests/interface-stability/base-exports.stdout - testsuite/tests/interface-stability/base-exports.stdout-javascript-unknown-ghcjs - testsuite/tests/interface-stability/base-exports.stdout-mingw32 - + testsuite/tests/perf/compiler/T26426.hs - testsuite/tests/perf/compiler/all.T - + testsuite/tests/profiling/should_run/T27225.hs - + testsuite/tests/profiling/should_run/T27225.stdout - + testsuite/tests/profiling/should_run/T27225b.hs - + testsuite/tests/profiling/should_run/T27225b.stdout - testsuite/tests/profiling/should_run/all.T - testsuite/tests/profiling/should_run/caller-cc/CallerCc1.prof.sample - testsuite/tests/profiling/should_run/callstack001.stdout - testsuite/tests/profiling/should_run/scc001.prof.sample - testsuite/tests/rts/T27131.hs - testsuite/tests/rts/T27131.stdout - + testsuite/tests/simplCore/should_compile/T4081.hs - + testsuite/tests/simplCore/should_compile/T4081.stderr - testsuite/tests/simplCore/should_compile/all.T - utils/check-exact/Main.hs - utils/check-exact/Transform.hs - utils/ghc-toolchain/src/GHC/Toolchain/Program.hs - utils/ghc-toolchain/src/GHC/Toolchain/Utils.hs - utils/haddock/haddock-api/haddock-api.cabal - utils/haddock/haddock-api/src/Haddock.hs - utils/haddock/haddock-api/src/Haddock/Backends/Hyperlinker.hs - utils/haddock/haddock-api/src/Haddock/Backends/Xhtml.hs - utils/haddock/haddock-api/src/Haddock/Options.hs - utils/haddock/haddock-api/src/Haddock/Utils.hs The diff was not included because it is too large. View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/378a445c9140fa15fe8dc179b74346… -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/378a445c9140fa15fe8dc179b74346… You're receiving this email because of your account on gitlab.haskell.org.

1 0

[Git][ghc/ghc][wip/az/exactprint-annotation-rationalisation] 32 commits: testsuite: detect fast bignum via ghc-internal, not removed ghc-bignum
by Alan Zimmerman (＠alanz) 14 Jun '26

14 Jun '26

Alan Zimmerman pushed to branch wip/az/exactprint-annotation-rationalisation at Glasgow Haskell Compiler / GHC Commits: 2f3cc9ff by Simon Jakobi at 2026-06-08T07:55:49-04:00 testsuite: detect fast bignum via ghc-internal, not removed ghc-bignum The ghc-bignum package was merged into ghc-internal, so the BIGNUM_GMP probe in test.mk ran `ghc-pkg field ghc-bignum exposed-modules`, which fails with "cannot find package ghc-bignum". That error went to stderr and leaked into the captured stderr of every makefile_test, causing spurious [bad stderr] failures across the suite. The probe also silently returned empty, so config.have_fast_bignum was wrongly False even on GMP builds. Probe ghc-internal's extra-libraries for the gmp library instead: the GMP backend module is an other-module (not exposed), but GMP_LIBS adds gmp to extra-libraries only on a GMP build, so this distinguishes the backends. Redirect stderr to keep any future missing-package error off the harness's stderr. This also removes a stale comment as per suggestion from hsyl20. Co-Authored-By: Claude Opus 4.7 <noreply(a)anthropic.com> - - - - - eb3bf6e7 by Alan Zimmerman at 2026-06-08T07:56:32-04:00 EPA: Rename Transform.anchorEof to addModuleCommentOrigDeltas This now matches what it actually does. - - - - - 498bb21a by David Eichmann at 2026-06-09T18:02:39-04:00 Hadrian: avoid response files when command line is short enough This replaces the logic of always using response files on Windows. With the new condition based on command line lenght, reponse files can be avoided in many more cases (on windows). Now that response files are only used in a small number of cases, response files are always kept and the -r / --keep-response-files command line options have been removed The response file paths are nolonger randomized. They are placed in the `_build/rsp` directory. This ensures they are ignored by git and we that Hadrian reuses response file paths when rebuilding rather than leaving stale response files around. Update user guide putting response files in its own section - - - - - 87f510a5 by Simon Hengel at 2026-06-09T18:03:25-04:00 Don't use non-breaking spaces - - - - - 41a19379 by David Eichmann at 2026-06-09T18:04:11-04:00 Hadrian: remove unused wrapper scripts from windows bindist These wrapper scripts are only installed on non-relocatable builds which are not generally supported on windows. - - - - - ce01ccb6 by sheaf at 2026-06-10T05:08:48-04:00 Don't drop ticks around variables of type `IO ()` GHC.Core.Utils.mkTick is responsible for placing a tick on a Core expression. It contains logic for dropping SCCs (non-counting profiling ticks) around non-function variables, as such variables cannot meaningfully contribute to profiles. However, the logic for what counts as a function was incorrect: it used `isFunTy` which returns 'False' for types such as 'IO ()' where the function arrow is hidden under a newtype. We now use 'mightBeFunTy' instead of 'isFunTy'. This ensures we don't drop ticks in cases we aren't sure. On the way, we improve the documentation of 'isFunTy', 'isPiTy' and 'mightBeFunTy', and update the latter's implementation to consistently handle unary classes. Fixes #27225 ------------------------- Metric Decrease: T5642 ------------------------- - - - - - d311c4f1 by Simon Jakobi at 2026-06-10T05:09:32-04:00 testsuite: Add regression test for #4081 Check that a strict constructor field is unboxed once outside an enclosing loop, not re-inspected each iteration (the float-out case-floating from 9cb20b488). Uses simonpj's `data T a = T !a` example from the ticket; T4081.stderr captures the expected Core. Co-Authored-By: Claude Opus 4.7 <noreply(a)anthropic.com> - - - - - 333df444 by sheaf at 2026-06-10T05:10:25-04:00 Check for cabal-install >= 3.12 upfront Starting with commit 8cb99552f607f6bc4000e45ab32532d50c8bb996, Hadrian requires cabal-install >= 3.12 in order to use the 'cabal path' command that was introduced in version 3.12, as per https://github.com/haskell/cabal/blob/a51c4ee1556d816ad86e90db7e6330dd51b0b… This was not reflected in the Hadrian build script, causing a delayed build failure instead of enforcing the version requirement upfront, which this patch does. Fixes #27317 - - - - - 98c20394 by sheaf at 2026-06-10T05:11:09-04:00 Fix crash in Data.Data instance for HsCtxt The Data.Data instance for HsCtxt contained an error for the 'toConstr' method, which could trigger for example when looking at -ddump-tc-ast traces. Replace it with the 'abstractConstr' pattern used in the rest of the codebase. - - - - - 5ac9ce7d by Zubin Duggal at 2026-06-10T21:26:32+05:30 hadrian: Remove old package.conf files when generating new ones Old package.conf files might exists with different hashes, causing issues like #26661 Fixes #26661 - - - - - c9015f09 by sheaf at 2026-06-11T12:40:28-04:00 Fix AArch64 clobbering bug for MUL2 On AArch64, the code generator could clobber one of the input operands when computing the lower bits of a MUL2 operation. This rendered invalid the subsequent computation of the high bits. This commit fixes that by using a temporary register. The register allocator can remove the redundant move in the common case when the registers do not conflict. Fixes #27046 - - - - - 7ab90288 by Rodrigo Mesquita at 2026-06-11T12:41:11-04:00 fix: make T27131 less flaky It seems that T27131 fails flakily in a race where we check the flag before the capability had the chance to process the mailbox which sets the flag. This seemingly should only happen if the capability ends up being the same for setting and checking the flag. - - - - - 8965cb76 by Marc Scholten at 2026-06-12T04:53:22-04:00 haddock: render modules concurrently - - - - - 8cc0b64a by Duncan Coutts at 2026-06-12T04:54:06-04:00 Promote HAVE_PREEMPTION from Timer.c to OSThreads.h We will want to know about HAVE_PREEMPTION in more places. HAVE_PREEMPTION tells us that we do have OS threads available, irrespective of whether THREADED is defined. In particular, HAVE_PREEMPTION is defined on all proper OSs, but not on WASM (and hyopthetically may not be true on some other platforms like micro-controllers, RTOSs, VM hypervisors etc). - - - - - cce574ed by Duncan Coutts at 2026-06-12T04:54:06-04:00 Define ACQUIRE_LOCK_ALWAYS and friends Fix issue #27335 Like the atomic _ALWAYS variants, these lock actions are always defined, rather than being dependent on whether we are in the THREADED case. All the "normal" LOCK macros are defined to be no-ops when !THREADED. The use case for the _ALWAYS variants is where we are using OS threads even in the non-threaded RTS. This includes everything to do with the timer/ticker thread, which is used in the non-threaded RTS too. In particular, we will want to use this for eventlog things, because the timer thread performs eventlogging concurrently with the main capability, even in the non-threaded RTS. - - - - - 1f28d1f6 by Duncan Coutts at 2026-06-12T04:54:06-04:00 Use ACQUIRE/RELEASE_LOCK_ALWAYS with eventBufMutex Even in the non-threaded RTS the eventBufMutex is needed by both the main capability and the timer/ticker thread, so always use the mutex. This should fix #25165 which is about the main capability and the timer thread posting events to the eventlog buffer concurrently and thereby corrupting the buffer data. - - - - - 0ff29782 by Duncan Coutts at 2026-06-12T04:54:06-04:00 Expose eventBufMutex in the EventLog interface/header We will need it in forkProcess to ensure we don't write to the global eventlog buffer concurrently with trying to flush eventlog buffers and do the fork(). - - - - - 7a688395 by Duncan Coutts at 2026-06-12T04:54:07-04:00 Split flushAllCapsEventsBufs into safe and unlocked version Following the convention that unlocked versions have a trailing _ underscore in their name. This one requires the caller to hold the eventlog global buffer mutex. We will need this in forkProcess. - - - - - 341ed474 by Duncan Coutts at 2026-06-12T04:54:07-04:00 Remove redundant use of stopTimer in setNumCapabilities Historically, the comment here was: We must stop the interval timer while we are changing the capabilities array lest handle_tick may try to context switch an old capability. See #17289. and We must disable the timer while we do this since the tick handler may call contextSwitchAllCapabilities, which may see the capabilities array as we free it. What this refers to is that historically, when changing the number of capabilities, the array of capabilities was reallocated to a new size, allocating new ones and freeing the old ones, thus invalidating all existing capbility pointers. Strangely, for good measure the code used to call stopTimer twice (hence the two similar comments above). However, since commit a3eccf06292dd666b24606251a52da2b466a9612, the capabilities array is no longer reallocated. Instead the array is allcoated once on RTS startup to the maximum size it could ever be allowed to be, and then capabilities get enabled/disabled at runtime. So the capability pointers never become invalid anymore. At worst, they may point to capabilities that are disabled. Thus we no longer need to stop the timer (twice) while we change the number of enabled capabilities. This also partially solves issue #27105, which notes that stopTimer is being used as if it were synchronous, when it is not. At least for this case, the solution is that stopTimer is not needed at all! - - - - - 674858e3 by Duncan Coutts at 2026-06-12T04:54:07-04:00 Remove redundant use of stopTimer in forkProcess but replace it with taking the eventlog buffer lock during the fork. Fixes issue #27105 The original reason to block the timer during a fork was that historically the timer was implemented using a periodic timer signal, and the signal itself would interrupt the fork system call (returning EINTR). For large processes (where fork() takes a while) this could permanently livelock: the timer always would go off before the fork could complete, which got retried in a loop forever. The timer is no longer implemented as a unix signal, but uses threads. Thus the original problem no longer exists. The only remaining reason to block the timer tick is to prevent actions taken by the tick from interfering with the delicate process involved in fork (taking a load of locks and pausing everything). The only thing we need to do is to prevent the eventlog from being written to or flushed while the fork is taking place. To achieve this all we need to do is hold the mutex for the global eventlog buffer. This removes the last use of stopTimer that expects stopTimer to work synchronously (which it was not) and thus solves issue #27105. To be clear, we solve issue #27105 not by making stopTimer synchronous, but by eliminating the use sites that expected it to be synchronous. - - - - - 40764930 by sheaf at 2026-06-12T14:54:43-04:00 Add type family performance test for #26426 Some GHC versions produced large numbers of coercions after typechecking and desugaring when compiling the program in #26426: Version | Typechecker time | Typechecker allocations | Coercions -------:|-----------------:|------------------------:|---------: 9.6 | 47 ms | 48 MB | 110k 9.8 | 1000 ms | 486 MB | 10,437k 9.10 | 922 ms | 489 MB | 10,436k 9.12 | 906 ms | 482 MB | 10,437k 9.14 | 63 ms | 55 MB | 333k 10.0 | 47 ms | 64 MB | 35k The improvement 9.12 -> 9.14 was due to commit 22d11fa818fae2c95c494fc0fac1f8cb4c6e7cb6, while the improvement 9.14 -> 10.0 was due to commit 0b7df6db9e46df40e86fbff1a66dc10440b99db5. As the behaviour of GHC seems better than it's ever been on this program, we declare victory, adding this performance test to ensure we don't regress on this program. On the way, we update Note [Combining equalities] in GHC.Tc.SolveR.Equality with the explanation of the 9.12 -> 9.14 improvement (getting rid of an exponential blowup in coercion sizes), and we update Note [Exploiting closed type families] in GHC.Tc.Solver.FunDeps with the explanation of the 9.14 -> 10.0 improvement (bringing down coercion size growth from cubic to quadratic). - - - - - 0f3d0a71 by Zubin Duggal at 2026-06-12T14:55:30-04:00 compiler: mark tool messages as errors/warnings depending on the exit code Fixes #27370 - - - - - d9ea2d76 by mangoiv at 2026-06-13T04:41:51-04:00 libraries/process: bump submodule to v1.6.30.0 - bump the submodule to the appropriate tag - suppress benign warning resulting from the change - - - - - 6ebaaba3 by David Eichmann at 2026-06-13T04:42:37-04:00 ghc-toolchain: don't throw when candidate executables are not found Fixes #27369 - - - - - 6c65e1e1 by David Eichmann at 2026-06-13T04:43:23-04:00 CI: lint-changelog checks for no-changelog label in script instead of rules - - - - - 8760741e by Alan Zimmerman at 2026-06-13T17:44:51+01:00 EPA: Rename Transform.anchorEof to addModuleCommentOrigDeltas This now matches what it actually does. - - - - - da7cc455 by Alan Zimmerman at 2026-06-13T17:44:51+01:00 EPA: Use standard type family declaration for Anno - - - - - 3735af95 by Alan Zimmerman at 2026-06-13T17:44:51+01:00 TTG: Add extension points to HsConDetails In contrast to normal TTG extension points, these are indexed by the arg and rec type parameters, since HsConDetails is a container type used in various roles. Each of these uses a GhcPass based structure, so the overall effect is a family of pass-sensitive extension points. data HsConDetails p arg rec = PrefixCon !(XPrefixCon p) [arg] -- C @t1 @t2 p1 p2 p3 | RecCon !(XRecCon p) rec -- C { x = p1, y = p2 } | InfixCon !(XInfixCon p) arg arg -- p1 `C` p2 | XHsConDetails !(XXHsConDetails p) type family XPrefixCon p type family XRecCon p type family XInfixCon p type family XXHsConDetails p - - - - - 953f4313 by Alan Zimmerman at 2026-06-13T17:44:51+01:00 EPA: remove LocatedLI / SrcSpanAnnLI These were used for module export lists, and import decl lists. Replace them with direct capture of the relevant EP Annotations in HsModule and ImportDecl annotation extension points. Also use the HsConDetails RecCon extension point to capture the braces in a record constructor - - - - - e40ecb88 by Alan Zimmerman at 2026-06-13T17:44:51+01:00 EPA: Remove LocatedC / SrcSpanAnnC Used for contexts - - - - - 4f003c73 by Alan Zimmerman at 2026-06-13T17:44:51+01:00 EPA Remove LocatedLC / LocatedLS LocatedLC/LocatedLS were unused - - - - - 5bc9a550 by Alan Zimmerman at 2026-06-13T17:44:51+01:00 EPA: Remove LocatedLW from LStmtLR - - - - - 165 changed files: - .gitlab-ci.yml - + changelog.d/T27046 - + changelog.d/T27225 - + changelog.d/T27317 - + changelog.d/T27359 - changelog.d/hadrian-response-files.md - + changelog.d/hadrian-stale-package-confs-26661 - + changelog.d/tool-messages-27370 - compiler/GHC/CmmToAsm/AArch64/CodeGen.hs - compiler/GHC/Core/Type.hs - compiler/GHC/Core/Utils.hs - compiler/GHC/Data/BooleanFormula.hs - compiler/GHC/Driver/Backend.hs - compiler/GHC/Hs.hs - compiler/GHC/Hs/Binds.hs - compiler/GHC/Hs/Decls.hs - compiler/GHC/Hs/Dump.hs - compiler/GHC/Hs/Expr.hs - compiler/GHC/Hs/ImpExp.hs - compiler/GHC/Hs/Instances.hs - compiler/GHC/Hs/Pat.hs - compiler/GHC/Hs/Stats.hs - compiler/GHC/Hs/Type.hs - compiler/GHC/Hs/Utils.hs - compiler/GHC/HsToCore/Docs.hs - compiler/GHC/HsToCore/Match.hs - compiler/GHC/HsToCore/Match/Constructor.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/Parser.y - compiler/GHC/Parser/Annotation.hs - compiler/GHC/Parser/PostProcess.hs - compiler/GHC/Parser/PostProcess/Haddock.hs - compiler/GHC/Parser/Types.hs - compiler/GHC/Rename/Bind.hs - compiler/GHC/Rename/Expr.hs - compiler/GHC/Rename/HsType.hs - compiler/GHC/Rename/Module.hs - compiler/GHC/Rename/Names.hs - compiler/GHC/Rename/Pat.hs - compiler/GHC/Rename/Utils.hs - compiler/GHC/Runtime/Debugger/Breakpoints.hs - compiler/GHC/Runtime/Eval/Types.hs - compiler/GHC/Runtime/Heap/Inspect.hs - compiler/GHC/SysTools/Process.hs - compiler/GHC/Tc/Deriv.hs - compiler/GHC/Tc/Deriv/Generate.hs - compiler/GHC/Tc/Gen/App.hs - compiler/GHC/Tc/Gen/Export.hs - compiler/GHC/Tc/Gen/HsType.hs - compiler/GHC/Tc/Gen/Match.hs - compiler/GHC/Tc/Gen/Pat.hs - compiler/GHC/Tc/Gen/Sig.hs - compiler/GHC/Tc/Module.hs - compiler/GHC/Tc/Solver/Equality.hs - compiler/GHC/Tc/Solver/FunDeps.hs - compiler/GHC/Tc/TyCl.hs - compiler/GHC/Tc/TyCl/PatSyn.hs - compiler/GHC/Tc/TyCl/Utils.hs - compiler/GHC/Tc/Utils/Backpack.hs - compiler/GHC/Tc/Zonk/Type.hs - compiler/GHC/ThToHs.hs - compiler/GHC/Types/RepType.hs - compiler/GHC/Utils/Logger.hs - compiler/Language/Haskell/Syntax.hs - compiler/Language/Haskell/Syntax/Binds.hs - compiler/Language/Haskell/Syntax/Decls.hs - compiler/Language/Haskell/Syntax/Expr.hs - compiler/Language/Haskell/Syntax/Extension.hs - compiler/Language/Haskell/Syntax/ImpExp.hs - compiler/Language/Haskell/Syntax/Pat.hs - compiler/Language/Haskell/Syntax/Type.hs - docs/users_guide/using.rst - ghc/GHCi/UI.hs - hadrian/build-cabal - hadrian/src/Builder.hs - hadrian/src/CommandLine.hs - hadrian/src/Hadrian/Builder/Ar.hs - hadrian/src/Hadrian/Haskell/Cabal/Parse.hs - hadrian/src/Hadrian/Utilities.hs - hadrian/src/Rules/BinaryDist.hs - libraries/ghc-internal/src/GHC/Internal/Lexeme.hs - libraries/process - rts/Capability.c - rts/Schedule.c - rts/Timer.c - rts/eventlog/EventLog.c - rts/eventlog/EventLog.h - rts/include/rts/OSThreads.h - testsuite/driver/testlib.py - testsuite/mk/test.mk - + testsuite/tests/codeGen/should_run/T27046.hs - + testsuite/tests/codeGen/should_run/T27046_cmm.cmm - testsuite/tests/codeGen/should_run/all.T - testsuite/tests/count-deps/CountDepsAst.stdout - testsuite/tests/count-deps/CountDepsParser.stdout - + testsuite/tests/driver/T27370/Makefile - + testsuite/tests/driver/T27370/T27370.hs - + testsuite/tests/driver/T27370/T27370.pp - + testsuite/tests/driver/T27370/T27370.stderr - + testsuite/tests/driver/T27370/all.T - 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/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/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/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/perf/compiler/T26426.hs - testsuite/tests/perf/compiler/all.T - testsuite/tests/printer/AnnotationNoListTuplePuns.stdout - testsuite/tests/printer/Makefile - testsuite/tests/printer/T18791.stderr - testsuite/tests/printer/Test20297.stdout - testsuite/tests/printer/Test24533.stdout - + testsuite/tests/profiling/should_run/T27225.hs - + testsuite/tests/profiling/should_run/T27225.stdout - + testsuite/tests/profiling/should_run/T27225b.hs - + testsuite/tests/profiling/should_run/T27225b.stdout - testsuite/tests/profiling/should_run/all.T - testsuite/tests/profiling/should_run/caller-cc/CallerCc1.prof.sample - testsuite/tests/profiling/should_run/callstack001.stdout - testsuite/tests/profiling/should_run/scc001.prof.sample - testsuite/tests/rts/T27131.hs - testsuite/tests/rts/T27131.stdout - + testsuite/tests/simplCore/should_compile/T4081.hs - + testsuite/tests/simplCore/should_compile/T4081.stderr - testsuite/tests/simplCore/should_compile/all.T - utils/check-exact/ExactPrint.hs - utils/check-exact/Main.hs - utils/check-exact/Transform.hs - utils/check-exact/Utils.hs - utils/ghc-toolchain/src/GHC/Toolchain/Program.hs - utils/ghc-toolchain/src/GHC/Toolchain/Utils.hs - utils/haddock/haddock-api/haddock-api.cabal - utils/haddock/haddock-api/src/Haddock.hs - utils/haddock/haddock-api/src/Haddock/Backends/Hoogle.hs - utils/haddock/haddock-api/src/Haddock/Backends/Hyperlinker.hs - utils/haddock/haddock-api/src/Haddock/Backends/LaTeX.hs - utils/haddock/haddock-api/src/Haddock/Backends/Xhtml.hs - utils/haddock/haddock-api/src/Haddock/Backends/Xhtml/Decl.hs - utils/haddock/haddock-api/src/Haddock/Convert.hs - utils/haddock/haddock-api/src/Haddock/GhcUtils.hs - utils/haddock/haddock-api/src/Haddock/Interface/Create.hs - utils/haddock/haddock-api/src/Haddock/Interface/LexParseRn.hs - utils/haddock/haddock-api/src/Haddock/Interface/Rename.hs - utils/haddock/haddock-api/src/Haddock/Interface/RenameType.hs - utils/haddock/haddock-api/src/Haddock/Options.hs - utils/haddock/haddock-api/src/Haddock/Types.hs - utils/haddock/haddock-api/src/Haddock/Utils.hs The diff was not included because it is too large. View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/642390f2f396fafea84af2e2658194… -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/642390f2f396fafea84af2e2658194… You're receiving this email because of your account on gitlab.haskell.org.

1 0

[Git][ghc/ghc][wip/az/epa-fix-transform-anchoreof] 26 commits: testsuite: detect fast bignum via ghc-internal, not removed ghc-bignum
by Alan Zimmerman (＠alanz) 14 Jun '26

14 Jun '26

Alan Zimmerman pushed to branch wip/az/epa-fix-transform-anchoreof at Glasgow Haskell Compiler / GHC Commits: 2f3cc9ff by Simon Jakobi at 2026-06-08T07:55:49-04:00 testsuite: detect fast bignum via ghc-internal, not removed ghc-bignum The ghc-bignum package was merged into ghc-internal, so the BIGNUM_GMP probe in test.mk ran `ghc-pkg field ghc-bignum exposed-modules`, which fails with "cannot find package ghc-bignum". That error went to stderr and leaked into the captured stderr of every makefile_test, causing spurious [bad stderr] failures across the suite. The probe also silently returned empty, so config.have_fast_bignum was wrongly False even on GMP builds. Probe ghc-internal's extra-libraries for the gmp library instead: the GMP backend module is an other-module (not exposed), but GMP_LIBS adds gmp to extra-libraries only on a GMP build, so this distinguishes the backends. Redirect stderr to keep any future missing-package error off the harness's stderr. This also removes a stale comment as per suggestion from hsyl20. Co-Authored-By: Claude Opus 4.7 <noreply(a)anthropic.com> - - - - - eb3bf6e7 by Alan Zimmerman at 2026-06-08T07:56:32-04:00 EPA: Rename Transform.anchorEof to addModuleCommentOrigDeltas This now matches what it actually does. - - - - - 498bb21a by David Eichmann at 2026-06-09T18:02:39-04:00 Hadrian: avoid response files when command line is short enough This replaces the logic of always using response files on Windows. With the new condition based on command line lenght, reponse files can be avoided in many more cases (on windows). Now that response files are only used in a small number of cases, response files are always kept and the -r / --keep-response-files command line options have been removed The response file paths are nolonger randomized. They are placed in the `_build/rsp` directory. This ensures they are ignored by git and we that Hadrian reuses response file paths when rebuilding rather than leaving stale response files around. Update user guide putting response files in its own section - - - - - 87f510a5 by Simon Hengel at 2026-06-09T18:03:25-04:00 Don't use non-breaking spaces - - - - - 41a19379 by David Eichmann at 2026-06-09T18:04:11-04:00 Hadrian: remove unused wrapper scripts from windows bindist These wrapper scripts are only installed on non-relocatable builds which are not generally supported on windows. - - - - - ce01ccb6 by sheaf at 2026-06-10T05:08:48-04:00 Don't drop ticks around variables of type `IO ()` GHC.Core.Utils.mkTick is responsible for placing a tick on a Core expression. It contains logic for dropping SCCs (non-counting profiling ticks) around non-function variables, as such variables cannot meaningfully contribute to profiles. However, the logic for what counts as a function was incorrect: it used `isFunTy` which returns 'False' for types such as 'IO ()' where the function arrow is hidden under a newtype. We now use 'mightBeFunTy' instead of 'isFunTy'. This ensures we don't drop ticks in cases we aren't sure. On the way, we improve the documentation of 'isFunTy', 'isPiTy' and 'mightBeFunTy', and update the latter's implementation to consistently handle unary classes. Fixes #27225 ------------------------- Metric Decrease: T5642 ------------------------- - - - - - d311c4f1 by Simon Jakobi at 2026-06-10T05:09:32-04:00 testsuite: Add regression test for #4081 Check that a strict constructor field is unboxed once outside an enclosing loop, not re-inspected each iteration (the float-out case-floating from 9cb20b488). Uses simonpj's `data T a = T !a` example from the ticket; T4081.stderr captures the expected Core. Co-Authored-By: Claude Opus 4.7 <noreply(a)anthropic.com> - - - - - 333df444 by sheaf at 2026-06-10T05:10:25-04:00 Check for cabal-install >= 3.12 upfront Starting with commit 8cb99552f607f6bc4000e45ab32532d50c8bb996, Hadrian requires cabal-install >= 3.12 in order to use the 'cabal path' command that was introduced in version 3.12, as per https://github.com/haskell/cabal/blob/a51c4ee1556d816ad86e90db7e6330dd51b0b… This was not reflected in the Hadrian build script, causing a delayed build failure instead of enforcing the version requirement upfront, which this patch does. Fixes #27317 - - - - - 98c20394 by sheaf at 2026-06-10T05:11:09-04:00 Fix crash in Data.Data instance for HsCtxt The Data.Data instance for HsCtxt contained an error for the 'toConstr' method, which could trigger for example when looking at -ddump-tc-ast traces. Replace it with the 'abstractConstr' pattern used in the rest of the codebase. - - - - - 5ac9ce7d by Zubin Duggal at 2026-06-10T21:26:32+05:30 hadrian: Remove old package.conf files when generating new ones Old package.conf files might exists with different hashes, causing issues like #26661 Fixes #26661 - - - - - c9015f09 by sheaf at 2026-06-11T12:40:28-04:00 Fix AArch64 clobbering bug for MUL2 On AArch64, the code generator could clobber one of the input operands when computing the lower bits of a MUL2 operation. This rendered invalid the subsequent computation of the high bits. This commit fixes that by using a temporary register. The register allocator can remove the redundant move in the common case when the registers do not conflict. Fixes #27046 - - - - - 7ab90288 by Rodrigo Mesquita at 2026-06-11T12:41:11-04:00 fix: make T27131 less flaky It seems that T27131 fails flakily in a race where we check the flag before the capability had the chance to process the mailbox which sets the flag. This seemingly should only happen if the capability ends up being the same for setting and checking the flag. - - - - - 8965cb76 by Marc Scholten at 2026-06-12T04:53:22-04:00 haddock: render modules concurrently - - - - - 8cc0b64a by Duncan Coutts at 2026-06-12T04:54:06-04:00 Promote HAVE_PREEMPTION from Timer.c to OSThreads.h We will want to know about HAVE_PREEMPTION in more places. HAVE_PREEMPTION tells us that we do have OS threads available, irrespective of whether THREADED is defined. In particular, HAVE_PREEMPTION is defined on all proper OSs, but not on WASM (and hyopthetically may not be true on some other platforms like micro-controllers, RTOSs, VM hypervisors etc). - - - - - cce574ed by Duncan Coutts at 2026-06-12T04:54:06-04:00 Define ACQUIRE_LOCK_ALWAYS and friends Fix issue #27335 Like the atomic _ALWAYS variants, these lock actions are always defined, rather than being dependent on whether we are in the THREADED case. All the "normal" LOCK macros are defined to be no-ops when !THREADED. The use case for the _ALWAYS variants is where we are using OS threads even in the non-threaded RTS. This includes everything to do with the timer/ticker thread, which is used in the non-threaded RTS too. In particular, we will want to use this for eventlog things, because the timer thread performs eventlogging concurrently with the main capability, even in the non-threaded RTS. - - - - - 1f28d1f6 by Duncan Coutts at 2026-06-12T04:54:06-04:00 Use ACQUIRE/RELEASE_LOCK_ALWAYS with eventBufMutex Even in the non-threaded RTS the eventBufMutex is needed by both the main capability and the timer/ticker thread, so always use the mutex. This should fix #25165 which is about the main capability and the timer thread posting events to the eventlog buffer concurrently and thereby corrupting the buffer data. - - - - - 0ff29782 by Duncan Coutts at 2026-06-12T04:54:06-04:00 Expose eventBufMutex in the EventLog interface/header We will need it in forkProcess to ensure we don't write to the global eventlog buffer concurrently with trying to flush eventlog buffers and do the fork(). - - - - - 7a688395 by Duncan Coutts at 2026-06-12T04:54:07-04:00 Split flushAllCapsEventsBufs into safe and unlocked version Following the convention that unlocked versions have a trailing _ underscore in their name. This one requires the caller to hold the eventlog global buffer mutex. We will need this in forkProcess. - - - - - 341ed474 by Duncan Coutts at 2026-06-12T04:54:07-04:00 Remove redundant use of stopTimer in setNumCapabilities Historically, the comment here was: We must stop the interval timer while we are changing the capabilities array lest handle_tick may try to context switch an old capability. See #17289. and We must disable the timer while we do this since the tick handler may call contextSwitchAllCapabilities, which may see the capabilities array as we free it. What this refers to is that historically, when changing the number of capabilities, the array of capabilities was reallocated to a new size, allocating new ones and freeing the old ones, thus invalidating all existing capbility pointers. Strangely, for good measure the code used to call stopTimer twice (hence the two similar comments above). However, since commit a3eccf06292dd666b24606251a52da2b466a9612, the capabilities array is no longer reallocated. Instead the array is allcoated once on RTS startup to the maximum size it could ever be allowed to be, and then capabilities get enabled/disabled at runtime. So the capability pointers never become invalid anymore. At worst, they may point to capabilities that are disabled. Thus we no longer need to stop the timer (twice) while we change the number of enabled capabilities. This also partially solves issue #27105, which notes that stopTimer is being used as if it were synchronous, when it is not. At least for this case, the solution is that stopTimer is not needed at all! - - - - - 674858e3 by Duncan Coutts at 2026-06-12T04:54:07-04:00 Remove redundant use of stopTimer in forkProcess but replace it with taking the eventlog buffer lock during the fork. Fixes issue #27105 The original reason to block the timer during a fork was that historically the timer was implemented using a periodic timer signal, and the signal itself would interrupt the fork system call (returning EINTR). For large processes (where fork() takes a while) this could permanently livelock: the timer always would go off before the fork could complete, which got retried in a loop forever. The timer is no longer implemented as a unix signal, but uses threads. Thus the original problem no longer exists. The only remaining reason to block the timer tick is to prevent actions taken by the tick from interfering with the delicate process involved in fork (taking a load of locks and pausing everything). The only thing we need to do is to prevent the eventlog from being written to or flushed while the fork is taking place. To achieve this all we need to do is hold the mutex for the global eventlog buffer. This removes the last use of stopTimer that expects stopTimer to work synchronously (which it was not) and thus solves issue #27105. To be clear, we solve issue #27105 not by making stopTimer synchronous, but by eliminating the use sites that expected it to be synchronous. - - - - - 40764930 by sheaf at 2026-06-12T14:54:43-04:00 Add type family performance test for #26426 Some GHC versions produced large numbers of coercions after typechecking and desugaring when compiling the program in #26426: Version | Typechecker time | Typechecker allocations | Coercions -------:|-----------------:|------------------------:|---------: 9.6 | 47 ms | 48 MB | 110k 9.8 | 1000 ms | 486 MB | 10,437k 9.10 | 922 ms | 489 MB | 10,436k 9.12 | 906 ms | 482 MB | 10,437k 9.14 | 63 ms | 55 MB | 333k 10.0 | 47 ms | 64 MB | 35k The improvement 9.12 -> 9.14 was due to commit 22d11fa818fae2c95c494fc0fac1f8cb4c6e7cb6, while the improvement 9.14 -> 10.0 was due to commit 0b7df6db9e46df40e86fbff1a66dc10440b99db5. As the behaviour of GHC seems better than it's ever been on this program, we declare victory, adding this performance test to ensure we don't regress on this program. On the way, we update Note [Combining equalities] in GHC.Tc.SolveR.Equality with the explanation of the 9.12 -> 9.14 improvement (getting rid of an exponential blowup in coercion sizes), and we update Note [Exploiting closed type families] in GHC.Tc.Solver.FunDeps with the explanation of the 9.14 -> 10.0 improvement (bringing down coercion size growth from cubic to quadratic). - - - - - 0f3d0a71 by Zubin Duggal at 2026-06-12T14:55:30-04:00 compiler: mark tool messages as errors/warnings depending on the exit code Fixes #27370 - - - - - d9ea2d76 by mangoiv at 2026-06-13T04:41:51-04:00 libraries/process: bump submodule to v1.6.30.0 - bump the submodule to the appropriate tag - suppress benign warning resulting from the change - - - - - 6ebaaba3 by David Eichmann at 2026-06-13T04:42:37-04:00 ghc-toolchain: don't throw when candidate executables are not found Fixes #27369 - - - - - 6c65e1e1 by David Eichmann at 2026-06-13T04:43:23-04:00 CI: lint-changelog checks for no-changelog label in script instead of rules - - - - - 8760741e by Alan Zimmerman at 2026-06-13T17:44:51+01:00 EPA: Rename Transform.anchorEof to addModuleCommentOrigDeltas This now matches what it actually does. - - - - - 75 changed files: - .gitlab-ci.yml - + changelog.d/T27046 - + changelog.d/T27225 - + changelog.d/T27317 - + changelog.d/T27359 - changelog.d/hadrian-response-files.md - + changelog.d/hadrian-stale-package-confs-26661 - + changelog.d/tool-messages-27370 - compiler/GHC/CmmToAsm/AArch64/CodeGen.hs - compiler/GHC/Core/Type.hs - compiler/GHC/Core/Utils.hs - compiler/GHC/Driver/Backend.hs - compiler/GHC/Hs/Instances.hs - compiler/GHC/Parser/PostProcess/Haddock.hs - compiler/GHC/Runtime/Debugger/Breakpoints.hs - compiler/GHC/Runtime/Eval/Types.hs - compiler/GHC/Runtime/Heap/Inspect.hs - compiler/GHC/SysTools/Process.hs - compiler/GHC/Tc/Solver/Equality.hs - compiler/GHC/Tc/Solver/FunDeps.hs - compiler/GHC/Types/RepType.hs - compiler/GHC/Utils/Logger.hs - docs/users_guide/using.rst - hadrian/build-cabal - hadrian/src/Builder.hs - hadrian/src/CommandLine.hs - hadrian/src/Hadrian/Builder/Ar.hs - hadrian/src/Hadrian/Haskell/Cabal/Parse.hs - hadrian/src/Hadrian/Utilities.hs - hadrian/src/Rules/BinaryDist.hs - libraries/ghc-internal/src/GHC/Internal/Lexeme.hs - libraries/process - rts/Capability.c - rts/Schedule.c - rts/Timer.c - rts/eventlog/EventLog.c - rts/eventlog/EventLog.h - rts/include/rts/OSThreads.h - testsuite/driver/testlib.py - testsuite/mk/test.mk - + testsuite/tests/codeGen/should_run/T27046.hs - + testsuite/tests/codeGen/should_run/T27046_cmm.cmm - testsuite/tests/codeGen/should_run/all.T - testsuite/tests/count-deps/CountDepsAst.stdout - testsuite/tests/count-deps/CountDepsParser.stdout - + testsuite/tests/driver/T27370/Makefile - + testsuite/tests/driver/T27370/T27370.hs - + testsuite/tests/driver/T27370/T27370.pp - + testsuite/tests/driver/T27370/T27370.stderr - + testsuite/tests/driver/T27370/all.T - + testsuite/tests/perf/compiler/T26426.hs - testsuite/tests/perf/compiler/all.T - + testsuite/tests/profiling/should_run/T27225.hs - + testsuite/tests/profiling/should_run/T27225.stdout - + testsuite/tests/profiling/should_run/T27225b.hs - + testsuite/tests/profiling/should_run/T27225b.stdout - testsuite/tests/profiling/should_run/all.T - testsuite/tests/profiling/should_run/caller-cc/CallerCc1.prof.sample - testsuite/tests/profiling/should_run/callstack001.stdout - testsuite/tests/profiling/should_run/scc001.prof.sample - testsuite/tests/rts/T27131.hs - testsuite/tests/rts/T27131.stdout - + testsuite/tests/simplCore/should_compile/T4081.hs - + testsuite/tests/simplCore/should_compile/T4081.stderr - testsuite/tests/simplCore/should_compile/all.T - utils/check-exact/Main.hs - utils/check-exact/Transform.hs - utils/ghc-toolchain/src/GHC/Toolchain/Program.hs - utils/ghc-toolchain/src/GHC/Toolchain/Utils.hs - utils/haddock/haddock-api/haddock-api.cabal - utils/haddock/haddock-api/src/Haddock.hs - utils/haddock/haddock-api/src/Haddock/Backends/Hyperlinker.hs - utils/haddock/haddock-api/src/Haddock/Backends/Xhtml.hs - utils/haddock/haddock-api/src/Haddock/Options.hs - utils/haddock/haddock-api/src/Haddock/Utils.hs The diff was not included because it is too large. View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/4588a8030dce3834501e31aad55932… -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/4588a8030dce3834501e31aad55932… You're receiving this email because of your account on gitlab.haskell.org.

1 0

[Git][ghc/ghc][wip/mangoiv/bp-process-bump] base: correct changelog entry for 4.21.3.0
by Magnus (＠MangoIV) 14 Jun '26

14 Jun '26

Magnus pushed to branch wip/mangoiv/bp-process-bump at Glasgow Haskell Compiler / GHC Commits: 3b176389 by mangoiv at 2026-06-14T18:50:27+02:00 base: correct changelog entry for 4.21.3.0 - - - - - 1 changed file: - libraries/base/changelog.md Changes: ===================================== libraries/base/changelog.md ===================================== @@ -1,6 +1,6 @@ # Changelog for [`base` package](http://hackage.haskell.org/package/base) -## 4.21.2.0 *June 2026* +## 4.21.3.0 *June 2026* * System.Info.fullCompilerVersion: add 'since' annotation ## 4.21.2.0 *March 2026* View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/3b176389fd626a4842fc2e186c7cea7… -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/3b176389fd626a4842fc2e186c7cea7… You're receiving this email because of your account on gitlab.haskell.org.

1 0

[Git][ghc/ghc][wip/mangoiv/bp-process-bump] base: correct changelog entry for 4.12.3.0
by Magnus (＠MangoIV) 14 Jun '26

14 Jun '26

Magnus pushed to branch wip/mangoiv/bp-process-bump at Glasgow Haskell Compiler / GHC Commits: b5b2785b by mangoiv at 2026-06-14T18:49:29+02:00 base: correct changelog entry for 4.12.3.0 - - - - - 1 changed file: - libraries/base/changelog.md Changes: ===================================== libraries/base/changelog.md ===================================== @@ -1,6 +1,6 @@ # Changelog for [`base` package](http://hackage.haskell.org/package/base) -## 4.21.2.0 *June 2026* +## 4.21.3.0 *June 2026* * System.Info.fullCompilerVersion: add 'since' annotation ## 4.21.2.0 *March 2026* View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/b5b2785b8bdbe7d623bab75341f9527… -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/b5b2785b8bdbe7d623bab75341f9527… You're receiving this email because of your account on gitlab.haskell.org.

1 0

[Git][ghc/ghc][wip/sjakobi/uniqfm-note] compiler: Add Note [Uniques and UniqFM shape]
by Simon Jakobi (＠sjakobi2) 14 Jun '26

14 Jun '26

Simon Jakobi pushed to branch wip/sjakobi/uniqfm-note at Glasgow Haskell Compiler / GHC Commits: ce999082 by Simon Jakobi at 2026-06-14T16:54:34+02:00 compiler: Add Note [Uniques and UniqFM shape] Also fix some outdated information in the module description for GHC.Types.Unique.FM. Co-Authored-By: Claude Opus 4.8 <noreply(a)anthropic.com> - - - - - 3 changed files: - compiler/GHC/Types/Unique.hs - compiler/GHC/Types/Unique/FM.hs - compiler/GHC/Types/Var/Env.hs Changes: ===================================== compiler/GHC/Types/Unique.hs ===================================== @@ -88,6 +88,10 @@ to distinguish uniques constructed by different parts of the compiler. To ensure that we assign distinct tags for each purpose, we represent tags in the compiler via the UniqueTag ADT. +The high-order tag also shapes any 'UniqFM' keyed by these uniques, clustering +keys near the trie root; see Note [Uniques and UniqFM shape] in +GHC.Types.Unique.FM. + The bidirectional mapping from the UniqueTag ADT to the corresponding character is witnessed by the uniqueTag and charToUniqueTag functions. See Note [Uniques for wired-in prelude things and known tags] ===================================== compiler/GHC/Types/Unique/FM.hs ===================================== @@ -10,13 +10,12 @@ Basically, the things need to be in class @Uniquable@, and we use the (A similar thing to @UniqSet@, as opposed to @Set@.) -The interface is based on @FiniteMap@s, but the implementation uses -@Data.IntMap@, which is both maintained and faster than the past -implementation (see commit log). +The implementation is a 'Word64Map' keyed by each element's 'Unique'; +see Note [Uniques and UniqFM shape]. -The @UniqFM@ interface maps directly to Data.IntMap, only -``Data.IntMap.union'' is left-biased and ``plusUFM'' right-biased -and ``addToUFM\_C'' and ``Data.IntMap.insertWith'' differ in the order +The @UniqFM@ interface maps directly to Word64Map, only +``Word64Map.union'' is left-biased and ``plusUFM'' right-biased +and ``addToUFM\_C'' and ``Word64Map.insertWith'' differ in the order of arguments of combining function. -} @@ -100,6 +99,55 @@ import qualified Data.Semigroup as Semi import Data.Functor.Classes (Eq1 (..)) import Data.Coerce +{- Note [Uniques and UniqFM shape] +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +A 'UniqFM' is a 'Word64Map' -- a big-endian PATRICIA trie -- keyed by the +'Word64' underlying each 'Unique'. A 'Unique' splits into a tag in the top 8 +bits (UNIQUE_TAG_BITS), identifying the supply or namespace that minted it, and +a running number in the low bits; see Note [Uniques and tags] in +GHC.Types.Unique. Those numbers are allocated sequentially -- from the global +'genSym' counter, or by 'uniqAway' from a set's largest local unique -- so they +stay far below the full 'Word64' range. Within a tag the keys are thus dense and +sequential, not scattered hashes, which keeps the trie shallow and is what makes +a 'Word64Map' a good fit. And because those numbers only grow, inserts within a +cluster tend to land above its existing keys -- a near-monotonic pattern that +big-endian PATRICIA tries service superoptimally, well below the O(log n) +worst case (see #24137). + +A PATRICIA trie branches on the most-significant bit on which its keys disagree, +so the tag bits are tested first, nearest the root. Uniques are therefore +partitioned by tag near the root: all keys with a given tag occupy a single +subtree (the largest one whose prefix already fixes every tag bit), and two +keys with different tags diverge closer to the root, where the trie switches on +a tag bit. In other words the high-order tag clusters together the keys minted +by each part of the compiler. + +This clustering would make tag-keyed bulk operations cheap -- collecting the +distinct tags, filtering to a set of tags, or splitting into per-tag submaps +could each reuse whole subtrees and touch O(number of distinct tags) nodes +rather than O(size). That is only potential, though: GHC has no tag-aware bulk +operations yet. + +The flip side is that the tag bits lengthen the path every per-key operation +walks: a lookup, insert, or delete descends past the tag-distinguishing nodes +near the root before reaching the number bits. Mixing tags thus adds branch +levels above each entry -- at most 7, since the tag is 8 bits with its top bit +clear for every ASCII tag. In-scope sets and 'VarSet's are the heavy case: +keyed by 'Var' uniques, they gather ~8-11 supply tags (desugarer, simplifier, +'uniqAway', wired-in, typechecker), spanning most of the tag bits, so a lookup +descends roughly 3-5 extra levels. A 'NameEnv'/'TypeEnv' is milder: external +names all share HscTag, so it is one big cluster plus a few wired-in and local +tags, ~2-4 levels. A map holding a single tag collapses the tag bits into the +root prefix and is correspondingly shallower, so keeping a map tag-homogeneous +(or splitting it by tag) speeds up its lookups. + +The trie's key order is exploited the other way too, to mint uniques: 'uniqAway' +derives a fresh unique not in an 'InScopeSet' from the largest key already in +that set's local-unique region (an O(depth) 'lookupLT') and increments it, +staying in that dedicated tag region (the 'X' tag), which cannot clash with +counter-allocated ones. See Note [Local uniques] in GHC.Types.Var.Env. +-} + -- | A finite map from @uniques@ of one type to -- elements in another type. -- ===================================== compiler/GHC/Types/Var/Env.hs ===================================== @@ -228,7 +228,9 @@ uniqAway' in_scope var -- | @unsafeGetFreshUnique in_scope@ finds a unique that is not in-scope in the -- given 'InScopeSet'. This must be used very carefully since one can very easily --- introduce non-unique 'Unique's this way. See Note [Local uniques]. +-- introduce non-unique 'Unique's this way. See Note [Local uniques], and +-- Note [Uniques and UniqFM shape] in GHC.Types.Unique.FM for the 'lookupLT' +-- trie mechanics it relies on. unsafeGetFreshLocalUnique :: InScopeSet -> Unique unsafeGetFreshLocalUnique (InScope set) | Just (uniq,_) <- Word64Map.lookupLT (getKey maxLocalUnique) (ufmToIntMap $ getUniqSet set) View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/ce9990825bda64c72e554f5c473e64d… -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/ce9990825bda64c72e554f5c473e64d… You're receiving this email because of your account on gitlab.haskell.org.

1 0

[Git][ghc/ghc][wip/marge_bot_batch_merge_job] 14 commits: libraries/process: bump submodule to v1.6.30.0
by Marge Bot (＠marge-bot) 14 Jun '26

14 Jun '26

Marge Bot pushed to branch wip/marge_bot_batch_merge_job at Glasgow Haskell Compiler / GHC Commits: d9ea2d76 by mangoiv at 2026-06-13T04:41:51-04:00 libraries/process: bump submodule to v1.6.30.0 - bump the submodule to the appropriate tag - suppress benign warning resulting from the change - - - - - 6ebaaba3 by David Eichmann at 2026-06-13T04:42:37-04:00 ghc-toolchain: don't throw when candidate executables are not found Fixes #27369 - - - - - 6c65e1e1 by David Eichmann at 2026-06-13T04:43:23-04:00 CI: lint-changelog checks for no-changelog label in script instead of rules - - - - - 4cfcdc5d by Matthew Pickering at 2026-06-14T11:39:13+02:00 Add missing req_interp modifier to T18441fail3 and T18441fail19 These tests require the interpreter but they were failing in a different way with the javascript backend because the interpreter was disabled and stderr is ignored by the test. - - - - - a9d868b7 by Matthew Pickering at 2026-06-14T11:39:13+02:00 hadrian: Fill in more of the default.host toolchain file When you are building a cross compiler this file will be used to build stage1 and it's libraries, so we need enough information here to work accurately. There is still more work to be done (see for example, word size is still fixed). - - - - - 59b15623 by Matthew Pickering at 2026-06-14T11:39:13+02:00 hadrian: Build stage 2 cross compilers * Most of hadrian is abstracted over the stage in order to remove the assumption that the target of all stages is the same platform. This allows the RTS to be built for two different targets for example. * Abstracts the bindist creation logic to allow building either normal or cross bindists. Normal bindists use stage 1 libraries and a stage 2 compiler. Cross bindists use stage 2 libararies and a stage 2 compiler. * 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 New hadrian target: * `binary-dist-dir-cross`: Build a cross compiler bindist (compiler = stage 1, libraries = stage 2) This commit also contains various changes to make stage2 compilers feasible. ------------------------- Metric Decrease: LinkableUsage02 ManyAlternatives ManyConstructors MultiComponentModulesRecomp MultiLayerModulesRecomp RecordUpdPerf T10421 T12150 T12227 T12425 T12707 T13035 T13379 T13820 T15703 T16577 T18140 T18282 T18698a T18698b T18923 T1969 T20049 T21839c T3294 T4801 T5030 T5321FD T5321Fun T5631 T5642 T6048 T783 T9020 T9198 T9233 T9630 T9872d T9961 parsing001 T3064 Metric Increase: T26989 hard_hole_fits ------------------------- Co-authored-by: Sven Tennie <sven.tennie(a)gmail.com> - - - - - e98029d5 by Matthew Pickering at 2026-06-14T11:39:13+02:00 ci: Test cross bindists We remove the special logic for testing in-tree cross compilers and instead test cross compiler bindists, like we do for all other platforms. - - - - - 25b52761 by Matthew Pickering at 2026-06-14T11:39:13+02:00 ci: Introduce CROSS_STAGE variable In preparation for building and testing stage3 bindists we introduce the CROSS_STAGE variable which is used by a CI job to determine what kind of bindist the CI job should produce. At the moment we are only using CROSS_STAGE=2 but in the future we will have some jobs which set CROSS_STAGE=3 to produce native bindists for a target, but produced by a cross compiler, which can be tested on by another CI job on the native platform. CROSS_STAGE=2: Build a normal cross compiler bindist CROSS_STAGE=3: Build a stage 3 bindist, one which is a native compiler and library for the target - - - - - 61366700 by Sven Tennie at 2026-06-14T11:39:13+02:00 ci: Increase timeout for emulators Test runs with emulators naturally take longer than on native machines. Generate jobs.yml - - - - - 12362d0e by Matthew Pickering at 2026-06-14T11:39:13+02:00 ci: Javascript don't set CROSS_EMULATOR There is no CROSS_EMULATOR needed to run javascript binaries, so we don't set the CROSS_EMULATOR to some dummy value. - - - - - 43713b0c by Sven Tennie at 2026-06-14T11:39:14+02:00 Javascript skip T23697 See #22355 about how HSC2HS and the Javascript target don't play well together. - - - - - fab848a0 by Sven Tennie at 2026-06-14T11:39:14+02:00 Mark T24602 as fragile It was skipped before (due to CROSS_EMULATOR being set, which changed for JS), so we don't make things worse by marking it as fragile. - - - - - a38c291b by Sven Tennie at 2026-06-14T11:39:14+02:00 Fix T22744 for GHCJS In fact, this test needs Template Haskell, not necessarily an interpreter. - - - - - e3984123 by konsumlamm at 2026-06-14T09:48:22-04:00 Implement CLC proposal #378 Add `Data.Double` and `Data.Float` modules Document that GHC uses IEEE 754 - - - - - 82 changed files: - .gitlab-ci.yml - .gitlab/ci.sh - .gitlab/generate-ci/gen_ci.hs - .gitlab/jobs.yaml - + changelog.d/stage2-cross-compilers - configure.ac - distrib/configure.ac.in - docs/users_guide/bugs.rst - hadrian/README.md - hadrian/bindist/config.mk.in - hadrian/cfg/default.host.target.in - + hadrian/cfg/system.config.host.in - hadrian/cfg/system.config.in - + hadrian/cfg/system.config.target.in - hadrian/hadrian.cabal - hadrian/src/Base.hs - + hadrian/src/BindistConfig.hs - hadrian/src/Builder.hs - hadrian/src/Context.hs - hadrian/src/Expression.hs - hadrian/src/Flavour.hs - hadrian/src/Flavour/Type.hs - hadrian/src/Hadrian/Builder.hs - hadrian/src/Hadrian/Haskell/Hash.hs - hadrian/src/Hadrian/Oracles/TextFile.hs - hadrian/src/Main.hs - hadrian/src/Oracles/Flag.hs - hadrian/src/Oracles/Flavour.hs - hadrian/src/Oracles/Setting.hs - hadrian/src/Oracles/TestSettings.hs - hadrian/src/Packages.hs - hadrian/src/Rules.hs - hadrian/src/Rules/BinaryDist.hs - hadrian/src/Rules/CabalReinstall.hs - hadrian/src/Rules/Changelog.hs - hadrian/src/Rules/Compile.hs - hadrian/src/Rules/Documentation.hs - hadrian/src/Rules/Generate.hs - hadrian/src/Rules/Gmp.hs - hadrian/src/Rules/Library.hs - hadrian/src/Rules/Program.hs - hadrian/src/Rules/Register.hs - hadrian/src/Rules/Rts.hs - hadrian/src/Rules/Test.hs - hadrian/src/Settings.hs - hadrian/src/Settings/Builders/Cabal.hs - hadrian/src/Settings/Builders/Common.hs - hadrian/src/Settings/Builders/Configure.hs - hadrian/src/Settings/Builders/DeriveConstants.hs - hadrian/src/Settings/Builders/Ghc.hs - hadrian/src/Settings/Builders/Hsc2Hs.hs - hadrian/src/Settings/Builders/RunTest.hs - hadrian/src/Settings/Builders/SplitSections.hs - hadrian/src/Settings/Default.hs - hadrian/src/Settings/Flavours/GhcInGhci.hs - hadrian/src/Settings/Flavours/Performance.hs - hadrian/src/Settings/Flavours/QuickCross.hs - hadrian/src/Settings/Packages.hs - hadrian/src/Settings/Program.hs - hadrian/src/Settings/Warnings.hs - libraries/base/base.cabal.in - libraries/base/changelog.md - + libraries/base/src/Data/Double.hs - + libraries/base/src/Data/Float.hs - libraries/base/tests/all.T - libraries/ghc-internal/src/GHC/Internal/Float.hs - libraries/process - m4/fp_find_nm.m4 - m4/prep_target_file.m4 - testsuite/driver/testlib.py - testsuite/ghc-config/ghc-config.hs - testsuite/tests/ghc-e/should_fail/all.T - testsuite/tests/interface-stability/base-exports.stdout - testsuite/tests/interface-stability/base-exports.stdout-javascript-unknown-ghcjs - testsuite/tests/interface-stability/base-exports.stdout-mingw32 - testsuite/tests/javascript/closure/all.T - testsuite/tests/perf/compiler/all.T - utils/ghc-toolchain/src/GHC/Toolchain/Program.hs - utils/ghc-toolchain/src/GHC/Toolchain/Utils.hs - utils/haddock/html-test/ref/Hash.html - utils/haddock/html-test/ref/Test.html - utils/haddock/html-test/ref/TypeFamilies3.html The diff was not included because it is too large. View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/f1b098bcb1dbf14ae8fbaa7482f18f… -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/f1b098bcb1dbf14ae8fbaa7482f18f… You're receiving this email because of your account on gitlab.haskell.org.

1 0

[Git][ghc/ghc][wip/romes/hadrian-cross-stage2-rebase_SVEN_FINAL] 26 commits: hadrian: Remove old package.conf files when generating new ones
by Sven Tennie (＠supersven) 14 Jun '26

14 Jun '26

Sven Tennie pushed to branch wip/romes/hadrian-cross-stage2-rebase_SVEN_FINAL at Glasgow Haskell Compiler / GHC Commits: 5ac9ce7d by Zubin Duggal at 2026-06-10T21:26:32+05:30 hadrian: Remove old package.conf files when generating new ones Old package.conf files might exists with different hashes, causing issues like #26661 Fixes #26661 - - - - - c9015f09 by sheaf at 2026-06-11T12:40:28-04:00 Fix AArch64 clobbering bug for MUL2 On AArch64, the code generator could clobber one of the input operands when computing the lower bits of a MUL2 operation. This rendered invalid the subsequent computation of the high bits. This commit fixes that by using a temporary register. The register allocator can remove the redundant move in the common case when the registers do not conflict. Fixes #27046 - - - - - 7ab90288 by Rodrigo Mesquita at 2026-06-11T12:41:11-04:00 fix: make T27131 less flaky It seems that T27131 fails flakily in a race where we check the flag before the capability had the chance to process the mailbox which sets the flag. This seemingly should only happen if the capability ends up being the same for setting and checking the flag. - - - - - 8965cb76 by Marc Scholten at 2026-06-12T04:53:22-04:00 haddock: render modules concurrently - - - - - 8cc0b64a by Duncan Coutts at 2026-06-12T04:54:06-04:00 Promote HAVE_PREEMPTION from Timer.c to OSThreads.h We will want to know about HAVE_PREEMPTION in more places. HAVE_PREEMPTION tells us that we do have OS threads available, irrespective of whether THREADED is defined. In particular, HAVE_PREEMPTION is defined on all proper OSs, but not on WASM (and hyopthetically may not be true on some other platforms like micro-controllers, RTOSs, VM hypervisors etc). - - - - - cce574ed by Duncan Coutts at 2026-06-12T04:54:06-04:00 Define ACQUIRE_LOCK_ALWAYS and friends Fix issue #27335 Like the atomic _ALWAYS variants, these lock actions are always defined, rather than being dependent on whether we are in the THREADED case. All the "normal" LOCK macros are defined to be no-ops when !THREADED. The use case for the _ALWAYS variants is where we are using OS threads even in the non-threaded RTS. This includes everything to do with the timer/ticker thread, which is used in the non-threaded RTS too. In particular, we will want to use this for eventlog things, because the timer thread performs eventlogging concurrently with the main capability, even in the non-threaded RTS. - - - - - 1f28d1f6 by Duncan Coutts at 2026-06-12T04:54:06-04:00 Use ACQUIRE/RELEASE_LOCK_ALWAYS with eventBufMutex Even in the non-threaded RTS the eventBufMutex is needed by both the main capability and the timer/ticker thread, so always use the mutex. This should fix #25165 which is about the main capability and the timer thread posting events to the eventlog buffer concurrently and thereby corrupting the buffer data. - - - - - 0ff29782 by Duncan Coutts at 2026-06-12T04:54:06-04:00 Expose eventBufMutex in the EventLog interface/header We will need it in forkProcess to ensure we don't write to the global eventlog buffer concurrently with trying to flush eventlog buffers and do the fork(). - - - - - 7a688395 by Duncan Coutts at 2026-06-12T04:54:07-04:00 Split flushAllCapsEventsBufs into safe and unlocked version Following the convention that unlocked versions have a trailing _ underscore in their name. This one requires the caller to hold the eventlog global buffer mutex. We will need this in forkProcess. - - - - - 341ed474 by Duncan Coutts at 2026-06-12T04:54:07-04:00 Remove redundant use of stopTimer in setNumCapabilities Historically, the comment here was: We must stop the interval timer while we are changing the capabilities array lest handle_tick may try to context switch an old capability. See #17289. and We must disable the timer while we do this since the tick handler may call contextSwitchAllCapabilities, which may see the capabilities array as we free it. What this refers to is that historically, when changing the number of capabilities, the array of capabilities was reallocated to a new size, allocating new ones and freeing the old ones, thus invalidating all existing capbility pointers. Strangely, for good measure the code used to call stopTimer twice (hence the two similar comments above). However, since commit a3eccf06292dd666b24606251a52da2b466a9612, the capabilities array is no longer reallocated. Instead the array is allcoated once on RTS startup to the maximum size it could ever be allowed to be, and then capabilities get enabled/disabled at runtime. So the capability pointers never become invalid anymore. At worst, they may point to capabilities that are disabled. Thus we no longer need to stop the timer (twice) while we change the number of enabled capabilities. This also partially solves issue #27105, which notes that stopTimer is being used as if it were synchronous, when it is not. At least for this case, the solution is that stopTimer is not needed at all! - - - - - 674858e3 by Duncan Coutts at 2026-06-12T04:54:07-04:00 Remove redundant use of stopTimer in forkProcess but replace it with taking the eventlog buffer lock during the fork. Fixes issue #27105 The original reason to block the timer during a fork was that historically the timer was implemented using a periodic timer signal, and the signal itself would interrupt the fork system call (returning EINTR). For large processes (where fork() takes a while) this could permanently livelock: the timer always would go off before the fork could complete, which got retried in a loop forever. The timer is no longer implemented as a unix signal, but uses threads. Thus the original problem no longer exists. The only remaining reason to block the timer tick is to prevent actions taken by the tick from interfering with the delicate process involved in fork (taking a load of locks and pausing everything). The only thing we need to do is to prevent the eventlog from being written to or flushed while the fork is taking place. To achieve this all we need to do is hold the mutex for the global eventlog buffer. This removes the last use of stopTimer that expects stopTimer to work synchronously (which it was not) and thus solves issue #27105. To be clear, we solve issue #27105 not by making stopTimer synchronous, but by eliminating the use sites that expected it to be synchronous. - - - - - 40764930 by sheaf at 2026-06-12T14:54:43-04:00 Add type family performance test for #26426 Some GHC versions produced large numbers of coercions after typechecking and desugaring when compiling the program in #26426: Version | Typechecker time | Typechecker allocations | Coercions -------:|-----------------:|------------------------:|---------: 9.6 | 47 ms | 48 MB | 110k 9.8 | 1000 ms | 486 MB | 10,437k 9.10 | 922 ms | 489 MB | 10,436k 9.12 | 906 ms | 482 MB | 10,437k 9.14 | 63 ms | 55 MB | 333k 10.0 | 47 ms | 64 MB | 35k The improvement 9.12 -> 9.14 was due to commit 22d11fa818fae2c95c494fc0fac1f8cb4c6e7cb6, while the improvement 9.14 -> 10.0 was due to commit 0b7df6db9e46df40e86fbff1a66dc10440b99db5. As the behaviour of GHC seems better than it's ever been on this program, we declare victory, adding this performance test to ensure we don't regress on this program. On the way, we update Note [Combining equalities] in GHC.Tc.SolveR.Equality with the explanation of the 9.12 -> 9.14 improvement (getting rid of an exponential blowup in coercion sizes), and we update Note [Exploiting closed type families] in GHC.Tc.Solver.FunDeps with the explanation of the 9.14 -> 10.0 improvement (bringing down coercion size growth from cubic to quadratic). - - - - - 0f3d0a71 by Zubin Duggal at 2026-06-12T14:55:30-04:00 compiler: mark tool messages as errors/warnings depending on the exit code Fixes #27370 - - - - - d9ea2d76 by mangoiv at 2026-06-13T04:41:51-04:00 libraries/process: bump submodule to v1.6.30.0 - bump the submodule to the appropriate tag - suppress benign warning resulting from the change - - - - - 6ebaaba3 by David Eichmann at 2026-06-13T04:42:37-04:00 ghc-toolchain: don't throw when candidate executables are not found Fixes #27369 - - - - - 6c65e1e1 by David Eichmann at 2026-06-13T04:43:23-04:00 CI: lint-changelog checks for no-changelog label in script instead of rules - - - - - 4cfcdc5d by Matthew Pickering at 2026-06-14T11:39:13+02:00 Add missing req_interp modifier to T18441fail3 and T18441fail19 These tests require the interpreter but they were failing in a different way with the javascript backend because the interpreter was disabled and stderr is ignored by the test. - - - - - a9d868b7 by Matthew Pickering at 2026-06-14T11:39:13+02:00 hadrian: Fill in more of the default.host toolchain file When you are building a cross compiler this file will be used to build stage1 and it's libraries, so we need enough information here to work accurately. There is still more work to be done (see for example, word size is still fixed). - - - - - 59b15623 by Matthew Pickering at 2026-06-14T11:39:13+02:00 hadrian: Build stage 2 cross compilers * Most of hadrian is abstracted over the stage in order to remove the assumption that the target of all stages is the same platform. This allows the RTS to be built for two different targets for example. * Abstracts the bindist creation logic to allow building either normal or cross bindists. Normal bindists use stage 1 libraries and a stage 2 compiler. Cross bindists use stage 2 libararies and a stage 2 compiler. * 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 New hadrian target: * `binary-dist-dir-cross`: Build a cross compiler bindist (compiler = stage 1, libraries = stage 2) This commit also contains various changes to make stage2 compilers feasible. ------------------------- Metric Decrease: LinkableUsage02 ManyAlternatives ManyConstructors MultiComponentModulesRecomp MultiLayerModulesRecomp RecordUpdPerf T10421 T12150 T12227 T12425 T12707 T13035 T13379 T13820 T15703 T16577 T18140 T18282 T18698a T18698b T18923 T1969 T20049 T21839c T3294 T4801 T5030 T5321FD T5321Fun T5631 T5642 T6048 T783 T9020 T9198 T9233 T9630 T9872d T9961 parsing001 T3064 Metric Increase: T26989 hard_hole_fits ------------------------- Co-authored-by: Sven Tennie <sven.tennie(a)gmail.com> - - - - - e98029d5 by Matthew Pickering at 2026-06-14T11:39:13+02:00 ci: Test cross bindists We remove the special logic for testing in-tree cross compilers and instead test cross compiler bindists, like we do for all other platforms. - - - - - 25b52761 by Matthew Pickering at 2026-06-14T11:39:13+02:00 ci: Introduce CROSS_STAGE variable In preparation for building and testing stage3 bindists we introduce the CROSS_STAGE variable which is used by a CI job to determine what kind of bindist the CI job should produce. At the moment we are only using CROSS_STAGE=2 but in the future we will have some jobs which set CROSS_STAGE=3 to produce native bindists for a target, but produced by a cross compiler, which can be tested on by another CI job on the native platform. CROSS_STAGE=2: Build a normal cross compiler bindist CROSS_STAGE=3: Build a stage 3 bindist, one which is a native compiler and library for the target - - - - - 61366700 by Sven Tennie at 2026-06-14T11:39:13+02:00 ci: Increase timeout for emulators Test runs with emulators naturally take longer than on native machines. Generate jobs.yml - - - - - 12362d0e by Matthew Pickering at 2026-06-14T11:39:13+02:00 ci: Javascript don't set CROSS_EMULATOR There is no CROSS_EMULATOR needed to run javascript binaries, so we don't set the CROSS_EMULATOR to some dummy value. - - - - - 43713b0c by Sven Tennie at 2026-06-14T11:39:14+02:00 Javascript skip T23697 See #22355 about how HSC2HS and the Javascript target don't play well together. - - - - - fab848a0 by Sven Tennie at 2026-06-14T11:39:14+02:00 Mark T24602 as fragile It was skipped before (due to CROSS_EMULATOR being set, which changed for JS), so we don't make things worse by marking it as fragile. - - - - - a38c291b by Sven Tennie at 2026-06-14T11:39:14+02:00 Fix T22744 for GHCJS In fact, this test needs Template Haskell, not necessarily an interpreter. - - - - - 101 changed files: - .gitlab-ci.yml - .gitlab/ci.sh - .gitlab/generate-ci/gen_ci.hs - .gitlab/jobs.yaml - + changelog.d/T27046 - + changelog.d/hadrian-stale-package-confs-26661 - + changelog.d/stage2-cross-compilers - + changelog.d/tool-messages-27370 - compiler/GHC/CmmToAsm/AArch64/CodeGen.hs - compiler/GHC/SysTools/Process.hs - compiler/GHC/Tc/Solver/Equality.hs - compiler/GHC/Tc/Solver/FunDeps.hs - configure.ac - distrib/configure.ac.in - hadrian/README.md - hadrian/bindist/config.mk.in - hadrian/cfg/default.host.target.in - + hadrian/cfg/system.config.host.in - hadrian/cfg/system.config.in - + hadrian/cfg/system.config.target.in - hadrian/hadrian.cabal - hadrian/src/Base.hs - + hadrian/src/BindistConfig.hs - hadrian/src/Builder.hs - hadrian/src/Context.hs - hadrian/src/Expression.hs - hadrian/src/Flavour.hs - hadrian/src/Flavour/Type.hs - hadrian/src/Hadrian/Builder.hs - hadrian/src/Hadrian/Haskell/Cabal/Parse.hs - hadrian/src/Hadrian/Haskell/Hash.hs - hadrian/src/Hadrian/Oracles/TextFile.hs - hadrian/src/Main.hs - hadrian/src/Oracles/Flag.hs - hadrian/src/Oracles/Flavour.hs - hadrian/src/Oracles/Setting.hs - hadrian/src/Oracles/TestSettings.hs - hadrian/src/Packages.hs - hadrian/src/Rules.hs - hadrian/src/Rules/BinaryDist.hs - hadrian/src/Rules/CabalReinstall.hs - hadrian/src/Rules/Changelog.hs - hadrian/src/Rules/Compile.hs - hadrian/src/Rules/Documentation.hs - hadrian/src/Rules/Generate.hs - hadrian/src/Rules/Gmp.hs - hadrian/src/Rules/Library.hs - hadrian/src/Rules/Program.hs - hadrian/src/Rules/Register.hs - hadrian/src/Rules/Rts.hs - hadrian/src/Rules/Test.hs - hadrian/src/Settings.hs - hadrian/src/Settings/Builders/Cabal.hs - hadrian/src/Settings/Builders/Common.hs - hadrian/src/Settings/Builders/Configure.hs - hadrian/src/Settings/Builders/DeriveConstants.hs - hadrian/src/Settings/Builders/Ghc.hs - hadrian/src/Settings/Builders/Hsc2Hs.hs - hadrian/src/Settings/Builders/RunTest.hs - hadrian/src/Settings/Builders/SplitSections.hs - hadrian/src/Settings/Default.hs - hadrian/src/Settings/Flavours/GhcInGhci.hs - hadrian/src/Settings/Flavours/Performance.hs - hadrian/src/Settings/Flavours/QuickCross.hs - hadrian/src/Settings/Packages.hs - hadrian/src/Settings/Program.hs - hadrian/src/Settings/Warnings.hs - libraries/base/tests/all.T - libraries/process - m4/fp_find_nm.m4 - m4/prep_target_file.m4 - rts/Capability.c - rts/Schedule.c - rts/Timer.c - rts/eventlog/EventLog.c - rts/eventlog/EventLog.h - rts/include/rts/OSThreads.h - testsuite/driver/testlib.py - testsuite/ghc-config/ghc-config.hs - + testsuite/tests/codeGen/should_run/T27046.hs - + testsuite/tests/codeGen/should_run/T27046_cmm.cmm - testsuite/tests/codeGen/should_run/all.T - + testsuite/tests/driver/T27370/Makefile - + testsuite/tests/driver/T27370/T27370.hs - + testsuite/tests/driver/T27370/T27370.pp - + testsuite/tests/driver/T27370/T27370.stderr - + testsuite/tests/driver/T27370/all.T - testsuite/tests/ghc-e/should_fail/all.T - testsuite/tests/javascript/closure/all.T - + testsuite/tests/perf/compiler/T26426.hs - testsuite/tests/perf/compiler/all.T - testsuite/tests/rts/T27131.hs - testsuite/tests/rts/T27131.stdout - utils/ghc-toolchain/src/GHC/Toolchain/Program.hs - utils/ghc-toolchain/src/GHC/Toolchain/Utils.hs - utils/haddock/haddock-api/haddock-api.cabal - utils/haddock/haddock-api/src/Haddock.hs - utils/haddock/haddock-api/src/Haddock/Backends/Hyperlinker.hs - utils/haddock/haddock-api/src/Haddock/Backends/Xhtml.hs - utils/haddock/haddock-api/src/Haddock/Options.hs - utils/haddock/haddock-api/src/Haddock/Utils.hs The diff was not included because it is too large. View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/5bbd73360da2da06e4abfe7b196bef… -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/5bbd73360da2da06e4abfe7b196bef… You're receiving this email because of your account on gitlab.haskell.org.

1 0

[Git][ghc/ghc] Pushed new branch wip/sjakobi/uniqfm-note
by Simon Jakobi (＠sjakobi2) 14 Jun '26

14 Jun '26

Simon Jakobi pushed new branch wip/sjakobi/uniqfm-note at Glasgow Haskell Compiler / GHC -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/tree/wip/sjakobi/uniqfm-note You're receiving this email because of your account on gitlab.haskell.org.

1 0

[Git][ghc/ghc] Pushed new branch wip/ad-hoc-lazifier
by Jaro Reinders (＠jaro) 14 Jun '26

14 Jun '26

Jaro Reinders pushed new branch wip/ad-hoc-lazifier at Glasgow Haskell Compiler / GHC -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/tree/wip/ad-hoc-lazifier You're receiving this email because of your account on gitlab.haskell.org.

1 0