| CARVIEW |
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:
- Juspay
- QBayLogic
- Channable
- Haskell Foundation
- Serokell
- Well-Typed
- Tweag
- Dotcom-Monitor
- LoadView
- Web Hosting Buddy
- Find My Electric
- Standard Chartered
- UpCloud
- Mercury
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.
]]>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
SPECIALISEpragma now allows use of type application syntax - The
SPECIALISEpragma 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
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
RequiredTypeArgumentscan now be used in more contextsGreatly 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 javascriptusage from within the browserA new primop
annotateStack#for pushing arbitrary data onto the call stack for later extraction when decoding stack traces-Wincomplete-record-selectorsis now part of-Wall. Libraries compiled with-Werrormay 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:
- Juspay
- QBayLogic
- Channable
- Haskell Foundation
- Serokell
- Well-Typed
- Tweag
- Dotcom-Monitor
- LoadView
- Web Hosting Buddy
- Find My Electric
- Standard Chartered
- UpCloud
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.
]]>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:
- Juspay
- QBayLogic
- Channable
- Haskell Foundation
- Serokell
- Well-Typed
- Tweag
- Dotcom-Monitor
- LoadView
- Web Hosting Buddy
- Find My Electric
- Standard Chartered
- UpCloud
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.
]]>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
SPECIALISEpragma now allows use of type application syntax - The
SPECIALISEpragma 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
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
RequiredTypeArgumentscan now be used in more contextsSSE/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:
- Juspay
- QBayLogic
- Channable
- Haskell Foundation
- Serokell
- Well-Typed
- Tweag
- Dotcom-Monitor
- LoadView
- Web Hosting Buddy
- Find My Electric
- Standard Chartered
- UpCloud
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.
]]>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:
- Juspay
- QBayLogic
- Channable
- Haskell Foundation
- Serokell
- Well-Typed
- Tweag
- Dotcom-Monitor
- LoadView
- Web Hosting Buddy
- Find My Electric
- Standard Chartered
- UpCloud
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.
]]>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
SPECIALISEpragma now allows use of type application syntax - The
SPECIALISEpragma 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
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
RequiredTypeArgumentscan now be used in more contextsSSE/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.
]]>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
SPECIALISEpragma now allows use of type application syntax - The
SPECIALISEpragma 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
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
RequiredTypeArgumentscan now be used in more contextsSSE/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.
]]>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
SPECIALISEpragma now allows use of type application syntax - The
SPECIALISEpragma 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
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
RequiredTypeArgmentscan now be used in more contextsSSE/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.
]]>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.
]]>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
SPECIALISEpragma now allows use of type application syntaxThe
SPECIALISEpragma 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
LinearTypesis enabled.RequiredTypeArgmentscan now be used in more contextsSSE/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.
]]>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.
]]>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
SPECIALISEpragma now allows use of type application syntaxThe
SPECIALISEpragma can be used to specialise for expression arguments as well as type arguments.Specialisation is now considerably more reliable in the presence of
newtypesthe 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.
]]>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
naturalAndNotreturning 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.
]]>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
Backtraceconstructor 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.
]]>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.
]]>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.
]]>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!
]]>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.
]]>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.
]]>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-evaland-fspec-eval-dictfunto 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
]]>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.
]]>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
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
HasFieldclass 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-determinismflag, 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 detailsGHC 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.
]]>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
filepathsubmodule to avoid a misbehavior ofsplitFileNameunder Windows.Update the
unixsubmodule to fix a compilation issue onmuslplatformsFix 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
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
HasFieldclass 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-determinismflag, 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 detailsGHC 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.
]]>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
HasFieldclass 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-determinismflag, 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 detailsGHC 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.
]]>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
HasFieldclass 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-determinismflag, 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 detailsGHC 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.
]]>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
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
HasFieldclass 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-determinismflag, 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 detailsGHC 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.
]]>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
]]>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.
]]>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.
]]>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
GHC2024language edition, building uponGHC2021with 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
letandwherebindingsThe 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.
]]>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
GHC2024language edition, building uponGHC2021with 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
letandwherebindingsThe 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.
]]>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
processlibrary 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 theprocessto avoid the issue. - Fixing a bug resulting in the distributed
hsc2hswrapper using flags from the compiler build environment (#24050). - Disabling the
-fasm-shortcuttingoptimisation with-O2as it is known to result in unsoundess and incorrect runtime results in some cases (#24507). - Ensuring we take
LDFLAGSinto 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
]]>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
GHC2024language edition, building uponGHC2021with 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
letandwherebindingsThe 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.
]]>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
GHC2024language edition, building uponGHC2021with 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
letandwherebindingsThe 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.
]]>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
GHC2024language edition, building uponGHC2021with 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
letandwherebindingsThe 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.
]]>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 fix for a bug where certain warnings flags were not recognised (#24071)
- Fixes for bugs in the renamer and typechecker (#24084, #24134, #24279, #24083)
- Fixes for bugs in the simplifier and code generator (#24160, #24242, #23628, #23659, #24160, #23862, #24295, #24370)
- Fixes for some memory leaks in GHCi (#24107, #24118)
- Improvements to error messages (#21097, #16996, #11050, #24196, #24275, #23768, #23784, #23778)
- A fix for a recompilation checking bug where GHC may miss changes in transitive dependencies when deciding to relink a program (#23724).
- 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
]]>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
]]>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-sectionson Windows. - Enabling
-split-sectionsfor 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
]]>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
TypeAbstractionslanguage extension, allowing types to be bound in type declarations TypeAbstractions.Support for the
ExtendedLiteralsextension, providing syntax for non-word-sized numeric literals in the surface language extended-literalsImproved rewrite rule matching behavior, allowing limited matching of higher-order patterns
Better support for user-defined warnings by way of the
WARNINGpragma warningsThe introduction of the new
GHC.TypeError.Unsatisfiableconstraint, allowing more predictable user-defined type errors unsatisfiableImplementation of the export deprecation proposal, allowing module exports to be marked with
DEPRECATEpragmas deprecated-exportsThe addition of build semaphore support for parallel compilation; with coming support in
cabal-installthis will allow better use of parallelism in multi-package builds jsemMore efficient representation of info table provenance information, reducing binary sizes by over 50% in some cases when
-finfo-table-mapis 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
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
TypeAbstractionslanguage extension, allowing types to be bound in type declarations TypeAbstractions.Support for the
ExtendedLiteralsextension, providing syntax for non-word-sized numeric literals in the surface language extended-literalsImproved rewrite rule matching behavior, allowing limited matching of higher-order patterns
Better support for user-defined warnings by way of the
WARNINGpragma warningsThe introduction of the new
GHC.TypeError.Unsatisfiableconstraint, allowing more predictable user-defined type errors unsatisfiableImplementation of the export deprecation proposal, allowing module exports to be marked with
DEPRECATEpragmas deprecated-exportsThe addition of build semaphore support for parallel compilation; with coming support in
cabal-installthis will allow better use of parallelism in multi-package builds jsemMore efficient representation of info table provenance information, reducing binary sizes by over 50% in some cases when
-finfo-table-mapis 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
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-specialisationflag. For more details see #23469 as well as #23109, #21229, #23445.Improve compile time and code generation performance when
-finfo-table-mapis 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
]]>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
TypeAbstractionslanguage extension, allowing types to be bound in type declarations.Support for the
ExtendedLiteralsextension, providing more consistent support for non-word-sized numeric literals in the surface languageImproved rewrite rule matching behavior, allowing limited matching of higher-order patterns
Better support for user-defined warnings by way of the
WARNINGpragmaThe introduction of the new
GHC.TypeError.Unsatisfiableconstraint, allowing more predictable user-defined type errorsImplementation of the export deprecation proposal, allowing module exports to be marked with
DEPRECATEpragmasThe 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-mapis 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.
]]>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_setclocksymbol 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
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
TypeAbstractionslanguage extension, allowing types to be bound in type declarations.Support for the
ExtendedLiteralsextension, providing more consistent support for non-word-sized numeric literals in the surface languageImproved rewrite rule matching behavior, allowing limited matching of higher-order patterns
Better support for user-defined warnings by way of the
WARNINGpragmaThe introduction of the new
GHC.TypeError.Unsatisfiableconstraint, allowing more predictable user-defined type errorsImplementation of the export deprecation proposal, allowing module exports to be marked with
DEPRECATEpragmasThe 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-mapis 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.
]]>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
TypeApplicationslanguage extension, allowing types to be bound in type declarations.Support for the
ExtendedLiteralsextension, providing more consistent support for non-word-sized numeric literals in the surface languageImproved rewrite rule matching behavior, allowing limited matching of higher-order patterns
Better support for user-defined warnings by way of the
WARNINGpragmaThe introduction of the new
GHC.TypeError.Unsatisfiableconstraint, allowing more predictable user-defined type errorsImplementation of the export deprecation proposal, allowing module exports to be marked with
DEPRECATEpragmasThe 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-mapis 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.
]]>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
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
TypeAbstractionslanguage extension, allowing types to be bound in type declarations.Support for the
ExtendedLiteralsextension, providing syntax for non-word-sized numeric literals in the surface languageImproved rewrite rule matching behavior, allowing limited matching of higher-order patterns
Better support for user-defined warnings by way of the
WARNINGpragmaThe introduction of the new
GHC.TypeError.Unsatisfiableconstraint, allowing more predictable user-defined type errorsImplementation of the export deprecation proposal, allowing module exports to be marked with
DEPRECATEpragmasThe addition of build semaphore support for parallel compilation; with coming support in
cabal-installthis will allow better use of parallelism in multi-package buildsMore efficient representation of info table provenance information, reducing binary sizes by over 50% in some cases when
-finfo-table-mapis 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.
]]>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
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
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-tarballsto a version which doesn’t use the reservedx18register 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
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
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
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
setKeepCafssymbol 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
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
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-tarballsto a version which doesn’t use the reservedx18register 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
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
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
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-diagnosticsflag (#22391) - Fixes to several subtle compiler panics. (#22491, #22416, #22549, #22475, #22039)
- Add necessary write barriers to
IORefoperations, 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
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
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
processlibrary where file handles specified asNoStreamwould 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
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
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 standardArray#.Introduction of the
\casessyntax 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
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 acabal-installbuild plan; seegenerate_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
- Choose a build plan appropriate for the bootstrap GHC version, such as
- In the build environment:
- Provision the
bootstrap-sourcestarball generated above.
- Provision the
- 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>
- Build Hadrian using the bootstrap script:
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 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
stage0compiler is the bootstrap compiler: a user-provided executable which will be used to compile GHC. The bootstrap compiler is chosen via theGHCvariable passed to theconfigurescript. - The
stage1compiler is the compiler built using thestage0compiler; 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
stage2compiler is the compiler built using thestage1compiler; it runs on the target platform. Thestage2compiler 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
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
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.hsfor arguments passed to GHC when compiling Haskell modulescfor arguments passed to the C compilercppfor arguments passed to the C++ compilerlinkfor arguments passed during linkingdepsfor arguments to aghc -Mcommand, 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.
]]>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
DeepSubsumptionlanguage 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
Haskell2010andHaskell98languages but disabled with theGHC2021language 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 aswithForeignPtr. These regressions are mostly small, but can be larger in certain edge cases. Judicious use ofunsafeWithForeignPtrwhen 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
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 standardArray#.Introduction of the
\casessyntax 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
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 standardArray#.Introduction of the
\casessyntax from GHC proposal 0302A 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
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:
A fix to a critical linking bug on Windows causing the 9.2.2 release to be unusable (#21196).
Numerous bug fixes for regressions and other issues in the typechecker (#2147, #21515, #20582, #20820, #21130, #21479).
Correctness bugs in the code generator and compiler backends (#21396, #20959, #21465).
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.
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
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 standardArray#.Introduction of the
\casessyntax from GHC proposal 0302A 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
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.
]]>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 standardArray#.Introduction of the
\casessyntax from GHC proposal 0302A 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
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-unwindflag, 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
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:
First-class support for Apple M1 hardware using GHC’s LLVM ARM backend.
Fix a number of incorrect rewrite rules for
fromInteger(#19345, #20066).Fix a number of runtime system and GC bugs which typically manifested in crashes (#19417, #19297, #19645, #19667, #18033, #20132, #19715, #20399, #20414, #20649, #19147, #20051, #20093)
Fixes for various compiler performance and memory usage issues (#20134, #13586, #20509, #19668, #19996, #19471)
Improvements and bug fixes for the code generator and optimiser (#18638, #19581, #19700, #19996, #19181, #19822)
Fixes for typechecker bugs (#19410 , #19191, #19522, #19400, #19849)
Bug fixes for the frontend and parser (#19397, #19838, #19518, #19777, #20242, #19786)
Emit warnings if Unicode Bidirectional Formatting characters are found in the source, possibly misleading code reviewers (#20263, vulnerability website).
Many packaging related fixes, including versioned
ghc-pkgexecutables (#20087), and actually distributing GHC versions linked against thenativebig integer backend (#18967, #19953) on both Windows and Alpine Linux. Some previous releases were still linked against theGMPlibrary due to a misconfiguration of the builders.A significant refactoring of
processfixing numerous bugs mostly on Apple platforms (#19994, process refactoring).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.
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.
]]>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
RecordDotSyntaxandNoFieldSelectorslanguage extensions, as well as Support forDuplicateRecordFieldswithPatternSynonyms.Introduction of the new
GHC2021language extension set, giving users convenient access to a larger set of language extensions which have been long considered stable.Merging of
ghc-exactprintinto the GHC tree, providing infrastructure for source-to-source program rewriting out-of-the-box.Introduction of a
BoxedRepRuntimeRep, allowing for polymorphism over levity of boxed objects (#17526)Implementation of the
UnliftedDataTypesextension, allowing users to define types which do not admit lazy evaluation (proposal)The new [
-hiprofiling][] mechanism which provides significantly improved insight into thunk leaks.Support for the
ghc-debugout-of-process heap inspection library ghc-debugSignificant 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
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.
]]>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-darwindue to an incorrect foreign import inhaskeline. 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-darwinbackend (#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-pkgexecutables (#20087), and actually distributing GHC versions linked against theinteger-simplebig integer backend (#18967, #19953) on both Windows and Alpine Linux. Previous releases were still linked against theGMPlibrary due to a misconfiguration of the builders.A significant refactoring of
processfixing 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.
]]>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
RecordDotSyntaxandNoFieldSelectorslanguage extensions, as well as Support forDuplicateRecordFieldswithPatternSynonyms.Introduction of the new
GHC2021language extension set, giving users convenient access to a larger set of language extensions which have been long considered stable.Merge of
ghc-exactprintinto the GHC tree, providing infrastructure for source-to-source program rewriting out-of-the-box.Introduction of a
BoxedRepRuntimeRep, allowing for polymorphism over levity of boxed objects (#17526)Implementation of the
UnliftedDataTypesextension, 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-debugout-of-process heap inspection library ghc-debugSupport 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
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.:
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 thatccalldoes not support variadic functions, this fact is not well-known by users. - the type provided by the user may be wrong (e.g. using
Intinstead ofCInt)
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:
To compile this, GHC will construct a C source file which #include’s
stdio.h. and defines a stub function which performs the call:
This approach brings a few advantages:
capiimports 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.
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):
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 arrHere 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:
We prefer to write:
withFile:
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:
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 arrAt 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:
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 nAfter 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:
since worker/wrapper may produce results of arbitrary
RuntimeRepwe must generalize the type ofwith:use
State#tokens to enforce execution ordering:teaching the simplifier to “push” strict contexts (e.g.
case) intowith#applications. For instance, transforminto
This transformation, which we call “strict context pushing” (SCP), is similar to a transform already performed on
runRW#applications (#15127). In this case ofwith#, 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:
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) s1As 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) s1While 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 theRuntimeRepof 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#:
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
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)
-> bWhat 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 fptrWhile 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:
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 fptrIn 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.
To avoid cluttering the code too much, we are playing a bit fast-and-loose with the
IOnewtype here. For instance, we treatpeekas a function of typeState# RealWorld -> (# State# RealWorld, a #)(i.e. the representation ofIO a)) instead ofIO a. We will continue this pragmatic abuse of notation below.↩︎
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.
]]>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
RecordDotSyntaxandNoFieldSelectorslanguage extensions, as well as Support forDuplicateRecordFieldswithPatternSynonyms.Introduction of the new
GHC2021language extension set, giving users convenient access to a larger set of language extensions which have been long considered stable.Merge of
ghc-exactprintinto the GHC tree, providing infrastructure for source-to-source program rewriting out-of-the-box.Introduction of a
BoxedRepRuntimeRep, allowing for polymorphism over levity of boxed objects (#17526)Implementation of the
UnliftedDataTypesextension, allowing users to define types which do not admit lazy evaluationThe new -hi profiling mechanism which provides significantly improved insight into thunk leaks.
Support for the
ghc-debugout-of-process heap inspection librarySupport 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!
]]>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
RecordDotSyntaxandNoFieldSelectorslanguage extensions, as well as Support forDuplicateRecordFieldswithPatternSynonyms.Introduction of the new
GHC2021language extension set, giving users convenient access to a larger set of language extensions which have been long considered stable.Merge of
ghc-exactprintinto the GHC tree, providing infrastructure for source-to-source program rewriting out-of-the-box.Introduction of a
BoxedRepRuntimeRep, allowing for polymorphism over levity of boxed objects (#17526)Implementation of the
UnliftedDataTypesextension, allowing users to define types which do not admit lazy evaluationThe new -hi profiling mechanism which provides significantly improved insight into thunk leaks.
Support for the
ghc-debugout-of-process heap inspection librarySupport 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!
]]>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:
- the ability to generate code in the ARM instruction set
- support for Darwin’s ARM application binary interface (ABI)
- 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
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,
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:
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 ceteraThe 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.
]]>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.
]]>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
LinearTypeslanguage 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
QualifiedDoextension, allowing more convenient overloading ofdosyntax.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.
]]>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
LinearTypeslanguage 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
QualifiedDoextension, allowing more convenient overloading ofdosyntax.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.
]]>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.
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-gcare 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.
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)
configurenow accepts a--enable-numaflag to enable/disablenumactlsupport 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.
]]>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:
- 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. - 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.
- 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:
- a lack of documentation and a few usability papercuts have limited adoption to a small set of developers.
- the lack of integration with GHC’s own continuous integration infrastructure meant that testing of GHC snapshots had to be performed manually
- 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:
Testing against GHC releases tests the patch-set, giving us (some) assurance that the patches themselves are correct.
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-timingsflag. 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.hackageresponsible 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
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.
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
binutilshave 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):
Next we can fetch and install the GHC 8.10.1 ARMv7 binary distribution for Debian 9:
$ wget https://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 installDepending 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.
]]>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
gdband 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
perfutility 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, andgdb - 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
PUSHandPOPinstructions, 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:
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# + 4This 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:
- Adding syntax in C– to encode local variable information
- Producing such syntax in the STG-to-C– code generator
- Adding information in Core to propagate value provenance, as discussed above
- 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.
]]>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
gdband 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
perfutility 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.
| 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.
| 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.
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
gdband 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
perfutility 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
SIGQUITsignal - via the
GHC.ExecutionStackinterface inbase
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
although this is an outstanding task.
This could be used in a number of ways:
when throwing an exception, one could capture the current stack for use in diagnostics output.
with
getThreadStackTracea monitoring library likeekgmight 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 excKeep 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 aOf 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 = throwIOWithCallStackFinally, new “catch” operations could be introduced providing the handler access to the exception’s stack:
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.
The unfortunate choice of the
SIGQUITsignal 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 thatSIGQUITshould 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.↩︎
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
gdband 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
perfutility 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:
- C functions provided by the runtime system (e.g.
rts_evalLazyIO) - C– functions provided by the runtime system
(e.g.
_rts_stgzuupdzuframe_ret) - Haskell functions exported by modules
(e.g.
ghczmprim_GHCziClasses_zdfEqBoolzuzdczeze_info) - 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,
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:
fcalledggcalledhhis currently executing
However, tail calls break this model. For instance, consider the Haskell function:
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.
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.↩︎
Ben Gamari - 2020-04-03
This post is the first 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
gdband 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
perfutility 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.
DWARF debugging information
For several years now GHC has had support for producing DWARF debugging information. DWARF is a widely-used format (used by Linux and several BSDs) for representing debug information (typically embedded in an executable) for consumption by runtime systems, profiling, and debugging tools. It allows representation of a variety of information:
line information mapping instructions back to their location in the source program (e.g. the instruction at address
xoriginated frommyprogram.cline 42).unwind information allowing call chains to be reconstructed from the runtime state of the execution stack (e.g. the program is currently executing
f, which was called fromg, which was called fromh, …)type information, allowing debugging tools to reconstruct the structure and identity of values from the runtime state of the program (e.g. when the program is executing the instruction at address
x, the value sitting in the$raxregister is a pointer to aFoobarobject.
Collectively, this information is what allows debuggers (e.g. gdb) and
profiling tools (e.g. perf) to do what they do.
The effort to add DWARF support to GHC started with Peter Wortmann’s dissertation work which introduced the ability for GHC to emit basic line and unwind information in its executables. This support has matured considerably over the past few years and should finally be ready for use with GHC 8.10.
There are a few potential use-cases for DWARF information:
Use in native debugging tools (e.g.
gdb)Dumping runtime call stacks to the console using the
SIGQUITsignal; this is particularly useful in productionComputing runtime call stacks from within the program (using the
GHC.ExecutionStackinterface inbase)Statistical profiling using tools like perf.
Capturing call-stacks in exceptions for reporting to the user
We will discuss all of these in this series of blog posts. The rest of this first post will examine how to compile a DWARF-enabled binary.
First steps
As of GHC 8.10.2, GHC HQ will provide DWARF-enabled binary distributions for Debian 9, Debian 10, and Fedora 27 (as of 8.10.1 only Debian 9 is provided). These binary distributions differ in two respects from the non-DWARF distributions:
- all provided libraries (e.g.
base,filepath,unix, etc.) are built with debug information. - the runtime system is built with a dependency on the
libdwlibrary (provided by theelfutilspackage).
Like other compilers, debug information support under GHC is enabled
with the -g flag. This flag can be passed a numeric “debug level”,
which determines the detail (and, consequently, size) of the debug
information that is produced. These levels are described in the GHC
user
guide.
When using native debug information we must keep in mind that all code linked into an executable (e.g. native libraries, Haskell libraries, and the code of the executable itself) must be built with debug information. Failure to ensure this will result in truncated backtraces.
To build a package with native debug information we can use
cabal-install’s --enable-debug-info flag (or, below, its equivalent
key in cabal.project). Here, we will use the vector testsuite as a
non-trivial example:
$ git clone https://github.com/haskell/vector
$ cd vector
$ cat >>cabal.project.local <<EOF
allow-newer: base
package vector
tests: True
package *
debug-info: 2
EOF
$ cabal new-build vector-tests-O0
For the sake of demonstration we built the vector-tests-O0 testsuite
(which builds vector’s tests without optimisation) since this provides
slightly more interesting stacktraces. We chose debug level 2 as we will
not be using the GHC-specific debug information emitted by debug level
3.
At this point we have a DWARF-annotated binary. This binary is functionally identical to a non-annotated build (apart from containing quite a few more bits, weighing in at over 150 megabytes). Most importantly, no optimizations were inhibited by enabling debug information.
In the next post we will begin to see what this extra 100 megabytes of debug information gives us.
]]>bgamari - 2020-03-24
The GHC team is happy to announce the availability of GHC 8.10.1. Source and binary distributions are available at the usual place.
GHC 8.10.1 brings a number of new features including:
The new
UnliftedNewtypesextension allowing newtypes around unlifted types.The new
StandaloneKindSignaturesextension allows users to give top-level kind signatures to type, type family, and class declarations.A new warning,
-Wderiving-defaults, to draw attention to ambiguous deriving clausesA number of improvements in code generation, including a new loop analyzer, optimisation of
memset,memcpyand array allocation, more aggressive specialisation, and pointer tagging for larger data types.A new GHCi command,
:instances, for listing the class instances available for a type.An upgraded Windows toolchain lifting the
MAX_PATHlimitationA new, low-latency garbage collector.
Improved support profiling, including support for sending profiler samples to the eventlog, allowing correlation between the profile and other program events
A full accounting of the changes of this release can be found in the release notes. A guide for migrating existing code to GHC 8.10 can be found in the release migration notes.
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 8.10.2 with the
resolution of #17418.
Cheers,
- Ben