- ghc-releases - Haskell.org

GHC 9.6.7 rc2 available
by Luite Stegeman 13 Feb '25

13 Feb '25

The GHC developers are very pleased to announce the availability of the second release candidate of GHC 9.6.7. Binary distributions, source distributions, and documentation are available at https://downloads.haskell.org/ghc/9.6.7-rc2 We hope to have this release available via ghcup shortly. Haskell Language Server does not yet build with GHC 9.6.7. See the note below. If all goes according to plan, we expect that the final release of GHC 9.6.7 will be available on February 28. Release candidate 2 contains the following changes relative to (the unannounced) release candidate 1: - the symbol atomic_inc64 is no longer exported from the RTS GHC 9.6.7 will bring a number of fixes, including: - GHC’s internal Unique type has been widened to 64-bits on 32-bit architectures, avoiding potential miscompilations on large projects. - Fix a runtime crash when using the compacting GC, caused by black holes in large objects. - Added new flags -fspec-eval and -fspec-eval-dictfun to allow switching off speculative evaluation. The following libraries have been updated since GHC 9.6.6: - base-4.18.3.0 (the version number in the rc2 release notes is incorrect) - filepath-1.4.301.0 - unix-2.8.6.0 - bytestring-0.11.5.4 - array-0.5.8.0 A more detailed description can be found in the [release notes] and a full list of changes in [GHC!13841] and [GHC!13891] Note about Haskell Language Server and building GHC 9.8+: The change of Unique to 64 bit [GHC#22010] adds the exported symbol ghc_unique_counter64 to the RTS. Unfortunately it's impossible to avoid this without breaking other things. If you encounter a linker error related to ghc_unique_counter64 when building GHC (or building a GHC-derived package like ghc-lib-parser) with GHC 9.6.7, you probably have to add this [fix] to the program you're building. At the time of writing all released GHC 9.8 versions are affected, as well as the latest version of ghc-lib-parser-9.8 on hackage (which is a dependency of Haskell Language Server). We would like to thank GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, the Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. Please give this release candidate a try and open a [ticket] if you see anything amiss. ~ Luite [release notes]: https://downloads.haskell.org/ghc/9.6.7-rc2/docs/users_guide/9.6.7-notes.ht… [GHC!13841]: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/13841 [GHC!13891]: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/13891 [GHC#22010]: https://gitlab.haskell.org/ghc/ghc/-/issues/22010 [fix] https://gitlab.haskell.org/ghc/ghc/-/merge_requests/13743 [ticket] https://gitlab.haskell.org/ghc/ghc/-/issues/new

1 0

Providing feedback on Glasgow Haskell Compiler release practices
by Ben Gamari 21 Jan '25

21 Jan '25

Hello GHC distributors and testers, Over the last few months we have been evaluating the GHC's policies with respect to release management and communications. Together with a small group of stakeholders, we have put together a document [1] which seeks to more precisely record we GHC releases are prepared, communicated, and released. As GHC distributors, we would love to hear your thoughts on how we can make your lives easier. It would be appreciated if you could review the document and leave your comments on the merge request. Thank you for all of your work in bringing functional programming to the masses. Cheers, - Ben [1] https://gitlab.haskell.org/ghc/ghc-hq/-/merge_requests/38

1 0

PSA: Correctness issue in GHC-9.12.1
by Andreas Klebinger 15 Jan '25

15 Jan '25

