Aquileo | GHC Developer bloghttp://haskell.org/ghc Fri, 27 Mar 2026 00:00:00 UTAquileo | GHC 9.12.4 is now availablehttp://haskell.org/ghc/blog/20260327-ghc-9.12.4-released.html GHC 9.12.4 is now available

wz1000 - 2026-03-27

The GHC developers are very pleased to announce the release of GHC 9.12.4. Binary distributions, source distributions, and documentation are available at downloads.haskell.org and via GHCup.

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

  • Fixed a critical code generation regression where sub-word division produced incorrect results (#26711, #26668), similar to the bug fixed in 9.12.2

  • Numerous fixes for register allocation bugs, preventing data corruption when spilling and reloading registers (#26411, #26526, #26537, #26542, #26550)

  • Fixes for several compiler crashes, including issues with CSE (#25468), and the simplifier(#26681), implicit parameters (#26451), and the type-class specialiser (#26682)

  • Fixed cast worker/wrapper incorrectly firing on INLINE functions (#26903)

  • Fixed LLVM backend miscompilation of bit manipulation operations (#20645, #26065, #26109)

  • Fixed associated type family and data family instance changes not triggering recompilation (#26183, #26705)

  • Fixed negative type literals causing the compiler to hang (#26861)

  • Improvements to determinism of compiler output (#26846, #26858)

  • Fixes for eventlog shutdown deadlocks (#26573) and lost wakeups in the RTS (#26324)

  • Fixed split sections support on Windows (#26696, #26494) and the LLVM backend (#26770)

  • Fixes for the bytecode compiler, PPC native code generator, and Wasm backend

  • The runtime linker now supports COMMON symbols (#6107)

  • Improved backtrace support: backtraces for error exceptions are now evaluated at throw time

  • NamedDefaults now correctly requires the class to be standard or have an in-scope default declaration, and handles poly-kinded classes (#25775, #25778, #25882)

  • … and many more

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.

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.

]]>
Fri, 27 Mar 2026 00:00:00 UThttp://haskell.org/ghc/blog/20260327-ghc-9.12.4-released.htmlghc-devs
Aquileo | GHC 9.12.4-rc1 is now availablehttp://haskell.org/ghc/blog/20260313-ghc-9.12.4-rc1-released.html GHC 9.12.4-rc1 is now available

wz1000 - 2026-03-13

The GHC developers are very pleased to announce the availability of the release candidate for GHC 9.12.4. Binary distributions, source distributions, and documentation are available at downloads.haskell.org and via GHCup.

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

  • Fixed a critical code generation regression where sub-word division produced incorrect results (#26711, #26668), similar to the bug fixed in 9.12.2
  • Numerous fixes for register allocation bugs, preventing data corruption when spilling and reloading registers (#26411, #26526, #26537, #26542, #26550)
  • Fixes for several compiler crashes, including issues with CSE (#25468), SetLevels (#26681), implicit parameters (#26451), and the type-class specialiser (#26682)
  • Fixed cast worker/wrapper incorrectly firing on INLINE functions (#26903)
  • Fixed LLVM backend miscompilation of bit manipulation operations (#20645, #26065, #26109)
  • Fixed associated type family and data family instance changes not triggering recompilation (#26183, #26705)
  • Fixed negative type literals causing the compiler to hang (#26861)
  • Improvements to determinism of compiler output (#26846, #26858)
  • Fixes for eventlog shutdown deadlocks (#26573) and lost wakeups in the RTS (#26324)
  • Fixed split sections support on Windows (#26696, #26494) and the LLVM backend (#26770)
  • Fixes for the bytecode compiler, PPC native code generator, and Wasm backend
  • The runtime linker now supports COMMON symbols (#6107)
  • Improved backtrace support: backtraces for error exceptions are now evaluated at throw time
  • NamedDefaults now correctly requires the class to be standard or have an in-scope default declaration, and handles poly-kinded classes (#25775, #25778, #25882)
  • … and many more

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 26 March 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.

]]>
Fri, 13 Mar 2026 00:00:00 UThttp://haskell.org/ghc/blog/20260313-ghc-9.12.4-rc1-released.htmlghc-devs
Aquileo | GHC 9.12.3 is now availablehttp://haskell.org/ghc/blog/20251227-ghc-9.12.3-released.html GHC 9.12.3 is now available

zubin - 2025-12-27

The GHC developers are very pleased to announce the release of GHC 9.12.3. Binary distributions, source distributions, and documentation are available at downloads.haskell.org.

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

  • Fix a number of crashes and miscompilations in the compiler frontend (#25004, #25960, #26256)
  • Improvements to efficiency of the runtime linker (#26009)
  • Fixes for several bugs in bytecode generation and the bytecode interpreter (#23210, #25975, #25750)
  • Fixes for bugs in the handling of WHITEHOLEs in the RTS (#26204, #26205)
  • Fix incorrect code generation for SSE vector operations (#25859)
  • Fix a use-after-free in the Windows runtime linker (#26613)
  • Support for synchronous JSFFI exports for the wasm backend
  • And many more!

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.

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.

]]>
Sat, 27 Dec 2025 00:00:00 UThttp://haskell.org/ghc/blog/20251227-ghc-9.12.3-released.htmlghc-devs
Aquileo | GHC 9.14.1 is now availablehttp://haskell.org/ghc/blog/20251219-ghc-9.14.1-released.html GHC 9.14.1 is now available

zubin - 2025-12-19

The GHC developers are very pleased to announce the release of GHC 9.14.1. Binary distributions, source distributions, and documentation are available at downloads.haskell.org.

GHC 9.14 brings a number of new features and improvements, including:

  • Significant improvements in specialisation:

    • The SPECIALISE pragma now allows use of type application syntax
    • The SPECIALISE pragma can be used to specialise for expression arguments as well as type arguments.
    • Specialisation is now considerably more reliable in the presence of newtypes
  • Significant GHCi improvements including:

    • Correctness and performance improvements in the bytecode interpreter
    • Features in the GHCi debugger
    • Support for multiple home units in GHCi
  • Implementation of the Explicit Level Imports proposal

  • RequiredTypeArguments can now be used in more contexts

  • Greatly improved SSE/AVX2 support in the x86 native code generator backend

  • Initial native code generator support for LoongArch

  • The WebAssembly backend now supports evaluation via the interpreter, allowing GHCi and TemplateHaskell evaluation, including foreign import javascript usage from within the browser

  • A new primop annotateStack# for pushing arbitrary data onto the call stack for later extraction when decoding stack traces

  • -Wincomplete-record-selectors is now part of -Wall. Libraries compiled with -Werror may need adjustment.

  • A major update of the Windows toolchain

  • Improved compatibility with macOS Tahoe

  • … and many more

A full accounting of changes can be found in the release notes. See the migration guide for guidance on migrating programs to this release.

Note that while this release makes many improvements in the specialisation optimisation, polymorphic specialisation remains disabled by default in the release due to concern over regressions of the sort identified in #26329. Users needing more aggressive specialisation can explicitly enable this feature with the -fpolymorphic-specialisation flag. Depending upon our experience with 9.14.1, we may enable this feature by default in a later minor release.

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 comprises this release.

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

]]>
Fri, 19 Dec 2025 00:00:00 UThttp://haskell.org/ghc/blog/20251219-ghc-9.14.1-released.htmlghc-devs
Aquileo | GHC 9.12.3-rc3 is now availablehttp://haskell.org/ghc/blog/20251211-ghc-9.12.3-rc3-released.html GHC 9.12.3-rc3 is now available

wz1000 - 2025-12-11

The GHC developers are very pleased to announce the availability of the third release candidate for GHC 9.12.3. Binary distributions, source distributions, and documentation are available at downloads.haskell.org and via GHCup.

GHC 9.12.3 is a bug-fix release fixing several issues of a variety of severities and scopes. 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 22 December 2025.

The changes from the first release candidate are

  • Fix use after free on windows due to a linker optimisation introduced in an earlier RC (#26613)
  • A fix for a bug in the configure script which result in the LLVM toolchain not being detected in certain situations (#26564)
  • Fixes for the WASM backend

GHC development is sponsored by:

We would like to that 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.

]]>
Thu, 11 Dec 2025 00:00:00 UThttp://haskell.org/ghc/blog/20251211-ghc-9.12.3-rc3-released.htmlghc-devs
Aquileo | GHC 9.14.1-rc3 is now availablehttp://haskell.org/ghc/blog/20251201-ghc-9.14.1-rc3-released.html GHC 9.14.1-rc3 is now available

zubin - 2025-12-01

The GHC developers are very pleased to announce the availability of the third release candidate of GHC 9.14.1. Binary distributions, source distributions, and documentation are available at downloads.haskell.org.

The changes from the second release candidate are:

  • Fix RTS segfaults in certain situations (#26495)
  • Fix use after free on windows due to a linker optimisation introduced in an earlier RC (#26613)

GHC 9.14 will bring a number of new features and improvements, including:

  • Significant improvements in specialisation:

    • The SPECIALISE pragma now allows use of type application syntax
    • The SPECIALISE pragma can be used to specialise for expression arguments as well as type arguments.
    • Specialisation is now considerably more reliable in the presence of newtypes
  • Significant GHCi improvements including:

    • Correctness and performance improvements in the bytecode interpreter
    • Features in the GHCi debugger
    • Support for multiple home units in GHCi
  • Implementation of the Explicit Level Imports proposal

  • RequiredTypeArguments can now be used in more contexts

  • SSE/AVX2 support in the x86 native code generator backend

  • A major update of the Windows toolchain and improved compatibility with macOS Tahoe

  • … and many more

A full accounting of changes can be found in the release notes. Given the many specialisation improvements and their potential for regression, we would very much appreciate testing and performance characterisation on downstream workloads.

Note that while this release makes many improvements in the specialisation optimisation, polymorphic specialisation will remain disabled by default in the final release due to concern over regressions of the sort identified in #26329. Users needing more aggressive specialisation can explicitly enable this feature with the -fpolymorphic-specialisation flag. Depending upon our experience with 9.14.1, we may enable this feature by default in a later minor release.

GHC development is sponsored by:

We would like to that 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.

]]>
Mon, 01 Dec 2025 00:00:00 UThttp://haskell.org/ghc/blog/20251201-ghc-9.14.1-rc3-released.htmlghc-devs
Aquileo | GHC 9.12.3-rc2 is now availablehttp://haskell.org/ghc/blog/20251111-ghc-9.12.3-rc2-released.html GHC 9.12.3-rc2 is now available

wz1000 - 2025-11-11

The GHC developers are very pleased to announce the availability of the second release candidate for GHC 9.12.3. Binary distributions, source distributions, and documentation are available at downloads.haskell.org and via GHCup.

GHC 9.12.3 is a bug-fix release fixing several issues of a variety of severities and scopes. 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 24 November 2025.

The changes from the first release candidate are

  • Fix a regression resulting in a panic with empty cases (#26442, #25960).
  • Fix for a potential segfault in the bytecode interpreter (#23210).
  • Fix for a regression with tabs not being allowed in string gaps (#26415).
  • Fix for a crash with the non-moving GC (#26204).
  • A rework of how internal symbols used by the code-generator are handled to adapt to changes in the Apple toolchain, enabling this release to bootstrap on macOS 26 Tahoe (#26166).

GHC development is sponsored by:

We would like to that 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.

]]>
Tue, 11 Nov 2025 00:00:00 UThttp://haskell.org/ghc/blog/20251111-ghc-9.12.3-rc2-released.htmlghc-devs
Aquileo | GHC 9.14.1-rc2 is now availablehttp://haskell.org/ghc/blog/20251104-ghc-9.14.1-rc2-released.html GHC 9.14.1-rc2 is now available

zubin - 2025-11-04

The GHC developers are very pleased to announce the availability of the second release candidate of GHC 9.14.1. Binary distributions, source distributions, and documentation are available at downloads.haskell.org.

The changes from the first release candidate are:

  • Bump the exceptions submodule to 0.10.11
  • Bump the os-string submodule to 2.0.8
  • Fix a driver regression causing an infinite loop with cyclic imports

GHC 9.14 will bring a number of new features and improvements, including:

  • Significant improvements in specialisation:

    • The SPECIALISE pragma now allows use of type application syntax
    • The SPECIALISE pragma can be used to specialise for expression arguments as well as type arguments.
    • Specialisation is now considerably more reliable in the presence of newtypes
  • Significant GHCi improvements including:

    • Correctness and performance improvements in the bytecode interpreter
    • Features in the GHCi debugger
    • Support for multiple home units in GHCi
  • Implementation of the Explicit Level Imports proposal

  • RequiredTypeArguments can now be used in more contexts

  • SSE/AVX2 support in the x86 native code generator backend

  • A major update of the Windows toolchain and improved compatibility with macOS Tahoe

  • … and many more

A full accounting of changes can be found in the release notes. Given the many specialisation improvements and their potential for regression, we would very much appreciate testing and performance characterisation on downstream workloads.

Note that while this release makes many improvements in the specialisation optimisation, polymorphic specialisation will remain disabled by default in the final release due to concern over regressions of the sort identified in #26329. Users needing more aggressive specialisation can explicitly enable this feature with the -fpolymorphic-specialisation flag. Depending upon our experience with 9.14.1, we may enable this feature by default in a later minor release.

We would like to thank the Zw3rk stake pool, Well-Typed, Mercury, Channable, Tweag I/O, Serokell, 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 have made the Haskell ecosystem what it is today.

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

]]>
Tue, 04 Nov 2025 00:00:00 UThttp://haskell.org/ghc/blog/20251104-ghc-9.14.1-rc2-released.htmlghc-devs
Aquileo | GHC 9.14.1-rc1 is now availablehttp://haskell.org/ghc/blog/20251030-ghc-9.14.1-rc1-released.html GHC 9.14.1-rc1 is now available

bgamari - 2025-10-30

The GHC developers are very pleased to announce the availability of the release candidate of GHC 9.14.1. Binary distributions, source distributions, and documentation are available at downloads.haskell.org.

GHC 9.14 will bring a number of new features and improvements, including:

  • Significant improvements in specialisation:

    • The SPECIALISE pragma now allows use of type application syntax
    • The SPECIALISE pragma can be used to specialise for expression arguments as well as type arguments.
    • Specialisation is now considerably more reliable in the presence of newtypes
  • Significant GHCi improvements including:

    • Correctness and performance improvements in the bytecode interpreter
    • Features in the GHCi debugger
    • Support for multiple home units in GHCi
  • Implementation of the Explicit Level Imports proposal

  • RequiredTypeArguments can now be used in more contexts

  • SSE/AVX2 support in the x86 native code generator backend

  • A major update of the Windows toolchain and improved compatibility with macOS Tahoe

  • … and many more

A full accounting of changes can be found in the release notes. Given the many specialisation improvements and their potential for regression, we would very much appreciate testing and performance characterisation on downstream workloads.

Note that while this release makes many improvements in the specialisation optimisation, polymorphic specialisation will remain disabled by default in the final release due to concern over regressions of the sort identified in #26329. Users needing more aggressive specialisation can explicitly enable this feature with the -fpolymorphic-specialisation flag. Depending upon our experience with 9.14.1, we may enable this feature by default in a later minor release.

This is the first and hopefully last release candidate prerelease of 9.14.1. This comes later than expected in part due to work on resolving a regression in macOS 26 (#26166) which threatened the usability of the release. This prerelease includes a fix to this regression; naturally, please open a ticket if you encounter any trouble when using this release on macOS Tahoe or recent XCode releases. We expect that this fix will be backported to GHC 9.12 and 9.10 in the coming months.

We would like to thank the Zw3rk stake pool, Well-Typed, Mercury, Channable, Tweag I/O, Serokell, 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 have made the Haskell ecosystem what it is today.

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

]]>
Thu, 30 Oct 2025 00:00:00 UThttp://haskell.org/ghc/blog/20251030-ghc-9.14.1-rc1-released.htmlghc-devs
Aquileo | GHC 9.14.1-alpha3 is now availablehttp://haskell.org/ghc/blog/20251007-ghc-9.14.1-alpha3-released.html GHC 9.14.1-alpha3 is now available

bgamari - 2025-10-09

The GHC developers are very pleased to announce the availability of the third alpha release of GHC 9.14.1. Binary distributions, source distributions, and documentation are available at downloads.haskell.org.

GHC 9.14 will bring a number of new features and improvements, including:

  • Significant improvements in specialisation:

    • The SPECIALISE pragma now allows use of type application syntax
    • The SPECIALISE pragma can be used to specialise for expression arguments as well as type arguments.
    • Specialisation is now considerably more reliable in the presence of newtypes
  • Significant improvements GHCi including:

    • Correctness and performance improvements in the bytecode interpreter
    • Features in the GHCi debugger
    • Support for multiple home units in GHCi
  • Implementation of the Explicit Level Imports proposal

  • RequiredTypeArgments can now be used in more contexts

  • SSE/AVX2 support in the x86 native code generator backend

  • A major update of the Windows toolchain

  • … and many more

A full accounting of changes can be found in the release notes. Given the many specialisation improvements and their potential for regression, we would very much appreciate testing and performance characterisation on downstream workloads.

Note that while this release makes many improvements in the specialisation optimisation, polymorphic specialisation will remain disabled by default in the final release due to concern over regressions of the sort identified in #26329. Users needing more aggressive specialisation can explicitly enable this feature with the -fpolymorphic-specialisation flag. Depending upon our experience with 9.14.1, we may enable this feature by default in a later minor release.

This is the third alpha release of 9.14.1. This comes later than expected in part due to work on a resolving a regression in the macOS 26 (#26166) which threatened the usability of the release. While a complete fix for this issue is not present in this alpha, we have done enough work to have confidence that it will be in finished for the release candidate which we expect should come the week of 27 October.

We would like to thank the Zw3rk stake pool, Well-Typed, Mercury, Channable, Tweag I/O, Serokell, 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 have made the Haskell ecosystem what it is today.

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

]]>
Thu, 09 Oct 2025 00:00:00 UThttp://haskell.org/ghc/blog/20251007-ghc-9.14.1-alpha3-released.htmlghc-devs
Aquileo | GHC 9.12.3-rc1 is now availablehttp://haskell.org/ghc/blog/20250922-ghc-9.12.3-rc1-released.html GHC 9.12.3-rc1 is now available

wz1000 - 2025-09-22

The GHC developers are very pleased to announce the availability of the release candidate for GHC 9.12.3. Binary distributions, source distributions, and documentation are available at downloads.haskell.org and via GHCup.

GHC 9.12.3 is a bug-fix release fixing several issues of a variety of severities and scopes. 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 2 October 2025.

We would like to thank Well-Typed, Tweag I/O, Juspay, QBayLogic, Channable, Serokell, 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.

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

]]>
Mon, 22 Sep 2025 00:00:00 UThttp://haskell.org/ghc/blog/20250922-ghc-9.12.3-rc1-released.htmlghc-devs
Aquileo | GHC 9.14.1-alpha2 is now availablehttp://haskell.org/ghc/blog/20250912-ghc-9.14.1-alpha2-released.html GHC 9.14.1-alpha2 is now available

bgamari - 2025-09-12

The GHC developers are very pleased to announce the availability of the second alpha prerelease of GHC 9.14.1. Binary distributions, source distributions, and documentation are available at downloads.haskell.org.

GHC 9.14 will bring a number of new features and improvements, including:

  • Significant improvements in specialisation:

    • The SPECIALISE pragma now allows use of type application syntax

    • The SPECIALISE pragma can be used to specialise for expression arguments as well as type arguments.

    • Specialisation is now considerably more reliable in the presence of newtypes

  • Significant improvements in the GHCi debugger

  • Record fields can be defined to be non-linear when LinearTypes is enabled.

  • RequiredTypeArgments can now be used in more contexts

  • SSE/AVX2 support in the x86 native code generator backend

  • A major update of the Windows toolchain

  • … and many more

A full accounting of changes can be found in the release notes. Given the many specialisation improvements and their potential for regression, we would very much appreciate testing and performance characterisation on downstream workloads.

Observant readers of these prerelease announcements will note that polymorphic specialisation has been dropped from alpha 2. This measure was taken out of an abundance of caution after finding a miscompilation during testing of alpha 1. While this bug will be fixed in the next alpha, we expect to keep polymorphic specialisation disabled by default in the final release. Users needing more aggressive specialisation can explicitly enable this feature with the -fpolymorphic-specialisation flag. Depending upon our experience with 9.14.1, we may enable this feature by default in a later minor release.

This is the second of three expected alpha prereleases. We expect the next (third) alpha will come 23 Sept. 2025, with the release candidate coming 7 Oct. 2025.

We would like to thank the Zw3rk stake pool, Well-Typed, Mercury, Channable, Tweag I/O, Serokell, 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 have made the Haskell ecosystem what it is today.

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

]]>
Fri, 12 Sep 2025 00:00:00 UThttp://haskell.org/ghc/blog/20250912-ghc-9.14.1-alpha2-released.htmlghc-devs
Aquileo | GHC 9.10.3 is now availablehttp://haskell.org/ghc/blog/20250910-ghc-9.10.3-released.html GHC 9.10.3 is now available

Zubin Duggal - 2025-09-10

The GHC developers are very pleased to announce the availability of the final release for GHC 9.10.3. Binary distributions, source distributions, and documentation are available at downloads.haskell.org and via GHCup.

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

  • Fix a number of crashes in the compiler frontend (#25960, #25004, #25056)
  • Fix incorrect results in the NCG (#25601, #26061)
  • Support for far jumps in the AArch64 NCG (#24648)
  • A fix for a segfault in the RTS when running certain code involving STM (#26205)
  • And many more!

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.

We would like to thank Well-Typed, Tweag I/O, Juspay, QBayLogic, Channable, Serokell, 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.

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

]]>
Wed, 10 Sep 2025 00:00:00 UThttp://haskell.org/ghc/blog/20250910-ghc-9.10.3-released.htmlghc-devs
Aquileo | GHC 9.14.1-alpha1 is now availablehttp://haskell.org/ghc/blog/20250819-ghc-9.14.1-alpha1-released.html GHC 9.14.1-alpha1 is now available

bgamari - 2025-08-19

The GHC developers are very pleased to announce the availability of the first alpha prerelease of GHC 9.14.1. Binary distributions, source distributions, and documentation are available at downloads.haskell.org.

GHC 9.14 will bring a number of new features and improvements, including:

  • Significant improvements in specialisation:

    • The SPECIALISE pragma now allows use of type application syntax

    • The SPECIALISE pragma can be used to specialise for expression arguments as well as type arguments.

    • Specialisation is now considerably more reliable in the presence of newtypes

    • the specialiser is now able to produce specialisations with polymorphic typeclass constraints, considerably broadening its scope.

  • Significant improvements in the GHCi debugger

  • Record fields can be defined to be non-linear when LinearTypes is enabled.

  • RequiredTypeArgments can now be used in more contexts

  • SSE/AVX support in the x86 native code generator backend

  • A major update of the Windows toolchain

  • … and many more

A full accounting of changes can be found in the release notes. Given the many specialisation improvements and their potential for regression, we would very much appreciate testing and performance characterisation on downstream workloads.

Due to unexpected complications, this initial prerelease comes a bit later than expected. Consequently, we expect to have three condensed alphas prior to the release candidate, in contrast to the scheduled three. We expect the next alpha will come the week of 9 Sept. 2025, while the third will come 23 Sept. 2025, with the release candidate coming 7 Oct. 2025.

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

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

]]>
Tue, 19 Aug 2025 00:00:00 UThttp://haskell.org/ghc/blog/20250819-ghc-9.14.1-alpha1-released.htmlghc-devs
Aquileo | GHC 9.10.3-rc4 is now availablehttp://haskell.org/ghc/blog/20250818-ghc-9.10.4-rc4-released.html GHC 9.10.3-rc4 is now available

wz1000 - 2025-08-18

The GHC developers are very pleased to announce the availability of the fourth release candidate for GHC 9.10.3. Binary distributions, source distributions, and documentation are available at downloads.haskell.org and via GHCup.

GHC 9.10.3 is a bug-fix release fixing over 50 issues of a variety of severities and scopes. 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.

The changes from the first release candidate are:

  • A fix for a rare segfault with code involving STM (#26205)
  • A fix for the naturalAndNot returning bogus results (#26205)
  • A fix for a crash in the renamer (#25056)

This release candidate will have a two-week testing period. If all goes well the final release will be available the week of 1 September 2025.

We would like to thank Well-Typed, Tweag I/O, Juspay, QBayLogic, Channable, Serokell, 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.

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

]]>
Mon, 18 Aug 2025 00:00:00 UThttp://haskell.org/ghc/blog/20250818-ghc-9.10.4-rc4-released.htmlghc-devs
Aquileo | GHC 9.10.3-rc3 is now availablehttp://haskell.org/ghc/blog/20250808-ghc-9.10.3-rc3-released.html GHC 9.10.3-rc3 is now available

wz1000 - 2025-08-08

The GHC developers are very pleased to announce the availability of the third release candidate for GHC 9.10.3. Binary distributions, source distributions, and documentation are available at downloads.haskell.org and via GHCup.

GHC 9.10.3 is a bug-fix release fixing over 50 issues of a variety of severities and scopes. 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.

The changes from the second release candidate are:

  • Reverting a change the exports of the Backtrace constructor in the base library that was backported due to confusion on CLC approvals (!14587)
  • Reverting a change to the configure script (!14324) that dropped probing for ld.gold

This release candidate will have a two-week testing period. If all goes well the final release will be available the week of 22 August 2025.

We would like to thank Well-Typed, Tweag I/O, Juspay, QBayLogic, Channable, Serokell, 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.

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

]]>
Fri, 08 Aug 2025 00:00:00 UThttp://haskell.org/ghc/blog/20250808-ghc-9.10.3-rc3-released.htmlghc-devs
Aquileo | GHC 9.10.3-rc2 is now availablehttp://haskell.org/ghc/blog/20250806-ghc-9.10.3-rc2-released.html GHC 9.10.3-rc2 is now available

wz1000 - 2025-08-06

The GHC developers are very pleased to announce the availability of the second release candidate for GHC 9.10.3. Binary distributions, source distributions, and documentation are available at downloads.haskell.org and via GHCup.

GHC 9.10.3 is a bug-fix release fixing over 50 issues of a variety of severities and scopes. 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.

The changes from the first release candidate are:

  • Bumping the text submodule to 2.1.3
  • Reverting a bug fix (!14291) that restricted previously allowed namespace specifiers (#26250)
  • Reverting the bump of the deepseq submodule to 1.5.2.0 (#26251)

This release candidate will have a two-week testing period. If all goes well the final release will be available the week of 19 August 2025.

We would like to thank Well-Typed, Tweag I/O, Juspay, QBayLogic, Channable, Serokell, 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.

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

]]>
Wed, 06 Aug 2025 00:00:00 UThttp://haskell.org/ghc/blog/20250806-ghc-9.10.3-rc2-released.htmlghc-devs
Aquileo | GHC 9.10.3-rc1 is now availablehttp://haskell.org/ghc/blog/20250728-ghc-9.10.3-rc1-released.html GHC 9.10.3-rc1 is now available

wz1000 - 2025-07-28

The GHC developers are very pleased to announce the availability of the release candidate for GHC 9.10.3. Binary distributions, source distributions, and documentation are available at downloads.haskell.org and via GHCup.

GHC 9.10.3 is a bug-fix release fixing over 50 issues of a variety of severities and scopes. 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 11 August 2025.

We would like to thank Well-Typed, Tweag I/O, Juspay, QBayLogic, Channable, Serokell, 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.

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

]]>
Mon, 28 Jul 2025 00:00:00 UThttp://haskell.org/ghc/blog/20250728-ghc-9.10.3-rc1-released.htmlghc-devs
Aquileo | GHC LTS Releaseshttp://haskell.org/ghc/blog/20250702-ghc-release-schedules.html GHC LTS Releases

Andreas Klebinger - 2025-07-07

GHC will start maintaining an LTS release/branch in the near future

A release being designated LTS (Long Term Support) in this case means we plan to support it over a longer timeframe than usual.

Concretely the plan is to provide updates for a LTS releases for at least two years. Most likely we will support LTS releases for even longer than that, aiming for a support window of three years currently.

During this time we will be providing minor releases fixing bugs as with any other release. The main difference being that we will do so for a longer period of time.

There are no plans to backport any new features to LTS releases after their initial release.

In terms of frequency of LTS releases we plan to have an overlap between LTS support windows of different LTS series of six months.

A potential timeline might then look like this:

2025 Aug    - LTS 9.14 released
2028 Spring - LTS 9.22 released
2028 Summer - LTS 9.14.X - last 9.14 point release
2031 Spring  - LTS 9.X released
2031 Summer - Last 9.22 point release
...

Non-LTS releases

GHC will continue to release new major non-lts releases on a ~6 Month cadence. We expect to cut back on the lifetime of these releases slightly, dedicating the resources freed up this way to enable a longer support window for the LTS releases.

Why LTS releases?

In practice some releases always saw more adoption than others by users. The GHC Team has not been blind to this fact and has at times informally extended the life of a certain release based on this as well.

This resulted in a sort of informal “post-hoc LTS” status of releases. At times with support windows not much shorter than our proposed minimum of two years.

This worked reasonable well for people who were confident to stay on a fairly old release, only upgrading to a newer “post-hoc LTS” once the dust settled. It also worked out for those who picked one of those “post-hoc LTS” releases by happenstance before it was clear the release would end up as “post-hoc LTS”.

However users who adopted major releases which did not end up as “post-hoc LTS” often had to choose between upgrading earlier than expected, or risk running into a show stopping bug after the support window of the release had already ended. Similarly much of this was based on informal community sentiment and rarely written down explicitly. Making this information hard to access for members not deeply involved in the day to day of the haskell community.

By designating a major release as LTS ahead of time we hope that users can make a informed decision about which GHC version they pick. Making it clear what the tradeoffs will be. With a clear choice between a longer support window or the newest features.

Why not make post-hoc LTS releases official instead?

This is a question that has come up a lot in discussion. The major downsides of this are a lack of predictability, and that a lot of time might be lost between the initial release and any such decision. If we declare a release as LTS 9 months after its .1 release we essentially shaved off months from the LTS support window.

On the flip side if we announce it ahead of time everyone knows that a given release will be the new LTS. So the hope is that this encourages more and quicker support for the release by the community. Hopefully compressing the timeline of bug fixing, testing and eventual widespread adoption.

Overall I’m hopeful that LTS releases being explicit will remove a lot of ambiguity around GHC versions. And while the guaranteed LTS support window might not be as long as one might hope having LTS releases with longer guaranteed support window should still be helpful to people working on long running haskell projects.

Next steps

The first LTS release will be GHC 9.14, which will be released this summer!

]]>
Mon, 07 Jul 2025 00:00:00 UThttp://haskell.org/ghc/blog/20250702-ghc-release-schedules.htmlghc-devs
Aquileo | GHC 9.10.2 is now availablehttp://haskell.org/ghc/blog/20250503-ghc-9.10.2-released.html GHC 9.10.2 is now available

Zubin Duggal - 2025-05-03

The GHC developers are very pleased to announce the availability of the final release for GHC 9.10.2. Binary distributions, source distributions, and documentation are available at downloads.haskell.org and via GHCup.

GHC 9.10.2 is a bug-fix release fixing over 50 issues of a variety of severities and scopes, including:

  • Significantly improved performance when dynamically loading Haskell symbols (#23415).
  • Fixing a bug where the simplifier sometimes destroyed join points during float out, which could impact performance (#24768).
  • Reduced memory fragmentation in the non-moving GC’s segment allocator, improving resident set size by up to 26% for some applications (#24150).
  • Added new flags to control speculative evaluation (-fspec-eval and -fspec-eval-dictfun) to work around performance regressions (#25606).
  • Fixed several platform-specific issues, including segfaults with FFI on PowerPC (#23034) and improved code generation for AArch64 with multiway branches now using jump tables (#19912)
  • And many more!

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.

We would like to thank Well-Typed, Tweag I/O, Juspay, QBayLogic, Channable, Serokell, 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.

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

]]>
Sat, 03 May 2025 00:00:00 UThttp://haskell.org/ghc/blog/20250503-ghc-9.10.2-released.htmlghc-devs
Aquileo | GHC 9.10.2-rc1 is now availablehttp://haskell.org/ghc/blog/20250418-ghc-9.10.2-rc1-released.html GHC 9.10.2-rc1 is now available

bgamari - 2025-04-18

The GHC developers are very pleased to announce the availability of the release candidate for GHC 9.10.2. Binary distributions, source distributions, and documentation are available at downloads.haskell.org and via GHCup.

GHC 9.10.2 is a bug-fix release fixing over 50 issues of a variety of severities and scopes. 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 1 May 2025.

We would like to thank Well-Typed, Tweag I/O, Juspay, QBayLogic, Channable, Serokell, 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.

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

]]>
Fri, 18 Apr 2025 00:00:00 UThttp://haskell.org/ghc/blog/20250418-ghc-9.10.2-rc1-released.htmlghc-devs
Aquileo | GHC 9.6.7 is now availablehttp://haskell.org/ghc/blog/20250324-ghc-9.6.7-released.html GHC 9.6.7 is now available

Luite Stegeman - 2025-03-24

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

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.

~ Luite

]]>
Mon, 24 Mar 2025 00:00:00 UThttp://haskell.org/ghc/blog/20250324-ghc-9.6.7-released.htmlghc-devs
Aquileo | GHC 9.12.2 is now availablehttp://haskell.org/ghc/blog/20250314-ghc-9.12.2-released.html GHC 9.12.2 is now available

Ben Gamari - 2025-03-14

The GHC developers are happy to announce the release of GHC 9.12.2. Binary distributions, source distributions, and documentation are available at downloads.haskell.org.

We hope to have this release available via ghcup shortly. This is a small release fixing a critical code generation bug, #25653, affecting some subword division operations.

As always, GHC’s release status, including planned future releases, can be found on the GHC Wiki status.

We would like to thank 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 who contribute their code, tickets, and energy to the GHC project.

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

]]>
Fri, 14 Mar 2025 00:00:00 UThttp://haskell.org/ghc/blog/20250314-ghc-9.12.2-released.htmlghc-devs
Aquileo | GHC 9.12.2-rc1 is now availablehttp://haskell.org/ghc/blog/20240225-ghc-9.12.2-rc1-released.html GHC 9.12.2-rc1 is now available

Ben Gamari - 2025-02-26

The GHC developers are happy to announce the availability of the first and likely final release candidate of GHC 9.12.2. This is an important bug-fix release resolving a significant correctness issue present in 9.12.1 (#25653).

In accordance with our under-discussion release policies this candidate will have a two-week testing window. The final 9.12.2 release will likely come the week of 12 March 2025.

As always, if you find anything amiss please open a ticket.

Happy Haskelling!

  • Ben
]]>
Wed, 26 Feb 2025 00:00:00 UThttp://haskell.org/ghc/blog/20240225-ghc-9.12.2-rc1-released.htmlghc-devs
Aquileo | GHC 9.12.1 is now availablehttp://haskell.org/ghc/blog/20241216-ghc-9.12.1-released.html GHC 9.12.1 is now available

Zubin Duggal - 2024-12-16

The GHC developers are very pleased to announce the release of GHC 9.12.1. Binary distributions, source distributions, and documentation are available at downloads.haskell.org.

We hope to have this release available via ghcup shortly.

GHC 9.12 will bring a number of new features and improvements, including:

  • The new language extension OrPatterns allowing you to combine multiple pattern clauses into one.

  • The MultilineStrings language extension to allow you to more easily write strings spanning multiple lines in your source code.

  • Improvements to the OverloadedRecordDot extension, allowing the built-in HasField class to be used for records with fields of non lifted representations.

  • The NamedDefaults language extension has been introduced allowing you to define defaults for typeclasses other than Num.

  • More deterministic object code output, controlled by the -fobject-determinism flag, which improves determinism of builds a lot (though does not fully do so) at the cost of some compiler performance (1-2%). See #12935 for the details

  • GHC now accepts type syntax in expressions as part of GHC Proposal #281.

  • The WASM backend now has support for TemplateHaskell.

  • Experimental support for the RISC-V platform with the native code generator.

  • … and many more

A full accounting of changes 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.

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.

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

]]>
Mon, 16 Dec 2024 00:00:00 UThttp://haskell.org/ghc/blog/20241216-ghc-9.12.1-released.htmlghc-devs
Aquileo | GHC 9.8.4 is now availablehttp://haskell.org/ghc/blog/20241202-ghc-9.8.4-released.html GHC 9.8.4 is now available

Ben Gamari - 2024-12-02

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

This release is a small release fixing a few issues noted in 9.8.3, including:

  • Update the filepath submodule to avoid a misbehavior of splitFileName under Windows.

  • Update the unix submodule to fix a compilation issue on musl platforms

  • Fix a potential source of miscompilation when building large projects on 32-bit platforms

  • Fix unsound optimisation of prompt# uses

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

  • Ben
]]>
Mon, 02 Dec 2024 00:00:00 UThttp://haskell.org/ghc/blog/20241202-ghc-9.8.4-released.htmlghc-devs
Aquileo | GHC 9.12.1-rc1 is now availablehttp://haskell.org/ghc/blog/20241129-ghc-9.12.1-rc1-released.html GHC 9.12.1-rc1 is now available

Zubin Duggal - 2024-11-29

The GHC developers are very pleased to announce the availability of the release candidate for GHC 9.12.1. Binary distributions, source distributions, and documentation are available at downloads.haskell.org.

We hope to have this release available via ghcup shortly.

GHC 9.12 will bring a number of new features and improvements, including:

  • The new language extension OrPatterns allowing you to combine multiple pattern clauses into one.

  • The MultilineStrings language extension to allow you to more easily write strings spanning multiple lines in your source code.

  • Improvements to the OverloadedRecordDot extension, allowing the built-in HasField class to be used for records with fields of non lifted representations.

  • The NamedDefaults language extension has been introduced allowing you to define defaults for typeclasses other than Num.

  • More deterministic object code output, controlled by the -fobject-determinism flag, which improves determinism of builds a lot (though does not fully do so) at the cost of some compiler performance (1-2%). See #12935 for the details

  • GHC now accepts type syntax in expressions as part of GHC Proposal #281.

  • The WASM backend now has support for TemplateHaskell.

  • … and many more

A full accounting of changes 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.

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.

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

]]>
Fri, 29 Nov 2024 00:00:00 UThttp://haskell.org/ghc/blog/20241129-ghc-9.12.1-rc1-released.htmlghc-devs
Aquileo | GHC 9.12.1-alpha3 is now availablehttp://haskell.org/ghc/blog/20241114-ghc-9.12.1-alpha3-released.html GHC 9.12.1-alpha3 is now available

Zubin Duggal - 2024-11-14

The GHC developers are very pleased to announce the availability of the third alpha release of GHC 9.12.1. Binary distributions, source distributions, and documentation are available at downloads.haskell.org.

We hope to have this release available via ghcup shortly.

GHC 9.12 will bring a number of new features and improvements, including:

  • The new language extension OrPatterns allowing you to combine multiple pattern clauses into one.

  • The MultilineStrings language extension to allow you to more easily write strings spanning multiple lines in your source code.

  • Improvements to the OverloadedRecordDot extension, allowing the built-in HasField class to be used for records with fields of non lifted representations.

  • The NamedDefaults language extension has been introduced allowing you to define defaults for typeclasses other than Num.

  • More deterministic object code output, controlled by the -fobject-determinism flag, which improves determinism of builds a lot (though does not fully do so) at the cost of some compiler performance (1-2%). See #12935 for the details

  • GHC now accepts type syntax in expressions as part of GHC Proposal #281.

  • The WASM backend now has support for TemplateHaskell.

  • … and many more

A full accounting of changes 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.

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.

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

]]>
Thu, 14 Nov 2024 00:00:00 UThttp://haskell.org/ghc/blog/20241114-ghc-9.12.1-alpha3-released.htmlghc-devs
Aquileo | GHC 9.12.1-alpha2 is now availablehttp://haskell.org/ghc/blog/20241105-ghc-9.12.1-alpha2-released.html GHC 9.12.1-alpha2 is now available

