GHC 9.12.5-rc2 is now available

The GHC developers are very pleased to announce the availability
of the second release candidate for GHC 9.12.5, ghc-9.12.5-rc2. The first release candidate did not receive an announcement since promptly after publishing it, an urgent issue with distribution of the process library on macos was discovered. This is now fixed.
Binary distributions, source distributions, and documentation are available at
downloads.haskell.org and via GHCup.

GHC 9.12.5 is a bug-fix release fixing many issues of a variety of
severities and scopes, including:

  • Implement version 2 of the ghc semaphore protocol for GHC’s -jsem jobserver on Linux and other POSIX platforms (#25087, #27253)
  • several improvements to the pattern match checker (#25926, #27124)
  • several improvements to the demand analyser (#27261, #27106, #26416)
  • several fixes regarding the interaction of ticks and coercions (#27121, #26929, #26642, #26693)
  • several fixes for blackholes (#27261)

… and many more

Mind that the very important overhaul of the semaphore-compat library to v2 is included in this release and that the semaphore feature will only start working with cabal-install 3.18 again, which is sadly a breaking but necessary change.

A full accounting of these fixes can be found in the
release notes. As always, GHC’s release status, including planned future
releases, can be found on the GHC Wiki status.

This release candidate will have a two-week testing period. If all goes well
the final release will be available the week of 8 July 2026.

GHC development is sponsored by:

We would like to thank these sponsors and other anonymous contributors
whose on-going financial and in-kind support has facilitated GHC maintenance
and release management over the years. Finally, this release would not have
been possible without the hundreds of open-source contributors whose work
comprise this release.

As always, do give this release a try and open a ticket if you see
anything amiss.

18 Likes

the current ghc-9.12 release candidates still have a known segfault, as reported by @TeofilC and i’ve reproduced and found the culprit: Making sure you're not a bot!

3 Likes

Further information:

  1. This is a regression compared to 9.12.3 (9.12.4 also has this bug) that is part of a patch that fixes other issues
  2. there are two more patches that probably want backporting as they fix quite bad bugs that have been merged recently:

Which in total warrants another RC. I will backport the patches and put up another RC after the grace time (week of July 8) to make sure other potential issues can be discovered.

2 Likes

I there anything new in git to match this announcemt. All I see in terms of commits on the origin/ghc-9.12 branch are:

2026-06-14 3b176389fd base: correct changelog entry for 4.21.3.0
2026-06-11 cac0a6de9f libraries/process: bump submodule to v1.6.30.0
2026-06-06 be19b814a9 release 9.12.5: bump base version
2026-06-05 a0a26f8038 bootstrap plans: move to proper file name
2026-06-05 6c4f3d6860 release candidate 9.12.5: set release to no
2026-06-05 347c77f747 release engineering: update sources to make it work at all
2026-06-03 e76917b659 Revert "packaging: regenerate llvm-targets"
2026-06-02 2de6cf2f8b release-notes: fix typo
2026-06-02 8bba0d57c5 release 9.12.5: update hadrian bootstrap plans; move to proper file name
2026-06-02 7ed997deb7 release 9.12.5: update hadrian bootstrap plans

And FWIW:

$ git ls-remote --get-url origin
https://gitlab.haskell.org/ghc/ghc.git

Yes. Git diff against the release tag for 9.12.4.

So that commit from 2026-06-14 is rc2? A new tag would be handy…

Should be there now. :slight_smile:

3 Likes

Many thanks for this! I have a semaphore-related question:

The boot packages of GHC 9.12.14 include Cabal-3.14.2.0 and semaphore-compat-1.0.0 and the boot packages of GHC 9.12.15-rc2 include Cabal-3.14.2.0 and semaphore-compat-2.0.0.

Does that mean that Cabal (the library), itself, is indifferent, and intends to be indifferent, as to whether it is passed the name of a version 1 or version 2 semaphore? (That is, Cabal intends to leave it to the user of its --semaphore=<semaphone name> option to ensure that name relates to a semaphore with a version that is compatible with the GHC version that Cabal will use?

Or is there a plan that Cabal will, in some later version before GHC 9.12.5 is released, check compatibility between the version of the semaphore it is passed and the semaphore version supported by the GHC version it will use?

If you want to use with Stack:

Add a setup-info dictionary to a configuration file with the applicable entry for your operating system. For example, on Windows or macOS/AArch64, a stack.yaml:

snapshot: nightly-2026-06-22 # GHC 9.12.4
compiler: ghc-9.12.4.20260614
compiler-check: match-exact # Anticipating future rc releases

# Only required before the GHC version has been installed:
setup-info:
  ghc:
    windows64:
      9.12.4.20260614:
        url: https://downloads.haskell.org/ghc/9.12.5-rc2/ghc-9.12.4.20260614-x86_64-unknown-mingw32.tar.xz
        # Can be extended with SHA protections etc: see https://docs.haskellstack.org/en/stable/configure/yaml/non-project/#setup-info
    macosx-aarch64:
      9.12.4.20260614:
        url: https://downloads.haskell.org/ghc/9.12.5-rc2/ghc-9.12.4.20260614-aarch64-apple-darwin.tar.bz2
        # Can be extended with SHA protections etc: see https://docs.haskellstack.org/en/stable/configure/yaml/non-project/#setup-info

I have modified Stack (in its fix6934 branch) to depend on semaphore-compat-2.0.0 and build with GHC 9.12.5-rc2/Cabal-3.14.2.0. That works fine on Windows 11 and Linux (Ubuntu via WSL2) but on macOS 26.5.1 (on AArch64) I am getting a failure when I build stack with build --semaphore.

The error report is (reformatted, for ease of reading):

...
[217 of 217] Compiling Stack
CallStack (from HasCallStack):
  fdReadByte, called at libraries/semaphore-compat/src/System/Semaphore/Internal/Posix.hs:159:9 in semaphore-compat-2.0.0-068d:System.Semaphore.Internal.Posix
  waitOnSemaphore, called at compiler/GHC/Driver/MakeSem.hs:321:51 in ghc-9.12.4.20260614-868c:GHC.Driver.MakeSem: end of file (fd=13)

Error: [S-7282]
       Stack failed to execute the build plan.

       While executing the build plan, Stack encountered the error:

       [S-7011]
       While building package stack-3.12.0 (scroll up to its section to see the error) using:
       .../ghc-9.12.4.20260614/setup/setup
         --verbose=1 
         --builddir=.../ghc-9.12.4.20260614
         build lib:stack exe:stack 
         --semaphore v2-stack_1sPonmdUx 
         --ghc-options " -fdiagnostics-color=always"

There is no macOS-specific code involved at Stack’s end, so my hypothesis is that there may be something up with semaphore-combat-2.0.0 (perhaps in combination with Cabal-3.14.2.0) on macOS.

I turned on Stack’s and Cabal’s verbose reporting, and it ends with:

2026-06-26 14:09:22.878725: [info] [217 of 217] Compiling Stack
2026-06-26 14:09:23.030317: [warn] fdWriteByte(fd=13): resource vanished (Broken pipe)
2026-06-26 14:09:23.118799: [debug] Loading project config file stack-ghc-9.12.5.yaml
2026-06-26 14:09:23.120822: [debug] Use of Casa server enabled: (CasaRepoPrefix "https://casa.stackage.org", 1280).
2026-06-26 14:09:23.122446: [debug] (SQL) SELECT COUNT(*) FROM "last_performed" WHERE ("action"=?) AND ("timestamp">=?); [PersistInt64 1,PersistUTCTime 2026-06-25 13:09:23.122421 UTC]
2026-06-26 14:09:23.122775: [error]
...

The [info] and [warn] lines are Cabal’s reporting. The [debug] lines reflect Stack’s usual verbose reporting.

EDIT: There was a bug and (thanks to @wz1000) there is a fix:

1 Like