GHC 9.6.6 is now available

The GHC developers are happy to announce the availability of GHC 9.6.6. Binary
distributions, source distributions, and documentation are available on the
release page.

Blog Post: GHC 9.6.6 is now available — The Glasgow Haskell Compiler

This release is primarily a bugfix release addressing some issues
found in the 9.6 series. These include:

  • A fix for a bug in the NCG that could lead to incorrect runtime results due to
    erroneously removing a jump instruction (#24507).
  • A fix for a linker error that manifested on certain platform/toolchain combinations,
    particularly darwin with a brew provisioned toolchain, arising due to a confusion
    in linker options between GHC and cabal (#22210).
  • A fix for a compiler panic in the simplifier due to incorrect eta expansion (#24718).
  • A fix for possible segfaults when using the bytecode interpreter due to incorrect
    constructor tagging (#24870).
  • And a few more fixes

A full accounting of changes can be found in the release notes. As
some of the fixed issues do affect correctness users are encouraged to
upgrade promptly.

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 Hacking!

-Zubin

18 Likes

I have updated Stack’s default setup-info dictionary for these binary distributions, and added GHC 9.6.6’s global hints to global-hints.yaml .

2 Likes

Curated bindists: Index of /ghcup/unofficial-bindists/ghc/9.6.6/

  • freebsd-x86_64 and alpine-i386 are only provided by ghcup
  • the other bindists have fixed documentation (manpage, user manual, etc. are missing from official ones)
2 Likes

I don’t see hls-powered attached with this. I thought changes between 9.6.5 and 9.6.6 were merely bugfixes rather than new features and don’t see any changes in base version as well.
So my assumption was that it would, by default, be supported by the hls-2.9.0.0.

Could you correct my understanding here.
Thanks

There is HLS 2.9.0.1 in works, I imagine it will be available pretty soon.

1 Like

GHC has no practical ABI compatibility. For every new GHC a new HLS binary needs to be built.

You can think of HLS as a proper compiler.

1 Like

if you don’t mind me asking, by when would we be able to use hls and cabal and a common ghc for both regular Haskell development and wasm or js development in haskell?

How far or close are we from that? Because after using Haskell, I want to continue using Haskell for everything.

I think it would be good if GHC maintains a status page about JS/WASM somewhere. Maybe that already exists @mpickering?

I think the keyword you are looking for is “runtime retargetability”, i.e. being able to use a single GHC binary to compile for multiple targets. There is definitely work going on here by @romes and others, but I don’t know how close we are.

1 Like

That’s right. I’m not actively working on it at the moment (even though it is on my priority list to get back to it when possible), but “runtime retargetability” would mean the same compiler could produce code for multiple targets such as x86_64, aarch64, JS, WASM, etc…

GHC has been coming closer than ever to being runtime retargetable over the years due to the work of many people, but there’s still a considerable amount of work to be done. As for me, I picked the project up in the toolchain configuration end of it and did a lot of progress on a tool to configure multiple targets and their toolchains that GHC can understand: ghc-toolchain. Here’s a blog post on it: Improving GHC's configuration logic and cross-compilation support with ghc-toolchain - Well-Typed: The Haskell Consultants

5 Likes