Zubin Duggal - 2024-11-05

The GHC developers are very pleased to announce the availability of the second alpha release of GHC 9.12.1. Binary distributions, source distributions, and documentation are available at downloads.haskell.org.

We hope to have this release available via ghcup shortly.

GHC 9.12 will bring a number of new features and improvements, including:

  • The new language extension OrPatterns allowing you to combine multiple pattern clauses into one.

  • The MultilineStrings language extension to allow you to more easily write strings spanning multiple lines in your source code.

  • Improvements to the OverloadedRecordDot extension, allowing the built-in HasField class to be used for records with fields of non lifted representations.

  • The NamedDefaults language extension has been introduced allowing you to define defaults for typeclasses other than Num.

  • More deterministic object code output, controlled by the -fobject-determinism flag, which improves determinism of builds a lot (though does not fully do so) at the cost of some compiler performance (1-2%). See #12935 for the details

  • GHC now accepts type syntax in expressions as part of GHC Proposal #281.

  • The WASM backend now has support for TemplateHaskell.

  • … and many more

A full accounting of changes 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.

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.

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

]]>
Tue, 05 Nov 2024 00:00:00 UThttp://haskell.org/ghc/blog/20241105-ghc-9.12.1-alpha2-released.htmlghc-devs
Aquileo | GHC 9.8.3 is now availablehttp://haskell.org/ghc/blog/20241020-ghc-9.8.3-released.html GHC 9.8.3 is now available

Ben Gamari - 2024-10-20

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

This release is primarily a bugfix release in the 9.8 series. These include:

  • Significantly improve performance of code loading via dynamic linking (#23415)
  • Fix a variety of miscompilations involving sub-word-size FFI arguments (#25018, #24314)
  • Fix a rare miscompilation by the x86 native code generator (#24507)
  • Improve runtime performance of some applications of runRW# (#25055)
  • Reduce fragmentation when using the non-moving garbage collector (#23340)
  • Fix source links in Haddock’s hyperlinked sources output (#24086)

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

  • Ben
]]>
Sun, 20 Oct 2024 00:00:00 UThttp://haskell.org/ghc/blog/20241020-ghc-9.8.3-released.htmlghc-devs
Aquileo | GHC 9.12.1-alpha1 is now availablehttp://haskell.org/ghc/blog/20241016-ghc-9.12.1-alpha1-released.html GHC 9.12.1-alpha1 is now available

Zubin Duggal - 2024-10-16

The GHC developers are very pleased to announce the availability of the first alpha release of GHC 9.12.1. Binary distributions, source distributions, and documentation are available at downloads.haskell.org.

We hope to have this release available via ghcup shortly.

GHC 9.12 will bring a number of new features and improvements, including:

  • The new language extension OrPatterns allowing you to combine multiple pattern clauses into one.

  • The MultilineStrings language extension to allow you to more easily write strings spanning multiple lines in your source code.

  • Improvements to the OverloadedRecordDot extension, allowing the built-in HasField class to be used for records with fields of non lifted representations.

  • The NamedDefaults language extension has been introduced allowing you to define defaults for typeclasses other than Num.

  • More deterministic object code output, controlled by the -fobject-determinism flag, which improves determinism of builds a lot (though does not fully do so) at the cost of some compiler performance (1-2%). See #12935 for the details

  • GHC now accepts type syntax in expressions as part of GHC Proposal #281.

  • … and many more

A full accounting of changes 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.

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.

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

]]>
Wed, 16 Oct 2024 00:00:00 UThttp://haskell.org/ghc/blog/20241016-ghc-9.12.1-alpha1-released.htmlghc-devs
Aquileo | GHC 9.6.6 is now availablehttp://haskell.org/ghc/blog/20240701-ghc-9.6.6-released.html GHC 9.6.6 is now available

Zubin Duggal - 2024-07-01

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.

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.

Enjoy!

-Zubin

]]>
Mon, 01 Jul 2024 00:00:00 UThttp://haskell.org/ghc/blog/20240701-ghc-9.6.6-released.htmlghc-devs
Aquileo | Deprecation of 32-bit Darwin and Windows platformshttp://haskell.org/ghc/blog/20240613-32-bit-darwin-and-windows-deprecation.html Deprecation of 32-bit Darwin and Windows platforms

Hécate - 2024-06-13

In the continuous effort to reduce the burden on GHC developers, some house cleaning has been done to delete dead code from GHC, and in particular: the code generation and runtime logic used by 32-bit macOS/iOS and Windows.

At the time of writing, binary distributions for 32-bit macOS/iOS and Windows have not been provided by either the GHC release engineering team or GHCup maintainers for years. The relevant code paths are completely untested in GHC CI pipelines.

In 2018, Apple communicated that starting from iOS 11 and macOS 10.15, 32-bit applications support was being phased out. As a result “macOS Mojave would be the last version of macOS to run 32-bit apps. Starting with macOS Catalina, 32-bit apps are no longer compatible with macOS.”

In 2020, Microsoft formally discontinued new 32-bit Windows 10 for OEM distributions, which is in line with its hardware requirements for Windows 11.

The transition period that started three years ago is now reaching its conclusion, and users will see a mention of this in the release notes shipped with GHC 9.12. Rest assured, these changes should not affect most users! Existing support for macOS/iOS on x86_64/aarch64, as well as Windows on x86_64 are not affected. Also, these cleanups will not be backported to ghc-9.10, so the remaining users that wish to target these obsolete platforms still have a relatively new GHC major version to begin with. Moreover, removal of legacy 32-bit Windows support opens the door to better support of ARM64 Windows, significantly reducing GHC maintenance overhead when working on relevant patches.

Should you have any questions about the impact of this process, please contact your operating system vendor and/or contact the GHC development team on the ghc-devs mailing-list.

]]>
Thu, 13 Jun 2024 00:00:00 UThttp://haskell.org/ghc/blog/20240613-32-bit-darwin-and-windows-deprecation.htmlghc-devs
Aquileo | GHC release planshttp://haskell.org/ghc/blog/20240521-ghc-release-priorities.html GHC release plans

Zubin Duggal - 2024-05-21

This post sets out our plans for upcoming releases in the next few months.

Given limited time and resources, we plan to prioritise work on the 9.6, 9.10 and master branches of GHC for the next few months.

9.10

With the release of 9.10.1, we look forward to the broader adoption of this release.

New releases in this series will continue at the usual rate depending on if and when any significant regressions or issues arise.

9.6

9.6.5 seems to be a relatively stable release so far and we plan to prioritise fixes given the relatively higher adoption of this branch. We know of one significant issue (#22210) to do with object merging arising from the interactions between GHC and cabal on certain platforms including Darwin with a brew-provisioned clang toolchain.

The upcoming 9.6.6 release will include a fix for this issue along with others that may arise. The 9.6.6 release is tentatively scheduled for the end of June, to allow for sufficient time following the 9.6.5 release for bugs and issues to be reported and addressed.

9.8

We plan to continue supporting this release series for the near future, but updates to this series might proceed at a slower rate than usual as we prioritise the new release (9.10) and supporting earlier releases with high uptake (9.6).

The next release in this series will likely be scheduled after the 9.6.6 release.

Conclusion

We hope that this clarfies the current state of our release branches. If you have any questions or comments then please be in touch via mailto:ghc-devs@haskell.org.

]]>
Tue, 21 May 2024 00:00:00 UThttp://haskell.org/ghc/blog/20240521-ghc-release-priorities.htmlghc-devs
Aquileo | GHC 9.10.1 is now availablehttp://haskell.org/ghc/blog/20240510-ghc-9.10.1-released.html GHC 9.10.1 is now available

bgamari - 2024-05-10

The GHC developers are very pleased to announce the release of GHC 9.10.1. Binary distributions, source distributions, and documentation are available at downloads.haskell.org and via GHCup.

GHC 9.10 brings a number of new features and improvements, including:

  • The introduction of the GHC2024 language edition, building upon GHC2021 with the addition of a number of widely-used extensions.

  • Partial implementation of the GHC Proposal #281, allowing visible quantification to be used in the types of terms.

  • Extension of LinearTypes to allow linear let and where bindings

  • The implementation of the exception backtrace proposal, allowing the annotation of exceptions with backtraces, as well as other user-defined context

  • Further improvements in the info table provenance mechanism, reducing code size to allow IPE information to be enabled more widely

  • Javascript FFI support in the WebAssembly backend

  • Improvements in the fragmentation characteristics of the low-latency non-moving garbage collector.

  • … and many more

A full accounting of changes 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.

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.

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

]]>
Fri, 10 May 2024 00:00:00 UThttp://haskell.org/ghc/blog/20240510-ghc-9.10.1-released.htmlghc-devs
Aquileo | GHC 9.10.1-rc1 is now availablehttp://haskell.org/ghc/blog/20240427-ghc-9.10.1-rc1-released.html GHC 9.10.1-rc1 is now available

bgamari - 2024-04-27

The GHC developers are very pleased to announce the availability of the release candidate for GHC 9.10.1. Binary distributions, source distributions, and documentation are available at downloads.haskell.org and via GHCup.

GHC 9.10 brings a number of new features and improvements, including:

  • The introduction of the GHC2024 language edition, building upon GHC2021 with the addition of a number of widely-used extensions.

  • Partial implementation of the GHC Proposal #281, allowing visible quantification to be used in the types of terms.

  • Extension of LinearTypes to allow linear let and where bindings

  • The implementation of the exception backtrace proposal, allowing the annotation of exceptions with backtraces, as well as other user-defined context

  • Further improvements in the info table provenance mechanism, reducing code size to allow IPE information to be enabled more widely

  • Javascript FFI support in the WebAssembly backend

  • Improvements in the fragmentation characteristics of the low-latency non-moving garbage collector.

  • … and many more

A full accounting of changes 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 is the penultimate prerelease leading to 9.10.1. In two weeks we plan to publish a release candidate, followed, if all things go well, by the final release a week later.

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.

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

]]>
Sat, 27 Apr 2024 00:00:00 UThttp://haskell.org/ghc/blog/20240427-ghc-9.10.1-rc1-released.htmlghc-devs
Aquileo | GHC 9.6.5 is now availablehttp://haskell.org/ghc/blog/20240416-ghc-9.6.5-released.html GHC 9.6.5 is now available

Zubin Duggal - 2024-04-16

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

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

  • Bumping the bundled process library to 1.6.19.0 to avoid a potential command injection vulnerability on Windows for clients of this library. This isn’t known to affect GHC itself, but allows users who depend on the installed version of the process to avoid the issue.
  • Fixing a bug resulting in the distributed hsc2hs wrapper using flags from the compiler build environment (#24050).
  • Disabling the -fasm-shortcutting optimisation with -O2 as it is known to result in unsoundess and incorrect runtime results in some cases (#24507).
  • Ensuring we take LDFLAGS into account when configuring a linker (#24565).
  • Fixing a bug arising from incorrect parsing of paths containing spaces in the settings file (#24265).
  • And many 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.

Enjoy!

-Zubin

]]>
Tue, 16 Apr 2024 00:00:00 UThttp://haskell.org/ghc/blog/20240416-ghc-9.6.5-released.htmlghc-devs
Aquileo | GHC 9.10.1-alpha3 is now availablehttp://haskell.org/ghc/blog/20240415-ghc-9.10.1-alpha3-released.html GHC 9.10.1-alpha3 is now available

bgamari - 2024-04-15

The GHC developers are very pleased to announce the availability of the third alpha release of GHC 9.10.1. Binary distributions, source distributions, and documentation are available at downloads.haskell.org.

We hope to have this release available via ghcup shortly.

GHC 9.10 will bring a number of new features and improvements, including:

  • The introduction of the GHC2024 language edition, building upon GHC2021 with the addition of a number of widely-used extensions.

  • Partial implementation of the GHC Proposal #281, allowing visible quantification to be used in the types of terms.

  • Extension of LinearTypes to allow linear let and where bindings

  • The implementation of the exception backtrace proposal, allowing the annotation of exceptions with backtraces, as well as other user-defined context

  • Further improvements in the info table provenance mechanism, reducing code size to allow IPE information to be enabled more widely

  • Javascript FFI support in the WebAssembly backend

  • Improvements in the fragmentation characteristics of the low-latency non-moving garbage collector.

  • … and many more

A full accounting of changes 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 alpha is the penultimate prerelease leading to 9.10.1. In two weeks we plan to publish a release candidate, followed, if all things go well, by the final release a week later.

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.

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

]]>
Mon, 15 Apr 2024 00:00:00 UThttp://haskell.org/ghc/blog/20240415-ghc-9.10.1-alpha3-released.htmlghc-devs
Aquileo | GHC 9.10.1-alpha2 is now availablehttp://haskell.org/ghc/blog/20240329-ghc-9.10.1-alpha2-released.html GHC 9.10.1-alpha2 is now available

bgamari - 2024-03-29

The GHC developers are very pleased to announce the availability of the second alpha release of GHC 9.10.1. Binary distributions, source distributions, and documentation are available at downloads.haskell.org.

We hope to have this release available via ghcup shortly.

GHC 9.10 will bring a number of new features and improvements, including:

  • The introduction of the GHC2024 language edition, building upon GHC2021 with the addition of a number of widely-used extensions.

  • Partial implementation of the GHC Proposal #281, allowing visible quantification to be used in the types of terms.

  • Extension of LinearTypes to allow linear let and where bindings

  • The implementation of the exception backtrace proposal, allowing the annotation of exceptions with backtraces, as well as other user-defined context

  • Further improvements in the info table provenance mechanism, reducing code size to allow IPE information to be enabled more widely

  • Javascript FFI support in the WebAssembly backend

  • Improvements in the fragmentation characteristics of the low-latency non-moving garbage collector.

  • … and many more

A full accounting of changes 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.

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.

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

]]>
Fri, 29 Mar 2024 00:00:00 UThttp://haskell.org/ghc/blog/20240329-ghc-9.10.1-alpha2-released.htmlghc-devs
Aquileo | GHC 9.10.1-alpha1 is now availablehttp://haskell.org/ghc/blog/20240313-ghc-9.10.1-alpha1-released.html GHC 9.10.1-alpha1 is now available

bgamari - 2024-03-13