Today a bug in 9.12.1 was reported and confirmed (#25653) which can lead to incorrect runtime results in compiled programs. In particular this seems to happen for sub-word divisions with a known divisor when optimizations are enabled and affects at least the x86 backend, although it’s likely that other backends are also affected. We plan to release a bug fix release 9.12.2 in the near future to address this issue and recommend people do not upgrade until then.

1 0

GHC 9.10.2 preparation
by Ben Gamari 20 Dec '24

20 Dec '24

Hi all, Preparations are currently underway on GHC 9.10.2. We currently have roughly 100 commits backported with another few dozen backport candidates. If you have a merge request which you want to be backported please do make sure it bears the ~"backport needed:9.10" label. Additionally, we plan on performing the following boot library version bumps: Cabal 3.12.0.0 -> 3.12.1.0 Cabal-syntax 3.12.0.0 -> 3.12.1.0 bytestring 0.12.1.0 -> 0.12.2.0 array 0.5.7.0 -> 0.5.8.0 deepseq 1.5.0.0 -> 1.5.1.0 directory 1.3.8.3 -> 1.3.9.0 filepath 1.5.2.0 -> 1.5.4.0 hpc 0.7.0.1 -> 0.7.0.2 process 1.6.19.0 -> 1.6.25.0 text 2.1.1 -> 2.1.2 unix 2.8.5.1 -> 2.8.6.0 exceptions 0.10.7 -> 0.10.9 Win32 2.14.0.0 -> 2.14.1.0 Naturally, if we find that any of these upgrades could cause significant ecosystem disruption then we may reconsider and notify the list. If things go according to plan, we expect that a prerelease will be ready by mid-January 2025, with a final release coming a few weeks later. Naturally, we will continue to report status updates on the tracking ticket [1] and will keep ghc-releases apprised if plans change. Cheers, - Ben [1] https://gitlab.haskell.org/ghc/ghc/-/issues/25433

1 0

GHC 9.6.7 plans
by Luite Stegeman 18 Dec '24

18 Dec '24

Hi all, I am currently in the process of preparing ghc-9.6.7 [1]. I'm planning for a release candidate to be ready on December 21st. If you need anything included that's not already listed, please reply in this thread or leave a comment in the tracking ticket [2], and apply the ~"backport needed:9.6" label. Already backported: * !13692: (setNumCapabilities: Assert that n_caps < MAX_N_CAPS) * !13618: rts/linker: Fix out-of-bounds mapping logic * !13544: DmdAnal: Make prompt# lazy (#25439 (closed)) * !13431: rts: fix pointer overflow undefined behavior in bytecode interpreter * !13371: Consider Wanteds with rewriters as not-insoluble * !13337: configure: Fix C++ probing when GCC version is the latest but G++ is old #23118 * !13276: Fix interaction between fork and kqueue (#24672 (closed)) * !13196: driver: Fix -working-dir for foreign files * !13151: JS: support rubbish static literals (#25177 (closed)) * !13113: AARCH64 linker: skip NONE relocations * !13096: Cmm: don't perform unsound optimizations on 32-bit compiler hosts (#24893 (closed) #24700 (closed)) * !13085: driver: Fix -Wmissing-home-modules when multiple units have the same module name * !13070: Only lookup ghcversion.h file in the RTS include-dirs by default. ( f954f428 ) * !13038: Address #25055 (closed), by disabling case-of-runRW# in Gentle phase * !13010: Linker: Add windows R_X86_64_PC64 relocation support * !12990: Fix -freg-graphs for FP and AARch64 NCG (#24941 (closed)). * !12975: X86 NCG: Fix argument promotion in foreign C calls ( a82121b3 ) * !12914: Linker: use m32 allocator for sections when NEED_PLT (#24432 (closed)) * !12748: rts: fix checkClosure error message * !12484: compiler: Fingerprint -fwrite-if-simplified-core * !12416: Don't generate wrappers for type data constructors with StrictData * !12201: RTS: Emit warning when -M < -H * !11989: Fix ffi callbacks with >6 args and non-64bit args. * !11777: GHCi: fix improper location of ghci_history file * !10520: Update rdt-theme to latest upstream version * !10436: rts: fix --disable-large-address-space * !10384: Simplify code and allow more optimisation on linearly typed code * !11878: release-ci: remove release-x86_64-linux-deb11-release+boot_nonmoving_gc job In progress: * !13524: hadrian: Bump directory bound to >=1.3.9 * !13252: Bump submodule array to 0.5.8.0 * !11020: Update Haddock submodule to fix #23368 * 13624: Widen uniques to 64 bit. Luite [1] https://gitlab.haskell.org/ghc/ghc/-/merge_requests/13740 [2] https://gitlab.haskell.org/ghc/ghc/-/issues/25559

1 0

GHC 9.12.1 is now available
by Zubin Duggal 16 Dec '24

16 Dec '24

The GHC developers are very pleased to announce the release of GHC 9.12.1. Binary distributions, source distributions, and documentation are available at [downloads.haskell.org][]. We hope to have this release available via ghcup shortly. GHC 9.12 will bring a number of new features and improvements, including: * The new language extension [OrPatterns] allowing you to combine multiple pattern clauses into one. * The [MultilineStrings] language extension to allow you to more easily write strings spanning multiple lines in your source code. * Improvements to the OverloadedRecordDot extension, allowing the built-in `HasField` class to be used for records with fields of non lifted representations. * The [NamedDefaults] language extension has been introduced allowing you to define defaults for typeclasses other than `Num`. * More deterministic object code output, controlled by the `-fobject-determinism` flag, which improves determinism of builds a lot (though does not fully do so) at the cost of some compiler performance (1-2%). See #12935 for the details * GHC now accepts type syntax in expressions as part of [GHC Proposal #281]. * The WASM backend now has support for TemplateHaskell. * Experimental support for the RISC-V platform with the native code generator. * ... and many more A full accounting of changes can be found in the [release notes][]. As always, GHC's release status, including planned future releases, can be found on the GHC Wiki [status][]. We would like to thank GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, the Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do give this release a try and open a [ticket][] if you see anything amiss. [release notes]: https://downloads.haskell.org/ghc/9.12.1/docs/users_guide/9.12.1-notes.html [status]: https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status [downloads.haskell.org] https://downloads.haskell.org/ghc/9.12.1 [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [OrPatterns]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0522-o… [MultilineStrings]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0569-m… [GHC Proposal #281]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0281-v… [NamedDefaults]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0409-e…

2 3

GHC 9.8.4 is now available
by Ben Gamari 03 Dec '24

03 Dec '24

The GHC developers are happy to announce the availability of GHC 9.8.4. Binary distributions, source distributions, and documentation are available on the [release] page. This release is a small release fixing a few issues noted in 9.8.3, including: * Update the `filepath` submodule to avoid a misbehavior of `splitFileName` under Windows. * Update the `unix` submodule to fix a compilation issue on `musl` platforms * Fix a potential source of miscompilation when building large projects on 32-bit platforms * Fix unsound optimisation of `prompt#` uses A full accounting of changes can be found in the [release notes]. As some of the fixed issues do affect correctness users are encouraged to upgrade promptly. We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do give this release a try and open a [ticket] if you see anything amiss. Happy compiling! - Ben [release]: https://www.haskell.org/ghc/download_ghc_9_8_4.html [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [release notes]: https://downloads.haskell.org/~ghc/9.8.4/docs/users_guide/9.8.4-notes.html

1 0

GHC 9.8.4 release status
by Ben Gamari 02 Dec '24

02 Dec '24

Hi all, After several false-starts, I believe we now have a candidate pipeline [1] for the 9.8.4 release. This includes bumps to the unix and filepath submodules, a few compiler correctness fixes, and some documentation packaging improvements. Do let me know if there are any questions or concerns, otherwise I will move ahead with release mid-next week. Cheers, - Ben [1] https://gitlab.haskell.org/ghc/ghc/-/pipelines/103556

2 4

[ANNOUNCE] GHC 9.12.1-rc1 is now available
by Zubin Duggal 29 Nov '24

29 Nov '24

The GHC developers are very pleased to announce the availability of the release candidate for GHC 9.12.1. Binary distributions, source distributions, and documentation are available at [downloads.haskell.org][]. We hope to have this release available via ghcup shortly. GHC 9.12 will bring a number of new features and improvements, including: * The new language extension [OrPatterns] allowing you to combine multiple pattern clauses into one. * The [MultilineStrings] language extension to allow you to more easily write strings spanning multiple lines in your source code. * Improvements to the OverloadedRecordDot extension, allowing the built-in `HasField` class to be used for records with fields of non lifted representations. * The [NamedDefaults] language extension has been introduced allowing you to define defaults for typeclasses other than `Num`. * More deterministic object code output, controlled by the `-fobject-determinism` flag, which improves determinism of builds a lot (though does not fully do so) at the cost of some compiler performance (1-2%). See #12935 for the details * GHC now accepts type syntax in expressions as part of [GHC Proposal #281]. * The WASM backend now has support for TemplateHaskell. * ... and many more A full accounting of changes can be found in the [release notes][]. As always, GHC's release status, including planned future releases, can be found on the GHC Wiki [status][]. We would like to thank GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, the Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do give this release a try and open a [ticket][] if you see anything amiss. Cheers, Zubin [release notes]: https://downloads.haskell.org/ghc/9.12.1-rc1/docs/users_guide/9.12.1-notes.… [status]: https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status [downloads.haskell.org] https://downloads.haskell.org/ghc/9.12.1-rc1 [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [OrPatterns]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0522-o… [MultilineStrings]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0569-m… [GHC Proposal #281]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0281-v… [NamedDefaults]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0409-e…

1 0

Re: [GHC-Releases] Feedback on potential change in boot library
by Sebastian Graf 27 Nov '24

27 Nov '24

Hi, Do we have concrete evidence that minor bumps in a boot library have caused breakage in the past? (That would of course be a bug in the boot library according to the PVP.) I would think that such breakage is even less of an issue for a new GHC minor release (say GHC 9.8.4). The hackage ecosystem is likely prepared to compile with the GHC 9.8 series at this point, so it should be possible to detect such breakages by compiling stackage/hackage and running testsuites. That is, I would think it is harder to anticipate unforeseen boot library breakage for a new major release of GHC than it is to anticipate breakage for a minor GHC release. Besides, the only reliable way to prevent such breakage is not to bump any boot library *at all*. If a boot library breaks on a minor bump, it is just as likely that it breaks on a super-minor bump. So bumping minor versions of boot library sounds reasonable to me, barring concrete evidence that minor bumps have caused problems in the past (which again means there was a bug in a boot library). Sebastian ------ Originalnachricht ------ Von "Tom Ellis" <tom-lists-haskell-cafe-2023(a)jaguarpaw.co.uk> An ghc-devs(a)haskell.org Datum 27.11.2024 10:57:57 Betreff Re: Feedback on potential change in boot library >Thanks Adam, > >I'm not too familiar with the GHC-side requirements here, but I wonder >if we can approach this issue from a different direction: is there >something we can do to help boot libraries avoid breaking changes? > >Tom > > >On Wed, Nov 27, 2024 at 08:02:10AM +0000, Adam Gundry wrote: >> It's not obvious to me that this is a good idea. Users already complain that >> "upgrading GHC broke my code", when in practice this frequently means "when >> upgrading GHC I used new boot library versions with incompatible APIs that >> broke my code". So having a policy of introducing more frequent API changes >> (and making it harder to switch between GHC releases in a single release >> series) needs clear justification IMHO. >> >> (Of course in the long term we should make it easier for users to pin boot >> library APIs while upgrading GHC independently, but we're not there yet.) >> >> I think that by default, it makes sense for a new minor GHC release to keep >> the same API versions of boot libraries, but bump to the latest super-minor >> component (i.e. for an A.B.C.D version, keep A.B.C the same but bump D). If >> a boot library fixes a bug that is critical enough to require bumping the >> version distributed with GHC, ideally there would be an API-compatible >> release of the boot library. Of course that might not always be feasible, >> and it is ultimately a judgement call for the GHC maintainers as to which >> boot library versions are best to ship. >> >> On 26/11/2024 22:27, Hécate via ghc-devs wrote: >> > From the cabal perspective this great news, as this will allow the >> > feedback cycle between our two projects to be shorter. Glad to see the >> > GHC team is considering this! >> > >> > Cheers, >> > Hécate >> > >> > Le 26/11/2024 à 21:14, Ben Gamari a écrit : >> > > tl;dr. We propose that GHC more aggressively bump its boot library >> > > dependencies. >> > > >> > > >> > > Hello all, >> > > >> > > Historically, GHC minor releases have been quite conservative in bumping >> > > boot library versions, generally defaulting to retaining the versions >> > > used in the GHC-x.y.1 release unless >> > > >> > > * a request is made by a boot library maintainer, or >> > > * we discover an issue which warrants a bump >> > > >> > > The motivation for this policy is both to >> > > >> > > * minimize the potential for regressions in correctness and >> > > performance, and >> > > >> > > * reduce the potential for end-user breakage due to interface changes >> > > as even minor releases can result in considerable impact (e.g. >> > > #25411, #22633) >> > > >> > > While this policy has served us well, its conservative nature demands >> > > the vigilence of both GHC and upstream maintainers to ensure that bumps >> > > that are truly necessary do not fall through the cracks. >> > > >> > > As the flaws of this process have been more apparent recently (e.g. >> > > #24597), we have done a bit of reflection on how we might improve the >> > > status quo. Concretely, I would like feedback on the adopting the >> > > following policy going forward: >> > > >> > > > Unless guidance is provided otherwise by a library maintainer, a GHC >> > > > x.y.z release will attempt to ship the newest minor version of each >> > > > boot libray in the same major series shipped with GHC x.y.1. >> > > I believe this policy would leave less room for human error and open >> > > opportunities for automated checking. On the other hand, the more >> > > aggressive bumping of submodules may mean that users are hit with more >> > > (usually minor) compatibility issues when moving between minor GHC >> > > releases. >> > > >> > > How do others feel about this? We are particularly interested to hear >> > > from boot library maintainers but feedback from packagers and users is >> > > also very much welcome. >_______________________________________________ >ghc-devs mailing list >ghc-devs(a)haskell.org >http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

2 1