<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"
    xmlns:dc="http://purl.org/dc/elements/1.1/">
    <channel>
        <title>GHC Developer blog</title>
        <link>http://haskell.org/ghc</link>
        <description><![CDATA[]]></description>
        <atom:link href="http://haskell.org/ghc/rss.xml" rel="self"
                   type="application/rss+xml" />
        <lastBuildDate>Fri, 27 Mar 2026 00:00:00 UT</lastBuildDate>
        <item>
    <title>GHC 9.12.4 is now available</title>
    <link>http://haskell.org/ghc/blog/20260327-ghc-9.12.4-released.html</link>
    <description><![CDATA[<h1>GHC 9.12.4 is now available</h1>
<h4 class="text-muted">wz1000 - 2026-03-27</h4>

<p>The GHC developers are very pleased to announce the release of GHC 9.12.4.
Binary distributions, source distributions, and documentation are available at
<a href="https://downloads.haskell.org/ghc/9.12.4">downloads.haskell.org</a> and via <a href="https://www.haskell.org/ghcup/">GHCup</a>.</p>
<p>GHC 9.12.4 is a bug-fix release fixing many issues of a variety of
severities and scopes, including:</p>
<ul>
<li><p>Fixed a critical code generation regression where sub-word division produced
incorrect results (<a href="https://gitlab.haskell.org/ghc/ghc/issues/26711">#26711</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/26668">#26668</a>), similar to the bug fixed in 9.12.2</p></li>
<li><p>Numerous fixes for register allocation bugs, preventing data corruption
when spilling and reloading registers
(<a href="https://gitlab.haskell.org/ghc/ghc/issues/26411">#26411</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/26526">#26526</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/26537">#26537</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/26542">#26542</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/26550">#26550</a>)</p></li>
<li><p>Fixes for several compiler crashes, including issues with CSE (<a href="https://gitlab.haskell.org/ghc/ghc/issues/25468">#25468</a>),
and the simplifier(<a href="https://gitlab.haskell.org/ghc/ghc/issues/26681">#26681</a>), implicit parameters (<a href="https://gitlab.haskell.org/ghc/ghc/issues/26451">#26451</a>), and the type-class
specialiser (<a href="https://gitlab.haskell.org/ghc/ghc/issues/26682">#26682</a>)</p></li>
<li><p>Fixed cast worker/wrapper incorrectly firing on INLINE functions (<a href="https://gitlab.haskell.org/ghc/ghc/issues/26903">#26903</a>)</p></li>
<li><p>Fixed LLVM backend miscompilation of bit manipulation operations
(<a href="https://gitlab.haskell.org/ghc/ghc/issues/20645">#20645</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/26065">#26065</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/26109">#26109</a>)</p></li>
<li><p>Fixed associated type family and data family instance changes not triggering
recompilation (<a href="https://gitlab.haskell.org/ghc/ghc/issues/26183">#26183</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/26705">#26705</a>)</p></li>
<li><p>Fixed negative type literals causing the compiler to hang (<a href="https://gitlab.haskell.org/ghc/ghc/issues/26861">#26861</a>)</p></li>
<li><p>Improvements to determinism of compiler output (<a href="https://gitlab.haskell.org/ghc/ghc/issues/26846">#26846</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/26858">#26858</a>)</p></li>
<li><p>Fixes for eventlog shutdown deadlocks (<a href="https://gitlab.haskell.org/ghc/ghc/issues/26573">#26573</a>)
and lost wakeups in the RTS (<a href="https://gitlab.haskell.org/ghc/ghc/issues/26324">#26324</a>)</p></li>
<li><p>Fixed split sections support on Windows (<a href="https://gitlab.haskell.org/ghc/ghc/issues/26696">#26696</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/26494">#26494</a>) and the LLVM backend (<a href="https://gitlab.haskell.org/ghc/ghc/issues/26770">#26770</a>)</p></li>
<li><p>Fixes for the bytecode compiler, PPC native code generator, and Wasm backend</p></li>
<li><p>The runtime linker now supports COMMON symbols (<a href="https://gitlab.haskell.org/ghc/ghc/issues/6107">#6107</a>)</p></li>
<li><p>Improved backtrace support: backtraces for <code>error</code> exceptions are now
evaluated at throw time</p></li>
<li><p><code>NamedDefaults</code> now correctly requires the class to be standard or have an
in-scope default declaration, and handles poly-kinded classes (<a href="https://gitlab.haskell.org/ghc/ghc/issues/25775">#25775</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/25778">#25778</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/25882">#25882</a>)</p></li>
<li><p>… and many more</p></li>
</ul>
<p>A full accounting of these fixes can be found in the <a href="https://gitlab.haskell.org/ghc/ghc/-/blob/ghc-9.12/docs/users_guide/9.12.4-notes.rst?ref_type=heads&amp;plain=1">release notes</a>. As
always, GHC’s release status, including planned future releases, can be found on
the GHC Wiki <a href="https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status">status</a>.</p>
<p>GHC development is sponsored by:</p>
<ul>
<li><a href="https://juspay.com/">Juspay</a></li>
<li><a href="https://qbaylogic.com/">QBayLogic</a></li>
<li><a href="https://www.channable.com/">Channable</a></li>
<li><a href="https://haskell.foundation/">Haskell Foundation</a></li>
<li><a href="https://serokell.io/">Serokell</a></li>
<li><a href="https://well-typed.com/">Well-Typed</a></li>
<li><a href="https://www.tweag.io/">Tweag</a></li>
<li><a href="https://www.dotcom-monitor.com/">Dotcom-Monitor</a></li>
<li><a href="https://www.loadview-testing.com/">LoadView</a></li>
<li><a href="https://webhostingbuddy.com/">Web Hosting Buddy</a></li>
<li><a href="https://www.findmyelectric.com/">Find My Electric</a></li>
<li><a href="https://www.sc.com">Standard Chartered</a></li>
<li><a href="https://upcloud.com">UpCloud</a></li>
<li><a href="https://mercury.com">Mercury</a></li>
</ul>
<p>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.</p>
<p>As always, do give this release a try and open a <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/new">ticket</a> if you see
anything amiss.</p>
]]></description>
    <pubDate>Fri, 27 Mar 2026 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20260327-ghc-9.12.4-released.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC 9.12.4-rc1 is now available</title>
    <link>http://haskell.org/ghc/blog/20260313-ghc-9.12.4-rc1-released.html</link>
    <description><![CDATA[<h1>GHC 9.12.4-rc1 is now available</h1>
<h4 class="text-muted">wz1000 - 2026-03-13</h4>

<p>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 <a href="https://downloads.haskell.org/ghc/9.12.4-rc1">downloads.haskell.org</a> and
via <a href="https://www.haskell.org/ghcup/">GHCup</a>.</p>
<p>GHC 9.12.4 is a bug-fix release fixing many issues of a variety of
severities and scopes, including:</p>
<ul>
<li>Fixed a critical code generation regression where sub-word division produced
incorrect results (<a href="https://gitlab.haskell.org/ghc/ghc/issues/26711">#26711</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/26668">#26668</a>), similar to the bug fixed in 9.12.2</li>
<li>Numerous fixes for register allocation bugs, preventing data corruption
when spilling and reloading registers
(<a href="https://gitlab.haskell.org/ghc/ghc/issues/26411">#26411</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/26526">#26526</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/26537">#26537</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/26542">#26542</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/26550">#26550</a>)</li>
<li>Fixes for several compiler crashes, including issues with
CSE (<a href="https://gitlab.haskell.org/ghc/ghc/issues/25468">#25468</a>), SetLevels (<a href="https://gitlab.haskell.org/ghc/ghc/issues/26681">#26681</a>),
implicit parameters (<a href="https://gitlab.haskell.org/ghc/ghc/issues/26451">#26451</a>), and the type-class specialiser (<a href="https://gitlab.haskell.org/ghc/ghc/issues/26682">#26682</a>)</li>
<li>Fixed cast worker/wrapper incorrectly firing on INLINE functions (<a href="https://gitlab.haskell.org/ghc/ghc/issues/26903">#26903</a>)</li>
<li>Fixed LLVM backend miscompilation of bit manipulation operations
(<a href="https://gitlab.haskell.org/ghc/ghc/issues/20645">#20645</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/26065">#26065</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/26109">#26109</a>)</li>
<li>Fixed associated type family and data family instance changes not triggering
recompilation (<a href="https://gitlab.haskell.org/ghc/ghc/issues/26183">#26183</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/26705">#26705</a>)</li>
<li>Fixed negative type literals causing the compiler to hang (<a href="https://gitlab.haskell.org/ghc/ghc/issues/26861">#26861</a>)</li>
<li>Improvements to determinism of compiler output (<a href="https://gitlab.haskell.org/ghc/ghc/issues/26846">#26846</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/26858">#26858</a>)</li>
<li>Fixes for eventlog shutdown deadlocks (<a href="https://gitlab.haskell.org/ghc/ghc/issues/26573">#26573</a>)
and lost wakeups in the RTS (<a href="https://gitlab.haskell.org/ghc/ghc/issues/26324">#26324</a>)</li>
<li>Fixed split sections support on Windows (<a href="https://gitlab.haskell.org/ghc/ghc/issues/26696">#26696</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/26494">#26494</a>) and the LLVM backend (<a href="https://gitlab.haskell.org/ghc/ghc/issues/26770">#26770</a>)</li>
<li>Fixes for the bytecode compiler, PPC native code generator, and Wasm backend</li>
<li>The runtime linker now supports COMMON symbols (<a href="https://gitlab.haskell.org/ghc/ghc/issues/6107">#6107</a>)</li>
<li>Improved backtrace support: backtraces for <code>error</code> exceptions are now
evaluated at throw time</li>
<li><code>NamedDefaults</code> now correctly requires the class to be standard or have an
in-scope default declaration, and handles poly-kinded classes (<a href="https://gitlab.haskell.org/ghc/ghc/issues/25775">#25775</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/25778">#25778</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/25882">#25882</a>)</li>
<li>… and many more</li>
</ul>
<p>A full accounting of these fixes can be found in the</p>
<p><a href="https://gitlab.haskell.org/ghc/ghc/-/blob/ghc-9.12/docs/users_guide/9.12.4-notes.rst?ref_type=heads&amp;plain=1">release notes</a>. As always, GHC’s release status, including planned future
releases, can be found on the GHC Wiki <a href="https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status">status</a>.</p>
<p>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.</p>
<p>GHC development is sponsored by:</p>
<ul>
<li><a href="https://juspay.com/">Juspay</a></li>
<li><a href="https://qbaylogic.com/">QBayLogic</a></li>
<li><a href="https://www.channable.com/">Channable</a></li>
<li><a href="https://haskell.foundation/">Haskell Foundation</a></li>
<li><a href="https://serokell.io/">Serokell</a></li>
<li><a href="https://well-typed.com/">Well-Typed</a></li>
<li><a href="https://www.tweag.io/">Tweag</a></li>
<li><a href="https://www.dotcom-monitor.com/">Dotcom-Monitor</a></li>
<li><a href="https://www.loadview-testing.com/">LoadView</a></li>
<li><a href="https://webhostingbuddy.com/">Web Hosting Buddy</a></li>
<li><a href="https://www.findmyelectric.com/">Find My Electric</a></li>
<li><a href="https://www.sc.com">Standard Chartered</a></li>
<li><a href="https://upcloud.com">UpCloud</a></li>
<li><a href="https://mercury.com">Mercury</a></li>
</ul>
<p>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.</p>
<p>As always, do give this release a try and open a <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/new">ticket</a> if you see
anything amiss.</p>
]]></description>
    <pubDate>Fri, 13 Mar 2026 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20260313-ghc-9.12.4-rc1-released.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC 9.12.3 is now available</title>
    <link>http://haskell.org/ghc/blog/20251227-ghc-9.12.3-released.html</link>
    <description><![CDATA[<h1>GHC 9.12.3 is now available</h1>
<h4 class="text-muted">zubin - 2025-12-27</h4>

<p>The GHC developers are very pleased to announce the release of GHC 9.12.3.
Binary distributions, source distributions, and documentation are available at
<a href="https://downloads.haskell.org/ghc/9.12.3">downloads.haskell.org</a>.</p>
<p>GHC 9.12.3 is a bug-fix release fixing many issues of a variety of
severities and scopes, including:</p>
<ul>
<li>Fix a number of crashes and miscompilations in the compiler frontend (<a href="https://gitlab.haskell.org/ghc/ghc/issues/25004">#25004</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/25960">#25960</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/26256">#26256</a>)</li>
<li>Improvements to efficiency of the runtime linker (<a href="https://gitlab.haskell.org/ghc/ghc/issues/26009">#26009</a>)</li>
<li>Fixes for several bugs in bytecode generation and the bytecode interpreter (<a href="https://gitlab.haskell.org/ghc/ghc/issues/23210">#23210</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/25975">#25975</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/25750">#25750</a>)</li>
<li>Fixes for bugs in the handling of WHITEHOLEs in the RTS (<a href="https://gitlab.haskell.org/ghc/ghc/issues/26204">#26204</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/26205">#26205</a>)</li>
<li>Fix incorrect code generation for SSE vector operations (<a href="https://gitlab.haskell.org/ghc/ghc/issues/25859">#25859</a>)</li>
<li>Fix a use-after-free in the Windows runtime linker (<a href="https://gitlab.haskell.org/ghc/ghc/issues/26613">#26613</a>)</li>
<li>Support for synchronous JSFFI exports for the wasm backend</li>
<li>And many more!</li>
</ul>
<p>A full accounting of these fixes can be found in the
<a href="https://downloads.haskell.org/~ghc/9.12.3/docs/users_guide/9.12.3-notes.html">release notes</a>. As always, GHC’s release status, including planned future
releases, can be found on the GHC Wiki <a href="https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status">status</a>.</p>
<p>GHC development is sponsored by:</p>
<ul>
<li><a href="https://juspay.com/">Juspay</a></li>
<li><a href="https://qbaylogic.com/">QBayLogic</a></li>
<li><a href="https://www.channable.com/">Channable</a></li>
<li><a href="https://haskell.foundation/">Haskell Foundation</a></li>
<li><a href="https://serokell.io/">Serokell</a></li>
<li><a href="https://well-typed.com/">Well-Typed</a></li>
<li><a href="https://www.tweag.io/">Tweag</a></li>
<li><a href="https://www.dotcom-monitor.com/">Dotcom-Monitor</a></li>
<li><a href="https://www.loadview-testing.com/">LoadView</a></li>
<li><a href="https://webhostingbuddy.com/">Web Hosting Buddy</a></li>
<li><a href="https://www.findmyelectric.com/">Find My Electric</a></li>
<li><a href="https://www.sc.com">Standard Chartered</a></li>
<li><a href="https://upcloud.com">UpCloud</a></li>
<li><a href="https://mercury.com">Mercury</a></li>
</ul>
<p>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.</p>
<p>As always, do give this release a try and open a <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/new">ticket</a> if you see
anything amiss.</p>
]]></description>
    <pubDate>Sat, 27 Dec 2025 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20251227-ghc-9.12.3-released.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC 9.14.1 is now available</title>
    <link>http://haskell.org/ghc/blog/20251219-ghc-9.14.1-released.html</link>
    <description><![CDATA[<h1>GHC 9.14.1 is now available</h1>
<h4 class="text-muted">zubin - 2025-12-19</h4>

<p>The GHC developers are very pleased to announce the release of GHC 9.14.1.
Binary distributions, source distributions, and documentation are available at
<a href="https://downloads.haskell.org/ghc/9.14.1">downloads.haskell.org</a>.</p>
<p>GHC 9.14 brings a number of new features and improvements, including:</p>
<ul>
<li><p>Significant improvements in specialisation:</p>
<ul>
<li>The <code>SPECIALISE</code> pragma now allows use of type application syntax</li>
<li>The <code>SPECIALISE</code> pragma can be used to specialise for expression arguments
as well as type arguments.</li>
<li>Specialisation is now considerably more reliable in the presence of
<code>newtype</code>s</li>
</ul></li>
<li><p>Significant GHCi improvements including:</p>
<ul>
<li>Correctness and performance improvements in the bytecode interpreter</li>
<li>Features in the GHCi debugger</li>
<li>Support for multiple home units in GHCi</li>
</ul></li>
<li><p>Implementation of the <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0682-explicit-level-imports.rst">Explicit Level Imports proposal</a></p></li>
<li><p><code>RequiredTypeArguments</code> can now be used in more contexts</p></li>
<li><p>Greatly improved <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/25030">SSE/AVX2 support</a> in the x86 native code generator backend</p></li>
<li><p>Initial native code generator support for LoongArch</p></li>
<li><p>The WebAssembly backend now supports <a href="https://www.tweag.io/blog/2025-04-17-wasm-ghci-browser/">evaluation via the interpreter</a>, allowing
GHCi and TemplateHaskell evaluation, including <code>foreign import javascript</code>
usage from within the browser</p></li>
<li><p>A new primop <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/26218"><code>annotateStack#</code></a> for pushing arbitrary data onto the call stack
for later extraction when decoding stack traces</p></li>
<li><p><a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0516-incomplete-record-selectors.rst"><code>-Wincomplete-record-selectors</code></a> is now part of <code>-Wall</code>. Libraries compiled
with <code>-Werror</code> may need adjustment.</p></li>
<li><p>A major update of the Windows toolchain</p></li>
<li><p>Improved compatibility with <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/26166">macOS Tahoe</a></p></li>
<li><p>… and many more</p></li>
</ul>
<p>A full accounting of changes can be found in the <a href="https://downloads.haskell.org/ghc/9.14.1/docs/users_guide/9.14.1-notes.html">release notes</a>.
See the <a href="https://gitlab.haskell.org/ghc/ghc/-/wikis/migration/9.14">migration guide</a> for guidance on migrating programs to this release.</p>
<p>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
<a href="https://gitlab.haskell.org/ghc/ghc/-/issues/26329"><span>#26329</span></a>. Users needing more aggressive specialisation can explicitly
enable this feature with the <code>-fpolymorphic-specialisation</code> flag. Depending
upon our experience with 9.14.1, we may enable this feature by default in a
later minor release.</p>
<p>GHC development is sponsored by:</p>
<ul>
<li><a href="https://juspay.com/">Juspay</a></li>
<li><a href="https://qbaylogic.com/">QBayLogic</a></li>
<li><a href="https://www.channable.com/">Channable</a></li>
<li><a href="https://haskell.foundation/">Haskell Foundation</a></li>
<li><a href="https://serokell.io/">Serokell</a></li>
<li><a href="https://well-typed.com/">Well-Typed</a></li>
<li><a href="https://www.tweag.io/">Tweag</a></li>
<li><a href="https://www.dotcom-monitor.com/">Dotcom-Monitor</a></li>
<li><a href="https://www.loadview-testing.com/">LoadView</a></li>
<li><a href="https://webhostingbuddy.com/">Web Hosting Buddy</a></li>
<li><a href="https://www.findmyelectric.com/">Find My Electric</a></li>
<li><a href="https://www.sc.com">Standard Chartered</a></li>
<li><a href="https://upcloud.com">UpCloud</a></li>
</ul>
<p>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.</p>
<p>As always, do give this release a try and open a <a href="https://gitlab.haskell.org/ghc/homepage/-/issues/new">ticket</a> if you see
anything amiss.</p>
]]></description>
    <pubDate>Fri, 19 Dec 2025 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20251219-ghc-9.14.1-released.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC 9.12.3-rc3 is now available</title>
    <link>http://haskell.org/ghc/blog/20251211-ghc-9.12.3-rc3-released.html</link>
    <description><![CDATA[<h1>GHC 9.12.3-rc3 is now available</h1>
<h4 class="text-muted">wz1000 - 2025-12-11</h4>

<p>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 <a href="https://downloads.haskell.org/ghc/9.12.3-rc3">downloads.haskell.org</a> and
via <a href="https://www.haskell.org/ghcup/">GHCup</a>.</p>
<p>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
<a href="https://gitlab.haskell.org/ghc/ghc/-/blob/ghc-9.12/docs/users_guide/9.12.3-notes.rst?ref_type=heads&amp;plain=1">release notes</a>. As always, GHC’s release status, including planned future
releases, can be found on the GHC Wiki <a href="https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status">status</a>.</p>
<p>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.</p>
<p>The changes from the first release candidate are</p>
<ul>
<li>Fix use after free on windows due to a linker optimisation introduced in an earlier RC (<a href="https://gitlab.haskell.org/ghc/ghc/issues/26613">#26613</a>)</li>
<li>A fix for a bug in the configure script which result in the LLVM toolchain not being detected in certain situations (<a href="https://gitlab.haskell.org/ghc/ghc/issues/26564">#26564</a>)</li>
<li>Fixes for the WASM backend</li>
</ul>
<p>GHC development is sponsored by:</p>
<ul>
<li><a href="https://juspay.com/">Juspay</a></li>
<li><a href="https://qbaylogic.com/">QBayLogic</a></li>
<li><a href="https://www.channable.com/">Channable</a></li>
<li><a href="https://haskell.foundation/">Haskell Foundation</a></li>
<li><a href="https://serokell.io/">Serokell</a></li>
<li><a href="https://well-typed.com/">Well-Typed</a></li>
<li><a href="https://www.tweag.io/">Tweag</a></li>
<li><a href="https://www.dotcom-monitor.com/">Dotcom-Monitor</a></li>
<li><a href="https://www.loadview-testing.com/">LoadView</a></li>
<li><a href="https://webhostingbuddy.com/">Web Hosting Buddy</a></li>
<li><a href="https://www.findmyelectric.com/">Find My Electric</a></li>
<li><a href="https://www.sc.com">Standard Chartered</a></li>
<li><a href="https://upcloud.com">UpCloud</a></li>
</ul>
<p>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.</p>
<p>As always, do give this release a try and open a <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/new">ticket</a> if you see
anything amiss.</p>
]]></description>
    <pubDate>Thu, 11 Dec 2025 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20251211-ghc-9.12.3-rc3-released.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC 9.14.1-rc3 is now available</title>
    <link>http://haskell.org/ghc/blog/20251201-ghc-9.14.1-rc3-released.html</link>
    <description><![CDATA[<h1>GHC 9.14.1-rc3 is now available</h1>
<h4 class="text-muted">zubin - 2025-12-01</h4>

<p>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 <a href="https://downloads.haskell.org/ghc/9.14.1-rc3">downloads.haskell.org</a>.</p>
<p>The changes from the second release candidate are:</p>
<ul>
<li>Fix RTS segfaults in certain situations (<a href="https://gitlab.haskell.org/ghc/ghc/issues/26495">#26495</a>)</li>
<li>Fix use after free on windows due to a linker optimisation introduced in an earlier RC (<a href="https://gitlab.haskell.org/ghc/ghc/issues/26613">#26613</a>)</li>
</ul>
<p>GHC 9.14 will bring a number of new features and improvements, including:</p>
<ul>
<li><p>Significant improvements in specialisation:</p>
<ul>
<li>The <code>SPECIALISE</code> pragma now allows use of type application syntax</li>
<li>The <code>SPECIALISE</code> pragma can be used to specialise for expression arguments
as well as type arguments.</li>
<li>Specialisation is now considerably more reliable in the presence of
<code>newtype</code>s</li>
</ul></li>
<li><p>Significant GHCi improvements including:</p>
<ul>
<li>Correctness and performance improvements in the bytecode interpreter</li>
<li>Features in the GHCi debugger</li>
<li>Support for multiple home units in GHCi</li>
</ul></li>
<li><p>Implementation of the <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0682-explicit-level-imports.rst">Explicit Level Imports proposal</a></p></li>
<li><p><code>RequiredTypeArguments</code> can now be used in more contexts</p></li>
<li><p>SSE/AVX2 support in the x86 native code generator backend</p></li>
<li><p>A major update of the Windows toolchain and improved compatibility with
macOS Tahoe</p></li>
<li><p>… and many more</p></li>
</ul>
<p>A full accounting of changes can be found in the <a href="https://downloads.haskell.org/ghc/9.14.1-rc3/docs/users_guide/9.14.1-notes.html">release notes</a>. Given the
many specialisation improvements and their potential for regression, we would
very much appreciate testing and performance characterisation on downstream
workloads.</p>
<p>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
<a href="https://gitlab.haskell.org/ghc/ghc/-/issues/26329"><span>#26329</span></a>. Users needing more aggressive specialisation can explicitly
enable this feature with the <code>-fpolymorphic-specialisation</code> flag. Depending
upon our experience with 9.14.1, we may enable this feature by default in a
later minor release.</p>
<p>GHC development is sponsored by:</p>
<ul>
<li><a href="https://juspay.com/">Juspay</a></li>
<li><a href="https://qbaylogic.com/">QBayLogic</a></li>
<li><a href="https://www.channable.com/">Channable</a></li>
<li><a href="https://haskell.foundation/">Haskell Foundation</a></li>
<li><a href="https://serokell.io/">Serokell</a></li>
<li><a href="https://well-typed.com/">Well-Typed</a></li>
<li><a href="https://www.tweag.io/">Tweag</a></li>
<li><a href="https://www.dotcom-monitor.com/">Dotcom-Monitor</a></li>
<li><a href="https://www.loadview-testing.com/">LoadView</a></li>
<li><a href="https://webhostingbuddy.com/">Web Hosting Buddy</a></li>
<li><a href="https://www.findmyelectric.com/">Find My Electric</a></li>
<li><a href="https://www.sc.com">Standard Chartered</a></li>
<li><a href="https://upcloud.com">UpCloud</a></li>
</ul>
<p>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.</p>
<p>As always, do give this release a try and open a <a href="https://gitlab.haskell.org/ghc/homepage/-/issues/new">ticket</a> if you see
anything amiss.</p>
]]></description>
    <pubDate>Mon, 01 Dec 2025 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20251201-ghc-9.14.1-rc3-released.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC 9.12.3-rc2 is now available</title>
    <link>http://haskell.org/ghc/blog/20251111-ghc-9.12.3-rc2-released.html</link>
    <description><![CDATA[<h1>GHC 9.12.3-rc2 is now available</h1>
<h4 class="text-muted">wz1000 - 2025-11-11</h4>

<p>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 <a href="https://downloads.haskell.org/ghc/9.12.3-rc2">downloads.haskell.org</a> and
via <a href="https://www.haskell.org/ghcup/">GHCup</a>.</p>
<p>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
<a href="https://gitlab.haskell.org/ghc/ghc/-/blob/ghc-9.12/docs/users_guide/9.12.3-notes.rst?ref_type=heads&amp;plain=1">release notes</a>. As always, GHC’s release status, including planned future
releases, can be found on the GHC Wiki <a href="https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status">status</a>.</p>
<p>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.</p>
<p>The changes from the first release candidate are</p>
<ul>
<li>Fix a regression resulting in a panic with empty cases (<a href="https://gitlab.haskell.org/ghc/ghc/issues/26442">#26442</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/25960">#25960</a>).</li>
<li>Fix for a potential segfault in the bytecode interpreter (<a href="https://gitlab.haskell.org/ghc/ghc/issues/23210">#23210</a>).</li>
<li>Fix for a regression with tabs not being allowed in string gaps (<a href="https://gitlab.haskell.org/ghc/ghc/issues/26415">#26415</a>).</li>
<li>Fix for a crash with the non-moving GC (<a href="https://gitlab.haskell.org/ghc/ghc/issues/26204">#26204</a>).</li>
<li>A rework of how internal symbols used by the code-generator are handled to
adapt to changes in the Apple toolchain, enabling this release to bootstrap on
macOS 26 Tahoe (<a href="https://gitlab.haskell.org/ghc/ghc/issues/26166">#26166</a>).</li>
</ul>
<p>GHC development is sponsored by:</p>
<ul>
<li><a href="https://juspay.com/">Juspay</a></li>
<li><a href="https://qbaylogic.com/">QBayLogic</a></li>
<li><a href="https://www.channable.com/">Channable</a></li>
<li><a href="https://haskell.foundation/">Haskell Foundation</a></li>
<li><a href="https://serokell.io/">Serokell</a></li>
<li><a href="https://well-typed.com/">Well-Typed</a></li>
<li><a href="https://www.tweag.io/">Tweag</a></li>
<li><a href="https://www.dotcom-monitor.com/">Dotcom-Monitor</a></li>
<li><a href="https://www.loadview-testing.com/">LoadView</a></li>
<li><a href="https://webhostingbuddy.com/">Web Hosting Buddy</a></li>
<li><a href="https://www.findmyelectric.com/">Find My Electric</a></li>
<li><a href="https://www.sc.com">Standard Chartered</a></li>
<li><a href="https://upcloud.com">UpCloud</a></li>
</ul>
<p>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.</p>
<p>As always, do give this release a try and open a <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/new">ticket</a> if you see
anything amiss.</p>
]]></description>
    <pubDate>Tue, 11 Nov 2025 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20251111-ghc-9.12.3-rc2-released.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC 9.14.1-rc2 is now available</title>
    <link>http://haskell.org/ghc/blog/20251104-ghc-9.14.1-rc2-released.html</link>
    <description><![CDATA[<h1>GHC 9.14.1-rc2 is now available</h1>
<h4 class="text-muted">zubin - 2025-11-04</h4>

<p>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 <a href="https://downloads.haskell.org/ghc/9.14.1-rc2">downloads.haskell.org</a>.</p>
<p>The changes from the first release candidate are:</p>
<ul>
<li>Bump the exceptions submodule to 0.10.11</li>
<li>Bump the os-string submodule to 2.0.8</li>
<li>Fix a driver regression causing an infinite loop with cyclic imports</li>
</ul>
<p>GHC 9.14 will bring a number of new features and improvements, including:</p>
<ul>
<li><p>Significant improvements in specialisation:</p>
<ul>
<li>The <code>SPECIALISE</code> pragma now allows use of type application syntax</li>
<li>The <code>SPECIALISE</code> pragma can be used to specialise for expression arguments
as well as type arguments.</li>
<li>Specialisation is now considerably more reliable in the presence of
<code>newtype</code>s</li>
</ul></li>
<li><p>Significant GHCi improvements including:</p>
<ul>
<li>Correctness and performance improvements in the bytecode interpreter</li>
<li>Features in the GHCi debugger</li>
<li>Support for multiple home units in GHCi</li>
</ul></li>
<li><p>Implementation of the <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0682-explicit-level-imports.rst">Explicit Level Imports proposal</a></p></li>
<li><p><code>RequiredTypeArguments</code> can now be used in more contexts</p></li>
<li><p>SSE/AVX2 support in the x86 native code generator backend</p></li>
<li><p>A major update of the Windows toolchain and improved compatibility with
macOS Tahoe</p></li>
<li><p>… and many more</p></li>
</ul>
<p>A full accounting of changes can be found in the <a href="https://downloads.haskell.org/ghc/9.14.1-rc2/docs/users_guide/9.14.1-notes.html">release notes</a>. Given the
many specialisation improvements and their potential for regression, we would
very much appreciate testing and performance characterisation on downstream
workloads.</p>
<p>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
<a href="https://gitlab.haskell.org/ghc/ghc/-/issues/26329"><span>#26329</span></a>. Users needing more aggressive specialisation can explicitly
enable this feature with the <code>-fpolymorphic-specialisation</code> flag. Depending
upon our experience with 9.14.1, we may enable this feature by default in a
later minor release.</p>
<p>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.</p>
<p>As always, do give this release a try and open a <a href="https://gitlab.haskell.org/ghc/homepage/-/issues/new">ticket</a> if you see
anything amiss.</p>
]]></description>
    <pubDate>Tue, 04 Nov 2025 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20251104-ghc-9.14.1-rc2-released.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC 9.14.1-rc1 is now available</title>
    <link>http://haskell.org/ghc/blog/20251030-ghc-9.14.1-rc1-released.html</link>
    <description><![CDATA[<h1>GHC 9.14.1-rc1 is now available</h1>
<h4 class="text-muted">bgamari - 2025-10-30</h4>

<p>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 <a href="https://downloads.haskell.org/ghc/9.14.1-rc1">downloads.haskell.org</a>.</p>
<p>GHC 9.14 will bring a number of new features and improvements, including:</p>
<ul>
<li><p>Significant improvements in specialisation:</p>
<ul>
<li>The <code>SPECIALISE</code> pragma now allows use of type application syntax</li>
<li>The <code>SPECIALISE</code> pragma can be used to specialise for expression arguments
as well as type arguments.</li>
<li>Specialisation is now considerably more reliable in the presence of
<code>newtype</code>s</li>
</ul></li>
<li><p>Significant GHCi improvements including:</p>
<ul>
<li>Correctness and performance improvements in the bytecode interpreter</li>
<li>Features in the GHCi debugger</li>
<li>Support for multiple home units in GHCi</li>
</ul></li>
<li><p>Implementation of the <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0682-explicit-level-imports.rst">Explicit Level Imports proposal</a></p></li>
<li><p><code>RequiredTypeArguments</code> can now be used in more contexts</p></li>
<li><p>SSE/AVX2 support in the x86 native code generator backend</p></li>
<li><p>A major update of the Windows toolchain and improved compatibility with
macOS Tahoe</p></li>
<li><p>… and many more</p></li>
</ul>
<p>A full accounting of changes can be found in the <a href="https://downloads.haskell.org/ghc/9.14.1-rc1/docs/users_guide/9.14.1-notes.html">release notes</a>. Given the
many specialisation improvements and their potential for regression, we would
very much appreciate testing and performance characterisation on downstream
workloads.</p>
<p>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
<a href="https://gitlab.haskell.org/ghc/ghc/-/issues/26329"><span>#26329</span></a>. Users needing more aggressive specialisation can explicitly
enable this feature with the <code>-fpolymorphic-specialisation</code> flag. Depending
upon our experience with 9.14.1, we may enable this feature by default in a
later minor release.</p>
<p>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 (<a href="https://gitlab.haskell.org/ghc/ghc/-/issues/26166"><span>#26166</span></a>) 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.</p>
<p>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.</p>
<p>As always, do give this release a try and open a <a href="https://gitlab.haskell.org/ghc/homepage/-/issues/new">ticket</a> if you see
anything amiss.</p>
]]></description>
    <pubDate>Thu, 30 Oct 2025 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20251030-ghc-9.14.1-rc1-released.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC 9.14.1-alpha3 is now available</title>
    <link>http://haskell.org/ghc/blog/20251007-ghc-9.14.1-alpha3-released.html</link>
    <description><![CDATA[<h1>GHC 9.14.1-alpha3 is now available</h1>
<h4 class="text-muted">bgamari - 2025-10-09</h4>

<p>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 <a href="https://downloads.haskell.org/ghc/9.14.1-alpha3">downloads.haskell.org</a>.</p>
<p>GHC 9.14 will bring a number of new features and improvements, including:</p>
<ul>
<li><p>Significant improvements in specialisation:</p>
<ul>
<li>The <code>SPECIALISE</code> pragma now allows use of type application syntax</li>
<li>The <code>SPECIALISE</code> pragma can be used to specialise for expression arguments
as well as type arguments.</li>
<li>Specialisation is now considerably more reliable in the presence of
<code>newtype</code>s</li>
</ul></li>
<li><p>Significant improvements GHCi including:</p>
<ul>
<li>Correctness and performance improvements in the bytecode interpreter</li>
<li>Features in the GHCi debugger</li>
<li>Support for multiple home units in GHCi</li>
</ul></li>
<li><p>Implementation of the <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0682-explicit-level-imports.rst">Explicit Level Imports proposal</a></p></li>
<li><p><code>RequiredTypeArgments</code> can now be used in more contexts</p></li>
<li><p>SSE/AVX2 support in the x86 native code generator backend</p></li>
<li><p>A major update of the Windows toolchain</p></li>
<li><p>… and many more</p></li>
</ul>
<p>A full accounting of changes can be found in the <a href="https://downloads.haskell.org/ghc/9.14.1-alpha3/docs/users_guide/9.14.1-notes.html">release notes</a>. Given the
many specialisation improvements and their potential for regression, we would
very much appreciate testing and performance characterisation on downstream
workloads.</p>
<p>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
<a href="https://gitlab.haskell.org/ghc/ghc/-/issues/26329"><span>#26329</span></a>. Users needing more aggressive specialisation can explicitly
enable this feature with the <code>-fpolymorphic-specialisation</code> flag. Depending
upon our experience with 9.14.1, we may enable this feature by default in a
later minor release.</p>
<p>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 (<a href="https://gitlab.haskell.org/ghc/ghc/-/issues/26166"><span>#26166</span></a>)
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.</p>
<p>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.</p>
<p>As always, do give this release a try and open a <a href="https://gitlab.haskell.org/ghc/homepage/-/issues/new">ticket</a> if you see
anything amiss.</p>
]]></description>
    <pubDate>Thu, 09 Oct 2025 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20251007-ghc-9.14.1-alpha3-released.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC 9.12.3-rc1 is now available</title>
    <link>http://haskell.org/ghc/blog/20250922-ghc-9.12.3-rc1-released.html</link>
    <description><![CDATA[<h1>GHC 9.12.3-rc1 is now available</h1>
<h4 class="text-muted">wz1000 - 2025-09-22</h4>

<p>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 <a href="https://downloads.haskell.org/ghc/9.12.3-rc1">downloads.haskell.org</a> and
via <a href="https://www.haskell.org/ghcup/">GHCup</a>.</p>
<p>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
<a href="https://gitlab.haskell.org/ghc/ghc/-/blob/ghc-9.12/docs/users_guide/9.12.3-notes.rst?ref_type=heads&amp;plain=1">release notes</a>. As always, GHC’s release status, including planned future
releases, can be found on the GHC Wiki <a href="https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status">status</a>.</p>
<p>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.</p>
<p>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.</p>
<p>As always, do give this release a try and open a <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/new">ticket</a> if you see
anything amiss.</p>
]]></description>
    <pubDate>Mon, 22 Sep 2025 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20250922-ghc-9.12.3-rc1-released.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC 9.14.1-alpha2 is now available</title>
    <link>http://haskell.org/ghc/blog/20250912-ghc-9.14.1-alpha2-released.html</link>
    <description><![CDATA[<h1>GHC 9.14.1-alpha2 is now available</h1>
<h4 class="text-muted">bgamari - 2025-09-12</h4>

<p>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 <a href="https://downloads.haskell.org/ghc/9.14.1-alpha2">downloads.haskell.org</a>.</p>
<p>GHC 9.14 will bring a number of new features and improvements, including:</p>
<ul>
<li><p>Significant improvements in specialisation:</p>
<ul>
<li><p>The <code>SPECIALISE</code> pragma now allows use of type application syntax</p></li>
<li><p>The <code>SPECIALISE</code> pragma can be used to specialise for expression arguments
as well as type arguments.</p></li>
<li><p>Specialisation is now considerably more reliable in the presence of
<code>newtype</code>s</p></li>
</ul></li>
<li><p>Significant improvements in the GHCi debugger</p></li>
<li><p>Record fields can be defined to be non-linear when <code>LinearTypes</code> is enabled.</p></li>
<li><p><code>RequiredTypeArgments</code> can now be used in more contexts</p></li>
<li><p>SSE/AVX2 support in the x86 native code generator backend</p></li>
<li><p>A major update of the Windows toolchain</p></li>
<li><p>… and many more</p></li>
</ul>
<p>A full accounting of changes can be found in the <a href="https://downloads.haskell.org/ghc/9.14.1-alpha2/docs/users_guide/9.14.1-notes.html">release notes</a>. Given the
many specialisation improvements and their potential for regression, we would
very much appreciate testing and performance characterisation on downstream
workloads.</p>
<p>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
<code>-fpolymorphic-specialisation</code> flag. Depending upon our experience with 9.14.1,
we may enable this feature by default in a later minor release.</p>
<p>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.</p>
<p>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.</p>
<p>As always, do give this release a try and open a <a href="https://gitlab.haskell.org/ghc/homepage/-/issues/new">ticket</a> if you see
anything amiss.</p>
]]></description>
    <pubDate>Fri, 12 Sep 2025 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20250912-ghc-9.14.1-alpha2-released.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC 9.10.3 is now available</title>
    <link>http://haskell.org/ghc/blog/20250910-ghc-9.10.3-released.html</link>
    <description><![CDATA[<h1>GHC 9.10.3 is now available</h1>
<h4 class="text-muted">Zubin Duggal - 2025-09-10</h4>

<p>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 <a href="https://downloads.haskell.org/ghc/9.10.3">downloads.haskell.org</a> and
via <a href="https://www.haskell.org/ghcup/">GHCup</a>.</p>
<p>GHC 9.10.3 is a bug-fix release fixing many issues of a variety of
severities and scopes, including:</p>
<ul>
<li>Fix a number of crashes in the compiler frontend (<a href="https://gitlab.haskell.org/ghc/ghc/issues/25960">#25960</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/25004">#25004</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/25056">#25056</a>)</li>
<li>Fix incorrect results in the NCG (<a href="https://gitlab.haskell.org/ghc/ghc/issues/25601">#25601</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/26061">#26061</a>)</li>
<li>Support for far jumps in the AArch64 NCG (<a href="https://gitlab.haskell.org/ghc/ghc/issues/24648">#24648</a>)</li>
<li>A fix for a segfault in the RTS when running certain code involving STM (<a href="https://gitlab.haskell.org/ghc/ghc/issues/26205">#26205</a>)</li>
<li>And many more!</li>
</ul>
<p>A full accounting of these fixes can be found in the <a href="https://downloads.haskell.org/~ghc/9.10.3/docs/users_guide/9.10.3-notes.html">release notes</a>. As
always, GHC’s release status, including planned future releases, can be found on
the GHC Wiki <a href="https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status">status</a>.</p>
<p>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.</p>
<p>As always, do give this release a try and open a <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/new">ticket</a> if you see
anything amiss.</p>
]]></description>
    <pubDate>Wed, 10 Sep 2025 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20250910-ghc-9.10.3-released.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC 9.14.1-alpha1 is now available</title>
    <link>http://haskell.org/ghc/blog/20250819-ghc-9.14.1-alpha1-released.html</link>
    <description><![CDATA[<h1>GHC 9.14.1-alpha1 is now available</h1>
<h4 class="text-muted">bgamari - 2025-08-19</h4>

<p>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 <a href="https://downloads.haskell.org/ghc/9.14.1-alpha1">downloads.haskell.org</a>.</p>
<p>GHC 9.14 will bring a number of new features and improvements, including:</p>
<ul>
<li><p>Significant improvements in specialisation:</p>
<ul>
<li><p>The <code>SPECIALISE</code> pragma now allows use of type application syntax</p></li>
<li><p>The <code>SPECIALISE</code> pragma can be used to specialise for expression arguments
as well as type arguments.</p></li>
<li><p>Specialisation is now considerably more reliable in the presence of
<code>newtype</code>s</p></li>
<li><p>the specialiser is now able to produce specialisations with
polymorphic typeclass constraints, considerably broadening its scope.</p></li>
</ul></li>
<li><p>Significant improvements in the GHCi debugger</p></li>
<li><p>Record fields can be defined to be non-linear when LinearTypes is enabled.</p></li>
<li><p>RequiredTypeArgments can now be used in more contexts</p></li>
<li><p>SSE/AVX support in the x86 native code generator backend</p></li>
<li><p>A major update of the Windows toolchain</p></li>
<li><p>… and many more</p></li>
</ul>
<p>A full accounting of changes can be found in the <a href="https://downloads.haskell.org/ghc/9.14.1-alpha1/docs/users_guide/9.14.1-notes.html">release notes</a>. Given the
many specialisation improvements and their potential for regression, we would
very much appreciate testing and performance characterisation on downstream
workloads.</p>
<p>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.</p>
<p>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.</p>
<p>As always, do give this release a try and open a <a href="https://gitlab.haskell.org/ghc/homepage/-/issues/new">ticket</a> if you see
anything amiss.</p>
]]></description>
    <pubDate>Tue, 19 Aug 2025 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20250819-ghc-9.14.1-alpha1-released.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC 9.10.3-rc4 is now available</title>
    <link>http://haskell.org/ghc/blog/20250818-ghc-9.10.4-rc4-released.html</link>
    <description><![CDATA[<h1>GHC 9.10.3-rc4 is now available</h1>
<h4 class="text-muted">wz1000 - 2025-08-18</h4>

<p>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 <a href="https://downloads.haskell.org/ghc/9.10.3-rc4">downloads.haskell.org</a> and
via <a href="https://www.haskell.org/ghcup/">GHCup</a>.</p>
<p>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
<a href="https://gitlab.haskell.org/ghc/ghc/-/blob/ghc-9.10/docs/users_guide/9.10.3-notes.rst?ref_type=heads&amp;plain=1">release notes</a>. As always, GHC’s release status, including planned future
releases, can be found on the GHC Wiki <a href="https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status">status</a>.</p>
<p>The changes from the first release candidate are:</p>
<ul>
<li>A fix for a rare segfault with code involving STM (<a href="https://gitlab.haskell.org/ghc/ghc/issues/26205">#26205</a>)</li>
<li>A fix for the <code>naturalAndNot</code> returning bogus results (<a href="https://gitlab.haskell.org/ghc/ghc/issues/26205">#26205</a>)</li>
<li>A fix for a crash in the renamer (<a href="https://gitlab.haskell.org/ghc/ghc/issues/25056">#25056</a>)</li>
</ul>
<p>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.</p>
<p>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.</p>
<p>As always, do give this release a try and open a <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/new">ticket</a> if you see
anything amiss.</p>
]]></description>
    <pubDate>Mon, 18 Aug 2025 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20250818-ghc-9.10.4-rc4-released.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC 9.10.3-rc3 is now available</title>
    <link>http://haskell.org/ghc/blog/20250808-ghc-9.10.3-rc3-released.html</link>
    <description><![CDATA[<h1>GHC 9.10.3-rc3 is now available</h1>
<h4 class="text-muted">wz1000 - 2025-08-08</h4>

<p>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 <a href="https://downloads.haskell.org/ghc/9.10.3-rc3">downloads.haskell.org</a> and
via <a href="https://www.haskell.org/ghcup/">GHCup</a>.</p>
<p>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
<a href="https://gitlab.haskell.org/ghc/ghc/-/blob/ghc-9.10/docs/users_guide/9.10.3-notes.rst?ref_type=heads&amp;plain=1">release notes</a>. As always, GHC’s release status, including planned future
releases, can be found on the GHC Wiki <a href="https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status">status</a>.</p>
<p>The changes from the second release candidate are:</p>
<ul>
<li>Reverting a change the exports of the <code>Backtrace</code> constructor in the base library that was backported
due to confusion on CLC approvals (<a href="https://gitlab.haskell.org/ghc/ghc/merge_requests/14587">!14587</a>)</li>
<li>Reverting a change to the configure script (<a href="https://gitlab.haskell.org/ghc/ghc/merge_requests/14324">!14324</a>) that dropped probing for ld.gold</li>
</ul>
<p>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.</p>
<p>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.</p>
<p>As always, do give this release a try and open a <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/new">ticket</a> if you see
anything amiss.</p>
]]></description>
    <pubDate>Fri, 08 Aug 2025 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20250808-ghc-9.10.3-rc3-released.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC 9.10.3-rc2 is now available</title>
    <link>http://haskell.org/ghc/blog/20250806-ghc-9.10.3-rc2-released.html</link>
    <description><![CDATA[<h1>GHC 9.10.3-rc2 is now available</h1>
<h4 class="text-muted">wz1000 - 2025-08-06</h4>

<p>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 <a href="https://downloads.haskell.org/ghc/9.10.3-rc2">downloads.haskell.org</a> and
via <a href="https://www.haskell.org/ghcup/">GHCup</a>.</p>
<p>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
<a href="https://gitlab.haskell.org/ghc/ghc/-/blob/ghc-9.10/docs/users_guide/9.10.3-notes.rst?ref_type=heads&amp;plain=1">release notes</a>. As always, GHC’s release status, including planned future
releases, can be found on the GHC Wiki <a href="https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status">status</a>.</p>
<p>The changes from the first release candidate are:</p>
<ul>
<li>Bumping the text submodule to 2.1.3</li>
<li>Reverting a bug fix (<a href="https://gitlab.haskell.org/ghc/ghc/merge_requests/14291">!14291</a>) that restricted previously allowed namespace specifiers (<a href="https://gitlab.haskell.org/ghc/ghc/issues/26250">#26250</a>)</li>
<li>Reverting the bump of the deepseq submodule to 1.5.2.0 (<a href="https://gitlab.haskell.org/ghc/ghc/issues/26251">#26251</a>)</li>
</ul>
<p>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.</p>
<p>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.</p>
<p>As always, do give this release a try and open a <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/new">ticket</a> if you see
anything amiss.</p>
]]></description>
    <pubDate>Wed, 06 Aug 2025 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20250806-ghc-9.10.3-rc2-released.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC 9.10.3-rc1 is now available</title>
    <link>http://haskell.org/ghc/blog/20250728-ghc-9.10.3-rc1-released.html</link>
    <description><![CDATA[<h1>GHC 9.10.3-rc1 is now available</h1>
<h4 class="text-muted">wz1000 - 2025-07-28</h4>

<p>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 <a href="https://downloads.haskell.org/ghc/9.10.3-rc1">downloads.haskell.org</a> and
via <a href="https://www.haskell.org/ghcup/">GHCup</a>.</p>
<p>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
<a href="https://gitlab.haskell.org/ghc/ghc/-/blob/ghc-9.10/docs/users_guide/9.10.3-notes.rst?ref_type=heads&amp;plain=1">release notes</a>. As always, GHC’s release status, including planned future
releases, can be found on the GHC Wiki <a href="https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status">status</a>.</p>
<p>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.</p>
<p>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.</p>
<p>As always, do give this release a try and open a <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/new">ticket</a> if you see
anything amiss.</p>
]]></description>
    <pubDate>Mon, 28 Jul 2025 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20250728-ghc-9.10.3-rc1-released.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC LTS Releases</title>
    <link>http://haskell.org/ghc/blog/20250702-ghc-release-schedules.html</link>
    <description><![CDATA[<h1>GHC LTS Releases</h1>
<h4 class="text-muted">Andreas Klebinger - 2025-07-07</h4>

<h2 id="ghc-will-start-maintaining-an-lts-releasebranch-in-the-near-future">GHC will start maintaining an LTS release/branch in the near future</h2>
<p>A release being designated LTS (Long Term Support) in this case means we plan to
support it over a longer timeframe than usual.</p>
<p>Concretely the plan is to provide updates for a LTS releases for <em>at least</em> two years. Most likely we will
support LTS releases for even longer than that, aiming for a support window of three years
currently.</p>
<p>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.</p>
<p>There are no plans to backport any new features to LTS releases after their initial release.</p>
<p>In terms of frequency of LTS releases we plan to have an overlap between LTS
support windows of different LTS series of six months.</p>
<p>A potential timeline might then look like this:</p>
<pre><code>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
...</code></pre>
<h2 id="non-lts-releases">Non-LTS releases</h2>
<p>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.</p>
<h2 id="why-lts-releases">Why LTS releases?</h2>
<p>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.</p>
<p>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.</p>
<p>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”.</p>
<p>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.</p>
<p>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.</p>
<h2 id="why-not-make-post-hoc-lts-releases-official-instead">Why not make post-hoc LTS releases official instead?</h2>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<h2 id="next-steps">Next steps</h2>
<p>The first LTS release will be GHC 9.14, which will be released this summer!</p>
]]></description>
    <pubDate>Mon, 07 Jul 2025 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20250702-ghc-release-schedules.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC 9.10.2 is now available</title>
    <link>http://haskell.org/ghc/blog/20250503-ghc-9.10.2-released.html</link>
    <description><![CDATA[<h1>GHC 9.10.2 is now available</h1>
<h4 class="text-muted">Zubin Duggal - 2025-05-03</h4>

<p>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 <a href="https://downloads.haskell.org/ghc/9.10.2">downloads.haskell.org</a> and
via <a href="https://www.haskell.org/ghcup/">GHCup</a>.</p>
<p>GHC 9.10.2 is a bug-fix release fixing over 50 issues of a variety of
severities and scopes, including:</p>
<ul>
<li>Significantly improved performance when dynamically loading Haskell symbols (<a href="https://gitlab.haskell.org/ghc/ghc/issues/23415">#23415</a>).</li>
<li>Fixing a bug where the simplifier sometimes destroyed join points during float out, which could impact performance (<a href="https://gitlab.haskell.org/ghc/ghc/issues/24768">#24768</a>).</li>
<li>Reduced memory fragmentation in the non-moving GC’s segment allocator, improving resident set size by up to 26% for some applications (<a href="https://gitlab.haskell.org/ghc/ghc/issues/24150">#24150</a>).</li>
<li>Added new flags to control speculative evaluation (-fspec-eval and -fspec-eval-dictfun) to work around performance regressions (<a href="https://gitlab.haskell.org/ghc/ghc/issues/25606">#25606</a>).</li>
<li>Fixed several platform-specific issues, including segfaults with FFI on PowerPC (<a href="https://gitlab.haskell.org/ghc/ghc/issues/23034">#23034</a>) and improved code
generation for AArch64 with multiway branches now using jump tables (<a href="https://gitlab.haskell.org/ghc/ghc/issues/19912">#19912</a>)</li>
<li>And many more!</li>
</ul>
<p>A full accounting of these fixes can be found in the <a href="https://downloads.haskell.org/~ghc/9.10.2/docs/users_guide/9.10.2-notes.html">release notes</a>. As
always, GHC’s release status, including planned future releases, can be found on
the GHC Wiki <a href="https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status">status</a>.</p>
<p>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.</p>
<p>As always, do give this release a try and open a <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/new">ticket</a> if you see
anything amiss.</p>
]]></description>
    <pubDate>Sat, 03 May 2025 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20250503-ghc-9.10.2-released.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC 9.10.2-rc1 is now available</title>
    <link>http://haskell.org/ghc/blog/20250418-ghc-9.10.2-rc1-released.html</link>
    <description><![CDATA[<h1>GHC 9.10.2-rc1 is now available</h1>
<h4 class="text-muted">bgamari - 2025-04-18</h4>

<p>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 <a href="https://downloads.haskell.org/ghc/9.10.2-rc1">downloads.haskell.org</a> and
via <a href="https://www.haskell.org/ghcup/">GHCup</a>.</p>
<p>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
<a href="https://gitlab.haskell.org/ghc/ghc/-/blob/ghc-9.10/docs/users_guide/9.10.2-notes.rst?ref_type=heads&amp;plain=1">release notes</a>. As always, GHC’s release status, including planned future
releases, can be found on the GHC Wiki <a href="https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status">status</a>.</p>
<p>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.</p>
<p>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.</p>
<p>As always, do give this release a try and open a <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/new">ticket</a> if you see
anything amiss.</p>
]]></description>
    <pubDate>Fri, 18 Apr 2025 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20250418-ghc-9.10.2-rc1-released.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC 9.6.7 is now available</title>
    <link>http://haskell.org/ghc/blog/20250324-ghc-9.6.7-released.html</link>
    <description><![CDATA[<h1>GHC 9.6.7 is now available</h1>
<h4 class="text-muted">Luite Stegeman - 2025-03-24</h4>

<p>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
<a href="/download_ghc_9_6_7.html">release page</a>.</p>
<p>GHC 9.6.7 brings number of fixes, including:</p>
<ul>
<li>GHC’s internal Unique type has been widened to 64-bits on 32-bit
architectures, avoiding potential miscompilations on large projects.</li>
<li>Fix a runtime crash when using the compacting GC, caused by black
holes in large objects.</li>
<li>Added new flags <code>-fspec-eval</code> and <code>-fspec-eval-dictfun</code> to allow
switching off speculative evaluation.</li>
</ul>
<p>The following libraries have been updated since GHC 9.6.6:</p>
<ul>
<li>base-4.18.3.0</li>
<li>filepath-1.4.301.0</li>
<li>unix-2.8.6.0</li>
<li>bytestring-0.11.5.4</li>
<li>array-0.5.8.0</li>
</ul>
<p>A more detailed description can be found in the
<a href="https://downloads.haskell.org/ghc/9.6.7/docs/users_guide/9.6.7-notes.html">release notes</a> and a
full list of changes in <a href="https://gitlab.haskell.org/ghc/ghc/-/merge_requests/13841">GHC<span>!13841</span></a>
and <a href="https://gitlab.haskell.org/ghc/ghc/-/merge_requests/13891">GHC<span>!13891</span></a></p>
<p>Note about Haskell Language Server and building GHC 9.8+:</p>
<p>The change of Unique to 64 bit (<a href="https://gitlab.haskell.org/ghc/ghc/-/issues/22010">GHC<span>#22010</span></a>)
adds the exported symbol
<code>ghc_unique_counter64</code> to the RTS. Unfortunately it’s impossible to
avoid this without breaking other things. If you encounter a linker
error related to <code>ghc_unique_counter64</code> when building GHC (or building a
GHC-derived package like ghc-lib-parser) with GHC 9.6.7, you probably
have to add this <a href="https://gitlab.haskell.org/ghc/ghc/-/merge_requests/13743">fix</a>
to the program you’re building.</p>
<p>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.</p>
<p>Please give this release a try and open a <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/new">ticket</a>
if you see anything amiss.</p>
<p>~ Luite</p>
]]></description>
    <pubDate>Mon, 24 Mar 2025 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20250324-ghc-9.6.7-released.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC 9.12.2 is now available</title>
    <link>http://haskell.org/ghc/blog/20250314-ghc-9.12.2-released.html</link>
    <description><![CDATA[<h1>GHC 9.12.2 is now available</h1>
<h4 class="text-muted">Ben Gamari - 2025-03-14</h4>

<p>The GHC developers are happy to announce the release of GHC 9.12.2.
Binary distributions, source distributions, and documentation are available at
<a href="https://downloads.haskell.org/ghc/9.12.2">downloads.haskell.org</a>.</p>
<p>We hope to have this release available via <code>ghcup</code> shortly. This is a small
release fixing a critical code generation bug, <a href="https://gitlab.haskell.org/ghc/ghc/issues/25653">#25653</a>, affecting some subword
division operations.</p>
<p>As always, GHC’s release status, including planned future releases, can
be found on the GHC Wiki <a href="https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status">status</a>.</p>
<p>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.</p>
<p>As always, do give this release a try and open a <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/new">ticket</a> if you see
anything amiss.</p>
]]></description>
    <pubDate>Fri, 14 Mar 2025 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20250314-ghc-9.12.2-released.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC 9.12.2-rc1 is now available</title>
    <link>http://haskell.org/ghc/blog/20240225-ghc-9.12.2-rc1-released.html</link>
    <description><![CDATA[<h1>GHC 9.12.2-rc1 is now available</h1>
<h4 class="text-muted">Ben Gamari - 2025-02-26</h4>

<p>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
(<a href="https://gitlab.haskell.org/ghc/ghc/issues/25653">#25653</a>).</p>
<p>In accordance with our under-discussion <a href="https://gitlab.haskell.org/ghc/ghc-hq/-/merge_requests/38">release policies</a> this candidate
will have a two-week testing window. The final 9.12.2 release will likely come
the week of 12 March 2025.</p>
<p>As always, if you find anything amiss please open a <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/new">ticket</a>.</p>
<p>Happy Haskelling!</p>
<ul>
<li>Ben</li>
</ul>
]]></description>
    <pubDate>Wed, 26 Feb 2025 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20240225-ghc-9.12.2-rc1-released.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC 9.12.1 is now available</title>
    <link>http://haskell.org/ghc/blog/20241216-ghc-9.12.1-released.html</link>
    <description><![CDATA[<h1>GHC 9.12.1 is now available</h1>
<h4 class="text-muted">Zubin Duggal - 2024-12-16</h4>

<p>The GHC developers are very pleased to announce the release of GHC 9.12.1.
Binary distributions, source distributions, and documentation are available at
<a href="https://downloads.haskell.org/ghc/9.12.1">downloads.haskell.org</a>.</p>
<p>We hope to have this release available via ghcup shortly.</p>
<p>GHC 9.12 will bring a number of new features and improvements, including:</p>
<ul>
<li><p>The new language extension <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0522-or-patterns.rst">OrPatterns</a> allowing you to combine multiple
pattern clauses into one.</p></li>
<li><p>The <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0569-multiline-strings.rst">MultilineStrings</a> language extension to allow you to more easily write
strings spanning multiple lines in your source code.</p></li>
<li><p>Improvements to the OverloadedRecordDot extension, allowing the built-in
<code>HasField</code> class to be used for records with fields of non lifted representations.</p></li>
<li><p>The <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0409-exportable-named-default.rst">NamedDefaults</a> language extension has been introduced allowing you to
define defaults for typeclasses other than <code>Num</code>.</p></li>
<li><p>More deterministic object code output, controlled by the <code>-fobject-determinism</code>
flag, which improves determinism of builds a lot (though does not fully do so)
at the cost of some compiler performance (1-2%). See <a href="https://gitlab.haskell.org/ghc/ghc/issues/12935">#12935</a> for the details</p></li>
<li><p>GHC now accepts type syntax in expressions as part of <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0281-visible-forall.rst">GHC Proposal <span>#281</span></a>.</p></li>
<li><p>The WASM backend now has support for TemplateHaskell.</p></li>
<li><p>Experimental support for the RISC-V platform with the native code generator.</p></li>
<li><p>… and many more</p></li>
</ul>
<p>A full accounting of changes can be found in the <a href="https://downloads.haskell.org/ghc/9.12.1/docs/users_guide/9.12.1-notes.html">release notes</a>.
As always, GHC’s release status, including planned future releases, can
be found on the GHC Wiki <a href="https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status">status</a>.</p>
<p>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.</p>
<p>As always, do give this release a try and open a <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/new">ticket</a> if you see
anything amiss.</p>
]]></description>
    <pubDate>Mon, 16 Dec 2024 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20241216-ghc-9.12.1-released.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC 9.8.4 is now available</title>
    <link>http://haskell.org/ghc/blog/20241202-ghc-9.8.4-released.html</link>
    <description><![CDATA[<h1>GHC 9.8.4 is now available</h1>
<h4 class="text-muted">Ben Gamari - 2024-12-02</h4>

<p>The GHC developers are happy to announce the availability of GHC 9.8.4. Binary
distributions, source distributions, and documentation are available on the
<a href="https://www.haskell.org/ghc/download_ghc_9_8_4.html">release</a> page.</p>
<p>This release is a small release fixing a few issues noted in 9.8.3, including:</p>
<ul>
<li><p>Update the <code>filepath</code> submodule to avoid a misbehavior of <code>splitFileName</code> under Windows.</p></li>
<li><p>Update the <code>unix</code> submodule to fix a compilation issue on <code>musl</code> platforms</p></li>
<li><p>Fix a potential source of miscompilation when building large projects on 32-bit platforms</p></li>
<li><p>Fix unsound optimisation of <code>prompt#</code> uses</p></li>
</ul>
<p>A full accounting of changes can be found in the <a href="https://downloads.haskell.org/~ghc/9.8.4/docs/users_guide/9.8.4-notes.html">release notes</a>. As
some of the fixed issues do affect correctness users are encouraged to
upgrade promptly.</p>
<p>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.</p>
<p>As always, do give this release a try and open a <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/new">ticket</a> if you see
anything amiss.</p>
<p>Happy compiling!</p>
<ul>
<li>Ben</li>
</ul>
]]></description>
    <pubDate>Mon, 02 Dec 2024 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20241202-ghc-9.8.4-released.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC 9.12.1-rc1 is now available</title>
    <link>http://haskell.org/ghc/blog/20241129-ghc-9.12.1-rc1-released.html</link>
    <description><![CDATA[<h1>GHC 9.12.1-rc1 is now available</h1>
<h4 class="text-muted">Zubin Duggal - 2024-11-29</h4>

<p>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 <a href="https://downloads.haskell.org/ghc/9.12.1-rc1">downloads.haskell.org</a>.</p>
<p>We hope to have this release available via ghcup shortly.</p>
<p>GHC 9.12 will bring a number of new features and improvements, including:</p>
<ul>
<li><p>The new language extension <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0522-or-patterns.rst">OrPatterns</a> allowing you to combine multiple
pattern clauses into one.</p></li>
<li><p>The <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0569-multiline-strings.rst">MultilineStrings</a> language extension to allow you to more easily write
strings spanning multiple lines in your source code.</p></li>
<li><p>Improvements to the OverloadedRecordDot extension, allowing the built-in
<code>HasField</code> class to be used for records with fields of non lifted representations.</p></li>
<li><p>The <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0409-exportable-named-default.rst">NamedDefaults</a> language extension has been introduced allowing you to
define defaults for typeclasses other than <code>Num</code>.</p></li>
<li><p>More deterministic object code output, controlled by the <code>-fobject-determinism</code>
flag, which improves determinism of builds a lot (though does not fully do so)
at the cost of some compiler performance (1-2%). See <a href="https://gitlab.haskell.org/ghc/ghc/issues/12935">#12935</a> for the details</p></li>
<li><p>GHC now accepts type syntax in expressions as part of <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0281-visible-forall.rst">GHC Proposal <span>#281</span></a>.</p></li>
<li><p>The WASM backend now has support for TemplateHaskell.</p></li>
<li><p>… and many more</p></li>
</ul>
<p>A full accounting of changes can be found in the <a href="https://downloads.haskell.org/ghc/9.12.1-rc1/docs/users_guide/9.12.1-notes.html">release notes</a>.
As always, GHC’s release status, including planned future releases, can
be found on the GHC Wiki <a href="https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status">status</a>.</p>
<p>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.</p>
<p>As always, do give this release a try and open a <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/new">ticket</a> if you see
anything amiss.</p>
]]></description>
    <pubDate>Fri, 29 Nov 2024 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20241129-ghc-9.12.1-rc1-released.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC 9.12.1-alpha3 is now available</title>
    <link>http://haskell.org/ghc/blog/20241114-ghc-9.12.1-alpha3-released.html</link>
    <description><![CDATA[<h1>GHC 9.12.1-alpha3 is now available</h1>
<h4 class="text-muted">Zubin Duggal - 2024-11-14</h4>

<p>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 <a href="https://downloads.haskell.org/ghc/9.12.1-alpha3">downloads.haskell.org</a>.</p>
<p>We hope to have this release available via ghcup shortly.</p>
<p>GHC 9.12 will bring a number of new features and improvements, including:</p>
<ul>
<li><p>The new language extension <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0522-or-patterns.rst">OrPatterns</a> allowing you to combine multiple
pattern clauses into one.</p></li>
<li><p>The <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0569-multiline-strings.rst">MultilineStrings</a> language extension to allow you to more easily write
strings spanning multiple lines in your source code.</p></li>
<li><p>Improvements to the OverloadedRecordDot extension, allowing the built-in
<code>HasField</code> class to be used for records with fields of non lifted representations.</p></li>
<li><p>The <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0409-exportable-named-default.rst">NamedDefaults</a> language extension has been introduced allowing you to
define defaults for typeclasses other than <code>Num</code>.</p></li>
<li><p>More deterministic object code output, controlled by the <code>-fobject-determinism</code>
flag, which improves determinism of builds a lot (though does not fully do so)
at the cost of some compiler performance (1-2%). See <a href="https://gitlab.haskell.org/ghc/ghc/issues/12935">#12935</a> for the details</p></li>
<li><p>GHC now accepts type syntax in expressions as part of <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0281-visible-forall.rst">GHC Proposal <span>#281</span></a>.</p></li>
<li><p>The WASM backend now has support for TemplateHaskell.</p></li>
<li><p>… and many more</p></li>
</ul>
<p>A full accounting of changes can be found in the <a href="https://downloads.haskell.org/ghc/9.12.1-alpha3/docs/users_guide/9.12.1-notes.html">release notes</a>.
As always, GHC’s release status, including planned future releases, can
be found on the GHC Wiki <a href="https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status">status</a>.</p>
<p>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.</p>
<p>As always, do give this release a try and open a <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/new">ticket</a> if you see
anything amiss.</p>
]]></description>
    <pubDate>Thu, 14 Nov 2024 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20241114-ghc-9.12.1-alpha3-released.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC 9.12.1-alpha2 is now available</title>
    <link>http://haskell.org/ghc/blog/20241105-ghc-9.12.1-alpha2-released.html</link>
    <description><![CDATA[<h1>GHC 9.12.1-alpha2 is now available</h1>
<h4 class="text-muted">Zubin Duggal - 2024-11-05</h4>

<p>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 <a href="https://downloads.haskell.org/ghc/9.12.1-alpha2">downloads.haskell.org</a>.</p>
<p>We hope to have this release available via ghcup shortly.</p>
<p>GHC 9.12 will bring a number of new features and improvements, including:</p>
<ul>
<li><p>The new language extension <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0522-or-patterns.rst">OrPatterns</a> allowing you to combine multiple
pattern clauses into one.</p></li>
<li><p>The <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0569-multiline-strings.rst">MultilineStrings</a> language extension to allow you to more easily write
strings spanning multiple lines in your source code.</p></li>
<li><p>Improvements to the OverloadedRecordDot extension, allowing the built-in
<code>HasField</code> class to be used for records with fields of non lifted representations.</p></li>
<li><p>The <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0409-exportable-named-default.rst">NamedDefaults</a> language extension has been introduced allowing you to
define defaults for typeclasses other than <code>Num</code>.</p></li>
<li><p>More deterministic object code output, controlled by the <code>-fobject-determinism</code>
flag, which improves determinism of builds a lot (though does not fully do so)
at the cost of some compiler performance (1-2%). See <a href="https://gitlab.haskell.org/ghc/ghc/issues/12935">#12935</a> for the details</p></li>
<li><p>GHC now accepts type syntax in expressions as part of <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0281-visible-forall.rst">GHC Proposal <span>#281</span></a>.</p></li>
<li><p>The WASM backend now has support for TemplateHaskell.</p></li>
<li><p>… and many more</p></li>
</ul>
<p>A full accounting of changes can be found in the <a href="https://downloads.haskell.org/ghc/9.12.1-alpha2/docs/users_guide/9.12.1-notes.html">release notes</a>.
As always, GHC’s release status, including planned future releases, can
be found on the GHC Wiki <a href="https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status">status</a>.</p>
<p>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.</p>
<p>As always, do give this release a try and open a <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/new">ticket</a> if you see
anything amiss.</p>
]]></description>
    <pubDate>Tue, 05 Nov 2024 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20241105-ghc-9.12.1-alpha2-released.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC 9.8.3 is now available</title>
    <link>http://haskell.org/ghc/blog/20241020-ghc-9.8.3-released.html</link>
    <description><![CDATA[<h1>GHC 9.8.3 is now available</h1>
<h4 class="text-muted">Ben Gamari - 2024-10-20</h4>

<p>The GHC developers are happy to announce the availability of GHC 9.8.3. Binary
distributions, source distributions, and documentation are available on the
<a href="https://www.haskell.org/ghc/download_ghc_9_8_3.html">release</a> page.</p>
<p>This release is primarily a bugfix release in the 9.8 series. These
include:</p>
<ul>
<li>Significantly improve performance of code loading via dynamic linking (<a href="https://gitlab.haskell.org/ghc/ghc/issues/23415">#23415</a>)</li>
<li>Fix a variety of miscompilations involving sub-word-size FFI arguments
(<a href="https://gitlab.haskell.org/ghc/ghc/issues/25018">#25018</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/24314">#24314</a>)</li>
<li>Fix a rare miscompilation by the x86 native code generator (<a href="https://gitlab.haskell.org/ghc/ghc/issues/24507">#24507</a>)</li>
<li>Improve runtime performance of some applications of <code>runRW#</code> (<a href="https://gitlab.haskell.org/ghc/ghc/issues/25055">#25055</a>)</li>
<li>Reduce fragmentation when using the non-moving garbage collector (<a href="https://gitlab.haskell.org/ghc/ghc/issues/23340">#23340</a>)</li>
<li>Fix source links in Haddock’s hyperlinked sources output (<a href="https://gitlab.haskell.org/ghc/ghc/issues/24086">#24086</a>)</li>
</ul>
<p>A full accounting of changes can be found in the <a href="https://downloads.haskell.org/~ghc/9.8.3/docs/users_guide/9.8.3-notes.html">release notes</a>. As
some of the fixed issues do affect correctness users are encouraged to
upgrade promptly.</p>
<p>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.</p>
<p>As always, do give this release a try and open a <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/new">ticket</a> if you see
anything amiss.</p>
<p>Happy compiling!</p>
<ul>
<li>Ben</li>
</ul>
]]></description>
    <pubDate>Sun, 20 Oct 2024 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20241020-ghc-9.8.3-released.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC 9.12.1-alpha1 is now available</title>
    <link>http://haskell.org/ghc/blog/20241016-ghc-9.12.1-alpha1-released.html</link>
    <description><![CDATA[<h1>GHC 9.12.1-alpha1 is now available</h1>
<h4 class="text-muted">Zubin Duggal - 2024-10-16</h4>

<p>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 <a href="https://downloads.haskell.org/ghc/9.12.1-alpha1">downloads.haskell.org</a>.</p>
<p>We hope to have this release available via ghcup shortly.</p>
<p>GHC 9.12 will bring a number of new features and improvements, including:</p>
<ul>
<li><p>The new language extension <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0522-or-patterns.rst">OrPatterns</a> allowing you to combine multiple
pattern clauses into one.</p></li>
<li><p>The <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0569-multiline-strings.rst">MultilineStrings</a> language extension to allow you to more easily write
strings spanning multiple lines in your source code.</p></li>
<li><p>Improvements to the OverloadedRecordDot extension, allowing the built-in
<code>HasField</code> class to be used for records with fields of non lifted representations.</p></li>
<li><p>The <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0409-exportable-named-default.rst">NamedDefaults</a> language extension has been introduced allowing you to
define defaults for typeclasses other than <code>Num</code>.</p></li>
<li><p>More deterministic object code output, controlled by the <code>-fobject-determinism</code>
flag, which improves determinism of builds a lot (though does not fully do so)
at the cost of some compiler performance (1-2%). See <a href="https://gitlab.haskell.org/ghc/ghc/issues/12935">#12935</a> for the details</p></li>
<li><p>GHC now accepts type syntax in expressions as part of <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0281-visible-forall.rst">GHC Proposal <span>#281</span></a>.</p></li>
<li><p>… and many more</p></li>
</ul>
<p>A full accounting of changes can be found in the <a href="https://downloads.haskell.org/ghc/9.12.1-alpha1/docs/users_guide/9.12.1-notes.html">release notes</a>.
As always, GHC’s release status, including planned future releases, can
be found on the GHC Wiki <a href="https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status">status</a>.</p>
<p>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.</p>
<p>As always, do give this release a try and open a <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/new">ticket</a> if you see
anything amiss.</p>
]]></description>
    <pubDate>Wed, 16 Oct 2024 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20241016-ghc-9.12.1-alpha1-released.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC 9.6.6 is now available</title>
    <link>http://haskell.org/ghc/blog/20240701-ghc-9.6.6-released.html</link>
    <description><![CDATA[<h1>GHC 9.6.6 is now available</h1>
<h4 class="text-muted">Zubin Duggal - 2024-07-01</h4>

<p>The GHC developers are happy to announce the availability of GHC 9.6.6. Binary
distributions, source distributions, and documentation are available on the
<a href="/download_ghc_9_6_6.html">release page</a>.</p>
<p>This release is primarily a bugfix release addressing some issues
found in the 9.6 series. These include:</p>
<ul>
<li>A fix for a bug in the NCG that could lead to incorrect runtime results due to
erroneously removing a jump instruction (<a href="https://gitlab.haskell.org/ghc/ghc/issues/24507">#24507</a>).</li>
<li>A fix for a linker error that manifested on certain platform/toolchain combinations,
particularly darwin with a brew provisioned toolchain, arising due to a confusion
in linker options between GHC and cabal (<a href="https://gitlab.haskell.org/ghc/ghc/issues/22210">#22210</a>).</li>
<li>A fix for a compiler panic in the simplifier due to incorrect eta expansion (<a href="https://gitlab.haskell.org/ghc/ghc/issues/24718">#24718</a>).</li>
<li>A fix for possible segfaults when using the bytecode interpreter due to incorrect
constructor tagging (<a href="https://gitlab.haskell.org/ghc/ghc/issues/24870">#24870</a>).</li>
<li>And a few more fixes</li>
</ul>
<p>A full accounting of changes can be found in the <a href="https://downloads.haskell.org/~ghc/9.6.6/docs/users_guide/9.6.6-notes.html">release notes</a>. As
some of the fixed issues do affect correctness users are encouraged to
upgrade promptly.</p>
<p>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.</p>
<p>As always, do give this release a try and open a <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/new">ticket</a> if you see
anything amiss.</p>
<p>Enjoy!</p>
<p>-Zubin</p>
]]></description>
    <pubDate>Mon, 01 Jul 2024 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20240701-ghc-9.6.6-released.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>Deprecation of 32-bit Darwin and Windows platforms</title>
    <link>http://haskell.org/ghc/blog/20240613-32-bit-darwin-and-windows-deprecation.html</link>
    <description><![CDATA[<h1>Deprecation of 32-bit Darwin and Windows platforms</h1>
<h4 class="text-muted">Hécate - 2024-06-13</h4>

<p>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.</p>
<p>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.</p>
<p>In 2018, Apple communicated that starting from <a href="https://developer.apple.com/documentation/uikit/app_and_environment/updating_your_app_from_32-bit_to_64-bit_architecture">iOS 11</a> and <a href="https://support.apple.com/en-us/103076">macOS 10.15</a>, 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.”</p>
<p>In 2020, Microsoft formally discontinued new 32-bit Windows 10 for OEM distributions, which is in line with
its <a href="https://learn.microsoft.com/en-us/windows-hardware/design/minimum/minimum-hardware-requirements-overview">hardware requirements</a> for Windows 11.</p>
<p>The transition period that started <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/18487">three years ago</a>
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.</p>
<p>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 <a href="https://mail.haskell.org/pipermail/ghc-devs/">ghc-devs</a> mailing-list.</p>
]]></description>
    <pubDate>Thu, 13 Jun 2024 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20240613-32-bit-darwin-and-windows-deprecation.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC release plans</title>
    <link>http://haskell.org/ghc/blog/20240521-ghc-release-priorities.html</link>
    <description><![CDATA[<h1>GHC release plans</h1>
<h4 class="text-muted">Zubin Duggal - 2024-05-21</h4>

<p>This post sets out our plans for upcoming releases in the next few months.</p>
<p>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.</p>
<h2 id="section">9.10</h2>
<p>With the release of 9.10.1, we look forward to the broader adoption of this release.</p>
<p>New releases in this series will continue at the usual rate depending on if and
when any significant regressions or issues arise.</p>
<h2 id="section-1">9.6</h2>
<p>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 (<a href="https://gitlab.haskell.org/ghc/ghc/issues/22210">#22210</a>) to do with object merging arising from the
interactions between GHC and cabal on certain platforms including Darwin with a
<code>brew</code>-provisioned clang toolchain.</p>
<p>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.</p>
<h2 id="section-2">9.8</h2>
<p>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).</p>
<p>The next release in this series will likely be scheduled after the 9.6.6 release.</p>
<h2 id="conclusion">Conclusion</h2>
<p>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
<a href="mailto:ghc-devs@haskell.org" class="uri">mailto:ghc-devs@haskell.org</a>.</p>
]]></description>
    <pubDate>Tue, 21 May 2024 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20240521-ghc-release-priorities.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC 9.10.1 is now available</title>
    <link>http://haskell.org/ghc/blog/20240510-ghc-9.10.1-released.html</link>
    <description><![CDATA[<h1>GHC 9.10.1 is now available</h1>
<h4 class="text-muted">bgamari - 2024-05-10</h4>

<p>The GHC developers are very pleased to announce the release of GHC 9.10.1.
Binary distributions, source distributions, and documentation are available at
<a href="https://downloads.haskell.org/ghc/9.10.1">downloads.haskell.org</a> and via <a href="https://www.haskell.org/ghcup/">GHCup</a>.</p>
<p>GHC 9.10 brings a number of new features and improvements, including:</p>
<ul>
<li><p>The introduction of the <code>GHC2024</code> language edition, building upon
<code>GHC2021</code> with the addition of a number of widely-used extensions.</p></li>
<li><p>Partial implementation of the <a href="https://github.com/ghc-proposals/ghc-proposals/pull/281">GHC Proposal <span>#281</span></a>, allowing visible
quantification to be used in the types of terms.</p></li>
<li><p><a href="https://github.com/ghc-proposals/ghc-proposals/pull/624">Extension</a> of LinearTypes to allow linear <code>let</code> and <code>where</code>
bindings</p></li>
<li><p>The implementation of the <a href="https://github.com/ghc-proposals/ghc-proposals/pull/330">exception backtrace proposal</a>, allowing the annotation of exceptions with backtraces, as well
as other user-defined context</p></li>
<li><p>Further improvements in the info table provenance mechanism, reducing
code size to allow IPE information to be enabled more widely</p></li>
<li><p>Javascript FFI support in the WebAssembly backend</p></li>
<li><p>Improvements in the fragmentation characteristics of the low-latency
non-moving garbage collector.</p></li>
<li><p>… and many more</p></li>
</ul>
<p>A full accounting of changes can be found in the <a href="https://downloads.haskell.org/ghc/9.10.1/docs/users_guide/9.10.1-notes.html">release notes</a>.
As always, GHC’s release status, including planned future releases, can
be found on the GHC Wiki <a href="https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status">status</a>.</p>
<p>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.</p>
<p>As always, do give this release a try and open a <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/new">ticket</a> if you see
anything amiss.</p>
]]></description>
    <pubDate>Fri, 10 May 2024 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20240510-ghc-9.10.1-released.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC 9.10.1-rc1 is now available</title>
    <link>http://haskell.org/ghc/blog/20240427-ghc-9.10.1-rc1-released.html</link>
    <description><![CDATA[<h1>GHC 9.10.1-rc1 is now available</h1>
<h4 class="text-muted">bgamari - 2024-04-27</h4>

<p>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 <a href="https://downloads.haskell.org/ghc/9.10.1-rc1">downloads.haskell.org</a> and
via <a href="https://www.haskell.org/ghcup/">GHCup</a>.</p>
<p>GHC 9.10 brings a number of new features and improvements, including:</p>
<ul>
<li><p>The introduction of the <code>GHC2024</code> language edition, building upon
<code>GHC2021</code> with the addition of a number of widely-used extensions.</p></li>
<li><p>Partial implementation of the <a href="https://github.com/ghc-proposals/ghc-proposals/pull/281">GHC Proposal <span>#281</span></a>, allowing visible
quantification to be used in the types of terms.</p></li>
<li><p><a href="https://github.com/ghc-proposals/ghc-proposals/pull/624">Extension</a> of LinearTypes to allow linear <code>let</code> and <code>where</code>
bindings</p></li>
<li><p>The implementation of the <a href="https://github.com/ghc-proposals/ghc-proposals/pull/330">exception backtrace proposal</a>, allowing the annotation of exceptions with backtraces, as well
as other user-defined context</p></li>
<li><p>Further improvements in the info table provenance mechanism, reducing
code size to allow IPE information to be enabled more widely</p></li>
<li><p>Javascript FFI support in the WebAssembly backend</p></li>
<li><p>Improvements in the fragmentation characteristics of the low-latency
non-moving garbage collector.</p></li>
<li><p>… and many more</p></li>
</ul>
<p>A full accounting of changes can be found in the <a href="https://downloads.haskell.org/ghc/9.10.1-rc1/docs/users_guide/9.10.1-notes.html">release notes</a>.
As always, GHC’s release status, including planned future releases, can
be found on the GHC Wiki <a href="https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status">status</a>.</p>
<p>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.</p>
<p>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.</p>
<p>As always, do give this release a try and open a <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/new">ticket</a> if you see
anything amiss.</p>
]]></description>
    <pubDate>Sat, 27 Apr 2024 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20240427-ghc-9.10.1-rc1-released.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC 9.6.5 is now available</title>
    <link>http://haskell.org/ghc/blog/20240416-ghc-9.6.5-released.html</link>
    <description><![CDATA[<h1>GHC 9.6.5 is now available</h1>
<h4 class="text-muted">Zubin Duggal - 2024-04-16</h4>

<p>The GHC developers are happy to announce the availability of GHC 9.6.5. Binary
distributions, source distributions, and documentation are available on the
<a href="/download_ghc_9_6_5.html">release page</a>.</p>
<p>This release is primarily a bugfix release addressing some issues
found in the 9.6 series. These include:</p>
<ul>
<li>Bumping the bundled <code>process</code> library to 1.6.19.0 to avoid a potential
<a href="https://github.com/haskell/security-advisories/blob/main/advisories/hackage/process/HSEC-2024-0003.md">command injection vulnerability</a> 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 <code>process</code> to avoid the issue.</li>
<li>Fixing a bug resulting in the distributed <code>hsc2hs</code> wrapper using flags from the
compiler build environment (<a href="https://gitlab.haskell.org/ghc/ghc/issues/24050">#24050</a>).</li>
<li>Disabling the <code>-fasm-shortcutting</code> optimisation with <code>-O2</code> as it is known
to result in unsoundess and incorrect runtime results in some cases (<a href="https://gitlab.haskell.org/ghc/ghc/issues/24507">#24507</a>).</li>
<li>Ensuring we take <code>LDFLAGS</code> into account when configuring a linker (<a href="https://gitlab.haskell.org/ghc/ghc/issues/24565">#24565</a>).</li>
<li>Fixing a bug arising from incorrect parsing of paths containing spaces in the
settings file (<a href="https://gitlab.haskell.org/ghc/ghc/issues/24265">#24265</a>).</li>
<li>And many more fixes</li>
</ul>
<p>A full accounting of changes can be found in the <a href="https://downloads.haskell.org/~ghc/9.6.5/docs/users_guide/9.6.5-notes.html">release notes</a>. As
some of the fixed issues do affect correctness users are encouraged to
upgrade promptly.</p>
<p>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.</p>
<p>As always, do give this release a try and open a <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/new">ticket</a> if you see
anything amiss.</p>
<p>Enjoy!</p>
<p>-Zubin</p>
]]></description>
    <pubDate>Tue, 16 Apr 2024 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20240416-ghc-9.6.5-released.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC 9.10.1-alpha3 is now available</title>
    <link>http://haskell.org/ghc/blog/20240415-ghc-9.10.1-alpha3-released.html</link>
    <description><![CDATA[<h1>GHC 9.10.1-alpha3 is now available</h1>
<h4 class="text-muted">bgamari - 2024-04-15</h4>

<p>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 <a href="https://downloads.haskell.org/ghc/9.10.1-alpha3">downloads.haskell.org</a>.</p>
<p>We hope to have this release available via ghcup shortly.</p>
<p>GHC 9.10 will bring a number of new features and improvements, including:</p>
<ul>
<li><p>The introduction of the <code>GHC2024</code> language edition, building upon
<code>GHC2021</code> with the addition of a number of widely-used extensions.</p></li>
<li><p>Partial implementation of the <a href="https://github.com/ghc-proposals/ghc-proposals/pull/281">GHC Proposal <span>#281</span></a>, allowing visible
quantification to be used in the types of terms.</p></li>
<li><p><a href="https://github.com/ghc-proposals/ghc-proposals/pull/624">Extension</a> of LinearTypes to allow linear <code>let</code> and <code>where</code>
bindings</p></li>
<li><p>The implementation of the <a href="https://github.com/ghc-proposals/ghc-proposals/pull/330">exception backtrace proposal</a>, allowing the annotation of exceptions with backtraces, as well
as other user-defined context</p></li>
<li><p>Further improvements in the info table provenance mechanism, reducing
code size to allow IPE information to be enabled more widely</p></li>
<li><p>Javascript FFI support in the WebAssembly backend</p></li>
<li><p>Improvements in the fragmentation characteristics of the low-latency
non-moving garbage collector.</p></li>
<li><p>… and many more</p></li>
</ul>
<p>A full accounting of changes can be found in the <a href="https://downloads.haskell.org/ghc/9.10.1-alpha3/docs/users_guide/9.10.1-notes.html">release notes</a>.
As always, GHC’s release status, including planned future releases, can
be found on the GHC Wiki <a href="https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status">status</a>.</p>
<p>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.</p>
<p>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.</p>
<p>As always, do give this release a try and open a <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/new">ticket</a> if you see
anything amiss.</p>
]]></description>
    <pubDate>Mon, 15 Apr 2024 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20240415-ghc-9.10.1-alpha3-released.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC 9.10.1-alpha2 is now available</title>
    <link>http://haskell.org/ghc/blog/20240329-ghc-9.10.1-alpha2-released.html</link>
    <description><![CDATA[<h1>GHC 9.10.1-alpha2 is now available</h1>
<h4 class="text-muted">bgamari - 2024-03-29</h4>

<p>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 <a href="https://downloads.haskell.org/ghc/9.10.1-alpha2">downloads.haskell.org</a>.</p>
<p>We hope to have this release available via ghcup shortly.</p>
<p>GHC 9.10 will bring a number of new features and improvements, including:</p>
<ul>
<li><p>The introduction of the <code>GHC2024</code> language edition, building upon
<code>GHC2021</code> with the addition of a number of widely-used extensions.</p></li>
<li><p>Partial implementation of the <a href="https://github.com/ghc-proposals/ghc-proposals/pull/281">GHC Proposal <span>#281</span></a>, allowing visible
quantification to be used in the types of terms.</p></li>
<li><p><a href="https://github.com/ghc-proposals/ghc-proposals/pull/624">Extension</a> of LinearTypes to allow linear <code>let</code> and <code>where</code>
bindings</p></li>
<li><p>The implementation of the <a href="https://github.com/ghc-proposals/ghc-proposals/pull/330">exception backtrace proposal</a>, allowing the annotation of exceptions with backtraces, as well
as other user-defined context</p></li>
<li><p>Further improvements in the info table provenance mechanism, reducing
code size to allow IPE information to be enabled more widely</p></li>
<li><p>Javascript FFI support in the WebAssembly backend</p></li>
<li><p>Improvements in the fragmentation characteristics of the low-latency
non-moving garbage collector.</p></li>
<li><p>… and many more</p></li>
</ul>
<p>A full accounting of changes can be found in the <a href="https://downloads.haskell.org/ghc/9.10.1-alpha2/docs/users_guide/9.10.1-notes.html">release notes</a>.
As always, GHC’s release status, including planned future releases, can
be found on the GHC Wiki <a href="https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status">status</a>.</p>
<p>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.</p>
<p>As always, do give this release a try and open a <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/new">ticket</a> if you see
anything amiss.</p>
]]></description>
    <pubDate>Fri, 29 Mar 2024 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20240329-ghc-9.10.1-alpha2-released.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC 9.10.1-alpha1 is now available</title>
    <link>http://haskell.org/ghc/blog/20240313-ghc-9.10.1-alpha1-released.html</link>
    <description><![CDATA[<h1>GHC 9.10.1-alpha1 is now available</h1>
<h4 class="text-muted">bgamari - 2024-03-13</h4>

<p>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 <a href="https://downloads.haskell.org/ghc/9.10.1-alpha1">downloads.haskell.org</a>.</p>
<p>We hope to have this release available via ghcup shortly.</p>
<p>GHC 9.10 will bring a number of new features and improvements, including:</p>
<ul>
<li><p>The introduction of the <code>GHC2024</code> language edition, building upon
<code>GHC2021</code> with the addition of a number of widely-used extensions.</p></li>
<li><p>Partial implementation of the <a href="https://github.com/ghc-proposals/ghc-proposals/pull/281">GHC Proposal <span>#281</span></a>, allowing visible
quantification to be used in the types of terms.</p></li>
<li><p><a href="https://github.com/ghc-proposals/ghc-proposals/pull/624">Extension</a> of LinearTypes to allow linear <code>let</code> and <code>where</code>
bindings</p></li>
<li><p>The implementation of the <a href="https://github.com/ghc-proposals/ghc-proposals/pull/330">exception backtrace proposal</a>, allowing the annotation of exceptions with backtraces, as well
as other user-defined context</p></li>
<li><p>Further improvements in the info table provenance mechanism, reducing
code size to allow IPE information to be enabled more widely</p></li>
<li><p>Javascript FFI support in the WebAssembly backend</p></li>
<li><p>Improvements in the fragmentation characteristics of the low-latency
non-moving garbage collector.</p></li>
<li><p>… and many more</p></li>
</ul>
<p>A full accounting of changes can be found in the <a href="https://downloads.haskell.org/ghc/9.10.1-alpha1/docs/users_guide/9.10.1-notes.html">release notes</a>.
As always, GHC’s release status, including planned future releases, can
be found on the GHC Wiki <a href="https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status">status</a>.</p>
<p>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 (<a href="https://gitlab.haskell.org/ghc/ghc/issues/24542">#24542</a>). 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.</p>
<p>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.</p>
<p>As always, do give this release a try and open a <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/new">ticket</a> if you see
anything amiss.</p>
]]></description>
    <pubDate>Wed, 13 Mar 2024 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20240313-ghc-9.10.1-alpha1-released.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC 9.8.2 is now available</title>
    <link>http://haskell.org/ghc/blog/20240223-ghc-9.8.2-released.html</link>
    <description><![CDATA[<h1>GHC 9.8.2 is now available</h1>
<h4 class="text-muted">Zubin Duggal - 2024-02-23</h4>

<p>The GHC developers are happy to announce the availability of GHC 9.8.2. Binary
distributions, source distributions, and documentation are available on the
<a href="/download_ghc_9_8_2.html">release page</a>.</p>
<p>This release is primarily a bugfix release addressing many issues
found in the 9.8 series. These include:</p>
<ul>
<li>A fix for a bug where certain warnings flags were not recognised (<a href="https://gitlab.haskell.org/ghc/ghc/issues/24071">#24071</a>)</li>
<li>Fixes for bugs in the renamer and typechecker (<a href="https://gitlab.haskell.org/ghc/ghc/issues/24084">#24084</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/24134">#24134</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/24279">#24279</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/24083">#24083</a>)</li>
<li>Fixes for bugs in the simplifier and code generator (<a href="https://gitlab.haskell.org/ghc/ghc/issues/24160">#24160</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/24242">#24242</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/23628">#23628</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/23659">#23659</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/24160">#24160</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/23862">#23862</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/24295">#24295</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/24370">#24370</a>)</li>
<li>Fixes for some memory leaks in GHCi (<a href="https://gitlab.haskell.org/ghc/ghc/issues/24107">#24107</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/24118">#24118</a>)</li>
<li>Improvements to error messages (<a href="https://gitlab.haskell.org/ghc/ghc/issues/21097">#21097</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/16996">#16996</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/11050">#11050</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/24196">#24196</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/24275">#24275</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/23768">#23768</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/23784">#23784</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/23778">#23778</a>)</li>
<li>A fix for a recompilation checking bug where GHC may miss changes in
transitive dependencies when deciding to relink a program (<a href="https://gitlab.haskell.org/ghc/ghc/issues/23724">#23724</a>).</li>
<li>And many more fixes</li>
</ul>
<p>A full accounting of changes can be found in the <a href="https://downloads.haskell.org/~ghc/9.8.2/docs/users_guide/9.8.2-notes.html">release notes</a>. As
some of the fixed issues do affect correctness users are encouraged to
upgrade promptly.</p>
<p>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.</p>
<p>As always, do give this release a try and open a <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/new">ticket</a> if you see
anything amiss.</p>
<p>Enjoy!</p>
<p>-Zubin</p>
]]></description>
    <pubDate>Fri, 23 Feb 2024 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20240223-ghc-9.8.2-released.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC 9.6.4 is now available</title>
    <link>http://haskell.org/ghc/blog/20240109-ghc-9.6.4-released.html</link>
    <description><![CDATA[<h1>GHC 9.6.4 is now available</h1>
<h4 class="text-muted">Zubin Duggal - 2024-01-09</h4>

<p>The GHC developers are happy to announce the availability of GHC 9.6.4. Binary
distributions, source distributions, and documentation are available on the
<a href="/download_ghc_9_6_4.html">release page</a>.</p>
<p>This release is primarily a bugfix release addressing a few issues
found in the 9.6 series. These include:</p>
<ul>
<li>A fix for a bug where certain warnings flags were not recognised (<a href="https://gitlab.haskell.org/ghc/ghc/issues/24071">#24071</a>)</li>
<li>Fixes for a number of simplifier bugs (<a href="https://gitlab.haskell.org/ghc/ghc/issues/23952">#23952</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/23862">#23862</a>).</li>
<li>Fixes for compiler panics with certain package databases involving unusable
units and module reexports (<a href="https://gitlab.haskell.org/ghc/ghc/issues/21097">#21097</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/16996">#16996</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/11050">#11050</a>).</li>
<li>A fix for a typechecker crash (<a href="https://gitlab.haskell.org/ghc/ghc/issues/24083">#24083</a>).</li>
<li>A fix for a code generator bug on AArch64 platforms resulting in invalid
conditional jumps (<a href="https://gitlab.haskell.org/ghc/ghc/issues/23746">#23746</a>).</li>
<li>Fixes for some memory leaks in GHCi (<a href="https://gitlab.haskell.org/ghc/ghc/issues/24107">#24107</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/24118">#24118</a>)</li>
<li>And a few other fixes</li>
</ul>
<p>A full accounting of changes can be found in the <a href="https://downloads.haskell.org/~ghc/9.6.4/docs/users_guide/9.6.4-notes.html">release notes</a>. As
some of the fixed issues do affect correctness users are encouraged to
upgrade promptly.</p>
<p>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.</p>
<p>As always, do give this release a try and open a <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/new">ticket</a> if you see
anything amiss.</p>
<p>Enjoy!</p>
<p>-Zubin</p>
]]></description>
    <pubDate>Tue, 09 Jan 2024 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20240109-ghc-9.6.4-released.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC 9.4.8 is now available</title>
    <link>http://haskell.org/ghc/blog/20231110-ghc-9.4.8-released.html</link>
    <description><![CDATA[<h1>GHC 9.4.8 is now available</h1>
<h4 class="text-muted">Zubin Duggal - 2023-11-10</h4>

<p>The GHC developers are happy to announce the availability of GHC 9.4.8. Binary
distributions, source distributions, and documentation are available on the
<a href="/download_ghc_9_4_8.html">release page</a>.</p>
<p>This release is primarily a bugfix release addressing a few issues
found in the 9.4 series. These include:</p>
<ul>
<li>A fix for a recompilation checking bug where GHC may miss changes in
transitive dependencies when deciding to relink a program (<a href="https://gitlab.haskell.org/ghc/ghc/issues/23724">#23724</a>).</li>
<li>A fix for a code generator bug on AArch64 platforms resulting in invalid
conditional jumps (<a href="https://gitlab.haskell.org/ghc/ghc/issues/23746">#23746</a>).</li>
<li>Support for <code>-split-sections</code> on Windows.</li>
<li>Enabling <code>-split-sections</code> for various Linux and Windows binary distributions,
enabling GHC to produce smaller binaries on these platforms.</li>
<li>And a few other fixes</li>
</ul>
<p>A full accounting of changes can be found in the <a href="https://downloads.haskell.org/~ghc/9.4.8/docs/users_guide/9.4.8-notes.html">release notes</a>. As
some of the fixed issues do affect correctness users are encouraged to
upgrade promptly.</p>
<p>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.</p>
<p>As always, do give this release a try and open a <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/new">ticket</a> if you see
anything amiss.</p>
<p>Enjoy!</p>
<p>-Bryan</p>
]]></description>
    <pubDate>Fri, 10 Nov 2023 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20231110-ghc-9.4.8-released.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC 9.8.1 is now available</title>
    <link>http://haskell.org/ghc/blog/20231009-ghc-9.8.1-released.html</link>
    <description><![CDATA[<h1>GHC 9.8.1 is now available</h1>
<h4 class="text-muted">bgamari - 2023-10-09</h4>

<p>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
<a href="https://downloads.haskell.org/ghc/9.8.1">downloads.haskell.org</a>.</p>
<p>GHC 9.8 brings a number of new features and improvements, including:</p>
<ul>
<li><p>Preliminary support the <code>TypeAbstractions</code> language extension,
allowing types to be bound in type declarations <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0425-decl-invis-binders.rst">TypeAbstractions</a>.</p></li>
<li><p>Support for the <code>ExtendedLiterals</code> extension, providing syntax for
non-word-sized numeric literals in the surface language
<a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0451-sized-literals.rst">extended-literals</a></p></li>
<li><p>Improved rewrite rule matching behavior, allowing limited matching of
higher-order patterns</p></li>
<li><p>Better support for user-defined warnings by way of the <code>WARNING</code>
pragma <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0541-warning-pragmas-with-categories.rst">warnings</a></p></li>
<li><p>The introduction of the new <code>GHC.TypeError.Unsatisfiable</code>
constraint, allowing more predictable user-defined type errors
<a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0433-unsatisfiable.rst">unsatisfiable</a></p></li>
<li><p>Implementation of the export deprecation proposal, allowing module
exports to be marked with <code>DEPRECATE</code> pragmas <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0134-deprecating-exports-proposal.rst">deprecated-exports</a></p></li>
<li><p>The addition of build semaphore support for parallel compilation;
with coming support in <code>cabal-install</code> this will allow better use of
parallelism in multi-package builds <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0540-jsem.rst">jsem</a></p></li>
<li><p>More efficient representation of info table provenance information,
reducing binary sizes by over 50% in some cases when
<code>-finfo-table-map</code> is in use</p></li>
</ul>
<p>A full accounting of changes can be found in the <a href="https://downloads.haskell.org/ghc/9.8.1/docs/users_guide/9.8.1-notes.html">release notes</a>.
Plans for GHC’s future releases can be found on the <a href="https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status">GHC Wiki</a>.</p>
<p>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.</p>
<dl>
<dt>Happy compiling,</dt>
<dd>
<p>Ben</p>
</dd>
</dl>
]]></description>
    <pubDate>Mon, 09 Oct 2023 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20231009-ghc-9.8.1-released.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC 9.8.1-rc1 is now available</title>
    <link>http://haskell.org/ghc/blog/20230929-ghc-9.8.1-rc1-released.html</link>
    <description><![CDATA[<h1>GHC 9.8.1-rc1 is now available</h1>
<h4 class="text-muted">bgamari - 2023-09-29</h4>

<p>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 <a href="https://downloads.haskell.org/ghc/9.8.1-rc1">downloads.haskell.org</a>.</p>
<p>GHC 9.8 will bring a number of new features and improvements, including:</p>
<ul>
<li><p>Preliminary support the <code>TypeAbstractions</code> language extension,
allowing types to be bound in type declarations <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0425-decl-invis-binders.rst">TypeAbstractions</a>.</p></li>
<li><p>Support for the <code>ExtendedLiterals</code> extension, providing syntax for
non-word-sized numeric literals in the surface language
<a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0451-sized-literals.rst">extended-literals</a></p></li>
<li><p>Improved rewrite rule matching behavior, allowing limited matching of
higher-order patterns</p></li>
<li><p>Better support for user-defined warnings by way of the <code>WARNING</code>
pragma <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0541-warning-pragmas-with-categories.rst">warnings</a></p></li>
<li><p>The introduction of the new <code>GHC.TypeError.Unsatisfiable</code>
constraint, allowing more predictable user-defined type errors
<a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0433-unsatisfiable.rst">unsatisfiable</a></p></li>
<li><p>Implementation of the export deprecation proposal, allowing module
exports to be marked with <code>DEPRECATE</code> pragmas <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0134-deprecating-exports-proposal.rst">deprecated-exports</a></p></li>
<li><p>The addition of build semaphore support for parallel compilation;
with coming support in <code>cabal-install</code> this will allow better use of
parallelism in multi-package builds <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0540-jsem.rst">jsem</a></p></li>
<li><p>More efficient representation of info table provenance information,
reducing binary sizes by over 50% in some cases when
<code>-finfo-table-map</code> is in use</p></li>
</ul>
<p>A full accounting of changes can be found in the <a href="https://downloads.haskell.org/ghc/9.8.1-alpha4/docs/users_guide/9.8.1-notes.html">release notes</a>.
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 <a href="https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status">status</a>.</p>
<p>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.</p>
<p>As always, do give this release a try and open a <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/new">ticket</a> if you see
anything amiss.</p>
<dl>
<dt>Happy compiling,</dt>
<dd>
<p>Ben</p>
</dd>
</dl>
]]></description>
    <pubDate>Fri, 29 Sep 2023 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20230929-ghc-9.8.1-rc1-released.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC 9.6.3 is now available</title>
    <link>http://haskell.org/ghc/blog/20230925-ghc-9.6.3-released.html</link>
    <description><![CDATA[<h1>GHC 9.6.3 is now available</h1>
<h4 class="text-muted">Bryan Richter - 2023-09-25</h4>

<p>The GHC developers are happy to announce the availability of GHC 9.6.3. Binary
distributions, source distributions, and documentation are available on the
<a href="/download_ghc_9_6_3.html">release page</a>.</p>
<p>This release is primarily a bugfix release addressing a few issues
found in the 9.6 series. These include:</p>
<ul>
<li><p>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 <code>-fpolymorphic-specialisation</code> flag. For more details
see <a href="https://gitlab.haskell.org/ghc/ghc/issues/23469">#23469</a> as well as <a href="https://gitlab.haskell.org/ghc/ghc/issues/23109">#23109</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/21229">#21229</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/23445">#23445</a>.</p></li>
<li><p>Improve compile time and code generation performance when <code>-finfo-table-map</code> is
enabled (<a href="https://gitlab.haskell.org/ghc/ghc/issues/23103">#23103</a>).</p></li>
<li><p>Make the recompilation check more robust when code generation flags are
changed (<a href="https://gitlab.haskell.org/ghc/ghc/issues/23369">#23369</a>).</p></li>
<li><p>Addition of memory barriers that improve soundness on platforms with weak
memory ordering.</p></li>
<li><p>And dozens of other fixes.</p></li>
</ul>
<p>A full accounting of changes can be found in the <a href="https://downloads.haskell.org/~ghc/9.6.3/docs/users_guide/9.6.3-notes.html">release notes</a>. As
some of the fixed issues do affect correctness users are encouraged to
upgrade promptly.</p>
<p>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.</p>
<p>As always, do give this release a try and open a <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/new">ticket</a> if you see
anything amiss.</p>
<p>Enjoy!</p>
<p>-Bryan</p>
]]></description>
    <pubDate>Mon, 25 Sep 2023 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20230925-ghc-9.6.3-released.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC 9.8.1-alpha4 is now available</title>
    <link>http://haskell.org/ghc/blog/20230919-ghc-9.8.1-alpha4-released.html</link>
    <description><![CDATA[<h1>GHC 9.8.1-alpha4 is now available</h1>
<h4 class="text-muted">bgamari - 2023-09-19</h4>

<p>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 <a href="https://downloads.haskell.org/ghc/9.8.1-alpha4">downloads.haskell.org</a>.</p>
<p>GHC 9.8 will bring a number of new features and improvements, including:</p>
<ul>
<li><p>Preliminary support the <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0425-decl-invis-binders.rst"><code>TypeAbstractions</code> language extension</a>,
allowing types to be bound in type declarations.</p></li>
<li><p>Support for the <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0451-sized-literals.rst"><code>ExtendedLiterals</code> extension</a>, providing
more consistent support for non-word-sized numeric literals in the surface
language</p></li>
<li><p>Improved rewrite rule matching behavior, allowing limited matching of
higher-order patterns</p></li>
<li><p>Better support for user-defined warnings by way of the <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0541-warning-pragmas-with-categories.rst"><code>WARNING</code>
pragma</a></p></li>
<li><p>The introduction of the new <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0433-unsatisfiable.rst"><code>GHC.TypeError.Unsatisfiable</code></a>
constraint, allowing more predictable user-defined type errors</p></li>
<li><p>Implementation of the <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0134-deprecating-exports-proposal.rst">export deprecation proposal</a>,
allowing module exports to be marked with <code>DEPRECATE</code> pragmas</p></li>
<li><p>The addition of <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0540-jsem.rst">build semaphore support</a> for parallel compilation,
allowing better use of parallelism across GHC builds</p></li>
<li><p>More efficient representation of info table provenance information,
reducing binary sizes by nearly 80% in some cases when
<code>-finfo-table-map</code> is in use</p></li>
</ul>
<p>A full accounting of changes can be found in the <a href="https://downloads.haskell.org/ghc/9.8.1-alpha4/docs/users_guide/9.8.1-notes.html">release notes</a>. 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.</p>
<p>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.</p>
<p>As always, do give this release a try and open a <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/new">ticket</a> if you see
anything amiss.</p>
]]></description>
    <pubDate>Tue, 19 Sep 2023 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20230919-ghc-9.8.1-alpha4-released.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC 9.4.7 is now available</title>
    <link>http://haskell.org/ghc/blog/20230825-ghc-9.4.7-released.html</link>
    <description><![CDATA[<h1>GHC 9.4.7 is now available</h1>
<h4 class="text-muted">Zubin Duggal - 2023-08-25</h4>

<p>The GHC developers are happy to announce the availability of GHC 9.4.7. Binary
distributions, source distributions, and documentation are available at
<a href="https://downloads.haskell.org/ghc/9.4.7">downloads.haskell.org</a>.</p>
<p>This release is primarily a bugfix release addressing some issues
found in 9.4.7. These include:</p>
<ul>
<li>A bump to bytestring-0.11.5.2 allowing GHC to be bootstrapped on
systems where the bootstrap compiler is built with the <code>pthread_condattr_setclock</code>
symbol available (<a href="https://gitlab.haskell.org/ghc/ghc/issues/23789">#23789</a>).</li>
<li>A number of bug fixes for scoping bugs in the specialiser, preventing
simplifier panics (<a href="https://gitlab.haskell.org/ghc/ghc/issues/21391">#21391</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/21689">#21689</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/21828">#21828</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/23762">#23762</a>).</li>
<li>Distributing dynamically linked alpine bindists (<a href="https://gitlab.haskell.org/ghc/ghc/issues/23349">#23349</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/23828">#23828</a>).</li>
<li>A bug fix for the release notes syntax, allowing them to built on
systems with older python and sphinx versions (<a href="https://gitlab.haskell.org/ghc/ghc/issues/23807">#23807</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/23818">#23818</a>).</li>
<li>… and a few more. See the <a href="https://downloads.haskell.org/~ghc/9.4.7/docs/users_guide/9.4.7-notes.html">release notes</a> for a full accounting.</li>
</ul>
<p>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.</p>
<p>As always, do give this release a try and open a <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/new">ticket</a> if you see
anything amiss.</p>
<p>Happy compiling,</p>
<ul>
<li>Zubin</li>
</ul>
]]></description>
    <pubDate>Fri, 25 Aug 2023 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20230825-ghc-9.4.7-released.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC 9.8.1-alpha3 is now available</title>
    <link>http://haskell.org/ghc/blog/20230823-ghc-9.8.1-alpha3-released.html</link>
    <description><![CDATA[<h1>GHC 9.8.1-alpha3 is now available</h1>
<h4 class="text-muted">bgamari - 2023-08-23</h4>

<p>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 <a href="https://downloads.haskell.org/ghc/9.8.1-alpha3">downloads.haskell.org</a>.</p>
<p>GHC 9.8 will bring a number of new features and improvements, including:</p>
<ul>
<li><p>Preliminary support the <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0425-decl-invis-binders.rst"><code>TypeAbstractions</code> language extension</a>,
allowing types to be bound in type declarations.</p></li>
<li><p>Support for the <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0451-sized-literals.rst"><code>ExtendedLiterals</code> extension</a>, providing
more consistent support for non-word-sized numeric literals in the surface
language</p></li>
<li><p>Improved rewrite rule matching behavior, allowing limited matching of
higher-order patterns</p></li>
<li><p>Better support for user-defined warnings by way of the <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0541-warning-pragmas-with-categories.rst"><code>WARNING</code>
pragma</a></p></li>
<li><p>The introduction of the new <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0433-unsatisfiable.rst"><code>GHC.TypeError.Unsatisfiable</code></a>
constraint, allowing more predictable user-defined type errors</p></li>
<li><p>Implementation of the <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0134-deprecating-exports-proposal.rst">export deprecation proposal</a>,
allowing module exports to be marked with <code>DEPRECATE</code> pragmas</p></li>
<li><p>The addition of <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0540-jsem.rst">build semaphore support</a> for parallel compilation,
allowing better use of parallelism across GHC builds</p></li>
<li><p>More efficient representation of info table provenance information,
reducing binary sizes by nearly 80% in some cases when
<code>-finfo-table-map</code> is in use</p></li>
</ul>
<p>A full accounting of changes can be found in the <a href="https://downloads.haskell.org/ghc/9.8.1-alpha3/docs/users_guide/9.8.1-notes.html">release notes</a>. 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.</p>
<p>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.</p>
<p>As always, do give this release a try and open a <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/new">ticket</a> if you see
anything amiss.</p>
]]></description>
    <pubDate>Wed, 23 Aug 2023 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20230823-ghc-9.8.1-alpha3-released.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC 9.8.1-alpha2 is now available</title>
    <link>http://haskell.org/ghc/blog/20230809-ghc-9.8.1-alpha2-released.html</link>
    <description><![CDATA[<h1>GHC 9.8.1-alpha2 is now available</h1>
<h4 class="text-muted">bgamari - 2023-08-09</h4>

<p>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 <a href="https://downloads.haskell.org/ghc/9.8.1-alpha2">downloads.haskell.org</a>.</p>
<p>GHC 9.8 will bring a number of new features and improvements, including:</p>
<ul>
<li><p>Preliminary support the <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0425-decl-invis-binders.rst"><code>TypeApplications</code> language extension</a>,
allowing types to be bound in type declarations.</p></li>
<li><p>Support for the <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0451-sized-literals.rst"><code>ExtendedLiterals</code> extension</a>, providing
more consistent support for non-word-sized numeric literals in the surface
language</p></li>
<li><p>Improved rewrite rule matching behavior, allowing limited matching of
higher-order patterns</p></li>
<li><p>Better support for user-defined warnings by way of the <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0541-warning-pragmas-with-categories.rst"><code>WARNING</code>
pragma</a></p></li>
<li><p>The introduction of the new <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0433-unsatisfiable.rst"><code>GHC.TypeError.Unsatisfiable</code></a>
constraint, allowing more predictable user-defined type errors</p></li>
<li><p>Implementation of the <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0134-deprecating-exports-proposal.rst">export deprecation proposal</a>,
allowing module exports to be marked with <code>DEPRECATE</code> pragmas</p></li>
<li><p>The addition of <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0540-jsem.rst">build semaphore support</a> for parallel compilation,
allowing better use of parallelism across GHC builds</p></li>
<li><p>More efficient representation of info table provenance information,
reducing binary sizes by nearly 80% in some cases when
<code>-finfo-table-map</code> is in use</p></li>
</ul>
<p>A full accounting of changes can be found in the <a href="https://downloads.haskell.org/ghc/9.8.1-alpha2/docs/users_guide/9.8.1-notes.html">release notes</a>.
This alpha includes roughly two dozen bug-fixes relative to alpha 1.</p>
<p>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.</p>
<p>As always, do give this release a try and open a <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/new">ticket</a> if you see
anything amiss.</p>
]]></description>
    <pubDate>Wed, 09 Aug 2023 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20230809-ghc-9.8.1-alpha2-released.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC 9.4.6 is now available</title>
    <link>http://haskell.org/ghc/blog/20230807-ghc-9.4.6-released.html</link>
    <description><![CDATA[<h1>GHC 9.4.6 is now available</h1>
<h4 class="text-muted">Zubin Duggal - 2023-08-07</h4>

<p>The GHC developers are happy to announce the availability of GHC 9.4.6. Binary
distributions, source distributions, and documentation are available at
<a href="https://downloads.haskell.org/ghc/9.4.6">downloads.haskell.org</a>.</p>
<p>This release is primarily a bugfix release addressing some issues
found in 9.4.6. These include:</p>
<ul>
<li>Many bug fixes for the simplifier, preventing compiler panics, loops and
incorrect code generation (<a href="https://gitlab.haskell.org/ghc/ghc/issues/22761">#22761</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/22549">#22549</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/23208">#23208</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/22761">#22761</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/22272">#22272</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/23146">#23146</a>,
<a href="https://gitlab.haskell.org/ghc/ghc/issues/23012">#23012</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/22547">#22547</a>).</li>
<li>Bug fixes for the typechecker involving newtype family instances, making
type equalities more robust and bugs having to do with defaulting representation
polymorphic type variables (<a href="https://gitlab.haskell.org/ghc/ghc/issues/23329">#23329</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/23333">#23333</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/23143">#23143</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/23154">#23154</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/23176">#23176</a>).</li>
<li>Some bug fixes for code generation, particularly on the aarch64 backend,
including adding more memory barriers for array read operations (<a href="https://gitlab.haskell.org/ghc/ghc/issues/23541">#23541</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/23749">#23749</a>).</li>
<li>Some bug fixes for windows builds, ensuring the reliablility of IO manager shutdown
and a bug fix for the RTS linker on windows (<a href="https://gitlab.haskell.org/ghc/ghc/issues/23691">#23691</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/22941">#22941</a>).</li>
<li>A bug fix for the non-moving GC ensuring mutator allocations are properly
accounted for (<a href="https://gitlab.haskell.org/ghc/ghc/issues/23312">#23312</a>).</li>
<li>A bug fix preventing some segfaults by ensuring that pinned allocations respect
block size (<a href="https://gitlab.haskell.org/ghc/ghc/issues/23400">#23400</a>).</li>
<li>Many bug fixes for the bytecode interpreter, allowing a greater subset
of the language to be interpreted (<a href="https://gitlab.haskell.org/ghc/ghc/issues/22376">#22376</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/22840">#22840</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/22051">#22051</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/21945">#21945</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/23068">#23068</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/22958">#22958</a>).</li>
<li>… and a few more. See the <a href="https://downloads.haskell.org/~ghc/9.4.6/docs/users_guide/9.4.6-notes.html">release notes</a> for a full accounting.</li>
</ul>
<p>As some of the fixed issues do affect correctness users are encouraged to
upgrade promptly.</p>
<p>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.</p>
<p>As always, do give this release a try and open a <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/new">ticket</a> if you see
anything amiss.</p>
<p>Happy compiling,</p>
<ul>
<li>Zubin</li>
</ul>
]]></description>
    <pubDate>Mon, 07 Aug 2023 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20230807-ghc-9.4.6-released.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC 9.8.1-alpha1 is now available</title>
    <link>http://haskell.org/ghc/blog/20230727-ghc-9.8.1-alpha1-released.html</link>
    <description><![CDATA[<h1>GHC 9.8.1-alpha1 is now available</h1>
<h4 class="text-muted">bgamari - 2023-07-27</h4>

<p>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 <a href="https://downloads.haskell.org/ghc/9.8.1-alpha1">downloads.haskell.org</a>.</p>
<p>GHC 9.8 will bring a number of new features and improvements, including:</p>
<ul>
<li><p>Preliminary support the <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0425-decl-invis-binders.rst"><code>TypeAbstractions</code> language extension</a>,
allowing types to be bound in type declarations.</p></li>
<li><p>Support for the <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0451-sized-literals.rst"><code>ExtendedLiterals</code></a> extension, providing syntax for
non-word-sized numeric literals in the surface language</p></li>
<li><p>Improved rewrite rule matching behavior, allowing limited matching of
higher-order patterns</p></li>
<li><p>Better support for user-defined warnings by way of the <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0541-warning-pragmas-with-categories.rst"><code>WARNING</code> pragma</a></p></li>
<li><p>The introduction of the new <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0433-unsatisfiable.rst"><code>GHC.TypeError.Unsatisfiable</code></a>
constraint, allowing more predictable user-defined type errors</p></li>
<li><p>Implementation of the <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0134-deprecating-exports-proposal.rst">export deprecation proposal</a>, allowing module
exports to be marked with <code>DEPRECATE</code> pragmas</p></li>
<li><p>The addition of <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0540-jsem.rst">build semaphore support</a> for parallel compilation;
with coming support in <code>cabal-install</code> this will allow better use of
parallelism in multi-package builds</p></li>
<li><p>More efficient representation of info table provenance information,
reducing binary sizes by over 50% in some cases when
<code>-finfo-table-map</code> is in use</p></li>
</ul>
<p>A full accounting of changes can be found in the <a href="https://downloads.haskell.org/ghc/9.8.1-alpha1/docs/users_guide/9.8.1-notes.html">release notes</a>.</p>
<p>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.</p>
<p>As always, do give this release a try and open a <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/new">ticket</a> if you see
anything amiss.</p>
]]></description>
    <pubDate>Thu, 27 Jul 2023 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20230727-ghc-9.8.1-alpha1-released.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC 9.2.8 is now available</title>
    <link>http://haskell.org/ghc/blog/20230526-ghc-9.2.8-released.html</link>
    <description><![CDATA[<h1>GHC 9.2.8 is now available</h1>
<h4 class="text-muted">Zubin Duggal - 2023-05-26</h4>

<p>The GHC developers are happy to announce the availability of GHC 9.2.8. Binary
distributions, source distributions, and documentation are available at
<a href="https://downloads.haskell.org/ghc/9.2.8">downloads.haskell.org</a>.</p>
<p>This release is primarily a bugfix release addressing one issue
found in 9.2.7:</p>
<ul>
<li>Fix a bug with RTS linker failing with ‘internal error: m32_allocator_init:
Failed to map’ on newer Linux kernels (<a href="https://gitlab.haskell.org/ghc/ghc/issues/19421">#19421</a>).</li>
</ul>
<p>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.</p>
<p>As always, do give this release a try and open a <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/new">ticket</a> if you see
anything amiss.</p>
<p>Happy compiling,</p>
<ul>
<li>Zubin</li>
</ul>
]]></description>
    <pubDate>Fri, 26 May 2023 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20230526-ghc-9.2.8-released.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC 9.6.2 is now available</title>
    <link>http://haskell.org/ghc/blog/20230523-ghc-9.6.2-released.html</link>
    <description><![CDATA[<h1>GHC 9.6.2 is now available</h1>
<h4 class="text-muted">Ben Gamari - 2023-05-23</h4>

<p>The GHC developers are happy to announce the availability of GHC 9.6.2. Binary
distributions, source distributions, and documentation are available at
<a href="https://downloads.haskell.org/ghc/9.6.2">downloads.haskell.org</a>.</p>
<p>This release is primarily a bugfix release addressing a few issues
found in 9.6.2. These include:</p>
<ul>
<li><p>a number of simplifier and specialisation issues (<a href="https://gitlab.haskell.org/ghc/ghc/issues/22761">#22761</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/22549">#22549</a>)</p></li>
<li><p>A bug resulting in crashes of programs using the new <code>listThreads#</code> primop
(<a href="https://gitlab.haskell.org/ghc/ghc/issues/23071">#23071</a>).</p></li>
<li><p>A compiler crash triggered by certain uses of quantified constraints
(<a href="https://gitlab.haskell.org/ghc/ghc/issues/23171">#23171</a>)</p></li>
<li><p>Various bugs in the Javascript backend have been fixed (<a href="https://gitlab.haskell.org/ghc/ghc/issues/23399">#23399</a>,
<a href="https://gitlab.haskell.org/ghc/ghc/issues/23360">#23360</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/23346">#23346</a>)</p></li>
<li><p>A missing write barrier in the non-moving collector’s handling of selector
thunks, resulting in undefined behavior (<a href="https://gitlab.haskell.org/ghc/ghc/issues/22930">#22930</a>).</p></li>
<li><p>The non-moving garbage collector’s treatment of weak pointers has been
revamped which should allow more reliable finalization of <code>Weak#</code>
closures (<a href="https://gitlab.haskell.org/ghc/ghc/issues/22327">#22327</a>)</p></li>
<li><p>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 (<a href="https://gitlab.haskell.org/ghc/ghc/issues/22929">#22929</a>)</p></li>
</ul>
<p>A full accounting of changes can be found in the <a href="https://downloads.haskell.org/~ghc/9.6.2/docs/users_guide/9.6.2-notes.html">release notes</a>. As
some of the fixed issues do affect correctness users are encouraged to
upgrade promptly.</p>
<p>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.</p>
<p>As always, do give this release a try and open a <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/new">ticket</a> if you see
anything amiss.</p>
<p>Happy compiling,</p>
<ul>
<li>Ben</li>
</ul>
]]></description>
    <pubDate>Tue, 23 May 2023 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20230523-ghc-9.6.2-released.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC 9.4.5 is now available</title>
    <link>http://haskell.org/ghc/blog/20230418-ghc-9.4.5-released.html</link>
    <description><![CDATA[<h1>GHC 9.4.5 is now available</h1>
<h4 class="text-muted">Zubin Duggal - 2023-04-18</h4>

<p>The GHC developers are happy to announce the availability of GHC 9.4.5. Binary
distributions, source distributions, and documentation are available at
<a href="https://downloads.haskell.org/ghc/9.4.5">downloads.haskell.org</a>.</p>
<p>This release is primarily a bugfix release addressing a few issues
found in 9.4.4. These include:</p>
<ul>
<li>Fixes for a number of bug fixes in the simplifier (<a href="https://gitlab.haskell.org/ghc/ghc/issues/22623">#22623</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/22718">#22718</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/22913">#22913</a>, 22695,
<a href="https://gitlab.haskell.org/ghc/ghc/issues/23184">#23184</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/22998">#22998</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/22662">#22662</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/22725">#22725</a>).</li>
<li>Many bug fixes to the non-moving and parallel GCs (<a href="https://gitlab.haskell.org/ghc/ghc/issues/22264">#22264</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/22327">#22327</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/22926">#22926</a>,
<a href="https://gitlab.haskell.org/ghc/ghc/issues/22927">#22927</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/22929">#22929</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/22930">#22930</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/17574">#17574</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/21840">#21840</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/22528">#22528</a>)</li>
<li>A fix a bug with the alignment of RTS data structures that could result in
segfaults when compiled with high optimisation settings on certain platforms
(<a href="https://gitlab.haskell.org/ghc/ghc/issues/22975">#22975</a> , <a href="https://gitlab.haskell.org/ghc/ghc/issues/22965">#22965</a>).</li>
<li>Bumping <code>gmp-tarballs</code> to a version which doesn’t use the reserved <code>x18</code>
register on AArch64/Darwin systems, and also has fixes for CVE-2021-43618
(<a href="https://gitlab.haskell.org/ghc/ghc/issues/22497">#22497</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/22789">#22789</a>).</li>
<li>A number of improvements to recompilation avoidance with multiple home units
(<a href="https://gitlab.haskell.org/ghc/ghc/issues/22675">#22675</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/22677">#22677</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/22669">#22669</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/22678">#22678</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/22679">#22679</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/22680">#22680</a>)</li>
<li>Fixes for regressions in the typechecker and constraint solver (<a href="https://gitlab.haskell.org/ghc/ghc/issues/22647">#22647</a>,
<a href="https://gitlab.haskell.org/ghc/ghc/issues/23134">#23134</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/22516">#22516</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/22743">#22743</a>)</li>
<li>Easier installation of binary distribution on MacOS platforms by changing the
installation Makefile to remove the quarantine attribute when installing.</li>
<li>… and many more. See the <a href="https://downloads.haskell.org/~ghc/9.4.5/docs/users_guide/9.4.5-notes.html">release notes</a> for a full accounting.</li>
</ul>
<p>As some of the fixed issues do affect correctness users are encouraged to
upgrade promptly.</p>
<p>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.</p>
<p>As always, do give this release a try and open a <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/new">ticket</a> if you see
anything amiss.</p>
<p>Happy compiling,</p>
<ul>
<li>Zubin</li>
</ul>
]]></description>
    <pubDate>Tue, 18 Apr 2023 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20230418-ghc-9.4.5-released.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC 9.6.1 is now available</title>
    <link>http://haskell.org/ghc/blog/20230310-ghc-9.6.1-released.html</link>
    <description><![CDATA[<h1>GHC 9.6.1 is now available</h1>
<h4 class="text-muted">bgamari - 2023-03-10</h4>

<p>The GHC team is very pleased to announce the availability of GHC 9.6.1.
As usual, binaries and source distributions are available at
<a href="https://downloads.haskell.org/ghc/9.6.1/">downloads.haskell.org</a>.</p>
<p>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:</p>
<ul>
<li><p>Both the Javascript and WebAssembly backends are still at an early
stage of development and are present in this release as a technology preview</p></li>
<li><p>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</p></li>
<li><p>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</p></li>
</ul>
<p>We hope to lift all of these limitations in future releases.</p>
<p>Additionally, 9.6.1 includes:</p>
<ul>
<li><p>Significant latency improvements in the non-moving garbage collector</p></li>
<li><p>Efficient runtime support for delimited continuations</p></li>
<li><p>Improvements in compiler error messages</p></li>
<li><p>Numerous improvements in the compiler’s memory usage</p></li>
</ul>
<p>See the <a href="https://downloads.haskell.org/ghc/9.6.1/docs/users_guide/9.6.1-notes.html">release notes</a> for a comprehensive accounting of changes in this
release.</p>
<p>As always, one can find a migration guide to aid in transitioning from older
releases on the <a href="https://gitlab.haskell.org/ghc/ghc/-/wikis/migration/9.6">GHC Wiki</a>. 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 <code>glibc</code> releases (namely
2.27), respectively.</p>
<p>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!</p>
<p>Cheers,</p>
<ul>
<li>Ben</li>
</ul>
]]></description>
    <pubDate>Fri, 10 Mar 2023 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20230310-ghc-9.6.1-released.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC 9.6.1-rc1 is now available</title>
    <link>http://haskell.org/ghc/blog/20230303-ghc-9.6.1-rc1-released.html</link>
    <description><![CDATA[<h1>GHC 9.6.1-rc1 is now available</h1>
<h4 class="text-muted">bgamari - 2023-03-03</h4>

<p>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
<a href="https://downloads.haskell.org/ghc/9.6.1-rc1/">downloads.haskell.org</a>.</p>
<p>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:</p>
<ul>
<li><p>Both the Javascript and WebAssembly backends are still at an early
stage of development and are present in this release as a technology preview</p></li>
<li><p>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</p></li>
<li><p>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</p></li>
</ul>
<p>We hope to lift all of these limitations in future releases.</p>
<p>Additionally, 9.6.1 will include:</p>
<ul>
<li><p>Significant latency improvements in the non-moving garbage collector</p></li>
<li><p>Efficient runtime support for delimited continuations</p></li>
<li><p>Improvements in compiler error messages</p></li>
<li><p>Numerous improvements in the compiler’s memory usage</p></li>
</ul>
<p>See the <a href="https://downloads.haskell.org/ghc/9.6.1-rc1/docs/users_guide/9.6.1-notes.html">release notes</a> for a comprehensive accounting of changes in this
release.</p>
<p>As always, one can find a migration guide to aid in transitioning from older
releases on the <a href="https://gitlab.haskell.org/ghc/ghc/-/wikis/migration/9.6">GHC Wiki</a>. 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 <code>glibc</code> releases (namely
2.27), respectively.</p>
<p>Please do give this release a try and open a <a href="https://gitlab.haskell.org/ghc/ghc/issues/">ticket</a> if you see anything
amiss. If all goes well we expect the final release should be available by late
next week.</p>
<p>Cheers,</p>
<ul>
<li>Ben</li>
</ul>
]]></description>
    <pubDate>Fri, 03 Mar 2023 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20230303-ghc-9.6.1-rc1-released.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC 9.2.7 is now available</title>
    <link>http://haskell.org/ghc/blog/20230227-ghc-9.2.7-released.html</link>
    <description><![CDATA[<h1>GHC 9.2.7 is now available</h1>
<h4 class="text-muted">Zubin Duggal - 2023-02-27</h4>

<p>The GHC developers are happy to announce the availability of GHC 9.2.7. Binary
distributions, source distributions, and documentation are available at
<a href="https://downloads.haskell.org/ghc/9.2.7">downloads.haskell.org</a>.</p>
<p>This release is primarily a bugfix release addressing a few issues
found in 9.2.6. These include:</p>
<ul>
<li>A fix for a bug with the RTS linker being unable to resolve the <code>setKeepCafs</code>
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 (<a href="https://gitlab.haskell.org/ghc/ghc/issues/22961">#22961</a>).</li>
<li>A fix a bug with the alignment of RTS data structures that could result in
segfaults when compiled with high optimisation settings on certain platforms
(<a href="https://gitlab.haskell.org/ghc/ghc/issues/22975">#22975</a> , <a href="https://gitlab.haskell.org/ghc/ghc/issues/22965">#22965</a>).</li>
<li>A fix for a bug in the simplifier related to placeholder values (rubbish
literals) emitted by the worker/wrapper optimisation leading to -dcore-lint
errors and compiler panics in certain cases (<a href="https://gitlab.haskell.org/ghc/ghc/issues/19882">#19882</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/22914">#22914</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/23000">#23000</a>).</li>
<li>Easier installation of binary distribution on MacOS platforms by changing the
installation Makefile to remove the quarantine attribute when installing.</li>
<li>… and a few more. See the <a href="https://downloads.haskell.org/~ghc/9.2.7/docs/html/users_guide/9.2.7-notes.html">release notes</a> for a full accounting.</li>
</ul>
<p>As some of the fixed issues do affect correctness users are encouraged to
upgrade promptly.</p>
<p>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.</p>
<p>As always, do give this release a try and open a <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/new">ticket</a> if you see
anything amiss.</p>
<p>Happy compiling,</p>
<ul>
<li>Zubin</li>
</ul>
]]></description>
    <pubDate>Mon, 27 Feb 2023 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20230227-ghc-9.2.7-released.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC 9.6.1-alpha3 is now available</title>
    <link>http://haskell.org/ghc/blog/20230213-ghc-9.6.1-alpha3-released.html</link>
    <description><![CDATA[<h1>GHC 9.6.1-alpha3 is now available</h1>
<h4 class="text-muted">bgamari - 2023-02-13</h4>

<p>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
<a href="https://downloads.haskell.org/ghc/9.6.1-alpha3/">downloads.haskell.org</a>.</p>
<p>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:</p>
<ul>
<li><p>Both the Javascript and WebAssembly backends are still at an early
stage of development and are present in this release as a technology preview</p></li>
<li><p>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</p></li>
<li><p>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</p></li>
</ul>
<p>We hope to lift all of these limitations in future releases.</p>
<p>Additionally, 9.6.1 will include:</p>
<ul>
<li><p>Significant latency improvements in the non-moving garbage collector</p></li>
<li><p>Efficient runtime support for delimited continuations</p></li>
<li><p>Improvements in compiler error messages</p></li>
<li><p>Numerous improvements in the compiler’s memory usage</p></li>
</ul>
<p>See the <a href="https://downloads.haskell.org/ghc/9.6.1-alpha3/docs/users_guide/9.6.1-notes.html">release notes</a> for a comprehensive accounting of changes in this
release.</p>
<p>As always, one can find a migration guide to aid in transitioning from older
releases on the <a href="https://gitlab.haskell.org/ghc/ghc/-/wikis/migration/9.6">GHC Wiki</a>. 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 <code>glibc</code> releases (namely
2.27), respectively.</p>
<p>Please do give this release a try and open a <a href="https://gitlab.haskell.org/ghc/ghc/issues/">ticket</a> if you see anything
amiss.</p>
<p>Cheers,</p>
<ul>
<li>Ben</li>
</ul>
]]></description>
    <pubDate>Mon, 13 Feb 2023 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20230213-ghc-9.6.1-alpha3-released.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC 9.2.6 is now available</title>
    <link>http://haskell.org/ghc/blog/20230210-ghc-9.2.6-released.html</link>
    <description><![CDATA[<h1>GHC 9.2.6 is now available</h1>
<h4 class="text-muted">Zubin Duggal - 2023-02-10</h4>

<p>The GHC developers are happy to announce the availability of GHC 9.2.6. Binary
distributions, source distributions, and documentation are available at
<a href="https://downloads.haskell.org/ghc/9.2.6">downloads.haskell.org</a>.</p>
<p>This release is primarily a bugfix release addressing a few issues
found in 9.2.5. These include:</p>
<ul>
<li>Fixes for a number of simplifier issues typically resulting in compiler panics
(<a href="https://gitlab.haskell.org/ghc/ghc/issues/22491">#22491</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/22482">#22482</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/19824">#19824</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/22718">#22718</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/22662">#22662</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/22039">#22039</a>).</li>
<li>Fix for a simplifier regression in 9.2.5 that could impact runtime performance
when compiling with optimisations due to duplication of expensive work (<a href="https://gitlab.haskell.org/ghc/ghc/issues/22425">#22425</a>).</li>
<li>Various stability improvments and bug fixes for the non moving and parallel GCs
(<a href="https://gitlab.haskell.org/ghc/ghc/issues/22528">#22528</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/20221">#20221</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/22264">#22264</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/22327">#22327</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/22929">#22929</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/22927">#22927</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/22929">#22929</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/22930">#22930</a>).</li>
<li>Allow certain keywords which can be used as variable names with
<code>-XOverloadedRecordDot</code> (<a href="https://gitlab.haskell.org/ghc/ghc/issues/20723">#20723</a>).</li>
<li>Improvements to typechecker performance for modules with holes in type
signatures (<a href="https://gitlab.haskell.org/ghc/ghc/issues/14766">#14766</a>)</li>
<li>Bump <code>gmp-tarballs</code> to a version which doesn’t use the reserved <code>x18</code>
register on AArch64/Darwin systems, and also has fixes for CVE-2021-43618
(<a href="https://gitlab.haskell.org/ghc/ghc/issues/22497">#22497</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/22789">#22789</a>).</li>
<li>… and a few more. See the <a href="https://downloads.haskell.org/~ghc/9.2.6/docs/html/users_guide/9.2.6-notes.html">release notes</a> for a full accounting.</li>
</ul>
<p>As some of the fixed issues do affect correctness users are encouraged to
upgrade promptly.</p>
<p>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.</p>
<p>As always, do give this release a try and open a <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/new">ticket</a> if you see
anything amiss.</p>
<p>Happy compiling,</p>
<ul>
<li>Zubin</li>
</ul>
]]></description>
    <pubDate>Fri, 10 Feb 2023 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20230210-ghc-9.2.6-released.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC 9.6.1-alpha2 is now available</title>
    <link>http://haskell.org/ghc/blog/20230130-ghc-9.6.1-alpha2-released.html</link>
    <description><![CDATA[<h1>GHC 9.6.1-alpha2 is now available</h1>
<h4 class="text-muted">bgamari - 2023-01-30</h4>

<p>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
<a href="https://downloads.haskell.org/ghc/9.6.1-alpha2/">downloads.haskell.org</a>.</p>
<p>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:</p>
<ul>
<li><p>Both the Javascript and WebAssembly backends are still at an early
stage of development and are present in this release as a technology preview</p></li>
<li><p>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</p></li>
<li><p>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</p></li>
</ul>
<p>We hope to lift all of these limitations in future releases.</p>
<p>Additionally, 9.6.1 will include:</p>
<ul>
<li><p>Significant latency improvements in the non-moving garbage collector</p></li>
<li><p>Efficient runtime support for delimited continuations</p></li>
<li><p>Improvements in compiler error messages</p></li>
<li><p>Numerous improvements in the compiler’s memory usage</p></li>
</ul>
<p>See the <a href="https://downloads.haskell.org/ghc/9.6.1-alpha2/docs/users_guide/9.6.1-notes.html">release notes</a> for a comprehensive accounting of changes in this
release.</p>
<p>As always, one can find a migration guide to aid in transitioning from older
releases on the <a href="https://gitlab.haskell.org/ghc/ghc/-/wikis/migration/9.6">GHC Wiki</a>. 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 <code>glibc</code> releases (namely
2.27), respectively.</p>
<p>Please do give this release a try and open a <a href="https://gitlab.haskell.org/ghc/ghc/issues/">ticket</a> if you see anything
amiss.</p>
<p>Cheers,</p>
<ul>
<li>Ben</li>
</ul>
]]></description>
    <pubDate>Mon, 30 Jan 2023 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20230130-ghc-9.6.1-alpha2-released.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC 9.6.1-alpha1 is now available</title>
    <link>http://haskell.org/ghc/blog/20230113-ghc-9.6.1-alpha1-released.html</link>
    <description><![CDATA[<h1>GHC 9.6.1-alpha1 is now available</h1>
<h4 class="text-muted">bgamari - 2023-01-13</h4>

<p>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
<a href="https://downloads.haskell.org/ghc/9.6.1-alpha1/">downloads.haskell.org</a>.
This is the first alpha release in the 9.6 series which will bring a number of
exciting features:</p>
<ul>
<li><p>A new Javascript code generation backend</p></li>
<li><p>A new WebAssembly code generation backend,</p></li>
<li><p>Significant latency improvements in the non-moving garbage collector</p></li>
<li><p>Support for loading of multiple components in GHCi</p></li>
<li><p>Efficient support for delimited continuations</p></li>
<li><p>Improvements in error messages</p></li>
<li><p>Numerous improvements in compiler-residency</p></li>
</ul>
<p>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.</p>
<p>Please give this release a try and open a <a href="https://gitlab.haskell.org/ghc/ghc/issues/">ticket</a> if you see anything
amiss.</p>
<p>Cheers,</p>
<ul>
<li>Ben</li>
</ul>
]]></description>
    <pubDate>Fri, 13 Jan 2023 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20230113-ghc-9.6.1-alpha1-released.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC 9.4.4 released</title>
    <link>http://haskell.org/ghc/blog/20221224-ghc-9.4.4-released.html</link>
    <description><![CDATA[<h1>GHC 9.4.4 released</h1>
<h4 class="text-muted">bgamari - 2022-12-24</h4>

<p>The GHC developers are happy to announce the availability of GHC 9.4.4. Binary
distributions, source distributions, and documentation are available at
<a href="https://downloads.haskell.org/ghc/9.4.4">downloads.haskell.org</a>.</p>
<p>This release is primarily a bugfix release. Bugs fixed include:</p>
<ul>
<li>An issue where the wrong labels were used in the eventlog for events emitted
when using info table profiling which was broken in 9.4.3 (<a href="https://gitlab.haskell.org/ghc/ghc/issues/22452">#22452</a>)</li>
<li>Fix a long standing bug where invalid eventlogs would be produced with long
command-lines (<a href="https://gitlab.haskell.org/ghc/ghc/issues/20221">#20221</a>)</li>
<li>Fix a regression in eta-expansion which resulted in serious performance
regressions in 9.4.3 (<a href="https://gitlab.haskell.org/ghc/ghc/issues/22424">#22424</a>)</li>
<li>Fix the <code>-fdefer-diagnostics</code> flag (<a href="https://gitlab.haskell.org/ghc/ghc/issues/22391">#22391</a>)</li>
<li>Fixes to several subtle compiler panics. (<a href="https://gitlab.haskell.org/ghc/ghc/issues/22491">#22491</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/22416">#22416</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/22549">#22549</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/22475">#22475</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/22039">#22039</a>)</li>
<li>Add necessary write barriers to <code>IORef</code> operations, avoiding potential
soundness issues on architectures with weakly-ordered memory models
(<a href="https://gitlab.haskell.org/ghc/ghc/issues/22468">#22468</a>)</li>
</ul>
<p>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 <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/new">ticket</a>. Likewise, if you are a downstream
packager, do consider migrating to <a href="https://gitlab.haskell.org/ghc/ghc/-/blob/e2520df3fffa0cf22fb19c5fb872832d11c07d35/hadrian">Hadrian</a> to run your build; the Hadrian
build system can be built using <code>cabal-install</code>, <code>stack</code>, or the in-tree
<a href="https://gitlab.haskell.org/ghc/ghc/-/blob/e2520df3fffa0cf22fb19c5fb872832d11c07d35/hadrian/bootstrap/README.md">bootstrap script</a>. See the accompanying <a href="https://www.haskell.org/ghc/blog/20220805-make-to-hadrian.html">blog post</a> for details on
migrating packaging to Hadrian.</p>
<p>We would also like to emphasize that GHC 9.4 must be used in conjunction with
<code>Cabal-3.8</code> or later. This is particularly important for Windows users due to
changes in GHC’s Windows toolchain.</p>
<p>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.</p>
<p>As always, do give this release a try and open a <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/new">ticket</a> if you see
anything amiss.</p>
<p>Happy Haskelling,</p>
<ul>
<li>Ben</li>
</ul>
]]></description>
    <pubDate>Sat, 24 Dec 2022 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20221224-ghc-9.4.4-released.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC 9.2.5 is now available</title>
    <link>http://haskell.org/ghc/blog/20221107-ghc-9.2.5-released.html</link>
    <description><![CDATA[<h1>GHC 9.2.5 is now available</h1>
<h4 class="text-muted">Zubin Duggal - 2022-11-07</h4>

<p>The GHC developers are happy to announce the availability of GHC 9.2.5. Binary
distributions, source distributions, and documentation are available at
<a href="https://downloads.haskell.org/ghc/9.2.5">downloads.haskell.org</a>.</p>
<p>This release is primarily a bugfix release addressing a few issues
found in 9.2.4. These include:</p>
<ul>
<li>Code generation issues in the AArch64 native code generator backend
resulting in incorrect runtime results in some circumstances (<a href="https://gitlab.haskell.org/ghc/ghc/issues/22282">#22282</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/21964">#21964</a>)</li>
<li>Fixes for a number of issues with the simplifier leading to core lint
errors and suboptimal performance (<a href="https://gitlab.haskell.org/ghc/ghc/issues/21694">#21694</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/21755">#21755</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/22114">#22114</a>)</li>
<li>A long-standing interface-file determinism issue where full paths would leak
into the interface file (<a href="https://gitlab.haskell.org/ghc/ghc/issues/22162">#22162</a>)</li>
<li>A runtime system bug where creating empty mutable arrays resulted in a crash
(<a href="https://gitlab.haskell.org/ghc/ghc/issues/21962">#21962</a>)</li>
<li>… and a few more. See the <a href="https://downloads.haskell.org/~ghc/9.2.5/docs/html/users_guide/9.2.5-notes.html">release notes</a> for a full accounting.</li>
</ul>
<p>As some of the fixed issues do affect correctness users are encouraged to
upgrade promptly.</p>
<p>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.</p>
<p>As always, do give this release a try and open a <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/new">ticket</a> if you see
anything amiss.</p>
<p>Happy compiling,</p>
<ul>
<li>Zubin</li>
</ul>
]]></description>
    <pubDate>Mon, 07 Nov 2022 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20221107-ghc-9.2.5-released.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC 9.4.3 released</title>
    <link>http://haskell.org/ghc/blog/20221103-ghc-9.4.3-released.html</link>
    <description><![CDATA[<h1>GHC 9.4.3 released</h1>
<h4 class="text-muted">bgamari - 2022-11-03</h4>

<p>The GHC developers are happy to announce the availability of GHC 9.4.3. Binary
distributions, source distributions, and documentation are available at
<a href="https://downloads.haskell.org/ghc/9.4.3">downloads.haskell.org</a>.</p>
<p>This release is primarily a bugfix release addressing a few issues
found in 9.4.2. These include:</p>
<ul>
<li>An issue where recursively calls could be speculatively evaluated, resulting
in non-termination (<a href="https://gitlab.haskell.org/ghc/ghc/issues/20836">#20836</a>)</li>
<li>A code generation issue in the AArch64 native code generator backend
resulting in incorrect runtime results in some circumstances (<a href="https://gitlab.haskell.org/ghc/ghc/issues/22282">#22282</a>)</li>
<li>A crash on Darwin when running executables compiled with IPE support (<a href="https://gitlab.haskell.org/ghc/ghc/issues/22080">#22080</a>)</li>
<li>A long-standing interface-file determinism issue where full paths would leak
into the interface file (<a href="https://gitlab.haskell.org/ghc/ghc/issues/22162">#22162</a>)</li>
<li>A bug in the <code>process</code> library where file handles specified as <code>NoStream</code> would
still be usable in the child (<a href="https://github.com/haskell/process/issues/251">process<span>#251</span></a>)</li>
</ul>
<p>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 <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/new">ticket</a>. Likewise, if you are a downstream
packager, do consider migrating to <a href="https://gitlab.haskell.org/ghc/ghc/-/blob/e2520df3fffa0cf22fb19c5fb872832d11c07d35/hadrian">Hadrian</a> to run your build; the Hadrian
build system can be built using <code>cabal-install</code>, <code>stack</code>, or the in-tree
<a href="https://gitlab.haskell.org/ghc/ghc/-/blob/e2520df3fffa0cf22fb19c5fb872832d11c07d35/hadrian/bootstrap/README.md">bootstrap script</a>. See the accompanying <a href="https://www.haskell.org/ghc/blog/20220805-make-to-hadrian.html">blog post</a> for details on
migrating packaging to Hadrian.</p>
<p>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.</p>
<p>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.</p>
<p>As always, do give this release a try and open a <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/new">ticket</a> if you see
anything amiss.</p>
<p>Happy Haskelling,</p>
<ul>
<li>Ben</li>
</ul>
]]></description>
    <pubDate>Thu, 03 Nov 2022 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20221103-ghc-9.4.3-released.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC 9.4.2 released</title>
    <link>http://haskell.org/ghc/blog/20220822-ghc-9.4.2-released.html</link>
    <description><![CDATA[<h1>GHC 9.4.2 released</h1>
<h4 class="text-muted">bgamari - 2022-08-22</h4>

<p>The GHC developers are happy to announce the availability of GHC 9.4.2. Binary
distributions, source distributions, and documentation are available at
<a href="https://downloads.haskell.org/ghc/9.4.2">downloads.haskell.org</a>.</p>
<p>This release is primarily a bugfix release addressing a few packaging issues
found in 9.4.1. See the <a href="https://downloads.haskell.org/~ghc/9.4.2/docs/users_guide/9.4.2-notes.html">release notes</a> for a full accounting.</p>
<p>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 <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/new">ticket</a>. Likewise, if you are a downstream
packager, do consider migrating to <a href="https://gitlab.haskell.org/ghc/ghc/-/blob/e2520df3fffa0cf22fb19c5fb872832d11c07d35/hadrian">Hadrian</a> to run your build; the Hadrian
build system can be built using <code>cabal-install</code>, <code>stack</code>, or the in-tree
<a href="https://gitlab.haskell.org/ghc/ghc/-/blob/e2520df3fffa0cf22fb19c5fb872832d11c07d35/hadrian/bootstrap/README.md">bootstrap script</a>. See the accompanying <a href="https://www.haskell.org/ghc/blog/20220805-make-to-hadrian.html">blog post</a> for details on
migrating packaging to Hadrian.</p>
<p>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.</p>
<p>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.</p>
<p>As always, do give this release a try and open a <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/new">ticket</a> if you see
anything amiss.</p>
<p>Happy Haskelling,</p>
<ul>
<li>Ben</li>
</ul>
]]></description>
    <pubDate>Mon, 22 Aug 2022 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20220822-ghc-9.4.2-released.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC 9.4.1 released</title>
    <link>http://haskell.org/ghc/blog/20220807-ghc-9.4.1-released.html</link>
    <description><![CDATA[<h1>GHC 9.4.1 released</h1>
<h4 class="text-muted">bgamari - 2022-08-07</h4>

<p>The GHC developers are happy to announce the availability of GHC 9.4.1. Binary
distributions, source distributions, and documentation are available at
<a href="https://downloads.haskell.org/ghc/9.4.1">downloads.haskell.org</a>.</p>
<p>This release includes:</p>
<ul>
<li><p>A new profiling mode, <code>-fprof-late</code>, which adds automatic cost-center
annotations to all top-level functions <em>after</em> 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..</p></li>
<li><p>A variety of plugin improvements including the introduction of a new
plugin type, <em>defaulting plugins</em>, and the ability for typechecking
plugins to rewrite type-families.</p></li>
<li><p>An improved constructed product result analysis, allowing unboxing of
nested structures, and a new boxity analysis, leading to less reboxing.</p></li>
<li><p>Introduction of a tag-check elision optimisation, bringing
significant performance improvements in strict programs.</p></li>
<li><p>Generalisation of a variety of primitive types to be levity
polymorphic. Consequently, the <code>ArrayArray#</code> type can at long last be
retired, replaced by standard <code>Array#</code>.</p></li>
<li><p>Introduction of the <code>\cases</code> syntax from <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0302-cases.rst">GHC proposal 0302</a>.</p></li>
<li><p>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.</p></li>
<li><p>Support for multiple home packages, significantly improving support
in IDEs and other tools for multi-package projects.</p></li>
<li><p>A refactoring of GHC’s error message infrastructure, allowing GHC to
provide diagnostic information to downstream consumers as structured
data, greatly easing IDE support.</p></li>
<li><p>Significant compile-time improvements to runtime and memory consumption.</p></li>
<li><p>On overhaul of our packaging infrastructure, allowing full
traceability of release artifacts and more reliable binary
distributions.</p></li>
<li><p>Reintroduction of deep subsumption (which was previously dropped with the
<em>simplified subsumption</em> change) as a language extension.</p></li>
<li><p>… and much more. See the <a href="https://downloads.haskell.org/~ghc/9.4.1/docs/users_guide/9.4.1-notes.html">release notes</a> for a full accounting.</p></li>
</ul>
<p>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 <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/new">ticket</a>. Likewise, if you are a downstream packager, do consider
migrating to <a href="https://gitlab.haskell.org/ghc/ghc/-/blob/e2520df3fffa0cf22fb19c5fb872832d11c07d35/hadrian">Hadrian</a> to run your build; the Hadrian build system can be built
using <code>cabal-install</code>, <code>stack</code>, or the in-tree <a href="https://gitlab.haskell.org/ghc/ghc/-/blob/e2520df3fffa0cf22fb19c5fb872832d11c07d35/hadrian/bootstrap/README.md">bootstrap script</a>. See the accompanying
<a href="https://www.haskell.org/ghc/blog/20220805-make-to-hadrian.html">blog post</a> for details on migrating packaging to Hadrian.</p>
<p>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.</p>
<p>As always, do give this release a try and open a <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/new">ticket</a> if you see
anything amiss.</p>
<p>Happy testing,</p>
<ul>
<li>Ben</li>
</ul>
]]></description>
    <pubDate>Sun, 07 Aug 2022 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20220807-ghc-9.4.1-released.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>Migrating from Make to Hadrian (for packagers)</title>
    <link>http://haskell.org/ghc/blog/20220805-make-to-hadrian.html</link>
    <description><![CDATA[<h1>Migrating from Make to Hadrian (for packagers)</h1>
<h4 class="text-muted">Sam Derbyshire - 2022-08-05</h4>

<p>As the <a href="https://gitlab.haskell.org/ghc/ghc/blob/master/hadrian/README.md">Hadrian build system for
GHC</a> 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.</p>
<p>This blog post will give an overview of using Hadrian, which should help
packagers migrate from the old Make-based build system.</p>
<!-- more -->
<h2 id="the-hadrian-build-system">The Hadrian build system</h2>
<p>Hadrian is a modular, statically-typed, extensible build system for GHC, introduced in the paper <a href="https://www.microsoft.com/en-us/research/wp-content/uploads/2016/03/hadrian.pdf">Non-recursive Make Considered Harmful</a>. It consists of a Haskell executable implemented using the <a href="https://hackage.haskell.org/package/shake">shake</a> library, and is used to configure and build GHC.</p>
<h2 id="building-hadrian">Building Hadrian</h2>
<p>Contributors to GHC will be accustomed to running the <code>./hadrian/build</code> script,
which builds and runs Hadrian. This script calls out to <code>cabal</code>, 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 <code>hadrian/bootstrap</code> directory.</p>
<h3 id="bootstrapping-hadrian">Bootstrapping Hadrian</h3>
<p>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:</p>
<ul>
<li>Locally:
<ul>
<li>Choose a build plan appropriate for the bootstrap GHC version, such as <code>hadrian/bootstrap/plan-bootstrap-8.10.7.json</code>.
(These build plans can also be generated manually from a <code>cabal-install</code> build plan; see <code>generate_bootstrap_plans</code>)</li>
<li>Fetch the sources needed by the build plan:
<code>bootstrap.py fetch -w &lt;path_to_ghc&gt; --deps plan-bootstrap-8.10.7.json -o 8_10_7_bootstrap_sources.tar.gz</code></li>
</ul></li>
<li>In the build environment:
<ul>
<li>Provision the <code>bootstrap-sources</code> tarball generated above.</li>
</ul></li>
<li>In your GHC build script:
<ul>
<li>Build Hadrian using the bootstrap script:
<code>bootstrap.py -w &lt;path_to_ghc&gt; --bootstrap-sources 8_10_7_bootstrap_sources.tar.gz</code></li>
<li>Build GHC using the resulting Hadrian executable, located by default in <code>bin/hadrian</code>, e.g.
<code>bin/hadrian -j --flavour=perf+debug_info -w &lt;path_to_ghc&gt;</code></li>
</ul></li>
</ul>
<p>An example of how to use these bootstrap scripts can be seen in the <a href="https://gitlab.haskell.org/bgamari/ghcs-nix/-/blob/master/hadrian-bootstrap.nix"><code>ghcs-nix</code>
repository</a>.
This repository contains Nix expressions specifying how to build many GHC
versions, with both Make and Hadrian.</p>
<p>From now on, we will assume that you have built Hadrian (either via
<code>./hadrian/build</code> or via bootstrapping), referring to the <code>hadrian</code> executable
agnostically.</p>
<h2 id="using-hadrian">Using Hadrian</h2>
<h3 id="how-does-hadrian-replace-make">How does Hadrian replace make?</h3>
<p>To build GHC, we begin as before by running <code>./boot</code> (if necessary, i.e. a
<code>configure</code> file doesn’t already exist) and then <code>./configure &lt;args&gt;</code>. 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 <code>GHC</code> environment variable,
and the selection of the C compiler uses the <code>CC</code> environment variable. This is
unchanged, and details can be found on the <a href="https://gitlab.haskell.org/ghc/ghc/-/wikis/building/using#run-the-configure-script">GHC
wiki</a>.</p>
<p>Once the configure script is run, we replace <code>make</code> commands with <code>hadrian</code>
commands. The fundamental command to build GHC with Hadrian is</p>
<div class="sourceCode" id="cb1"><pre class="sourceCode sh"><code class="sourceCode bash"><span id="cb1-1"><a href="#cb1-1" aria-hidden="true" tabindex="-1"></a><span class="ex">hadrian</span> <span class="op">&lt;</span>args<span class="op">&gt;</span></span></code></pre></div>
<h3 id="hadrian-stages">Hadrian stages</h3>
<p>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 <strong>stages</strong>:</p>
<ul>
<li>The <code>stage0</code> compiler is the bootstrap compiler: a user-provided executable
which will be used to compile GHC. The bootstrap compiler is chosen via the
<code>GHC</code> variable passed to the <code>configure</code> script.</li>
<li>The <code>stage1</code> compiler is the compiler built using the <code>stage0</code> 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.</li>
<li>The <code>stage2</code> compiler is the compiler built using the <code>stage1</code> compiler; it
runs on the target platform. The <code>stage2</code> compiler is necessary for the
implementation of Template Haskell and GHC plugins.</li>
</ul>
<p>In Hadrian, build artifacts are put in a subdirectory of the build folder (by
default, <code>_build</code>) corresponding to the stage of the compiler <strong>used to perform
the build</strong>. This means that the <code>stage2</code> compiler will be found (if using the
default build directory, <code>_build</code>) at <code>_build/stage1/bin/ghc</code>.</p>
<p>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</p>
<div class="sourceCode" id="cb2"><pre class="sourceCode sh"><code class="sourceCode bash"><span id="cb2-1"><a href="#cb2-1" aria-hidden="true" tabindex="-1"></a><span class="ex">hadrian</span> <span class="op">&lt;</span>stage<span class="op">&gt;</span>:<span class="dt">{lib</span><span class="op">,</span><span class="dt">exe}</span>:<span class="op">&lt;</span>package name<span class="op">&gt;</span></span></code></pre></div>
<p>For example, <code>hadrian stage2:lib:base</code> will build the <code>stage2</code> <code>base</code> library,
and put it into the <code>_build/stage1</code> subdirectory.</p>
<h3 id="flavours-and-flavour-transformers">Flavours and flavour transformers</h3>
<p>A Hadrian <strong>build flavour</strong> is a pre-defined collection of build settings that
fully define a GHC build. These are described
<a href="https://gitlab.haskell.org/ghc/ghc/blob/master/hadrian/doc/flavours.md">here</a>.
The flavour being used determines the ways in which GHC and its libraries will
be built, as described in the <a href="https://gitlab.haskell.org/ghc/ghc/blob/master/hadrian/doc/flavours.md#ways">Hadrian documentation</a>.
This replaces the variables of the <code>make</code> build system such as <code>GhcLibWays</code>,
<code>DYNAMIC_GHC_PROGRAMS</code>, <code>DYNAMIC_BY_DEFAULT</code>.</p>
<p>A flavour is set using the <code>--flavour</code> command-line argument, e.g.
<code>hadrian/build --flavour=perf</code>. As a packager you probably want to use either
the <code>release</code> or <code>perf</code> flavour:</p>
<div class="table">
<table>
<colgroup>
<col style="width: 43%" />
<col style="width: 56%" />
</colgroup>
<thead>
<tr class="header">
<th>flavour name</th>
<th>description</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td><code>perf</code></td>
<td>A fully optimised bindist</td>
</tr>
<tr class="even">
<td><code>release</code></td>
<td>The same configuration as <code>perf</code>, but with additional build products such as interface files containing Haddock docs</td>
</tr>
</tbody>
</table>
</div>
<p>Flavours can be modified using <em>flavour transformers</em>. For example, the
<code>profiled_ghc</code> flavour transformer compiles the GHC library and executable with
cost-centre profiling enabled. One can, e.g., apply the <code>profiled_ghc</code>
transformer to the <code>perf</code> flavour with <code>hadrian --flavour=perf+profiled_ghc</code>.</p>
<div class="table">
<table>
<thead>
<tr class="header">
<th>Make variable</th>
<th>Hadrian flavour transformer</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td><code>GhcProfiled</code></td>
<td><code>profiled_ghc</code></td>
</tr>
<tr class="even">
<td><code>GhcDebugged</code></td>
<td><code>debug_ghc</code></td>
</tr>
<tr class="odd">
<td><code>SplitObjs</code></td>
<td><code>split_sections</code></td>
</tr>
</tbody>
</table>
</div>
<p>The full list of supported flavour transformers is available
<a href="https://gitlab.haskell.org/ghc/ghc/blob/master/hadrian/doc/flavours.md">here</a>.</p>
<h3 id="building-ghc-for-distribution">Building GHC for distribution</h3>
<p>Packagers will be interested in the <code>binary-dist</code> and <code>binary-dist-dir</code> Hadrian
targets. For example, the command</p>
<div class="sourceCode" id="cb3"><pre class="sourceCode sh"><code class="sourceCode bash"><span id="cb3-1"><a href="#cb3-1" aria-hidden="true" tabindex="-1"></a><span class="ex">hadrian/build</span> <span class="at">--flavour</span><span class="op">=</span>release binary-dist</span></code></pre></div>
<p>will produce a complete release binary distribution tarball, while the
<code>binary-dist-dir</code> target produces the directory only (not the tarball). The
resulting bindist will be placed in <code>_build/bindist</code>.</p>
<p>When building the <code>binary-dist</code> target, documentation (namely, Haddock
documentation and GHC’s <a href="https://www.sphinx-doc.org/">Sphinx</a>-built user’s
guide) will be built by default. Building of documentation can be disabled
using Hadrian’s <code>--docs=...</code> 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:</p>
<pre><code># Build only the documentation for the base package, without using sphinx
hadrian {..} docs:base --docs=no-sphinx</code></pre>
<p>Further information about configuring the documentation built by Hadrian can be
found in the <a href="https://gitlab.haskell.org/ghc/ghc/blob/master/hadrian/README.md#documentation">Hadrian readme</a>.</p>
<h3 id="large-integer-implementation">Large-integer implementation</h3>
<p>GHC supports several implementations of the <code>Integer</code>/<code>Natural</code> types and
operations on them. The selection of the implementation is done using the
<code>--bignum</code> Hadrian argument, e.g. <code>--bignum=gmp</code> to use the <a href="https://gmplib.org/">GMP
library</a>, or <code>--bignum=native</code> to use a pure-Haskell
implementation.</p>
<h3 id="key-value-settings">Key-value settings</h3>
<p>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:</p>
<pre><code>hadrian {..} &quot;*.*.ghc.*.opts += -my-ghc-option&quot;</code></pre>
<p>Passing an additional option when compiling the <code>ghc</code> library only:</p>
<pre><code>hadrian {..} &quot;*.ghc.ghc.*.opts += -my-ghc-option&quot;</code></pre>
<p>These settings can also be placed in a <code>hadrian.settings</code> file in the build
root (by default <code>_build</code>), instead of passing them in the command line.</p>
<p>Hadrian currently supports the <a href="https://gitlab.haskell.org/ghc/ghc/-/blob/a9fc15b1228d557c2241a28ac702d4a6e140d975/hadrian/doc/user-settings.md#key-value-and-key-value-style-settings">following key-value settings</a></p>
<ul>
<li><code>(&lt;stage&gt; or *).(&lt;package name&gt; or *).ghc.{hs, c, cpp, link, deps, *}.opts</code><br />
Arguments passed to GHC invocations.
<ul>
<li><code>hs</code> for arguments passed to GHC when compiling Haskell modules</li>
<li><code>c</code> for arguments passed to the C compiler</li>
<li><code>cpp</code> for arguments passed to the C++ compiler</li>
<li><code>link</code> for arguments passed during linking</li>
<li><code>deps</code> for arguments to a <code>ghc -M</code> command, which outputs
dependency information between Haskell modules</li>
</ul></li>
<li><code>(&lt;stage&gt; or *).(&lt;package name&gt; or *).cc.{c, deps, *}.opts</code><br />
Arguments passed directly to the C compiler.</li>
<li><code>(&lt;stage&gt; or *).(&lt;package name&gt; or *).cabal.configure.opts</code><br />
Arguments passed to the cabal configure step.</li>
<li><code>(&lt;stage&gt; or *).(&lt;package name&gt; or *).hsc2hs.run.opts</code><br />
Arguments passed when running Hsc2Hs.</li>
</ul>
<p>These Hadrian key-value settings are useful to replace the assignment of Make variables,
even though Hadrian is not intended to be a one-to-one replacement of Make;
recovering the behaviour with Hadrian might require a few tweaks.</p>
<p>Consider for example the way that Make passes flags to GHC when compiling
source Haskell files. Make has several different variables, such as
<code>SRC_HC_OPTS</code>, <code>WAY_&lt;way&gt;_&lt;pkg&gt;_OPTS</code>, <code>EXTRA_HC_OPTS</code>. 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
<code>*.*.ghc.hs.opts</code> Hadrian key-value setting.</p>
<p>The following table serves as a general guideline in migrating the use of Make variables (bearing the above caveats in mind):</p>
<div class="table">
<table>
<colgroup>
<col style="width: 49%" />
<col style="width: 50%" />
</colgroup>
<thead>
<tr class="header">
<th>Make variable</th>
<th>Hadrian key-value setting</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td><code>GhcLibOpts</code></td>
<td><code>*.*.ghc.*.opts</code></td>
</tr>
<tr class="even">
<td><code>GhcRtsHcOpts</code></td>
<td><code>*.*.rts.*.opts</code></td>
</tr>
<tr class="odd">
<td><code>SRC_HC_OPTS</code>, <code>EXTRA_HC_OPTS</code></td>
<td><code>*.*.ghc.hs.opts</code></td>
</tr>
<tr class="even">
<td><code>SRC_CC_OPTS</code>, <code>EXTRA_CC_OPTS</code></td>
<td><code>*.*.ghc.c.opts</code> with <code>-optc</code> prefix</td>
</tr>
<tr class="odd">
<td><code>SRC_CPP_OPTS</code>, <code>EXTRA_CPP_OPTS</code></td>
<td>a combination of <code>*.*.ghc.c.opts</code> with <code>-optc</code> prefix and <code>*.*.cc.c.opts</code></td>
</tr>
<tr class="even">
<td><code>SRC_LD_OPTS</code>, <code>EXTRA_LD_OPTS</code></td>
<td><code>*.*.ghc.link.opts</code> with <code>-optl</code> prefix</td>
</tr>
<tr class="odd">
<td><code>&lt;pkg&gt;_EXTRA_LD_OPTS</code></td>
<td><code>*.&lt;pkg&gt;.ghc.link.opts</code> with <code>-optl</code> prefix</td>
</tr>
<tr class="even">
<td><code>&lt;pkg&gt;_CONFIGURE_OPTS</code></td>
<td><code>*.&lt;pkg&gt;.cabal.configure.opts</code></td>
</tr>
<tr class="odd">
<td><code>utils/hsc2hs_dist-install_EXTRA_LD_OPTS</code></td>
<td><code>*.*.hsc2hs.run.opt</code> with <code>-L</code> prefix</td>
</tr>
</tbody>
</table>
</div>
<p>To pass module-specific or way-specific options, e.g. passing a C pre-processor
option when compiling specific modules in a certain <code>way</code> (as when using a
<code>Way_&lt;way&gt;_&lt;pkg&gt;_OPTS</code> Make variable), please use the programmatic interface
described <a href="#programmatic-configuration">below</a>.</p>
<h3 id="programmatic-configuration">Programmatic configuration</h3>
<p>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 <a href="https://gitlab.haskell.org/ghc/ghc/-/blob/master/hadrian/doc/user-settings.md#directly-modifying-hadrian-configuration">Hadrian
manual</a>.
A good starting place to look for inspiration is <a href="https://gitlab.haskell.org/ghc/ghc/-/blob/a9fc15b1228d557c2241a28ac702d4a6e140d975/hadrian/src/Settings/Packages.hs">Settings.Packages</a>, which contains the
arguments used to build GHC and the libraries it depends upon. The
<a href="https://hackage.haskell.org/package/shake">documentation for Shake</a> is also a
helpful resource, as Hadrian uses the Shake EDSL to implement its build rules.</p>
<h2 id="further-support">Further support</h2>
<p>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.</p>
]]></description>
    <pubDate>Fri, 05 Aug 2022 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20220805-make-to-hadrian.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC 9.2.4 is now available</title>
    <link>http://haskell.org/ghc/blog/20220728-ghc-9.2.4-released.html</link>
    <description><![CDATA[<h1>GHC 9.2.4 is now available</h1>
<h4 class="text-muted">Zubin Duggal - 2022-07-28</h4>

<p>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 <a href="https://downloads.haskell.org/ghc/9.2.4"><code>downloads.haskell.org</code></a>.</p>
<p>This release will include:</p>
<ul>
<li><p>The new <code>DeepSubsumption</code> language extension which reverses the
effects of the <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0287-simplify-subsumption.rst">Simplified Subsumption Proposal</a> 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.</p>
<p>This extension is enabled by default with the <code>Haskell2010</code>
and <code>Haskell98</code> languages but disabled with the <code>GHC2021</code>
language originally introduced in GHC 9.2.1.</p>
<p>See the <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0511-deep-subsumption.rst">Deep Subsumption Proposal</a> for more details.</p></li>
<li><p>Fixes for segfaults that may arise due to a bug in the implementation of the
<code>keepAlive#</code> primop. This may regress performance for certain programs which
use this primop or functions which use the primop, such as <code>withForeignPtr</code>.
These regressions are mostly small, but can be larger in certain edge cases.
Judicious use of <code>unsafeWithForeignPtr</code> 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 (<a href="https://gitlab.haskell.org/ghc/ghc/issues/21708">#21708</a>).</p>
<p>We have a <a href="https://gitlab.haskell.org/ghc/ghc/-/wikis/proposal/with-combinator">wiki page</a>
that tracks possible solutions to this problem, and Ben wrote a
<a href="https://www.haskell.org/ghc/blog/20210607-the-keepAlive-story.html">blog post</a>
detailing the introduction of the <code>keepAlive#</code> primop and its history.</p></li>
<li><p>Fixes for a number of miscompilations on AArch64 and other platforms (<a href="https://gitlab.haskell.org/ghc/ghc/issues/21624">#21624</a>,
<a href="https://gitlab.haskell.org/ghc/ghc/issues/21773">#21773</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/20735">#20735</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/21685">#21685</a>).</p></li>
<li><p>Fixes for segfaults due to bugs in the RTS and GC (<a href="https://gitlab.haskell.org/ghc/ghc/issues/21708">#21708</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/21880">#21880</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/21885">#21885</a>).</p></li>
<li><p>Fixing the behaviour of Ctrl-C with GHCi on Windows (<a href="https://gitlab.haskell.org/ghc/ghc/issues/21889">#21889</a>).</p></li>
<li><p>… and much more. See the <a href="https://downloads.haskell.org/~ghc/9.2.4/docs/html/users_guide/9.2.4-notes.html">release notes</a> for a full accounting.</p></li>
</ul>
<p>As some of the fixed issues do affect correctness users are encouraged to
upgrade promptly.</p>
<p>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.</p>
<p>As always, do give this release a try and open a <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/new">ticket</a> if you see
anything amiss.</p>
<p>Happy compiling,</p>
<ul>
<li>Zubin</li>
</ul>
]]></description>
    <pubDate>Thu, 28 Jul 2022 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20220728-ghc-9.2.4-released.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC 9.4.1-rc1 released</title>
    <link>http://haskell.org/ghc/blog/20220721-ghc-9.4.1-rc1-released.html</link>
    <description><![CDATA[<h1>GHC 9.4.1-rc1 released</h1>
<h4 class="text-muted">bgamari - 2022-07-21</h4>

<p>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
<a href="https://downloads.haskell.org/ghc/9.4.1-rc1">downloads.haskell.org</a>.</p>
<p>This release will include:</p>
<ul>
<li><p>A new profiling mode, <code>-fprof-late</code>, which adds automatic cost-center
annotations to all top-level functions <em>after</em> 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..</p></li>
<li><p>A variety of plugin improvements including the introduction of a new
plugin type, <em>defaulting plugins</em>, and the ability for typechecking
plugins to rewrite type-families.</p></li>
<li><p>An improved constructed product result analysis, allowing unboxing of
nested structures, and a new boxity analysis, leading to less reboxing.</p></li>
<li><p>Introduction of a tag-check elision optimisation, bringing
significant performance improvements in strict programs.</p></li>
<li><p>Generalisation of a variety of primitive types to be levity
polymorphic. Consequently, the <code>ArrayArray#</code> type can at long last be
retired, replaced by standard <code>Array#</code>.</p></li>
<li><p>Introduction of the <code>\cases</code> syntax from <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0302-cases.rst">GHC proposal 0302</a>.</p></li>
<li><p>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.</p></li>
<li><p>Support for multiple home packages, significantly improving support
in IDEs and other tools for multi-package projects.</p></li>
<li><p>A refactoring of GHC’s error message infrastructure, allowing GHC to
provide diagnostic information to downstream consumers as structured
data, greatly easing IDE support.</p></li>
<li><p>Significant compile-time improvements to runtime and memory consumption.</p></li>
<li><p>On overhaul of our packaging infrastructure, allowing full
traceability of release artifacts and more reliable binary
distributions.</p></li>
<li><p>Reintroduction of deep subsumption (which was previously dropped with the
<em>simplified subsumption</em> change) as a language extension.</p></li>
<li><p>… and much more. See the <a href="https://downloads.haskell.org/~ghc/9.4.1-rc1/docs/users_guide/9.4.1-notes.html">release notes</a> for a full accounting.</p></li>
</ul>
<p>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 <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/new">ticket</a>. Likewise, if you are a downstream packager, do consider
migrating to <a href="https://gitlab.haskell.org/ghc/ghc/-/blob/e2520df3fffa0cf22fb19c5fb872832d11c07d35/hadrian">Hadrian</a> to run your build; the Hadrian build system can be built
using <code>cabal-install</code>, <code>stack</code>, or the in-tree <a href="https://gitlab.haskell.org/ghc/ghc/-/blob/e2520df3fffa0cf22fb19c5fb872832d11c07d35/hadrian/bootstrap/README.md">bootstrap script</a>. We will be
publishing a blog post describing the migration process to Hadrian in the
coming weeks.</p>
<p>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.</p>
<p>As always, do give this release a try and open a <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/new">ticket</a> if you see
anything amiss.</p>
<p>Happy testing,</p>
<ul>
<li>Ben</li>
</ul>
]]></description>
    <pubDate>Thu, 21 Jul 2022 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20220721-ghc-9.4.1-rc1-released.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC 9.4.1-alpha3 released</title>
    <link>http://haskell.org/ghc/blog/20220624-ghc-9.4.1-alpha3-released.html</link>
    <description><![CDATA[<h1>GHC 9.4.1-alpha3 released</h1>
<h4 class="text-muted">bgamari - 2022-06-24</h4>

<p>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
<a href="https://downloads.haskell.org/ghc/9.4.1-alpha3">downloads.haskell.org</a>.</p>
<p>This major release will include:</p>
<ul>
<li><p>A new profiling mode, <code>-fprof-late</code>, which adds automatic cost-center
annotations to all top-level functions <em>after</em> Core optimisation has
run. This incurs significantly less performance cost while still
providing informative profiles.</p></li>
<li><p>A variety of plugin improvements including the introduction of a new
plugin type, <em>defaulting plugins</em>, and the ability for typechecking
plugins to rewrite type-families.</p></li>
<li><p>An improved constructed product result analysis, allowing unboxing of
nested structures, and a new boxity analysis, leading to less reboxing.</p></li>
<li><p>Introduction of a tag-check elision optimisation, bringing
significant performance improvements in strict programs.</p></li>
<li><p>Generalisation of a variety of primitive types to be levity
polymorphic. Consequently, the <code>ArrayArray#</code> type can at long last be
retired, replaced by standard <code>Array#</code>.</p></li>
<li><p>Introduction of the <code>\cases</code> syntax from <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0302-cases.rst">GHC proposal 0302</a></p></li>
<li><p>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.</p></li>
<li><p>Support for multiple home packages, significantly improving support
in IDEs and other tools for multi-package projects.</p></li>
<li><p>A refactoring of GHC’s error message infrastructure, allowing GHC to
provide diagnostic information to downstream consumers as structured
data, greatly easing IDE support.</p></li>
<li><p>Significant compile-time improvements to runtime and memory consumption.</p></li>
<li><p>On overhaul of our packaging infrastructure, allowing full
traceability of release artifacts and more reliable binary
distributions.</p></li>
<li><p>… and much more. See the <a href="https://downloads.haskell.org/~ghc/9.4.1-alpha3/docs/users_guide/9.4.1-notes.html">release notes</a> for a full accounting.</p></li>
</ul>
<p>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 <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/new">ticket</a>. Likewise, if you are a downstream
packager, do consider migrating to <a href="https://gitlab.haskell.org/ghc/ghc/-/blob/e2520df3fffa0cf22fb19c5fb872832d11c07d35/hadrian">Hadrian</a> to run your build; the
Hadrian build system can be built using <code>cabal-install</code>, <code>stack</code>, or the
in-tree <a href="https://gitlab.haskell.org/ghc/ghc/-/blob/e2520df3fffa0cf22fb19c5fb872832d11c07d35/hadrian/bootstrap/README.md">bootstrap script</a>.</p>
<p>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.</p>
<p>As always, do give this release a try and open a <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/new">ticket</a> if you see
anything amiss.</p>
<p>Happy testing,</p>
<ul>
<li>Ben</li>
</ul>
]]></description>
    <pubDate>Fri, 24 Jun 2022 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20220624-ghc-9.4.1-alpha3-released.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC 9.2.3 is now available</title>
    <link>http://haskell.org/ghc/blog/20220527-ghc-9.2.3-released.html</link>
    <description><![CDATA[<h1>GHC 9.2.3 is now available</h1>
<h4 class="text-muted">Zubin Duggal - 2022-05-27</h4>

<p>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 <a href="https://downloads.haskell.org/ghc/9.2.3"><code>downloads.haskell.org</code></a>.</p>
<p>This release includes many bug-fixes and other improvements to 9.2.2 including:</p>
<ul>
<li><p>A fix to a critical linking bug on Windows causing the 9.2.2 release to be unusable (<a href="https://gitlab.haskell.org/ghc/ghc/issues/21196">#21196</a>).</p></li>
<li><p>Numerous bug fixes for regressions and other issues in the typechecker (<a href="https://gitlab.haskell.org/ghc/ghc/issues/2147">#2147</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/21515">#21515</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/20582">#20582</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/20820">#20820</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/21130">#21130</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/21479">#21479</a>).</p></li>
<li><p>Correctness bugs in the code generator and compiler backends (<a href="https://gitlab.haskell.org/ghc/ghc/issues/21396">#21396</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/20959">#20959</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/21465">#21465</a>).</p></li>
<li><p>Packaging fixes on many platforms (<a href="https://gitlab.haskell.org/ghc/ghc/issues/20760">#20760</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/21487">#21487</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/21402">#21402</a>).</p></li>
<li><p>Many others. See the <a href="https://downloads.haskell.org/ghc/9.2.3/docs/html/users_guide/9.2.3-notes.html">release notes</a> for a full list.</p></li>
</ul>
<p>As some of the fixed issues do affect correctness users are encouraged to
upgrade promptly.</p>
<p>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.</p>
<p>As always, do give this release a try and open a <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/new">ticket</a> if you see
anything amiss.</p>
<p>Happy compiling,</p>
<ul>
<li>Zubin</li>
</ul>
]]></description>
    <pubDate>Fri, 27 May 2022 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20220527-ghc-9.2.3-released.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC 9.4.1-alpha2 released</title>
    <link>http://haskell.org/ghc/blog/20220524-ghc-9.4.1-alpha2-released.html</link>
    <description><![CDATA[<h1>GHC 9.4.1-alpha2 released</h1>
<h4 class="text-muted">bgamari - 2022-05-24</h4>

<p>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
<a href="https://downloads.haskell.org/ghc/9.4.1-alpha2">downloads.haskell.org</a>.</p>
<p>This major release will include:</p>
<ul>
<li><p>A new profiling mode, <code>-fprof-late</code>, which adds automatic cost-center
annotations to all top-level functions <em>after</em> Core optimisation has
run. This incurs significantly less performance cost while still
providing informative profiles.</p></li>
<li><p>A variety of plugin improvements including the introduction of a new
plugin type, <em>defaulting plugins</em>, and the ability for typechecking
plugins to rewrite type-families.</p></li>
<li><p>An improved constructed product result analysis, allowing unboxing of
nested structures, and a new boxity analysis, leading to less reboxing.</p></li>
<li><p>Introduction of a tag-check elision optimisation, bringing
significant performance improvements in strict programs.</p></li>
<li><p>Generalisation of a variety of primitive types to be levity
polymorphic. Consequently, the <code>ArrayArray#</code> type can at long last be
retired, replaced by standard <code>Array#</code>.</p></li>
<li><p>Introduction of the <code>\cases</code> syntax from <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0302-cases.rst">GHC proposal 0302</a></p></li>
<li><p>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.</p></li>
<li><p>Support for multiple home packages, significantly improving support
in IDEs and other tools for multi-package projects.</p></li>
<li><p>A refactoring of GHC’s error message infrastructure, allowing GHC to
provide diagnostic information to downstream consumers as structured
data, greatly easing IDE support.</p></li>
<li><p>Significant compile-time improvements to runtime and memory consumption.</p></li>
<li><p>On overhaul of our packaging infrastructure, allowing full
traceability of release artifacts and more reliable binary
distributions.</p></li>
<li><p>… and much more. See the <a href="https://downloads.haskell.org/~ghc/9.4.1-alpha2/docs/users_guide/9.4.1-notes.html">release notes</a> for a full accounting.</p></li>
</ul>
<p>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 <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/new">ticket</a>. Likewise, if you are a downstream
packager, do consider migrating to <a href="https://gitlab.haskell.org/ghc/ghc/-/blob/e2520df3fffa0cf22fb19c5fb872832d11c07d35/hadrian">Hadrian</a> to run your build; the
Hadrian build system can be built using <code>cabal-install</code>, <code>stack</code>, or the
in-tree <a href="https://gitlab.haskell.org/ghc/ghc/-/blob/e2520df3fffa0cf22fb19c5fb872832d11c07d35/hadrian/bootstrap/README.md">bootstrap script</a>.</p>
<p>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.</p>
<p>As always, do give this release a try and open a <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/new">ticket</a> if you see
anything amiss.</p>
<p>Happy testing,</p>
<ul>
<li>Ben</li>
</ul>
]]></description>
    <pubDate>Tue, 24 May 2022 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20220524-ghc-9.4.1-alpha2-released.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>Mid 2022 Release Plans</title>
    <link>http://haskell.org/ghc/blog/20220523-release-status.html</link>
    <description><![CDATA[<h1>Mid 2022 Release Plans</h1>
<h4 class="text-muted">Matthew Pickering - 2022-05-23</h4>

<p>This post sets out our current plans for the upcoming
releases in the next few months.</p>
<h2 id="section">9.4.1</h2>
<p>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.</p>
<p>The final 9.4.1 release is scheduled for late July.</p>
<p>The release manager for this release is Ben Gamari.</p>
<h2 id="section-1">9.2.3</h2>
<p>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:</p>
<ul>
<li>a panic involving unbound cycle-breaker variables that prevented several
libraries from compiling, such as <code>massiv-io</code> (<a href="https://gitlab.haskell.org/ghc/ghc/issues/20231">#20231</a>),</li>
<li>a typechecker regression in which GHC refused to use recursive equalities
involving type families (<a href="https://gitlab.haskell.org/ghc/ghc/issues/21473">#21473</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/21515">#21515</a>).</li>
</ul>
<p>The release manager for this release is Zubin Duggal.</p>
<h2 id="series">9.0.* series</h2>
<p>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:</p>
<ul>
<li>The 9.2 series does not contain significant breakage (when upgrading from 9.0)</li>
<li>Anecdotal evidence suggests that many companies are upgrading straight from 8.10.7
to 9.2.2 and skipping the 9.0.* releases.</li>
<li>We do not currently have capacity to manage 4 active branches.</li>
</ul>
<h2 id="conclusion">Conclusion</h2>
<p>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 <a href="mailto:ghc-devs@haskell.org" class="uri">mailto:ghc-devs@haskell.org</a>.</p>
]]></description>
    <pubDate>Mon, 23 May 2022 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20220523-release-status.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC 9.4.1-alpha1 released</title>
    <link>http://haskell.org/ghc/blog/20220501-ghc-9.4.1-alpha1-released.html</link>
    <description><![CDATA[<h1>GHC 9.4.1-alpha1 released</h1>
<h4 class="text-muted">bgamari - 2022-05-01</h4>

<p>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
<a href="https://downloads.haskell.org/ghc/9.4.1-alpha1">downloads.haskell.org</a>.</p>
<p>This major release will include:</p>
<ul>
<li><p>A new profiling mode, <code>-fprof-late</code>, which adds automatic cost-center
annotations to all top-level functions <em>after</em> Core optimisation has
run. This incurs significantly less performance cost while still
providing informative profiles.</p></li>
<li><p>A variety of plugin improvements including the introduction of a new
plugin type, <em>defaulting plugins</em>, and the ability for typechecking
plugins to rewrite type-families.</p></li>
<li><p>An improved constructed product result analysis, allowing unboxing of
nested structures, and a new boxity analysis, leading to less reboxing.</p></li>
<li><p>Introduction of a tag-check elision optimisation, bringing
significant performance improvements in strict programs.</p></li>
<li><p>Generalisation of a variety of primitive types to be levity
polymorphic. Consequently, the <code>ArrayArray#</code> type can at long last be
retired, replaced by standard <code>Array#</code>.</p></li>
<li><p>Introduction of the <code>\cases</code> syntax from <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0302-cases.rst">GHC proposal 0302</a></p></li>
<li><p>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.</p></li>
<li><p>Support for multiple home packages, significantly improving support
in IDEs and other tools for multi-package projects.</p></li>
<li><p>A refactoring of GHC’s error message infrastructure, allowing GHC to
provide diagnostic information to downstream consumers as structured
data, greatly easing IDE support.</p></li>
<li><p>Significant compile-time improvements to runtime and memory consumption.</p></li>
<li><p>… and much more</p></li>
</ul>
<p>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.</p>
<p>As always, do give this release a try and open a <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/new">ticket</a> if you see
anything amiss.</p>
<p>Happy testing,</p>
<ul>
<li>Ben</li>
</ul>
]]></description>
    <pubDate>Sun, 01 May 2022 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20220501-ghc-9.4.1-alpha1-released.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC 9.2.2 is now available</title>
    <link>http://haskell.org/ghc/blog/20220305-ghc-9.2.2-released.html</link>
    <description><![CDATA[<h1>GHC 9.2.2 is now available</h1>
<h4 class="text-muted">bgamari - 2022-03-06</h4>

<p>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 <a href="https://downloads.haskell.org/ghc/9.2.2"><code>downloads.haskell.org</code></a>.</p>
<p>This release includes many bug-fixes and other improvements to 9.2.1 including:</p>
<ul>
<li><p>A number of bug-fixes in the new AArch64 native code generator</p></li>
<li><p>Fixes ensuring that the <code>indexWord8ArrayAs*#</code> family of primops is handled
correctly on platforms lacking support for unaligned memory accesses
(<a href="https://gitlab.haskell.org/ghc/ghc/issues/21015">#21015</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/20987">#20987</a>).</p></li>
<li><p>Improvements to the compatibility story in GHC’s migration to the
XDG Base Directory Specification (<a href="https://gitlab.haskell.org/ghc/ghc/issues/20684">#20684</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/20669">#20669</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/20660">#20660</a>)</p></li>
<li><p>Restored compatibility with Windows 7</p></li>
<li><p>A new <code>-fcompact-unwind</code> flag, improving compatibility with C++ libraries on
Apple Darwin (<a href="https://gitlab.haskell.org/ghc/ghc/issues/11829">#11829</a>)</p></li>
<li><p>Introduction of a new flag, <code>-fcheck-prim-bounds</code>, enabling runtime bounds
checking of array primops (<a href="https://gitlab.haskell.org/ghc/ghc/issues/20769">#20769</a>)</p></li>
<li><p>Unboxing of unlifted types (<a href="https://gitlab.haskell.org/ghc/ghc/issues/20663">#20663</a>)</p></li>
<li><p>Numerous improvements in compiler performance.</p></li>
<li><p>Many, many others. See the <a href="https://downloads.haskell.org/ghc/9.2.2/docs/html/users_guide/9.2.2-notes.html">release notes</a> for a full list.</p></li>
</ul>
<p>As some of the fixed issues do affect correctness users are encouraged to
upgrade promptly.</p>
<p>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.</p>
<p>As always, do open a <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/new">ticket</a> if you see anything amiss.</p>
<p>Happy compiling,</p>
<ul>
<li>Ben</li>
</ul>
]]></description>
    <pubDate>Sun, 06 Mar 2022 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20220305-ghc-9.2.2-released.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC 9.0.2 is now available</title>
    <link>http://haskell.org/ghc/blog/20211225-ghc-9.0.2-released.html</link>
    <description><![CDATA[<h1>GHC 9.0.2 is now available</h1>
<h4 class="text-muted">Zubin Duggal - 2021-12-25</h4>

<p>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 <a href="https://downloads.haskell.org/ghc/9.0.2"><code>downloads.haskell.org</code></a>.</p>
<p>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:</p>
<ul>
<li><p>First-class support for Apple M1 hardware using GHC’s LLVM ARM backend.</p></li>
<li><p>Fix a number of incorrect rewrite rules for <code>fromInteger</code> (<a href="https://gitlab.haskell.org/ghc/ghc/issues/19345">#19345</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/20066">#20066</a>).</p></li>
<li><p>Fix a number of runtime system and GC bugs which typically manifested in
crashes (<a href="https://gitlab.haskell.org/ghc/ghc/issues/19417">#19417</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/19297">#19297</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/19645">#19645</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/19667">#19667</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/18033">#18033</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/20132">#20132</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/19715">#19715</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/20399">#20399</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/20414">#20414</a>,
<a href="https://gitlab.haskell.org/ghc/ghc/issues/20649">#20649</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/19147">#19147</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/20051">#20051</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/20093">#20093</a>)</p></li>
<li><p>Fixes for various compiler performance and memory usage issues (<a href="https://gitlab.haskell.org/ghc/ghc/issues/20134">#20134</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/13586">#13586</a>,
<a href="https://gitlab.haskell.org/ghc/ghc/issues/20509">#20509</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/19668">#19668</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/19996">#19996</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/19471">#19471</a>)</p></li>
<li><p>Improvements and bug fixes for the code generator and optimiser (<a href="https://gitlab.haskell.org/ghc/ghc/issues/18638">#18638</a>,
<a href="https://gitlab.haskell.org/ghc/ghc/issues/19581">#19581</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/19700">#19700</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/19996">#19996</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/19181">#19181</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/19822">#19822</a>)</p></li>
<li><p>Fixes for typechecker bugs (<a href="https://gitlab.haskell.org/ghc/ghc/issues/19410">#19410</a> , <a href="https://gitlab.haskell.org/ghc/ghc/issues/19191">#19191</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/19522">#19522</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/19400">#19400</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/19849">#19849</a>)</p></li>
<li><p>Bug fixes for the frontend and parser (<a href="https://gitlab.haskell.org/ghc/ghc/issues/19397">#19397</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/19838">#19838</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/19518">#19518</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/19777">#19777</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/20242">#20242</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/19786">#19786</a>)</p></li>
<li><p>Emit warnings if Unicode Bidirectional Formatting characters are found in the source,
possibly misleading code reviewers (<a href="https://gitlab.haskell.org/ghc/ghc/issues/20263">#20263</a>, <a href="https://trojansource.codes/">vulnerability website</a>).</p></li>
<li><p>Many packaging related fixes, including versioned <code>ghc-pkg</code> executables
(<a href="https://gitlab.haskell.org/ghc/ghc/issues/20087">#20087</a>), and actually distributing GHC versions linked against the
<code>native</code> big integer backend (<a href="https://gitlab.haskell.org/ghc/ghc/issues/18967">#18967</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/19953">#19953</a>) on both Windows and Alpine
Linux. Some previous releases were still linked against the <code>GMP</code> library due to a
misconfiguration of the builders.</p></li>
<li><p>A significant refactoring of <code>process</code> fixing numerous bugs mostly on
Apple platforms (<a href="https://gitlab.haskell.org/ghc/ghc/issues/19994">#19994</a>, <a href="https://github.com/haskell/process/pull/208">process refactoring</a>).</p></li>
<li><p>Bug fixes for the linker on Darwin platforms (<a href="https://gitlab.haskell.org/ghc/ghc/issues/20004">#20004</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/19968">#19968</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/19950">#19950</a>).</p></li>
</ul>
<p>A complete list of bug fixes and improvements can be found in the <a href="https://downloads.haskell.org/ghc/9.0.2/docs/html/users_guide/9.0.2-notes.html">release
notes</a>.</p>
<p>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.</p>
<p>As always, do open a <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/new">ticket</a> if you see anything amiss.</p>
]]></description>
    <pubDate>Sat, 25 Dec 2021 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20211225-ghc-9.0.2-released.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC 9.2.1 is now available</title>
    <link>http://haskell.org/ghc/blog/20211029-ghc-9.2.1-released.html</link>
    <description><![CDATA[<h1>GHC 9.2.1 is now available</h1>
<h4 class="text-muted">bgamari - 2021-10-29</h4>

<p>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 <a href="https://downloads.haskell.org/ghc/9.2.1"><code>downloads.haskell.org</code></a>.</p>
<p>GHC 9.2 brings a number of exciting features including:</p>
<ul>
<li><p>A native code generation backend for AArch64, significantly speeding
compilation time on ARM platforms like the Apple M1.</p></li>
<li><p>Many changes in the area of records, including the new
<code>RecordDotSyntax</code> and <code>NoFieldSelectors</code> language extensions, as well
as Support for <code>DuplicateRecordFields</code> with <code>PatternSynonyms</code>.</p></li>
<li><p>Introduction of the new <code>GHC2021</code> language extension set, giving
users convenient access to a larger set of language extensions which
have been long considered stable.</p></li>
<li><p>Merging of <code>ghc-exactprint</code> into the GHC tree, providing
infrastructure for source-to-source program rewriting out-of-the-box.</p></li>
<li><p>Introduction of a <code>BoxedRep</code> <code>RuntimeRep</code>, allowing for polymorphism
over levity of boxed objects (<a href="https://gitlab.haskell.org/ghc/ghc/issues/17526">#17526</a>)</p></li>
<li><p>Implementation of the <code>UnliftedDataTypes</code> extension, allowing users
to define types which do not admit lazy evaluation (<a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0265-unlifted-datatypes.rst">proposal</a>)</p></li>
<li><p>The new [<code>-hi</code> profiling][] mechanism which provides significantly
improved insight into thunk leaks.</p></li>
<li><p>Support for the <code>ghc-debug</code> out-of-process heap inspection library
<a href="http://ghc.gitlab.haskell.org/ghc-debug/">ghc-debug</a></p></li>
<li><p>Significant improvements in the bytecode interpreter, allowing more
programs to be efficently run in GHCi and Template Haskell splices.</p></li>
<li><p>Support for profiling of pinned objects with the cost-centre profiler
(<a href="https://gitlab.haskell.org/ghc/ghc/issues/7275">#7275</a>)</p></li>
<li><p>Faster compilation and a smaller memory footprint</p></li>
<li><p>Introduction of Haddock documentation support in TemplateHaskell (<a href="https://gitlab.haskell.org/ghc/ghc/issues/5467">#5467</a>)</p></li>
</ul>
<p>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.</p>
<p>As always, do open a <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/new">ticket</a> if you see anything amiss.</p>
<p>Happy testing,</p>
<ul>
<li>Ben</li>
</ul>
]]></description>
    <pubDate>Fri, 29 Oct 2021 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20211029-ghc-9.2.1-released.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC 8.10.7 is now available</title>
    <link>http://haskell.org/ghc/blog/20210827-ghc-8.10.7-released.html</link>
    <description><![CDATA[<h1>GHC 8.10.7 is now available</h1>
<h4 class="text-muted">Zubin Duggal - 2021-08-27</h4>

<p>The GHC team is very pleased to announce the availability of GHC
8.10.7. Source and binary distributions are available at the <a href="https://downloads.haskell.org/ghc/8.10.7/">usual
place</a>.</p>
<p>This is a small bugfix release, fixing one linking portability issue (<a href="https://gitlab.haskell.org/ghc/ghc/issues/19950">#19950</a>)
present in GHC 8.10.5 and GHC 8.10.6 on some x86_64 macOS toolchains, which
resulted in undefined symbol errors for <code>___darwin_check_fd_set_overflow</code>.</p>
<p>Issue <a href="https://gitlab.haskell.org/ghc/ghc/issues/19950">#19950</a> 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).</p>
<p>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.</p>
<p>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.</p>
<p>A complete list of bug fixes and improvements can be found in the <a href="https://downloads.haskell.org/ghc/8.10.7/docs/html/users_guide/8.10.7-notes.html">release
notes</a>.</p>
<p>As always, feel free to report any issues you encounter via
<a href="https://gitlab.haskell.org/ghc/ghc/-/issues/new">gitlab.haskell.org</a>.</p>
]]></description>
    <pubDate>Fri, 27 Aug 2021 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20210827-ghc-8.10.7-released.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC 8.10.6 is now available</title>
    <link>http://haskell.org/ghc/blog/20210814-ghc-8.10.6-released.html</link>
    <description><![CDATA[<h1>GHC 8.10.6 is now available</h1>
<h4 class="text-muted">Zubin Duggal - 2021-08-14</h4>

<p>The GHC team is very pleased to announce the availability of GHC 8.10.6.
Source and binary distributions are available at the <a href="https://downloads.haskell.org/ghc/8.10.6/">usual
place</a>.</p>
<p>This is a bugfix release, fixing many issues present in GHC 8.10.5, including:</p>
<ul>
<li><p>A fix for segmentation faults in GHCi on <code>aarch64-darwin</code> due to
an incorrect foreign import in <code>haskeline</code>. See <a href="https://www.haskell.org/ghc/blog/20210709-capi-usage.html">this blog
post</a> by Ben Gamari
for more details on how your library could be affected.</p></li>
<li><p>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 (<a href="https://gitlab.haskell.org/ghc/ghc/issues/19763">#19763</a>).</p></li>
<li><p>No longer emitting spurious warnings for LLVM versions (LLVM 9-12) that were
actually supported (<a href="https://gitlab.haskell.org/ghc/ghc/issues/19973">#19973</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/19829">#19829</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/19959">#19959</a>).</p></li>
<li><p>Numerous bug fixes for the new LLVM based <code>aarch64-darwin</code> backend (<a href="https://gitlab.haskell.org/ghc/ghc/issues/20132">#20132</a>).</p></li>
<li><p>Fixes and stability improvements for the non-moving GC (<a href="https://gitlab.haskell.org/ghc/ghc/issues/19715">#19715</a>).</p></li>
<li><p>Many other bug fixes for the RTS (<a href="https://gitlab.haskell.org/ghc/ghc/issues/18033">#18033</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/20132">#20132</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/20093">#20093</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/19421">#19421</a>).</p></li>
<li><p>Many packaging related fixes, including versioned <code>ghc-pkg</code> executables
(<a href="https://gitlab.haskell.org/ghc/ghc/issues/20087">#20087</a>), and actually distributing GHC versions linked against the
<code>integer-simple</code> big integer backend (<a href="https://gitlab.haskell.org/ghc/ghc/issues/18967">#18967</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/19953">#19953</a>) on both Windows and Alpine
Linux. Previous releases were still linked against the <code>GMP</code> library due to a
misconfiguration of the builders.</p></li>
<li><p>A significant refactoring of <code>process</code> fixing numerous bugs mostly on
Apple platforms (<a href="https://gitlab.haskell.org/ghc/ghc/issues/19994">#19994</a>, <a href="https://github.com/haskell/process/pull/208">process refactoring</a>).</p></li>
<li><p>A FreeBSD release after fixing issues that caused GHC 8.10.5 to be unable to build
(<a href="https://gitlab.haskell.org/ghc/ghc/issues/19958">#19958</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/19948">#19948</a>).</p></li>
<li><p>Bug fixes for the linker on Darwin platforms (<a href="https://gitlab.haskell.org/ghc/ghc/issues/20004">#20004</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/19968">#19968</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/19950">#19950</a>).</p></li>
</ul>
<p>A complete list of bug fixes and improvements can be found in the <a href="https://downloads.haskell.org/ghc/8.10.6/docs/html/users_guide/8.10.6-notes.html">release
notes</a>.</p>
<p>As always, feel free to report any issues you encounter via
<a href="https://gitlab.haskell.org/ghc/ghc/-/issues/new">gitlab.haskell.org</a>.</p>
]]></description>
    <pubDate>Sat, 14 Aug 2021 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20210814-ghc-8.10.6-released.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC 9.2.1-rc1 is now available</title>
    <link>http://haskell.org/ghc/blog/20210807-ghc-9.2.1-rc1-released.html</link>
    <description><![CDATA[<h1>GHC 9.2.1-rc1 is now available</h1>
<h4 class="text-muted">bgamari - 2021-08-07</h4>

<p>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
<a href="https://downloads.haskell.org/ghc/9.2.1-rc1">downloads.haskell.org</a>.</p>
<p>GHC 9.2 will bring a number of exciting features including:</p>
<ul>
<li><p>A native code generation backend for AArch64, significantly reducing
compilation times on ARM platforms such as the Apple M1.</p></li>
<li><p>Many changes in the area of records, including the new
<code>RecordDotSyntax</code> and <code>NoFieldSelectors</code> language extensions, as well
as Support for <code>DuplicateRecordFields</code> with <code>PatternSynonyms</code>.</p></li>
<li><p>Introduction of the new <code>GHC2021</code> language extension set, giving
users convenient access to a larger set of language extensions which
have been long considered stable.</p></li>
<li><p>Merge of <code>ghc-exactprint</code> into the GHC tree, providing infrastructure
for source-to-source program rewriting out-of-the-box.</p></li>
<li><p>Introduction of a <code>BoxedRep</code> <code>RuntimeRep</code>, allowing for polymorphism
over levity of boxed objects (<a href="https://gitlab.haskell.org/ghc/ghc/issues/17526">#17526</a>)</p></li>
<li><p>Implementation of the <code>UnliftedDataTypes</code> extension, allowing users
to define types which do not admit lazy evaluation (<a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0265-unlifted-datatypes.rst">proposal</a>)</p></li>
<li><p>The new <a href="https://well-typed.com/blog/2021/01/first-look-at-hi-profiling-mode/">-hi profiling</a> mechanism which provides significantly
improved insight into thunk leaks.</p></li>
<li><p>Support for the <code>ghc-debug</code> out-of-process heap inspection library
<a href="http://ghc.gitlab.haskell.org/ghc-debug/">ghc-debug</a></p></li>
<li><p>Support for profiling of pinned objects with the cost-centre profiler
(<a href="https://gitlab.haskell.org/ghc/ghc/issues/7275">#7275</a>)</p></li>
<li><p>Introduction of Haddock documentation support in TemplateHaskell (<a href="https://gitlab.haskell.org/ghc/ghc/issues/5467">#5467</a>)</p></li>
</ul>
<p>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.</p>
<p>As always, do give this a try and open a <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/new">ticket</a> if you see anything amiss.</p>
<p>Happy testing,</p>
<ul>
<li>Ben</li>
</ul>
]]></description>
    <pubDate>Sat, 07 Aug 2021 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20210807-ghc-9.2.1-rc1-released.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>Best practices for foreign imports</title>
    <link>http://haskell.org/ghc/blog/20210709-capi-usage.html</link>
    <description><![CDATA[<h1>Best practices for foreign imports</h1>
<h4 class="text-muted">bgamari - 2021-07-12</h4>

<p>tl;dr: When importing system libraries we strongly recommend that users use
GHC’s <a href="https://downloads.haskell.org/ghc/9.0.1/docs/html/users_guide/exts/ffi.html?highlight=capiffi#extension-CApiFFI"><code>capi</code> calling convention</a>. For details, see the <a href="#recommendations">recommendations
section</a> below.</p>
<p>One of Haskell’s strengths is its great foreign function interface: using
time-tested foreign libraries or raw system calls is just a <code>foreign import</code>
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
<a href="https://www.haskell.org/ghc/blog/20210607-the-keepAlive-story.html"><code>keepAlive#</code> post</a>.
This week we will look at another complexity which has recently caused us
trouble: calling conventions.</p>
<h2 id="why-this-matters">Why this matters</h2>
<p>With the increasing prevalance of ARM hardware with Apple’s recent releases,
many latent bugs due to calling convention details are becoming more visible.</p>
<p>For instance, in <a href="https://gitlab.haskell.org/ghc/ghc/issues/20079">#20079</a> it was noticed that GHCi crashes on
AArch64/Darwin when the terminal window is resized. We eventually found that
this was due to a <a href="https://github.com/judah/haskeline/issues/162">bug</a> in <code>haskeline</code>: <code>ioctl</code>, a variadic
function, was <a href="https://github.com/judah/haskeline/blob/c03e7029b2d9c3d16da5480306b42b8d4ebe03cf/System/Console/Haskeline/Backend/Posix.hsc#L64">imported</a> using GHC’s <code>ccall</code> calling convention.
The <a href="https://github.com/judah/haskeline/pull/163/files">fix</a> is straightforward: use the <a href="https://downloads.haskell.org/ghc/9.0.1/docs/html/users_guide/exts/ffi.html?highlight=capiffi#extension-CApiFFI"><code>capi</code> pseudo-calling
convention</a> introduced in GHC 7.6.1.</p>
<p>It turns out that incorrect <code>ioctl</code> imports is <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/20085#note_363651">rather common
pattern</a> among
Hackage packages. Consequently, we thought it would be helpful to offer some
explicit guidance for users.</p>
<h2 id="background-foreign-calling-conventions">Background: Foreign calling conventions</h2>
<p>During a function call both the caller and the callee must agree on several
operational details:</p>
<ul>
<li>when the function is called:
<ul>
<li>which arguments can be passed in registers?</li>
<li>in what order are the remaining arguments pushed to the stack?</li>
<li>how are variadic functions handled?</li>
<li>must the stack be aligned?</li>
<li>where is the return address found?</li>
</ul></li>
<li>when the function returns:
<ul>
<li>who is responsible for popping the arguments from the stack?</li>
<li>where is the return value(s) stored?</li>
</ul></li>
</ul>
<p>Together, these details are known as a <em>calling convention</em> and are typically
implied by the operating system and target architecture. For instance, x86-64 Linux
(and most other POSIX platforms) typically uses the <a href="https://github.com/hjl-tools/x86-psABI/wiki/x86-64-psABI-1.0.pdf">System V amd64 calling
convention</a> whereas 32-bit Windows has no fewer than three commonly-used
conventions.</p>
<p>When compiling C source, the C compiler determines a function’s
calling convention using its <em>signature</em>, which typically appears in a header
file. However, when GHC imports a function with the usual <code>ccall</code> calling convention, e.g.:</p>
<div class="sourceCode" id="cb1"><pre class="sourceCode haskell"><code class="sourceCode haskell"><span id="cb1-1"><a href="#cb1-1" aria-hidden="true" tabindex="-1"></a>foreign <span class="kw">import</span> ccall &quot;hello_world&quot; helloWorld :: <span class="dt">IO</span> ()</span></code></pre></div>
<p>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:</p>
<ul>
<li>many calling conventions treat variadic functions (e.g. <code>printf</code>)
differently from the corresponding non-variadic signature; while it is
<a href="https://downloads.haskell.org/ghc/9.0.1/docs/html/users_guide/exts/ffi.html?highlight=capiffi#varargs-not-supported-by-ccall-calling-convention">documented</a> that <code>ccall</code> does not support variadic
functions, this fact is not well-known by users.</li>
<li>the type provided by the user may be wrong (e.g. using <code>Int</code> instead of <code>CInt</code>)</li>
</ul>
<p>Unfortunately, with the <code>foreign import ccall</code> mechanism the compiler has no
way of catching such issues, potentially leaving the user with
difficult-to-spot, platform-dependent soundness bugs.</p>
<h2 id="safe-foreign-calls-via-capiffi">Safe foreign calls via <code>CApiFFI</code></h2>
<p>To address help mitigate this class of bugs, GHC 7.10 introduced a new language
extension, <a href="https://downloads.haskell.org/ghc/9.0.1/docs/html/users_guide/exts/ffi.html?highlight=capiffi#extension-CApiFFI"><code>CApiFFI</code></a>, which offers a more robust way to import foreign
functions. Unlike <code>ccall</code>, <code>capi</code> 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:</p>
<div class="sourceCode" id="cb2"><pre class="sourceCode haskell"><code class="sourceCode haskell"><span id="cb2-1"><a href="#cb2-1" aria-hidden="true" tabindex="-1"></a>foreign <span class="kw">import</span> capi &quot;stdio.h puts&quot; c_puts :: <span class="dt">Ptr</span> <span class="dt">CChar</span> -&gt; <span class="dt">IO</span> <span class="dt">CInt</span></span></code></pre></div>
<p>To compile this, GHC will construct a C source file which <code>#include</code>’s
<code>stdio.h</code>. and defines a stub function which performs the call:</p>
<div class="sourceCode" id="cb3"><pre class="sourceCode c"><code class="sourceCode c"><span id="cb3-1"><a href="#cb3-1" aria-hidden="true" tabindex="-1"></a><span class="pp">#include </span><span class="im">&quot;stdio.h&quot;</span></span>
<span id="cb3-2"><a href="#cb3-2" aria-hidden="true" tabindex="-1"></a>HsInt32 ghczuwrapperZC0ZCmainZCHelloZCputs<span class="op">(</span><span class="dt">void</span><span class="op">*</span> a1<span class="op">)</span> <span class="op">{</span></span>
<span id="cb3-3"><a href="#cb3-3" aria-hidden="true" tabindex="-1"></a>    <span class="cf">return</span> puts<span class="op">(</span>a1<span class="op">);</span></span>
<span id="cb3-4"><a href="#cb3-4" aria-hidden="true" tabindex="-1"></a><span class="op">}</span></span></code></pre></div>
<p>This approach brings a few advantages:</p>
<ul>
<li><code>capi</code> imports can be used to import functions defined using CPP</li>
<li>the calling convention is decided by the C compiler using the signature
provided in the indicated header file, eliminating the potential for
inconsistency</li>
<li>variadic functions “just work”</li>
<li>it removes the need to worry about which of Windows’ zoo of supported
conventions is used (see <a href="https://gitlab.haskell.org/ghc/ghc/issues/12890">#12890</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/3052">#3052</a>)</li>
</ul>
<h2 id="recommendations">Recommendations for users</h2>
<p>As a rule, the easiest code to debug is the code that you don’t need to write.
Consequently, users are encouraged to use existing bindings libraries (e.g.
<code>unix</code>) instead of defining their own foreign imports when possible.</p>
<p>Of course, not all libraries have bindings available. In these cases we
recommend that users use <code>foreign import capi</code> for imports of libraries not under
their control (e.g. system libraries).</p>
<p>Note, however, that <code>capi</code> does incur a small (arguably negligible) runtime
cost due to the to the C stub. It is justifiable to use <code>ccall</code> to avoid this
runtime cost in cases where the foreign function is shipped with a package’s
<code>cbits</code>, where the calling convention is clear.</p>
]]></description>
    <pubDate>Mon, 12 Jul 2021 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20210709-capi-usage.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>The tale of keepAlive#</title>
    <link>http://haskell.org/ghc/blog/20210607-the-keepAlive-story.html</link>
    <description><![CDATA[<h1>The tale of keepAlive#</h1>
<h4 class="text-muted">bgamari - 2021-06-08</h4>

<p>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, <code>keepAlive#</code>, which largely replaces the venerable
<code>touch#</code> operation. This post will give some background on <code>touch#</code>, 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.</p>
<p>Users who merely want to know how to adapt their existing <code>touch#</code> uses for the
new <code>keepAlive#</code> should feel free to skip to the <a href="#keepAlive">last section</a> of
the post.</p>
<h2 id="the-challenge-of-foreign-references">The challenge of foreign references</h2>
<p>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.</p>
<p>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.</p>
<p>However, taken together these two features pose significant
challenges to language implementors; specifically, consider a program such as:</p>
<div class="sourceCode" id="cb1"><pre class="sourceCode haskell"><code class="sourceCode haskell"><span id="cb1-1"><a href="#cb1-1" aria-hidden="true" tabindex="-1"></a><span class="co">-- Recall that:</span></span>
<span id="cb1-2"><a href="#cb1-2" aria-hidden="true" tabindex="-1"></a><span class="co">--   newPinnedByteArray       :: Int -&gt; IO (MutableByteArray RealWorld)</span></span>
<span id="cb1-3"><a href="#cb1-3" aria-hidden="true" tabindex="-1"></a><span class="co">--   setByteArray             :: Prim a =&gt; MutableByteArray RealWorld -&gt; Int -&gt; Int -&gt; a -&gt; IO ()</span></span>
<span id="cb1-4"><a href="#cb1-4" aria-hidden="true" tabindex="-1"></a><span class="co">--   mutableByteArrayContents :: MutableByteArray RealWorld -&gt; Ptr a</span></span>
<span id="cb1-5"><a href="#cb1-5" aria-hidden="true" tabindex="-1"></a><span class="kw">import</span> <span class="dt">Data.Primitive.ByteArray</span></span>
<span id="cb1-6"><a href="#cb1-6" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb1-7"><a href="#cb1-7" aria-hidden="true" tabindex="-1"></a>main <span class="ot">=</span> printDots <span class="dv">10</span></span>
<span id="cb1-8"><a href="#cb1-8" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb1-9"><a href="#cb1-9" aria-hidden="true" tabindex="-1"></a><span class="ot">printDots ::</span> <span class="dt">Int</span> <span class="ot">-&gt;</span> <span class="dt">IO</span> ()</span>
<span id="cb1-10"><a href="#cb1-10" aria-hidden="true" tabindex="-1"></a>printDots len <span class="ot">=</span> <span class="kw">do</span></span>
<span id="cb1-11"><a href="#cb1-11" aria-hidden="true" tabindex="-1"></a>    arr <span class="ot">&lt;-</span> newPinnedByteArray len</span>
<span id="cb1-12"><a href="#cb1-12" aria-hidden="true" tabindex="-1"></a>    setByteArray arr <span class="dv">0</span> len (<span class="fu">fromIntegral</span> <span class="op">$</span> <span class="fu">ord</span> <span class="ch">&#39;.&#39;</span><span class="ot"> ::</span> <span class="dt">Word8</span>)</span>
<span id="cb1-13"><a href="#cb1-13" aria-hidden="true" tabindex="-1"></a>    <span class="kw">let</span><span class="ot"> ptr ::</span> <span class="dt">Ptr</span> <span class="dt">CChar</span></span>
<span id="cb1-14"><a href="#cb1-14" aria-hidden="true" tabindex="-1"></a>        ptr <span class="ot">=</span> byteArrayContents arr</span>
<span id="cb1-15"><a href="#cb1-15" aria-hidden="true" tabindex="-1"></a>    puts ptr</span>
<span id="cb1-16"><a href="#cb1-16" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb1-17"><a href="#cb1-17" aria-hidden="true" tabindex="-1"></a><span class="co">-- Recall that:</span></span>
<span id="cb1-18"><a href="#cb1-18" aria-hidden="true" tabindex="-1"></a><span class="co">--   void puts(const char *);</span></span>
<span id="cb1-19"><a href="#cb1-19" aria-hidden="true" tabindex="-1"></a>foreign <span class="kw">import</span> ccall &quot;puts&quot;</span>
<span id="cb1-20"><a href="#cb1-20" aria-hidden="true" tabindex="-1"></a><span class="ot">    puts ::</span> <span class="dt">Ptr</span> <span class="dt">CChar</span> <span class="ot">-&gt;</span> <span class="dt">IO</span> ()</span></code></pre></div>
<p>Here we have allocated an array on the Haskell heap, initialized it, and passed
it to the C <code>puts</code> function, which will print it to <code>stdout</code>. On its face, this
program looks completely innocuous: it contains no mentions of <code>unsafe</code>
functions, the array’s bounds are clearly respected, and <code>puts</code> is specified to
treat its argument as immutable. Indeed, running the program even prints the
expected result (at least most of the time).</p>
<p>However, despite its appearance, this program is fatally flawed. Specifically,
note that <code>puts</code> is (implicitly) declared to be a <code>safe</code> 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 <code>puts</code> there
are no references to <code>arr</code> remaining on the Haskell heap, leading the collector
to conclude that the array can be safely reclaimed. However, <code>arr</code> is <em>not</em>
dead: it is still in use via the <em>off-heap</em> reference passed to <code>puts</code>.
However, this reference is not visible to the garbage collector.</p>
<p>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
<code>byteArrayContents</code> is potentially problematic in this way.</p>
<p>To make such off-heap references visible to the runtime, GHC has long provided the
<code>touch</code> operation (embodied by the <code>GHC.Exts.touch#</code> primop):</p>
<div class="sourceCode" id="cb2"><pre class="sourceCode haskell"><code class="sourceCode haskell"><span id="cb2-1"><a href="#cb2-1" aria-hidden="true" tabindex="-1"></a><span class="ot">touch ::</span> <span class="kw">forall</span> a<span class="op">.</span> a <span class="ot">-&gt;</span> <span class="dt">IO</span> ()</span></code></pre></div>
<p>Semantically (and, mostly, operationally) the action <code>touch x</code> 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 <code>printDots</code> as follows:</p>
<div class="sourceCode" id="cb3"><pre class="sourceCode haskell"><code class="sourceCode haskell"><span id="cb3-1"><a href="#cb3-1" aria-hidden="true" tabindex="-1"></a>printDots len <span class="ot">=</span> </span>
<span id="cb3-2"><a href="#cb3-2" aria-hidden="true" tabindex="-1"></a>    arr <span class="ot">&lt;-</span> newPinnedByteArray len</span>
<span id="cb3-3"><a href="#cb3-3" aria-hidden="true" tabindex="-1"></a>    setByteArray arr <span class="dv">0</span> len (<span class="fu">fromIntegral</span> <span class="op">$</span> <span class="fu">ord</span> <span class="ch">&#39;.&#39;</span><span class="ot"> ::</span> <span class="dt">Word8</span>)</span>
<span id="cb3-4"><a href="#cb3-4" aria-hidden="true" tabindex="-1"></a>    puts (byteArrayContents arr)</span>
<span id="cb3-5"><a href="#cb3-5" aria-hidden="true" tabindex="-1"></a>    touch arr</span></code></pre></div>
<p>Here we have added a <code>touch</code> after the <code>puts</code>, ensuring that <code>arr</code> is retained
<em>at least</em> until the call has returned.</p>
<p>To a functional programmer, <code>touch</code> 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:</p>
<div class="sourceCode" id="cb4"><pre class="sourceCode haskell"><code class="sourceCode haskell"><span id="cb4-1"><a href="#cb4-1" aria-hidden="true" tabindex="-1"></a>hdl <span class="ot">&lt;-</span> openFile <span class="st">&quot;hello.txt&quot;</span></span>
<span id="cb4-2"><a href="#cb4-2" aria-hidden="true" tabindex="-1"></a>hPutStrLn hdl <span class="st">&quot;hello world!&quot;</span></span>
<span id="cb4-3"><a href="#cb4-3" aria-hidden="true" tabindex="-1"></a>hClose hdl</span></code></pre></div>
<p>We prefer to write:
<code>withFile</code>:</p>
<div class="sourceCode" id="cb5"><pre class="sourceCode haskell"><code class="sourceCode haskell"><span id="cb5-1"><a href="#cb5-1" aria-hidden="true" tabindex="-1"></a>withFile <span class="st">&quot;hello.txt&quot;</span> <span class="op">$</span> \hdl <span class="ot">-&gt;</span></span>
<span id="cb5-2"><a href="#cb5-2" aria-hidden="true" tabindex="-1"></a>    hPutStrLn hdl <span class="st">&quot;hello world!&quot;</span></span></code></pre></div>
<p>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 <code>touch</code> and its variants directly. For instance, while
<code>Foreign.ForeignPtr</code> provides a <a href="https://hackage.haskell.org/package/base-4.15.0.0/docs/Foreign-ForeignPtr.html#v:touchForeignPtr"><code>touchForeignPtr</code></a> operation the documentation
strong recommends that the user rather use <a href="https://hackage.haskell.org/package/base-4.15.0.0/docs/Foreign-ForeignPtr.html#v:withForeignPtr"><code>withForeignPtr</code></a>.</p>
<p>While it is rarely seen in user code, the <code>touch#</code> primop has served
the Haskell community well for many years: a handful of occurrences in <code>base</code>,
<code>bytestring</code>, 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.</p>
<h2 id="aside-a-bit-of-simplifier-background">Aside: A bit of simplifier background</h2>
<p>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 <code>touch#</code>. To see why, let us examine
a transform performed by GHC’s simplifier which I will call <em>dead-continuation
elimination</em> (DCE).</p>
<p>Consider that you have a program such as:</p>
<div class="sourceCode" id="cb6"><pre class="sourceCode haskell"><code class="sourceCode haskell"><span id="cb6-1"><a href="#cb6-1" aria-hidden="true" tabindex="-1"></a>doThings <span class="ot">=</span></span>
<span id="cb6-2"><a href="#cb6-2" aria-hidden="true" tabindex="-1"></a>    <span class="kw">case</span> <span class="fu">error</span> <span class="st">&quot;hello world&quot;</span><span class="ot"> ::</span> <span class="dt">Int</span> <span class="kw">of</span></span>
<span id="cb6-3"><a href="#cb6-3" aria-hidden="true" tabindex="-1"></a>      <span class="dv">0</span>  <span class="ot">-&gt;</span>  <span class="co">{- some large expression -}</span></span>
<span id="cb6-4"><a href="#cb6-4" aria-hidden="true" tabindex="-1"></a>      <span class="dv">1</span>  <span class="ot">-&gt;</span>  <span class="co">{- another large expression -}</span></span>
<span id="cb6-5"><a href="#cb6-5" aria-hidden="true" tabindex="-1"></a>      <span class="op">...</span></span></code></pre></div>
<p>Here we have a program with a divergent expression (namely the <code>error</code>
application) scrutinized by a <code>case</code> 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.</p>
<p>By the dead-continuation elimination transform, GHC’s simplifier will cull this
unreachable code, turning the program into:</p>
<div class="sourceCode" id="cb7"><pre class="sourceCode haskell"><code class="sourceCode haskell"><span id="cb7-1"><a href="#cb7-1" aria-hidden="true" tabindex="-1"></a>doThings <span class="ot">=</span></span>
<span id="cb7-2"><a href="#cb7-2" aria-hidden="true" tabindex="-1"></a>    <span class="kw">case</span> <span class="fu">error</span> <span class="st">&quot;hello world&quot;</span><span class="ot"> ::</span> <span class="dt">Int</span> <span class="kw">of</span> { }</span></code></pre></div>
<p>This optimisation can significantly reduce program sizes. Note that exceptions
are only one source of divergence: any non-terminating scrutinee can trigger this
transformation.</p>
<h2 id="the-shortcomings-of-touch">The shortcomings of <code>touch#</code></h2>
<p>With this transformation in mind, consider a trivial modification to the
original <code>printDots</code> program which loops the <code>puts</code> call infinitely:</p>
<div class="sourceCode" id="cb8"><pre class="sourceCode haskell"><code class="sourceCode haskell"><span id="cb8-1"><a href="#cb8-1" aria-hidden="true" tabindex="-1"></a><span class="ot">printManyDots ::</span> <span class="dt">Int</span> <span class="ot">-&gt;</span> <span class="dt">IO</span> ()</span>
<span id="cb8-2"><a href="#cb8-2" aria-hidden="true" tabindex="-1"></a>printManyDots len <span class="ot">=</span> <span class="kw">do</span></span>
<span id="cb8-3"><a href="#cb8-3" aria-hidden="true" tabindex="-1"></a>    arr <span class="ot">&lt;-</span> newPinnedByteArray len</span>
<span id="cb8-4"><a href="#cb8-4" aria-hidden="true" tabindex="-1"></a>    setByteArray arr <span class="dv">0</span> len (<span class="fu">fromIntegral</span> <span class="op">$</span> <span class="fu">ord</span> <span class="ch">&#39;.&#39;</span><span class="ot"> ::</span> <span class="dt">Word8</span>)</span>
<span id="cb8-5"><a href="#cb8-5" aria-hidden="true" tabindex="-1"></a>    forever <span class="op">$</span> puts (byteArrayContents arr)</span>
<span id="cb8-6"><a href="#cb8-6" aria-hidden="true" tabindex="-1"></a>    touch arr</span></code></pre></div>
<p>At its face, this modification looks benign enough; indeed, many server
applications take a very similar form (replacing <code>puts</code> with some request
handling logic). However in <a href="https://gitlab.haskell.org/ghc/ghc/issues/14346">#14346</a> we noticed that the simplifier could in
some cases determine that the <code>forever $ ...</code> expression would diverge and
consequently that the <code>touch arr</code> continuation was unreachable. By the DCE
transform, this continuation could be dropped. Without the <code>touch</code>
application, the garbage collector may prematurely collect <code>arr</code>, resulting in
unsoundness in an otherwise reasonable-looking program.</p>
<p>In light of this, it becomes clear that the design of <code>touch#</code> is not
compatible with DCE (which is otherwise a perfectly sound transform under
Haskell’s semantics): to faithfully serve its purpose, <code>touch#</code> must be
retained even if it could never be executed.</p>
<p>As there are relatively few uses of <code>touch#</code>, we tried for a while to paper
over this issue with the judicious use of <code>NOINLINE</code> 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 <code>base</code> interfaces
(<a href="https://gitlab.haskell.org/ghc/ghc/issues/15260">#15260</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/14403">#14403</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/15544">#15544</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/13707">#13707</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/14329">#14329</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/18061">#18061</a>). 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.</p>
<h2 id="finding-an-alternative-design">Finding an alternative design</h2>
<p>At first glance, the design of a safer <code>touch#</code> seems obvious by analogy to
<code>withFile</code>:</p>
<div class="sourceCode" id="cb9"><pre class="sourceCode haskell"><code class="sourceCode haskell"><span id="cb9-1"><a href="#cb9-1" aria-hidden="true" tabindex="-1"></a><span class="ot">with ::</span> a <span class="ot">-&gt;</span> (a <span class="ot">-&gt;</span> m b) <span class="ot">-&gt;</span> m b</span></code></pre></div>
<p>Under such a design <code>with x f</code> would evaluate to <code>f x</code>, ensuring that <code>x</code> is
kept alive (at least) until evaluation finishes.</p>
<p>While this interface is simple and pleasingly similar to patterns which
Haskellers expect, it does not make for a good primop design. In particular,
<code>touch#</code> 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 <code>with</code> above is <em>extremely</em> restrictive to
the optimisations available to the simplifier.</p>
<p>For instance, consider a function like,</p>
<div class="sourceCode" id="cb10"><pre class="sourceCode haskell"><code class="sourceCode haskell"><span id="cb10-1"><a href="#cb10-1" aria-hidden="true" tabindex="-1"></a><span class="ot">readWord8_touch ::</span> <span class="dt">ForeignPtr</span> <span class="dt">Word8</span> <span class="ot">-&gt;</span> <span class="dt">IO</span> <span class="dt">Word8</span></span>
<span id="cb10-2"><a href="#cb10-2" aria-hidden="true" tabindex="-1"></a>readWord8_touch fptr <span class="ot">=</span> <span class="kw">do</span></span>
<span id="cb10-3"><a href="#cb10-3" aria-hidden="true" tabindex="-1"></a>    n <span class="ot">&lt;-</span> peek (unsafeForeignPtrToPtr fptr)</span>
<span id="cb10-4"><a href="#cb10-4" aria-hidden="true" tabindex="-1"></a>    touch fptr</span>
<span id="cb10-5"><a href="#cb10-5" aria-hidden="true" tabindex="-1"></a>    <span class="fu">return</span> n</span></code></pre></div>
<p>After a bit of simplification this will become:</p>
<div class="sourceCode" id="cb11"><pre class="sourceCode haskell"><code class="sourceCode haskell"><span id="cb11-1"><a href="#cb11-1" aria-hidden="true" tabindex="-1"></a><span class="ot">readWord8_touch ::</span> <span class="dt">ForeignPtr</span> <span class="dt">Word8</span> <span class="ot">-&gt;</span> <span class="dt">IO</span> <span class="dt">Word8</span></span>
<span id="cb11-2"><a href="#cb11-2" aria-hidden="true" tabindex="-1"></a>readWord8_touch fptr <span class="ot">=</span> <span class="dt">IO</span> (\s0 <span class="ot">-&gt;</span></span>
<span id="cb11-3"><a href="#cb11-3" aria-hidden="true" tabindex="-1"></a>    <span class="kw">case</span> readWord8<span class="op">#</span> (unsafeForeignPtrToPtr fptr) s0 <span class="kw">of</span> (<span class="op">#</span> s1, n <span class="op">#</span>) <span class="ot">-&gt;</span></span>
<span id="cb11-4"><a href="#cb11-4" aria-hidden="true" tabindex="-1"></a>    <span class="kw">case</span> touch<span class="op">#</span> fptr s1 <span class="kw">of</span> s2 <span class="ot">-&gt;</span> </span>
<span id="cb11-5"><a href="#cb11-5" aria-hidden="true" tabindex="-1"></a>      (<span class="op">#</span> s2, <span class="dt">W8</span><span class="op">#</span> n <span class="op">#</span>)</span></code></pre></div>
<p>This function will benefit from GHC’s worker/wrapper transform, resulting in
a pair of Core bindings<a href="#fn1" class="footnote-ref" id="fnref1" role="doc-noteref"><sup>1</sup></a>:</p>
<div class="sourceCode" id="cb12"><pre class="sourceCode haskell"><code class="sourceCode haskell"><span id="cb12-1"><a href="#cb12-1" aria-hidden="true" tabindex="-1"></a><span class="co">-- The worker:</span></span>
<span id="cb12-2"><a href="#cb12-2" aria-hidden="true" tabindex="-1"></a><span class="ot">worker_readWord8_touch ::</span> <span class="dt">ForeignPtr</span> <span class="dt">Word8</span> <span class="ot">-&gt;</span> <span class="dt">State</span><span class="op">#</span> <span class="dt">RealWorld</span> <span class="ot">-&gt;</span> (<span class="op">#</span> <span class="dt">State</span><span class="op">#</span> <span class="dt">RealWorld</span>, <span class="dt">Word8</span><span class="op">#</span> <span class="op">#</span>)</span>
<span id="cb12-3"><a href="#cb12-3" aria-hidden="true" tabindex="-1"></a>worker_readWord8_touch fptr s0 <span class="ot">=</span></span>
<span id="cb12-4"><a href="#cb12-4" aria-hidden="true" tabindex="-1"></a>    <span class="kw">case</span> peek (unsafeForeignPtrToPtr fptr) s0 <span class="kw">of</span> (<span class="op">#</span> s0, n <span class="op">#</span>) <span class="ot">-&gt;</span></span>
<span id="cb12-5"><a href="#cb12-5" aria-hidden="true" tabindex="-1"></a>    <span class="kw">case</span> touch<span class="op">#</span> fptr s0 <span class="kw">of</span> s1 <span class="ot">-&gt;</span></span>
<span id="cb12-6"><a href="#cb12-6" aria-hidden="true" tabindex="-1"></a>      (<span class="op">#</span> s1, n <span class="op">#</span>)</span>
<span id="cb12-7"><a href="#cb12-7" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb12-8"><a href="#cb12-8" aria-hidden="true" tabindex="-1"></a><span class="co">-- The wrapper:</span></span>
<span id="cb12-9"><a href="#cb12-9" aria-hidden="true" tabindex="-1"></a><span class="ot">readWord8_touch ::</span> <span class="dt">ForeignPtr</span> <span class="dt">Word8</span> <span class="ot">-&gt;</span> <span class="dt">IO</span> <span class="dt">Word8</span></span>
<span id="cb12-10"><a href="#cb12-10" aria-hidden="true" tabindex="-1"></a>readWord8_touch fptr <span class="ot">=</span> <span class="dt">IO</span> <span class="op">$</span> \s <span class="ot">-&gt;</span></span>
<span id="cb12-11"><a href="#cb12-11" aria-hidden="true" tabindex="-1"></a>    <span class="kw">case</span> worker_readWord fptr s <span class="kw">of</span> (<span class="op">#</span> s1, n <span class="op">#</span>) <span class="ot">-&gt;</span></span>
<span id="cb12-12"><a href="#cb12-12" aria-hidden="true" tabindex="-1"></a>      (<span class="op">#</span> s1, <span class="dt">W8</span><span class="op">#</span> n <span class="op">#</span>)</span>
<span id="cb12-13"><a href="#cb12-13" aria-hidden="true" tabindex="-1"></a><span class="ot">{-# INLINE readWord8_touch #-}</span></span></code></pre></div>
<p>The <code>readWord8_touch</code> wrapper can then be inlined into call sites, allowing
elimination of the <code>W8#</code> allocation (via case-of-known-constructor) at
call-sites which strictly consume the result.</p>
<p>However, if we rewrite <code>readWord8</code> using <code>with</code> we will rather get Core of the
form:</p>
<div class="sourceCode" id="cb13"><pre class="sourceCode haskell"><code class="sourceCode haskell"><span id="cb13-1"><a href="#cb13-1" aria-hidden="true" tabindex="-1"></a><span class="ot">readWord8_with ::</span> <span class="dt">ForeignPtr</span> <span class="dt">Word8</span> <span class="ot">-&gt;</span> <span class="dt">IO</span> <span class="dt">Word8</span></span>
<span id="cb13-2"><a href="#cb13-2" aria-hidden="true" tabindex="-1"></a>readWord8_with fptr <span class="ot">=</span> with fptr <span class="op">$</span> \fptr&#39; <span class="ot">-&gt;</span> <span class="dt">IO</span> <span class="op">$</span> \s0 <span class="ot">-&gt;</span></span>
<span id="cb13-3"><a href="#cb13-3" aria-hidden="true" tabindex="-1"></a>    <span class="kw">case</span> peek (unsafeForeignPtrToPtr fptr&#39;) s0 <span class="kw">of</span> (<span class="op">#</span> s1, n <span class="op">#</span>) <span class="ot">-&gt;</span></span>
<span id="cb13-4"><a href="#cb13-4" aria-hidden="true" tabindex="-1"></a>      (<span class="op">#</span> s1, <span class="dt">W8</span><span class="op">#</span> n <span class="op">#</span>)</span></code></pre></div>
<p>Unlike <code>readWord8_touch</code>, this right-hand side does not have the
constructed-product property and therefore can not benefit from unboxing by the
worker/wrapper transform. Consequently, <code>readWord8_with</code> will allocate
a <code>W8#</code> 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.</p>
<h3 id="recovering-the-cpr-property">Recovering the CPR property?</h3>
<p>At first appearance, there is no reason why GHC could not learn to transform
programs defined in terms of <code>with</code> to retain the CPR property. In particular,
this would require three changes:</p>
<ol type="1">
<li><p>since worker/wrapper may produce results of arbitrary <code>RuntimeRep</code>
we must generalize the type of <code>with</code>:</p>
<div class="sourceCode" id="cb14"><pre class="sourceCode haskell"><code class="sourceCode haskell"><span id="cb14-1"><a href="#cb14-1" aria-hidden="true" tabindex="-1"></a>with<span class="op">#</span><span class="ot"> ::</span> <span class="kw">forall</span> a (<span class="ot">r ::</span> <span class="dt">RuntimeRep</span>) (<span class="ot">b ::</span> <span class="dt">TYPE</span> r)<span class="op">.</span></span>
<span id="cb14-2"><a href="#cb14-2" aria-hidden="true" tabindex="-1"></a>         a <span class="ot">-&gt;</span> (a <span class="ot">-&gt;</span> b) <span class="ot">-&gt;</span> b</span></code></pre></div></li>
<li><p>use <code>State#</code> tokens to enforce execution ordering:</p>
<div class="sourceCode" id="cb15"><pre class="sourceCode haskell"><code class="sourceCode haskell"><span id="cb15-1"><a href="#cb15-1" aria-hidden="true" tabindex="-1"></a>with<span class="op">#</span><span class="ot"> ::</span> <span class="kw">forall</span> a (<span class="ot">r ::</span> <span class="dt">RuntimeRep</span>) (<span class="ot">b ::</span> <span class="dt">TYPE</span> r)<span class="op">.</span></span>
<span id="cb15-2"><a href="#cb15-2" aria-hidden="true" tabindex="-1"></a>         a <span class="ot">-&gt;</span> <span class="dt">State</span><span class="op">#</span> s <span class="ot">-&gt;</span> (<span class="dt">State</span><span class="op">#</span> s <span class="ot">-&gt;</span> b) <span class="ot">-&gt;</span> b</span></code></pre></div></li>
<li><p>teaching the simplifier to “push” strict contexts (e.g. <code>case</code>) into
<code>with#</code> applications. For instance, transform</p>
<div class="sourceCode" id="cb16"><pre class="sourceCode haskell"><code class="sourceCode haskell"><span id="cb16-1"><a href="#cb16-1" aria-hidden="true" tabindex="-1"></a><span class="kw">case</span> (with<span class="op">#</span> x s (\s&#39; <span class="ot">-&gt;</span> k)) <span class="kw">of</span> alt <span class="ot">-&gt;</span> rhs</span></code></pre></div>
<p>into</p>
<div class="sourceCode" id="cb17"><pre class="sourceCode haskell"><code class="sourceCode haskell"><span id="cb17-1"><a href="#cb17-1" aria-hidden="true" tabindex="-1"></a>with<span class="op">#</span> x s (\s&#39; <span class="ot">-&gt;</span> <span class="kw">case</span> k <span class="kw">of</span> alt <span class="ot">-&gt;</span> rhs)</span></code></pre></div>
<p>This transformation, which we call “strict context pushing” (SCP), is
similar to a transform already performed on <code>runRW#</code> applications (<a href="https://gitlab.haskell.org/ghc/ghc/issues/15127">#15127</a>).
In this case of <code>with#</code>, it is sound as it strictly <em>grows</em> the scope of the
continuation and therefore <em>lengthens</em> the lifetime of the kept-alive value.</p></li>
</ol>
<p>This SCP transformation allows us to eliminate the allocation incurred in the
case of <code>readWord8</code> by way of inlining and simplification. That is, consider a
strict call-site of <code>readWord8</code>:</p>
<div class="sourceCode" id="cb18"><pre class="sourceCode haskell"><code class="sourceCode haskell"><span id="cb18-1"><a href="#cb18-1" aria-hidden="true" tabindex="-1"></a><span class="dt">IO</span> <span class="op">$</span> \s0 <span class="ot">-&gt;</span></span>
<span id="cb18-2"><a href="#cb18-2" aria-hidden="true" tabindex="-1"></a>  <span class="kw">case</span> readWord8 fptr s0 <span class="kw">of</span> (<span class="op">#</span> s1, n <span class="op">#</span>) <span class="ot">-&gt;</span></span>
<span id="cb18-3"><a href="#cb18-3" aria-hidden="true" tabindex="-1"></a>  <span class="kw">case</span> n <span class="kw">of</span> <span class="dt">W8</span><span class="op">#</span> n<span class="op">#</span> <span class="ot">-&gt;</span></span>
<span id="cb18-4"><a href="#cb18-4" aria-hidden="true" tabindex="-1"></a>    doSomething n<span class="op">#</span></span></code></pre></div>
<p>First, we inline <code>readWord8</code>, resulting in:</p>
<div class="sourceCode" id="cb19"><pre class="sourceCode haskell"><code class="sourceCode haskell"><span id="cb19-1"><a href="#cb19-1" aria-hidden="true" tabindex="-1"></a><span class="dt">IO</span> <span class="op">$</span> \s0 <span class="ot">-&gt;</span></span>
<span id="cb19-2"><a href="#cb19-2" aria-hidden="true" tabindex="-1"></a>  <span class="kw">case</span> (</span>
<span id="cb19-3"><a href="#cb19-3" aria-hidden="true" tabindex="-1"></a>    with<span class="op">#</span> fptr s0 (\s1 <span class="ot">-&gt;</span></span>
<span id="cb19-4"><a href="#cb19-4" aria-hidden="true" tabindex="-1"></a>      <span class="kw">case</span> peek (unsafeForeignPtrToPtr fptr&#39;) s1 <span class="kw">of</span> (<span class="op">#</span> s2, n<span class="op">#</span> <span class="op">#</span>) <span class="ot">-&gt;</span></span>
<span id="cb19-5"><a href="#cb19-5" aria-hidden="true" tabindex="-1"></a>        (<span class="op">#</span> s2, <span class="dt">W8</span><span class="op">#</span> n<span class="op">#</span> <span class="op">#</span>)</span>
<span id="cb19-6"><a href="#cb19-6" aria-hidden="true" tabindex="-1"></a>    )</span>
<span id="cb19-7"><a href="#cb19-7" aria-hidden="true" tabindex="-1"></a>  ) <span class="kw">of</span> (<span class="op">#</span> s3, n <span class="op">#</span>) <span class="ot">-&gt;</span></span>
<span id="cb19-8"><a href="#cb19-8" aria-hidden="true" tabindex="-1"></a>  <span class="kw">case</span> n <span class="kw">of</span> <span class="dt">W8</span><span class="op">#</span> n<span class="op">#</span> <span class="ot">-&gt;</span></span>
<span id="cb19-9"><a href="#cb19-9" aria-hidden="true" tabindex="-1"></a>    doSomething n<span class="op">#</span></span></code></pre></div>
<p>Now, by the SCP transform above, the outer <code>case</code> can be pushed inside of the
<code>with#</code>:</p>
<div class="sourceCode" id="cb20"><pre class="sourceCode haskell"><code class="sourceCode haskell"><span id="cb20-1"><a href="#cb20-1" aria-hidden="true" tabindex="-1"></a><span class="dt">IO</span> <span class="op">$</span> \s0 <span class="ot">-&gt;</span></span>
<span id="cb20-2"><a href="#cb20-2" aria-hidden="true" tabindex="-1"></a>  with<span class="op">#</span> fptr s0 (\s1 <span class="ot">-&gt;</span></span>
<span id="cb20-3"><a href="#cb20-3" aria-hidden="true" tabindex="-1"></a>    <span class="kw">case</span> (</span>
<span id="cb20-4"><a href="#cb20-4" aria-hidden="true" tabindex="-1"></a>      <span class="kw">case</span> peek (unsafeForeignPtrToPtr fptr&#39;) s1 <span class="kw">of</span> (<span class="op">#</span> s2, n<span class="op">#</span> <span class="op">#</span>) <span class="ot">-&gt;</span></span>
<span id="cb20-5"><a href="#cb20-5" aria-hidden="true" tabindex="-1"></a>        (<span class="op">#</span> s2, <span class="dt">W8</span><span class="op">#</span> n<span class="op">#</span> <span class="op">#</span>)</span>
<span id="cb20-6"><a href="#cb20-6" aria-hidden="true" tabindex="-1"></a>    ) <span class="kw">of</span> (<span class="op">#</span> s3, n <span class="op">#</span>) <span class="ot">-&gt;</span></span>
<span id="cb20-7"><a href="#cb20-7" aria-hidden="true" tabindex="-1"></a>    <span class="kw">case</span> n <span class="kw">of</span> <span class="dt">W8</span><span class="op">#</span> n<span class="op">#</span> <span class="ot">-&gt;</span></span>
<span id="cb20-8"><a href="#cb20-8" aria-hidden="true" tabindex="-1"></a>      doSomething n<span class="op">#</span></span>
<span id="cb20-9"><a href="#cb20-9" aria-hidden="true" tabindex="-1"></a>  )</span></code></pre></div>
<p>Finally, case-of-known constructor can be applied twice, eliminating the <code>W8#</code>
allocation:</p>
<div class="sourceCode" id="cb21"><pre class="sourceCode haskell"><code class="sourceCode haskell"><span id="cb21-1"><a href="#cb21-1" aria-hidden="true" tabindex="-1"></a><span class="dt">IO</span> <span class="op">$</span> \s0 <span class="ot">-&gt;</span></span>
<span id="cb21-2"><a href="#cb21-2" aria-hidden="true" tabindex="-1"></a>  with<span class="op">#</span> fptr s0 (\s1 <span class="ot">-&gt;</span></span>
<span id="cb21-3"><a href="#cb21-3" aria-hidden="true" tabindex="-1"></a>    <span class="kw">case</span> peek (unsafeForeignPtrToPtr fptr&#39;) s1 <span class="kw">of</span> (<span class="op">#</span> s2, n<span class="op">#</span> <span class="op">#</span>) <span class="ot">-&gt;</span></span>
<span id="cb21-4"><a href="#cb21-4" aria-hidden="true" tabindex="-1"></a>      doSomething n<span class="op">#</span></span>
<span id="cb21-5"><a href="#cb21-5" aria-hidden="true" tabindex="-1"></a>  )</span></code></pre></div>
<p>Hooray!</p>
<h3 id="the-trouble-with-scp">The trouble with SCP</h3>
<p>At first glance, this SCP transform looks like a promising way to eliminate a
major source of overhead imposed by <code>with#</code>. Unfortunately, testing quickly
revealed that matters are not so simple. For instance, consider a loop which
uses <code>readWord8</code> to sum the elements of an array:</p>
<div class="sourceCode" id="cb22"><pre class="sourceCode haskell"><code class="sourceCode haskell"><span id="cb22-1"><a href="#cb22-1" aria-hidden="true" tabindex="-1"></a><span class="ot">sumArray ::</span> <span class="dt">ForeignPtr</span> <span class="dt">Word8</span>    <span class="co">-- ^ an array of Word8s</span></span>
<span id="cb22-2"><a href="#cb22-2" aria-hidden="true" tabindex="-1"></a>         <span class="ot">-&gt;</span> <span class="dt">Int</span>                 <span class="co">-- ^ array length</span></span>
<span id="cb22-3"><a href="#cb22-3" aria-hidden="true" tabindex="-1"></a>         <span class="ot">-&gt;</span> <span class="dt">IO</span> <span class="dt">Word8</span></span>
<span id="cb22-4"><a href="#cb22-4" aria-hidden="true" tabindex="-1"></a>sumArray fptr n <span class="ot">=</span> <span class="dt">IO</span> (go <span class="dv">0</span><span class="op">#</span> n)</span>
<span id="cb22-5"><a href="#cb22-5" aria-hidden="true" tabindex="-1"></a>  <span class="kw">where</span></span>
<span id="cb22-6"><a href="#cb22-6" aria-hidden="true" tabindex="-1"></a><span class="ot">    go ::</span> <span class="dt">Word8</span><span class="op">#</span> <span class="ot">-&gt;</span> <span class="dt">Int</span> <span class="ot">-&gt;</span> <span class="dt">State</span><span class="op">#</span> <span class="dt">RealWorld</span> <span class="ot">-&gt;</span> (<span class="op">#</span> <span class="dt">State</span><span class="op">#</span> <span class="dt">RealWorld</span>, <span class="dt">Word8</span> <span class="op">#</span>)</span>
<span id="cb22-7"><a href="#cb22-7" aria-hidden="true" tabindex="-1"></a>    go accum <span class="dv">0</span> s0 <span class="ot">=</span> (<span class="op">#</span> s0, <span class="dt">W8</span><span class="op">#</span> accum <span class="op">#</span>)</span>
<span id="cb22-8"><a href="#cb22-8" aria-hidden="true" tabindex="-1"></a>    go accum i s0 <span class="ot">=</span></span>
<span id="cb22-9"><a href="#cb22-9" aria-hidden="true" tabindex="-1"></a>      <span class="kw">case</span> readWord8 (fptr <span class="ot">`plusForeignPtr`</span> i) s0 <span class="kw">of</span> (<span class="op">#</span> s1, n <span class="op">#</span>) <span class="ot">-&gt;</span></span>
<span id="cb22-10"><a href="#cb22-10" aria-hidden="true" tabindex="-1"></a>      <span class="kw">case</span> n <span class="kw">of</span> <span class="dt">W8</span><span class="op">#</span> n<span class="op">#</span> <span class="ot">-&gt;</span></span>
<span id="cb22-11"><a href="#cb22-11" aria-hidden="true" tabindex="-1"></a>        go (accum <span class="op">+#</span> n<span class="op">#</span>) (i<span class="op">-</span><span class="dv">1</span>) s1</span></code></pre></div>
<p>As written, this program will run in constant space (modulo short-lived garbage
<code>W8#</code> constructors). However, consider what happens if we inline <code>readWord8#</code>,
apply the SCP transform, and simplify in the second equation of <code>go</code>:</p>
<div class="sourceCode" id="cb23"><pre class="sourceCode haskell"><code class="sourceCode haskell"><span id="cb23-1"><a href="#cb23-1" aria-hidden="true" tabindex="-1"></a>    go accum i s0 <span class="ot">=</span></span>
<span id="cb23-2"><a href="#cb23-2" aria-hidden="true" tabindex="-1"></a>      with<span class="op">#</span> (fptr <span class="ot">`plusForeignPtr`</span> i) s0 (\s1 <span class="ot">-&gt;</span></span>
<span id="cb23-3"><a href="#cb23-3" aria-hidden="true" tabindex="-1"></a>        <span class="kw">case</span> peek (unsafeForeignPtrToPtr (fptr <span class="ot">`plusForeignPtr`</span> i)) s1 <span class="kw">of</span> (<span class="op">#</span> s2, n<span class="op">#</span> <span class="op">#</span>) <span class="ot">-&gt;</span></span>
<span id="cb23-4"><a href="#cb23-4" aria-hidden="true" tabindex="-1"></a>          go (accum <span class="op">+#</span> n<span class="op">#</span>) (i<span class="op">-</span><span class="dv">1</span>) s1</span></code></pre></div>
<p>While we have successfully eliminated the garbage <code>W8#</code> allocations,
the recursive <code>go</code> call (previously a tail-call) is now beneath a <code>with#</code>
application. Since most implementations of <code>with#</code> will have the operational
effect of pushing a frame to the evaluation stack, this transforms the
otherwise constant-space <code>sumArray</code> into an O(n) program. This is clearly not
acceptable.</p>
<p>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.</p>
<p>While we found no way to make SCP work, the modifications we made to <code>with#</code>’s
type at the beginning of this section are desireable regardless. That is:</p>
<ul>
<li><code>with#</code> must be polymorphic in the <code>RuntimeRep</code> of its result lest the user is
unable to use it to compute unboxed results.</li>
<li>the use of <code>State#</code> tokens is a good hint to the user that they must take
care to control execution ordering to safely use the operation</li>
</ul>
<p>Consequently, we will adopt the following type for <code>with#</code>:</p>
<div class="sourceCode" id="cb24"><pre class="sourceCode haskell"><code class="sourceCode haskell"><span id="cb24-1"><a href="#cb24-1" aria-hidden="true" tabindex="-1"></a>with<span class="op">#</span><span class="ot"> ::</span> <span class="kw">forall</span> a (<span class="ot">r ::</span> <span class="dt">RuntimeRep</span>) (<span class="ot">b ::</span> <span class="dt">TYPE</span> r)<span class="op">.</span></span>
<span id="cb24-2"><a href="#cb24-2" aria-hidden="true" tabindex="-1"></a>        a <span class="ot">-&gt;</span> <span class="dt">State</span><span class="op">#</span> s <span class="ot">-&gt;</span> (<span class="dt">State</span><span class="op">#</span> s <span class="ot">-&gt;</span> b) <span class="ot">-&gt;</span> b</span></code></pre></div>
<h2 id="generating-code-for-with">Generating code for <code>with#</code></h2>
<p>Above we considered some of the design decisions surrounding the user-facing
interface of <code>with#</code>. However, the interface is only half of the story: the
compiler must also know how to generate code for <code>with#</code>.</p>
<p>Thankfully, doing so is (currently) reasonably straightforward as GHC’s DCE
optimisation strictly occurs on Core. For this reason, we can safely desugar
<code>with#</code> into <code>touch#</code> by inlining after the Core-to-Core optimisation pipeline
has run (namely in the <code>CorePrep</code> stage of compilation). Specifically, an
application:</p>
<div class="sourceCode" id="cb25"><pre class="sourceCode haskell"><code class="sourceCode haskell"><span id="cb25-1"><a href="#cb25-1" aria-hidden="true" tabindex="-1"></a><span class="co">-- Recall that</span></span>
<span id="cb25-2"><a href="#cb25-2" aria-hidden="true" tabindex="-1"></a><span class="co">--   with# :: forall a (r :: RuntimeRep) (b :: TYPE r).</span></span>
<span id="cb25-3"><a href="#cb25-3" aria-hidden="true" tabindex="-1"></a><span class="co">--            a -&gt; State# s -&gt; (State# s -&gt; b) -&gt; b</span></span>
<span id="cb25-4"><a href="#cb25-4" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb25-5"><a href="#cb25-5" aria-hidden="true" tabindex="-1"></a>with<span class="op">#</span> x s0 (\s0 <span class="ot">-&gt;</span> k)</span></code></pre></div>
<p>can be rewritten to</p>
<div class="sourceCode" id="cb26"><pre class="sourceCode haskell"><code class="sourceCode haskell"><span id="cb26-1"><a href="#cb26-1" aria-hidden="true" tabindex="-1"></a><span class="kw">case</span> k s0 <span class="kw">of</span> r <span class="ot">-&gt;</span></span>
<span id="cb26-2"><a href="#cb26-2" aria-hidden="true" tabindex="-1"></a><span class="kw">case</span> touch<span class="op">#</span> x s0 <span class="kw">of</span> s1 <span class="ot">-&gt;</span></span>
<span id="cb26-3"><a href="#cb26-3" aria-hidden="true" tabindex="-1"></a>  r</span></code></pre></div>
<p>Admittedly, this rewrite is a bit suspicious as we there is nothing
ensuring the ordering between the <code>case k s</code> and the <code>touch#</code> (since they are
both applied to the <code>State#</code> token <code>s</code>). However, this is a pragmatic choice:
GHC’s STG pipeline currently performs no optimisation which could reorder
these expressions and forcing <code>with#</code> to return a <code>(# State# s, b #)</code> would
preclude its use in some pure contexts.</p>
<p>On the bright side, the fact that we can reuse <code>touch#</code> means that we can
provide <code>with#</code> with minimal overhead and no further changes to the backend.</p>
<h2 id="keepAlive"><code>keepAlive#</code> in GHC 9.0</h2>
<p>While we originally set out to supercede (and ultimately remove) <code>touch#</code>, the
issues described above (and others described in the <a href="https://gitlab.haskell.org/ghc/ghc/-/wikis/proposal/with-combinator">Wiki</a>) made it clear
that this plan was not feasible: what <code>touch#</code> 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 <code>with#</code>.</p>
<p>Consequently, in GHC 9.0 we opted for a pragmatic solution: continue to allow
use of <code>touch#</code> where necessary but prefer to use the safer <code>with</code>-style where
possible. GHC 9.0.1 exposes this operation as <code>keepAlive#</code> (the kinds in the
type below are slightly different than those present in 9.0, referring to
<code>BoxedRep</code> <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0203-pointer-rep.rst">introduced</a> in 9.2 for added precision):</p>
<div class="sourceCode" id="cb27"><pre class="sourceCode haskell"><code class="sourceCode haskell"><span id="cb27-1"><a href="#cb27-1" aria-hidden="true" tabindex="-1"></a>keepAlive<span class="op">#</span><span class="ot"> ::</span> <span class="kw">forall</span> (<span class="ot">lev ::</span> <span class="dt">Levity</span>) (<span class="ot">a ::</span> <span class="dt">TYPE</span> (<span class="dt">BoxedRep</span> lev))</span>
<span id="cb27-2"><a href="#cb27-2" aria-hidden="true" tabindex="-1"></a>                     (<span class="ot">rep ::</span> <span class="dt">RuntimeRep</span>) (<span class="ot">b ::</span> <span class="dt">TYPE</span> rep) s<span class="op">.</span></span>
<span id="cb27-3"><a href="#cb27-3" aria-hidden="true" tabindex="-1"></a>              a</span>
<span id="cb27-4"><a href="#cb27-4" aria-hidden="true" tabindex="-1"></a>           <span class="ot">-&gt;</span> <span class="dt">State</span><span class="op">#</span> s</span>
<span id="cb27-5"><a href="#cb27-5" aria-hidden="true" tabindex="-1"></a>           <span class="ot">-&gt;</span> (<span class="dt">State</span><span class="op">#</span> s <span class="ot">-&gt;</span> b)</span>
<span id="cb27-6"><a href="#cb27-6" aria-hidden="true" tabindex="-1"></a>           <span class="ot">-&gt;</span> b</span></code></pre></div>
<p>What implications does this have on user code? For most users, none: nearly all
uses of <code>touch#</code> are buried in low-level libraries which have already been
adapted by the GHC maintainers.</p>
<p>If you <em>do</em> for some reason use <code>touch#</code>, 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 <code>touch#</code> is necessary
which would not be equally-well served by, e.g., <code>ForeignPtr</code> or a higher-level
scoped allocation primitive.</p>
<p>If you have determined that the low-level primitive is indeed unavoidable then
the next question is whether <code>touch#</code> should be replaced with <code>keepAlive#</code>. In the
general case this unfortunately comes down to a safety/performance tradeoff.
Specifically, let us consider the example of the <code>withForeignPtr</code> operation
exposed by <code>base</code>. When written in terms of <code>touch</code> this operation is defined
as:</p>
<div class="sourceCode" id="cb28"><pre class="sourceCode haskell"><code class="sourceCode haskell"><span id="cb28-1"><a href="#cb28-1" aria-hidden="true" tabindex="-1"></a><span class="ot">withForeignPtr ::</span> <span class="dt">ForeignPtr</span> a <span class="ot">-&gt;</span> (<span class="dt">Ptr</span> a <span class="ot">-&gt;</span> <span class="dt">IO</span> b) <span class="ot">-&gt;</span> <span class="dt">IO</span> b</span>
<span id="cb28-2"><a href="#cb28-2" aria-hidden="true" tabindex="-1"></a>withForeignPtr fptr k <span class="ot">=</span> <span class="kw">do</span></span>
<span id="cb28-3"><a href="#cb28-3" aria-hidden="true" tabindex="-1"></a>    k (unsafeForeignPtrToPtr fptr)</span>
<span id="cb28-4"><a href="#cb28-4" aria-hidden="true" tabindex="-1"></a>    touch fptr</span></code></pre></div>
<p>While this can produce very efficient code, it is also deeply unsafe as the
user may provide a divergent continuation (e.g. <code>withForeignPtr fptr (forever ...)</code>). For the reasons described above, this can result in the dropping of the
<code>touch#</code>, resulting in unsoundness.</p>
<p>To avoid this, we should rather express <code>withForeignPtr</code> in terms of
<code>keepAlive#</code>:</p>
<div class="sourceCode" id="cb29"><pre class="sourceCode haskell"><code class="sourceCode haskell"><span id="cb29-1"><a href="#cb29-1" aria-hidden="true" tabindex="-1"></a><span class="ot">withForeignPtr ::</span> <span class="dt">ForeignPtr</span> a <span class="ot">-&gt;</span> (<span class="dt">Ptr</span> a <span class="ot">-&gt;</span> <span class="dt">IO</span> b) <span class="ot">-&gt;</span> <span class="dt">IO</span> b</span>
<span id="cb29-2"><a href="#cb29-2" aria-hidden="true" tabindex="-1"></a>withForeignPtr fptr k <span class="ot">=</span> <span class="dt">IO</span> <span class="op">$</span> \s0 <span class="ot">-&gt;</span> </span>
<span id="cb29-3"><a href="#cb29-3" aria-hidden="true" tabindex="-1"></a>    keepAlive<span class="op">#</span> fptr s0 (unIO <span class="op">$</span> k (unsafeForeignPtrToPtr fptr))</span></code></pre></div>
<p>This avoids unsoundness at the expense of needing to allocate the <code>b</code> result of
the continuation. This is the implementation provided with <code>base-4.15</code>.</p>
<h3 id="introducing-unsafewithforeignptr">Introducing <code>unsafeWithForeignPtr</code></h3>
<p>While the introduction of <code>keepAlive#</code> affects relatively little user-code, the
added cost of <code>withForeignPtr</code> has the potential to be more impactful. In
particular, it is not uncommon to find code such as:</p>
<div class="sourceCode" id="cb30"><pre class="sourceCode haskell"><code class="sourceCode haskell"><span id="cb30-1"><a href="#cb30-1" aria-hidden="true" tabindex="-1"></a>withForeignPtr fptr (peek <span class="op">@</span><span class="dt">Word8</span>)</span></code></pre></div>
<p>in tight inner-loops. Adding an allocation in such a context would be
catestrophic for performance and consequently <code>GHC.ForeignPtr</code> exports the old,
<code>touch#</code>-based implementation of <code>withForeignPtr</code> as <code>unsafeWithForeignPtr</code>.
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.</p>
<h3 id="guidance-for-earlier-ghc-releases">Guidance for earlier GHC releases</h3>
<p>As noted, use of <code>touch#</code> in previous GHC versions is a bit perilous unless due
care is taken. Let’s consider an example:</p>
<div class="sourceCode" id="cb31"><pre class="sourceCode haskell"><code class="sourceCode haskell"><span id="cb31-1"><a href="#cb31-1" aria-hidden="true" tabindex="-1"></a><span class="ot">foo ::</span> <span class="dt">ByteArray</span> <span class="ot">-&gt;</span> <span class="dt">IO</span> ()</span>
<span id="cb31-2"><a href="#cb31-2" aria-hidden="true" tabindex="-1"></a>foo x <span class="ot">=</span> <span class="kw">do</span></span>
<span id="cb31-3"><a href="#cb31-3" aria-hidden="true" tabindex="-1"></a>    doSomething x                        <span class="co">-- (a)</span></span>
<span id="cb31-4"><a href="#cb31-4" aria-hidden="true" tabindex="-1"></a>    <span class="op">...</span></span>
<span id="cb31-5"><a href="#cb31-5" aria-hidden="true" tabindex="-1"></a>    doForeignCall (byteArrayContents x)  <span class="co">-- (b)</span></span>
<span id="cb31-6"><a href="#cb31-6" aria-hidden="true" tabindex="-1"></a>    <span class="op">...</span></span>
<span id="cb31-7"><a href="#cb31-7" aria-hidden="true" tabindex="-1"></a>    touch x                              <span class="co">-- (c)</span></span></code></pre></div>
<p>For this program to be safe, the user must guarantee that no subexpression in
the body of <code>foo</code> between (a) (the point that <code>x</code> potentially becomes
unreachable) and (c) (the <code>touch</code>, which we must ensure DCE does not drop)
is provably divergent. In the case that all of the <code>...</code>s are statically known
it is possible to determine this by inspection.</p>
<p>However, things are harder if the function takes a user-provided continuation a
la <code>withForeignPtr</code>:</p>
<div class="sourceCode" id="cb32"><pre class="sourceCode haskell"><code class="sourceCode haskell"><span id="cb32-1"><a href="#cb32-1" aria-hidden="true" tabindex="-1"></a><span class="ot">withForeignPtr ::</span> <span class="dt">ForeignPtr</span> a <span class="ot">-&gt;</span> (<span class="dt">Ptr</span> a <span class="ot">-&gt;</span> <span class="dt">IO</span> b) <span class="ot">-&gt;</span> <span class="dt">IO</span> b</span>
<span id="cb32-2"><a href="#cb32-2" aria-hidden="true" tabindex="-1"></a>withForeignPtr fptr k <span class="ot">=</span> <span class="kw">do</span></span>
<span id="cb32-3"><a href="#cb32-3" aria-hidden="true" tabindex="-1"></a>    k (unsafeForeignPtrToPtr fptr)</span>
<span id="cb32-4"><a href="#cb32-4" aria-hidden="true" tabindex="-1"></a>    touch fptr</span></code></pre></div>
<p>In this case the only reliable way to avoid unsoundness is to place a <code>NOINLINE</code>
on <code>withForeignPtr</code>. This deprives the simplifier of knowledge of <code>k</code>, ensuring
that it cannot conclude that <code>touch</code> is unreachable.</p>
<h2 id="conclusion">Conclusion</h2>
<p>Here we have described a bit of the story that lead to <code>keepAlive#</code>. 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.</p>
<p>If you have any questions regarding <code>touch#</code> and <code>keepAlive#</code>, do be in touch
on the <a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs"><code>ghc-devs</code> mailing list</a>.</p>
<section id="footnotes" class="footnotes footnotes-end-of-document" role="doc-endnotes">
<hr />
<ol>
<li id="fn1"><p>To avoid cluttering the code too much, we are playing a bit
fast-and-loose with the <code>IO</code> newtype here. For instance, we treat <code>peek</code> as a
function of type <code>State# RealWorld -&gt; (# State# RealWorld, a #)</code> (i.e. the
representation of <code>IO a)</code>) instead of <code>IO a</code>. We will continue this
pragmatic abuse of notation below.<a href="#fnref1" class="footnote-back" role="doc-backlink">↩︎</a></p></li>
</ol>
</section>
]]></description>
    <pubDate>Tue, 08 Jun 2021 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20210607-the-keepAlive-story.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC 8.10.5 is now available</title>
    <link>http://haskell.org/ghc/blog/20210605-ghc-8.10.5-released.html</link>
    <description><![CDATA[<h1>GHC 8.10.5 is now available</h1>
<h4 class="text-muted">Zubin Duggal - 2021-06-05</h4>

<p>The GHC team is very pleased to announce the availability of GHC 8.10.5.
Source and binary distributions are available at the <a href="https://downloads.haskell.org/ghc/8.10.5/">usual
place</a>.</p>
<p>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:</p>
<ul>
<li><p>First-class support for Apple M1 hardware using GHC’s LLVM ARM backend</p></li>
<li><p>Fix a bug resulting in segmentation faults where code may be unloaded
prematurely when using the parallel garbage collector (<a href="https://gitlab.haskell.org/ghc/ghc/issues/19417">#19417</a>) along
with other bugs in the GC and linker (<a href="https://gitlab.haskell.org/ghc/ghc/issues/19147">#19147</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/19287">#19287</a>)</p></li>
<li><p>Improve code layout fixing certain performance regressions (<a href="https://gitlab.haskell.org/ghc/ghc/issues/18053">#18053</a>)
and other code generation bug fixes (<a href="https://gitlab.haskell.org/ghc/ghc/issues/19645">#19645</a>)</p></li>
<li><p>Bug fixes for signal handling when using the pthread itimer implementation.</p></li>
<li><p>Improvements to the specializer and simplifier reducing code size and
and memory usage (<a href="https://gitlab.haskell.org/ghc/ghc/issues/17151">#17151</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/18923">#18923</a>,<a href="https://gitlab.haskell.org/ghc/ghc/issues/18140">#18140</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/10421">#10421</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/18282">#18282</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/13253">#13253</a>).</p></li>
<li><p>Fix a bug where typechecker plugins could be run with an inconsistent
typechecker environment (<a href="https://gitlab.haskell.org/ghc/ghc/issues/19191">#19191</a>).</p></li>
<li><p>Fix a simplifier bug which lead to an exponential blow up and excessive
memory usage in certain cases</p></li>
</ul>
<p>A complete list of bug fixes and improvements can be found in the release notes: <a href="https://downloads.haskell.org/ghc/8.10.5/docs/html/users_guide/8.10.5-notes.html">release
notes</a>,</p>
<p>As always, feel free to report any issues you encounter via
<a href="https://gitlab.haskell.org/ghc/ghc/-/issues/new">gitlab.haskell.org</a>.</p>
]]></description>
    <pubDate>Sat, 05 Jun 2021 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20210605-ghc-8.10.5-released.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC 9.2.1-alpha2 now available</title>
    <link>http://haskell.org/ghc/blog/20210422-ghc-9.2.1-alpha2-relased.html</link>
    <description><![CDATA[<h1>GHC 9.2.1-alpha2 now available</h1>
<h4 class="text-muted">Ben Gamari - 2021-04-22</h4>

<p>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
<a href="https://downloads.haskell.org/ghc/9.2.1-alpha2">downloads.haskell.org</a>.</p>
<p>GHC 9.2 will bring a number of exciting features including:</p>
<ul>
<li><p>Many changes in the area of records, including the new
<code>RecordDotSyntax</code> and <code>NoFieldSelectors</code> language extensions, as well
as Support for <code>DuplicateRecordFields</code> with <code>PatternSynonyms</code>.</p></li>
<li><p>Introduction of the new <code>GHC2021</code> language extension set, giving
users convenient access to a larger set of language extensions which
have been long considered stable.</p></li>
<li><p>Merge of <code>ghc-exactprint</code> into the GHC tree, providing infrastructure
for source-to-source program rewriting out-of-the-box.</p></li>
<li><p>Introduction of a <code>BoxedRep</code> <code>RuntimeRep</code>, allowing for polymorphism
over levity of boxed objects (<a href="https://gitlab.haskell.org/ghc/ghc/issues/17526">#17526</a>)</p></li>
<li><p>Implementation of the <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0265-unlifted-datatypes.rst"><code>UnliftedDataTypes</code> extension</a>, allowing
users to define types which do not admit lazy evaluation</p></li>
<li><p>The new <a href="https://well-typed.com/blog/2021/01/first-look-at-hi-profiling-mode/">-hi profiling</a> mechanism which provides significantly
improved insight into thunk leaks.</p></li>
<li><p>Support for the <a href="http://ghc.gitlab.haskell.org/ghc-debug/"><code>ghc-debug</code></a> out-of-process heap inspection
library</p></li>
<li><p>Support for profiling of pinned objects with the cost-centre profiler
(<a href="https://gitlab.haskell.org/ghc/ghc/issues/7275">#7275</a>)</p></li>
<li><p>Introduction of Haddock documentation support in TemplateHaskell (<a href="https://gitlab.haskell.org/ghc/ghc/issues/5467">#5467</a>)</p></li>
<li><p>Proper support for impredicative types in the form of Quick-Look
impredicativity.</p></li>
<li><p>A native code generator backend for AArch64.</p></li>
</ul>
<p>This pre-release brings nearly 50 fixes relative to the first alpha,
although the long-awaited ARM NCG backend hasn’t quite landed yet.</p>
<p>As always, do give this a try and open a <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/new">ticket</a> if you see anything amiss.</p>
<p>Happy testing!</p>
]]></description>
    <pubDate>Thu, 22 Apr 2021 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20210422-ghc-9.2.1-alpha2-relased.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC 9.2.1-alpha1 now available</title>
    <link>http://haskell.org/ghc/blog/20210401-ghc-9.2.1-alpha1-released.html</link>
    <description><![CDATA[<h1>GHC 9.2.1-alpha1 now available</h1>
<h4 class="text-muted">Ben Gamari - 2021-04-01</h4>

<p>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
<a href="https://downloads.haskell.org/ghc/9.2.1-alpha1">downloads.haskell.org</a>.</p>
<p>GHC 9.2 will bring a number of exciting features including:</p>
<ul>
<li><p>Many changes in the area of records, including the new
<code>RecordDotSyntax</code> and <code>NoFieldSelectors</code> language extensions, as well
as Support for <code>DuplicateRecordFields</code> with <code>PatternSynonyms</code>.</p></li>
<li><p>Introduction of the new <code>GHC2021</code> language extension set, giving
users convenient access to a larger set of language extensions which
have been long considered stable.</p></li>
<li><p>Merge of <code>ghc-exactprint</code> into the GHC tree, providing infrastructure
for source-to-source program rewriting out-of-the-box.</p></li>
<li><p>Introduction of a <code>BoxedRep</code> <code>RuntimeRep</code>, allowing for polymorphism
over levity of boxed objects (<a href="https://gitlab.haskell.org/ghc/ghc/issues/17526">#17526</a>)</p></li>
<li><p>Implementation of the <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0265-unlifted-datatypes.rst"><code>UnliftedDataTypes</code> extension</a>, allowing
users to define types which do not admit lazy evaluation</p></li>
<li><p>The new <a href="https://well-typed.com/blog/2021/01/first-look-at-hi-profiling-mode/">-hi profiling</a> mechanism which provides significantly
improved insight into thunk leaks.</p></li>
<li><p>Support for the <a href="http://ghc.gitlab.haskell.org/ghc-debug/"><code>ghc-debug</code></a> out-of-process heap inspection
library</p></li>
<li><p>Support for profiling of pinned objects with the cost-centre profiler
(<a href="https://gitlab.haskell.org/ghc/ghc/issues/7275">#7275</a>)</p></li>
<li><p>Introduction of Haddock documentation support in TemplateHaskell (<a href="https://gitlab.haskell.org/ghc/ghc/issues/5467">#5467</a>)</p></li>
</ul>
<p>In addition, the final 9.2.1 release will bring a new native code
generator for ARM, providing fast, first-class for Haskell on <a href="https://www.haskell.org/ghc/blog/20210309-apple-m1-story.html">Apple
ARM hardware</a>, although this functionality is not yet
present in this alpha.</p>
<p>As always, do give this a try and open a <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/new">ticket</a> if you see anything amiss.</p>
<p>Happy testing!</p>
]]></description>
    <pubDate>Thu, 01 Apr 2021 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20210401-ghc-9.2.1-alpha1-released.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>Status update: GHC on Apple M1 hardware</title>
    <link>http://haskell.org/ghc/blog/20210309-apple-m1-story.html</link>
    <description><![CDATA[<h1>Status update: GHC on Apple M1 hardware</h1>
<h4 class="text-muted">bgamari - 2021-03-09</h4>

<p>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.</p>
<p>To run natively on Apple M1 hardware running macOS, GHC needs three
things:</p>
<ol type="1">
<li>the ability to generate code in the ARM instruction set</li>
<li>support for Darwin’s ARM application binary interface (ABI)</li>
<li>various build system changes to accomodate the new platform</li>
</ol>
<p>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).</p>
<p>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.</p>
<h2 id="the-memory-ordering-problem">The memory ordering problem</h2>
<p>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.</p>
<p>Consequently, until recently GHC’s runtime relied on a mix of <code>volatile</code>
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.</p>
<p>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
<a href="https://research.google.com/pubs/archive/35604.pdf">ThreadSanitizer</a> 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.</p>
<h2 id="the-abi-problem">The ABI problem</h2>
<p>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. <code>Word8</code>). The problem arises from the
definition of sub-word size types in <code>base</code>. For instance, <code>Word8</code> is defined
as</p>
<div class="sourceCode" id="cb1"><pre class="sourceCode haskell"><code class="sourceCode haskell"><span id="cb1-1"><a href="#cb1-1" aria-hidden="true" tabindex="-1"></a><span class="kw">data</span> <span class="dt">Word8</span> <span class="ot">=</span> <span class="dt">W8</span><span class="op">#</span> <span class="dt">Word</span><span class="op">#</span></span></code></pre></div>
<p>This means that, from the perspective of the compiler, <code>Word8</code> 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 <a href="https://developer.apple.com/documentation/xcode/writing_arm64_code_for_apple_platforms">calling convention</a> which is sensitive to argument width.
This means that foreign calls like,</p>
<div class="sourceCode" id="cb2"><pre class="sourceCode haskell"><code class="sourceCode haskell"><span id="cb2-1"><a href="#cb2-1" aria-hidden="true" tabindex="-1"></a>foreign <span class="kw">import</span> ccall &quot;f&quot; f :: <span class="dt">Word8</span> -&gt; <span class="dt">IO</span> ()</span></code></pre></div>
<p>are treated incorrectly under this scheme on ARM/Darwin.</p>
<h2 id="the-long-term-plan">The long-term plan</h2>
<p>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
<a href="https://github.com/ghc-proposals/ghc-proposals/pull/74">GHC Proposal 74</a>).
However, there is still a fair amount of work that remains. First, we must
rework the lifted types defined by <code>base</code> to take advantage of these
sub-word-size types:</p>
<div class="sourceCode" id="cb3"><pre class="sourceCode haskell"><code class="sourceCode haskell"><span id="cb3-1"><a href="#cb3-1" aria-hidden="true" tabindex="-1"></a><span class="co">-- today we have:</span></span>
<span id="cb3-2"><a href="#cb3-2" aria-hidden="true" tabindex="-1"></a><span class="kw">data</span> <span class="dt">Word8</span> <span class="ot">=</span> <span class="dt">W8</span><span class="op">#</span> <span class="dt">Word</span><span class="op">#</span></span>
<span id="cb3-3"><a href="#cb3-3" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb3-4"><a href="#cb3-4" aria-hidden="true" tabindex="-1"></a><span class="co">-- in the glorious future we will have:</span></span>
<span id="cb3-5"><a href="#cb3-5" aria-hidden="true" tabindex="-1"></a><span class="kw">data</span> <span class="dt">Word8</span> <span class="ot">=</span> <span class="dt">W8</span><span class="op">#</span> <span class="dt">Word8</span><span class="op">#</span></span></code></pre></div>
<p>However, this change in isolation ends breaking quite a bit of code since many
of GHC’s primops <em>primops</em> are still defined in terms of <code>Word#</code>. For instance,
in GHC 9.0 the primop for reading a <code>Word8</code> from a <code>ByteArray</code> has the type:</p>
<div class="sourceCode" id="cb4"><pre class="sourceCode haskell"><code class="sourceCode haskell"><span id="cb4-1"><a href="#cb4-1" aria-hidden="true" tabindex="-1"></a>indexWord8Array<span class="op">#</span><span class="ot"> ::</span> <span class="dt">ByteArray</span><span class="op">#</span> <span class="ot">-&gt;</span> <span class="dt">Int</span><span class="op">#</span> <span class="ot">-&gt;</span> <span class="dt">Word</span><span class="op">#</span></span></code></pre></div>
<p>Consequently, a common idiom like <code>W8# (indexWord8Array# byteArray n)</code>
will break if we were to merely make above change to <code>Word8</code>. It turns out that we
can mitigate most of this by changing the primop definitions as well. That is,</p>
<div class="sourceCode" id="cb5"><pre class="sourceCode haskell"><code class="sourceCode haskell"><span id="cb5-1"><a href="#cb5-1" aria-hidden="true" tabindex="-1"></a><span class="co">-- today:</span></span>
<span id="cb5-2"><a href="#cb5-2" aria-hidden="true" tabindex="-1"></a>indexWord8Array<span class="op">#</span><span class="ot"> ::</span> <span class="dt">ByteArray</span><span class="op">#</span> <span class="ot">-&gt;</span> <span class="dt">Int</span><span class="op">#</span> <span class="ot">-&gt;</span> <span class="dt">Word</span><span class="op">#</span></span>
<span id="cb5-3"><a href="#cb5-3" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb5-4"><a href="#cb5-4" aria-hidden="true" tabindex="-1"></a><span class="co">-- the glorious future:</span></span>
<span id="cb5-5"><a href="#cb5-5" aria-hidden="true" tabindex="-1"></a>indexWord8Array<span class="op">#</span><span class="ot"> ::</span> <span class="dt">ByteArray</span><span class="op">#</span> <span class="ot">-&gt;</span> <span class="dt">Int</span><span class="op">#</span> <span class="ot">-&gt;</span> <span class="dt">Word8</span><span class="op">#</span></span></code></pre></div>
<p>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 (<code>W8#</code> in this case). We just need the constructor
and primops to agree to preserve that level of compatibility.</p>
<h2 id="improving-consistency-of-word-sized-integer-types">Improving consistency of word-sized integer types</h2>
<p>Darwin/ARM’s size-sensitive ABI also provides considerable incentive to fix a
long-standing wart in our treatment of <code>Word32#</code> and <code>Word64</code>: <code>Word64#</code> (resp.
<code>Word32#</code>) are only available on 32-bit (resp. 64-bit) platforms (<a href="https://gitlab.haskell.org/ghc/ghc/issues/11953">#11953</a>).
This requires the user to awkwardly rely on CPP to select between <code>Word64#</code>
(resp. <code>Word32#</code>) and <code>Word#</code> for 64-bit (resp. 32-bit) wide integers,
depending upon the host platform.</p>
<p>Making all sized integer types always available on all architectures allows
considerable simplification of many bits of <code>base</code> 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 <code>Word#</code> GHC 8.10
provided the following family of primops:</p>
<div class="sourceCode" id="cb6"><pre class="sourceCode haskell"><code class="sourceCode haskell"><span id="cb6-1"><a href="#cb6-1" aria-hidden="true" tabindex="-1"></a>GHC.Exts.narrowWord8<span class="op">#</span><span class="ot">  ::</span> <span class="dt">GHC.Prim.Word</span><span class="op">#</span>    <span class="ot">-&gt;</span> <span class="dt">GHC.Prim.Word8</span><span class="op">#</span></span>
<span id="cb6-2"><a href="#cb6-2" aria-hidden="true" tabindex="-1"></a>GHC.Exts.extendWord8<span class="op">#</span><span class="ot">  ::</span> <span class="dt">GHC.Prim.Word8</span><span class="op">#</span>   <span class="ot">-&gt;</span> <span class="dt">GHC.Prim.Word</span><span class="op">#</span></span>
<span id="cb6-3"><a href="#cb6-3" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb6-4"><a href="#cb6-4" aria-hidden="true" tabindex="-1"></a>GHC.Exts.narrowWord16<span class="op">#</span><span class="ot"> ::</span> <span class="dt">GHC.Prim.Word</span><span class="op">#</span>    <span class="ot">-&gt;</span> <span class="dt">GHC.Prim.Word16</span><span class="op">#</span></span>
<span id="cb6-5"><a href="#cb6-5" aria-hidden="true" tabindex="-1"></a>GHC.Exts.extendWord16<span class="op">#</span><span class="ot"> ::</span> <span class="dt">GHC.Prim.Word16</span><span class="op">#</span>  <span class="ot">-&gt;</span> <span class="dt">GHC.Prim.Word</span><span class="op">#</span></span>
<span id="cb6-6"><a href="#cb6-6" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb6-7"><a href="#cb6-7" aria-hidden="true" tabindex="-1"></a>GHC.Exts.narrowInt8<span class="op">#</span><span class="ot">   ::</span> <span class="dt">GHC.Prim.Int</span><span class="op">#</span>     <span class="ot">-&gt;</span> <span class="dt">GHC.Prim.Int8</span><span class="op">#</span></span>
<span id="cb6-8"><a href="#cb6-8" aria-hidden="true" tabindex="-1"></a>GHC.Exts.extendInt8<span class="op">#</span><span class="ot">   ::</span> <span class="dt">GHC.Prim.Int8</span><span class="op">#</span>    <span class="ot">-&gt;</span> <span class="dt">GHC.Prim.Int</span><span class="op">#</span></span>
<span id="cb6-9"><a href="#cb6-9" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb6-10"><a href="#cb6-10" aria-hidden="true" tabindex="-1"></a>GHC.Exts.narrowInt16<span class="op">#</span><span class="ot">  ::</span> <span class="dt">GHC.Prim.Int</span><span class="op">#</span>     <span class="ot">-&gt;</span> <span class="dt">GHC.Prim.Int16</span><span class="op">#</span></span>
<span id="cb6-11"><a href="#cb6-11" aria-hidden="true" tabindex="-1"></a>GHC.Exts.extendInt16<span class="op">#</span><span class="ot">  ::</span> <span class="dt">GHC.Prim.Int16</span><span class="op">#</span>   <span class="ot">-&gt;</span> <span class="dt">GHC.Prim.Int</span><span class="op">#</span></span></code></pre></div>
<p>However, if we were to add such operations for, e.g., <code>Word64#</code>
we would end up with:</p>
<div class="sourceCode" id="cb7"><pre class="sourceCode haskell"><code class="sourceCode haskell"><span id="cb7-1"><a href="#cb7-1" aria-hidden="true" tabindex="-1"></a>GHC.Exts.narrowWord64<span class="op">#</span><span class="ot">  ::</span> <span class="dt">GHC.Prim.Word</span><span class="op">#</span>   <span class="ot">-&gt;</span> <span class="dt">GHC.Prim.Word64</span><span class="op">#</span></span>
<span id="cb7-2"><a href="#cb7-2" aria-hidden="true" tabindex="-1"></a>GHC.Exts.extendWord64<span class="op">#</span><span class="ot">  ::</span> <span class="dt">GHC.Prim.Word64</span><span class="op">#</span> <span class="ot">-&gt;</span> <span class="dt">GHC.Prim.Word</span><span class="op">#</span></span></code></pre></div>
<p>Consider the case of <code>narrowWord64#</code> on a 32-bit platform (where <code>Word#</code> is 32-bits wide):
the operation’s semantics make its argument <em>wider</em>, yet its name suggests it
makes the value <em>narrower</em> (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
<code>narrow</code> and <code>extend</code> 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:</p>
<div class="sourceCode" id="cb8"><pre class="sourceCode haskell"><code class="sourceCode haskell"><span id="cb8-1"><a href="#cb8-1" aria-hidden="true" tabindex="-1"></a>GHC.Exts.wordToWord64<span class="op">#</span><span class="ot">  ::</span> <span class="dt">GHC.Prim.Word</span><span class="op">#</span>   <span class="ot">-&gt;</span> <span class="dt">GHC.Prim.Word64</span><span class="op">#</span></span>
<span id="cb8-2"><a href="#cb8-2" aria-hidden="true" tabindex="-1"></a>GHC.Exts.word64ToWord<span class="op">#</span><span class="ot">  ::</span> <span class="dt">GHC.Prim.Word64</span><span class="op">#</span> <span class="ot">-&gt;</span> <span class="dt">GHC.Prim.Word</span><span class="op">#</span></span>
<span id="cb8-3"><a href="#cb8-3" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb8-4"><a href="#cb8-4" aria-hidden="true" tabindex="-1"></a>GHC.Exts.wordToWord32<span class="op">#</span><span class="ot">  ::</span> <span class="dt">GHC.Prim.Word</span><span class="op">#</span>   <span class="ot">-&gt;</span> <span class="dt">GHC.Prim.Word32</span><span class="op">#</span></span>
<span id="cb8-5"><a href="#cb8-5" aria-hidden="true" tabindex="-1"></a>GHC.Exts.word32ToWord<span class="op">#</span><span class="ot">  ::</span> <span class="dt">GHC.Prim.Word32</span><span class="op">#</span> <span class="ot">-&gt;</span> <span class="dt">GHC.Prim.Word</span><span class="op">#</span></span>
<span id="cb8-6"><a href="#cb8-6" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb8-7"><a href="#cb8-7" aria-hidden="true" tabindex="-1"></a><span class="co">-- et cetera</span></span></code></pre></div>
<p>The above changes are documented in the
<a href="https://gitlab.haskell.org/ghc/ghc/-/wikis/Unboxed-Numerics">Wiki</a> 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 (<a href="https://gitlab.haskell.org/ghc/ghc/issues/17375">#17375</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/17377">#17377</a>).</p>
<h2 id="the-short-term-plan">The short-term plan</h2>
<p>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.</p>
<p>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.</p>
<h2 id="a-cherry-on-top-a-new-ncg-for-arm">A cherry on top: A new NCG for ARM</h2>
<p>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.</p>
<p>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.</p>
<h2 id="summary">Summary</h2>
<p>To summarize, over two years of work to improve the state of GHC on ARM will be
culminating in the coming months. Specifically:</p>
<ul>
<li><p>GHC 8.10.4 solidified ARM support by revamping the runtime’s treatment of
memory consistency.</p></li>
<li><p>GHC 8.10.5 will be out in the coming weeks with initial Darwin/ARM support</p></li>
<li><p>GHC 9.0.2 will be out a few weeks later, also with Darwin/ARM support</p></li>
<li><p>GHC 9.2.1 will be released in June 2021 sporting Darwin/ARM support,
revamped sized-integer types in <code>base</code>, and considerably faster compilation
thanks to Moritz’s ARM NCG backend.</p></li>
</ul>
<p>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.</p>
<p>Lastly, thanks to Davean Scies and <a href="https://simspace.com/">Simspace</a> for their
help and support in hosting a set of M1 CI runners.</p>
]]></description>
    <pubDate>Tue, 09 Mar 2021 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20210309-apple-m1-story.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC 8.10.4 is now available</title>
    <link>http://haskell.org/ghc/blog/20210204-ghc-8.10.4-released.html</link>
    <description><![CDATA[<h1>GHC 8.10.4 is now available</h1>
<h4 class="text-muted">bgamari - 2021-02-05</h4>

<p>The GHC team is very pleased to announce the availability of GHC 8.10.4.
Source and binary distributions are available at the <a href="https://downloads.haskell.org/ghc/8.10.4/">usual
place</a>.</p>
<p>This is a small bug-fix release, fixing two bugs present in 8.10.3:</p>
<ul>
<li><p>Fix a linker hang triggered by dynamic code loading on Windows
(<a href="https://gitlab.haskell.org/ghc/ghc/issues/19155">#19155</a>)</p></li>
<li><p>Fix a crash caused by inappropriate garbage of heap-allocated data reachable
from foreign exports (<a href="https://gitlab.haskell.org/ghc/ghc/issues/19149">#19149</a>)</p></li>
</ul>
<p>As always, feel free to report any issues you encounter via
<a href="https://gitlab.haskell.org/ghc/ghc/-/issues/new">gitlab.haskell.org</a>.</p>
]]></description>
    <pubDate>Fri, 05 Feb 2021 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20210204-ghc-8.10.4-released.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC 9.0.1 is now available</title>
    <link>http://haskell.org/ghc/blog/20210204-ghc-9.0.1-released.html</link>
    <description><![CDATA[<h1>GHC 9.0.1 is now available</h1>
<h4 class="text-muted">bgamari - 2021-02-04</h4>

<p>The GHC team is very pleased to announce the availability of GHC 9.0.1.
Source and binary distributions are available at the <a href="https://downloads.haskell.org/ghc/9.0.1/">usual
place</a>.</p>
<p>In addition to numerous bug fixes, GHC 9.0.1 brings a number of new
features:</p>
<ul>
<li><p>A first cut of the new <code>LinearTypes</code> <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0111-linear-types.rst">language extension</a>, allowing use
of linear function syntax and linear record fields.</p></li>
<li><p>A new bignum library, <code>ghc-bignum</code>, improving portability and allowing GHC
to be more easily used with integer libraries other than GMP.</p></li>
<li><p>Improvements in code generation, resulting in considerable
runtime performance improvements in some programs.</p></li>
<li><p>Improvements in pattern-match checking, allowing more precise
detection of redundant cases and reduced compilation time.</p></li>
<li><p>Implementation of the “simplified subsumption” <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0287-simplify-subsumption.rst">proposal</a>
simplifying the type system and paving the way for QuickLook
impredicativity in GHC 9.2.</p></li>
<li><p>Implementation of the <code>QualifiedDo</code> <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0216-qualified-do.rst">extension</a>, allowing more
convenient overloading of <code>do</code> syntax.</p></li>
<li><p>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.</p></li>
<li><p>Improvements in compilation time.</p></li>
</ul>
<p>And many more. See the <a href="https://downloads.haskell.org/ghc/9.0.1/docs/html/users_guide/9.0.1-notes.html">release notes</a> for a full accounting of the
changes in this release.</p>
<p>As always, feel free to report any issues you encounter via
<a href="https://gitlab.haskell.org/ghc/ghc/-/issues/new">gitlab.haskell.org</a>.</p>
]]></description>
    <pubDate>Thu, 04 Feb 2021 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20210204-ghc-9.0.1-released.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC 9.0.1 release candidate 1 now available</title>
    <link>http://haskell.org/ghc/blog/20201229-ghc-9.0.1-rc1-released.html</link>
    <description><![CDATA[<h1>GHC 9.0.1 release candidate 1 now available</h1>
<h4 class="text-muted">bgamari - 2020-12-29</h4>

<p>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 <a href="https://downloads.haskell.org/ghc/9.0.1-rc1/">usual place</a>.</p>
<p>This release candidate comes quite a bit later than expected after
difficulty finding a performance neutral fix for a critical soundness
bug, <a href="https://gitlab.haskell.org/ghc/ghc/issues/17760">#17760</a>. See the <a href="https://gitlab.haskell.org/ghc/ghc/-/wikis/migration/9.0#ghc-prim-07">migration page</a> for details on the solution, particularly
if you are a library maintainer currently using the <code>touch#</code> primop or
<code>Foreign.ForeignPtr.withForeignPtr</code>.</p>
<p>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.</p>
<p>In addition to numerous bug fixes, GHC 9.0.1 will bring a number of new
features:</p>
<ul>
<li><p>A first cut of the new <code>LinearTypes</code> <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0111-linear-types.rst">language extension</a>, allowing use
of linear function syntax and linear record fields.</p></li>
<li><p>A new bignum library (<code>ghc-bignum</code>), allowing GHC to be more easily
used with integer libraries other than GMP.</p></li>
<li><p>Improvements in code generation, resulting in considerable
performance improvements in some programs.</p></li>
<li><p>Improvements in pattern-match checking, allowing more precise
detection of redundant cases and reduced compilation time.</p></li>
<li><p>Implementation of the “simplified subsumption” <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0287-simplify-subsumption.rst">proposal</a>
simplifying the type system and paving the way for QuickLook
impredicativity in GHC 9.2.</p></li>
<li><p>Implementation of the <code>QualifiedDo</code> <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0216-qualified-do.rst">extension</a>, allowing more
convenient overloading of <code>do</code> syntax.</p></li>
<li><p>Improvements in compilation time.</p></li>
</ul>
<p>And many more. See the <a href="https://downloads.haskell.org/ghc/9.0.1-rc1/docs/html/users_guide/9.0.1-notes.html">release notes</a> for a full accounting of the
changes in this release.</p>
<p>As always, do test this release and open tickets for whatever issues you
encounter.</p>
]]></description>
    <pubDate>Tue, 29 Dec 2020 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20201229-ghc-9.0.1-rc1-released.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC 8.10.3 released</title>
    <link>http://haskell.org/ghc/blog/20201219-ghc-8.10.3-released.html</link>
    <description><![CDATA[<h1>GHC 8.10.3 released</h1>
<h4 class="text-muted">bgamari - 2020-12-19</h4>

<p>The GHC team is happy to announce the release of GHC 8.10.3. Source
and binary distributions are available at the <a href="https://downloads.haskell.org/ghc/8.10.3/">usual place</a>.</p>
<p>GHC 8.10.3 fixes a number of issues in present in GHC 8.10.2 including:</p>
<ul>
<li><p>Numerous stability improves on Windows</p></li>
<li><p>More robust support for architectures with weak memory ordering
guarantees (e.g. modern ARM hardware).</p></li>
<li><p>GHC can now split dynamic objects to accomodate macOS’ RPATH size
limitation when building large projects (<a href="https://gitlab.haskell.org/ghc/ghc/issues/14444">#14444</a>)</p></li>
<li><p>Several correctness bugs in the new low-latency garbage collector</p></li>
</ul>
<p>Note that at the moment we still require that macOS Catalina users
exempt the binary distribution from the notarization requirement by
running <code>xattr -cr .</code> on the unpacked tree before running <code>make install</code>.
This situation will hopefully be improved for GHC 9.0.1 with the
resolution of <a href="https://gitlab.haskell.org/ghc/ghc/issues/17418">#17418</a>.</p>
]]></description>
    <pubDate>Sat, 19 Dec 2020 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20201219-ghc-8.10.3-released.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC 8.10.2 released</title>
    <link>http://haskell.org/ghc/blog/20200808-ghc-8.10.2-released.html</link>
    <description><![CDATA[<h1>GHC 8.10.2 released</h1>
<h4 class="text-muted">bgamari - 2020-08-08</h4>

<p>The GHC team is happy to announce the availability of GHC 8.10.2. Source
and binary distributions are available at the <a href="https://downloads.haskell.org/ghc/8.10.2/">usual
place</a>.</p>
<p>GHC 8.10.2 fixes a number of issues in present in GHC 8.10.1 including:</p>
<ul>
<li><p>Fixes a bug in process creation on Windows (<a href="https://gitlab.haskell.org/ghc/ghc/issues/17926">#17926</a>).</p></li>
<li><p>Fixes a code generation bug resulting in incorrect code
generation for foreign calls with complex arguments (<a href="https://gitlab.haskell.org/ghc/ghc/issues/18527">#18527</a>)</p></li>
<li><p>Fixes a bug causing object merging to fail when the lld linker is in
use (<a href="https://gitlab.haskell.org/ghc/ghc/issues/17962">#17962</a>)</p></li>
<li><p>Introduces a workaround for a Linux kernel bug in the implementation
of the timerfd mechanism (<a href="https://gitlab.haskell.org/ghc/ghc/issues/18033">#18033</a>).</p></li>
<li><p>Fixes a few specialiser regressions (<a href="https://gitlab.haskell.org/ghc/ghc/issues/17810">#17810</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/18120">#18120</a>) as well
introduces a variety of miscellaneous specialiser improvements
(<a href="https://gitlab.haskell.org/ghc/ghc/issues/16473">#16473</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/17930">#17930</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/17966">#17966</a>)</p></li>
<li><p>Fixes a potential loss of sharing due to left operator sections (<a href="https://gitlab.haskell.org/ghc/ghc/issues/18151">#18151</a>).</p></li>
<li><p>Fix bootstrapping of GHC with the LLVM backend on x86-64 (<a href="https://gitlab.haskell.org/ghc/ghc/issues/17920">#17920</a>).</p></li>
<li><p>A few important correctness fixes for the low-latency garbage
collector. Users of <code>--nonmoving-gc</code> are strongly encouraged to upgrade
promptly.</p></li>
</ul>
<p>Note that at the moment we still require that macOS Catalina users
exempt the binary distribution from the notarization requirement by
running <code>xattr -cr .</code> on the unpacked tree before running <code>make install</code>.
This situation will hopefully be improved for GHC 9.0.1 with the
resolution of <a href="https://gitlab.haskell.org/ghc/ghc/issues/17418">#17418</a>.</p>
]]></description>
    <pubDate>Sat, 08 Aug 2020 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20200808-ghc-8.10.2-released.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>GHC 8.8.4 released</title>
    <link>http://haskell.org/ghc/blog/20200715-ghc-8.8.4-released.html</link>
    <description><![CDATA[<h1>GHC 8.8.4 released</h1>
<h4 class="text-muted">bgamari - 2020-07-15</h4>

<p>The GHC team is proud to announce the release of GHC 8.8.4. The source
distribution, binary distributions, and documentation are available at
<a href="https://downloads.haskell.org/~ghc/8.8.4">downloads.haskell.org</a>.</p>
<p>Release notes are also <a href="https://downloads.haskell.org/ghc/8.8.4/docs/html/users_guide/8.8.4-notes.html">available</a>.</p>
<p>This release fixes a handful of issues affecting 8.8.3:</p>
<ul>
<li><p>Fixes a bug in process creation on Windows (<a href="https://gitlab.haskell.org/ghc/ghc/issues/17926">#17926</a>). Due to this fix
we strongly encourage all Windows users to upgrade immediately.</p></li>
<li><p>Works around a Linux kernel bug in the implementation of timerfd
(<a href="https://gitlab.haskell.org/ghc/ghc/issues/18033">#18033</a>)</p></li>
<li><p>Fixes a few linking issues affecting ARM</p></li>
<li><p>Fixes “missing interface file” error triggered by some uses of
<code>Data.Ord.Ordering</code> (<a href="https://gitlab.haskell.org/ghc/ghc/issues/18185">#18185</a>)</p></li>
<li><p>Fixes an integer overflow in the compact-normal-form import
implementation (<a href="https://gitlab.haskell.org/ghc/ghc/issues/16992">#16992</a>)</p></li>
<li><p><code>configure</code> now accepts a <code>--enable-numa</code> flag to enable/disable
<code>numactl</code> support on Linux.</p></li>
<li><p>Fixes potentially lost sharing due to the desugaring of left operator
sections (<a href="https://gitlab.haskell.org/ghc/ghc/issues/18151">#18151</a>).</p></li>
<li><p>Fixes a build-system bug resulting in potential miscompilation by
unregisteised compilers (<a href="https://gitlab.haskell.org/ghc/ghc/issues/18024">#18024</a>)</p></li>
</ul>
<p>As always, if anything looks amiss do let us know.</p>
]]></description>
    <pubDate>Wed, 15 Jul 2020 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20200715-ghc-8.8.4-released.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>Integrating head.hackage with GHC's CI infrastructure</title>
    <link>http://haskell.org/ghc/blog/20200611-head-hackage.html</link>
    <description><![CDATA[<h1>Integrating head.hackage with GHC's CI infrastructure</h1>
<h4 class="text-muted">Ben Gamari - 2020-06-11</h4>

<p>Hello everyone,</p>
<p>As I mentioned a last year in my <a href="20190403-infra-status.html">infrastructure
update</a>, 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.</p>
<p>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!</p>
<h2 id="the-goal">The goal</h2>
<p>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:</p>
<ul>
<li><p><em>correctness testing</em>: 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.</p></li>
<li><p><em>compiler performance testing</em>: By measuring the performance of the compiler
as it compilers user code we learn more about the <em>typical</em> cost centers
within GHC. While we have dedicated performance testsuites (e.g. <code>nofib</code>)
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.</p></li>
<li><p><em>runtime performance testing</em>: As with (2), but measuring the performance of
the compiled program itself rather than that of GHC.</p></li>
</ul>
<p>While these potential benefits are significant, so are the challenges:</p>
<ol type="1">
<li><em>changes in GHC and core libraries</em>: Due to the tight coupling between GHC
and its core libraries (e.g. <code>base</code>, <code>template-haskell</code>), 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 <a href="https://www.haskell.org/ghc/blog/20190722-ghc-8.8.1-rc1-released.html">PVP</a>.</li>
<li><em>persistent breakage</em>: Because of the expected breakage mentioned in (1) any
package set of non-trivial size will contain at least a few broken packages
at any given time. For this reason, in contrast to typical CI pipelines, we
want to be notified only when packages’ build state <em>changes</em>: e.g. when a
package breakage <em>starts</em> (e.g. due to a breaking change being merged to GHC) but
not every subsequent breakage.</li>
<li><em>changes in user programs</em>: Particularly when tracking performance changes we
must take care when updating the tested set of packages: A we are fooled into
thinking that a change in a user program is a regression in GHC.</li>
</ol>
<p>While (2) and (3) are both non-trivial problems, a solution to (1) is close at
hand in the form of the
<a href="https://gitlab.haskell.org/ghc/head.hackage">head.hackage</a> patch-set.</p>
<h2 id="patching-hackage-for-pre-releases">Patching Hackage for pre-releases</h2>
<p>The <code>head.hackage</code> project is a set of patches and associated tools for
patching released Hackage packages to build with GHC pre-releases. While
<code>head.hackage</code> has been a tool in GHC developers’ toolbox for over a year now,
a few considerations has kept it from reaching its potential:</p>
<ol type="1">
<li>a lack of documentation and a few usability papercuts have limited adoption
to a small set of developers.</li>
<li>the lack of integration with GHC’s own continuous integration infrastructure
meant that testing of GHC snapshots had to be performed manually</li>
<li>the lack of automated testing of the patchset has precluded scaling the
approach to a larger set of packages.</li>
</ol>
<p>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 <code>head.hackage</code> to build a real-world package.</p>
<h2 id="testing-infrastructure">Testing infrastructure</h2>
<p>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:</p>
<ol type="1">
<li><p>Testing against GHC releases tests the patch-set, giving us (some)
assurance that the patches themselves are correct.</p></li>
<li><p>Testing against <code>master</code> (or pre-releases) provides assurance that
GHC itself hasn’t regressed.</p></li>
</ol>
<p>Happily, this effort has now converged on a usable result, embodied in
three merge requests:</p>
<p><a href="https://gitlab.haskell.org/ghc/head.hackage/merge_requests/2">ghc/head.hackage<span>!2</span></a>
adds CI support to <code>head.hackage</code>. In addition to a pass/fail status for the
overall build, this job produces (e.g. as seen in <a href="https://gitlab.haskell.org/ghc/head.hackage/-/jobs/361579">this
run</a>) a variety of
additional products:</p>
<ul>
<li><p>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.</p></li>
<li><p>a tarball of build logs, each including statistics from GHC’s
<code>-ddump-timings</code> 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.</p></li>
</ul>
<p>These can be fed to downstream tools, allowing us to better understand and
record the evolution of GHC’s performance and correctness.</p>
<h2 id="making-patched-packages-accessible-to-users">Making patched packages accessible to users</h2>
<p>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. <code>head.hackage</code>’s continuous integration now
produces a <a href="http://ghc.gitlab.haskell.org/head.hackage/">Hackage repository</a>,
which can be easily used to build existing projects using <code>cabal v2-build</code>’s
remote repository support. Use of this repository will be the focus of a future
blog post.</p>
<h2 id="future-work">Future work</h2>
<p>There are a few things that remain to be done:</p>
<ul>
<li><p>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.</p></li>
<li><p>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!</p>
<p>Furthermore, we might consider making authors of GHC patches which break
<code>head.hackage</code> responsible for updating the broken packages, further
spreading the maintenance load.</p></li>
<li><p>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.</p></li>
</ul>
<p>Finally, I would like to acknowledge Herbert Valerio Riedel whose vision for
the <code>head.hackage</code> patch-set evolved into the infrastructure described above.</p>
<p>Cheers,</p>
<ul>
<li>Ben</li>
</ul>
]]></description>
    <pubDate>Thu, 11 Jun 2020 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20200611-head-hackage.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>Profiling Template Haskell splices</title>
    <link>http://haskell.org/ghc/blog/20200524-profiling-template-haskell.html</link>
    <description><![CDATA[<h1>Profiling Template Haskell splices</h1>
<h4 class="text-muted">Ben Gamari - 2020-05-25</h4>

<p>This weekend a user came into <code>#ghc</code> asking how to profile their Template
Haskell splices using GHC’s <a href="https://downloads.haskell.org/~ghc/8.10.1/docs/html/users_guide/profiling.html">cost-center profiler</a>. While this is
<a href="https://downloads.haskell.org/~ghc/8.10.1/docs/html/users_guide/glasgow_exts.html#using-template-haskell-with-profiling">not so hard</a> 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.</p>
<p>In short, the method we arrived at takes advantage of GHC’s <a href="https://downloads.haskell.org/~ghc/8.10.1/docs/html/users_guide/ghci.html#ghc-flag--fexternal-interpreter">external
interpreter</a> coupled with <code>cabal-install</code>’s support for
producing <a href="https://downloads.haskell.org/~ghc/8.10.1/docs/html/users_guide/packages.html">package environment files</a>. To demonstrate the
approach, we will profile the Template Haskell-based lens derivation logic of
the <code>optics-th</code> package, using the <code>T799</code> module as our source of splices.</p>
<p>We first start by setting up a working directory of the project:</p>
<pre><code>$ cabal unpack optics-th
$ cd optics-th-0.3</code></pre>
<p>Now we will build the package with <code>cabal v2-build</code>, taking care to instruct
cabal to enable profiling and create a GHC environment file (which will be
necessary shortly):</p>
<pre><code>$ cabal v2-build lib:optics-th \
    --enable-profiling --write-ghc-environment-files=always</code></pre>
<p>Finally, we can invoke <code>ghc</code> on the module containing our splices, instructing
GHC to evaluate splices using the external interpreter with profiling enabled:</p>
<pre><code>$ ghc -prof -fexternal-interpreter -opti+RTS -opti-p tests/Optics/TH/Tests/T799.hs </code></pre>
<p>Now we have our profile:</p>
<pre><code>$ 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                         &lt;built-in&gt;                                               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

...</code></pre>
<p>Of course, we can also pass any of the usual heap profiling flags to the interpreter
by adding additional <code>-opti</code> flags. For instance,</p>
<pre><code>$ ghc -prof -fexternal-interpreter -opti+RTS -opti-p -opti-hy tests/Optics/TH/Tests/T799.hs </code></pre>
<p>would produce a heap profile by type, in addition to the usual <code>.prof</code> file.</p>
<h2 id="how-does-it-work">How does it work?</h2>
<p>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 <code>ghc</code> executable provided in
GHC binary distributions is not built with profiling enabled.</p>
<p>For this reason we must instruct GHC to rather run splices in another process
via the <code>-fexternal-interpreter</code> flag. This process is provided by the
<code>ghc-iserv</code> 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 <code>cabal-install</code>
came up short).</p>
<p>However, if we invoke GHC manually we must somehow tell it where to find the
dependencies that <code>cabal-install</code> built. For this we tell <code>cabal-install</code>
to save this information as a GHC package environment with the
<code>--write-ghc-environment-files</code> flag. GHC will look for this file (which is
named, e.g., <code>.ghc.environment.x86_64-linux-8.10.1</code>) when invoked.</p>
<p>Finally, invoking <code>ghc</code> with <code>-prof</code> 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.</p>
]]></description>
    <pubDate>Mon, 25 May 2020 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20200524-profiling-template-haskell.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>The state of GHC on ARM</title>
    <link>http://haskell.org/ghc/blog/20200515-ghc-on-arm.html</link>
    <description><![CDATA[<h1>The state of GHC on ARM</h1>
<h4 class="text-muted">bgamari - 2020-05-15</h4>

<p>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.</p>
<p>This task has a long history, being the project that brought me to GHC
development <a href="http://www.smart-cactus.org/~ben/posts/2013-01-04-ghc-arm-update.html">many years
ago</a>, 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.</p>
<p>In short, things are in significantly better shape today than they were back
in 2012. There are a few reasons for this:</p>
<ul>
<li><p>LLVM and <code>binutils</code> have stabilized significantly on ARM (this <a href="http://www.smart-cactus.org/~ben/posts/2014-11-28-state-of-llvm-backend.html">wasn’t
always</a>
the case)</p></li>
<li><p>ARM support in GHC’s linker is now mostly complete</p></li>
<li><p>(since GHC 8.10) GHC’s runtime system is much more careful about ensuring
memory ordering (see <a href="https://gitlab.haskell.org/ghc/ghc/merge_requests/1128">!1128</a>)</p></li>
</ul>
<p>Consequently, it now fairly easy to bring up GHC on ARMv7 and ARMv8 machines.</p>
<h3 id="getting-started-on-a-raspberry-pi">Getting started on a Raspberry Pi</h3>
<p>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.</p>
<p>Most Raspberry Pi users will be using the Raspbian Debian variant. Unfortunately,
due to some <a href="https://gitlab.haskell.org/ghc/ghc/issues/17856#note_256497">creative packaging
decisions</a> on the
part of the Raspbian maintainers, installing GHC under Raspbian requires a bit
of manual intervention.</p>
<p>First, we need to install LLVM 9 (which GHC uses for code generation on ARM):</p>
<div class="sourceCode" id="cb1"><pre class="sourceCode bash"><code class="sourceCode bash"><span id="cb1-1"><a href="#cb1-1" aria-hidden="true" tabindex="-1"></a><span class="ex">$</span> sudo apt-get install llvm-9</span></code></pre></div>
<p>Next we can fetch and install the GHC 8.10.1 ARMv7 binary distribution
for Debian 9:</p>
<div class="sourceCode" id="cb2"><pre class="sourceCode bash"><code class="sourceCode bash"><span id="cb2-1"><a href="#cb2-1" aria-hidden="true" tabindex="-1"></a><span class="ex">$</span> wget http://downloads.haskell.org/~ghc/8.10.1/ghc-8.10.1-armv7-deb9-linux.tar.xz</span>
<span id="cb2-2"><a href="#cb2-2" aria-hidden="true" tabindex="-1"></a><span class="ex">$</span> tar <span class="at">-xf</span> ghc-8.10.1-armv7-deb9-linux.tar.gz</span>
<span id="cb2-3"><a href="#cb2-3" aria-hidden="true" tabindex="-1"></a><span class="ex">$</span> cd ghc-8.10.1</span>
<span id="cb2-4"><a href="#cb2-4" aria-hidden="true" tabindex="-1"></a><span class="ex">$</span> ./configure CONF_CC_OPTS_STAGE2=<span class="st">&quot;-marm -march=armv7-a&quot;</span> CFLAGS=<span class="st">&quot;-marm -march=armv7-a&quot;</span></span>
<span id="cb2-5"><a href="#cb2-5" aria-hidden="true" tabindex="-1"></a><span class="ex">$</span> sudo make install</span></code></pre></div>
<p>Depending upon the speed of your storage medium this may take a while.
Here we have had to override the C flags inferred by <code>autoconf</code> since otherwise
<code>gcc</code> will produce invalid assembler (see <a href="https://gitlab.haskell.org/ghc/ghc/issues/17856">#17856</a>).</p>
<p>Finally, we can test our handiwork:</p>
<div class="sourceCode" id="cb3"><pre class="sourceCode bash"><code class="sourceCode bash"><span id="cb3-1"><a href="#cb3-1" aria-hidden="true" tabindex="-1"></a><span class="ex">$</span> ghc <span class="at">--version</span></span>
<span id="cb3-2"><a href="#cb3-2" aria-hidden="true" tabindex="-1"></a><span class="ex">$</span> cat <span class="op">&gt;</span> Hello.hs <span class="op">&lt;&lt;EOF</span></span>
<span id="cb3-3"><a href="#cb3-3" aria-hidden="true" tabindex="-1"></a><span class="st">&gt; main = putStrLn &quot;hello world!&quot;</span></span>
<span id="cb3-4"><a href="#cb3-4" aria-hidden="true" tabindex="-1"></a><span class="st">&gt; EOF</span></span>
<span id="cb3-5"><a href="#cb3-5" aria-hidden="true" tabindex="-1"></a><span class="st">$ ghc Hello.hs</span></span>
<span id="cb3-6"><a href="#cb3-6" aria-hidden="true" tabindex="-1"></a><span class="st">$ ./Hello</span></span>
<span id="cb3-7"><a href="#cb3-7" aria-hidden="true" tabindex="-1"></a><span class="st">hello world!</span></span></code></pre></div>
<p>We can even use GHCi:</p>
<div class="sourceCode" id="cb4"><pre class="sourceCode bash"><code class="sourceCode bash"><span id="cb4-1"><a href="#cb4-1" aria-hidden="true" tabindex="-1"></a><span class="ex">$</span> ghci</span>
<span id="cb4-2"><a href="#cb4-2" aria-hidden="true" tabindex="-1"></a><span class="ex">GHCi,</span> version 8.10.1: https://www.haskell.org/ghc/  :<span class="pp">?</span> for help</span>
<span id="cb4-3"><a href="#cb4-3" aria-hidden="true" tabindex="-1"></a><span class="ex">Prelude</span><span class="op">&gt;</span> putStrLn $ cycle <span class="st">&quot;turtles all the way down.\n&quot;</span></span>
<span id="cb4-4"><a href="#cb4-4" aria-hidden="true" tabindex="-1"></a><span class="ex">turtles</span> all the way down.</span>
<span id="cb4-5"><a href="#cb4-5" aria-hidden="true" tabindex="-1"></a><span class="ex">turtles</span> all the way down.</span>
<span id="cb4-6"><a href="#cb4-6" aria-hidden="true" tabindex="-1"></a><span class="ex">turtles</span> all the way down.</span>
<span id="cb4-7"><a href="#cb4-7" aria-hidden="true" tabindex="-1"></a><span class="ex">...</span></span></code></pre></div>
<p>Currently <code>Cabal</code>’s upstream doesn’t provide a <code>cabal-install</code> binary
distribution for ARM (although this will hopefully change
<a href="https://github.com/haskell/cabal/issues/6616">soon</a>). Nevertheless, I have
provided one
<a href="https://home.smart-cactus.org/~ben/ghc/cabal-install-3.4.0.0-rc4-armv7l-deb10.tar.xz">here</a>.</p>
<h3 id="future-work">Future work</h3>
<p>As always, there is plenty left to be done.</p>
<h4 id="further-memory-ordering-robustness">Further memory ordering robustness</h4>
<p>While <a href="https://gitlab.haskell.org/ghc/ghc/merge_requests/1128">!1128</a> 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
<a href="http://isvolatileusefulwiththreads.in/C/">abusing</a> C’s <code>volatile</code> 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).</p>
<p>However, finding all of the data races in the RTS is no small task. I currently
have an on-going series of <a href="https://gitlab.haskell.org/ghc/ghc/-/merge_requests/2642">merge
requests</a> which
adds support for checking GHC’s runtime with the
<a href="https://github.com/google/sanitizers/wiki/ThreadSanitizerCppManual">ThreadSanitizer</a>
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 <a href="https://gitlab.haskell.org/ghc/ghc/issues/17757">few</a>
<a href="https://gitlab.haskell.org/ghc/ghc/issues/17289">more</a> bugs and should make
GHC on ARM quite solid.</p>
<p>Where ThreadSanitizer does <em>not</em> 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.</p>
<h4 id="a-native-code-generator">A native code generator?</h4>
<p>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.</p>
<p>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!</p>
<h3 id="acknowledgments">Acknowledgments</h3>
<p>Continuous integration for ARM would not be possible without hosted hardware
contributions provided by <a href="https://www.packet.com/">Packet</a> through
the <a href="https://www.worksonarm.com/">Works on ARM</a> program.</p>
]]></description>
    <pubDate>Fri, 15 May 2020 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20200515-ghc-on-arm.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>DWARF support in GHC (part 5)</title>
    <link>http://haskell.org/ghc/blog/20200407-dwarf-5.html</link>
    <description><![CDATA[<h1>DWARF support in GHC (part 5)</h1>
<h4 class="text-muted">Ben Gamari - 2020-04-07</h4>

<p>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:</p>
<ul>
<li><a href="20200403-dwarf-1.html">Part 1</a> introduces DWARF debugging
information and explains how its generation can be enabled in GHC.</li>
<li><a href="20200404-dwarf-2.html">Part 2</a> looks at a DWARF-enabled program in
<code>gdb</code> and examines some of the limitations of this style of debug
information.</li>
<li><a href="20200405-dwarf-3.html">Part 3</a> looks at the backtrace support of
GHC’s runtime system and how it can be used from Haskell.</li>
<li><a href="20200406-dwarf-4.html">Part 4</a> examines how the Linux <code>perf</code>
utility can be used on GHC-compiled programs.</li>
<li><a href="20200407-dwarf-5.html">Part 5</a> concludes the series by describing
future work, related projects, and ways in which you can help.</li>
</ul>
<h2 id="future-work">Future work</h2>
<p>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.</p>
<p>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:</p>
<ul>
<li>Merge the fruits of my latest push on DWARF support upstream (<a href="https://gitlab.haskell.org/ghc/ghc/merge_requests/2380">!2380</a>,
<a href="https://gitlab.haskell.org/ghc/ghc/merge_requests/2373">!2373</a>, <a href="https://gitlab.haskell.org/ghc/ghc/merge_requests/2387">!2387</a>)</li>
<li>Make GHC-generated symbols (e.g. <code>59fw_info</code>) more reflective of
their origin in the source program</li>
<li>Preserve call-stacks in exceptions (as discussed in <a href="20200405-dwarf-3.html">part
3</a>)</li>
<li>Reduce the size of debug information through more concise
representation (see <a href="https://gitlab.haskell.org/ghc/ghc/issues/17609">#17609</a>)</li>
<li>Some RTS symbols (e.g. <code>stg_PAP_apply</code>) don’t have accurate unwind
information, leading to truncated backtraces in some cases (<a href="https://gitlab.haskell.org/ghc/ghc/issues/17627">#17627</a>)</li>
<li>Implement a native (e.g. non-DWARF-based) stack unwinder in the GHC
runtime system, allowing improved unwind performance in Haskell code</li>
<li>Windows PDB support (<a href="https://gitlab.haskell.org/ghc/ghc/issues/12397">#12397</a>)</li>
<li>Try moving GHC’s stack pointer to the native stack pointer register,
enabling call-graph profiling via DWARF unwinding (as discussed in
<a href="20200406-dwarf-4.html">part 4</a>, <a href="https://gitlab.haskell.org/ghc/ghc/issues/8272">#8272</a>)</li>
<li>Build statistical profiling support into the GHC runtime system
(<a href="https://gitlab.haskell.org/ghc/ghc/issues/10915">#10915</a>)</li>
<li>Add support for expressing local variables in C–, enabling
allocation profiling</li>
<li>Add support for tracking register value semantics in STG-to-C– and
DWARF type information, enabling local variable introspection.</li>
<li>Implement thread support in <code>GHC.ExecutionStack</code></li>
<li>Make better use of GHC-specific source-note information (mentioned
briefly in <a href="20200403-dwarf-1.html">part 1</a>)</li>
<li>Symbol demangling support in the GHC RTS, <code>perf</code>, and <code>gdb</code></li>
<li>Analysis tools</li>
</ul>
<p>As always, we are looking for people to help with this effort. If any of
the above tasks sound enticing to you, do let us know. Deep compiler
experience is quite unnecessary for many of these tasks, especially
those in the area of analysis tools.</p>
<p>Below I will describe in greater detail a few of the tasks which I think
hold the greatest potential.</p>
<h3 id="profile-analysis-tools">Profile analysis tools</h3>
<p>In his thesis, Peter Wortmann shows that the one-to-one correspondence
between instructions and line numbers required by DWARF (see <a href="20200403-dwarf-1.html">part
1</a>) 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
<code>perf record</code> (e.g. exporting the samples via the <code>perf script</code> tool or
the <code>linux-perf</code> <a href="http://hackage.haskell.org/package/linux-perf">Haskell
library</a>) and using the
the extended DWARF annotations <a href="https://downloads.haskell.org/~ghc/8.10.1/docs/html/users_guide/debug-info.html#dw-tag-ghc-src-note">produced by
GHC</a>.</p>
<p>Peter’s Haskell Implementor’s Workshop
<a href="https://www.youtube.com/watch?v=kBm1sW3hNck">demonstration</a> 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.</p>
<h3 id="using-native-stack-pointer-register">Using native stack pointer register</h3>
<p>As noted in <a href="20200406-dwarf-4.html">part 4</a>, GHC’s current execution
model on x86 precludes use of <code>perf record</code>’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
(<a href="https://gitlab.haskell.org/ghc/ghc/issues/8272">#8272</a>). This would potentially carry a few benefits:</p>
<ul>
<li><p>it would enable use of native profiling tools</p></li>
<li><p>the native code generator could use the <code>PUSH</code> and <code>POP</code>
instructions, which may be more concise or better optimised in the
microarchitecture than our current stack manipulation strategy</p></li>
</ul>
<p>However, there are also a few tricky points:</p>
<ul>
<li><p>LLVM makes very strong assumptions about the nature of the stack;
consequently, moving the LLVM backend to this scheme may be
non-trivial.</p></li>
<li><p>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.</p></li>
</ul>
<p>There is some interesting discussion surrounding this idea in <a href="https://gitlab.haskell.org/ghc/ghc/issues/8272">#8272</a> and
<a href="https://github.com/ghc-proposals/ghc-proposals/pull/17">GHC Proposal MR
<span>#17</span></a>.</p>
<h3 id="building-sampling-profiling-into-the-ghc-runtime">Building sampling profiling into the GHC runtime</h3>
<p>Without fixing the stack register issue described above, <code>perf</code>’s
call-graph profiling functionality is unusable. However, nothing is
stopping GHC from providing its own sampling infrastructure in the
runtime (<a href="https://gitlab.haskell.org/ghc/ghc/issues/10915">#10915</a>). In 2016 I started a
<a href="https://gitlab.haskell.org/ghc/ghc/tree/wip/libdw-prof">branch</a>) doing
exactly this using <code>perf_events</code>’s signal-based sampling interface,
dumping samples to GHC’s eventlog.</p>
<p>As far as I can recall the <code>wip/libdw-prof</code> branch can readily collect
samples; the work that remains primarily revolves around developing
analysis tools.</p>
<p>One approach would be to build a tool to convert the GHC-eventlog-based
output from the <code>wip/libdw-prof</code> branch into a <code>perf.data</code> file for use
with <code>perf report</code>. However, one could no doubt do much better with a
more specialised tool, as described in the “Profile analysis tools”
above.</p>
<p>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 <code>perf_events</code> event.</p>
<h3 id="in-scope-bindings">In-scope bindings</h3>
<p>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:</p>
<div class="sourceCode" id="cb1"><pre class="sourceCode haskell"><code class="sourceCode haskell"><span id="cb1-1"><a href="#cb1-1" aria-hidden="true" tabindex="-1"></a><span class="ot">f ::</span> (<span class="dt">Int</span>, <span class="dt">String</span>) <span class="ot">-&gt;</span> <span class="dt">Int</span></span>
<span id="cb1-2"><a href="#cb1-2" aria-hidden="true" tabindex="-1"></a>f (x, _) <span class="ot">=</span> x <span class="op">+</span> <span class="dv">4</span></span></code></pre></div>
<p>GHC’s worker-wrapper transformation would likely transform this to,</p>
<div class="sourceCode" id="cb2"><pre class="sourceCode haskell"><code class="sourceCode haskell"><span id="cb2-1"><a href="#cb2-1" aria-hidden="true" tabindex="-1"></a><span class="ot">f ::</span> (<span class="dt">Int</span>, <span class="dt">String</span>) <span class="ot">-&gt;</span> <span class="dt">Int</span></span>
<span id="cb2-2"><a href="#cb2-2" aria-hidden="true" tabindex="-1"></a>f pair <span class="ot">=</span></span>
<span id="cb2-3"><a href="#cb2-3" aria-hidden="true" tabindex="-1"></a>  <span class="kw">case</span> pair <span class="kw">of</span> (x, _) <span class="ot">-&gt;</span> </span>
<span id="cb2-4"><a href="#cb2-4" aria-hidden="true" tabindex="-1"></a>  <span class="kw">case</span> x <span class="kw">of</span> <span class="dt">I</span><span class="op">#</span> x<span class="op">#</span> <span class="ot">-&gt;</span></span>
<span id="cb2-5"><a href="#cb2-5" aria-hidden="true" tabindex="-1"></a>  <span class="kw">case</span> <span class="op">$</span>wf x<span class="op">#</span> <span class="kw">of</span> result <span class="ot">-&gt;</span></span>
<span id="cb2-6"><a href="#cb2-6" aria-hidden="true" tabindex="-1"></a>    <span class="dt">I</span><span class="op">#</span> result</span>
<span id="cb2-7"><a href="#cb2-7" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb2-8"><a href="#cb2-8" aria-hidden="true" tabindex="-1"></a><span class="op">$</span><span class="ot">wf ::</span> <span class="dt">Int</span><span class="op">#</span> <span class="ot">-&gt;</span> <span class="dt">Int</span><span class="op">#</span></span>
<span id="cb2-9"><a href="#cb2-9" aria-hidden="true" tabindex="-1"></a><span class="op">$</span>wf x<span class="op">#</span> <span class="ot">=</span> x<span class="op">#</span> <span class="op">+</span> <span class="dv">4</span></span></code></pre></div>
<p>This sort of transformation is ubiquitous and critical to the quality of
GHC’s produced code. Naturally, we would want to ensure that the debug
information of <code>$wf</code> can represent the fact that <code>x#</code> is the unboxed
first element of the argument of <code>f</code>. I suspect that the best way to
accomplish this would be to propagate value provenance information
through binders’ (e.g. in this case <code>x#</code>) <code>IdInfo</code> metadata.</p>
<p>This would involve:</p>
<ol type="1">
<li>Adding syntax in C– to encode local variable information</li>
<li>Producing such syntax in the STG-to-C– code generator</li>
<li>Adding information in Core to propagate value provenance, as
discussed above</li>
<li>Populate this information in worker-wrapper</li>
</ol>
<p>While being able to poke around at Haskell values in <code>gdb</code> 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.</p>
<h3 id="aside-event-tracing">Aside: Event tracing</h3>
<p>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 <code>perf</code>, <code>bcc</code>, <code>bpftrace</code>, and <code>dtrace</code> 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.</p>
<p>The easiest on-ramp to tracing support is via the <a href="http://dtrace.org/guide/chp-usdt.html">User-space
Statically-Defined Tracepoint</a>
(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.</p>
<p>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 <code>--enable-dtrace</code> <code>configure</code> flag). However, it is possible that
this support may have bit-rotted (<a href="https://gitlab.haskell.org/ghc/ghc/issues/15543">#15543</a>).</p>
<p>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.</p>
<h3 id="aside-llvm-and-x-ray">Aside: LLVM and X-Ray</h3>
<p>It should also be noted that LLVM provides another, much different
approach to the tracing/profiling problem with its <a href="https://www.llvm.org/docs/XRay.html">XRay instrumentation
infrastructure</a>. This approach
seeks to introduce low-cost tracing instrumentation in generated code,
allowing precise and highly detailed accounting of runtime costs.</p>
<p>Matthew Pickering tried (<a href="https://gitlab.haskell.org/ghc/ghc/issues/15929">#15929</a>) 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 <code>alias</code> mechanism to convince LLVM that
our type annotations are correct; this confuses the XRay logic).</p>
<h2 id="acknowledgments">Acknowledgments</h2>
<p>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.</p>
<p>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 <a href="http://etheses.whiterose.ac.uk/8321/">dissertation</a>
provide the theoretical foundation for all of this functionality, but
his initial implmentation kick-started the effort and the promising
results he <a href="https://www.youtube.com/watch?v=kBm1sW3hNck">demonstrated</a>
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.</p>
<p>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.</p>
]]></description>
    <pubDate>Tue, 07 Apr 2020 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20200407-dwarf-5.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>DWARF support in GHC (part 4)</title>
    <link>http://haskell.org/ghc/blog/20200406-dwarf-4.html</link>
    <description><![CDATA[<h1>DWARF support in GHC (part 4)</h1>
<h4 class="text-muted">Ben Gamari - 2020-04-06</h4>

<p>This post is the fourth of a series examining GHC’s support for DWARF
debug information and the tooling that this support enables:</p>
<ul>
<li><a href="20200403-dwarf-1.html">Part 1</a> introduces DWARF debugging
information and explains how its generation can be enabled in GHC.</li>
<li><a href="20200404-dwarf-2.html">Part 2</a> looks at a DWARF-enabled program in
<code>gdb</code> and examines some of the limitations of this style of debug
information.</li>
<li><a href="20200405-dwarf-3.html">Part 3</a> looks at the backtrace support of
GHC’s runtime system and how it can be used from Haskell.</li>
<li><a href="20200406-dwarf-4.html">Part 4</a> examines how the Linux <code>perf</code>
utility can be used on GHC-compiled programs.</li>
<li><a href="20200407-dwarf-5.html">Part 5</a> concludes the series by describing
future work, related projects, and ways in which you can help.</li>
</ul>
<h2 id="profiling-with-perf">Profiling with <code>perf</code></h2>
<p>The final application of debug information that we will examine is
performance analysis, specifically profiling with the Linux <code>perf</code>
<a href="https://perf.wiki.kernel.org/index.php/Main_Page">tool</a>.</p>
<p><code>perf</code> 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 <code>perf</code> to profile allocations of a Haskell program.</p>
<p>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.</p>
<div class="table">
<table style="width:89%;">
<caption>Summary of the trade-offs made by cost-center profiler and
statistical profiling with <code>perf</code>.</caption>
<colgroup>
<col style="width: 22%" />
<col style="width: 30%" />
<col style="width: 36%" />
</colgroup>
<thead>
<tr class="header">
<th style="text-align: center;">Attribute</th>
<th style="text-align: center;"><code>perf</code></th>
<th style="text-align: center;">cost-center profiler</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td style="text-align: center;">Runtime impact</td>
<td style="text-align: center;">negligible</td>
<td style="text-align: center;">anywhere from moderate to
high</td>
</tr>
<tr class="even">
<td style="text-align: center;">Relatability to
source program</td>
<td style="text-align: center;">often hard to relate
back to source program</td>
<td style="text-align: center;">profile structure directly
reflects cost centers
declared in source program</td>
</tr>
<tr class="odd">
<td style="text-align: center;">Provides call
graphs</td>
<td style="text-align: center;">yes, with limited depth</td>
<td style="text-align: center;">yes</td>
</tr>
<tr class="even">
<td style="text-align: center;">Provides call
graphs on Haskell
programs</td>
<td style="text-align: center;">not currently</td>
<td style="text-align: center;">yes</td>
</tr>
<tr class="odd">
<td style="text-align: center;">Profiled
variables</td>
<td style="text-align: center;">time, allocations,
micro-architectural
counters, system calls,
user- and kernel-space
probe points</td>
<td style="text-align: center;">time, allocations</td>
</tr>
<tr class="even">
<td style="text-align: center;">Determinism</td>
<td style="text-align: center;">profile is statistical
and will likely vary
from run to run</td>
<td style="text-align: center;">deterministic</td>
</tr>
</tbody>
</table>
</div>
<p>To see this trade-off in action, let’s return to our <code>vector-tests-O0</code>
example. We can acquire a simple time profile by simply running the
executable under <code>perf record</code>:</p>
<pre><code>$ perf record vector-tests-O0</code></pre>
<p>The resulting profile can be examined via <code>perf report</code>. This will show
you a TUI interface along the lines of</p>
<pre><code>Samples: 145K of event &#39;cycles:ppp&#39;, 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
...</code></pre>
<p>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 <code>perf</code> will show the annotated assembler of this function,
along with the associated Haskell source.</p>
<p>In principle, <code>perf record</code> can also give us call-graph information. We
will examine this in depth in the next section.</p>
<h3 id="paths-to-call-stack-profiling">Paths to call-stack profiling</h3>
<p>In addition to the flat profiles we saw earlier, <code>perf</code> 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 <code>perf record -g</code> command.</p>
<p>Unlike flat profiles, call-graph capture tends to be quite language- and
hardware-dependent. Consequently, <code>perf record</code> currently provides three
mechanisms for collecting call-stacks:</p>
<ul>
<li><p>via the <a href="https://en.wikipedia.org/wiki/Call_stack#FRAME-POINTER">frame pointer
register</a>:
GHC doesn’t track the frame-pointer like many imperative languages
do, so this is unusable on Haskell programs.</p></li>
<li><p>via the <a href="https://lwn.net/Articles/680985/">last branch record</a>
(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).</p></li>
<li><p>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.</p></li>
</ul>
<p>Recent Intel hardware also includes another, more expensive hardware
mechanism, the Branch Trace Store, which could be useful for deeper
call-graph acquisition but <code>perf record</code> support currently does not
support using it for call-graph capture.</p>
<div class="table">
<table style="width:88%;">
<caption>Summary of trade-offs made by various call-stack collection
mechanisms supported by <code>perf record</code>.</caption>
<colgroup>
<col style="width: 25%" />
<col style="width: 20%" />
<col style="width: 21%" />
<col style="width: 21%" />
</colgroup>
<thead>
<tr class="header">
<th style="text-align: center;">attribute</th>
<th style="text-align: center;">frame pointer</th>
<th style="text-align: center;">LBR</th>
<th style="text-align: center;">DWARF</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td style="text-align: center;">maximum depth</td>
<td style="text-align: center;">unlimited</td>
<td style="text-align: center;">32 on Skylake</td>
<td style="text-align: center;">unlimited</td>
</tr>
<tr class="even">
<td style="text-align: center;">runtime overhead</td>
<td style="text-align: center;">negligible</td>
<td style="text-align: center;">negligible</td>
<td style="text-align: center;">small</td>
</tr>
<tr class="odd">
<td style="text-align: center;">compatible with GHC
execution model</td>
<td style="text-align: center;">no</td>
<td style="text-align: center;">yes?</td>
<td style="text-align: center;">not currently</td>
</tr>
</tbody>
</table>
</div>
<p>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. <code>%rsp</code> on x86-64) to store the Haskell stack pointer GHC rather
reserves another register (<code>%rbp</code> 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 <code>perf record</code> sadly is not. For this
reason, the unwind information produced by <code>ghc -g</code> is of little use
when profiling with <code>perf record -g</code>.</p>
<p>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
<code>call</code> instruction means that in practice the call-graphs produced by
this method tend not to be very useful.</p>
<p>In sum, currently I do not have a prescription for call-graph profiling
of Haskell programs with <code>perf</code>. The <a href="20200407-dwarf-5.html">next and final
post</a> 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.</p>
]]></description>
    <pubDate>Mon, 06 Apr 2020 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20200406-dwarf-4.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>DWARF support in GHC (part 3)</title>
    <link>http://haskell.org/ghc/blog/20200405-dwarf-3.html</link>
    <description><![CDATA[<h1>DWARF support in GHC (part 3)</h1>
<h4 class="text-muted">Ben Gamari - 2020-04-05</h4>

<p>This post is the third of a series examining GHC’s support for DWARF
debug information and the tooling that this support enables:</p>
<ul>
<li><a href="20200403-dwarf-1.html">Part 1</a> introduces DWARF debugging
information and explains how its generation can be enabled in GHC.</li>
<li><a href="20200404-dwarf-2.html">Part 2</a> looks at a DWARF-enabled program in
<code>gdb</code> and examines some of the limitations of this style of debug
information.</li>
<li><a href="20200405-dwarf-3.html">Part 3</a> looks at the backtrace support of
GHC’s runtime system and how it can be used from Haskell.</li>
<li><a href="20200406-dwarf-4.html">Part 4</a> examines how the Linux <code>perf</code>
utility can be used on GHC-compiled programs.</li>
<li><a href="20200407-dwarf-5.html">Part 5</a> concludes the series by describing
future work, related projects, and ways in which you can help.</li>
</ul>
<h2 id="getting-backtraces-from-the-runtime">Getting backtraces from the runtime</h2>
<p>We saw in the <a href="20200404-dwarf-2.html">last post</a> that GHC’s debug
information can be used by the <code>gdb</code> 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:</p>
<ul>
<li>via the <code>SIGQUIT</code> signal</li>
<li>via the <code>GHC.ExecutionStack</code> interface in <code>base</code></li>
</ul>
<p>In the first case, programs built with debug symbols and a
<code>libdw</code>-enabled compiler can be sent the <code>SIGQUIT</code> signal <a href="#fn1" class="footnote-ref" id="fnref1" role="doc-noteref"><sup>1</sup></a>,
resulting in a stack trace being blurted to <code>stderr</code>:</p>
<pre><code>$ vector-tests-O0 &gt;/dev/null &amp; 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)</code></pre>
<p>This can be especially useful in diagnosing unexpected CPU usage or
latency in long-running tasks (e.g. a server stuck in a loop).</p>
<p>Note, however, that this currently only provides a backtrace of the
program’s main capability. Backtrace support for multiple capabilities
is an <a href="https://gitlab.haskell.org/ghc/ghc/issues/15774">outstanding
task</a>.</p>
<h3 id="getting-backtraces-from-haskell">Getting backtraces from Haskell</h3>
<p>The runtime’s unwinding support can also be invoked from Haskell
programs via the
<a href="https://hackage.haskell.org/package/base-4.12.0.0/docs/GHC-ExecutionStack.html">GHC.ExecutionStack</a>
interface. This provides:</p>
<div class="sourceCode" id="cb2"><pre class="sourceCode haskell"><code class="sourceCode haskell"><span id="cb2-1"><a href="#cb2-1" aria-hidden="true" tabindex="-1"></a><span class="co">-- | A source location.</span></span>
<span id="cb2-2"><a href="#cb2-2" aria-hidden="true" tabindex="-1"></a><span class="kw">data</span> <span class="dt">Location</span> <span class="ot">=</span> <span class="co">{- ... -}</span></span>
<span id="cb2-3"><a href="#cb2-3" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb2-4"><a href="#cb2-4" aria-hidden="true" tabindex="-1"></a><span class="co">-- | Returns a stack trace of the calling thread or &#39;Nothing&#39;</span></span>
<span id="cb2-5"><a href="#cb2-5" aria-hidden="true" tabindex="-1"></a><span class="co">-- if the runtime system lacks libdw support.</span></span>
<span id="cb2-6"><a href="#cb2-6" aria-hidden="true" tabindex="-1"></a><span class="ot">getStackTrace ::</span> <span class="dt">IO</span> (<span class="dt">Maybe</span> [<span class="dt">Location</span>])</span></code></pre></div>
<p>In the future we would also like to provide</p>
<div class="sourceCode" id="cb3"><pre class="sourceCode haskell"><code class="sourceCode haskell"><span id="cb3-1"><a href="#cb3-1" aria-hidden="true" tabindex="-1"></a><span class="ot">getThreadStackTrace ::</span> <span class="dt">ThreadId</span> <span class="ot">-&gt;</span> <span class="dt">IO</span> (<span class="dt">Maybe</span> [<span class="dt">Location</span>])</span></code></pre></div>
<p>although this is an <a href="https://gitlab.haskell.org/ghc/ghc/issues/17630">outstanding
task</a>.</p>
<p>This could be used in a number of ways:</p>
<ol type="1">
<li><p>when throwing an exception, one could capture the current stack for
use in diagnostics output.</p></li>
<li><p>with <code>getThreadStackTrace</code> a monitoring library like <code>ekg</code> might
provide the ability to enumerate the program’s threads and
introspect on what they are up to.</p></li>
</ol>
<p>We’ll look at (1) in greater detail below.</p>
<h3 id="providing-backtraces-for-exceptions">Providing backtraces for exceptions</h3>
<p>Attaching backtrace information to exceptions is fairly straightforward.
For instance, one could provide</p>
<div class="sourceCode" id="cb4"><pre class="sourceCode haskell"><code class="sourceCode haskell"><span id="cb4-1"><a href="#cb4-1" aria-hidden="true" tabindex="-1"></a><span class="kw">data</span> <span class="dt">WithStack</span> e <span class="ot">=</span> <span class="dt">WithStack</span> (<span class="dt">Maybe</span> [<span class="dt">Location</span>]) e</span>
<span id="cb4-2"><a href="#cb4-2" aria-hidden="true" tabindex="-1"></a><span class="kw">instance</span> <span class="dt">Exception</span> (<span class="dt">WithStack</span> e)</span>
<span id="cb4-3"><a href="#cb4-3" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb4-4"><a href="#cb4-4" aria-hidden="true" tabindex="-1"></a><span class="ot">throwIOWithStack ::</span> e <span class="ot">-&gt;</span> <span class="dt">IO</span> a</span>
<span id="cb4-5"><a href="#cb4-5" aria-hidden="true" tabindex="-1"></a>throwIOWithStack exc <span class="ot">=</span> <span class="kw">do</span></span>
<span id="cb4-6"><a href="#cb4-6" aria-hidden="true" tabindex="-1"></a> stack <span class="ot">&lt;-</span> getStackTrace</span>
<span id="cb4-7"><a href="#cb4-7" aria-hidden="true" tabindex="-1"></a> throwM <span class="op">$</span> <span class="dt">WithStack</span> stack exc</span>
<span id="cb4-8"><a href="#cb4-8" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb4-9"><a href="#cb4-9" aria-hidden="true" tabindex="-1"></a><span class="ot">throwWithStack ::</span> e <span class="ot">-&gt;</span> a</span>
<span id="cb4-10"><a href="#cb4-10" aria-hidden="true" tabindex="-1"></a>throwWithStack <span class="ot">=</span> unsafePerformIO <span class="op">.</span> throwIOWithStack</span>
<span id="cb4-11"><a href="#cb4-11" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb4-12"><a href="#cb4-12" aria-hidden="true" tabindex="-1"></a><span class="co">-- | Attach a stack trace to any exception thrown by the enclosed action.</span></span>
<span id="cb4-13"><a href="#cb4-13" aria-hidden="true" tabindex="-1"></a><span class="co">-- Note that this is idempotent.</span></span>
<span id="cb4-14"><a href="#cb4-14" aria-hidden="true" tabindex="-1"></a><span class="ot">addStack ::</span> <span class="dt">IO</span> a <span class="ot">-&gt;</span> <span class="dt">IO</span> a</span>
<span id="cb4-15"><a href="#cb4-15" aria-hidden="true" tabindex="-1"></a>addStack <span class="ot">=</span> handle f</span>
<span id="cb4-16"><a href="#cb4-16" aria-hidden="true" tabindex="-1"></a>  <span class="kw">where</span></span>
<span id="cb4-17"><a href="#cb4-17" aria-hidden="true" tabindex="-1"></a><span class="ot">    f ::</span> <span class="dt">SomeException</span> <span class="ot">-&gt;</span> <span class="dt">IO</span> b</span>
<span id="cb4-18"><a href="#cb4-18" aria-hidden="true" tabindex="-1"></a>    f exc <span class="op">|</span> <span class="dt">WithStack</span>{} <span class="ot">&lt;-</span> fromException exc <span class="ot">=</span></span>
<span id="cb4-19"><a href="#cb4-19" aria-hidden="true" tabindex="-1"></a>      throwIO exc  <span class="co">-- ensure idempotency</span></span>
<span id="cb4-20"><a href="#cb4-20" aria-hidden="true" tabindex="-1"></a>    f (<span class="dt">SomeException</span> exc) <span class="ot">=</span></span>
<span id="cb4-21"><a href="#cb4-21" aria-hidden="true" tabindex="-1"></a>      throwIOWithStack exc</span></code></pre></div>
<p>Keep in mind that DWARF stack unwinding can incur a significant overhead
(being linear in the depth of the stack with a significant constant
factor). Consequently, it would be unwise to use <code>throwIOWithStack</code>
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.</p>
<p>Unfortunately, the untyped nature of Haskell exceptions complicates the
migration path for existing code. Specifically, if a library provides a
function which throws <code>MyException</code>, users catching <code>MyException</code> would
break if the library started throwing <code>WithStack MyException</code>. While
this may be manageable in the case of user libraries, for packages at
the heart of the Haskell ecosystem (e.g. <code>base</code>) this is a significant
hurdle.</p>
<p>Another design which avoids this migration problem is to incorporate
backtraces directly into the <code>base</code> <code>SomeException</code> type, which is used
to represent all thrown exceptions. Specifically, <code>Control.Exception</code>
could then expose a variety of throwing functions, reflecting the many
call stack mechanisms GHC now offers:</p>
<div class="sourceCode" id="cb5"><pre class="sourceCode haskell"><code class="sourceCode haskell"><span id="cb5-1"><a href="#cb5-1" aria-hidden="true" tabindex="-1"></a><span class="kw">data</span> <span class="dt">SomeException</span> <span class="kw">where</span></span>
<span id="cb5-2"><a href="#cb5-2" aria-hidden="true" tabindex="-1"></a>    <span class="dt">SomeException</span><span class="ot"> ::</span> <span class="kw">forall</span> e<span class="op">.</span> <span class="dt">Exception</span> e</span>
<span id="cb5-3"><a href="#cb5-3" aria-hidden="true" tabindex="-1"></a>                  <span class="ot">=&gt;</span> <span class="dt">Maybe</span> [<span class="dt">Location</span>]  <span class="co">-- ^ backtrace, if available</span></span>
<span id="cb5-4"><a href="#cb5-4" aria-hidden="true" tabindex="-1"></a>                  <span class="ot">-&gt;</span> e                 <span class="co">-- ^ the exception</span></span>
<span id="cb5-5"><a href="#cb5-5" aria-hidden="true" tabindex="-1"></a>                  <span class="ot">-&gt;</span> <span class="dt">SomeException</span></span>
<span id="cb5-6"><a href="#cb5-6" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb5-7"><a href="#cb5-7" aria-hidden="true" tabindex="-1"></a><span class="co">-- | A representation of source locations consolidating &#39;GHC.Stack.SrcLoc&#39;,</span></span>
<span id="cb5-8"><a href="#cb5-8" aria-hidden="true" tabindex="-1"></a><span class="co">-- &#39;GHC.Stack.CostCentre&#39;, and &#39;GHC.ExecutionStack.Location&#39;.</span></span>
<span id="cb5-9"><a href="#cb5-9" aria-hidden="true" tabindex="-1"></a><span class="kw">data</span> <span class="dt">Location</span> <span class="ot">=</span> <span class="co">{- ... -}</span></span>
<span id="cb5-10"><a href="#cb5-10" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb5-11"><a href="#cb5-11" aria-hidden="true" tabindex="-1"></a><span class="co">-- | Throws an exception with no stack trace.</span></span>
<span id="cb5-12"><a href="#cb5-12" aria-hidden="true" tabindex="-1"></a><span class="ot">throwIO ::</span> e <span class="ot">-&gt;</span> <span class="dt">IO</span> a</span>
<span id="cb5-13"><a href="#cb5-13" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb5-14"><a href="#cb5-14" aria-hidden="true" tabindex="-1"></a><span class="co">-- | Throws an exception with a stack trace captured via</span></span>
<span id="cb5-15"><a href="#cb5-15" aria-hidden="true" tabindex="-1"></a><span class="co">-- &#39;GHC.Stack.getStackTrace&#39;.</span></span>
<span id="cb5-16"><a href="#cb5-16" aria-hidden="true" tabindex="-1"></a><span class="ot">throwIOWithExecutionStack ::</span> e <span class="ot">-&gt;</span> <span class="dt">IO</span> a</span>
<span id="cb5-17"><a href="#cb5-17" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb5-18"><a href="#cb5-18" aria-hidden="true" tabindex="-1"></a><span class="co">-- | Throws an exception with a `HasCallStack` stack trace.</span></span>
<span id="cb5-19"><a href="#cb5-19" aria-hidden="true" tabindex="-1"></a><span class="ot">throwIOWithCallStack ::</span> <span class="dt">HasCallStack</span> <span class="ot">=&gt;</span> e <span class="ot">-&gt;</span> <span class="dt">IO</span> a</span></code></pre></div>
<p>Of course, this raises the question of which call-stack method a
particular exception ought to use. This is often unknowable, depending
upon the user’s build configuration. Consequently, we might consider
exposing something of the form:</p>
<div class="sourceCode" id="cb6"><pre class="sourceCode haskell"><code class="sourceCode haskell"><span id="cb6-1"><a href="#cb6-1" aria-hidden="true" tabindex="-1"></a><span class="co">-- | Throws an exception with a stack trace using the most</span></span>
<span id="cb6-2"><a href="#cb6-2" aria-hidden="true" tabindex="-1"></a><span class="co">-- precise method available in the current build configuration.</span></span>
<span id="cb6-3"><a href="#cb6-3" aria-hidden="true" tabindex="-1"></a><span class="ot">throwIOWithStack ::</span> <span class="dt">HasCallStack</span> <span class="ot">=&gt;</span> e <span class="ot">-&gt;</span> <span class="dt">IO</span> a</span>
<span id="cb6-4"><a href="#cb6-4" aria-hidden="true" tabindex="-1"></a>throwIOWithStack</span>
<span id="cb6-5"><a href="#cb6-5" aria-hidden="true" tabindex="-1"></a>  <span class="op">|</span> profiling_enabled <span class="ot">=</span> throwIOWithCostCentreStack</span>
<span id="cb6-6"><a href="#cb6-6" aria-hidden="true" tabindex="-1"></a>  <span class="op">|</span> dwarf_enabled     <span class="ot">=</span> throwIOWithExecutionStack</span>
<span id="cb6-7"><a href="#cb6-7" aria-hidden="true" tabindex="-1"></a>  <span class="op">|</span> <span class="fu">otherwise</span>         <span class="ot">=</span> throwIOWithCallStack</span></code></pre></div>
<p>Finally, new “catch” operations could be introduced providing the
handler access to the exception’s stack:</p>
<div class="sourceCode" id="cb7"><pre class="sourceCode haskell"><code class="sourceCode haskell"><span id="cb7-1"><a href="#cb7-1" aria-hidden="true" tabindex="-1"></a><span class="ot">catchWithLocation ::</span> <span class="dt">IO</span> a <span class="ot">-&gt;</span> (e <span class="ot">-&gt;</span> <span class="dt">Maybe</span> [<span class="dt">Location</span>] <span class="ot">-&gt;</span> <span class="dt">IO</span> a) <span class="ot">-&gt;</span> <span class="dt">IO</span> a</span></code></pre></div>
<p>Above are just two possible designs; I’m sure there are other points
worthy of exploration. Do let me know if you are interesting in picking
up this line of work.</p>
<p>The <a href="20200406-dwarf-4.html">next post</a> will look at using the Linux
<code>perf</code> utility to profile Haskell executables.</p>
<section id="footnotes" class="footnotes footnotes-end-of-document" role="doc-endnotes">
<hr />
<ol>
<li id="fn1"><p>The unfortunate choice of the <code>SIGQUIT</code> 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 <code>SIGQUIT</code> should be used for…
quitting. Do let us know on <a href="https://gitlab.haskell.org/ghc/ghc/issues/17451">#17451</a> if you feel should we should
reconsider the choice to follow Java on this point.<a href="#fnref1" class="footnote-back" role="doc-backlink">↩︎</a></p></li>
</ol>
</section>
]]></description>
    <pubDate>Sun, 05 Apr 2020 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20200405-dwarf-3.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>
<item>
    <title>DWARF support in GHC (part 2)</title>
    <link>http://haskell.org/ghc/blog/20200404-dwarf-2.html</link>
    <description><![CDATA[<h1>DWARF support in GHC (part 2)</h1>
<h4 class="text-muted">Ben Gamari - 2020-04-04</h4>

<p>This post is the second of a series examining GHC’s support for DWARF
debug information and the tooling that this support enables:</p>
<ul>
<li><a href="20200403-dwarf-1.html">Part 1</a> introduces DWARF debugging
information and explains how its generation can be enabled in GHC.</li>
<li><a href="20200404-dwarf-2.html">Part 2</a> looks at a DWARF-enabled program in
<code>gdb</code> and examines some of the limitations of this style of debug
information.</li>
<li><a href="20200405-dwarf-3.html">Part 3</a> looks at the backtrace support of
GHC’s runtime system and how it can be used from Haskell.</li>
<li><a href="20200406-dwarf-4.html">Part 4</a> examines how the Linux <code>perf</code>
utility can be used on GHC-compiled programs.</li>
<li><a href="20200407-dwarf-5.html">Part 5</a> concludes the series by describing
future work, related projects, and ways in which you can help.</li>
</ul>
<h2 id="using-gdb-on-haskell-programs">Using <code>gdb</code> on Haskell programs</h2>
<p><code>gdb</code> is an interactive debugger ubiquitous on Unix systems. Let’s try
using it to run our executable and then break into execution with
<code>Ctrl-C</code>:</p>
<pre><code>$ gdb vector-tests-O0
GNU gdb (GDB) 8.3
...
Reading symbols from dist-newstyle/.../vector-tests-O0...
(gdb) run
Using host libthread_db library &quot;/nix/store/pnd2kl27sag76h23wa5kl95a76n3k9i3-glibc-2.27/lib/libthread_db.so.1&quot;.
Data.Vector.Fusion.Bundle:
  fromList.toList == id: [OK, passed 100 tests]
  toList.fromList == id: [OK, passed 100 tests]
...
  postscanr: [OK, passed 100 tests]
  postscanr&#39;: [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=&lt;optimized out&gt;) at rts/Schedule.c:467
#83 scheduleWaitThread (tso=&lt;optimized out&gt;, 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=&lt;optimized out&gt;, argv=&lt;optimized out&gt;, main_closure=0x14122d0, rts_config=...) at rts/RtsMain.c:72
#86 0x0000000000455df4 in main ()
(gdb) </code></pre>
<p>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
<code>CoArbitraryAll1</code> frames. There are four kinds of symbol names seen
here:</p>
<ol type="1">
<li>C functions provided by the runtime system (e.g. <code>rts_evalLazyIO</code>)</li>
<li>C– functions provided by the runtime system
(e.g. <code>_rts_stgzuupdzuframe_ret</code>)</li>
<li>Haskell functions exported by modules
(e.g. <code>ghczmprim_GHCziClasses_zdfEqBoolzuzdczeze_info</code>)</li>
<li>Haskell functions internal to modules (e.g. <code>s1TRr_info</code>)</li>
</ol>
<p>In cases (2) and (3) the names are derived from source program names via
GHC’s <a href="https://gitlab.haskell.org/ghc/ghc/wikis/commentary/compiler/symbol-names">Z
encoding</a>)
symbol name mangling scheme. For instance,</p>
<div class="table">
<table>
<tbody>
<tr class="odd">
<td style="text-align: left;">mangled</td>
<td style="text-align: left;"><code>ghczmprim_GHCziClasses_zdfEqBoolzuzdczeze_info</code></td>
</tr>
<tr class="even">
<td style="text-align: left;">demangled</td>
<td style="text-align: left;"><code>ghc-prim_GHC.Classes_$fEqBool_$c==_info</code></td>
</tr>
</tbody>
</table>
</div>
<p>In principle <code>gdb</code> could be taught to perform this demangling on our
behalf.</p>
<p>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.</p>
<h3 id="surprises-in-debug-information">Surprises in debug information</h3>
<p>As noted above, GHC backtraces can at times be slightly surprising. To
see why, consider the simple program,</p>
<div class="sourceCode" id="cb2"><pre class="sourceCode haskell"><code class="sourceCode haskell"><span id="cb2-1"><a href="#cb2-1" aria-hidden="true" tabindex="-1"></a><span class="ot">f ::</span> [<span class="dt">Int</span>] <span class="ot">-&gt;</span> <span class="dt">Int</span></span>
<span id="cb2-2"><a href="#cb2-2" aria-hidden="true" tabindex="-1"></a>f <span class="ot">=</span> <span class="fu">sum</span> <span class="op">.</span> <span class="fu">map</span> (<span class="op">*</span> <span class="dv">42</span>)</span></code></pre></div>
<p>The code generated for this function (when compiled with <code>-O</code>) will
inevitably contain a multiplication instruction and an addition
instruction. However, which source location should these be attributed
to <a href="#fn1" class="footnote-ref" id="fnref1" role="doc-noteref"><sup>1</sup></a>? One might say <code>f</code>, or somewhere in <code>Data.List.sum</code>, or
somewhere in <code>foldl</code> (which <code>sum</code> is defined in terms of). Moreover,
these sets of options can grow to be quite large, particularly in cases
where stream fusion is involved.</p>
<p>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 <a href="https://downloads.haskell.org/~ghc/8.10.1-alpha2/docs/html/users_guide/debug-info.html#dw-tag-ghc-src-note">extended DWARF
form</a>
which encodes the entire set of source locations. However, there is
currently widely available tooling which can consume this information.</p>
<p>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 <code>f; g; h</code> means:</p>
<ul>
<li><code>f</code> called <code>g</code></li>
<li><code>g</code> called <code>h</code></li>
<li><code>h</code> is currently executing</li>
</ul>
<p>However, tail calls break this model. For instance, consider the Haskell
function:</p>
<div class="sourceCode" id="cb3"><pre class="sourceCode haskell"><code class="sourceCode haskell"><span id="cb3-1"><a href="#cb3-1" aria-hidden="true" tabindex="-1"></a><span class="ot">tail_caller ::</span> [<span class="dt">Int</span>] <span class="ot">-&gt;</span> <span class="dt">Int</span></span>
<span id="cb3-2"><a href="#cb3-2" aria-hidden="true" tabindex="-1"></a>tail_caller xs <span class="ot">=</span> <span class="fu">sum</span> xs</span>
<span id="cb3-3"><a href="#cb3-3" aria-hidden="true" tabindex="-1"></a></span>
<span id="cb3-4"><a href="#cb3-4" aria-hidden="true" tabindex="-1"></a><span class="fu">sum</span><span class="ot"> ::</span> [<span class="dt">Int</span>] <span class="ot">-&gt;</span> <span class="dt">Int</span></span>
<span id="cb3-5"><a href="#cb3-5" aria-hidden="true" tabindex="-1"></a><span class="fu">sum</span> xs <span class="ot">=</span> foldl&#39; (<span class="op">+</span>) <span class="dv">0</span> xs</span></code></pre></div>
<p>Without optimisation, the code generated for <code>tail_caller</code> will simply
jump straight to the entry-point of <code>sum</code>; no stack entry will be left
to mark the fact that <code>sum</code> was called by <code>tail_caller</code>. 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.</p>
<h3 id="breakpoints">Breakpoints</h3>
<p>In addition to printing backtraces, we can also set breakpoints:</p>
<pre><code>(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=&lt;optimized out&gt;) at rts/Schedule.c:467
#6  scheduleWaitThread (tso=&lt;optimized out&gt;, 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=&lt;optimized out&gt;, argv=&lt;optimized out&gt;, main_closure=0x14122d0, rts_config=...) at rts/RtsMain.c:72
#9  0x0000000000455df4 in main ()</code></pre>
<p>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).</p>
<p>In the <a href="20200405-dwarf-3.html">next post</a> we will see how we can use
GHC’s native unwinding support to gather stack traces from within
Haskell programs.</p>
<section id="footnotes" class="footnotes footnotes-end-of-document" role="doc-endnotes">
<hr />
<ol>
<li id="fn1"><p>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
<a href="http://etheses.whiterose.ac.uk/8321/">dissertation</a>. I would
encourage anyone interested to peruse Chapter 4 of this very
readable work.<a href="#fnref1" class="footnote-back" role="doc-backlink">↩︎</a></p></li>
</ol>
</section>
]]></description>
    <pubDate>Sat, 04 Apr 2020 00:00:00 UT</pubDate>
    <guid>http://haskell.org/ghc/blog/20200404-dwarf-2.html</guid>
    <dc:creator>ghc-devs</dc:creator>
</item>

    </channel>
</rss>