The GHC developers are very pleased to announce the availability of the first alpha release of GHC 9.10.1. Binary distributions, source distributions, and documentation are available at downloads.haskell.org.

We hope to have this release available via ghcup shortly.

GHC 9.10 will bring a number of new features and improvements, including:

  • The introduction of the GHC2024 language edition, building upon GHC2021 with the addition of a number of widely-used extensions.

  • Partial implementation of the GHC Proposal #281, allowing visible quantification to be used in the types of terms.

  • Extension of LinearTypes to allow linear let and where bindings

  • The implementation of the exception backtrace proposal, allowing the annotation of exceptions with backtraces, as well as other user-defined context

  • Further improvements in the info table provenance mechanism, reducing code size to allow IPE information to be enabled more widely

  • Javascript FFI support in the WebAssembly backend

  • Improvements in the fragmentation characteristics of the low-latency non-moving garbage collector.

  • … and many more

A full accounting of changes 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.

Many will notice that this release comes a fair bit later than the previously-announced schedule. While this delay has been attributable to a variety factors, the most recent cause is a set of issues with GHC 9.10’s binary distributions on Windows (#24542). Instead of continuing to hold up the release process while we sort out this situation, we have instead provided this alpha without the usual assortment of Windows binary distributions. We expect to have this resolved by alpha 2; apologies to eager Windows testers for this delay.

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.

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

]]>
Wed, 13 Mar 2024 00:00:00 UThttp://haskell.org/ghc/blog/20240313-ghc-9.10.1-alpha1-released.htmlghc-devs
Aquileo | GHC 9.8.2 is now availablehttp://haskell.org/ghc/blog/20240223-ghc-9.8.2-released.html GHC 9.8.2 is now available

Zubin Duggal - 2024-02-23

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

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

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.

Enjoy!

-Zubin

]]>
Fri, 23 Feb 2024 00:00:00 UThttp://haskell.org/ghc/blog/20240223-ghc-9.8.2-released.htmlghc-devs
Aquileo | GHC 9.6.4 is now availablehttp://haskell.org/ghc/blog/20240109-ghc-9.6.4-released.html GHC 9.6.4 is now available

Zubin Duggal - 2024-01-09

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

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

  • A fix for a bug where certain warnings flags were not recognised (#24071)
  • Fixes for a number of simplifier bugs (#23952, #23862).
  • Fixes for compiler panics with certain package databases involving unusable units and module reexports (#21097, #16996, #11050).
  • A fix for a typechecker crash (#24083).
  • A fix for a code generator bug on AArch64 platforms resulting in invalid conditional jumps (#23746).
  • Fixes for some memory leaks in GHCi (#24107, #24118)
  • And a few other 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.

Enjoy!

-Zubin

]]>
Tue, 09 Jan 2024 00:00:00 UThttp://haskell.org/ghc/blog/20240109-ghc-9.6.4-released.htmlghc-devs
Aquileo | GHC 9.4.8 is now availablehttp://haskell.org/ghc/blog/20231110-ghc-9.4.8-released.html GHC 9.4.8 is now available

Zubin Duggal - 2023-11-10

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

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

  • A fix for a recompilation checking bug where GHC may miss changes in transitive dependencies when deciding to relink a program (#23724).
  • A fix for a code generator bug on AArch64 platforms resulting in invalid conditional jumps (#23746).
  • Support for -split-sections on Windows.
  • Enabling -split-sections for various Linux and Windows binary distributions, enabling GHC to produce smaller binaries on these platforms.
  • And a few other 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.

Enjoy!

-Bryan

]]>
Fri, 10 Nov 2023 00:00:00 UThttp://haskell.org/ghc/blog/20231110-ghc-9.4.8-released.htmlghc-devs
Aquileo | GHC 9.8.1 is now availablehttp://haskell.org/ghc/blog/20231009-ghc-9.8.1-released.html GHC 9.8.1 is now available

bgamari - 2023-10-09

The GHC developers are very pleased to announce the availability of the final release of GHC 9.8.1. Binary distributions, source distributions, and documentation are available at downloads.haskell.org.

GHC 9.8 brings a number of new features and improvements, including:

  • Preliminary support the TypeAbstractions language extension, allowing types to be bound in type declarations TypeAbstractions.

  • Support for the ExtendedLiterals extension, providing syntax for non-word-sized numeric literals in the surface language extended-literals

  • Improved rewrite rule matching behavior, allowing limited matching of higher-order patterns

  • Better support for user-defined warnings by way of the WARNING pragma warnings

  • The introduction of the new GHC.TypeError.Unsatisfiable constraint, allowing more predictable user-defined type errors unsatisfiable

  • Implementation of the export deprecation proposal, allowing module exports to be marked with DEPRECATE pragmas deprecated-exports

  • The addition of build semaphore support for parallel compilation; with coming support in cabal-install this will allow better use of parallelism in multi-package builds jsem

  • More efficient representation of info table provenance information, reducing binary sizes by over 50% in some cases when -finfo-table-map is in use

A full accounting of changes can be found in the release notes. Plans for GHC’s future releases can be found on the GHC Wiki.

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.

Happy compiling,

Ben

]]>
Mon, 09 Oct 2023 00:00:00 UThttp://haskell.org/ghc/blog/20231009-ghc-9.8.1-released.htmlghc-devs
Aquileo | GHC 9.8.1-rc1 is now availablehttp://haskell.org/ghc/blog/20230929-ghc-9.8.1-rc1-released.html GHC 9.8.1-rc1 is now available

bgamari - 2023-09-29

The GHC developers are very pleased to announce the availability of the release candidate of GHC 9.8.1. Binary distributions, source distributions, and documentation are available at downloads.haskell.org.

GHC 9.8 will bring a number of new features and improvements, including:

  • Preliminary support the TypeAbstractions language extension, allowing types to be bound in type declarations TypeAbstractions.

  • Support for the ExtendedLiterals extension, providing syntax for non-word-sized numeric literals in the surface language extended-literals

  • Improved rewrite rule matching behavior, allowing limited matching of higher-order patterns

  • Better support for user-defined warnings by way of the WARNING pragma warnings

  • The introduction of the new GHC.TypeError.Unsatisfiable constraint, allowing more predictable user-defined type errors unsatisfiable

  • Implementation of the export deprecation proposal, allowing module exports to be marked with DEPRECATE pragmas deprecated-exports

  • The addition of build semaphore support for parallel compilation; with coming support in cabal-install this will allow better use of parallelism in multi-package builds jsem

  • More efficient representation of info table provenance information, reducing binary sizes by over 50% in some cases when -finfo-table-map is in use

A full accounting of changes can be found in the release notes. This candidate includes roughly 20 new commits relative to alpha 4, including what we believe should be nearly the last changes to GHC’s boot libraries. As always, GHC’s release status can be found on the GHC Wiki status.

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.

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

Happy compiling,

Ben

]]>
Fri, 29 Sep 2023 00:00:00 UThttp://haskell.org/ghc/blog/20230929-ghc-9.8.1-rc1-released.htmlghc-devs
Aquileo | GHC 9.6.3 is now availablehttp://haskell.org/ghc/blog/20230925-ghc-9.6.3-released.html GHC 9.6.3 is now available

Bryan Richter - 2023-09-25

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

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

  • Disable Polymorphic Specialisation (a performance optimisation) by default. It was discovered that Polymorphic Specialisation as currently implemented in GHC can lead to hard to diagnose bugs resulting in incorrect runtime results. Users wishing to use this optimisation despite the caveats will now have to explicitly enable the new -fpolymorphic-specialisation flag. For more details see #23469 as well as #23109, #21229, #23445.

  • Improve compile time and code generation performance when -finfo-table-map is enabled (#23103).

  • Make the recompilation check more robust when code generation flags are changed (#23369).

  • Addition of memory barriers that improve soundness on platforms with weak memory ordering.

  • And dozens of other 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.

Enjoy!

-Bryan

]]>
Mon, 25 Sep 2023 00:00:00 UThttp://haskell.org/ghc/blog/20230925-ghc-9.6.3-released.htmlghc-devs
Aquileo | GHC 9.8.1-alpha4 is now availablehttp://haskell.org/ghc/blog/20230919-ghc-9.8.1-alpha4-released.html GHC 9.8.1-alpha4 is now available

bgamari - 2023-09-19

The GHC developers are very pleased to announce the availability of the fourth alpha prerelease of GHC 9.8.1. Binary distributions, source distributions, and documentation are available at downloads.haskell.org.

GHC 9.8 will bring a number of new features and improvements, including:

  • Preliminary support the TypeAbstractions language extension, allowing types to be bound in type declarations.

  • Support for the ExtendedLiterals extension, providing more consistent support for non-word-sized numeric literals in the surface language

  • Improved rewrite rule matching behavior, allowing limited matching of higher-order patterns

  • Better support for user-defined warnings by way of the WARNING pragma

  • The introduction of the new GHC.TypeError.Unsatisfiable constraint, allowing more predictable user-defined type errors

  • Implementation of the export deprecation proposal, allowing module exports to be marked with DEPRECATE pragmas

  • The addition of build semaphore support for parallel compilation, allowing better use of parallelism across GHC builds

  • More efficient representation of info table provenance information, reducing binary sizes by nearly 80% in some cases when -finfo-table-map is in use

A full accounting of changes can be found in the release notes. This alpha includes roughly 40 new commits relative to alpha 3, including what we believe should be nearly the last changes to GHC’s boot libraries.

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.

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

]]>
Tue, 19 Sep 2023 00:00:00 UThttp://haskell.org/ghc/blog/20230919-ghc-9.8.1-alpha4-released.htmlghc-devs
Aquileo | GHC 9.4.7 is now availablehttp://haskell.org/ghc/blog/20230825-ghc-9.4.7-released.html GHC 9.4.7 is now available

Zubin Duggal - 2023-08-25

The GHC developers are happy to announce the availability of GHC 9.4.7. Binary distributions, source distributions, and documentation are available at downloads.haskell.org.

This release is primarily a bugfix release addressing some issues found in 9.4.7. These include:

  • A bump to bytestring-0.11.5.2 allowing GHC to be bootstrapped on systems where the bootstrap compiler is built with the pthread_condattr_setclock symbol available (#23789).
  • A number of bug fixes for scoping bugs in the specialiser, preventing simplifier panics (#21391, #21689, #21828, #23762).
  • Distributing dynamically linked alpine bindists (#23349, #23828).
  • A bug fix for the release notes syntax, allowing them to built on systems with older python and sphinx versions (#23807, #23818).
  • … and a few more. See the release notes for a full accounting.

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 compiling,

  • Zubin
]]>
Fri, 25 Aug 2023 00:00:00 UThttp://haskell.org/ghc/blog/20230825-ghc-9.4.7-released.htmlghc-devs
Aquileo | GHC 9.8.1-alpha3 is now availablehttp://haskell.org/ghc/blog/20230823-ghc-9.8.1-alpha3-released.html GHC 9.8.1-alpha3 is now available

bgamari - 2023-08-23

The GHC developers are very pleased to announce the availability of the third alpha prerelease of GHC 9.8.1. Binary distributions, source distributions, and documentation are available at downloads.haskell.org.

GHC 9.8 will bring a number of new features and improvements, including:

  • Preliminary support the TypeAbstractions language extension, allowing types to be bound in type declarations.

  • Support for the ExtendedLiterals extension, providing more consistent support for non-word-sized numeric literals in the surface language

  • Improved rewrite rule matching behavior, allowing limited matching of higher-order patterns

  • Better support for user-defined warnings by way of the WARNING pragma

  • The introduction of the new GHC.TypeError.Unsatisfiable constraint, allowing more predictable user-defined type errors

  • Implementation of the export deprecation proposal, allowing module exports to be marked with DEPRECATE pragmas

  • The addition of build semaphore support for parallel compilation, allowing better use of parallelism across GHC builds

  • More efficient representation of info table provenance information, reducing binary sizes by nearly 80% in some cases when -finfo-table-map is in use

A full accounting of changes can be found in the release notes. This alpha includes roughly a dozen changes relative to alpha 2, including what we believe should be nearly the last changes to GHC’s boot libraries.

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.

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

]]>
Wed, 23 Aug 2023 00:00:00 UThttp://haskell.org/ghc/blog/20230823-ghc-9.8.1-alpha3-released.htmlghc-devs
Aquileo | GHC 9.8.1-alpha2 is now availablehttp://haskell.org/ghc/blog/20230809-ghc-9.8.1-alpha2-released.html GHC 9.8.1-alpha2 is now available

bgamari - 2023-08-09

The GHC developers are very pleased to announce the availability of the second alpha prerelease of GHC 9.8.1. Binary distributions, source distributions, and documentation are available at downloads.haskell.org.

GHC 9.8 will bring a number of new features and improvements, including:

  • Preliminary support the TypeApplications language extension, allowing types to be bound in type declarations.

  • Support for the ExtendedLiterals extension, providing more consistent support for non-word-sized numeric literals in the surface language

  • Improved rewrite rule matching behavior, allowing limited matching of higher-order patterns

  • Better support for user-defined warnings by way of the WARNING pragma

  • The introduction of the new GHC.TypeError.Unsatisfiable constraint, allowing more predictable user-defined type errors

  • Implementation of the export deprecation proposal, allowing module exports to be marked with DEPRECATE pragmas

  • The addition of build semaphore support for parallel compilation, allowing better use of parallelism across GHC builds

  • More efficient representation of info table provenance information, reducing binary sizes by nearly 80% in some cases when -finfo-table-map is in use

A full accounting of changes can be found in the release notes. This alpha includes roughly two dozen bug-fixes relative to alpha 1.

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.

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

]]>
Wed, 09 Aug 2023 00:00:00 UThttp://haskell.org/ghc/blog/20230809-ghc-9.8.1-alpha2-released.htmlghc-devs
Aquileo | GHC 9.4.6 is now availablehttp://haskell.org/ghc/blog/20230807-ghc-9.4.6-released.html GHC 9.4.6 is now available

Zubin Duggal - 2023-08-07

The GHC developers are happy to announce the availability of GHC 9.4.6. Binary distributions, source distributions, and documentation are available at downloads.haskell.org.

