The GHC developers are very pleased to announce the release of GHC 9.12.4. Binary distributions, source distributions, and documentation are available at downloads.haskell.org and via GHCup.
GHC 9.12.4 is a bug-fix release fixing many issues of a variety of severities and scopes, including:
Fixed a critical code generation regression where sub-word division produced incorrect results (#26711, #26668), similar to the bug fixed in 9.12.2
Numerous fixes for register allocation bugs, preventing data corruption when spilling and reloading registers (#26411, #26526, #26537, #26542, #26550)
Fixes for several compiler crashes, including issues with CSE (#25468), and the simplifier(#26681), implicit parameters (#26451), and the type-class specialiser (#26682)
Fixed cast worker/wrapper incorrectly firing on INLINE functions (#26903)
Fixed LLVM backend miscompilation of bit manipulation operations (#20645, #26065, #26109)
Fixed associated type family and data family instance changes not triggering recompilation (#26183, #26705)
Fixed negative type literals causing the compiler to hang (#26861)
Improvements to determinism of compiler output (#26846, #26858)
Fixes for eventlog shutdown deadlocks (#26573) and lost wakeups in the RTS (#26324)
Fixed split sections support on Windows (#26696, #26494) and the LLVM backend (#26770)
Fixes for the bytecode compiler, PPC native code generator, and Wasm backend
The runtime linker now supports COMMON symbols (#6107)
Improved backtrace support: backtraces for error exceptions are now
evaluated at throw time
NamedDefaults now correctly requires the class to be standard or have an
in-scope default declaration, and handles poly-kinded classes (#25775, #25778, #25882)
… and many more
A full accounting of these fixes can be found in the release notes. As always, GHC’s release status, including planned future releases, can be found on the GHC Wiki status.
GHC development is sponsored by:
We would like to thank these sponsors and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release.
As always, do give this release a try and open a ticket if you see anything amiss.
]]>The GHC developers are very pleased to announce the availability of the release candidate for GHC 9.12.4. Binary distributions, source distributions, and documentation are available at downloads.haskell.org and via GHCup.
GHC 9.12.4 is a bug-fix release fixing many issues of a variety of severities and scopes, including:
error exceptions are now
evaluated at throw timeNamedDefaults now correctly requires the class to be standard or have an
in-scope default declaration, and handles poly-kinded classes (#25775, #25778, #25882)A full accounting of these fixes can be found in the
release notes. As always, GHC’s release status, including planned future releases, can be found on the GHC Wiki status.
This release candidate will have a two-week testing period. If all goes well the final release will be available the week of 26 March 2026.
GHC development is sponsored by:
We would like to thank these sponsors and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release.
As always, do give this release a try and open a ticket if you see anything amiss.
]]>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:
A full accounting of these fixes can be found in the release notes. As always, GHC’s release status, including planned future releases, can be found on the GHC Wiki status.
GHC development is sponsored by:
We would like to thank these sponsors and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release.
As always, do give this release a try and open a ticket if you see anything amiss.
]]>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:
SPECIALISE pragma now allows use of type application syntaxSPECIALISE pragma can be used to specialise for expression arguments
as well as type arguments.newtypesSignificant GHCi improvements including:
Implementation of the Explicit Level Imports proposal
RequiredTypeArguments can now be used in more contexts
Greatly improved SSE/AVX2 support in the x86 native code generator backend
Initial native code generator support for LoongArch
The WebAssembly backend now supports evaluation via the interpreter, allowing
GHCi and TemplateHaskell evaluation, including foreign import javascript
usage from within the browser
A new primop annotateStack# for pushing arbitrary data onto the call stack
for later extraction when decoding stack traces
-Wincomplete-record-selectors is now part of -Wall. Libraries compiled
with -Werror may need adjustment.
A major update of the Windows toolchain
Improved compatibility with macOS Tahoe
… and many more
A full accounting of changes can be found in the release notes. See the migration guide for guidance on migrating programs to this release.
Note that while this release makes many improvements in the specialisation
optimisation, polymorphic specialisation remains disabled by default in the
release due to concern over regressions of the sort identified in
#26329. Users needing more aggressive specialisation can explicitly
enable this feature with the -fpolymorphic-specialisation flag. Depending
upon our experience with 9.14.1, we may enable this feature by default in a
later minor release.
GHC development is sponsored by:
We would like to thank these sponsors and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprises this release.
As always, do give this release a try and open a ticket if you see anything amiss.
]]>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
GHC development is sponsored by:
We would like to that these sponsors and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release.
As always, do give this release a try and open a ticket if you see anything amiss.
]]>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:
GHC 9.14 will bring a number of new features and improvements, including:
Significant improvements in specialisation:
SPECIALISE pragma now allows use of type application syntaxSPECIALISE pragma can be used to specialise for expression arguments
as well as type arguments.newtypesSignificant GHCi improvements including:
Implementation of the Explicit Level Imports proposal
RequiredTypeArguments can now be used in more contexts
SSE/AVX2 support in the x86 native code generator backend
A major update of the Windows toolchain and improved compatibility with macOS Tahoe
… and many more
A full accounting of changes can be found in the release notes. Given the many specialisation improvements and their potential for regression, we would very much appreciate testing and performance characterisation on downstream workloads.
Note that while this release makes many improvements in the specialisation
optimisation, polymorphic specialisation will remain disabled by default in the
final release due to concern over regressions of the sort identified in
#26329. Users needing more aggressive specialisation can explicitly
enable this feature with the -fpolymorphic-specialisation flag. Depending
upon our experience with 9.14.1, we may enable this feature by default in a
later minor release.
GHC development is sponsored by:
We would like to that these sponsors and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release.
As always, do give this release a try and open a ticket if you see anything amiss.
]]>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
GHC development is sponsored by:
We would like to that these sponsors and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release.
As always, do give this release a try and open a ticket if you see anything amiss.
]]>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:
GHC 9.14 will bring a number of new features and improvements, including:
Significant improvements in specialisation:
SPECIALISE pragma now allows use of type application syntaxSPECIALISE pragma can be used to specialise for expression arguments
as well as type arguments.newtypesSignificant GHCi improvements including:
Implementation of the Explicit Level Imports proposal
RequiredTypeArguments can now be used in more contexts
SSE/AVX2 support in the x86 native code generator backend
A major update of the Windows toolchain and improved compatibility with macOS Tahoe
… and many more
A full accounting of changes can be found in the release notes. Given the many specialisation improvements and their potential for regression, we would very much appreciate testing and performance characterisation on downstream workloads.
Note that while this release makes many improvements in the specialisation
optimisation, polymorphic specialisation will remain disabled by default in the
final release due to concern over regressions of the sort identified in
#26329. Users needing more aggressive specialisation can explicitly
enable this feature with the -fpolymorphic-specialisation flag. Depending
upon our experience with 9.14.1, we may enable this feature by default in a
later minor release.
We would like to thank the Zw3rk stake pool, Well-Typed, Mercury, Channable, Tweag I/O, Serokell, SimSpace, the Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work have made the Haskell ecosystem what it is today.
As always, do give this release a try and open a ticket if you see anything amiss.
]]>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:
SPECIALISE pragma now allows use of type application syntaxSPECIALISE pragma can be used to specialise for expression arguments
as well as type arguments.newtypesSignificant GHCi improvements including:
Implementation of the Explicit Level Imports proposal
RequiredTypeArguments can now be used in more contexts
SSE/AVX2 support in the x86 native code generator backend
A major update of the Windows toolchain and improved compatibility with macOS Tahoe
… and many more
A full accounting of changes can be found in the release notes. Given the many specialisation improvements and their potential for regression, we would very much appreciate testing and performance characterisation on downstream workloads.
Note that while this release makes many improvements in the specialisation
optimisation, polymorphic specialisation will remain disabled by default in the
final release due to concern over regressions of the sort identified in
#26329. Users needing more aggressive specialisation can explicitly
enable this feature with the -fpolymorphic-specialisation flag. Depending
upon our experience with 9.14.1, we may enable this feature by default in a
later minor release.
This is the first and hopefully last release candidate prerelease of 9.14.1. This comes later than expected in part due to work on resolving a regression in macOS 26 (#26166) which threatened the usability of the release. This prerelease includes a fix to this regression; naturally, please open a ticket if you encounter any trouble when using this release on macOS Tahoe or recent XCode releases. We expect that this fix will be backported to GHC 9.12 and 9.10 in the coming months.
We would like to thank the Zw3rk stake pool, Well-Typed, Mercury, Channable, Tweag I/O, Serokell, SimSpace, the Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work have made the Haskell ecosystem what it is today.
As always, do give this release a try and open a ticket if you see anything amiss.
]]>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:
SPECIALISE pragma now allows use of type application syntaxSPECIALISE pragma can be used to specialise for expression arguments
as well as type arguments.newtypesSignificant improvements GHCi including:
Implementation of the Explicit Level Imports proposal
RequiredTypeArgments can now be used in more contexts
SSE/AVX2 support in the x86 native code generator backend
A major update of the Windows toolchain
… and many more
A full accounting of changes can be found in the release notes. Given the many specialisation improvements and their potential for regression, we would very much appreciate testing and performance characterisation on downstream workloads.
Note that while this release makes many improvements in the specialisation
optimisation, polymorphic specialisation will remain disabled by default in the
final release due to concern over regressions of the sort identified in
#26329. Users needing more aggressive specialisation can explicitly
enable this feature with the -fpolymorphic-specialisation flag. Depending
upon our experience with 9.14.1, we may enable this feature by default in a
later minor release.
This is the third alpha release of 9.14.1. This comes later than expected in part due to work on a resolving a regression in the macOS 26 (#26166) which threatened the usability of the release. While a complete fix for this issue is not present in this alpha, we have done enough work to have confidence that it will be in finished for the release candidate which we expect should come the week of 27 October.
We would like to thank the Zw3rk stake pool, Well-Typed, Mercury, Channable, Tweag I/O, Serokell, SimSpace, the Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work have made the Haskell ecosystem what it is today.
As always, do give this release a try and open a ticket if you see anything amiss.
]]>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.
]]>The GHC developers are very pleased to announce the availability of the second alpha prerelease of GHC 9.14.1. Binary distributions, source distributions, and documentation are available at downloads.haskell.org.
GHC 9.14 will bring a number of new features and improvements, including:
Significant improvements in specialisation:
The SPECIALISE pragma now allows use of type application syntax
The SPECIALISE pragma can be used to specialise for expression arguments
as well as type arguments.
Specialisation is now considerably more reliable in the presence of
newtypes
Significant improvements in the GHCi debugger
Record fields can be defined to be non-linear when LinearTypes is enabled.
RequiredTypeArgments can now be used in more contexts
SSE/AVX2 support in the x86 native code generator backend
A major update of the Windows toolchain
… and many more
A full accounting of changes can be found in the release notes. Given the many specialisation improvements and their potential for regression, we would very much appreciate testing and performance characterisation on downstream workloads.
Observant readers of these prerelease announcements will note that polymorphic
specialisation has been dropped from alpha 2. This measure was taken out of an
abundance of caution after finding a miscompilation during testing of alpha 1.
While this bug will be fixed in the next alpha, we expect to keep polymorphic
specialisation disabled by default in the final release. Users needing more
aggressive specialisation can explicitly enable this feature with the
-fpolymorphic-specialisation flag. Depending upon our experience with 9.14.1,
we may enable this feature by default in a later minor release.
This is the second of three expected alpha prereleases. We expect the next (third) alpha will come 23 Sept. 2025, with the release candidate coming 7 Oct. 2025.
We would like to thank the Zw3rk stake pool, Well-Typed, Mercury, Channable, Tweag I/O, Serokell, SimSpace, the Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work have made the Haskell ecosystem what it is today.
As always, do give this release a try and open a ticket if you see anything amiss.
]]>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:
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.
]]>The GHC developers are very pleased to announce the availability of the first alpha prerelease of GHC 9.14.1. Binary distributions, source distributions, and documentation are available at downloads.haskell.org.
GHC 9.14 will bring a number of new features and improvements, including:
Significant improvements in specialisation:
The SPECIALISE pragma now allows use of type application syntax
The SPECIALISE pragma can be used to specialise for expression arguments
as well as type arguments.
Specialisation is now considerably more reliable in the presence of
newtypes
the specialiser is now able to produce specialisations with polymorphic typeclass constraints, considerably broadening its scope.
Significant improvements in the GHCi debugger
Record fields can be defined to be non-linear when LinearTypes is enabled.
RequiredTypeArgments can now be used in more contexts
SSE/AVX support in the x86 native code generator backend
A major update of the Windows toolchain
… and many more
A full accounting of changes can be found in the release notes. Given the many specialisation improvements and their potential for regression, we would very much appreciate testing and performance characterisation on downstream workloads.
Due to unexpected complications, this initial prerelease comes a bit later than expected. Consequently, we expect to have three condensed alphas prior to the release candidate, in contrast to the scheduled three. We expect the next alpha will come the week of 9 Sept. 2025, while the third will come 23 Sept. 2025, with the release candidate coming 7 Oct. 2025.
We would like to thank the Zw3rk stake pool, Well-Typed, Mercury, Channable, Tweag I/O, Serokell, SimSpace, the Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release.
As always, do give this release a try and open a ticket if you see anything amiss.
]]>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:
naturalAndNot returning bogus results (#26205)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.
]]>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:
Backtrace constructor in the base library that was backported
due to confusion on CLC approvals (!14587)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.
]]>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:
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.
]]>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.
]]>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
...
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.
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.
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.
The first LTS release will be GHC 9.14, which will be released this summer!
]]>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:
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.
]]>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.
]]>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:
-fspec-eval and -fspec-eval-dictfun to allow
switching off speculative evaluation.The following libraries have been updated since GHC 9.6.6:
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
]]>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.
]]>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!
The GHC developers are very pleased to announce the release of GHC 9.12.1. Binary distributions, source distributions, and documentation are available at downloads.haskell.org.
We hope to have this release available via ghcup shortly.
GHC 9.12 will bring a number of new features and improvements, including:
The new language extension OrPatterns allowing you to combine multiple pattern clauses into one.
The MultilineStrings language extension to allow you to more easily write strings spanning multiple lines in your source code.
Improvements to the OverloadedRecordDot extension, allowing the built-in
HasField class to be used for records with fields of non lifted representations.
The NamedDefaults language extension has been introduced allowing you to
define defaults for typeclasses other than Num.
More deterministic object code output, controlled by the -fobject-determinism
flag, which improves determinism of builds a lot (though does not fully do so)
at the cost of some compiler performance (1-2%). See #12935 for the details
GHC now accepts type syntax in expressions as part of GHC Proposal #281.
The WASM backend now has support for TemplateHaskell.
Experimental support for the RISC-V platform with the native code generator.
… and many more
A full accounting of changes can be found in the release notes. As always, GHC’s release status, including planned future releases, can be found on the GHC Wiki status.
We would like to thank GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, the Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release.
As always, do give this release a try and open a ticket if you see anything amiss.
]]>The GHC developers are happy to announce the availability of GHC 9.8.4. Binary distributions, source distributions, and documentation are available on the release page.
This release is a small release fixing a few issues noted in 9.8.3, including:
Update the filepath submodule to avoid a misbehavior of splitFileName under Windows.
Update the unix submodule to fix a compilation issue on musl platforms
Fix a potential source of miscompilation when building large projects on 32-bit platforms
Fix unsound optimisation of prompt# uses
A full accounting of changes can be found in the release notes. As some of the fixed issues do affect correctness users are encouraged to upgrade promptly.
We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release.
As always, do give this release a try and open a ticket if you see anything amiss.
Happy compiling!
The GHC developers are very pleased to announce the availability of the release candidate for GHC 9.12.1. Binary distributions, source distributions, and documentation are available at downloads.haskell.org.
We hope to have this release available via ghcup shortly.
GHC 9.12 will bring a number of new features and improvements, including:
The new language extension OrPatterns allowing you to combine multiple pattern clauses into one.
The MultilineStrings language extension to allow you to more easily write strings spanning multiple lines in your source code.
Improvements to the OverloadedRecordDot extension, allowing the built-in
HasField class to be used for records with fields of non lifted representations.
The NamedDefaults language extension has been introduced allowing you to
define defaults for typeclasses other than Num.
More deterministic object code output, controlled by the -fobject-determinism
flag, which improves determinism of builds a lot (though does not fully do so)
at the cost of some compiler performance (1-2%). See #12935 for the details
GHC now accepts type syntax in expressions as part of GHC Proposal #281.
The WASM backend now has support for TemplateHaskell.
… and many more
A full accounting of changes can be found in the release notes. As always, GHC’s release status, including planned future releases, can be found on the GHC Wiki status.
We would like to thank GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, the Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release.
As always, do give this release a try and open a ticket if you see anything amiss.
]]>The GHC developers are very pleased to announce the availability of the third alpha release of GHC 9.12.1. Binary distributions, source distributions, and documentation are available at downloads.haskell.org.
We hope to have this release available via ghcup shortly.
GHC 9.12 will bring a number of new features and improvements, including:
The new language extension OrPatterns allowing you to combine multiple pattern clauses into one.
The MultilineStrings language extension to allow you to more easily write strings spanning multiple lines in your source code.
Improvements to the OverloadedRecordDot extension, allowing the built-in
HasField class to be used for records with fields of non lifted representations.
The NamedDefaults language extension has been introduced allowing you to
define defaults for typeclasses other than Num.
More deterministic object code output, controlled by the -fobject-determinism
flag, which improves determinism of builds a lot (though does not fully do so)
at the cost of some compiler performance (1-2%). See #12935 for the details
GHC now accepts type syntax in expressions as part of GHC Proposal #281.
The WASM backend now has support for TemplateHaskell.
… and many more
A full accounting of changes can be found in the release notes. As always, GHC’s release status, including planned future releases, can be found on the GHC Wiki status.
We would like to thank GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, the Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release.
As always, do give this release a try and open a ticket if you see anything amiss.
]]>The GHC developers are very pleased to announce the availability of the second alpha release of GHC 9.12.1. Binary distributions, source distributions, and documentation are available at downloads.haskell.org.
We hope to have this release available via ghcup shortly.
GHC 9.12 will bring a number of new features and improvements, including:
The new language extension OrPatterns allowing you to combine multiple pattern clauses into one.
The MultilineStrings language extension to allow you to more easily write strings spanning multiple lines in your source code.
Improvements to the OverloadedRecordDot extension, allowing the built-in
HasField class to be used for records with fields of non lifted representations.
The NamedDefaults language extension has been introduced allowing you to
define defaults for typeclasses other than Num.
More deterministic object code output, controlled by the -fobject-determinism
flag, which improves determinism of builds a lot (though does not fully do so)
at the cost of some compiler performance (1-2%). See #12935 for the details
GHC now accepts type syntax in expressions as part of GHC Proposal #281.
The WASM backend now has support for TemplateHaskell.
… and many more
A full accounting of changes can be found in the release notes. As always, GHC’s release status, including planned future releases, can be found on the GHC Wiki status.
We would like to thank GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, the Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release.
As always, do give this release a try and open a ticket if you see anything amiss.
]]>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:
runRW# (#25055)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!
The GHC developers are very pleased to announce the availability of the first alpha release of GHC 9.12.1. Binary distributions, source distributions, and documentation are available at downloads.haskell.org.
We hope to have this release available via ghcup shortly.
GHC 9.12 will bring a number of new features and improvements, including:
The new language extension OrPatterns allowing you to combine multiple pattern clauses into one.
The MultilineStrings language extension to allow you to more easily write strings spanning multiple lines in your source code.
Improvements to the OverloadedRecordDot extension, allowing the built-in
HasField class to be used for records with fields of non lifted representations.
The NamedDefaults language extension has been introduced allowing you to
define defaults for typeclasses other than Num.
More deterministic object code output, controlled by the -fobject-determinism
flag, which improves determinism of builds a lot (though does not fully do so)
at the cost of some compiler performance (1-2%). See #12935 for the details
GHC now accepts type syntax in expressions as part of GHC Proposal #281.
… and many more
A full accounting of changes can be found in the release notes. As always, GHC’s release status, including planned future releases, can be found on the GHC Wiki status.
We would like to thank GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, the Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release.
As always, do give this release a try and open a ticket if you see anything amiss.
]]>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 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
]]>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.
]]>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.
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.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.
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.
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.
]]>The GHC developers are very pleased to announce the release of GHC 9.10.1. Binary distributions, source distributions, and documentation are available at downloads.haskell.org and via GHCup.
GHC 9.10 brings a number of new features and improvements, including:
The introduction of the GHC2024 language edition, building upon
GHC2021 with the addition of a number of widely-used extensions.
Partial implementation of the GHC Proposal #281, allowing visible quantification to be used in the types of terms.
Extension of LinearTypes to allow linear let and where
bindings
The implementation of the exception backtrace proposal, allowing the annotation of exceptions with backtraces, as well as other user-defined context
Further improvements in the info table provenance mechanism, reducing code size to allow IPE information to be enabled more widely
Javascript FFI support in the WebAssembly backend
Improvements in the fragmentation characteristics of the low-latency non-moving garbage collector.
… and many more
A full accounting of changes can be found in the release notes. As always, GHC’s release status, including planned future releases, can be found on the GHC Wiki status.
We would like to thank GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, the Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release.
As always, do give this release a try and open a ticket if you see anything amiss.
]]>The GHC developers are very pleased to announce the availability of the release candidate for GHC 9.10.1. Binary distributions, source distributions, and documentation are available at downloads.haskell.org and via GHCup.
GHC 9.10 brings a number of new features and improvements, including:
The introduction of the GHC2024 language edition, building upon
GHC2021 with the addition of a number of widely-used extensions.
Partial implementation of the GHC Proposal #281, allowing visible quantification to be used in the types of terms.
Extension of LinearTypes to allow linear let and where
bindings
The implementation of the exception backtrace proposal, allowing the annotation of exceptions with backtraces, as well as other user-defined context
Further improvements in the info table provenance mechanism, reducing code size to allow IPE information to be enabled more widely
Javascript FFI support in the WebAssembly backend
Improvements in the fragmentation characteristics of the low-latency non-moving garbage collector.
… and many more
A full accounting of changes can be found in the release notes. As always, GHC’s release status, including planned future releases, can be found on the GHC Wiki status.
This is the penultimate prerelease leading to 9.10.1. In two weeks we plan to publish a release candidate, followed, if all things go well, by the final release a week later.
We would like to thank GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, the Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release.
As always, do give this release a try and open a ticket if you see anything amiss.
]]>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:
process library to 1.6.19.0 to avoid a potential
command injection vulnerability on Windows for clients of this library. This isn’t
known to affect GHC itself, but allows users who depend on the installed
version of the process to avoid the issue.hsc2hs wrapper using flags from the
compiler build environment (#24050).-fasm-shortcutting optimisation with -O2 as it is known
to result in unsoundess and incorrect runtime results in some cases (#24507).LDFLAGS into account when configuring a linker (#24565).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
]]>The GHC developers are very pleased to announce the availability of the third alpha release of GHC 9.10.1. Binary distributions, source distributions, and documentation are available at downloads.haskell.org.
We hope to have this release available via ghcup shortly.
GHC 9.10 will bring a number of new features and improvements, including:
The introduction of the GHC2024 language edition, building upon
GHC2021 with the addition of a number of widely-used extensions.
Partial implementation of the GHC Proposal #281, allowing visible quantification to be used in the types of terms.
Extension of LinearTypes to allow linear let and where
bindings
The implementation of the exception backtrace proposal, allowing the annotation of exceptions with backtraces, as well as other user-defined context
Further improvements in the info table provenance mechanism, reducing code size to allow IPE information to be enabled more widely
Javascript FFI support in the WebAssembly backend
Improvements in the fragmentation characteristics of the low-latency non-moving garbage collector.
… and many more
A full accounting of changes can be found in the release notes. As always, GHC’s release status, including planned future releases, can be found on the GHC Wiki status.
This alpha is the penultimate prerelease leading to 9.10.1. In two weeks we plan to publish a release candidate, followed, if all things go well, by the final release a week later.
We would like to thank GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, the Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release.
As always, do give this release a try and open a ticket if you see anything amiss.
]]>The GHC developers are very pleased to announce the availability of the second alpha release of GHC 9.10.1. Binary distributions, source distributions, and documentation are available at downloads.haskell.org.
We hope to have this release available via ghcup shortly.
GHC 9.10 will bring a number of new features and improvements, including:
The introduction of the GHC2024 language edition, building upon
GHC2021 with the addition of a number of widely-used extensions.
Partial implementation of the GHC Proposal #281, allowing visible quantification to be used in the types of terms.
Extension of LinearTypes to allow linear let and where
bindings
The implementation of the exception backtrace proposal, allowing the annotation of exceptions with backtraces, as well as other user-defined context
Further improvements in the info table provenance mechanism, reducing code size to allow IPE information to be enabled more widely
Javascript FFI support in the WebAssembly backend
Improvements in the fragmentation characteristics of the low-latency non-moving garbage collector.
… and many more
A full accounting of changes can be found in the release notes. As always, GHC’s release status, including planned future releases, can be found on the GHC Wiki status.
We would like to thank GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, the Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release.
As always, do give this release a try and open a ticket if you see anything amiss.
]]>The GHC developers are very pleased to announce the availability of the first alpha release of GHC 9.10.1. Binary distributions, source distributions, and documentation are available at downloads.haskell.org.
We hope to have this release available via ghcup shortly.
GHC 9.10 will bring a number of new features and improvements, including:
The introduction of the GHC2024 language edition, building upon
GHC2021 with the addition of a number of widely-used extensions.
Partial implementation of the GHC Proposal #281, allowing visible quantification to be used in the types of terms.
Extension of LinearTypes to allow linear let and where
bindings
The implementation of the exception backtrace proposal, allowing the annotation of exceptions with backtraces, as well as other user-defined context
Further improvements in the info table provenance mechanism, reducing code size to allow IPE information to be enabled more widely
Javascript FFI support in the WebAssembly backend
Improvements in the fragmentation characteristics of the low-latency non-moving garbage collector.
… and many more
A full accounting of changes can be found in the release notes. As always, GHC’s release status, including planned future releases, can be found on the GHC Wiki status.
Many will notice that this release comes a fair bit later than the previously-announced schedule. While this delay has been attributable to a variety factors, the most recent cause is a set of issues with GHC 9.10’s binary distributions on Windows (#24542). Instead of continuing to hold up the release process while we sort out this situation, we have instead provided this alpha without the usual assortment of Windows binary distributions. We expect to have this resolved by alpha 2; apologies to eager Windows testers for this delay.
We would like to thank GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, the Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release.
As always, do give this release a try and open a ticket if you see anything amiss.
]]>The GHC developers are happy to announce the availability of GHC 9.8.2. Binary distributions, source distributions, and documentation are available on the release page.
This release is primarily a bugfix release addressing many issues found in the 9.8 series. These include:
A full accounting of changes can be found in the release notes. As some of the fixed issues do affect correctness users are encouraged to upgrade promptly.
We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release.
As always, do give this release a try and open a ticket if you see anything amiss.
Enjoy!
-Zubin
]]>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 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
]]>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:
-split-sections on Windows.-split-sections for various Linux and Windows binary distributions,
enabling GHC to produce smaller binaries on these platforms.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
]]>The GHC developers are very pleased to announce the availability of the final release of GHC 9.8.1. Binary distributions, source distributions, and documentation are available at downloads.haskell.org.
GHC 9.8 brings a number of new features and improvements, including:
Preliminary support the TypeAbstractions language extension,
allowing types to be bound in type declarations TypeAbstractions.
Support for the ExtendedLiterals extension, providing syntax for
non-word-sized numeric literals in the surface language
extended-literals
Improved rewrite rule matching behavior, allowing limited matching of higher-order patterns
Better support for user-defined warnings by way of the WARNING
pragma warnings
The introduction of the new GHC.TypeError.Unsatisfiable
constraint, allowing more predictable user-defined type errors
unsatisfiable
Implementation of the export deprecation proposal, allowing module
exports to be marked with DEPRECATE pragmas deprecated-exports
The addition of build semaphore support for parallel compilation;
with coming support in cabal-install this will allow better use of
parallelism in multi-package builds jsem
More efficient representation of info table provenance information,
reducing binary sizes by over 50% in some cases when
-finfo-table-map is in use
A full accounting of changes can be found in the release notes. Plans for GHC’s future releases can be found on the GHC Wiki.
We would like to thank GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, the Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release.
Ben
The GHC developers are very pleased to announce the availability of the release candidate of GHC 9.8.1. Binary distributions, source distributions, and documentation are available at downloads.haskell.org.
GHC 9.8 will bring a number of new features and improvements, including:
Preliminary support the TypeAbstractions language extension,
allowing types to be bound in type declarations TypeAbstractions.
Support for the ExtendedLiterals extension, providing syntax for
non-word-sized numeric literals in the surface language
extended-literals
Improved rewrite rule matching behavior, allowing limited matching of higher-order patterns
Better support for user-defined warnings by way of the WARNING
pragma warnings
The introduction of the new GHC.TypeError.Unsatisfiable
constraint, allowing more predictable user-defined type errors
unsatisfiable
Implementation of the export deprecation proposal, allowing module
exports to be marked with DEPRECATE pragmas deprecated-exports
The addition of build semaphore support for parallel compilation;
with coming support in cabal-install this will allow better use of
parallelism in multi-package builds jsem
More efficient representation of info table provenance information,
reducing binary sizes by over 50% in some cases when
-finfo-table-map is in use
A full accounting of changes can be found in the release notes. This candidate includes roughly 20 new commits relative to alpha 4, including what we believe should be nearly the last changes to GHC’s boot libraries. As always, GHC’s release status can be found on the GHC Wiki status.
We would like to thank GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, the Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release.
As always, do give this release a try and open a ticket if you see anything amiss.
Ben
The GHC developers are happy to announce the availability of GHC 9.6.3. Binary distributions, source distributions, and documentation are available on the release page.
This release is primarily a bugfix release addressing a few issues found in the 9.6 series. These include:
Disable Polymorphic Specialisation (a performance optimisation) by default. It
was discovered that Polymorphic Specialisation as currently implemented in GHC
can lead to hard to diagnose bugs resulting in incorrect runtime results.
Users wishing to use this optimisation despite the caveats will now have to
explicitly enable the new -fpolymorphic-specialisation flag. For more details
see #23469 as well as #23109, #21229, #23445.
Improve compile time and code generation performance when -finfo-table-map is
enabled (#23103).
Make the recompilation check more robust when code generation flags are changed (#23369).
Addition of memory barriers that improve soundness on platforms with weak memory ordering.
And dozens of other fixes.
A full accounting of changes can be found in the release notes. As some of the fixed issues do affect correctness users are encouraged to upgrade promptly.
We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release.
As always, do give this release a try and open a ticket if you see anything amiss.
Enjoy!
-Bryan
]]>The GHC developers are very pleased to announce the availability of the fourth alpha prerelease of GHC 9.8.1. Binary distributions, source distributions, and documentation are available at downloads.haskell.org.
GHC 9.8 will bring a number of new features and improvements, including:
Preliminary support the TypeAbstractions language extension,
allowing types to be bound in type declarations.
Support for the ExtendedLiterals extension, providing
more consistent support for non-word-sized numeric literals in the surface
language
Improved rewrite rule matching behavior, allowing limited matching of higher-order patterns
Better support for user-defined warnings by way of the WARNING
pragma
The introduction of the new GHC.TypeError.Unsatisfiable
constraint, allowing more predictable user-defined type errors
Implementation of the export deprecation proposal,
allowing module exports to be marked with DEPRECATE pragmas
The addition of build semaphore support for parallel compilation, allowing better use of parallelism across GHC builds
More efficient representation of info table provenance information,
reducing binary sizes by nearly 80% in some cases when
-finfo-table-map is in use
A full accounting of changes can be found in the release notes. This alpha includes roughly 40 new commits relative to alpha 3, including what we believe should be nearly the last changes to GHC’s boot libraries.
We would like to thank GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, the Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release.
As always, do give this release a try and open a ticket if you see anything amiss.
]]>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:
pthread_condattr_setclock
symbol available (#23789).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,
The GHC developers are very pleased to announce the availability of the third alpha prerelease of GHC 9.8.1. Binary distributions, source distributions, and documentation are available at downloads.haskell.org.
GHC 9.8 will bring a number of new features and improvements, including:
Preliminary support the TypeAbstractions language extension,
allowing types to be bound in type declarations.
Support for the ExtendedLiterals extension, providing
more consistent support for non-word-sized numeric literals in the surface
language
Improved rewrite rule matching behavior, allowing limited matching of higher-order patterns
Better support for user-defined warnings by way of the WARNING
pragma
The introduction of the new GHC.TypeError.Unsatisfiable
constraint, allowing more predictable user-defined type errors
Implementation of the export deprecation proposal,
allowing module exports to be marked with DEPRECATE pragmas
The addition of build semaphore support for parallel compilation, allowing better use of parallelism across GHC builds
More efficient representation of info table provenance information,
reducing binary sizes by nearly 80% in some cases when
-finfo-table-map is in use
A full accounting of changes can be found in the release notes. This alpha includes roughly a dozen changes relative to alpha 2, including what we believe should be nearly the last changes to GHC’s boot libraries.
We would like to thank GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, the Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release.
As always, do give this release a try and open a ticket if you see anything amiss.
]]>The GHC developers are very pleased to announce the availability of the second alpha prerelease of GHC 9.8.1. Binary distributions, source distributions, and documentation are available at downloads.haskell.org.
GHC 9.8 will bring a number of new features and improvements, including:
Preliminary support the TypeApplications language extension,
allowing types to be bound in type declarations.
Support for the ExtendedLiterals extension, providing
more consistent support for non-word-sized numeric literals in the surface
language
Improved rewrite rule matching behavior, allowing limited matching of higher-order patterns
Better support for user-defined warnings by way of the WARNING
pragma
The introduction of the new GHC.TypeError.Unsatisfiable
constraint, allowing more predictable user-defined type errors
Implementation of the export deprecation proposal,
allowing module exports to be marked with DEPRECATE pragmas
The addition of build semaphore support for parallel compilation, allowing better use of parallelism across GHC builds
More efficient representation of info table provenance information,
reducing binary sizes by nearly 80% in some cases when
-finfo-table-map is in use
A full accounting of changes can be found in the release notes. This alpha includes roughly two dozen bug-fixes relative to alpha 1.
We would like to thank GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, the Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release.
As always, do give this release a try and open a ticket if you see anything amiss.
]]>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:
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,
The GHC developers are very pleased to announce the availability of the first alpha prerelease of GHC 9.8.1. Binary distributions, source distributions, and documentation are available at downloads.haskell.org.
GHC 9.8 will bring a number of new features and improvements, including:
Preliminary support the TypeAbstractions language extension,
allowing types to be bound in type declarations.
Support for the ExtendedLiterals extension, providing syntax for
non-word-sized numeric literals in the surface language
Improved rewrite rule matching behavior, allowing limited matching of higher-order patterns
Better support for user-defined warnings by way of the WARNING pragma
The introduction of the new GHC.TypeError.Unsatisfiable
constraint, allowing more predictable user-defined type errors
Implementation of the export deprecation proposal, allowing module
exports to be marked with DEPRECATE pragmas
The addition of build semaphore support for parallel compilation;
with coming support in cabal-install this will allow better use of
parallelism in multi-package builds
More efficient representation of info table provenance information,
reducing binary sizes by over 50% in some cases when
-finfo-table-map is in use
A full accounting of changes can be found in the release notes.
We would like to thank GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, the Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release.
As always, do give this release a try and open a ticket if you see anything amiss.
]]>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:
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,
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,
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:
gmp-tarballs to a version which doesn’t use the reserved x18
register on AArch64/Darwin systems, and also has fixes for CVE-2021-43618
(#22497, #22789).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,
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,
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,
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:
setKeepCafs
symbol which started being used by the GHC library in 9.2.6, resulting in
code depending on this symbol failing to load in GHCi or via a compile time
splice when using a statically linked GHC, such as on Windows (#22961).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,
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,
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:
-XOverloadedRecordDot (#20723).gmp-tarballs to a version which doesn’t use the reserved x18
register on AArch64/Darwin systems, and also has fixes for CVE-2021-43618
(#22497, #22789).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,
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,
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,
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:
-fdefer-diagnostics flag (#22391)IORef operations, avoiding potential
soundness issues on architectures with weakly-ordered memory models
(#22468)Note that, as GHC 9.4 is the first release series where the release artifacts
are all generated by our new Hadrian build system, it is possible that there
will be packaging issues. If you enounter trouble while using a binary
distribution, please open a ticket. Likewise, if you are a downstream
packager, do consider migrating to Hadrian to run your build; the Hadrian
build system can be built using cabal-install, stack, or the in-tree
bootstrap script. See the accompanying blog post for details on
migrating packaging to Hadrian.
We would also like to emphasize that GHC 9.4 must be used in conjunction with
Cabal-3.8 or later. This is particularly important for Windows users due to
changes in GHC’s Windows toolchain.
We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release.
As always, do give this release a try and open a ticket if you see anything amiss.
Happy Haskelling,
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:
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,
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:
process library where file handles specified as NoStream would
still be usable in the child (process#251)Note that, as GHC 9.4 is the first release series where the release artifacts
are all generated by our new Hadrian build system, it is possible that there
will be packaging issues. If you enounter trouble while using a binary
distribution, please open a ticket. Likewise, if you are a downstream
packager, do consider migrating to Hadrian to run your build; the Hadrian
build system can be built using cabal-install, stack, or the in-tree
bootstrap script. See the accompanying blog post for details on
migrating packaging to Hadrian.
We would also like to emphasize that GHC 9.4 must be used in conjunction with Cabal-3.8 or later. This is particularly important for Windows users due to changes in GHC’s Windows toolchain.
We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release.
As always, do give this release a try and open a ticket if you see anything amiss.
Happy Haskelling,
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,
The GHC developers are happy to announce the availability of GHC 9.4.1. Binary distributions, source distributions, and documentation are available at downloads.haskell.org.
This release includes:
A new profiling mode, -fprof-late, which adds automatic cost-center
annotations to all top-level functions after Core optimisation has
run. This provides informative profiles while interfering
significantly less with GHC’s aggressive optimisations, making it
easier to understand the performance of programs which depend upon
simplification..
A variety of plugin improvements including the introduction of a new plugin type, defaulting plugins, and the ability for typechecking plugins to rewrite type-families.
An improved constructed product result analysis, allowing unboxing of nested structures, and a new boxity analysis, leading to less reboxing.
Introduction of a tag-check elision optimisation, bringing significant performance improvements in strict programs.
Generalisation of a variety of primitive types to be levity
polymorphic. Consequently, the ArrayArray# type can at long last be
retired, replaced by standard Array#.
Introduction of the \cases syntax from GHC proposal 0302.
A complete overhaul of GHC’s Windows support. This includes a migration to a fully Clang-based C toolchain, a deep refactoring of the linker, and many fixes in WinIO.
Support for multiple home packages, significantly improving support in IDEs and other tools for multi-package projects.
A refactoring of GHC’s error message infrastructure, allowing GHC to provide diagnostic information to downstream consumers as structured data, greatly easing IDE support.
Significant compile-time improvements to runtime and memory consumption.
On overhaul of our packaging infrastructure, allowing full traceability of release artifacts and more reliable binary distributions.
Reintroduction of deep subsumption (which was previously dropped with the simplified subsumption change) as a language extension.
… and much more. See the release notes for a full accounting.
Note that, as 9.4.1 is the first release for which the released artifacts will
all be generated by our Hadrian build system, it is possible that there will be
packaging issues. If you enounter trouble while using a binary distribution,
please open a ticket. Likewise, if you are a downstream packager, do consider
migrating to Hadrian to run your build; the Hadrian build system can be built
using cabal-install, stack, or the in-tree bootstrap script. See the accompanying
blog post for details on migrating packaging to Hadrian.
We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release.
As always, do give this release a try and open a ticket if you see anything amiss.
Happy testing,
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.
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.
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.
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:
hadrian/bootstrap/plan-bootstrap-8.10.7.json.
(These build plans can also be generated manually from a cabal-install build plan; see generate_bootstrap_plans)bootstrap.py fetch -w <path_to_ghc> --deps plan-bootstrap-8.10.7.json -o 8_10_7_bootstrap_sources.tar.gzbootstrap-sources tarball generated above.bootstrap.py -w <path_to_ghc> --bootstrap-sources 8_10_7_bootstrap_sources.tar.gzbin/hadrian, e.g.
bin/hadrian -j --flavour=perf+debug_info -w <path_to_ghc>An example of how to use these bootstrap scripts can be seen in the ghcs-nix
repository.
This repository contains Nix expressions specifying how to build many GHC
versions, with both Make and Hadrian.
From now on, we will assume that you have built Hadrian (either via
./hadrian/build or via bootstrapping), referring to the hadrian executable
agnostically.
To build GHC, we begin as before by running ./boot (if necessary, i.e. a
configure file doesn’t already exist) and then ./configure <args>. As with
Make, the build environment is determined by the configure script, which will
read provided arguments as well as environment variables. For example, the
selection of the bootstrap compiler is done via the GHC environment variable,
and the selection of the C compiler uses the CC environment variable. This is
unchanged, and details can be found on the GHC
wiki.
Once the configure script is run, we replace make commands with hadrian
commands. The fundamental command to build GHC with Hadrian is
hadrian <args>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:
stage0 compiler is the bootstrap compiler: a user-provided executable
which will be used to compile GHC. The bootstrap compiler is chosen via the
GHC variable passed to the configure script.stage1 compiler is the compiler built using the stage0 compiler; it
runs on the build platform and produces code for the target platform. The
stage1 compiler is limited in that it does not support dynamic code loading
via the internal bytecode interpreter.stage2 compiler is the compiler built using the stage1 compiler; it
runs on the target platform. The stage2 compiler is necessary for the
implementation of Template Haskell and GHC plugins.In Hadrian, build artifacts are put in a subdirectory of the build folder (by
default, _build) corresponding to the stage of the compiler used to perform
the build. This means that the stage2 compiler will be found (if using the
default build directory, _build) at _build/stage1/bin/ghc.
Hadrian provides meta-targets which can be used to build particular subsets of the compiler. A typical Hadrian command, which builds a library or executable for a given stage, looks like
hadrian <stage>:{lib,exe}:<package name>For example, hadrian stage2:lib:base will build the stage2 base library,
and put it into the _build/stage1 subdirectory.
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.
Packagers will be interested in the binary-dist and binary-dist-dir Hadrian
targets. For example, the command
hadrian/build --flavour=release binary-distwill 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.
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.
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, *}.optshs for arguments passed to GHC when compiling Haskell modulesc for arguments passed to the C compilercpp for arguments passed to the C++ compilerlink for arguments passed during linkingdeps for arguments to a ghc -M command, which outputs
dependency information between Haskell modules(<stage> or *).(<package name> or *).cc.{c, deps, *}.opts(<stage> or *).(<package name> or *).cabal.configure.opts(<stage> or *).(<package name> or *).hsc2hs.run.optsThese 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.
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.
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.
]]>The GHC developers are very happy to at announce the availability of GHC
9.2.4. Binary distributions, source distributions, and documentation are
available at downloads.haskell.org.
This release will include:
The new DeepSubsumption language extension which reverses the
effects of the Simplified Subsumption Proposal introduced in GHC 9.0. This
is an attempt to make GHC 9.2.4 more backwards compatible with GHC 8.10 and
eases migration for users who depended on this feature.
This extension is enabled by default with the Haskell2010
and Haskell98 languages but disabled with the GHC2021
language originally introduced in GHC 9.2.1.
See the Deep Subsumption Proposal for more details.
Fixes for segfaults that may arise due to a bug in the implementation of the
keepAlive# primop. This may regress performance for certain programs which
use this primop or functions which use the primop, such as withForeignPtr.
These regressions are mostly small, but can be larger in certain edge cases.
Judicious use of unsafeWithForeignPtr when its argument is known not to
statically diverge can mitigate these in many cases. It is our judgment that
the critical correctness issues justify the regression in performance and that
it is important to get a release out with the fix while we work on a better
approach which will improve performance for future releases (#21708).
We have a wiki page
that tracks possible solutions to this problem, and Ben wrote a
blog post
detailing the introduction of the keepAlive# primop and its history.
Fixes for a number of miscompilations on AArch64 and other platforms (#21624, #21773, #20735, #21685).
Fixes for segfaults due to bugs in the RTS and GC (#21708, #21880, #21885).
Fixing the behaviour of Ctrl-C with GHCi on Windows (#21889).
… and much more. See the release notes for a full accounting.
As some of the fixed issues do affect correctness users are encouraged to upgrade promptly.
We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk stake pool, Tweag I/O, Serokell, Equinix, SimSpace, Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release.
As always, do give this release a try and open a ticket if you see anything amiss.
Happy compiling,
The GHC developers are happy to announce the availability of the first (and likely last) release candidate of GHC 9.4.1. Binary distributions, source distributions, and documentation are available at downloads.haskell.org.
This release will include:
A new profiling mode, -fprof-late, which adds automatic cost-center
annotations to all top-level functions after Core optimisation has
run. This provides informative profiles while interfering
significantly less with GHC’s aggressive optimisations, making it
easier to understand the performance of programs which depend upon
simplification..
A variety of plugin improvements including the introduction of a new plugin type, defaulting plugins, and the ability for typechecking plugins to rewrite type-families.
An improved constructed product result analysis, allowing unboxing of nested structures, and a new boxity analysis, leading to less reboxing.
Introduction of a tag-check elision optimisation, bringing significant performance improvements in strict programs.
Generalisation of a variety of primitive types to be levity
polymorphic. Consequently, the ArrayArray# type can at long last be
retired, replaced by standard Array#.
Introduction of the \cases syntax from GHC proposal 0302.
A complete overhaul of GHC’s Windows support. This includes a migration to a fully Clang-based C toolchain, a deep refactoring of the linker, and many fixes in WinIO.
Support for multiple home packages, significantly improving support in IDEs and other tools for multi-package projects.
A refactoring of GHC’s error message infrastructure, allowing GHC to provide diagnostic information to downstream consumers as structured data, greatly easing IDE support.
Significant compile-time improvements to runtime and memory consumption.
On overhaul of our packaging infrastructure, allowing full traceability of release artifacts and more reliable binary distributions.
Reintroduction of deep subsumption (which was previously dropped with the simplified subsumption change) as a language extension.
… and much more. See the release notes for a full accounting.
Note that, as 9.4.1 is the first release for which the released artifacts will
all be generated by our Hadrian build system, it is possible that there will be
packaging issues. If you enounter trouble while using a binary distribution,
please open a ticket. Likewise, if you are a downstream packager, do consider
migrating to Hadrian to run your build; the Hadrian build system can be built
using cabal-install, stack, or the in-tree bootstrap script. We will be
publishing a blog post describing the migration process to Hadrian in the
coming weeks.
We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk stake pool, Tweag I/O, Serokell, Equinix, SimSpace, Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release.
As always, do give this release a try and open a ticket if you see anything amiss.
Happy testing,
The GHC developers are happy to announce the availability of the third alpha release of the GHC 9.4 series. Binary distributions, source distributions, and documentation are available at downloads.haskell.org.
This major release will include:
A new profiling mode, -fprof-late, which adds automatic cost-center
annotations to all top-level functions after Core optimisation has
run. This incurs significantly less performance cost while still
providing informative profiles.
A variety of plugin improvements including the introduction of a new plugin type, defaulting plugins, and the ability for typechecking plugins to rewrite type-families.
An improved constructed product result analysis, allowing unboxing of nested structures, and a new boxity analysis, leading to less reboxing.
Introduction of a tag-check elision optimisation, bringing significant performance improvements in strict programs.
Generalisation of a variety of primitive types to be levity
polymorphic. Consequently, the ArrayArray# type can at long last be
retired, replaced by standard Array#.
Introduction of the \cases syntax from GHC proposal 0302
A complete overhaul of GHC’s Windows support. This includes a migration to a fully Clang-based C toolchain, a deep refactoring of the linker, and many fixes in WinIO.
Support for multiple home packages, significantly improving support in IDEs and other tools for multi-package projects.
A refactoring of GHC’s error message infrastructure, allowing GHC to provide diagnostic information to downstream consumers as structured data, greatly easing IDE support.
Significant compile-time improvements to runtime and memory consumption.
On overhaul of our packaging infrastructure, allowing full traceability of release artifacts and more reliable binary distributions.
… and much more. See the release notes for a full accounting.
Note that, as 9.4.1 is the first release for which the released
artifacts will all be generated by our Hadrian build system, it’s possible that there
will be packaging issues. If you enounter trouble while using a binary
distribution, please open a ticket. Likewise, if you are a downstream
packager, do consider migrating to Hadrian to run your build; the
Hadrian build system can be built using cabal-install, stack, or the
in-tree bootstrap script.
We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk stake pool, Tweag I/O, Serokell, Equinix, SimSpace, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release.
As always, do give this release a try and open a ticket if you see anything amiss.
Happy testing,
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,
The GHC developers are happy to announce the availability of the second alpha release of the GHC 9.4 series. Binary distributions, source distributions, and documentation are available at downloads.haskell.org.
This major release will include:
A new profiling mode, -fprof-late, which adds automatic cost-center
annotations to all top-level functions after Core optimisation has
run. This incurs significantly less performance cost while still
providing informative profiles.
A variety of plugin improvements including the introduction of a new plugin type, defaulting plugins, and the ability for typechecking plugins to rewrite type-families.
An improved constructed product result analysis, allowing unboxing of nested structures, and a new boxity analysis, leading to less reboxing.
Introduction of a tag-check elision optimisation, bringing significant performance improvements in strict programs.
Generalisation of a variety of primitive types to be levity
polymorphic. Consequently, the ArrayArray# type can at long last be
retired, replaced by standard Array#.
Introduction of the \cases syntax from GHC proposal 0302
A complete overhaul of GHC’s Windows support. This includes a migration to a fully Clang-based C toolchain, a deep refactoring of the linker, and many fixes in WinIO.
Support for multiple home packages, significantly improving support in IDEs and other tools for multi-package projects.
A refactoring of GHC’s error message infrastructure, allowing GHC to provide diagnostic information to downstream consumers as structured data, greatly easing IDE support.
Significant compile-time improvements to runtime and memory consumption.
On overhaul of our packaging infrastructure, allowing full traceability of release artifacts and more reliable binary distributions.
… and much more. See the release notes for a full accounting.
Note that, as 9.4.1 is the first release for which the released
artifacts will all be generated by our Hadrian build system, it’s possible that there
will be packaging issues. If you enounter trouble while using a binary
distribution, please open a ticket. Likewise, if you are a downstream
packager, do consider migrating to Hadrian to run your build; the
Hadrian build system can be built using cabal-install, stack, or the
in-tree bootstrap script.
We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk stake pool, Tweag I/O, Serokell, Equinix, SimSpace, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release.
As always, do give this release a try and open a ticket if you see anything amiss.
Happy testing,
This post sets out our current plans for the upcoming releases in the next few months.
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.
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:
massiv-io (#20231),The release manager for this release is Zubin Duggal.
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:
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.
]]>The GHC developers are happy to announce the availability of the first alpha release of the GHC 9.4 series. Binary distributions, source distributions, and documentation are available at downloads.haskell.org.
This major release will include:
A new profiling mode, -fprof-late, which adds automatic cost-center
annotations to all top-level functions after Core optimisation has
run. This incurs significantly less performance cost while still
providing informative profiles.
A variety of plugin improvements including the introduction of a new plugin type, defaulting plugins, and the ability for typechecking plugins to rewrite type-families.
An improved constructed product result analysis, allowing unboxing of nested structures, and a new boxity analysis, leading to less reboxing.
Introduction of a tag-check elision optimisation, bringing significant performance improvements in strict programs.
Generalisation of a variety of primitive types to be levity
polymorphic. Consequently, the ArrayArray# type can at long last be
retired, replaced by standard Array#.
Introduction of the \cases syntax from GHC proposal 0302
A complete overhaul of GHC’s Windows support. This includes a migration to a fully Clang-based C toolchain, a deep refactoring of the linker, and many fixes in WinIO.
Support for multiple home packages, significantly improving support in IDEs and other tools for multi-package projects.
A refactoring of GHC’s error message infrastructure, allowing GHC to provide diagnostic information to downstream consumers as structured data, greatly easing IDE support.
Significant compile-time improvements to runtime and memory consumption.
… and much more
We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk stake pool, Tweag I/O, Serokell, Equinix, SimSpace, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release.
As always, do give this release a try and open a ticket if you see anything amiss.
Happy testing,
The GHC developers are very happy to at announce the availability of GHC
9.2.2. Binary distributions, source distributions, and documentation are
available at downloads.haskell.org.
This release includes many bug-fixes and other improvements to 9.2.1 including:
A number of bug-fixes in the new AArch64 native code generator
Fixes ensuring that the indexWord8ArrayAs*# family of primops is handled
correctly on platforms lacking support for unaligned memory accesses
(#21015, #20987).
Improvements to the compatibility story in GHC’s migration to the XDG Base Directory Specification (#20684, #20669, #20660)
Restored compatibility with Windows 7
A new -fcompact-unwind flag, improving compatibility with C++ libraries on
Apple Darwin (#11829)
Introduction of a new flag, -fcheck-prim-bounds, enabling runtime bounds
checking of array primops (#20769)
Unboxing of unlifted types (#20663)
Numerous improvements in compiler performance.
Many, many others. See the release notes for a full list.
As some of the fixed issues do affect correctness users are encouraged to upgrade promptly.
Finally, thank you to Microsoft Research, GitHub, IOHK, the Zw3rk stake pool, Tweag I/O, Serokell, Equinix, SimSpace, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Moreover, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release.
As always, do open a ticket if you see anything amiss.
Happy compiling,
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-pkg executables
(#20087), and actually distributing GHC versions linked against the
native big integer backend (#18967, #19953) on both Windows and Alpine
Linux. Some previous releases were still linked against the GMP library due to a
misconfiguration of the builders.
A significant refactoring of process fixing numerous bugs mostly on
Apple platforms (#19994, process refactoring).
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.
]]>The GHC developers are very happy to at long last announce the availability of GHC
9.2.1. Binary distributions, source distributions, and documentation are
available at downloads.haskell.org.
GHC 9.2 brings a number of exciting features including:
A native code generation backend for AArch64, significantly speeding compilation time on ARM platforms like the Apple M1.
Many changes in the area of records, including the new
RecordDotSyntax and NoFieldSelectors language extensions, as well
as Support for DuplicateRecordFields with PatternSynonyms.
Introduction of the new GHC2021 language extension set, giving
users convenient access to a larger set of language extensions which
have been long considered stable.
Merging of ghc-exactprint into the GHC tree, providing
infrastructure for source-to-source program rewriting out-of-the-box.
Introduction of a BoxedRep RuntimeRep, allowing for polymorphism
over levity of boxed objects (#17526)
Implementation of the UnliftedDataTypes extension, allowing users
to define types which do not admit lazy evaluation (proposal)
The new [-hi profiling][] mechanism which provides significantly
improved insight into thunk leaks.
Support for the ghc-debug out-of-process heap inspection library
ghc-debug
Significant improvements in the bytecode interpreter, allowing more programs to be efficently run in GHCi and Template Haskell splices.
Support for profiling of pinned objects with the cost-centre profiler (#7275)
Faster compilation and a smaller memory footprint
Introduction of Haddock documentation support in TemplateHaskell (#5467)
Finally, thank you to Microsoft Research, GitHub, IOHK, the Zw3rk stake pool, Tweag I/O, Serokell, Equinix, SimSpace, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Moreover, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release.
As always, do open a ticket if you see anything amiss.
Happy testing,
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.
]]>The GHC team is very pleased to announce the availability of GHC 8.10.6. Source and binary distributions are available at the usual place.
This is a bugfix release, fixing many issues present in GHC 8.10.5, including:
A fix for segmentation faults in GHCi on aarch64-darwin due to
an incorrect foreign import in haskeline. See this blog
post by Ben Gamari
for more details on how your library could be affected.
A fix for a critical bug affecting Haskell Language Server (HLS) among other applications caused by missing RTS symbols required for statically linked builds of the GHC library (#19763).
No longer emitting spurious warnings for LLVM versions (LLVM 9-12) that were actually supported (#19973, #19829, #19959).
Numerous bug fixes for the new LLVM based aarch64-darwin backend (#20132).
Fixes and stability improvements for the non-moving GC (#19715).
Many other bug fixes for the RTS (#18033, #20132, #20093, #19421).
Many packaging related fixes, including versioned ghc-pkg executables
(#20087), and actually distributing GHC versions linked against the
integer-simple big integer backend (#18967, #19953) on both Windows and Alpine
Linux. Previous releases were still linked against the GMP library due to a
misconfiguration of the builders.
A significant refactoring of process fixing numerous bugs mostly on
Apple platforms (#19994, process refactoring).
A FreeBSD release after fixing issues that caused GHC 8.10.5 to be unable to build (#19958, #19948).
Bug fixes for the linker on Darwin platforms (#20004, #19968, #19950).
A complete list of bug fixes and improvements can be found in the release notes.
As always, feel free to report any issues you encounter via gitlab.haskell.org.
]]>The GHC team is very happy to announce the availability of the release cadidate of the 9.2.1 release. Binary distributions, source distributions, and documentation are available at downloads.haskell.org.
GHC 9.2 will bring a number of exciting features including:
A native code generation backend for AArch64, significantly reducing compilation times on ARM platforms such as the Apple M1.
Many changes in the area of records, including the new
RecordDotSyntax and NoFieldSelectors language extensions, as well
as Support for DuplicateRecordFields with PatternSynonyms.
Introduction of the new GHC2021 language extension set, giving
users convenient access to a larger set of language extensions which
have been long considered stable.
Merge of ghc-exactprint into the GHC tree, providing infrastructure
for source-to-source program rewriting out-of-the-box.
Introduction of a BoxedRep RuntimeRep, allowing for polymorphism
over levity of boxed objects (#17526)
Implementation of the UnliftedDataTypes extension, allowing users
to define types which do not admit lazy evaluation (proposal)
The new -hi profiling mechanism which provides significantly improved insight into thunk leaks.
Support for the ghc-debug out-of-process heap inspection library
ghc-debug
Support for profiling of pinned objects with the cost-centre profiler (#7275)
Introduction of Haddock documentation support in TemplateHaskell (#5467)
Thank you to GitHub, IOHK, the Zw3rk stake pool, Tweag I/O, Serokell, Equinix, SimSpace, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Moreover, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release.
As always, do give this a try and open a ticket if you see anything amiss.
Happy testing,
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.
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.
During a function call both the caller and the callee must agree on several operational details:
Together, these details are known as a calling convention and are typically implied by the operating system and target architecture. For instance, x86-64 Linux (and most other POSIX platforms) typically uses the System V amd64 calling convention whereas 32-bit Windows has no fewer than three commonly-used conventions.
When compiling C source, the C compiler determines a function’s
calling convention using its signature, which typically appears in a header
file. However, when GHC imports a function with the usual ccall calling convention, e.g.:
foreign import ccall "hello_world" helloWorld :: IO ()it does not have the benefit of a signature; instead it must infer the calling convention from the type given by the import. This can break in two ways:
printf)
differently from the corresponding non-variadic signature; while it is
documented that ccall does not support variadic
functions, this fact is not well-known by users.Int instead of CInt)Unfortunately, with the foreign import ccall mechanism the compiler has no
way of catching such issues, potentially leaving the user with
difficult-to-spot, platform-dependent soundness bugs.
CApiFFITo address help mitigate this class of bugs, GHC 7.10 introduced a new language
extension, CApiFFI, which offers a more robust way to import foreign
functions. Unlike ccall, capi requires that the user specify both the
foreign function’s name as well as the name of the header file where its
signature can be found. For instance, one can write:
foreign import capi "stdio.h puts" c_puts :: Ptr CChar -> IO CIntTo compile this, GHC will construct a C source file which #include’s
stdio.h. and defines a stub function which performs the call:
#include "stdio.h"
HsInt32 ghczuwrapperZC0ZCmainZCHelloZCputs(void* a1) {
return puts(a1);
}This approach brings a few advantages:
capi imports can be used to import functions defined using CPPAs 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.
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.
One of the joys of working in a garbage collected language is that one is freed from the burden of thinking about object lifetime. Instead, it is the responsibility of the runtime to retain each object as long as it is reachable from the roots of the heap graph.
Moreover, one of the great joys of Haskell is its robust foreign function interface, giving users the ability to easily weave together Haskell and foreign code in a safe and efficient manner.
However, taken together these two features pose significant challenges to language implementors; specifically, consider a program such as:
-- Recall that:
-- newPinnedByteArray :: Int -> IO (MutableByteArray RealWorld)
-- setByteArray :: Prim a => MutableByteArray RealWorld -> Int -> Int -> a -> IO ()
-- mutableByteArrayContents :: MutableByteArray RealWorld -> Ptr a
import Data.Primitive.ByteArray
main = printDots 10
printDots :: Int -> IO ()
printDots len = do
arr <- newPinnedByteArray len
setByteArray arr 0 len (fromIntegral $ ord '.' :: Word8)
let ptr :: Ptr CChar
ptr = byteArrayContents arr
puts ptr
-- Recall that:
-- void puts(const char *);
foreign import ccall "puts"
puts :: Ptr CChar -> IO ()Here we have allocated an array on the Haskell heap, initialized it, and passed
it to the C puts function, which will print it to stdout. On its face, this
program looks completely innocuous: it contains no mentions of unsafe
functions, the array’s bounds are clearly respected, and puts is specified to
treat its argument as immutable. Indeed, running the program even prints the
expected result (at least most of the time).
However, despite its appearance, this program is fatally flawed. Specifically,
note that puts is (implicitly) declared to be a safe foreign call; this
means that GHC is free to do as it pleases (e.g. continue running another
Haskell thread or, perhaps, initiate a GC) while the C call executes in another
operating system thread. This is problematic since upon entering puts there
are no references to arr remaining on the Haskell heap, leading the collector
to conclude that the array can be safely reclaimed. However, arr is not
dead: it is still in use via the off-heap reference passed to puts.
However, this reference is not visible to the garbage collector.
Premature collection of live heap objects may result in arbitrary heap
corruption, which may cause a program crash at best and incorrect runtime
result at worst. Also note that while FFI is the most common reason for off-heap
references, it is certainly not the only reason. In particular, any use of
byteArrayContents is potentially problematic in this way.
To make such off-heap references visible to the runtime, GHC has long provided the
touch operation (embodied by the GHC.Exts.touch# primop):
touch :: forall a. a -> IO ()Semantically (and, mostly, operationally) the action touch x is a no-op; it
merely instructs GHC to ensure that the given value is alive at the point when the
action is executed. Using this operation we can fix printDots as follows:
printDots len =
arr <- newPinnedByteArray len
setByteArray arr 0 len (fromIntegral $ ord '.' :: Word8)
puts (byteArrayContents arr)
touch 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:
hdl <- openFile "hello.txt"
hPutStrLn hdl "hello world!"
hClose hdlWe prefer to write:
withFile:
withFile "hello.txt" $ \hdl ->
hPutStrLn hdl "hello world!"as the latter makes the lifetime of the resource apparent from the program’s
syntactic structure alone. In the same way, users have historically been advised
to stay away from using touch and its variants directly. For instance, while
Foreign.ForeignPtr provides a touchForeignPtr operation the documentation
strong recommends that the user rather use withForeignPtr.
While it is rarely seen in user code, the touch# primop has served
the Haskell community well for many years: a handful of occurrences in base,
bytestring, and other foundational libraries ensured that garbage colection
and foreign calls could peacefully coexist. However, as we will see, the design
of the primop is ripe for unsoundness.
Over the years GHC’s simplifier (the GHC subsystem responsible for
optimising programs in its Core intermediate representation)
has consistently grown in its abilities. By GHC 8.2 we started to come to
the realization that all was not well with touch#. To see why, let us examine
a transform performed by GHC’s simplifier which I will call dead-continuation
elimination (DCE).
Consider that you have a program such as:
doThings =
case error "hello world" :: Int of
0 -> {- some large expression -}
1 -> {- another large expression -}
...Here we have a program with a divergent expression (namely the error
application) scrutinized by a case with a number of large alternatives.
Under Haskell’s semantics, it is impossible for program execution to reach
any of these alternatives’ right-hand-sides.
By the dead-continuation elimination transform, GHC’s simplifier will cull this unreachable code, turning the program into:
doThings =
case error "hello world" :: Int of { }This optimisation can significantly reduce program sizes. Note that exceptions are only one source of divergence: any non-terminating scrutinee can trigger this transformation.
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.
At first glance, the design of a safer touch# seems obvious by analogy to
withFile:
with :: a -> (a -> m b) -> m bUnder 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.
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 RuntimeRep
we must generalize the type of with:
with# :: forall a (r :: RuntimeRep) (b :: TYPE r).
a -> (a -> b) -> buse State# tokens to enforce execution ordering:
with# :: forall a (r :: RuntimeRep) (b :: TYPE r).
a -> State# s -> (State# s -> b) -> bteaching the simplifier to “push” strict contexts (e.g. case) into
with# applications. For instance, transform
case (with# x s (\s' -> k)) of alt -> rhsinto
with# x s (\s' -> case k of alt -> rhs)This transformation, which we call “strict context pushing” (SCP), is
similar to a transform already performed on runRW# applications (#15127).
In this case of with#, it is sound as it strictly grows the scope of the
continuation and therefore lengthens the lifetime of the kept-alive value.
This SCP transformation allows us to eliminate the allocation incurred in the
case of readWord8 by way of inlining and simplification. That is, consider a
strict call-site of readWord8:
IO $ \s0 ->
case readWord8 fptr s0 of (# s1, n #) ->
case n of W8# n# ->
doSomething n#First, we inline readWord8, resulting in:
IO $ \s0 ->
case (
with# fptr s0 (\s1 ->
case peek (unsafeForeignPtrToPtr fptr') s1 of (# s2, n# #) ->
(# s2, W8# n# #)
)
) of (# s3, n #) ->
case n of W8# n# ->
doSomething n#Now, by the SCP transform above, the outer case can be pushed inside of the
with#:
IO $ \s0 ->
with# fptr s0 (\s1 ->
case (
case peek (unsafeForeignPtrToPtr fptr') s1 of (# s2, n# #) ->
(# s2, W8# n# #)
) of (# s3, n #) ->
case n of W8# n# ->
doSomething n#
)Finally, case-of-known constructor can be applied twice, eliminating the W8#
allocation:
IO $ \s0 ->
with# fptr s0 (\s1 ->
case peek (unsafeForeignPtrToPtr fptr') s1 of (# s2, n# #) ->
doSomething n#
)Hooray!
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 the RuntimeRep of its result lest the user is
unable to use it to compute unboxed results.State# tokens is a good hint to the user that they must take
care to control execution ordering to safely use the operationConsequently, we will adopt the following type for with#:
with# :: forall a (r :: RuntimeRep) (b :: TYPE r).
a -> State# s -> (State# s -> b) -> bwith#Above we considered some of the design decisions surrounding the user-facing
interface of with#. However, the interface is only half of the story: the
compiler must also know how to generate code for with#.
Thankfully, doing so is (currently) reasonably straightforward as GHC’s DCE
optimisation strictly occurs on Core. For this reason, we can safely desugar
with# into touch# by inlining after the Core-to-Core optimisation pipeline
has run (namely in the CorePrep stage of compilation). Specifically, an
application:
-- Recall that
-- with# :: forall a (r :: RuntimeRep) (b :: TYPE r).
-- a -> State# s -> (State# s -> b) -> b
with# x s0 (\s0 -> k)can be rewritten to
case k s0 of r ->
case touch# x s0 of s1 ->
rAdmittedly, 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.0While 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.
unsafeWithForeignPtrWhile the introduction of keepAlive# affects relatively little user-code, the
added cost of withForeignPtr has the potential to be more impactful. In
particular, it is not uncommon to find code such as:
withForeignPtr fptr (peek @Word8)in tight inner-loops. Adding an allocation in such a context would be
catestrophic for performance and consequently GHC.ForeignPtr exports the old,
touch#-based implementation of withForeignPtr as unsafeWithForeignPtr.
This allows performance sensitive code to avoid boxing when it is known that the
continuation is not certain to diverge. Since this operation is unsafe in the
presence of known-divergent continuations, users are strong encouraged to
use this operation sparingly and only in cases where the continuation is
obviously not divergent.
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.
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 IO newtype here. For instance, we treat peek as a
function of type State# RealWorld -> (# State# RealWorld, a #) (i.e. the
representation of IO a)) instead of IO a. We will continue this
pragmatic abuse of notation below.↩︎
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.
]]>The GHC developers are very happy to announce the availability of the second alpha release in the 9.2.1 series. Binary distributions, source distributions, and documentation are available from downloads.haskell.org.
GHC 9.2 will bring a number of exciting features including:
Many changes in the area of records, including the new
RecordDotSyntax and NoFieldSelectors language extensions, as well
as Support for DuplicateRecordFields with PatternSynonyms.
Introduction of the new GHC2021 language extension set, giving
users convenient access to a larger set of language extensions which
have been long considered stable.
Merge of ghc-exactprint into the GHC tree, providing infrastructure
for source-to-source program rewriting out-of-the-box.
Introduction of a BoxedRep RuntimeRep, allowing for polymorphism
over levity of boxed objects (#17526)
Implementation of the UnliftedDataTypes extension, allowing
users to define types which do not admit lazy evaluation
The new -hi profiling mechanism which provides significantly improved insight into thunk leaks.
Support for the ghc-debug out-of-process heap inspection
library
Support for profiling of pinned objects with the cost-centre profiler (#7275)
Introduction of Haddock documentation support in TemplateHaskell (#5467)
Proper support for impredicative types in the form of Quick-Look impredicativity.
A native code generator backend for AArch64.
This pre-release brings nearly 50 fixes relative to the first alpha, although the long-awaited ARM NCG backend hasn’t quite landed yet.
As always, do give this a try and open a ticket if you see anything amiss.
Happy testing!
]]>The GHC developers are very happy to announce the availability of the first alpha release in the 9.2.1 series. Binary distributions, source distributions, and documentation are available from downloads.haskell.org.
GHC 9.2 will bring a number of exciting features including:
Many changes in the area of records, including the new
RecordDotSyntax and NoFieldSelectors language extensions, as well
as Support for DuplicateRecordFields with PatternSynonyms.
Introduction of the new GHC2021 language extension set, giving
users convenient access to a larger set of language extensions which
have been long considered stable.
Merge of ghc-exactprint into the GHC tree, providing infrastructure
for source-to-source program rewriting out-of-the-box.
Introduction of a BoxedRep RuntimeRep, allowing for polymorphism
over levity of boxed objects (#17526)
Implementation of the UnliftedDataTypes extension, allowing
users to define types which do not admit lazy evaluation
The new -hi profiling mechanism which provides significantly improved insight into thunk leaks.
Support for the ghc-debug out-of-process heap inspection
library
Support for profiling of pinned objects with the cost-centre profiler (#7275)
Introduction of Haddock documentation support in TemplateHaskell (#5467)
In addition, the final 9.2.1 release will bring a new native code generator for ARM, providing fast, first-class for Haskell on Apple ARM hardware, although this functionality is not yet present in this alpha.
As always, do give this a try and open a ticket if you see anything amiss.
Happy testing!
]]>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:
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.
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.
Point (2) above has been particularly thorny due to the interaction
between Darwin’s ABI and GHC’s historically-simplistic way of representing
sub-word size integer types (e.g. Word8). The problem arises from the
definition of sub-word size types in base. For instance, Word8 is defined
as
data Word8 = W8# Word#This means that, from the perspective of the compiler, Word8 is simply a
word-sized (e.g. 64-bit) value; the fact that only the bottom 8-bits contains
useful information has no representation in the type system. Until now this
scheme has served us fine. However, this changes with Darwin/ARM,
which defines a calling convention which is sensitive to argument width.
This means that foreign calls like,
foreign import ccall "f" f :: Word8 -> IO ()are treated incorrectly under this scheme on ARM/Darwin.
Fixing the above issue correctly requires teaching GHC about the representation
of sub-word size types. Thankfully, the first step in this direction was
already taken several releases ago with the introduction of unlifted
sub-word-size integer types (as described in
GHC Proposal 74).
However, there is still a fair amount of work that remains. First, we must
rework the lifted types defined by base to take advantage of these
sub-word-size types:
-- today we have:
data Word8 = W8# Word#
-- in the glorious future we will have:
data Word8 = W8# Word8#However, this change in isolation ends breaking quite a bit of code since many
of GHC’s primops primops are still defined in terms of Word#. For instance,
in GHC 9.0 the primop for reading a Word8 from a ByteArray has the type:
indexWord8Array# :: ByteArray# -> Int# -> Word#Consequently, a common idiom like W8# (indexWord8Array# byteArray n)
will break if we were to merely make above change to Word8. It turns out that we
can mitigate most of this by changing the primop definitions as well. That is,
-- today:
indexWord8Array# :: ByteArray# -> Int# -> Word#
-- the glorious future:
indexWord8Array# :: ByteArray# -> Int# -> Word8#Note only does this type better reflect the operation’s meaning, but it also
eliminates a significant fraction of the churn required by the lifted-type
change. The return type can help here because most code doesn’t actually care
what the type being returned is, so long as it can be boxed right away by the
corresponding constructor (W8# in this case). We just need the constructor
and primops to agree to preserve that level of compatibility.
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).
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.
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.
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.
]]>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.
]]>The GHC team is very pleased to announce the availability of GHC 9.0.1. Source and binary distributions are available at the usual place.
In addition to numerous bug fixes, GHC 9.0.1 brings a number of new features:
A first cut of the new LinearTypes language extension, allowing use
of linear function syntax and linear record fields.
A new bignum library, ghc-bignum, improving portability and allowing GHC
to be more easily used with integer libraries other than GMP.
Improvements in code generation, resulting in considerable runtime performance improvements in some programs.
Improvements in pattern-match checking, allowing more precise detection of redundant cases and reduced compilation time.
Implementation of the “simplified subsumption” proposal simplifying the type system and paving the way for QuickLook impredicativity in GHC 9.2.
Implementation of the QualifiedDo extension, allowing more
convenient overloading of do syntax.
An experimental new IO manager implementation for Windows platforms, both improving performance and fixing many of the quirks with the old manager built on POSIX-emulation.
Improvements in compilation time.
And many more. See the release notes for a full accounting of the changes in this release.
As always, feel free to report any issues you encounter via gitlab.haskell.org.
]]>The GHC team is very pleased to announce the availability of the first release candidate of GHC 9.0.1 series. Source and binary distributions are available at the usual place.
This release candidate comes quite a bit later than expected after
difficulty finding a performance neutral fix for a critical soundness
bug, #17760. See the migration page for details on the solution, particularly
if you are a library maintainer currently using the touch# primop or
Foreign.ForeignPtr.withForeignPtr.
Nevertheless, this release has nevertheless seen a considerable amount of testing and consequently we hope that this should be the last pre-release before the final release.
In addition to numerous bug fixes, GHC 9.0.1 will bring a number of new features:
A first cut of the new LinearTypes language extension, allowing use
of linear function syntax and linear record fields.
A new bignum library (ghc-bignum), allowing GHC to be more easily
used with integer libraries other than GMP.
Improvements in code generation, resulting in considerable performance improvements in some programs.
Improvements in pattern-match checking, allowing more precise detection of redundant cases and reduced compilation time.
Implementation of the “simplified subsumption” proposal simplifying the type system and paving the way for QuickLook impredicativity in GHC 9.2.
Implementation of the QualifiedDo extension, allowing more
convenient overloading of do syntax.
Improvements in compilation time.
And many more. See the release notes for a full accounting of the changes in this release.
As always, do test this release and open tickets for whatever issues you encounter.
]]>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.
The GHC team is happy to announce the availability of GHC 8.10.2. Source and binary distributions are available at the usual place.
GHC 8.10.2 fixes a number of issues in present in GHC 8.10.1 including:
Fixes a bug in process creation on Windows (#17926).
Fixes a code generation bug resulting in incorrect code generation for foreign calls with complex arguments (#18527)
Fixes a bug causing object merging to fail when the lld linker is in use (#17962)
Introduces a workaround for a Linux kernel bug in the implementation of the timerfd mechanism (#18033).
Fixes a few specialiser regressions (#17810, #18120) as well introduces a variety of miscellaneous specialiser improvements (#16473, #17930, #17966)
Fixes a potential loss of sharing due to left operator sections (#18151).
Fix bootstrapping of GHC with the LLVM backend on x86-64 (#17920).
A few important correctness fixes for the low-latency garbage
collector. Users of --nonmoving-gc are strongly encouraged to upgrade
promptly.
Note that at the moment we still require that macOS Catalina users
exempt the binary distribution from the notarization requirement by
running xattr -cr . on the unpacked tree before running make install.
This situation will hopefully be improved for GHC 9.0.1 with the
resolution of #17418.
The GHC team is proud to announce the release of GHC 8.8.4. The source distribution, binary distributions, and documentation are available at downloads.haskell.org.
Release notes are also available.
This release fixes a handful of issues affecting 8.8.3:
Fixes a bug in process creation on Windows (#17926). Due to this fix we strongly encourage all Windows users to upgrade immediately.
Works around a Linux kernel bug in the implementation of timerfd (#18033)
Fixes a few linking issues affecting ARM
Fixes “missing interface file” error triggered by some uses of
Data.Ord.Ordering (#18185)
Fixes an integer overflow in the compact-normal-form import implementation (#16992)
configure now accepts a --enable-numa flag to enable/disable
numactl support on Linux.
Fixes potentially lost sharing due to the desugaring of left operator sections (#18151).
Fixes a build-system bug resulting in potential miscompilation by unregisteised compilers (#18024)
As always, if anything looks amiss do let us know.
]]>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!
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:
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.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.
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:
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.
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-timings flag. Not only do these logs capture the reason for failure
in the case of erroring builds, but they can be scraped for compiler
performance metrics, allowing us to track compiler performance on a diverse
set of real-world code.
These can be fed to downstream tools, allowing us to better understand and record the evolution of GHC’s performance and correctness.
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.
There are a few things that remain to be done:
Work out how to handle tracking of persistent breakage; for instance, we want a responsible party to be notified when a package initially breaks (e.g. when a breaking change is merged to GHC) but not in every subsequent build.
Determine a sustainable means to keep this patch-set up-to-date. Thusfar this has fallen on the shoulders of a few dedicated contributors (thanks Ryan Scott!), but to make this work in the long term we need a more diverse group of maintainers. If this sort of work sounds like something you would be interested in contributing to, please do be in touch!
Furthermore, we might consider making authors of GHC patches which break
head.hackage responsible for updating the broken packages, further
spreading the maintenance load.
Currently our testing is limited to testing that compilation of the packages does not fail. However, we might also consider extending this to running package testsuites in select cases. This would give us further assurance of correctness, although would likely significantly increase maintenance and computational cost.
Finally, I would like to acknowledge Herbert Valerio Riedel whose vision for
the head.hackage patch-set evolved into the infrastructure described above.
Cheers,
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.
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.
The ARM architecture represents an overwhelming majority of CPUs on this planet. Furthermore, there are now GHC users (myself included) who stake their livelihood on being able to deploy their Haskell applications on ARM-based platforms. As such, the task of making GHC run well on ARM has never been more important.
This task has a long history, being the project that brought me to GHC development many years ago, and reliability of support has varied greatly from release-to-release. As I’ve had a few people ask about the state of GHC-on-ARM over the past few months, I thought now might be a good time to write some words on the state of things.
In short, things are in significantly better shape today than they were back in 2012. There are a few reasons for this:
LLVM and binutils have stabilized significantly on ARM (this wasn’t
always
the case)
ARM support in GHC’s linker is now mostly complete
(since GHC 8.10) GHC’s runtime system is much more careful about ensuring memory ordering (see !1128)
Consequently, it now fairly easy to bring up GHC on ARMv7 and ARMv8 machines.
By far, the most readily-available ARM hardware running a standard Linux distribution is the Raspberry Pi. Moreover, with more recent hardware iterations (e.g. Raspberry Pi 4) the hardware is capable enough to run GHC itself without incurring too much of a pain due to long compile times.
Most Raspberry Pi users will be using the Raspbian Debian variant. Unfortunately, due to some creative packaging decisions on the part of the Raspbian maintainers, installing GHC under Raspbian requires a bit of manual intervention.
First, we need to install LLVM 9 (which GHC uses for code generation on ARM):
$ sudo apt-get install llvm-9Next we can fetch and install the GHC 8.10.1 ARMv7 binary distribution for Debian 9:
$ wget http://downloads.haskell.org/~ghc/8.10.1/ghc-8.10.1-armv7-deb9-linux.tar.xz
$ tar -xf ghc-8.10.1-armv7-deb9-linux.tar.gz
$ cd ghc-8.10.1
$ ./configure CONF_CC_OPTS_STAGE2="-marm -march=armv7-a" CFLAGS="-marm -march=armv7-a"
$ sudo make 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.
As always, there is plenty left to be done.
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.
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!
Continuous integration for ARM would not be possible without hosted hardware contributions provided by Packet through the Works on ARM program.
]]>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:
gdb and examines some of the limitations of this style of debug
information.perf
utility can be used on GHC-compiled programs.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:
59fw_info) more reflective of
their origin in the source programstg_PAP_apply) don’t have accurate unwind
information, leading to truncated backtraces in some cases (#17627)GHC.ExecutionStackperf, and gdbAs 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.
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.
As noted in part 4, GHC’s current execution
model on x86 precludes use of perf record’s call-graph profiling
functionality. The most promising avenue to fix this would be to rework
GHC to use the native stack pointer register to track the Haskell stack
(#8272). This would potentially carry a few benefits:
it would enable use of native profiling tools
the native code generator could use the PUSH and POP
instructions, which may be more concise or better optimised in the
microarchitecture than our current stack manipulation strategy
However, there are also a few tricky points:
LLVM makes very strong assumptions about the nature of the stack; consequently, moving the LLVM backend to this scheme may be non-trivial.
the System V ABI requires that the stack always have a small region above the stack pointer (called the “red zone”) which code can use for temporary storage. GHC would need to ensure this before calling into foreign code.
There is some interesting discussion surrounding this idea in #8272 and GHC Proposal MR #17.
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.
Most imperative compilers produce debug information that allow debuggers display and modify in-scope variables and their values. In principle GHC could also provide such support. However, doing so in a way that will be useful in simplified programs would be quite non-trivial. For instance, consider the program:
f :: (Int, String) -> Int
f (x, _) = x + 4GHC’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:
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.
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.
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).
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.
]]>This post is the fourth of a series examining GHC’s support for DWARF debug information and the tooling that this support enables:
gdb and examines some of the limitations of this style of debug
information.perf
utility can be used on GHC-compiled programs.perfThe 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.
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.
This post is the third of a series examining GHC’s support for DWARF debug information and the tooling that this support enables:
gdb and examines some of the limitations of this style of debug
information.perf
utility can be used on GHC-compiled programs.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:
SIGQUIT signalGHC.ExecutionStack interface in baseIn 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.
The runtime’s unwinding support can also be invoked from Haskell programs via the GHC.ExecutionStack interface. This provides:
-- | A source location.
data Location = {- ... -}
-- | Returns a stack trace of the calling thread or 'Nothing'
-- if the runtime system lacks libdw support.
getStackTrace :: IO (Maybe [Location])In the future we would also like to provide
getThreadStackTrace :: ThreadId -> IO (Maybe [Location])although this is an outstanding task.
This could be used in a number of ways:
when throwing an exception, one could capture the current stack for use in diagnostics output.
with getThreadStackTrace a monitoring library like ekg might
provide the ability to enumerate the program’s threads and
introspect on what they are up to.
We’ll look at (1) in greater detail below.
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:
catchWithLocation :: IO a -> (e -> Maybe [Location] -> IO a) -> IO aAbove 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 SIGQUIT signal to dump a backtrace
originates from the Java virtual machine implementations, where this
has been long available. GHC currently follows this precedent
although some people believe that SIGQUIT should be used for…
quitting. Do let us know on #17451 if you feel should we should
reconsider the choice to follow Java on this point.↩︎
This post is the second of a series examining GHC’s support for DWARF debug information and the tooling that this support enables:
gdb and examines some of the limitations of this style of debug
information.perf
utility can be used on GHC-compiled programs.gdb on Haskell programsgdb 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:
rts_evalLazyIO)_rts_stgzuupdzuframe_ret)ghczmprim_GHCziClasses_zdfEqBoolzuzdczeze_info)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.
As noted above, GHC backtraces can at times be slightly surprising. To see why, consider the simple program,
f :: [Int] -> Int
f = sum . map (* 42)The code generated for this function (when compiled with -O) will
inevitably contain a multiplication instruction and an addition
instruction. However, which source location should these be attributed
to 1? One might say f, or somewhere in Data.List.sum, or
somewhere in foldl (which sum is defined in terms of). Moreover,
these sets of options can grow to be quite large, particularly in cases
where stream fusion is involved.
Unfortunately, the DWARF specification requires that GHC choose precisely one of these locations when producing debug information. At the moment GHC uses heuristics to choose from among the options, but these heuristics, like all heuristics, can sometimes produce less than helpful results. GHC can also emit an extended DWARF form which encodes the entire set of source locations. However, there is currently widely available tooling which can consume this information.
In addition to the above wrinkle there is another feature of GHC’s
produced code that poses a challenge when producing debug information:
tail calls. In a language lacking tail calls, a stack frame typically
contains a pointer to the instruction following the function call that
pushed the frame. This serves as the address to which execution will
return after the callee finishes and is guaranteed to be in the same
procedure as the call itself. For this reason, stack backtraces always
reflect the history of a program’s execution. That is, a stack
containing the frames f; g; h means:
f called gg called hh is currently executingHowever, tail calls break this model. For instance, consider the Haskell function:
tail_caller :: [Int] -> Int
tail_caller xs = sum xs
sum :: [Int] -> Int
sum xs = foldl' (+) 0 xsWithout 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.
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.↩︎