GHC 9.4.1 is now available!

The GHC developers are very pleased to announce the availability of GHC
9.4.1. Binary distributions, source distributions, and documentation are
available at

This release includes:

  • A new profiling mode, -fprof-late, which adds automatic cost-center
    annotations to all top-level functions after Core optimisation has
    run. This provides informative profiles while interfering
    significantly less with GHC’s aggressive optimisations, making it
    easier to understand the performance of programs which depend upon

  • A variety of plugin improvements including the introduction of a new
    plugin type, defaulting plugins, and the ability for typechecking
    plugins to rewrite type-families.

  • An improved constructed product result analysis, allowing unboxing of
    nested structures, and a new boxity analysis, leading to less reboxing.

  • Introduction of a tag-check elision optimisation, bringing
    significant performance improvements in strict programs.

  • Generalisation of a variety of primitive types to be levity
    polymorphic. Consequently, the ArrayArray# type can at long last be
    retired, replaced by standard Array#.

  • Introduction of the \cases syntax from GHC proposal 0302.

  • A complete overhaul of GHC’s Windows support. This includes a
    migration to a fully Clang-based C toolchain, a deep refactoring of
    the linker, and many fixes in WinIO.

  • Support for multiple home packages, significantly improving support
    in IDEs and other tools for multi-package projects.

  • A refactoring of GHC’s error message infrastructure, allowing GHC to
    provide diagnostic information to downstream consumers as structured
    data, greatly easing IDE support.

  • Significant compile-time improvements to runtime and memory consumption.

  • On overhaul of our packaging infrastructure, allowing full
    traceability of release artifacts and more reliable binary

  • Reintroduction of deep subsumption (which was previously dropped with the
    simplified subsumption change) as a language extension.

  • … and much more. See the release notes for a full accounting.

Note that, as 9.4.1 is the first release for which the released artifacts will
all be generated by our Hadrian build system, it is possible that there will be
packaging issues. If you enounter trouble while using a binary distribution,
please open a ticket. Likewise, if you are a downstream packager, do consider
migrating to Hadrian to run your build; the Hadrian build system can be built
using cabal-install, stack, or the in-tree bootstrap script. See the accompanying
blog post for details on migrating packaging to Hadrian.

We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk stake pool,
Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, Haskell Foundation, 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.

Happy testing,

  • Ben

Might this release be related to this issue I just reported?

Congratulations Ben!


The aarch64-darwin seems to install some of the symlinks a bit wrong (I don’t think this is just ghcup!):

vanessa@Vanessas-Air bin % ./ghc-9.4.1
zsh: permission denied: ./ghc-9.4.1

vanessa@Vanessas-Air bin % file ghc-9.4.1
ghc-9.4.1: ASCII text
1 Like

The aarch64-darwin seems to install some of the symlinks a bit wrong (I don’t think this is just ghcup!):

Sigh, indeed, I can reproduce this and it does look wrong. It appears that Darwin’s cp -P behaves differently from the same from coreutils. Bizarrely, it appears that one must pass cp -RP to reproduce the standard semantics.

1 Like

Yes, it appears that BSD and coreutils differ in their behavior here; clearly we need to improve our testing coverage of the wrapper scripts.

I have fixed this issue in !8789. Needless to say, we will need to put out a 9.4.2 quite soon. In the meantime, BSD users can patch the binary distribution with,

--- Makefile.old        2022-08-07 18:26:32.288968006 -0400
+++ Makefile    2022-08-07 18:26:44.505988585 -0400
@@ -40,7 +40,7 @@
 define installscript
        echo "installscript $1 -> $2"
        @if [ -L 'wrappers/$1' ]; then                \
-               $(CP) -P 'wrappers/$1' '$2' ;             \
+               $(CP) -RP 'wrappers/$1' '$2' ;            \
        else                                                                      \
                rm -f '$2' &&                                 \
                $(CREATE_SCRIPT) '$2' &&                  \


Hi, couple of small things I note:

  1. Previous releases contained a directory ghc-9.2.4 in the archive. 9.4.1 instead has something like ghc-9.4.1-x86_64-unknown-linux for ghc-9.4.1-x86_64-deb10-linux.tar.xz. Unsure if this is a deliberate change.
  2. It seems that deb11 is supported for x86_64 but there is no aarch64 release. Can we expect aarch64 deb11 support to appear at some point?

So there’s no automatic testing of bindists?

1 Like

This is a result of the switch to Hadrian.

Sure, I can add this configuration.


There is indeed automatic testing of bindists in every CI job. However, this particular issue was not caught because we used coreutils in our Darwin testing environment rather than Darwin’s native BSD tools. This is being fixed.

For the record, this issue is being tracked as GHC #21974.


This sounds like only a limited number of people are affected (those that haven’t installed coreutils via brew)?

Hackage documentation index for base- seems broken. Pressing s doesn’t open the quick-jump search box. Though, it works with base-

Hmm, that is indeed mysterious. Can you open a ticket?

That is to some extent true; I’d imagine there are quite a few Darwin users who are using coreutils, although we certainly can’t depend upon this fact.

1 Like

Congrats on the release!

Can I help/pester ghcup install ghc 9.4.1 to happen? Is ghcup maintained by the GHC team?

Sure, here is the issue:

It’s maintained by @hasufell although we do try to work with him to ensure it’s well-supported. Unfortunately, the Darwin bindist issue mentioned above complicates matters.


You can install 9.4.1 already as a custom bindist, see the GHCup user guide page on installing custom bindists and the list of GHC binaries, e.g.:

ghcup install ghc -u '' 9.4.1

That is for the Debian 11 bindist, but should also work on some other Linux distributions.

1 Like

9.4.1 is now added to ghcup: Comparing 19bc7f338e8e3ccaa1ce22019e255165f935c506^...master · haskell/ghcup-metadata · GitHub

Fixed darwin bindists are hosted here: Index of /ghcup/unofficial-bindists/ghc/curated/9.4.1/


Why does: “ghcup install ghc”
seem to install ghc 8.10.7 by default instead of this newer version?

Also; I did a “ghcup install ghc 9.4.1” and it seemed to do it, but then running “ghc --version” still gives 8.10.2 , it seems I must manually edit the $PATH in the environment?