This release is primarily a bugfix release addressing some issues found in 9.4.6. These include:

  • Many bug fixes for the simplifier, preventing compiler panics, loops and incorrect code generation (#22761, #22549, #23208, #22761, #22272, #23146, #23012, #22547).
  • Bug fixes for the typechecker involving newtype family instances, making type equalities more robust and bugs having to do with defaulting representation polymorphic type variables (#23329, #23333, #23143, #23154, #23176).
  • Some bug fixes for code generation, particularly on the aarch64 backend, including adding more memory barriers for array read operations (#23541, #23749).
  • Some bug fixes for windows builds, ensuring the reliablility of IO manager shutdown and a bug fix for the RTS linker on windows (#23691, #22941).
  • A bug fix for the non-moving GC ensuring mutator allocations are properly accounted for (#23312).
  • A bug fix preventing some segfaults by ensuring that pinned allocations respect block size (#23400).
  • Many bug fixes for the bytecode interpreter, allowing a greater subset of the language to be interpreted (#22376, #22840, #22051, #21945, #23068, #22958).
  • … and a few more. See the release notes for a full accounting.

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 compiling,

  • Zubin
]]>
Mon, 07 Aug 2023 00:00:00 UThttp://haskell.org/ghc/blog/20230807-ghc-9.4.6-released.htmlghc-devs
Aquileo | GHC 9.8.1-alpha1 is now availablehttp://haskell.org/ghc/blog/20230727-ghc-9.8.1-alpha1-released.html GHC 9.8.1-alpha1 is now available

bgamari - 2023-07-27

The GHC developers are very pleased to announce the availability of the first alpha prerelease of GHC 9.8.1. Binary distributions, source distributions, and documentation are available at downloads.haskell.org.

GHC 9.8 will bring a number of new features and improvements, including:

  • Preliminary support the TypeAbstractions language extension, allowing types to be bound in type declarations.

  • Support for the ExtendedLiterals extension, providing syntax for non-word-sized numeric literals in the surface language

  • Improved rewrite rule matching behavior, allowing limited matching of higher-order patterns

  • Better support for user-defined warnings by way of the WARNING pragma

  • The introduction of the new GHC.TypeError.Unsatisfiable constraint, allowing more predictable user-defined type errors

  • Implementation of the export deprecation proposal, allowing module exports to be marked with DEPRECATE pragmas

  • The addition of build semaphore support for parallel compilation; with coming support in cabal-install this will allow better use of parallelism in multi-package builds

  • More efficient representation of info table provenance information, reducing binary sizes by over 50% in some cases when -finfo-table-map is in use

A full accounting of changes can be found in the release notes.

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.

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

]]>
Thu, 27 Jul 2023 00:00:00 UThttp://haskell.org/ghc/blog/20230727-ghc-9.8.1-alpha1-released.htmlghc-devs
Aquileo | GHC 9.2.8 is now availablehttp://haskell.org/ghc/blog/20230526-ghc-9.2.8-released.html GHC 9.2.8 is now available

Zubin Duggal - 2023-05-26

The GHC developers are happy to announce the availability of GHC 9.2.8. Binary distributions, source distributions, and documentation are available at downloads.haskell.org.

This release is primarily a bugfix release addressing one issue found in 9.2.7:

  • Fix a bug with RTS linker failing with ‘internal error: m32_allocator_init: Failed to map’ on newer Linux kernels (#19421).

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 compiling,

  • Zubin
]]>
Fri, 26 May 2023 00:00:00 UThttp://haskell.org/ghc/blog/20230526-ghc-9.2.8-released.htmlghc-devs
Aquileo | GHC 9.6.2 is now availablehttp://haskell.org/ghc/blog/20230523-ghc-9.6.2-released.html GHC 9.6.2 is now available

Ben Gamari - 2023-05-23

The GHC developers are happy to announce the availability of GHC 9.6.2. Binary distributions, source distributions, and documentation are available at downloads.haskell.org.

This release is primarily a bugfix release addressing a few issues found in 9.6.2. These include:

  • a number of simplifier and specialisation issues (#22761, #22549)

  • A bug resulting in crashes of programs using the new listThreads# primop (#23071).

  • A compiler crash triggered by certain uses of quantified constraints (#23171)

  • Various bugs in the Javascript backend have been fixed (#23399, #23360, #23346)

  • A missing write barrier in the non-moving collector’s handling of selector thunks, resulting in undefined behavior (#22930).

  • The non-moving garbage collector’s treatment of weak pointers has been revamped which should allow more reliable finalization of Weak# closures (#22327)

  • The non-moving garbage collector now bounds the amount of marking it will do during the post-marking stop-the-world phase, greatly reducing tail latencies in some programs (#22929)

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 compiling,

  • Ben
]]>
Tue, 23 May 2023 00:00:00 UThttp://haskell.org/ghc/blog/20230523-ghc-9.6.2-released.htmlghc-devs
Aquileo | GHC 9.4.5 is now availablehttp://haskell.org/ghc/blog/20230418-ghc-9.4.5-released.html GHC 9.4.5 is now available

Zubin Duggal - 2023-04-18

The GHC developers are happy to announce the availability of GHC 9.4.5. Binary distributions, source distributions, and documentation are available at downloads.haskell.org.

This release is primarily a bugfix release addressing a few issues found in 9.4.4. These include:

  • Fixes for a number of bug fixes in the simplifier (#22623, #22718, #22913, 22695, #23184, #22998, #22662, #22725).
  • Many bug fixes to the non-moving and parallel GCs (#22264, #22327, #22926, #22927, #22929, #22930, #17574, #21840, #22528)
  • A fix a bug with the alignment of RTS data structures that could result in segfaults when compiled with high optimisation settings on certain platforms (#22975 , #22965).
  • Bumping gmp-tarballs to a version which doesn’t use the reserved x18 register on AArch64/Darwin systems, and also has fixes for CVE-2021-43618 (#22497, #22789).
  • A number of improvements to recompilation avoidance with multiple home units (#22675, #22677, #22669, #22678, #22679, #22680)
  • Fixes for regressions in the typechecker and constraint solver (#22647, #23134, #22516, #22743)
  • Easier installation of binary distribution on MacOS platforms by changing the installation Makefile to remove the quarantine attribute when installing.
  • … and many more. See the release notes for a full accounting.

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 compiling,

  • Zubin
]]>
Tue, 18 Apr 2023 00:00:00 UThttp://haskell.org/ghc/blog/20230418-ghc-9.4.5-released.htmlghc-devs
Aquileo | GHC 9.6.1 is now availablehttp://haskell.org/ghc/blog/20230310-ghc-9.6.1-released.html GHC 9.6.1 is now available

bgamari - 2023-03-10

The GHC team is very pleased to announce the availability of GHC 9.6.1. As usual, binaries and source distributions are available at downloads.haskell.org.

Beginning with GHC 9.6.1, GHC can be built as a cross-compiler to WebAssembly and JavaScript. This is an important step towards robust support for compiling Haskell to the Web, but there are a few caveats to be aware of in the 9.6 series:

  • Both the Javascript and WebAssembly backends are still at an early stage of development and are present in this release as a technology preview

  • Using GHC as a cross-compiler is not as easy as we would like it to be; in particular, there are challenges related to Template Haskell

  • GHC is not yet run-time retargetable; a given GHC binary targets exactly one platform, and both WebAssembly and JavaScript are considered platforms for this purpose. Cross-compilers must be built from source by their users

We hope to lift all of these limitations in future releases.

Additionally, 9.6.1 includes:

  • Significant latency improvements in the non-moving garbage collector

  • Efficient runtime support for delimited continuations

  • Improvements in compiler error messages

  • Numerous improvements in the compiler’s memory usage

See the release notes for a comprehensive accounting of changes in this release.

As always, one can find a migration guide to aid in transitioning from older releases on the GHC Wiki. We have also recently started extending our release process to cover a wider set of Linux distributions. In particular, we now offer Rocky 8 and Ubuntu 20.04 binary distributions which cover RedHat-derivative and distributions using older glibc releases (namely 2.27), respectively.

Thanks to everyone who has contributed code, documentation, testing, and tickets to this release process. As this release represents upstream GHC’s first step towards supporting web targets, we are very excited to have this release out the door!

Cheers,

  • Ben
]]>
Fri, 10 Mar 2023 00:00:00 UThttp://haskell.org/ghc/blog/20230310-ghc-9.6.1-released.htmlghc-devs
Aquileo | GHC 9.6.1-rc1 is now availablehttp://haskell.org/ghc/blog/20230303-ghc-9.6.1-rc1-released.html GHC 9.6.1-rc1 is now available

bgamari - 2023-03-03

The GHC team is very pleased to announce the availability of the first (and likely final) release candidate of GHC 9.6.1. As usual, binaries and source distributions are available at downloads.haskell.org.

Beginning with GHC 9.6.1, GHC can be built as a cross-compiler to WebAssembly and JavaScript. This is an important step towards robust support for compiling Haskell to the Web, but there are a few caveats to be aware of in the 9.6 series:

  • Both the Javascript and WebAssembly backends are still at an early stage of development and are present in this release as a technology preview

  • Using GHC as a cross-compiler is not as easy as we would like it to be; in particular, there are challenges related to Template Haskell

  • GHC is not yet run-time retargetable; a given GHC binary targets exactly one platform, and both WebAssembly and JavaScript are considered platforms for this purpose. Cross-compilers must be built from source by their users

We hope to lift all of these limitations in future releases.

Additionally, 9.6.1 will include:

  • Significant latency improvements in the non-moving garbage collector

  • Efficient runtime support for delimited continuations

  • Improvements in compiler error messages

  • Numerous improvements in the compiler’s memory usage

See the release notes for a comprehensive accounting of changes in this release.

As always, one can find a migration guide to aid in transitioning from older releases on the GHC Wiki. We have also recently started extending our release process to cover a wider set of Linux distributions. In particular, we now offer Rocky 8 and Ubuntu 20.04 binary distributions which cover RedHat-derivative and distributions using older glibc releases (namely 2.27), respectively.

Please do give this release a try and open a ticket if you see anything amiss. If all goes well we expect the final release should be available by late next week.

Cheers,

  • Ben
]]>
Fri, 03 Mar 2023 00:00:00 UThttp://haskell.org/ghc/blog/20230303-ghc-9.6.1-rc1-released.htmlghc-devs
Aquileo | GHC 9.2.7 is now availablehttp://haskell.org/ghc/blog/20230227-ghc-9.2.7-released.html GHC 9.2.7 is now available

Zubin Duggal - 2023-02-27

The GHC developers are happy to announce the availability of GHC 9.2.7. Binary distributions, source distributions, and documentation are available at downloads.haskell.org.

This release is primarily a bugfix release addressing a few issues found in 9.2.6. These include:

  • A fix for a bug with the RTS linker being unable to resolve the setKeepCafs symbol which started being used by the GHC library in 9.2.6, resulting in code depending on this symbol failing to load in GHCi or via a compile time splice when using a statically linked GHC, such as on Windows (#22961).
  • A fix a bug with the alignment of RTS data structures that could result in segfaults when compiled with high optimisation settings on certain platforms (#22975 , #22965).
  • A fix for a bug in the simplifier related to placeholder values (rubbish literals) emitted by the worker/wrapper optimisation leading to -dcore-lint errors and compiler panics in certain cases (#19882, #22914, #23000).
  • Easier installation of binary distribution on MacOS platforms by changing the installation Makefile to remove the quarantine attribute when installing.
  • … and a few more. See the release notes for a full accounting.

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 compiling,

  • Zubin
]]>
Mon, 27 Feb 2023 00:00:00 UThttp://haskell.org/ghc/blog/20230227-ghc-9.2.7-released.htmlghc-devs
Aquileo | GHC 9.6.1-alpha3 is now availablehttp://haskell.org/ghc/blog/20230213-ghc-9.6.1-alpha3-released.html GHC 9.6.1-alpha3 is now available

bgamari - 2023-02-13

The GHC team is very pleased to announce the availability of GHC 9.6.1-alpha3. As usual, binaries and source distributions are available at downloads.haskell.org.

Beginning with GHC 9.6.1, GHC can be built as a cross-compiler to WebAssembly and JavaScript. This is an important step towards robust support for compiling Haskell to the Web, but there are a few caveats to be aware of in the 9.6 series:

  • Both the Javascript and WebAssembly backends are still at an early stage of development and are present in this release as a technology preview

  • Using GHC as a cross-compiler is not as easy as we would like it to be; in particular, there are challenges related to Template Haskell

  • GHC is not yet run-time retargetable; a given GHC binary targets exactly one platform, and both WebAssembly and JavaScript are considered platforms for this purpose. Cross-compilers must be built from source by their users

We hope to lift all of these limitations in future releases.

Additionally, 9.6.1 will include:

  • Significant latency improvements in the non-moving garbage collector

  • Efficient runtime support for delimited continuations

  • Improvements in compiler error messages

  • Numerous improvements in the compiler’s memory usage

See the release notes for a comprehensive accounting of changes in this release.

As always, one can find a migration guide to aid in transitioning from older releases on the GHC Wiki. We have also recently started extending our release process to cover a wider set of Linux distributions. In particular, we now offer Rocky 8 and Ubuntu 20.04 binary distributions which cover RedHat-derivative and distributions using older glibc releases (namely 2.27), respectively.

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

Cheers,

  • Ben
]]>
Mon, 13 Feb 2023 00:00:00 UThttp://haskell.org/ghc/blog/20230213-ghc-9.6.1-alpha3-released.htmlghc-devs
Aquileo | GHC 9.2.6 is now availablehttp://haskell.org/ghc/blog/20230210-ghc-9.2.6-released.html GHC 9.2.6 is now available

Zubin Duggal - 2023-02-10

The GHC developers are happy to announce the availability of GHC 9.2.6. Binary distributions, source distributions, and documentation are available at downloads.haskell.org.

This release is primarily a bugfix release addressing a few issues found in 9.2.5. These include:

  • Fixes for a number of simplifier issues typically resulting in compiler panics (#22491, #22482, #19824, #22718, #22662, #22039).
  • Fix for a simplifier regression in 9.2.5 that could impact runtime performance when compiling with optimisations due to duplication of expensive work (#22425).
  • Various stability improvments and bug fixes for the non moving and parallel GCs (#22528, #20221, #22264, #22327, #22929, #22927, #22929, #22930).
  • Allow certain keywords which can be used as variable names with -XOverloadedRecordDot (#20723).
  • Improvements to typechecker performance for modules with holes in type signatures (#14766)
  • Bump gmp-tarballs to a version which doesn’t use the reserved x18 register on AArch64/Darwin systems, and also has fixes for CVE-2021-43618 (#22497, #22789).
  • … and a few more. See the release notes for a full accounting.

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 compiling,

  • Zubin
]]>
Fri, 10 Feb 2023 00:00:00 UThttp://haskell.org/ghc/blog/20230210-ghc-9.2.6-released.htmlghc-devs
Aquileo | GHC 9.6.1-alpha2 is now availablehttp://haskell.org/ghc/blog/20230130-ghc-9.6.1-alpha2-released.html GHC 9.6.1-alpha2 is now available

bgamari - 2023-01-30

The GHC team is very pleased to announce the availability of GHC 9.6.1-alpha2. As usual, binaries and source distributions are available at downloads.haskell.org.

Beginning with GHC 9.6.1, GHC can be built as a cross-compiler to WebAssembly and JavaScript. This is an important step towards robust support for compiling Haskell to the Web, but there are a few caveats to be aware of in the 9.6 series:

  • Both the Javascript and WebAssembly backends are still at an early stage of development and are present in this release as a technology preview

  • Using GHC as a cross-compiler is not as easy as we would like it to be; in particular, there are challenges related to Template Haskell

  • GHC is not yet run-time retargetable; a given GHC binary targets exactly one platform, and both WebAssembly and JavaScript are considered platforms for this purpose. Cross-compilers must be built from source by their users

We hope to lift all of these limitations in future releases.

Additionally, 9.6.1 will include:

  • Significant latency improvements in the non-moving garbage collector

  • Efficient runtime support for delimited continuations

  • Improvements in compiler error messages

  • Numerous improvements in the compiler’s memory usage

See the release notes for a comprehensive accounting of changes in this release.

As always, one can find a migration guide to aid in transitioning from older releases on the GHC Wiki. We have also recently started extending our release process to cover a wider set of Linux distributions. In particular, we now offer Rocky 8 and Ubuntu 20.04 binary distributions which cover RedHat-derivative and distributions using older glibc releases (namely 2.27), respectively.

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

Cheers,

  • Ben
]]>
Mon, 30 Jan 2023 00:00:00 UThttp://haskell.org/ghc/blog/20230130-ghc-9.6.1-alpha2-released.htmlghc-devs
Aquileo | GHC 9.6.1-alpha1 is now availablehttp://haskell.org/ghc/blog/20230113-ghc-9.6.1-alpha1-released.html GHC 9.6.1-alpha1 is now available

bgamari - 2023-01-13

The GHC team is very pleased to announce the availability of GHC 9.6.1-alpha1. As usual, binaries and source distributions are available at downloads.haskell.org. This is the first alpha release in the 9.6 series which will bring a number of exciting features:

  • A new Javascript code generation backend

  • A new WebAssembly code generation backend,

  • Significant latency improvements in the non-moving garbage collector

  • Support for loading of multiple components in GHCi

  • Efficient support for delimited continuations

  • Improvements in error messages

  • Numerous improvements in compiler-residency

Note that both the Javascript and WebAssembly backends are still in a state of infancy and are present in this release as a technology preview; we hope that they will mature considerably before the final 9.6.1 release.

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

Cheers,

  • Ben
]]>
Fri, 13 Jan 2023 00:00:00 UThttp://haskell.org/ghc/blog/20230113-ghc-9.6.1-alpha1-released.htmlghc-devs
Aquileo | GHC 9.4.4 releasedhttp://haskell.org/ghc/blog/20221224-ghc-9.4.4-released.html GHC 9.4.4 released

bgamari - 2022-12-24

The GHC developers are happy to announce the availability of GHC 9.4.4. Binary distributions, source distributions, and documentation are available at downloads.haskell.org.

This release is primarily a bugfix release. Bugs fixed include:

  • An issue where the wrong labels were used in the eventlog for events emitted when using info table profiling which was broken in 9.4.3 (#22452)
  • Fix a long standing bug where invalid eventlogs would be produced with long command-lines (#20221)
  • Fix a regression in eta-expansion which resulted in serious performance regressions in 9.4.3 (#22424)
  • Fix the -fdefer-diagnostics flag (#22391)
  • Fixes to several subtle compiler panics. (#22491, #22416, #22549, #22475, #22039)
  • Add necessary write barriers to IORef operations, avoiding potential soundness issues on architectures with weakly-ordered memory models (#22468)

Note that, as GHC 9.4 is the first release series where the release artifacts are all generated by our new 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 also like to emphasize that GHC 9.4 must be used in conjunction with Cabal-3.8 or later. This is particularly important for Windows users due to changes in GHC’s Windows toolchain.

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 Haskelling,

  • Ben
]]>
Sat, 24 Dec 2022 00:00:00 UThttp://haskell.org/ghc/blog/20221224-ghc-9.4.4-released.htmlghc-devs
Aquileo | GHC 9.2.5 is now availablehttp://haskell.org/ghc/blog/20221107-ghc-9.2.5-released.html GHC 9.2.5 is now available

Zubin Duggal - 2022-11-07

The GHC developers are happy to announce the availability of GHC 9.2.5. Binary distributions, source distributions, and documentation are available at downloads.haskell.org.

This release is primarily a bugfix release addressing a few issues found in 9.2.4. These include:

  • Code generation issues in the AArch64 native code generator backend resulting in incorrect runtime results in some circumstances (#22282, #21964)
  • Fixes for a number of issues with the simplifier leading to core lint errors and suboptimal performance (#21694, #21755, #22114)
  • A long-standing interface-file determinism issue where full paths would leak into the interface file (#22162)
  • A runtime system bug where creating empty mutable arrays resulted in a crash (#21962)
  • … and a few more. See the release notes for a full accounting.

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 compiling,

  • Zubin
]]>
Mon, 07 Nov 2022 00:00:00 UThttp://haskell.org/ghc/blog/20221107-ghc-9.2.5-released.htmlghc-devs
Aquileo | GHC 9.4.3 releasedhttp://haskell.org/ghc/blog/20221103-ghc-9.4.3-released.html GHC 9.4.3 released

bgamari - 2022-11-03

The GHC developers are happy to announce the availability of GHC 9.4.3. Binary distributions, source distributions, and documentation are available at downloads.haskell.org.

This release is primarily a bugfix release addressing a few issues found in 9.4.2. These include:

  • An issue where recursively calls could be speculatively evaluated, resulting in non-termination (#20836)
  • A code generation issue in the AArch64 native code generator backend resulting in incorrect runtime results in some circumstances (#22282)
  • A crash on Darwin when running executables compiled with IPE support (#22080)
  • A long-standing interface-file determinism issue where full paths would leak into the interface file (#22162)
  • A bug in the process library where file handles specified as NoStream would still be usable in the child (process#251)

Note that, as GHC 9.4 is the first release series where the release artifacts are all generated by our new 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 also like to emphasize that GHC 9.4 must be used in conjunction with Cabal-3.8 or later. This is particularly important for Windows users due to changes in GHC’s Windows toolchain.

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 Haskelling,

  • Ben
]]>
Thu, 03 Nov 2022 00:00:00 UThttp://haskell.org/ghc/blog/20221103-ghc-9.4.3-released.htmlghc-devs
Aquileo | GHC 9.4.2 releasedhttp://haskell.org/ghc/blog/20220822-ghc-9.4.2-released.html GHC 9.4.2 released

bgamari - 2022-08-22

The GHC developers are happy to announce the availability of GHC 9.4.2. Binary distributions, source distributions, and documentation are available at downloads.haskell.org.

This release is primarily a bugfix release addressing a few packaging issues found in 9.4.1. See the release notes for a full accounting.

Note that, as GHC 9.4 is the first release series where the release artifacts are all generated by our new 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 also like to emphasize that GHC 9.4 must be used in conjunction with Cabal-3.8 or later. This is particularly important for Windows users due to changes in GHC’s Windows toolchain.

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 Haskelling,

  • Ben
]]>
Mon, 22 Aug 2022 00:00:00 UThttp://haskell.org/ghc/blog/20220822-ghc-9.4.2-released.htmlghc-devs
Aquileo | GHC 9.4.1 releasedhttp://haskell.org/ghc/blog/20220807-ghc-9.4.1-released.html GHC 9.4.1 released

bgamari - 2022-08-07

The GHC developers are happy to announce the availability of GHC 9.4.1. Binary distributions, source distributions, and documentation are available at downloads.haskell.org.

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 simplification..

  • 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 distributions.

  • 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
]]>
Sun, 07 Aug 2022 00:00:00 UThttp://haskell.org/ghc/blog/20220807-ghc-9.4.1-released.htmlghc-devs
Aquileo | Migrating from Make to Hadrian (for packagers)http://haskell.org/ghc/blog/20220805-make-to-hadrian.html Migrating from Make to Hadrian (for packagers)

Sam Derbyshire - 2022-08-05

As the Hadrian build system for GHC has reached maturity and the old Make-based build system is becoming increasingly costly to maintain, the GHC maintenance team has decided that it is finally time to remove GHC’s Make-based build system. GHC 9.4 will be the last release series compatible with Make, which will be limited to booting with GHC 9.0. From 9.6 onwards, the only supported way to build GHC will be to use Hadrian.

This blog post will give an overview of using Hadrian, which should help packagers migrate from the old Make-based build system.

The Hadrian build system

Hadrian is a modular, statically-typed, extensible build system for GHC, introduced in the paper Non-recursive Make Considered Harmful. It consists of a Haskell executable implemented using the shake library, and is used to configure and build GHC.

Building Hadrian

Contributors to GHC will be accustomed to running the ./hadrian/build script, which builds and runs Hadrian. This script calls out to cabal, which fetches the dependencies of the Hadrian package from Hackage before building the resulting Haskell executable. While this is convenient for developers, it isn’t appropriate for build environments in which one doesn’t have access to the network (e.g. in order to enforce a hermetic build environment). For that reason, Hadrian provides a set of scripts for bootstrapping the build system from source tarballs. These can be found in the hadrian/bootstrap directory.

Bootstrapping Hadrian

The Hadrian bootstrap scripts are driven by a set of precomputed build plans; these depend on the version of the bootstrap GHC being used. A typical workflow might look like the following:

  • Locally:
    • Choose a build plan appropriate for the bootstrap GHC version, such as hadrian/bootstrap/plan-bootstrap-8.10.7.json. (These build plans can also be generated manually from a cabal-install build plan; see generate_bootstrap_plans)
    • Fetch the sources needed by the build plan: bootstrap.py fetch -w <path_to_ghc> --deps plan-bootstrap-8.10.7.json -o 8_10_7_bootstrap_sources.tar.gz
  • In the build environment:
    • Provision the bootstrap-sources tarball generated above.
  • In your GHC build script:
    • Build Hadrian using the bootstrap script: bootstrap.py -w <path_to_ghc> --bootstrap-sources 8_10_7_bootstrap_sources.tar.gz
    • Build GHC using the resulting Hadrian executable, located by default in bin/hadrian, e.g. bin/hadrian -j --flavour=perf+debug_info -w <path_to_ghc>

An example of how to use these bootstrap scripts can be seen in the ghcs-nix repository. This repository contains Nix expressions specifying how to build many GHC versions, with both Make and Hadrian.

From now on, we will assume that you have built Hadrian (either via ./hadrian/build or via bootstrapping), referring to the hadrian executable agnostically.

Using Hadrian

How does Hadrian replace make?

To build GHC, we begin as before by running ./boot (if necessary, i.e. a configure file doesn’t already exist) and then ./configure <args>. As with Make, the build environment is determined by the configure script, which will read provided arguments as well as environment variables. For example, the selection of the bootstrap compiler is done via the GHC environment variable, and the selection of the C compiler uses the CC environment variable. This is unchanged, and details can be found on the GHC wiki.

Once the configure script is run, we replace make commands with hadrian commands. The fundamental command to build GHC with Hadrian is

hadrian <args>

Hadrian stages

GHC is a self-hosted compiler. This means that we need to provide a GHC executable in order to compile GHC. In Hadrian, this is done in stages:

  • The stage0 compiler is the bootstrap compiler: a user-provided executable which will be used to compile GHC. The bootstrap compiler is chosen via the GHC variable passed to the configure script.
  • The stage1 compiler is the compiler built using the stage0 compiler; it runs on the build platform and produces code for the target platform. The stage1 compiler is limited in that it does not support dynamic code loading via the internal bytecode interpreter.
  • The stage2 compiler is the compiler built using the stage1 compiler; it runs on the target platform. The stage2 compiler is necessary for the implementation of Template Haskell and GHC plugins.

In Hadrian, build artifacts are put in a subdirectory of the build folder (by default, _build) corresponding to the stage of the compiler used to perform the build. This means that the stage2 compiler will be found (if using the default build directory, _build) at _build/stage1/bin/ghc.

Hadrian provides meta-targets which can be used to build particular subsets of the compiler. A typical Hadrian command, which builds a library or executable for a given stage, looks like

hadrian <stage>:{lib,exe}:<package name>

For example, hadrian stage2:lib:base will build the stage2 base library, and put it into the _build/stage1 subdirectory.

Flavours and flavour transformers

A Hadrian build flavour is a pre-defined collection of build settings that fully define a GHC build. These are described here. The flavour being used determines the ways in which GHC and its libraries will be built, as described in the Hadrian documentation. This replaces the variables of the make build system such as GhcLibWays, DYNAMIC_GHC_PROGRAMS, DYNAMIC_BY_DEFAULT.

A flavour is set using the --flavour command-line argument, e.g. hadrian/build --flavour=perf. As a packager you probably want to use either the release or perf flavour:

flavour name description
perf A fully optimised bindist
release The same configuration as perf, but with additional build products such as interface files containing Haddock docs

Flavours can be modified using flavour transformers. For example, the profiled_ghc flavour transformer compiles the GHC library and executable with cost-centre profiling enabled. One can, e.g., apply the profiled_ghc transformer to the perf flavour with hadrian --flavour=perf+profiled_ghc.

Make variable Hadrian flavour transformer
GhcProfiled profiled_ghc
GhcDebugged debug_ghc
SplitObjs split_sections

The full list of supported flavour transformers is available here.

Building GHC for distribution

Packagers will be interested in the binary-dist and binary-dist-dir Hadrian targets. For example, the command

hadrian/build --flavour=release binary-dist

will produce a complete release binary distribution tarball, while the binary-dist-dir target produces the directory only (not the tarball). The resulting bindist will be placed in _build/bindist.

When building the binary-dist target, documentation (namely, Haddock documentation and GHC’s Sphinx-built user’s guide) will be built by default. Building of documentation can be disabled using Hadrian’s --docs=... command-line flag. If you don’t want to build documentation, there are options to disable building various parts of the documentation. For example, if you don’t have Sphinx available, you can disable the parts of the documentation which require it:

# Build only the documentation for the base package, without using sphinx
hadrian {..} docs:base --docs=no-sphinx

Further information about configuring the documentation built by Hadrian can be found in the Hadrian readme.

Large-integer implementation

GHC supports several implementations of the Integer/Natural types and operations on them. The selection of the implementation is done using the --bignum Hadrian argument, e.g. --bignum=gmp to use the GMP library, or --bignum=native to use a pure-Haskell implementation.

Key-value settings

While we expect that the mechanisms described above will suffice for most builds, Hadrian also provides a fine-grained key-value configuration mechanism for modifying the command-lines passed to each of the tools run by Hadrian. For instance, one can pass an additional argument to all GHC invocations via:

hadrian {..} "*.*.ghc.*.opts += -my-ghc-option"

Passing an additional option when compiling the ghc library only:

hadrian {..} "*.ghc.ghc.*.opts += -my-ghc-option"

These settings can also be placed in a hadrian.settings file in the build root (by default _build), instead of passing them in the command line.

Hadrian currently supports the following key-value settings

  • (<stage> or *).(<package name> or *).ghc.{hs, c, cpp, link, deps, *}.opts
    Arguments passed to GHC invocations.
    • hs for arguments passed to GHC when compiling Haskell modules
    • c for arguments passed to the C compiler
    • cpp for arguments passed to the C++ compiler
    • link for arguments passed during linking
    • deps for arguments to a ghc -M command, which outputs dependency information between Haskell modules
  • (<stage> or *).(<package name> or *).cc.{c, deps, *}.opts
    Arguments passed directly to the C compiler.
  • (<stage> or *).(<package name> or *).cabal.configure.opts
    Arguments passed to the cabal configure step.
  • (<stage> or *).(<package name> or *).hsc2hs.run.opts
    Arguments passed when running Hsc2Hs.

These Hadrian key-value settings are useful to replace the assignment of Make variables, even though Hadrian is not intended to be a one-to-one replacement of Make; recovering the behaviour with Hadrian might require a few tweaks.

Consider for example the way that Make passes flags to GHC when compiling source Haskell files. Make has several different variables, such as SRC_HC_OPTS, WAY_<way>_<pkg>_OPTS, EXTRA_HC_OPTS. These are passed in order, with later flags overriding previous ones. With Hadrian, things are much simpler, and one can usually achieve the same goal by simply setting the *.*.ghc.hs.opts Hadrian key-value setting.

The following table serves as a general guideline in migrating the use of Make variables (bearing the above caveats in mind):

Make variable Hadrian key-value setting
GhcLibOpts *.*.ghc.*.opts
GhcRtsHcOpts *.*.rts.*.opts
SRC_HC_OPTS, EXTRA_HC_OPTS *.*.ghc.hs.opts
SRC_CC_OPTS, EXTRA_CC_OPTS *.*.ghc.c.opts with -optc prefix
SRC_CPP_OPTS, EXTRA_CPP_OPTS a combination of *.*.ghc.c.opts with -optc prefix and *.*.cc.c.opts
SRC_LD_OPTS, EXTRA_LD_OPTS *.*.ghc.link.opts with -optl prefix
<pkg>_EXTRA_LD_OPTS *.<pkg>.ghc.link.opts with -optl prefix
<pkg>_CONFIGURE_OPTS *.<pkg>.cabal.configure.opts
utils/hsc2hs_dist-install_EXTRA_LD_OPTS *.*.hsc2hs.run.opt with -L prefix

To pass module-specific or way-specific options, e.g. passing a C pre-processor option when compiling specific modules in a certain way (as when using a Way_<way>_<pkg>_OPTS Make variable), please use the programmatic interface described below.

Programmatic configuration

If the above configuration mechanisms aren’t sufficient, it is also possible to directly add new configurations to Hadrian. This allows finer-grained changes, such as changing the options when compiling a specific module or set of modules. If you really need to do this, you can read about it in the Hadrian manual. A good starting place to look for inspiration is Settings.Packages, which contains the arguments used to build GHC and the libraries it depends upon. The documentation for Shake is also a helpful resource, as Hadrian uses the Shake EDSL to implement its build rules.

Further support

If you are having any issues with packaging GHC after these changes, or find yourself needing to use the programmatic interface, please open an issue on the issue tracker, so that we can work together to modify Hadrian for your needs.

]]>
Fri, 05 Aug 2022 00:00:00 UThttp://haskell.org/ghc/blog/20220805-make-to-hadrian.htmlghc-devs
Aquileo | GHC 9.2.4 is now availablehttp://haskell.org/ghc/blog/20220728-ghc-9.2.4-released.html GHC 9.2.4 is now available

Zubin Duggal - 2022-07-28

The GHC developers are very happy to at announce the availability of GHC 9.2.4. Binary distributions, source distributions, and documentation are available at downloads.haskell.org.

This release will include:

  • The new DeepSubsumption language extension which reverses the effects of the Simplified Subsumption Proposal introduced in GHC 9.0. This is an attempt to make GHC 9.2.4 more backwards compatible with GHC 8.10 and eases migration for users who depended on this feature.

    This extension is enabled by default with the Haskell2010 and Haskell98 languages but disabled with the GHC2021 language originally introduced in GHC 9.2.1.

    See the Deep Subsumption Proposal for more details.

  • Fixes for segfaults that may arise due to a bug in the implementation of the keepAlive# primop. This may regress performance for certain programs which use this primop or functions which use the primop, such as withForeignPtr. These regressions are mostly small, but can be larger in certain edge cases. Judicious use of unsafeWithForeignPtr when its argument is known not to statically diverge can mitigate these in many cases. It is our judgment that the critical correctness issues justify the regression in performance and that it is important to get a release out with the fix while we work on a better approach which will improve performance for future releases (#21708).

    We have a wiki page that tracks possible solutions to this problem, and Ben wrote a blog post detailing the introduction of the keepAlive# primop and its history.

  • Fixes for a number of miscompilations on AArch64 and other platforms (#21624, #21773, #20735, #21685).

  • Fixes for segfaults due to bugs in the RTS and GC (#21708, #21880, #21885).

  • Fixing the behaviour of Ctrl-C with GHCi on Windows (#21889).

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

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, 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 compiling,

  • Zubin
]]>
Thu, 28 Jul 2022 00:00:00 UThttp://haskell.org/ghc/blog/20220728-ghc-9.2.4-released.htmlghc-devs
Aquileo | GHC 9.4.1-rc1 releasedhttp://haskell.org/ghc/blog/20220721-ghc-9.4.1-rc1-released.html GHC 9.4.1-rc1 released

bgamari - 2022-07-21

The GHC developers are happy to announce the availability of the first (and likely last) release candidate of GHC 9.4.1. Binary distributions, source distributions, and documentation are available at downloads.haskell.org.

This release will include:

  • 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 simplification..

  • 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 distributions.

  • 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. We will be publishing a blog post describing the migration process to Hadrian in the coming weeks.

We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk stake pool, 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
]]>
Thu, 21 Jul 2022 00:00:00 UThttp://haskell.org/ghc/blog/20220721-ghc-9.4.1-rc1-released.htmlghc-devs
Aquileo | GHC 9.4.1-alpha3 releasedhttp://haskell.org/ghc/blog/20220624-ghc-9.4.1-alpha3-released.html GHC 9.4.1-alpha3 released

bgamari - 2022-06-24

The GHC developers are happy to announce the availability of the third alpha release of the GHC 9.4 series. Binary distributions, source distributions, and documentation are available at downloads.haskell.org.

This major release will include:

  • A new profiling mode, -fprof-late, which adds automatic cost-center annotations to all top-level functions after Core optimisation has run. This incurs significantly less performance cost while still providing informative profiles.

  • 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 distributions.

  • … 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’s 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.

We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk stake pool, Tweag I/O, Serokell, Equinix, SimSpace, 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
]]>
Fri, 24 Jun 2022 00:00:00 UThttp://haskell.org/ghc/blog/20220624-ghc-9.4.1-alpha3-released.htmlghc-devs
Aquileo | GHC 9.2.3 is now availablehttp://haskell.org/ghc/blog/20220527-ghc-9.2.3-released.html GHC 9.2.3 is now available

Zubin Duggal - 2022-05-27

The GHC developers are very happy to at announce the availability of GHC 9.2.3. Binary distributions, source distributions, and documentation are available at downloads.haskell.org.

This release includes many bug-fixes and other improvements to 9.2.2 including:

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, Tweag I/O, Serokell, Equinix, SimSpace, 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 compiling,

  • Zubin
]]>
Fri, 27 May 2022 00:00:00 UThttp://haskell.org/ghc/blog/20220527-ghc-9.2.3-released.htmlghc-devs
Aquileo | GHC 9.4.1-alpha2 releasedhttp://haskell.org/ghc/blog/20220524-ghc-9.4.1-alpha2-released.html GHC 9.4.1-alpha2 released

bgamari - 2022-05-24

The GHC developers are happy to announce the availability of the second alpha release of the GHC 9.4 series. Binary distributions, source distributions, and documentation are available at downloads.haskell.org.

This major release will include:

  • A new profiling mode, -fprof-late, which adds automatic cost-center annotations to all top-level functions after Core optimisation has run. This incurs significantly less performance cost while still providing informative profiles.

  • 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 distributions.

  • … 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’s 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.

We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk stake pool, Tweag I/O, Serokell, Equinix, SimSpace, 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
]]>
Tue, 24 May 2022 00:00:00 UThttp://haskell.org/ghc/blog/20220524-ghc-9.4.1-alpha2-released.htmlghc-devs
Aquileo | Mid 2022 Release Planshttp://haskell.org/ghc/blog/20220523-release-status.html Mid 2022 Release Plans

Matthew Pickering - 2022-05-23

This post sets out our current plans for the upcoming releases in the next few months.

9.4.1

The next stage of the 9.4.1 release series (alpha2) will be released within the next few days. The main changes in alpha2 relative to alpha1 are improvements to the packaging and release process which have fixed a number of packaging bugs present in alpha1 due to moving to bindists built by hadrian.

The final 9.4.1 release is scheduled for late July.

The release manager for this release is Ben Gamari.

9.2.3

The 9.2.3 release is scheduled to immediately follow the 9.4.1-alpha1. This release fixes some packaging issues on Windows and a few bugs, notably:

  • a panic involving unbound cycle-breaker variables that prevented several libraries from compiling, such as massiv-io (#20231),
  • a typechecker regression in which GHC refused to use recursive equalities involving type families (#21473, #21515).

The release manager for this release is Zubin Duggal.

9.0.* series

We do not intend to produce any more releases in the 9.0.* series. From our perspective there are no serious bugs affecting the 9.0.2 release. It is advised that users start using the 9.2 series, which we intend to stabilise in the same manner as the 8.10 series. We have made this decision for the following reasons:

  • The 9.2 series does not contain significant breakage (when upgrading from 9.0)
  • Anecdotal evidence suggests that many companies are upgrading straight from 8.10.7 to 9.2.2 and skipping the 9.0.* releases.
  • We do not currently have capacity to manage 4 active branches.

Conclusion

This post summarises the latest state of the release cycles and our intent within the next few months. If you have any questions or comments then please post the next few months. If you have any questions or comments then please be in touch via mailto:ghc-devs@haskell.org.

]]>
Mon, 23 May 2022 00:00:00 UThttp://haskell.org/ghc/blog/20220523-release-status.htmlghc-devs
Aquileo | GHC 9.4.1-alpha1 releasedhttp://haskell.org/ghc/blog/20220501-ghc-9.4.1-alpha1-released.html GHC 9.4.1-alpha1 released

