GHC 9.6.7 is now available

The GHC developers are very pleased to announce the availability of
GHC 9.6.7. Binary distributions, source distributions, and
documentation are available at https://downloads.haskell.org/ghc/9.6.7.

We hope to have this release available via ghcup shortly.

GHC 9.6.7 brings number of fixes, including:

  • GHC’s internal Unique type has been widened to 64-bits on 32-bit
    architectures, avoiding potential miscompilations on large projects.
  • Fix a runtime crash when using the compacting GC, caused by black
    holes in large objects.
  • Added new flags -fspec-eval and -fspec-eval-dictfun to allow
    switching off speculative evaluation.

The following libraries have been updated since GHC 9.6.6:

  • base-4.18.3.0
  • filepath-1.4.301.0
  • unix-2.8.6.0
  • bytestring-0.11.5.4
  • array-0.5.8.0

A more detailed description can be found in the release notes and a
full list of changes in GHC!13841 and GHC!13891

Note about Haskell Language Server and building GHC 9.8+:

The change of Unique to 64 bit GHC#22010 adds the exported symbol
ghc_unique_counter64 to the RTS. Unfortunately it’s impossible to
avoid this without breaking other things. If you encounter a linker
error related to ghc_unique_counter64 when building GHC (or building a
GHC-derived package like ghc-lib-parser) with GHC 9.6.7, you probably
have to add this fix to the program you’re building.

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

Please give this release a try and open a ticket if you see anything amiss.

~ Hécate, for release manager @luite

20 Likes

Can anyone explain these in more detail? The user’s guide explanation leaves a lot to be desired:

Enables speculative evaluation which usually results in fewer allocations. Enabling speculative evaluation should not cause performance regressions. If you encounter any, please open a ticket.
(source)

What is speculative execution? When should I disable it?

1 Like

This is not a GHC-specific concept, you can read more at https://en.wikipedia.org/wiki/Speculative_execution. In the context of GHC you can read a bit more in https://gitlab.haskell.org/ghc/ghc/-/issues/25284.

I’m sorry, but that wikipedia page doesn’t tell me much more than what I already knew: “Speculative execution means performing a task that might not be needed.” It lists a bunch of different kinds of speculative execution (which all seem to be at the level of CPU’s and not compilers by the way), but which one does GHC have? One of them even says:

A 2003 PhD thesis made GHC support a kind of speculative execution with an abortion mechanism to back out in case of a bad choice called optimistic execution.[9] It was deemed too complicated.[10]

Which makes me think GHC does not have it. Hence my surprise to find out GHC does have some form of speculative execution.

That issue seems to only concern the speculative execution of dictionaries, but that is a separate flag. Does GHC speculate on other thunks too?


I think this piece of documentation is what I was after:

-- | To a first approximation, 'exprOkForSpeculation' returns True of
-- an expression that is:
--
--  * Safe to evaluate even if normal order eval might not
--    evaluate the expression at all, and
--
--  * Safe /not/ to evaluate even if normal order would do so
--
-- More specifically, this means that:
--  * A: Evaluation of the expression reaches weak-head-normal-form,
--  * B: soon,
--  * C: without causing a write side effect (e.g. writing a mutable variable).
--
-- In particular, an expression that may
--  * throw a synchronous Haskell exception, or
--  * risk an unchecked runtime exception (e.g. array
--    out of bounds, divide by zero)
-- is /not/ considered OK-for-speculation, as these violate condition A.

So any expressions that satisfy those conditions might be evaluated speculatively.

3 Likes

This has landed in GHCup’s default channel now: GHC 9.6.7 proper by hasufell · Pull Request #291 · haskell/ghcup-metadata · GitHub

Changes compared to upstream:

  • added FreeBSD, Alpine i386 and Alpine aarch64 bindists
  • fixed missing manpages from 6 bindists

The bindists are stored here: Index of /ghcup/unofficial-bindists/ghc/9.6.7/

HLS is not (yet) supported, but you can build it yourself:

ghcup compile hls -g 2.9.0.1 --ghc 9.6.7 --cabal-update -- --constraint="ghc-lib-parser == 9.8.5.20250214" --index-state="2025-02-14T12:50:38Z"
12 Likes

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

2 Likes

For now I created a Fedora Linux copr repo (“ppa”) for ghc-9.6.7, while considering how to handle this extra release more officially: I plan to make official ghc9.6 package builds for the current stable fedora releases that use ghc-9.6.6 as the main ghc package at least.

Not sure yet if Stackage LTS 22 can be bumped to 9.6.7 at this point…

(One feedback again: I would have preferred to see hadrian’s dependency bump on directory to have been limited to Windows.)

1 Like