bgamari - 2022-05-01

The GHC developers are happy to announce the availability of the first alpha release of the GHC 9.4 series. Binary distributions, source distributions, and documentation are available at downloads.haskell.org.

This major release will include:

  • A new profiling mode, -fprof-late, which adds automatic cost-center annotations to all top-level functions after Core optimisation has run. This incurs significantly less performance cost while still providing informative profiles.

  • 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.

  • … and much more

We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk stake pool, Tweag I/O, Serokell, Equinix, SimSpace, 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
]]>
Sun, 01 May 2022 00:00:00 UThttp://haskell.org/ghc/blog/20220501-ghc-9.4.1-alpha1-released.htmlghc-devs
Aquileo | GHC 9.2.2 is now availablehttp://haskell.org/ghc/blog/20220305-ghc-9.2.2-released.html GHC 9.2.2 is now available

bgamari - 2022-03-06

The GHC developers are very happy to at announce the availability of GHC 9.2.2. Binary distributions, source distributions, and documentation are available at downloads.haskell.org.

This release includes many bug-fixes and other improvements to 9.2.1 including:

  • A number of bug-fixes in the new AArch64 native code generator

  • Fixes ensuring that the indexWord8ArrayAs*# family of primops is handled correctly on platforms lacking support for unaligned memory accesses (#21015, #20987).

  • Improvements to the compatibility story in GHC’s migration to the XDG Base Directory Specification (#20684, #20669, #20660)

  • Restored compatibility with Windows 7

  • A new -fcompact-unwind flag, improving compatibility with C++ libraries on Apple Darwin (#11829)

  • Introduction of a new flag, -fcheck-prim-bounds, enabling runtime bounds checking of array primops (#20769)

  • Unboxing of unlifted types (#20663)

  • Numerous improvements in compiler performance.

  • Many, many others. See the release notes for a full list.

As some of the fixed issues do affect correctness users are encouraged to upgrade promptly.

Finally, thank you to Microsoft Research, GitHub, IOHK, the Zw3rk stake pool, Tweag I/O, Serokell, Equinix, SimSpace, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Moreover, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release.

As always, do open a ticket if you see anything amiss.

Happy compiling,

  • Ben
]]>
Sun, 06 Mar 2022 00:00:00 UThttp://haskell.org/ghc/blog/20220305-ghc-9.2.2-released.htmlghc-devs
Aquileo | GHC 9.0.2 is now availablehttp://haskell.org/ghc/blog/20211225-ghc-9.0.2-released.html GHC 9.0.2 is now available

Zubin Duggal - 2021-12-25

The GHC developers are very happy to at long last announce the availability of GHC 9.0.2. Binary distributions, source distributions, and documentation are available at downloads.haskell.org.

GHC 9.0.2 adds first class AArch64/Darwin support using the LLVM backend, as well as fixing a number of critical correctness bugs with the 9.0.1 release, along with numerous improvements to compiler performance and memory usage:

A complete list of bug fixes and improvements can be found in the release notes.

Finally, thank you to Microsoft Research, GitHub, IOHK, the Zw3rk stake pool, Tweag I/O, Serokell, Equinix, SimSpace, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Moreover, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release.

As always, do open a ticket if you see anything amiss.

]]>
Sat, 25 Dec 2021 00:00:00 UThttp://haskell.org/ghc/blog/20211225-ghc-9.0.2-released.htmlghc-devs
Aquileo | GHC 9.2.1 is now availablehttp://haskell.org/ghc/blog/20211029-ghc-9.2.1-released.html GHC 9.2.1 is now available

bgamari - 2021-10-29

The GHC developers are very happy to at long last announce the availability of GHC 9.2.1. Binary distributions, source distributions, and documentation are available at downloads.haskell.org.

GHC 9.2 brings a number of exciting features including:

  • A native code generation backend for AArch64, significantly speeding compilation time on ARM platforms like the Apple M1.

  • Many changes in the area of records, including the new RecordDotSyntax and NoFieldSelectors language extensions, as well as Support for DuplicateRecordFields with PatternSynonyms.

  • Introduction of the new GHC2021 language extension set, giving users convenient access to a larger set of language extensions which have been long considered stable.

  • Merging of ghc-exactprint into the GHC tree, providing infrastructure for source-to-source program rewriting out-of-the-box.

  • Introduction of a BoxedRep RuntimeRep, allowing for polymorphism over levity of boxed objects (#17526)

  • Implementation of the UnliftedDataTypes extension, allowing users to define types which do not admit lazy evaluation (proposal)

  • The new [-hi profiling][] mechanism which provides significantly improved insight into thunk leaks.

  • Support for the ghc-debug out-of-process heap inspection library ghc-debug

  • Significant improvements in the bytecode interpreter, allowing more programs to be efficently run in GHCi and Template Haskell splices.

  • Support for profiling of pinned objects with the cost-centre profiler (#7275)

  • Faster compilation and a smaller memory footprint

  • Introduction of Haddock documentation support in TemplateHaskell (#5467)

Finally, thank you to Microsoft Research, GitHub, IOHK, the Zw3rk stake pool, Tweag I/O, Serokell, Equinix, SimSpace, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Moreover, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release.

As always, do open a ticket if you see anything amiss.

Happy testing,

  • Ben
]]>
Fri, 29 Oct 2021 00:00:00 UThttp://haskell.org/ghc/blog/20211029-ghc-9.2.1-released.htmlghc-devs
Aquileo | GHC 8.10.7 is now availablehttp://haskell.org/ghc/blog/20210827-ghc-8.10.7-released.html GHC 8.10.7 is now available

Zubin Duggal - 2021-08-27

The GHC team is very pleased to announce the availability of GHC 8.10.7. Source and binary distributions are available at the usual place.

This is a small bugfix release, fixing one linking portability issue (#19950) present in GHC 8.10.5 and GHC 8.10.6 on some x86_64 macOS toolchains, which resulted in undefined symbol errors for ___darwin_check_fd_set_overflow.

Issue #19950 is caused by a bug in newer Apple toolchains (specifically XCode 12) where programs compiled with affected versions of XCode are not backwards compatible with configurations running older version of XCode (certain versions of XCode 11).

We claimed to have fixed this in GHC 8.10.6, but alas this wasn’t the case. The fix was originally tested on the master branch, which uses a different build configuration from the 8.10 branch. We have now tested the fix on the GHC 8.10 branch and finally squashed the bug.

We would like to thank Microsoft Research, GitHub, IOHK, the Zw3rk stake pool, Tweag I/O, Serokell, Equinix, SimSpace, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. We would also like to thank the hundreds of open-source contributors whose work makes GHC possible.

A complete list of bug fixes and improvements can be found in the release notes.

As always, feel free to report any issues you encounter via gitlab.haskell.org.

]]>
Fri, 27 Aug 2021 00:00:00 UThttp://haskell.org/ghc/blog/20210827-ghc-8.10.7-released.htmlghc-devs
Aquileo | GHC 8.10.6 is now availablehttp://haskell.org/ghc/blog/20210814-ghc-8.10.6-released.html GHC 8.10.6 is now available

Zubin Duggal - 2021-08-14

The GHC team is very pleased to announce the availability of GHC 8.10.6. Source and binary distributions are available at the usual place.

This is a bugfix release, fixing many issues present in GHC 8.10.5, including:

  • A fix for segmentation faults in GHCi on aarch64-darwin due to an incorrect foreign import in haskeline. See this blog post by Ben Gamari for more details on how your library could be affected.

  • A fix for a critical bug affecting Haskell Language Server (HLS) among other applications caused by missing RTS symbols required for statically linked builds of the GHC library (#19763).

  • No longer emitting spurious warnings for LLVM versions (LLVM 9-12) that were actually supported (#19973, #19829, #19959).

  • Numerous bug fixes for the new LLVM based aarch64-darwin backend (#20132).

  • Fixes and stability improvements for the non-moving GC (#19715).

  • Many other bug fixes for the RTS (#18033, #20132, #20093, #19421).

  • Many packaging related fixes, including versioned ghc-pkg executables (#20087), and actually distributing GHC versions linked against the integer-simple big integer backend (#18967, #19953) on both Windows and Alpine Linux. Previous releases were still linked against the GMP library due to a misconfiguration of the builders.

  • A significant refactoring of process fixing numerous bugs mostly on Apple platforms (#19994, process refactoring).

  • A FreeBSD release after fixing issues that caused GHC 8.10.5 to be unable to build (#19958, #19948).

  • Bug fixes for the linker on Darwin platforms (#20004, #19968, #19950).

A complete list of bug fixes and improvements can be found in the release notes.

As always, feel free to report any issues you encounter via gitlab.haskell.org.

]]>
Sat, 14 Aug 2021 00:00:00 UThttp://haskell.org/ghc/blog/20210814-ghc-8.10.6-released.htmlghc-devs
Aquileo | GHC 9.2.1-rc1 is now availablehttp://haskell.org/ghc/blog/20210807-ghc-9.2.1-rc1-released.html GHC 9.2.1-rc1 is now available

bgamari - 2021-08-07

The GHC team is very happy to announce the availability of the release cadidate of the 9.2.1 release. Binary distributions, source distributions, and documentation are available at downloads.haskell.org.

GHC 9.2 will bring a number of exciting features including:

  • A native code generation backend for AArch64, significantly reducing compilation times on ARM platforms such as the Apple M1.

  • Many changes in the area of records, including the new RecordDotSyntax and NoFieldSelectors language extensions, as well as Support for DuplicateRecordFields with PatternSynonyms.

  • Introduction of the new GHC2021 language extension set, giving users convenient access to a larger set of language extensions which have been long considered stable.

  • Merge of ghc-exactprint into the GHC tree, providing infrastructure for source-to-source program rewriting out-of-the-box.

  • Introduction of a BoxedRep RuntimeRep, allowing for polymorphism over levity of boxed objects (#17526)

  • Implementation of the UnliftedDataTypes extension, allowing users to define types which do not admit lazy evaluation (proposal)

  • The new -hi profiling mechanism which provides significantly improved insight into thunk leaks.

  • Support for the ghc-debug out-of-process heap inspection library ghc-debug

  • Support for profiling of pinned objects with the cost-centre profiler (#7275)

  • Introduction of Haddock documentation support in TemplateHaskell (#5467)

Thank you to GitHub, IOHK, the Zw3rk stake pool, Tweag I/O, Serokell, Equinix, SimSpace, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Moreover, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release.

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

Happy testing,

  • Ben
]]>
Sat, 07 Aug 2021 00:00:00 UThttp://haskell.org/ghc/blog/20210807-ghc-9.2.1-rc1-released.htmlghc-devs
Aquileo | Best practices for foreign importshttp://haskell.org/ghc/blog/20210709-capi-usage.html Best practices for foreign imports

bgamari - 2021-07-12

tl;dr: When importing system libraries we strongly recommend that users use GHC’s capi calling convention. For details, see the recommendations section below.

One of Haskell’s strengths is its great foreign function interface: using time-tested foreign libraries or raw system calls is just a foreign import away. However, while syntactically simple, safely using foreign functions can be quite tricky. A few weeks ago we saw one facet of this problem in the keepAlive# post. This week we will look at another complexity which has recently caused us trouble: calling conventions.

Why this matters

With the increasing prevalance of ARM hardware with Apple’s recent releases, many latent bugs due to calling convention details are becoming more visible.

For instance, in #20079 it was noticed that GHCi crashes on AArch64/Darwin when the terminal window is resized. We eventually found that this was due to a bug in haskeline: ioctl, a variadic function, was imported using GHC’s ccall calling convention. The fix is straightforward: use the capi pseudo-calling convention introduced in GHC 7.6.1.

It turns out that incorrect ioctl imports is rather common pattern among Hackage packages. Consequently, we thought it would be helpful to offer some explicit guidance for users.

Background: Foreign calling conventions

During a function call both the caller and the callee must agree on several operational details:

  • when the function is called:
    • which arguments can be passed in registers?
    • in what order are the remaining arguments pushed to the stack?
    • how are variadic functions handled?
    • must the stack be aligned?
    • where is the return address found?
  • when the function returns:
    • who is responsible for popping the arguments from the stack?
    • where is the return value(s) stored?

Together, these details are known as a calling convention and are typically implied by the operating system and target architecture. For instance, x86-64 Linux (and most other POSIX platforms) typically uses the System V amd64 calling convention whereas 32-bit Windows has no fewer than three commonly-used conventions.

When compiling C source, the C compiler determines a function’s calling convention using its signature, which typically appears in a header file. However, when GHC imports a function with the usual ccall calling convention, e.g.:

foreign import ccall "hello_world" helloWorld :: IO ()

it does not have the benefit of a signature; instead it must infer the calling convention from the type given by the import. This can break in two ways:

  • many calling conventions treat variadic functions (e.g. printf) differently from the corresponding non-variadic signature; while it is documented that ccall does not support variadic functions, this fact is not well-known by users.
  • the type provided by the user may be wrong (e.g. using Int instead of CInt)

Unfortunately, with the foreign import ccall mechanism the compiler has no way of catching such issues, potentially leaving the user with difficult-to-spot, platform-dependent soundness bugs.

Safe foreign calls via CApiFFI

To address help mitigate this class of bugs, GHC 7.10 introduced a new language extension, CApiFFI, which offers a more robust way to import foreign functions. Unlike ccall, capi requires that the user specify both the foreign function’s name as well as the name of the header file where its signature can be found. For instance, one can write:

foreign import capi "stdio.h puts" c_puts :: Ptr CChar -> IO CInt

To compile this, GHC will construct a C source file which #include’s stdio.h. and defines a stub function which performs the call:

#include "stdio.h"
HsInt32 ghczuwrapperZC0ZCmainZCHelloZCputs(void* a1) {
    return puts(a1);
}

This approach brings a few advantages:

  • capi imports can be used to import functions defined using CPP
  • the calling convention is decided by the C compiler using the signature provided in the indicated header file, eliminating the potential for inconsistency
  • variadic functions “just work”
  • it removes the need to worry about which of Windows’ zoo of supported conventions is used (see #12890, #3052)

Recommendations for users

As a rule, the easiest code to debug is the code that you don’t need to write. Consequently, users are encouraged to use existing bindings libraries (e.g. unix) instead of defining their own foreign imports when possible.

Of course, not all libraries have bindings available. In these cases we recommend that users use foreign import capi for imports of libraries not under their control (e.g. system libraries).

Note, however, that capi does incur a small (arguably negligible) runtime cost due to the to the C stub. It is justifiable to use ccall to avoid this runtime cost in cases where the foreign function is shipped with a package’s cbits, where the calling convention is clear.

]]>
Mon, 12 Jul 2021 00:00:00 UThttp://haskell.org/ghc/blog/20210709-capi-usage.htmlghc-devs
Aquileo | The tale of keepAlive#http://haskell.org/ghc/blog/20210607-the-keepAlive-story.html The tale of keepAlive#

bgamari - 2021-06-08

In GHC 9.0 we have reworked the primops used for guaranteeing heap object lifetime in the presence of off-heap references. The result is a new primop, keepAlive#, which largely replaces the venerable touch# operation. This post will give some background on touch#, describe the rationale for this change, discuss some of the alternatives that were evaluated on the way to this new design, and provide some guidance on how this change affects users.

Users who merely want to know how to adapt their existing touch# uses for the new keepAlive# should feel free to skip to the last section of the post.

The challenge of foreign references

One of the joys of working in a garbage collected language is that one is freed from the burden of thinking about object lifetime. Instead, it is the responsibility of the runtime to retain each object as long as it is reachable from the roots of the heap graph.

Moreover, one of the great joys of Haskell is its robust foreign function interface, giving users the ability to easily weave together Haskell and foreign code in a safe and efficient manner.

However, taken together these two features pose significant challenges to language implementors; specifically, consider a program such as:

-- Recall that:
--   newPinnedByteArray       :: Int -> IO (MutableByteArray RealWorld)
--   setByteArray             :: Prim a => MutableByteArray RealWorld -> Int -> Int -> a -> IO ()
--   mutableByteArrayContents :: MutableByteArray RealWorld -> Ptr a
import Data.Primitive.ByteArray

main = printDots 10

printDots :: Int -> IO ()
printDots len = do
    arr <- newPinnedByteArray len
    setByteArray arr 0 len (fromIntegral $ ord '.' :: Word8)
    let ptr :: Ptr CChar
        ptr = byteArrayContents arr
    puts ptr

-- Recall that:
--   void puts(const char *);
foreign import ccall "puts"
    puts :: Ptr CChar -> IO ()

Here we have allocated an array on the Haskell heap, initialized it, and passed it to the C puts function, which will print it to stdout. On its face, this program looks completely innocuous: it contains no mentions of unsafe functions, the array’s bounds are clearly respected, and puts is specified to treat its argument as immutable. Indeed, running the program even prints the expected result (at least most of the time).

However, despite its appearance, this program is fatally flawed. Specifically, note that puts is (implicitly) declared to be a safe foreign call; this means that GHC is free to do as it pleases (e.g. continue running another Haskell thread or, perhaps, initiate a GC) while the C call executes in another operating system thread. This is problematic since upon entering puts there are no references to arr remaining on the Haskell heap, leading the collector to conclude that the array can be safely reclaimed. However, arr is not dead: it is still in use via the off-heap reference passed to puts. However, this reference is not visible to the garbage collector.

Premature collection of live heap objects may result in arbitrary heap corruption, which may cause a program crash at best and incorrect runtime result at worst. Also note that while FFI is the most common reason for off-heap references, it is certainly not the only reason. In particular, any use of byteArrayContents is potentially problematic in this way.

To make such off-heap references visible to the runtime, GHC has long provided the touch operation (embodied by the GHC.Exts.touch# primop):

touch :: forall a. a -> IO ()

Semantically (and, mostly, operationally) the action touch x is a no-op; it merely instructs GHC to ensure that the given value is alive at the point when the action is executed. Using this operation we can fix printDots as follows:

printDots len = 
    arr <- newPinnedByteArray len
    setByteArray arr 0 len (fromIntegral $ ord '.' :: Word8)
    puts (byteArrayContents arr)
    touch arr

Here we have added a touch after the puts, ensuring that arr is retained at least until the call has returned.

To a functional programmer, touch may smell a bit odd, merely serving to introduce a side-effect. By contrast, most idiomatic Haskell libraries rather express resource lifetimes using the “with” pattern. That is, rather than write:

hdl <- openFile "hello.txt"
hPutStrLn hdl "hello world!"
hClose hdl

We prefer to write: withFile:

withFile "hello.txt" $ \hdl ->
    hPutStrLn hdl "hello world!"

as the latter makes the lifetime of the resource apparent from the program’s syntactic structure alone. In the same way, users have historically been advised to stay away from using touch and its variants directly. For instance, while Foreign.ForeignPtr provides a touchForeignPtr operation the documentation strong recommends that the user rather use withForeignPtr.

While it is rarely seen in user code, the touch# primop has served the Haskell community well for many years: a handful of occurrences in base, bytestring, and other foundational libraries ensured that garbage colection and foreign calls could peacefully coexist. However, as we will see, the design of the primop is ripe for unsoundness.

Aside: A bit of simplifier background

Over the years GHC’s simplifier (the GHC subsystem responsible for optimising programs in its Core intermediate representation) has consistently grown in its abilities. By GHC 8.2 we started to come to the realization that all was not well with touch#. To see why, let us examine a transform performed by GHC’s simplifier which I will call dead-continuation elimination (DCE).

Consider that you have a program such as:

doThings =
    case error "hello world" :: Int of
      0  ->  {- some large expression -}
      1  ->  {- another large expression -}
      ...

Here we have a program with a divergent expression (namely the error application) scrutinized by a case with a number of large alternatives. Under Haskell’s semantics, it is impossible for program execution to reach any of these alternatives’ right-hand-sides.

By the dead-continuation elimination transform, GHC’s simplifier will cull this unreachable code, turning the program into:

doThings =
    case error "hello world" :: Int of { }

This optimisation can significantly reduce program sizes. Note that exceptions are only one source of divergence: any non-terminating scrutinee can trigger this transformation.

The shortcomings of touch#

With this transformation in mind, consider a trivial modification to the original printDots program which loops the puts call infinitely:

printManyDots :: Int -> IO ()
printManyDots len = do
    arr <- newPinnedByteArray len
    setByteArray arr 0 len (fromIntegral $ ord '.' :: Word8)
    forever $ puts (byteArrayContents arr)
    touch arr

At its face, this modification looks benign enough; indeed, many server applications take a very similar form (replacing puts with some request handling logic). However in #14346 we noticed that the simplifier could in some cases determine that the forever $ ... expression would diverge and consequently that the touch arr continuation was unreachable. By the DCE transform, this continuation could be dropped. Without the touch application, the garbage collector may prematurely collect arr, resulting in unsoundness in an otherwise reasonable-looking program.

In light of this, it becomes clear that the design of touch# is not compatible with DCE (which is otherwise a perfectly sound transform under Haskell’s semantics): to faithfully serve its purpose, touch# must be retained even if it could never be executed.

As there are relatively few uses of touch#, we tried for a while to paper over this issue with the judicious use of NOINLINE to hide the divergence from GHC’s sights. However, between 8.2 and 8.10 we encountered at least six other user reports of unsoundness due to various manifestations of this issue in various base interfaces (#15260, #14403, #15544, #13707, #14329, #18061). For this reason, last year we resolved to address the issue in the 9.0 release, marking the beginning of a nearly year-long journey towards a possible replacement which lead us through nearly a dozen design and implementation variants.

Finding an alternative design

At first glance, the design of a safer touch# seems obvious by analogy to withFile:

with :: a -> (a -> m b) -> m b

Under such a design with x f would evaluate to f x, ensuring that x is kept alive (at least) until evaluation finishes.

While this interface is simple and pleasingly similar to patterns which Haskellers expect, it does not make for a good primop design. In particular, touch# incurs nearly no runtime overhead (it doesn’t even emit code of its own) and generally occurs in performance-critical, low-level code. Consequently, it is important to minimize the performance overhead imposed by our new primitive. However, the type given to with above is extremely restrictive to the optimisations available to the simplifier.

For instance, consider a function like,

readWord8_touch :: ForeignPtr Word8 -> IO Word8
readWord8_touch fptr = do
    n <- peek (unsafeForeignPtrToPtr fptr)
    touch fptr
    return n

After a bit of simplification this will become:

readWord8_touch :: ForeignPtr Word8 -> IO Word8
readWord8_touch fptr = IO (\s0 ->
    case readWord8# (unsafeForeignPtrToPtr fptr) s0 of (# s1, n #) ->
    case touch# fptr s1 of s2 -> 
      (# s2, W8# n #)

This function will benefit from GHC’s worker/wrapper transform, resulting in a pair of Core bindings1:

-- The worker:
worker_readWord8_touch :: ForeignPtr Word8 -> State# RealWorld -> (# State# RealWorld, Word8# #)
worker_readWord8_touch fptr s0 =
    case peek (unsafeForeignPtrToPtr fptr) s0 of (# s0, n #) ->
    case touch# fptr s0 of s1 ->
      (# s1, n #)

-- The wrapper:
readWord8_touch :: ForeignPtr Word8 -> IO Word8
readWord8_touch fptr = IO $ \s ->
    case worker_readWord fptr s of (# s1, n #) ->
      (# s1, W8# n #)
{-# INLINE readWord8_touch #-}

The readWord8_touch wrapper can then be inlined into call sites, allowing elimination of the W8# allocation (via case-of-known-constructor) at call-sites which strictly consume the result.

However, if we rewrite readWord8 using with we will rather get Core of the form:

readWord8_with :: ForeignPtr Word8 -> IO Word8
readWord8_with fptr = with fptr $ \fptr' -> IO $ \s0 ->
    case peek (unsafeForeignPtrToPtr fptr') s0 of (# s1, n #) ->
      (# s1, W8# n #)

Unlike readWord8_touch, this right-hand side does not have the constructed-product property and therefore can not benefit from unboxing by the worker/wrapper transform. Consequently, readWord8_with will allocate a W8# result on every call. Empirically we found that these added allocations significantly regress runtime performance of many, if not most, Haskell programs. GHC in particular regressed in compile-time by nearly 10% in some cases.

Recovering the CPR property?

At first appearance, there is no reason why GHC could not learn to transform programs defined in terms of with to retain the CPR property. In particular, this would require three changes:

  1. since worker/wrapper may produce results of arbitrary RuntimeRep we must generalize the type of with:

    with# :: forall a (r :: RuntimeRep) (b :: TYPE r).
             a -> (a -> b) -> b
  2. use State# tokens to enforce execution ordering:

    with# :: forall a (r :: RuntimeRep) (b :: TYPE r).
             a -> State# s -> (State# s -> b) -> b
  3. teaching the simplifier to “push” strict contexts (e.g. case) into with# applications. For instance, transform

    case (with# x s (\s' -> k)) of alt -> rhs

    into

    with# x s (\s' -> case k of alt -> rhs)

    This transformation, which we call “strict context pushing” (SCP), is similar to a transform already performed on runRW# applications (#15127). In this case of with#, it is sound as it strictly grows the scope of the continuation and therefore lengthens the lifetime of the kept-alive value.

This SCP transformation allows us to eliminate the allocation incurred in the case of readWord8 by way of inlining and simplification. That is, consider a strict call-site of readWord8:

IO $ \s0 ->
  case readWord8 fptr s0 of (# s1, n #) ->
  case n of W8# n# ->
    doSomething n#

First, we inline readWord8, resulting in:

IO $ \s0 ->
  case (
    with# fptr s0 (\s1 ->
      case peek (unsafeForeignPtrToPtr fptr') s1 of (# s2, n# #) ->
        (# s2, W8# n# #)
    )
  ) of (# s3, n #) ->
  case n of W8# n# ->
    doSomething n#

Now, by the SCP transform above, the outer case can be pushed inside of the with#:

IO $ \s0 ->
  with# fptr s0 (\s1 ->
    case (
      case peek (unsafeForeignPtrToPtr fptr') s1 of (# s2, n# #) ->
        (# s2, W8# n# #)
    ) of (# s3, n #) ->
    case n of W8# n# ->
      doSomething n#
  )

Finally, case-of-known constructor can be applied twice, eliminating the W8# allocation:

IO $ \s0 ->
  with# fptr s0 (\s1 ->
    case peek (unsafeForeignPtrToPtr fptr') s1 of (# s2, n# #) ->
      doSomething n#
  )

Hooray!

The trouble with SCP

At first glance, this SCP transform looks like a promising way to eliminate a major source of overhead imposed by with#. Unfortunately, testing quickly revealed that matters are not so simple. For instance, consider a loop which uses readWord8 to sum the elements of an array:

sumArray :: ForeignPtr Word8    -- ^ an array of Word8s
         -> Int                 -- ^ array length
         -> IO Word8
sumArray fptr n = IO (go 0# n)
  where
    go :: Word8# -> Int -> State# RealWorld -> (# State# RealWorld, Word8 #)
    go accum 0 s0 = (# s0, W8# accum #)
    go accum i s0 =
      case readWord8 (fptr `plusForeignPtr` i) s0 of (# s1, n #) ->
      case n of W8# n# ->
        go (accum +# n#) (i-1) s1

As written, this program will run in constant space (modulo short-lived garbage W8# constructors). However, consider what happens if we inline readWord8#, apply the SCP transform, and simplify in the second equation of go:

    go accum i s0 =
      with# (fptr `plusForeignPtr` i) s0 (\s1 ->
        case peek (unsafeForeignPtrToPtr (fptr `plusForeignPtr` i)) s1 of (# s2, n# #) ->
          go (accum +# n#) (i-1) s1

While we have successfully eliminated the garbage W8# allocations, the recursive go call (previously a tail-call) is now beneath a with# application. Since most implementations of with# will have the operational effect of pushing a frame to the evaluation stack, this transforms the otherwise constant-space sumArray into an O(n) program. This is clearly not acceptable.

Unfortunately, this problem is quite difficult to avoid. While one can think of placing various heuristic restrictions on the contexts where SCP is applied, there is no obviously-correct, local criterion which robostly preserves CPR while avoiding stack blow-up.

While we found no way to make SCP work, the modifications we made to with#’s type at the beginning of this section are desireable regardless. That is:

  • with# must be polymorphic in the RuntimeRep of its result lest the user is unable to use it to compute unboxed results.
  • the use of State# tokens is a good hint to the user that they must take care to control execution ordering to safely use the operation

Consequently, we will adopt the following type for with#:

with# :: forall a (r :: RuntimeRep) (b :: TYPE r).
        a -> State# s -> (State# s -> b) -> b

Generating code for with#

Above we considered some of the design decisions surrounding the user-facing interface of with#. However, the interface is only half of the story: the compiler must also know how to generate code for with#.

Thankfully, doing so is (currently) reasonably straightforward as GHC’s DCE optimisation strictly occurs on Core. For this reason, we can safely desugar with# into touch# by inlining after the Core-to-Core optimisation pipeline has run (namely in the CorePrep stage of compilation). Specifically, an application:

-- Recall that
--   with# :: forall a (r :: RuntimeRep) (b :: TYPE r).
--            a -> State# s -> (State# s -> b) -> b

with# x s0 (\s0 -> k)

can be rewritten to

case k s0 of r ->
case touch# x s0 of s1 ->
  r

Admittedly, this rewrite is a bit suspicious as we there is nothing ensuring the ordering between the case k s and the touch# (since they are both applied to the State# token s). However, this is a pragmatic choice: GHC’s STG pipeline currently performs no optimisation which could reorder these expressions and forcing with# to return a (# State# s, b #) would preclude its use in some pure contexts.

On the bright side, the fact that we can reuse touch# means that we can provide with# with minimal overhead and no further changes to the backend.

keepAlive# in GHC 9.0

While we originally set out to supercede (and ultimately remove) touch#, the issues described above (and others described in the Wiki) made it clear that this plan was not feasible: what touch# lacks in robustness and aesthetics, it makes up for in efficiency and ease-of-optimisation. Moreover, there are occassionally cases which do not fit with the lexically-scoped semantics of with#.

Consequently, in GHC 9.0 we opted for a pragmatic solution: continue to allow use of touch# where necessary but prefer to use the safer with-style where possible. GHC 9.0.1 exposes this operation as keepAlive# (the kinds in the type below are slightly different than those present in 9.0, referring to BoxedRep introduced in 9.2 for added precision):

keepAlive# :: forall (lev :: Levity) (a :: TYPE (BoxedRep lev))
                     (rep :: RuntimeRep) (b :: TYPE rep) s.
              a
           -> State# s
           -> (State# s -> b)
           -> b

What implications does this have on user code? For most users, none: nearly all uses of touch# are buried in low-level libraries which have already been adapted by the GHC maintainers.

If you do for some reason use touch#, we advise that you first consider whether it is possible to replace the usage with a higher-level, less fragile abstraction: in our experience, there are few cases where touch# is necessary which would not be equally-well served by, e.g., ForeignPtr or a higher-level scoped allocation primitive.

If you have determined that the low-level primitive is indeed unavoidable then the next question is whether touch# should be replaced with keepAlive#. In the general case this unfortunately comes down to a safety/performance tradeoff. Specifically, let us consider the example of the withForeignPtr operation exposed by base. When written in terms of touch this operation is defined as:

withForeignPtr :: ForeignPtr a -> (Ptr a -> IO b) -> IO b
withForeignPtr fptr k = do
    k (unsafeForeignPtrToPtr fptr)
    touch fptr

While this can produce very efficient code, it is also deeply unsafe as the user may provide a divergent continuation (e.g. withForeignPtr fptr (forever ...)). For the reasons described above, this can result in the dropping of the touch#, resulting in unsoundness.

To avoid this, we should rather express withForeignPtr in terms of keepAlive#:

withForeignPtr :: ForeignPtr a -> (Ptr a -> IO b) -> IO b
withForeignPtr fptr k = IO $ \s0 -> 
    keepAlive# fptr s0 (unIO $ k (unsafeForeignPtrToPtr fptr))

This avoids unsoundness at the expense of needing to allocate the b result of the continuation. This is the implementation provided with base-4.15.

Introducing unsafeWithForeignPtr

While the introduction of keepAlive# affects relatively little user-code, the added cost of withForeignPtr has the potential to be more impactful. In particular, it is not uncommon to find code such as:

withForeignPtr fptr (peek @Word8)

in tight inner-loops. Adding an allocation in such a context would be catestrophic for performance and consequently GHC.ForeignPtr exports the old, touch#-based implementation of withForeignPtr as unsafeWithForeignPtr. This allows performance sensitive code to avoid boxing when it is known that the continuation is not certain to diverge. Since this operation is unsafe in the presence of known-divergent continuations, users are strong encouraged to use this operation sparingly and only in cases where the continuation is obviously not divergent.

Guidance for earlier GHC releases

As noted, use of touch# in previous GHC versions is a bit perilous unless due care is taken. Let’s consider an example:

foo :: ByteArray -> IO ()
foo x = do
    doSomething x                        -- (a)
    ...
    doForeignCall (byteArrayContents x)  -- (b)
    ...
    touch x                              -- (c)

For this program to be safe, the user must guarantee that no subexpression in the body of foo between (a) (the point that x potentially becomes unreachable) and (c) (the touch, which we must ensure DCE does not drop) is provably divergent. In the case that all of the ...s are statically known it is possible to determine this by inspection.

However, things are harder if the function takes a user-provided continuation a la withForeignPtr:

withForeignPtr :: ForeignPtr a -> (Ptr a -> IO b) -> IO b
withForeignPtr fptr k = do
    k (unsafeForeignPtrToPtr fptr)
    touch fptr

In this case the only reliable way to avoid unsoundness is to place a NOINLINE on withForeignPtr. This deprives the simplifier of knowledge of k, ensuring that it cannot conclude that touch is unreachable.

Conclusion

Here we have described a bit of the story that lead to keepAlive#. While the full story is significantly longer (and ultimately lead to the three-month deferral of the 9.0.1 release), the result is a primop which avoids a class of pernicious soundness issues which had lurked in previous releases.

If you have any questions regarding touch# and keepAlive#, do be in touch on the ghc-devs mailing list.


  1. To avoid cluttering the code too much, we are playing a bit fast-and-loose with the IO newtype here. For instance, we treat peek as a function of type State# RealWorld -> (# State# RealWorld, a #) (i.e. the representation of IO a)) instead of IO a. We will continue this pragmatic abuse of notation below.↩︎

]]>
Tue, 08 Jun 2021 00:00:00 UThttp://haskell.org/ghc/blog/20210607-the-keepAlive-story.htmlghc-devs
Aquileo | GHC 8.10.5 is now availablehttp://haskell.org/ghc/blog/20210605-ghc-8.10.5-released.html GHC 8.10.5 is now available

Zubin Duggal - 2021-06-05

The GHC team is very pleased to announce the availability of GHC 8.10.5. Source and binary distributions are available at the usual place.

This release adds native ARM/Darwin support, as well as bringing performance improvements and fixing numerous bugs of varying severity present in the 8.10 series:

  • First-class support for Apple M1 hardware using GHC’s LLVM ARM backend

  • Fix a bug resulting in segmentation faults where code may be unloaded prematurely when using the parallel garbage collector (#19417) along with other bugs in the GC and linker (#19147, #19287)

  • Improve code layout fixing certain performance regressions (#18053) and other code generation bug fixes (#19645)

  • Bug fixes for signal handling when using the pthread itimer implementation.

  • Improvements to the specializer and simplifier reducing code size and and memory usage (#17151, #18923,#18140, #10421, #18282, #13253).

  • Fix a bug where typechecker plugins could be run with an inconsistent typechecker environment (#19191).

  • Fix a simplifier bug which lead to an exponential blow up and excessive memory usage in certain cases

A complete list of bug fixes and improvements can be found in the release notes: release notes,

As always, feel free to report any issues you encounter via gitlab.haskell.org.

]]>
Sat, 05 Jun 2021 00:00:00 UThttp://haskell.org/ghc/blog/20210605-ghc-8.10.5-released.htmlghc-devs
Aquileo | GHC 9.2.1-alpha2 now availablehttp://haskell.org/ghc/blog/20210422-ghc-9.2.1-alpha2-relased.html GHC 9.2.1-alpha2 now available

Ben Gamari - 2021-04-22

The GHC developers are very happy to announce the availability of the second alpha release in the 9.2.1 series. Binary distributions, source distributions, and documentation are available from downloads.haskell.org.

GHC 9.2 will bring a number of exciting features including:

  • Many changes in the area of records, including the new RecordDotSyntax and NoFieldSelectors language extensions, as well as Support for DuplicateRecordFields with PatternSynonyms.

  • Introduction of the new GHC2021 language extension set, giving users convenient access to a larger set of language extensions which have been long considered stable.

  • Merge of ghc-exactprint into the GHC tree, providing infrastructure for source-to-source program rewriting out-of-the-box.

  • Introduction of a BoxedRep RuntimeRep, allowing for polymorphism over levity of boxed objects (#17526)

  • Implementation of the UnliftedDataTypes extension, allowing users to define types which do not admit lazy evaluation

  • The new -hi profiling mechanism which provides significantly improved insight into thunk leaks.

  • Support for the ghc-debug out-of-process heap inspection library

  • Support for profiling of pinned objects with the cost-centre profiler (#7275)

  • Introduction of Haddock documentation support in TemplateHaskell (#5467)

  • Proper support for impredicative types in the form of Quick-Look impredicativity.

  • A native code generator backend for AArch64.

This pre-release brings nearly 50 fixes relative to the first alpha, although the long-awaited ARM NCG backend hasn’t quite landed yet.

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

Happy testing!

]]>
Thu, 22 Apr 2021 00:00:00 UThttp://haskell.org/ghc/blog/20210422-ghc-9.2.1-alpha2-relased.htmlghc-devs
Aquileo | GHC 9.2.1-alpha1 now availablehttp://haskell.org/ghc/blog/20210401-ghc-9.2.1-alpha1-released.html GHC 9.2.1-alpha1 now available

Ben Gamari - 2021-04-01

The GHC developers are very happy to announce the availability of the first alpha release in the 9.2.1 series. Binary distributions, source distributions, and documentation are available from downloads.haskell.org.

GHC 9.2 will bring a number of exciting features including:

  • Many changes in the area of records, including the new RecordDotSyntax and NoFieldSelectors language extensions, as well as Support for DuplicateRecordFields with PatternSynonyms.

  • Introduction of the new GHC2021 language extension set, giving users convenient access to a larger set of language extensions which have been long considered stable.

  • Merge of ghc-exactprint into the GHC tree, providing infrastructure for source-to-source program rewriting out-of-the-box.

  • Introduction of a BoxedRep RuntimeRep, allowing for polymorphism over levity of boxed objects (#17526)

  • Implementation of the UnliftedDataTypes extension, allowing users to define types which do not admit lazy evaluation

  • The new -hi profiling mechanism which provides significantly improved insight into thunk leaks.

  • Support for the ghc-debug out-of-process heap inspection library

  • Support for profiling of pinned objects with the cost-centre profiler (#7275)

  • Introduction of Haddock documentation support in TemplateHaskell (#5467)

In addition, the final 9.2.1 release will bring a new native code generator for ARM, providing fast, first-class for Haskell on Apple ARM hardware, although this functionality is not yet present in this alpha.

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

Happy testing!

]]>
Thu, 01 Apr 2021 00:00:00 UThttp://haskell.org/ghc/blog/20210401-ghc-9.2.1-alpha1-released.htmlghc-devs
Aquileo | Status update: GHC on Apple M1 hardwarehttp://haskell.org/ghc/blog/20210309-apple-m1-story.html Status update: GHC on Apple M1 hardware

bgamari - 2021-03-09

A few months ago, Apple released the latest round of Apple hardware built upon their M1 ARM implementation. Today, existing x86-64 GHC releases can be used on M1 hardware using Rosetta emulation. In this post I will describe recent work in GHC to enable native use of the compiler on M1 hardware, as well as some welcome improvements to GHC’s general ARM support coming in GHC 9.2.

To run natively on Apple M1 hardware running macOS, GHC needs three things:

  1. the ability to generate code in the ARM instruction set
  2. support for Darwin’s ARM application binary interface (ABI)
  3. various build system changes to accomodate the new platform

GHC has had (1) for many years now through the LLVM code generation backend. By far the largest chunk of work necessary for minimal M1 support has been (2) and (3).

Below I will discuss efforts that have gone into each of these aspects. However, readers with less interest in compiler development may skip to the final section for a brief overview of the state of play.

The memory ordering problem

While GHC has long had ARM support, it has until recently been something of a second-class citizen and exhibited some degree of instability. One major cause of this was runtime’s ad-hoc treatment of memory consistency. GHC’s runtime was written well-before memory consistency models were widely understood, and nearly two decades before the standardization of C11 atomics.

Consequently, until recently GHC’s runtime relied on a mix of volatile variables and explicit memory barriers to enforce memory consistency. However, ensuring correctness in a large concurrent system like GHC’s runtime is extraordinarily difficult. As a result, numerous bugs lurked. To make matter worse, bugs generally did not affect platforms with strong memory models (e.g. x86) and only manifested on platforms like ARM where they are considerably harder to debug.

To address this, I merged a large refactoring of GHC’s lock-free memory paths in GHC 9.0. This patch moved the runtime to use standard acquire-release orderings in place of our previous explicit barriers. In addition to being easier to audit, this change enabled the use of ThreadSanitizer to idenitfy data-races within the runtime system. Using ThreadSanitizer, I was able to identify and fix over a dozen distinct data races within the runtime. As a result, we can now have considerably greater confidence in the correctness of GHC on today’s increasingly wide, out-of-order ARM implementations.

The ABI problem

Point (2) above has been particularly thorny due to the interaction between Darwin’s ABI and GHC’s historically-simplistic way of representing sub-word size integer types (e.g. Word8). The problem arises from the definition of sub-word size types in base. For instance, Word8 is defined as

data Word8 = W8# Word#

This means that, from the perspective of the compiler, Word8 is simply a word-sized (e.g. 64-bit) value; the fact that only the bottom 8-bits contains useful information has no representation in the type system. Until now this scheme has served us fine. However, this changes with Darwin/ARM, which defines a calling convention which is sensitive to argument width. This means that foreign calls like,

foreign import ccall "f" f :: Word8 -> IO ()

are treated incorrectly under this scheme on ARM/Darwin.

The long-term plan

Fixing the above issue correctly requires teaching GHC about the representation of sub-word size types. Thankfully, the first step in this direction was already taken several releases ago with the introduction of unlifted sub-word-size integer types (as described in GHC Proposal 74). However, there is still a fair amount of work that remains. First, we must rework the lifted types defined by base to take advantage of these sub-word-size types:

-- today we have:
data Word8 = W8# Word#

-- in the glorious future we will have:
data Word8 = W8# Word8#

However, this change in isolation ends breaking quite a bit of code since many of GHC’s primops primops are still defined in terms of Word#. For instance, in GHC 9.0 the primop for reading a Word8 from a ByteArray has the type:

indexWord8Array# :: ByteArray# -> Int# -> Word#

Consequently, a common idiom like W8# (indexWord8Array# byteArray n) will break if we were to merely make above change to Word8. It turns out that we can mitigate most of this by changing the primop definitions as well. That is,

-- today:
indexWord8Array# :: ByteArray# -> Int# -> Word#

-- the glorious future:
indexWord8Array# :: ByteArray# -> Int# -> Word8#

Note only does this type better reflect the operation’s meaning, but it also eliminates a significant fraction of the churn required by the lifted-type change. The return type can help here because most code doesn’t actually care what the type being returned is, so long as it can be boxed right away by the corresponding constructor (W8# in this case). We just need the constructor and primops to agree to preserve that level of compatibility.

Improving consistency of word-sized integer types

Darwin/ARM’s size-sensitive ABI also provides considerable incentive to fix a long-standing wart in our treatment of Word32# and Word64: Word64# (resp. Word32#) are only available on 32-bit (resp. 64-bit) platforms (#11953). This requires the user to awkwardly rely on CPP to select between Word64# (resp. Word32#) and Word# for 64-bit (resp. 32-bit) wide integers, depending upon the host platform.

Making all sized integer types always available on all architectures allows considerable simplification of many bits of base and other core libraries. However, it also also reveals an awkward property of our existing primop naming. Specifically to convert between the fixed-width integer types and Word# GHC 8.10 provided the following family of primops:

GHC.Exts.narrowWord8#  :: GHC.Prim.Word#    -> GHC.Prim.Word8#
GHC.Exts.extendWord8#  :: GHC.Prim.Word8#   -> GHC.Prim.Word#

GHC.Exts.narrowWord16# :: GHC.Prim.Word#    -> GHC.Prim.Word16#
GHC.Exts.extendWord16# :: GHC.Prim.Word16#  -> GHC.Prim.Word#

GHC.Exts.narrowInt8#   :: GHC.Prim.Int#     -> GHC.Prim.Int8#
GHC.Exts.extendInt8#   :: GHC.Prim.Int8#    -> GHC.Prim.Int#

GHC.Exts.narrowInt16#  :: GHC.Prim.Int#     -> GHC.Prim.Int16#
GHC.Exts.extendInt16#  :: GHC.Prim.Int16#   -> GHC.Prim.Int#

However, if we were to add such operations for, e.g., Word64# we would end up with:

GHC.Exts.narrowWord64#  :: GHC.Prim.Word#   -> GHC.Prim.Word64#
GHC.Exts.extendWord64#  :: GHC.Prim.Word64# -> GHC.Prim.Word#

Consider the case of narrowWord64# on a 32-bit platform (where Word# is 32-bits wide): the operation’s semantics make its argument wider, yet its name suggests it makes the value narrower (N.B. on a 64-bit platform this operation is a no-op). We felt that this is too confusing to be allowed to stand. Consequently the narrow and extend primops will be deprecated in 9.2 and eventually removed in GHC 9.8. They will be replaced by a set of more clearly named operations:

GHC.Exts.wordToWord64#  :: GHC.Prim.Word#   -> GHC.Prim.Word64#
GHC.Exts.word64ToWord#  :: GHC.Prim.Word64# -> GHC.Prim.Word#

GHC.Exts.wordToWord32#  :: GHC.Prim.Word#   -> GHC.Prim.Word32#
GHC.Exts.word32ToWord#  :: GHC.Prim.Word32# -> GHC.Prim.Word#

-- et cetera

The above changes are documented in the Wiki and will ship in GHC 9.2.1. While we would generally prefer to make these changes through the usual GHC proposals process, we deemed that due to the urgency of M1 support and relatively confined impact of the changes, users would be better served by quickly moving ahead (since otherwise proper M1 support likely would not have happened until 9.4). On the whole, this new story will be considerably more pleasant for all and fixes a number of related issues (#17375, #17377).

The short-term plan

Of course, the changes described above would be inappropriate to include in a minor GHC release. However, we feel that it is important that M1 support is shipped well before the release of GHC 9.2.1. For this reason, Moritz Angerman, has been working tirelessly over the past several months to backport the M1 changes to the GHC 8.10 branch, using a less principled approach for working around the calling convention issue.

This work will be released shortly in the form of a GHC 8.10.5 release. We also expect that this work will also make it into GHC 9.0.2 or 9.0.3.

A cherry on top: A new NCG for ARM

While LLVM has served us well on ARM, it is not known for its speed. For instance, on x86-64 a GHC bootstrap build using the LLVM takes roughly twice as long as a similar build using the native code generator. As Apple’s new hardware will mean that ARM will gain considerable adoption by developers, we thought such a sizeable compile-time tax was unacceptable.

To address this, Moritz Angerman picked up the long-standing (and quite large) task of implementing a native ARM backend for GHC (as enjoyed by x86-64 and PowerPC). Early indications suggest that this backend will considerably reduce compilation time on ARM platforms, bringing times in line with what we see on x86-64. This work will ship in GHC 9.2.1.

Summary

To summarize, over two years of work to improve the state of GHC on ARM will be culminating in the coming months. Specifically:

  • GHC 8.10.4 solidified ARM support by revamping the runtime’s treatment of memory consistency.

  • GHC 8.10.5 will be out in the coming weeks with initial Darwin/ARM support

  • GHC 9.0.2 will be out a few weeks later, also with Darwin/ARM support

  • GHC 9.2.1 will be released in June 2021 sporting Darwin/ARM support, revamped sized-integer types in base, and considerably faster compilation thanks to Moritz’s ARM NCG backend.

On the whole, this has been a very long road but we are quickly approach its end. This is almost entirely due to a few people who deserve recognition here: First, Moritz Angerman not just for his incredible work on the NCG and Darwin support, but also for his help wrangling CI and tireless work on the thankless task of backporting. Second, thanks to John Ericson for his work in pushing through the various primop cleanups (and knock-on changes in downstream libraries) necessitated by the M1 ABI issue.

Lastly, thanks to Davean Scies and Simspace for their help and support in hosting a set of M1 CI runners.

]]>
Tue, 09 Mar 2021 00:00:00 UThttp://haskell.org/ghc/blog/20210309-apple-m1-story.htmlghc-devs
Aquileo | GHC 8.10.4 is now availablehttp://haskell.org/ghc/blog/20210204-ghc-8.10.4-released.html GHC 8.10.4 is now available

bgamari - 2021-02-05

The GHC team is very pleased to announce the availability of GHC 8.10.4. Source and binary distributions are available at the usual place.

This is a small bug-fix release, fixing two bugs present in 8.10.3:

  • Fix a linker hang triggered by dynamic code loading on Windows (#19155)

  • Fix a crash caused by inappropriate garbage of heap-allocated data reachable from foreign exports (#19149)

As always, feel free to report any issues you encounter via gitlab.haskell.org.

]]>
Fri, 05 Feb 2021 00:00:00 UThttp://haskell.org/ghc/blog/20210204-ghc-8.10.4-released.htmlghc-devs
Aquileo | GHC 9.0.1 is now availablehttp://haskell.org/ghc/blog/20210204-ghc-9.0.1-released.html GHC 9.0.1 is now available

bgamari - 2021-02-04

The GHC team is very pleased to announce the availability of GHC 9.0.1. Source and binary distributions are available at the usual place.

In addition to numerous bug fixes, GHC 9.0.1 brings a number of new features:

  • A first cut of the new LinearTypes language extension, allowing use of linear function syntax and linear record fields.

  • A new bignum library, ghc-bignum, improving portability and allowing GHC to be more easily used with integer libraries other than GMP.

  • Improvements in code generation, resulting in considerable runtime performance improvements in some programs.

  • Improvements in pattern-match checking, allowing more precise detection of redundant cases and reduced compilation time.

  • Implementation of the “simplified subsumption” proposal simplifying the type system and paving the way for QuickLook impredicativity in GHC 9.2.

  • Implementation of the QualifiedDo extension, allowing more convenient overloading of do syntax.

  • An experimental new IO manager implementation for Windows platforms, both improving performance and fixing many of the quirks with the old manager built on POSIX-emulation.

  • Improvements in compilation time.

And many more. See the release notes for a full accounting of the changes in this release.

As always, feel free to report any issues you encounter via gitlab.haskell.org.

]]>
Thu, 04 Feb 2021 00:00:00 UThttp://haskell.org/ghc/blog/20210204-ghc-9.0.1-released.htmlghc-devs
Aquileo | GHC 9.0.1 release candidate 1 now availablehttp://haskell.org/ghc/blog/20201229-ghc-9.0.1-rc1-released.html GHC 9.0.1 release candidate 1 now available

bgamari - 2020-12-29

The GHC team is very pleased to announce the availability of the first release candidate of GHC 9.0.1 series. Source and binary distributions are available at the usual place.

This release candidate comes quite a bit later than expected after difficulty finding a performance neutral fix for a critical soundness bug, #17760. See the migration page for details on the solution, particularly if you are a library maintainer currently using the touch# primop or Foreign.ForeignPtr.withForeignPtr.

Nevertheless, this release has nevertheless seen a considerable amount of testing and consequently we hope that this should be the last pre-release before the final release.

In addition to numerous bug fixes, GHC 9.0.1 will bring a number of new features:

  • A first cut of the new LinearTypes language extension, allowing use of linear function syntax and linear record fields.

  • A new bignum library (ghc-bignum), allowing GHC to be more easily used with integer libraries other than GMP.

  • Improvements in code generation, resulting in considerable performance improvements in some programs.

  • Improvements in pattern-match checking, allowing more precise detection of redundant cases and reduced compilation time.

  • Implementation of the “simplified subsumption” proposal simplifying the type system and paving the way for QuickLook impredicativity in GHC 9.2.

  • Implementation of the QualifiedDo extension, allowing more convenient overloading of do syntax.

  • Improvements in compilation time.

And many more. See the release notes for a full accounting of the changes in this release.

As always, do test this release and open tickets for whatever issues you encounter.

]]>
Tue, 29 Dec 2020 00:00:00 UThttp://haskell.org/ghc/blog/20201229-ghc-9.0.1-rc1-released.htmlghc-devs
Aquileo | GHC 8.10.3 releasedhttp://haskell.org/ghc/blog/20201219-ghc-8.10.3-released.html GHC 8.10.3 released

bgamari - 2020-12-19

The GHC team is happy to announce the release of GHC 8.10.3. Source and binary distributions are available at the usual place.

GHC 8.10.3 fixes a number of issues in present in GHC 8.10.2 including:

  • Numerous stability improves on Windows

  • More robust support for architectures with weak memory ordering guarantees (e.g. modern ARM hardware).

  • GHC can now split dynamic objects to accomodate macOS’ RPATH size limitation when building large projects (#14444)

  • Several correctness bugs in the new low-latency garbage collector

Note that at the moment we still require that macOS Catalina users exempt the binary distribution from the notarization requirement by running xattr -cr . on the unpacked tree before running make install. This situation will hopefully be improved for GHC 9.0.1 with the resolution of #17418.

]]>
Sat, 19 Dec 2020 00:00:00 UThttp://haskell.org/ghc/blog/20201219-ghc-8.10.3-released.htmlghc-devs
Aquileo | GHC 8.10.2 releasedhttp://haskell.org/ghc/blog/20200808-ghc-8.10.2-released.html GHC 8.10.2 released

bgamari - 2020-08-08

The GHC team is happy to announce the availability of GHC 8.10.2. Source and binary distributions are available at the usual place.

GHC 8.10.2 fixes a number of issues in present in GHC 8.10.1 including:

  • Fixes a bug in process creation on Windows (#17926).

  • Fixes a code generation bug resulting in incorrect code generation for foreign calls with complex arguments (#18527)

  • Fixes a bug causing object merging to fail when the lld linker is in use (#17962)

  • Introduces a workaround for a Linux kernel bug in the implementation of the timerfd mechanism (#18033).

  • Fixes a few specialiser regressions (#17810, #18120) as well introduces a variety of miscellaneous specialiser improvements (#16473, #17930, #17966)

  • Fixes a potential loss of sharing due to left operator sections (#18151).

  • Fix bootstrapping of GHC with the LLVM backend on x86-64 (#17920).

  • A few important correctness fixes for the low-latency garbage collector. Users of --nonmoving-gc are strongly encouraged to upgrade promptly.

Note that at the moment we still require that macOS Catalina users exempt the binary distribution from the notarization requirement by running xattr -cr . on the unpacked tree before running make install. This situation will hopefully be improved for GHC 9.0.1 with the resolution of #17418.

]]>
Sat, 08 Aug 2020 00:00:00 UThttp://haskell.org/ghc/blog/20200808-ghc-8.10.2-released.htmlghc-devs
Aquileo | GHC 8.8.4 releasedhttp://haskell.org/ghc/blog/20200715-ghc-8.8.4-released.html GHC 8.8.4 released

bgamari - 2020-07-15

The GHC team is proud to announce the release of GHC 8.8.4. The source distribution, binary distributions, and documentation are available at downloads.haskell.org.

Release notes are also available.

This release fixes a handful of issues affecting 8.8.3:

  • Fixes a bug in process creation on Windows (#17926). Due to this fix we strongly encourage all Windows users to upgrade immediately.

  • Works around a Linux kernel bug in the implementation of timerfd (#18033)

  • Fixes a few linking issues affecting ARM

  • Fixes “missing interface file” error triggered by some uses of Data.Ord.Ordering (#18185)

  • Fixes an integer overflow in the compact-normal-form import implementation (#16992)

  • configure now accepts a --enable-numa flag to enable/disable numactl support on Linux.

  • Fixes potentially lost sharing due to the desugaring of left operator sections (#18151).

  • Fixes a build-system bug resulting in potential miscompilation by unregisteised compilers (#18024)

As always, if anything looks amiss do let us know.

]]>
Wed, 15 Jul 2020 00:00:00 UThttp://haskell.org/ghc/blog/20200715-ghc-8.8.4-released.htmlghc-devs
Aquileo | Integrating head.hackage with GHC's CI infrastructurehttp://haskell.org/ghc/blog/20200611-head-hackage.html Integrating head.hackage with GHC's CI infrastructure

Ben Gamari - 2020-06-11

Hello everyone,

As I mentioned a last year in my infrastructure update, one of the many features that we have gained as a result of our migration to GitLab is the ability to incorporate testing against user code (e.g. from Hackage) into our routine CI testing. In the past year we have been hard at work to make this infrastructure a reality.

In this post we will describe the current state of that infrastructure as well as what you (yes, you!) can do to help us make the most of this infrastructure; no GHC hacking experience is required!

The goal

For a long time we have discussed using our large package repositories (Hackage and Stackage) for testing of GHC snapshots and pre-releases. Specifically, there are three ends which such testing might serve:

  • correctness testing: By confirming that user code compiles we have better assurance that we understand the full implications of changes made in GHC on our users and that those changes are implemented correctly.

  • compiler performance testing: By measuring the performance of the compiler as it compilers user code we learn more about the typical cost centers within GHC. While we have dedicated performance testsuites (e.g. nofib) that also serve this purpose, there is plenty of evidence that suggests that the programs in these testsuites are qualitatively different from modern Haskell programs.

  • runtime performance testing: As with (2), but measuring the performance of the compiled program itself rather than that of GHC.

While these potential benefits are significant, so are the challenges:

  1. changes in GHC and core libraries: Due to the tight coupling between GHC and its core libraries (e.g. base, template-haskell), GHC releases are typically accompanied by library changes which often break user programs. These need to be patched but in a way that allows package authors to respect the PVP.
  2. persistent breakage: Because of the expected breakage mentioned in (1) any package set of non-trivial size will contain at least a few broken packages at any given time. For this reason, in contrast to typical CI pipelines, we want to be notified only when packages’ build state changes: e.g. when a package breakage starts (e.g. due to a breaking change being merged to GHC) but not every subsequent breakage.
  3. changes in user programs: Particularly when tracking performance changes we must take care when updating the tested set of packages: A we are fooled into thinking that a change in a user program is a regression in GHC.

While (2) and (3) are both non-trivial problems, a solution to (1) is close at hand in the form of the head.hackage patch-set.

Patching Hackage for pre-releases

The head.hackage project is a set of patches and associated tools for patching released Hackage packages to build with GHC pre-releases. While head.hackage has been a tool in GHC developers’ toolbox for over a year now, a few considerations has kept it from reaching its potential:

  1. a lack of documentation and a few usability papercuts have limited adoption to a small set of developers.
  2. the lack of integration with GHC’s own continuous integration infrastructure meant that testing of GHC snapshots had to be performed manually
  3. the lack of automated testing of the patchset has precluded scaling the approach to a larger set of packages.

The remainder of this post will discuss our recent work in implementing continuous integration infrastructure to address points (2) and (3). In a future post we will discuss work done to address (1) and walk the user through use of head.hackage to build a real-world package.

Testing infrastructure

Of course, the patch-set is of little value if it is not tested. For this reason we introduced continuous integration infrastructure, allowing us to build the patch-set with both released and pre-released compilers. These two build configurations test somewhat orthogonal notions of correctness:

  1. Testing against GHC releases tests the patch-set, giving us (some) assurance that the patches themselves are correct.

  2. Testing against master (or pre-releases) provides assurance that GHC itself hasn’t regressed.

Happily, this effort has now converged on a usable result, embodied in three merge requests:

ghc/head.hackage!2 adds CI support to head.hackage. In addition to a pass/fail status for the overall build, this job produces (e.g. as seen in this run) a variety of additional products:

  • a JSON summary of the run, describing the dependency graph and pass/fail state of each package. We can feed this to an external service to track newly-failing packages.

  • a tarball of build logs, each including statistics from GHC’s -ddump-timings flag. Not only do these logs capture the reason for failure in the case of erroring builds, but they can be scraped for compiler performance metrics, allowing us to track compiler performance on a diverse set of real-world code.

These can be fed to downstream tools, allowing us to better understand and record the evolution of GHC’s performance and correctness.

Making patched packages accessible to users

Our final goal in this effort was to make the patched packages themselves readily accessible to users, allowing users to be easily use GHC’s pre-releases to build larger projects. head.hackage’s continuous integration now produces a Hackage repository, which can be easily used to build existing projects using cabal v2-build’s remote repository support. Use of this repository will be the focus of a future blog post.

Future work

There are a few things that remain to be done:

  • Work out how to handle tracking of persistent breakage; for instance, we want a responsible party to be notified when a package initially breaks (e.g. when a breaking change is merged to GHC) but not in every subsequent build.

  • Determine a sustainable means to keep this patch-set up-to-date. Thusfar this has fallen on the shoulders of a few dedicated contributors (thanks Ryan Scott!), but to make this work in the long term we need a more diverse group of maintainers. If this sort of work sounds like something you would be interested in contributing to, please do be in touch!

    Furthermore, we might consider making authors of GHC patches which break head.hackage responsible for updating the broken packages, further spreading the maintenance load.

  • Currently our testing is limited to testing that compilation of the packages does not fail. However, we might also consider extending this to running package testsuites in select cases. This would give us further assurance of correctness, although would likely significantly increase maintenance and computational cost.

Finally, I would like to acknowledge Herbert Valerio Riedel whose vision for the head.hackage patch-set evolved into the infrastructure described above.

Cheers,

  • Ben
]]>
Thu, 11 Jun 2020 00:00:00 UThttp://haskell.org/ghc/blog/20200611-head-hackage.htmlghc-devs
Aquileo | Profiling Template Haskell spliceshttp://haskell.org/ghc/blog/20200524-profiling-template-haskell.html Profiling Template Haskell splices

Ben Gamari - 2020-05-25

This weekend a user came into #ghc asking how to profile their Template Haskell splices using GHC’s cost-center profiler. While this is not so hard in the simple case where you have no dependencies, doing so with a real package took a surprisingly long time and was non-obvious to even GHC developers. Consequently, I felt this might be helpful to write down the prescription.

In short, the method we arrived at takes advantage of GHC’s external interpreter coupled with cabal-install’s support for producing package environment files. To demonstrate the approach, we will profile the Template Haskell-based lens derivation logic of the optics-th package, using the T799 module as our source of splices.

We first start by setting up a working directory of the project:

$ cabal unpack optics-th
$ cd optics-th-0.3

Now we will build the package with cabal v2-build, taking care to instruct cabal to enable profiling and create a GHC environment file (which will be necessary shortly):

$ cabal v2-build lib:optics-th \
    --enable-profiling --write-ghc-environment-files=always

Finally, we can invoke ghc on the module containing our splices, instructing GHC to evaluate splices using the external interpreter with profiling enabled:

$ ghc -prof -fexternal-interpreter -opti+RTS -opti-p tests/Optics/TH/Tests/T799.hs 

Now we have our profile:

$ cat ghc-iserv-prof.prof 
	Sun May 24 17:20 2020 Time and Allocation Profiling Report  (Final)

	   ghc-iserv-prof +RTS -p -RTS 12 13

	total time  =        0.25 secs   (253 ticks @ 1000 us, 1 processor)
	total alloc =   4,607,184 bytes  (excludes profiling overheads)

COST CENTRE         MODULE                       SRC                                                     %time %alloc

MAIN                MAIN                         <built-in>                                               96.8   82.0
reifyDatatype       Language.Haskell.TH.Datatype src/Language/Haskell/TH/Datatype.hs:353:1-70              1.2    1.9
makeFieldOptics     Optics.TH.Internal.Product   src/Optics/TH/Internal/Product.hs:63:1-101                0.8    7.6
resolveTypeSynonyms Language.Haskell.TH.Datatype src/Language/Haskell/TH/Datatype.hs:(1257,1)-(1303,28)    0.4    5.7

...

Of course, we can also pass any of the usual heap profiling flags to the interpreter by adding additional -opti flags. For instance,

$ ghc -prof -fexternal-interpreter -opti+RTS -opti-p -opti-hy tests/Optics/TH/Tests/T799.hs 

would produce a heap profile by type, in addition to the usual .prof file.

How does it work?

The challenge in profiling Template Haskell is that we must arrange that splices run under a profiling-enabled runtime system. In GHC’s default internal interpreter mode of operation, splices (and, e.g., GHCi evaluations) are evaluated in the same process as the compiler. However, the ghc executable provided in GHC binary distributions is not built with profiling enabled.

For this reason we must instruct GHC to rather run splices in another process via the -fexternal-interpreter flag. This process is provided by the ghc-iserv executable; your GHC binary distribution ships with several variants of this executable, including one with profiling enabled. The easiest way to enable use of profiling and the external interpreter do this is by invoking GHC manually (all of my attempts at achieving this via cabal-install came up short).

However, if we invoke GHC manually we must somehow tell it where to find the dependencies that cabal-install built. For this we tell cabal-install to save this information as a GHC package environment with the --write-ghc-environment-files flag. GHC will look for this file (which is named, e.g., .ghc.environment.x86_64-linux-8.10.1) when invoked.

Finally, invoking ghc with -prof not only tells the compiler to produce profiled code, but also forces the compiler to build dependencies with profiling support. This includes both runtime dependencies, as well as the dependencies which provide splice expressions.

]]>
Mon, 25 May 2020 00:00:00 UThttp://haskell.org/ghc/blog/20200524-profiling-template-haskell.htmlghc-devs
Aquileo | The state of GHC on ARMhttp://haskell.org/ghc/blog/20200515-ghc-on-arm.html The state of GHC on ARM

bgamari - 2020-05-15

The ARM architecture represents an overwhelming majority of CPUs on this planet. Furthermore, there are now GHC users (myself included) who stake their livelihood on being able to deploy their Haskell applications on ARM-based platforms. As such, the task of making GHC run well on ARM has never been more important.

This task has a long history, being the project that brought me to GHC development many years ago, and reliability of support has varied greatly from release-to-release. As I’ve had a few people ask about the state of GHC-on-ARM over the past few months, I thought now might be a good time to write some words on the state of things.

In short, things are in significantly better shape today than they were back in 2012. There are a few reasons for this:

  • LLVM and binutils have stabilized significantly on ARM (this wasn’t always the case)

  • ARM support in GHC’s linker is now mostly complete

  • (since GHC 8.10) GHC’s runtime system is much more careful about ensuring memory ordering (see !1128)

Consequently, it now fairly easy to bring up GHC on ARMv7 and ARMv8 machines.

Getting started on a Raspberry Pi

By far, the most readily-available ARM hardware running a standard Linux distribution is the Raspberry Pi. Moreover, with more recent hardware iterations (e.g. Raspberry Pi 4) the hardware is capable enough to run GHC itself without incurring too much of a pain due to long compile times.

Most Raspberry Pi users will be using the Raspbian Debian variant. Unfortunately, due to some creative packaging decisions on the part of the Raspbian maintainers, installing GHC under Raspbian requires a bit of manual intervention.

First, we need to install LLVM 9 (which GHC uses for code generation on ARM):

$ sudo apt-get install llvm-9

Next we can fetch and install the GHC 8.10.1 ARMv7 binary distribution for Debian 9:

$ wget http://downloads.haskell.org/~ghc/8.10.1/ghc-8.10.1-armv7-deb9-linux.tar.xz
$ tar -xf ghc-8.10.1-armv7-deb9-linux.tar.gz
$ cd ghc-8.10.1
$ ./configure CONF_CC_OPTS_STAGE2="-marm -march=armv7-a" CFLAGS="-marm -march=armv7-a"
$ sudo make install

Depending upon the speed of your storage medium this may take a while. Here we have had to override the C flags inferred by autoconf since otherwise gcc will produce invalid assembler (see #17856).

Finally, we can test our handiwork:

$ ghc --version
$ cat > Hello.hs <<EOF
> main = putStrLn "hello world!"
> EOF
$ ghc Hello.hs
$ ./Hello
hello world!

We can even use GHCi:

$ ghci
GHCi, version 8.10.1: https://www.haskell.org/ghc/  :? for help
Prelude> putStrLn $ cycle "turtles all the way down.\n"
turtles all the way down.
turtles all the way down.
turtles all the way down.
...

Currently Cabal’s upstream doesn’t provide a cabal-install binary distribution for ARM (although this will hopefully change soon). Nevertheless, I have provided one here.

Future work

As always, there is plenty left to be done.

Further memory ordering robustness

While !1128 was a significant step forward in stability on ARM (and other weakly-ordered architectures), there is still room for improvement. GHC’s runtime system has long been abusing C’s volatile keyword to prevent the compiler from doing unsound things with our ubiquitous reliance on undefined behavior (in our defense, prior to the introduction on the C memory model in C11 it was not possible to write programs like GHC’s RTS in standard C).

However, finding all of the data races in the RTS is no small task. I currently have an on-going series of merge requests which adds support for checking GHC’s runtime with the ThreadSanitizer data-race detector. This is itself a non-trivial task as it requires that GHC adopt C atomics in place of our previous use of explicit barriers wherever possible. That being said, I hope to have this work done for 8.14. This will squash a few more bugs and should make GHC on ARM quite solid.

Where ThreadSanitizer does not help us is in checking the lack of data races between the mutator and the runtime system. In principle it would be possible to emit ThreadSanitizer instrumentation, in practice we have found that ThreadSanitizer gets quite upset at our large address-space reservations. Nevertheless, we have found that even just checking the RTS in isolation is very helpful, having caught several bugs that would have likely otherwise gone unnoticed.

A native code generator?

In my opinion, it is a shame that we do not have a dedicated native code generator for the most populus architecture on the planet. ARM hardware is typically fairly slow relative to x86; even under the best of conditions compile-times will be rather long. The fact that we also rely on LLVM, which itself isn’t the fastest compiler under the sun, exacerbates this problem.

However, eliminating LLVM from the equation shouldn’t be hard. ARM isn’t a complex architecture; in particular, ARMv8 is a relatively clean RISC ISA with little in the way of historical baggage. It would be relatively easy for someone with a basic grasp of assembler to write a native code generator backend for this platform in a week or two. I think this would be a great project for someone; perhaps that person could be you!

Acknowledgments

Continuous integration for ARM would not be possible without hosted hardware contributions provided by Packet through the Works on ARM program.

]]>
Fri, 15 May 2020 00:00:00 UThttp://haskell.org/ghc/blog/20200515-ghc-on-arm.htmlghc-devs
Aquileo | DWARF support in GHC (part 5)http://haskell.org/ghc/blog/20200407-dwarf-5.html DWARF support in GHC (part 5)

Ben Gamari - 2020-04-07

This is the fifth and final post of a series examining GHC’s support for DWARF debug information and the tooling that this support enables:

  • Part 1 introduces DWARF debugging information and explains how its generation can be enabled in GHC.
  • Part 2 looks at a DWARF-enabled program in gdb and examines some of the limitations of this style of debug information.
  • Part 3 looks at the backtrace support of GHC’s runtime system and how it can be used from Haskell.
  • Part 4 examines how the Linux perf utility can be used on GHC-compiled programs.
  • Part 5 concludes the series by describing future work, related projects, and ways in which you can help.

Future work

In the previous four posts we saw of some the functionality enabled by DWARF debug information. As of GHC 8.10.2 everything we saw above should be possible with the standard DWARF-enabled GHC binary distributions.

However, there is still a great deal of untapped potential and much remains to be done. Here is a sampling of tasks in no particular order:

  • Merge the fruits of my latest push on DWARF support upstream (!2380, !2373, !2387)
  • Make GHC-generated symbols (e.g. 59fw_info) more reflective of their origin in the source program
  • Preserve call-stacks in exceptions (as discussed in part 3)
  • Reduce the size of debug information through more concise representation (see #17609)
  • Some RTS symbols (e.g. stg_PAP_apply) don’t have accurate unwind information, leading to truncated backtraces in some cases (#17627)
  • Implement a native (e.g. non-DWARF-based) stack unwinder in the GHC runtime system, allowing improved unwind performance in Haskell code
  • Windows PDB support (#12397)
  • Try moving GHC’s stack pointer to the native stack pointer register, enabling call-graph profiling via DWARF unwinding (as discussed in part 4, #8272)
  • Build statistical profiling support into the GHC runtime system (#10915)
  • Add support for expressing local variables in C–, enabling allocation profiling
  • Add support for tracking register value semantics in STG-to-C– and DWARF type information, enabling local variable introspection.
  • Implement thread support in GHC.ExecutionStack
  • Make better use of GHC-specific source-note information (mentioned briefly in part 1)
  • Symbol demangling support in the GHC RTS, perf, and gdb
  • Analysis tools

As always, we are looking for people to help with this effort. If any of the above tasks sound enticing to you, do let us know. Deep compiler experience is quite unnecessary for many of these tasks, especially those in the area of analysis tools.

Below I will describe in greater detail a few of the tasks which I think hold the greatest potential.

Profile analysis tools

In his thesis, Peter Wortmann shows that the one-to-one correspondence between instructions and line numbers required by DWARF (see part 1) can result in rather un-helpful profiles. He shows that one can do significantly better by splitting the attribution of an instruction across the full set of source locations that gave rise to it. This is not something that existing tools can do. One could implement this approach on top of the sample data produced by perf record (e.g. exporting the samples via the perf script tool or the linux-perf Haskell library) and using the the extended DWARF annotations produced by GHC.

Peter’s Haskell Implementor’s Workshop demonstration showed one possible interface for such an analysis tool, marrying Haskell source and Core with sample data in the ThreadScope interface. It would be great to continue exploration down this path.

Using native stack pointer register

As noted in part 4, GHC’s current execution model on x86 precludes use of perf record’s call-graph profiling functionality. The most promising avenue to fix this would be to rework GHC to use the native stack pointer register to track the Haskell stack (#8272). This would potentially carry a few benefits:

  • it would enable use of native profiling tools

  • the native code generator could use the PUSH and POP instructions, which may be more concise or better optimised in the microarchitecture than our current stack manipulation strategy

However, there are also a few tricky points:

  • LLVM makes very strong assumptions about the nature of the stack; consequently, moving the LLVM backend to this scheme may be non-trivial.

  • the System V ABI requires that the stack always have a small region above the stack pointer (called the “red zone”) which code can use for temporary storage. GHC would need to ensure this before calling into foreign code.

There is some interesting discussion surrounding this idea in #8272 and GHC Proposal MR #17.

Building sampling profiling into the GHC runtime

Without fixing the stack register issue described above, perf’s call-graph profiling functionality is unusable. However, nothing is stopping GHC from providing its own sampling infrastructure in the runtime (#10915). In 2016 I started a branch) doing exactly this using perf_events’s signal-based sampling interface, dumping samples to GHC’s eventlog.

As far as I can recall the wip/libdw-prof branch can readily collect samples; the work that remains primarily revolves around developing analysis tools.

One approach would be to build a tool to convert the GHC-eventlog-based output from the wip/libdw-prof branch into a perf.data file for use with perf report. However, one could no doubt do much better with a more specialised tool, as described in the “Profile analysis tools” above.

While simple, this signal-based approach does imply a slightly more overhead (in the form of context-switches) than necessary. A more efficient approach might involve the Linux eBPF mechanism, which can be triggered from a perf_events event.

In-scope bindings

Most imperative compilers produce debug information that allow debuggers display and modify in-scope variables and their values. In principle GHC could also provide such support. However, doing so in a way that will be useful in simplified programs would be quite non-trivial. For instance, consider the program:

f :: (Int, String) -> Int
f (x, _) = x + 4

GHC’s worker-wrapper transformation would likely transform this to,

f :: (Int, String) -> Int
f pair =
  case pair of (x, _) -> 
  case x of I# x# ->
  case $wf x# of result ->
    I# result

$wf :: Int# -> Int#
$wf x# = x# + 4

This sort of transformation is ubiquitous and critical to the quality of GHC’s produced code. Naturally, we would want to ensure that the debug information of $wf can represent the fact that x# is the unboxed first element of the argument of f. I suspect that the best way to accomplish this would be to propagate value provenance information through binders’ (e.g. in this case x#) IdInfo metadata.

This would involve:

  1. Adding syntax in C– to encode local variable information
  2. Producing such syntax in the STG-to-C– code generator
  3. Adding information in Core to propagate value provenance, as discussed above
  4. Populate this information in worker-wrapper

While being able to poke around at Haskell values in gdb is perhaps a tempting proposition, all-in-all I suspect that the costs (both in implementation time and complexity) of would likely outweigh the benefits it would bring. This is especially true given that GHC already has the GHCi debugger for cases where such interactive debugging is necessary.

Aside: Event tracing

Some users have related to me that they have sometimes wished that GHC programs were as “traceable” as other programming language. In particular, tools like perf, bcc, bpftrace, and dtrace provide robust, minimal-overhead, language-agonstic tracing infrastructure which can be invaluable in production settings. It would be great if Haskell programs could benefit from these same tools.

The easiest on-ramp to tracing support is via the User-space Statically-Defined Tracepoint (USDT) mechanism supported by all of the aforementioned tools. Under this scheme, the traced program embeds a bit of metadata describing the available tracepoints, the information they provide, and how they are enabled.

It turns out that GHC’s runtime system already defines a number of USDT tracepoints (although they need to be enabled when configuring GHC with the --enable-dtrace configure flag). However, it is possible that this support may have bit-rotted (#15543).

However, it may also be useful to be able to define USDT tracepoints in Haskell programs. A simple implementation of this would simply be a Template Haskell splice which would generate the necessary C stubs and splice in a foreign function import and call into the program.

Aside: LLVM and X-Ray

It should also be noted that LLVM provides another, much different approach to the tracing/profiling problem with its XRay instrumentation infrastructure. This approach seeks to introduce low-cost tracing instrumentation in generated code, allowing precise and highly detailed accounting of runtime costs.

Matthew Pickering tried (#15929) adding XRay support to GHC’s LLVM backend. Unfortunately, this effort ended up being rather stunted, in part due to limitations of LLVM itself (specifically difficulties with tail-calls) and in part due to limitations of GHC’s LLVM backend (namely, we rely on the LLVM IR alias mechanism to convince LLVM that our type annotations are correct; this confuses the XRay logic).

Acknowledgments

This work has been a multi-year (off-and-on) effort for me, but it would not have been possible without a number of others.

In particular, this work would never have even started without the efforts of Peter Wortmann. Not only does the causality formalism he described in his dissertation provide the theoretical foundation for all of this functionality, but his initial implmentation kick-started the effort and the promising results he demonstrated at the Haskell Implementors’ Workshop provided me with the motivation to keep picking away at the seemingly endless stream of details which arose as I refined the feature over the years.

In general, Well-Typed’s work on GHC (and, therefore, my own work) would not have been possible without the support of Microsoft Research, IOHK and others who have supported the position which allows me to work on GHC for many years. In addition, some of my early work in 2015 to clean up the original DWARF implementation was supported directly by funding from Microsoft Research.

]]>
Tue, 07 Apr 2020 00:00:00 UThttp://haskell.org/ghc/blog/20200407-dwarf-5.htmlghc-devs
Aquileo | DWARF support in GHC (part 4)http://haskell.org/ghc/blog/20200406-dwarf-4.html DWARF support in GHC (part 4)

Ben Gamari - 2020-04-06

This post is the fourth of a series examining GHC’s support for DWARF debug information and the tooling that this support enables:

  • Part 1 introduces DWARF debugging information and explains how its generation can be enabled in GHC.
  • Part 2 looks at a DWARF-enabled program in gdb and examines some of the limitations of this style of debug information.
  • Part 3 looks at the backtrace support of GHC’s runtime system and how it can be used from Haskell.
  • Part 4 examines how the Linux perf utility can be used on GHC-compiled programs.
  • Part 5 concludes the series by describing future work, related projects, and ways in which you can help.

Profiling with perf

The final application of debug information that we will examine is performance analysis, specifically profiling with the Linux perf tool.

perf is a statistical profiling tool relying on, among other things, the underlying machine’s performance monitoring hardware. It can be used not only to profile time, but also details of the microarchitecture such as cache-misses, front-end stalls, etc. With a bit of cleverness, one can even use perf to profile allocations of a Haskell program.

Moreover, all of this profiling functionality comes with a negligible impact on the throughput of the profiled profiling. Of course, for all of these benefits one trades off precision and ease of interpretation of the resulting profile.

Summary of the trade-offs made by cost-center profiler and statistical profiling with perf.
Attribute perf cost-center profiler
Runtime impact negligible anywhere from moderate to high
Relatability to source program often hard to relate back to source program profile structure directly reflects cost centers declared in source program
Provides call graphs yes, with limited depth yes
Provides call graphs on Haskell programs not currently yes
Profiled variables time, allocations, micro-architectural counters, system calls, user- and kernel-space probe points time, allocations
Determinism profile is statistical and will likely vary from run to run deterministic

To see this trade-off in action, let’s return to our vector-tests-O0 example. We can acquire a simple time profile by simply running the executable under perf record:

$ perf record vector-tests-O0

The resulting profile can be examined via perf report. This will show you a TUI interface along the lines of

Samples: 145K of event 'cycles:ppp', Event count (approx.): 98781024840
Overhead  Command          Shared Object       Symbol
  10.19%  vector-tests-O0  vector-tests-O0     [.] integerzmwiredzmin_GHCziIntegerziType_quotInteger_info
   5.02%  vector-tests-O0  vector-tests-O0     [.] evacuate
   3.58%  vector-tests-O0  vector-tests-O0     [.] stg_upd_frame_info+0xffffffffffc00000
   3.28%  vector-tests-O0  vector-tests-O0     [.] QuickCheckzm2zi13zi2zmac90a2a0d9e0dd2c227d795a9d4d9de22a119c3781b679f3b245300e1b658c43_TestziQuickCheckziGen_zdwzdsgamma_info
   2.96%  vector-tests-O0  vector-tests-O0     [.] integerzmwiredzmin_GHCziIntegerziType_timesInteger_info
   2.93%  vector-tests-O0  vector-tests-O0     [.] integerzmwiredzmin_GHCziIntegerziType_minusInteger_info
   2.67%  vector-tests-O0  vector-tests-O0     [.] integerzmwiredzmin_GHCziIntegerziType_testBitInteger_info
   2.34%  vector-tests-O0  vector-tests-O0     [.] integerzmwiredzmin_GHCziIntegerziType_eqIntegerzh_info
   2.30%  vector-tests-O0  vector-tests-O0     [.] randomzm1zi1zmc60864d5616c60090371cdf8e600240f388e8a9bd87aa769d8045bda89826ee2_SystemziRandom_zdwrandomIvalInteger_info
   2.18%  vector-tests-O0  vector-tests-O0     [.] integerzmwiredzmin_GHCziIntegerziType_plusInteger_info
   2.16%  vector-tests-O0  vector-tests-O0     [.] integerzmwiredzmin_GHCziIntegerziType_divInteger_info
   1.71%  vector-tests-O0  vector-tests-O0     [.] QuickCheckzm2zi13zi2zmac90a2a0d9e0dd2c227d795a9d4d9de22a119c3781b679f3b245300e1b658c43_TestziQuickCheckziGen_zdwilog2_info
   1.63%  vector-tests-O0  vector-tests-O0     [.] stg_ap_p_info+0xffffffffffc00010
   1.52%  vector-tests-O0  vector-tests-O0     [.] integerzmwiredzmin_GHCziIntegerziType_remInteger_info
   1.36%  vector-tests-O0  vector-tests-O0     [.] hs_popcnt64
   1.34%  vector-tests-O0  vector-tests-O0     [.] stg_PAP_apply
   1.23%  vector-tests-O0  vector-tests-O0     [.] stg_ap_0_fast
   1.22%  vector-tests-O0  vector-tests-O0     [.] stg_gc_noregs
   1.20%  vector-tests-O0  vector-tests-O0     [.] stg_newByteArrayzh
   1.15%  vector-tests-O0  vector-tests-O0     [.] stg_ap_pp_info+0xffffffffffc00000
   1.11%  vector-tests-O0  vector-tests-O0     [.] _randomzm1zi1zmc60864d5616c60090371cdf8e600240f388e8a9bd87aa769d8045bda89826ee2_SystemziRandom_b1_siHV_entry
   0.98%  vector-tests-O0  vector-tests-O0     [.] integerzmwiredzmin_GHCziIntegerziType_geIntegerzh_info
   0.98%  vector-tests-O0  vector-tests-O0     [.] stg_BLACKHOLE_info+0xffffffffffc00069
   0.92%  vector-tests-O0  vector-tests-O0     [.] scavenge_block
...

This profile shows costs from both the runtime system and compiled Haskell. If one selects an entry from this list with the arrow keys and presses enter perf will show the annotated assembler of this function, along with the associated Haskell source.

In principle, perf record can also give us call-graph information. We will examine this in depth in the next section.

Paths to call-stack profiling

In addition to the flat profiles we saw earlier, perf can also produce call-graph profiles which sample not only the current location of execution but also callers to the enclosing function. Such call-graph profiles are produced with the perf record -g command.

Unlike flat profiles, call-graph capture tends to be quite language- and hardware-dependent. Consequently, perf record currently provides three mechanisms for collecting call-stacks:

  • via the frame pointer register: GHC doesn’t track the frame-pointer like many imperative languages do, so this is unusable on Haskell programs.

  • via the last branch record (LBR): This takes advantage of the LBR, a hardware feature of Intel CPUs, and is only really usable on modern (e.g. Skylake and later) hardware. However, even on Skylake it provides only a very limited stack depth (32 branches on Skylake, of which many will be uninteresting).

  • via DWARF unwinding: This uses DWARF unwinding information to decode the state of the stack, which is captured at sampling-time. This capture can result in non-trivial runtime overhead.

Recent Intel hardware also includes another, more expensive hardware mechanism, the Branch Trace Store, which could be useful for deeper call-graph acquisition but perf record support currently does not support using it for call-graph capture.

Summary of trade-offs made by various call-stack collection mechanisms supported by perf record.
attribute frame pointer LBR DWARF
maximum depth unlimited 32 on Skylake unlimited
runtime overhead negligible negligible small
compatible with GHC execution model no yes? not currently

Unfortunately, call-stack profiling support for Haskell is complicated by the fact that currently GHC uses machine registers in a rather non-standard way: rather than use the machine’s stack pointer register (e.g. %rsp on x86-64) to store the Haskell stack pointer GHC rather reserves another register (%rbp on x86-64). This choice simplifies interaction with foreign code at the expense of one usable register. While DWARF’s representation of unwinding information is sufficiently flexible to encode GHC’s non-standard stack register, the unwinding logic in the Linux kernel used by perf record sadly is not. For this reason, the unwind information produced by ghc -g is of little use when profiling with perf record -g.

Other than DWARF unwinding, the only other viable call-graph option is the last-branch register (LBR). Unfortunately, the rather restrictive 32-branch depth limit and the fact that GHC does not use the traditional call instruction means that in practice the call-graphs produced by this method tend not to be very useful.

In sum, currently I do not have a prescription for call-graph profiling of Haskell programs with perf. The next and final post will conclude this discussion of GHC’s debug information support by looking at future directions (including solutions to this call-graph problem) and other related projects.

]]>
Mon, 06 Apr 2020 00:00:00 UThttp://haskell.org/ghc/blog/20200406-dwarf-4.htmlghc-devs
Aquileo | DWARF support in GHC (part 3)http://haskell.org/ghc/blog/20200405-dwarf-3.html DWARF support in GHC (part 3)

Ben Gamari - 2020-04-05

This post is the third of a series examining GHC’s support for DWARF debug information and the tooling that this support enables:

  • Part 1 introduces DWARF debugging information and explains how its generation can be enabled in GHC.
  • Part 2 looks at a DWARF-enabled program in gdb and examines some of the limitations of this style of debug information.
  • Part 3 looks at the backtrace support of GHC’s runtime system and how it can be used from Haskell.
  • Part 4 examines how the Linux perf utility can be used on GHC-compiled programs.
  • Part 5 concludes the series by describing future work, related projects, and ways in which you can help.

Getting backtraces from the runtime

We saw in the last post that GHC’s debug information can be used by the gdb interactive debugger to provide meaningful backtraces of running Haskell programs. However, debuggers are not the only consumer of these backtraces. For several releases now the GHC RTS has itself supported stack backtraces. This support can be invoked in two ways:

  • via the SIGQUIT signal
  • via the GHC.ExecutionStack interface in base

In the first case, programs built with debug symbols and a libdw-enabled compiler can be sent the SIGQUIT signal 1, resulting in a stack trace being blurted to stderr:

$ vector-tests-O0 >/dev/null & sleep 0.2; kill -QUIT %1
Caught SIGQUIT; Backtrace:
                 0x1387442    set_initial_registers (rts/Libdw.c:288.0)
            0x7feecbf2b0e0    dwfl_thread_getframes (/nix/store/35vnzk39hwsx18d1bkcd30r5xrx026mr-elfutils-0.176/lib/libdw-0.176.so)
            0x7feecbf2ab4e    get_one_thread_cb (/nix/store/35vnzk39hwsx18d1bkcd30r5xrx026mr-elfutils-0.176/lib/libdw-0.176.so)
            0x7feecbf2aea3    dwfl_getthreads (/nix/store/35vnzk39hwsx18d1bkcd30r5xrx026mr-elfutils-0.176/lib/libdw-0.176.so)
            0x7feecbf2b479    dwfl_getthread_frames (/nix/store/35vnzk39hwsx18d1bkcd30r5xrx026mr-elfutils-0.176/lib/libdw-0.176.so)
                 0x1387abd    libdwGetBacktrace (rts/Libdw.c:259.0)
                 0x1373b26    backtrace_handler (rts/posix/Signals.c:534.0)
            0x7feecbf7185f    (null) (/nix/store/g2p6fwjc995jrq3d8vph7k45l9zhdf8f-glibc-2.27/lib/libpthread-2.27.so)
                 0x137f24f    _rts_stgzuapzup_ret (_build/stage1/rts/build/cmm/AutoApply.cmm:654.18)
                 0x137de10    stg_upd_frame_info (rts/Updates.cmm:31.1)
                  0xa7cc80    _randomzm1zi1zmc60864d5616c60090371cdf8e600240f388e8a9bd87aa769d8045bda89826ee2_SystemziRandom_lvl6_siHP_entry (System/Random.hs:489.70)
                 0x12c52d8    integerzmwiredzmin_GHCziIntegerziType_minusInteger_info (libraries/integer-gmp/src/GHC/Integer/Type.hs:437.1)
                  0xa7d098    randomzm1zi1zmc60864d5616c60090371cdf8e600240f388e8a9bd87aa769d8045bda89826ee2_SystemziRandom_zdwrandomIvalInteger_info (System/Random.hs:487.20)
                  0x98da50    _QuickCheckzm2zi13zi2zmac90a2a0d9e0dd2c227d795a9d4d9de22a119c3781b679f3b245300e1b658c43_TestziQuickCheckziArbitrary_sat_sx8e_entry (Test/QuickCheck/Arbitrary.hs:988.26)
                 0x137de10    stg_upd_frame_info (rts/Updates.cmm:31.1)
...
                 0x137c810    stg_stop_thread_info (rts/StgStartup.cmm:42.1)
                 0x136571b    StgRunJmp (rts/StgCRun.c:370.0)
                 0x136241b    scheduleWaitThread (rts/Capability.h:219.0)
                 0x135f35e    hs_main (rts/RtsMain.c:73.0)
                  0x455df4    (null) (/opt/exp/ghc/ghc-8.10/vector/dist-newstyle/build/x86_64-linux/ghc-8.10.0.20191231/vector-0.13.0.1/t/vector-tests-O0/build/vector-tests-O0/vector-tests-O0)
            0x7feecbd4ab8e    __libc_start_main (/nix/store/g2p6fwjc995jrq3d8vph7k45l9zhdf8f-glibc-2.27/lib/libc-2.27.so)
                  0x40a82a    _start (../sysdeps/x86_64/start.S:122.0)

This can be especially useful in diagnosing unexpected CPU usage or latency in long-running tasks (e.g. a server stuck in a loop).

Note, however, that this currently only provides a backtrace of the program’s main capability. Backtrace support for multiple capabilities is an outstanding task.

Getting backtraces from Haskell

The runtime’s unwinding support can also be invoked from Haskell programs via the GHC.ExecutionStack interface. This provides:

-- | A source location.
data Location = {- ... -}

-- | Returns a stack trace of the calling thread or 'Nothing'
-- if the runtime system lacks libdw support.
getStackTrace :: IO (Maybe [Location])

In the future we would also like to provide

getThreadStackTrace :: ThreadId -> IO (Maybe [Location])

although this is an outstanding task.

This could be used in a number of ways:

  1. when throwing an exception, one could capture the current stack for use in diagnostics output.

  2. with getThreadStackTrace a monitoring library like ekg might provide the ability to enumerate the program’s threads and introspect on what they are up to.

We’ll look at (1) in greater detail below.

Providing backtraces for exceptions

Attaching backtrace information to exceptions is fairly straightforward. For instance, one could provide

data WithStack e = WithStack (Maybe [Location]) e
instance Exception (WithStack e)

throwIOWithStack :: e -> IO a
throwIOWithStack exc = do
 stack <- getStackTrace
 throwM $ WithStack stack exc

throwWithStack :: e -> a
throwWithStack = unsafePerformIO . throwIOWithStack

-- | Attach a stack trace to any exception thrown by the enclosed action.
-- Note that this is idempotent.
addStack :: IO a -> IO a
addStack = handle f
  where
    f :: SomeException -> IO b
    f exc | WithStack{} <- fromException exc =
      throwIO exc  -- ensure idempotency
    f (SomeException exc) =
      throwIOWithStack exc

Keep in mind that DWARF stack unwinding can incur a significant overhead (being linear in the depth of the stack with a significant constant factor). Consequently, it would be unwise to use throwIOWithStack indiscriminantly (e.g. when throwing an asynchronous exception to kill another thread). However, for truly “exceptional” cases (e.g. failing due to a non-existent file), it would offer quite some value.

Unfortunately, the untyped nature of Haskell exceptions complicates the migration path for existing code. Specifically, if a library provides a function which throws MyException, users catching MyException would break if the library started throwing WithStack MyException. While this may be manageable in the case of user libraries, for packages at the heart of the Haskell ecosystem (e.g. base) this is a significant hurdle.

Another design which avoids this migration problem is to incorporate backtraces directly into the base SomeException type, which is used to represent all thrown exceptions. Specifically, Control.Exception could then expose a variety of throwing functions, reflecting the many call stack mechanisms GHC now offers:

data SomeException where
    SomeException :: forall e. Exception e
                  => Maybe [Location]  -- ^ backtrace, if available
                  -> e                 -- ^ the exception
                  -> SomeException

-- | A representation of source locations consolidating 'GHC.Stack.SrcLoc',
-- 'GHC.Stack.CostCentre', and 'GHC.ExecutionStack.Location'.
data Location = {- ... -}

-- | Throws an exception with no stack trace.
throwIO :: e -> IO a

-- | Throws an exception with a stack trace captured via
-- 'GHC.Stack.getStackTrace'.
throwIOWithExecutionStack :: e -> IO a

-- | Throws an exception with a `HasCallStack` stack trace.
throwIOWithCallStack :: HasCallStack => e -> IO a

Of course, this raises the question of which call-stack method a particular exception ought to use. This is often unknowable, depending upon the user’s build configuration. Consequently, we might consider exposing something of the form:

-- | Throws an exception with a stack trace using the most
-- precise method available in the current build configuration.
throwIOWithStack :: HasCallStack => e -> IO a
throwIOWithStack
  | profiling_enabled = throwIOWithCostCentreStack
  | dwarf_enabled     = throwIOWithExecutionStack
  | otherwise         = throwIOWithCallStack

Finally, new “catch” operations could be introduced providing the handler access to the exception’s stack:

catchWithLocation :: IO a -> (e -> Maybe [Location] -> IO a) -> IO a

Above are just two possible designs; I’m sure there are other points worthy of exploration. Do let me know if you are interesting in picking up this line of work.

The next post will look at using the Linux perf utility to profile Haskell executables.


  1. The unfortunate choice of the SIGQUIT signal to dump a backtrace originates from the Java virtual machine implementations, where this has been long available. GHC currently follows this precedent although some people believe that SIGQUIT should be used for… quitting. Do let us know on #17451 if you feel should we should reconsider the choice to follow Java on this point.↩︎

]]>
Sun, 05 Apr 2020 00:00:00 UThttp://haskell.org/ghc/blog/20200405-dwarf-3.htmlghc-devs
Aquileo | DWARF support in GHC (part 2)http://haskell.org/ghc/blog/20200404-dwarf-2.html DWARF support in GHC (part 2)

Ben Gamari - 2020-04-04

This post is the second of a series examining GHC’s support for DWARF debug information and the tooling that this support enables:

  • Part 1 introduces DWARF debugging information and explains how its generation can be enabled in GHC.
  • Part 2 looks at a DWARF-enabled program in gdb and examines some of the limitations of this style of debug information.
  • Part 3 looks at the backtrace support of GHC’s runtime system and how it can be used from Haskell.
  • Part 4 examines how the Linux perf utility can be used on GHC-compiled programs.
  • Part 5 concludes the series by describing future work, related projects, and ways in which you can help.

Using gdb on Haskell programs

gdb is an interactive debugger ubiquitous on Unix systems. Let’s try using it to run our executable and then break into execution with Ctrl-C:

$ gdb vector-tests-O0
GNU gdb (GDB) 8.3
...
Reading symbols from dist-newstyle/.../vector-tests-O0...
(gdb) run
Using host libthread_db library "/nix/store/pnd2kl27sag76h23wa5kl95a76n3k9i3-glibc-2.27/lib/libthread_db.so.1".
Data.Vector.Fusion.Bundle:
  fromList.toList == id: [OK, passed 100 tests]
  toList.fromList == id: [OK, passed 100 tests]
...
  postscanr: [OK, passed 100 tests]
  postscanr': [OK, passed 100 tests]
^C
Program received signal SIGINT, Interrupt.
stg_ap_pp_fast () at _build/stage1/rts/build/cmm/AutoApply.cmm:3708
3708	        default: {
(gdb) bt
#0  stg_ap_pp_fast () at _build/stage1/rts/build/cmm/AutoApply.cmm:3708
#1  0x000000000137de10 in _rts_stgzuupdzuframe_ret ()
#2  0x0000000000997668 in QuickCheckzm2zi13zi2zmac90a2a0d9e0dd2c227d795a9d4d9de22a119c3781b679f3b245300e1b658c43_TestziQuickCheckziArbitrary_zdfCoArbitraryAll1_info () at Test/QuickCheck/Arbitrary.hs:1230
#3  0x000000000137de10 in _rts_stgzuupdzuframe_ret ()
...
#54 0x0000000000997668 in QuickCheckzm2zi13zi2zmac90a2a0d9e0dd2c227d795a9d4d9de22a119c3781b679f3b245300e1b658c43_TestziQuickCheckziArbitrary_zdfCoArbitraryAll1_info () at Test/QuickCheck/Arbitrary.hs:1230
#55 0x000000000137de10 in _rts_stgzuupdzuframe_ret ()
#56 0x0000000001316510 in ghczmprim_GHCziClasses_zdfEqBoolzuzdczeze_info () at libraries/ghc-prim/GHC/Classes.hs:205
#57 0x0000000000643698 in r5bd2_info () at Data/Vector.hs:289
#58 0x000000000137de10 in _rts_stgzuupdzuframe_ret ()
#59 0x00000000009bc478 in s1TRr_info () at Test/QuickCheck/Property.hs:225
#60 0x00000000009bbc88 in s1TQC_info () at Test/QuickCheck/Property.hs:190
#61 0x0000000001375f50 in _rts_stgzucatchzuframe_ret () at rts/Exception.cmm:335
#62 0x00000000009bbe08 in s1TQX_info () at Test/QuickCheck/Property.hs:252
#63 0x00000000009b7670 in s1TIa_info () at Test/QuickCheck/Property.hs:216
...
#68 0x00000000009b7670 in s1TIa_info () at Test/QuickCheck/Property.hs:216
#69 0x00000000009b7c18 in s1TIJ_info () at Test/QuickCheck/Property.hs:207
#70 0x00000000009b7670 in s1TIa_info () at Test/QuickCheck/Property.hs:216
#71 0x00000000009b7670 in s1TIa_info () at Test/QuickCheck/Property.hs:216
#72 0x00000000009bff88 in QuickCheckzm2zi13zi2zmac90a2a0d9e0dd2c227d795a9d4d9de22a119c3781b679f3b245300e1b658c43_TestziQuickCheckziProperty_reduceRose1_info () at Test/QuickCheck/Property.hs:232
#73 0x00000000009e18a8 in s2eT1_info () at Test/QuickCheck/Test.hs:331
#74 0x0000000001375f50 in _rts_stgzucatchzuframe_ret () at rts/Exception.cmm:335
#75 0x00000000009e2380 in QuickCheckzm2zi13zi2zmac90a2a0d9e0dd2c227d795a9d4d9de22a119c3781b679f3b245300e1b658c43_TestziQuickCheckziTest_quickCheck4_info () at Test/QuickCheck/Test.hs:333
#76 0x00000000007479b0 in s4py_info () at Test/Framework/Providers/QuickCheck2.hs:114
#77 0x0000000000755cf8 in s2dc_info () at Test/Framework/Improving.hs:68
#78 0x0000000000762080 in r6ny_info () at Test/Framework/Runners/ThreadPool.hs:62
#79 0x0000000001375f50 in _rts_stgzucatchzuframe_ret () at rts/Exception.cmm:335
#80 0x000000000137c810 in _rts_stgzustopzuthread_ret ()
#81 0x000000000136571b in StgRunIsImplementedInAssembler () at rts/StgCRun.c:370
#82 0x000000000136241b in schedule (task=0x175aa00, initialCapability=<optimized out>) at rts/Schedule.c:467
#83 scheduleWaitThread (tso=<optimized out>, ret=ret@entry=0x0, pcap=pcap@entry=0x7fffffff5210) at rts/Schedule.c:2600
#84 0x000000000138b204 in rts_evalLazyIO (cap=cap@entry=0x7fffffff5210, p=p@entry=0x14122d0, ret=ret@entry=0x0) at rts/RtsAPI.c:530
#85 0x000000000135f35e in hs_main (argc=<optimized out>, argv=<optimized out>, main_closure=0x14122d0, rts_config=...) at rts/RtsMain.c:72
#86 0x0000000000455df4 in main ()
(gdb) 

Here we see the state of the stack around one second into the execution. Note that I have elided a good number (around 50) repeated CoArbitraryAll1 frames. There are four kinds of symbol names seen here:

  1. C functions provided by the runtime system (e.g. rts_evalLazyIO)
  2. C– functions provided by the runtime system (e.g. _rts_stgzuupdzuframe_ret)
  3. Haskell functions exported by modules (e.g. ghczmprim_GHCziClasses_zdfEqBoolzuzdczeze_info)
  4. Haskell functions internal to modules (e.g. s1TRr_info)

In cases (2) and (3) the names are derived from source program names via GHC’s Z encoding) symbol name mangling scheme. For instance,

mangled ghczmprim_GHCziClasses_zdfEqBoolzuzdczeze_info
demangled ghc-prim_GHC.Classes_$fEqBool_$c==_info

In principle gdb could be taught to perform this demangling on our behalf.

Aside from symbol names, the above backtrace also gives us (often more informative) source locations. However, it should be noted that this line information can be slightly misleading at times for reasons that we will describe below.

Surprises in debug information

As noted above, GHC backtraces can at times be slightly surprising. To see why, consider the simple program,

f :: [Int] -> Int
f = sum . map (* 42)

The code generated for this function (when compiled with -O) will inevitably contain a multiplication instruction and an addition instruction. However, which source location should these be attributed to 1? One might say f, or somewhere in Data.List.sum, or somewhere in foldl (which sum is defined in terms of). Moreover, these sets of options can grow to be quite large, particularly in cases where stream fusion is involved.

Unfortunately, the DWARF specification requires that GHC choose precisely one of these locations when producing debug information. At the moment GHC uses heuristics to choose from among the options, but these heuristics, like all heuristics, can sometimes produce less than helpful results. GHC can also emit an extended DWARF form which encodes the entire set of source locations. However, there is currently widely available tooling which can consume this information.

In addition to the above wrinkle there is another feature of GHC’s produced code that poses a challenge when producing debug information: tail calls. In a language lacking tail calls, a stack frame typically contains a pointer to the instruction following the function call that pushed the frame. This serves as the address to which execution will return after the callee finishes and is guaranteed to be in the same procedure as the call itself. For this reason, stack backtraces always reflect the history of a program’s execution. That is, a stack containing the frames f; g; h means:

  • f called g
  • g called h
  • h is currently executing

However, tail calls break this model. For instance, consider the Haskell function:

tail_caller :: [Int] -> Int
tail_caller xs = sum xs

sum :: [Int] -> Int
sum xs = foldl' (+) 0 xs

Without optimisation, the code generated for tail_caller will simply jump straight to the entry-point of sum; no stack entry will be left to mark the fact that sum was called by tail_caller. This, coupled with the source location ambiguity described above, can at times lead to slightly surprising backtraces. If you find a case that you think makes little sense, please do open a ticket. We are always looking for ways to improve the quality of the debug information produced by GHC.

Breakpoints

In addition to printing backtraces, we can also set breakpoints:

(gdb) break Test/Framework/Improving.hs:68
(gdb) cont
Continuing.

Breakpoint 1, s2dc_info () at Test/Framework/Improving.hs:68
68	Test/Framework/Improving.hs: No such file or directory.
(gdb) bt
#0  s2dc_info () at Test/Framework/Improving.hs:68
#1  0x0000000000762080 in r6ny_info () at Test/Framework/Runners/ThreadPool.hs:62
#2  0x0000000001375f50 in _rts_stgzucatchzuframe_ret () at rts/Exception.cmm:335
#3  0x000000000137c810 in _rts_stgzustopzuthread_ret ()
#4  0x000000000136571b in StgRunIsImplementedInAssembler () at rts/StgCRun.c:370
#5  0x000000000136241b in schedule (task=0x175aa00, initialCapability=<optimized out>) at rts/Schedule.c:467
#6  scheduleWaitThread (tso=<optimized out>, ret=ret@entry=0x0, pcap=pcap@entry=0x7fffffff5210) at rts/Schedule.c:2600
#7  0x000000000138b204 in rts_evalLazyIO (cap=cap@entry=0x7fffffff5210, p=p@entry=0x14122d0, ret=ret@entry=0x0) at rts/RtsAPI.c:530
#8  0x000000000135f35e in hs_main (argc=<optimized out>, argv=<optimized out>, main_closure=0x14122d0, rts_config=...) at rts/RtsMain.c:72
#9  0x0000000000455df4 in main ()

However, at the moment this is little more than a parlor trick since our debug information does not encode information about in-scope bindings (fixing this is a significant project in its own right and is not currently planned).

In the next post we will see how we can use GHC’s native unwinding support to gather stack traces from within Haskell programs.


  1. The very question of what it means to “attribute” a machine operation to a source location is itself a tricky one to precisely define in a lazy language like Haskell. Finding such a definition was a central part of Peter Wortmann’s dissertation. I would encourage anyone interested to peruse Chapter 4 of this very readable work.↩︎

]]>
Sat, 04 Apr 2020 00:00:00 UThttp://haskell.org/ghc/blog/20200404-dwarf-2.htmlghc-devs