September 2026 - ghc-devs

Very very slow Hadrian
by Simon Peyton Jones 28 Sep '26

28 Sep '26

Friends Is it my imagination or has Hadrian become a LOT slower? I am trying to run a single test, thus: hadrian/build -j6 \ --flavour=perf+no_profiled_libs+ticky_ghc \ test \ --skip=_build/stage0/** \ --skip=_build/stage1/** \ --skip=_build/stage1/rts/** \ --skip=_build/stage1/libraries/** \ --skip=_build/stage1/utils/** \ --docs=none \ --only=ClassOperator This takes 70 seconds, of which almost all is spent with Hadrian saying stuff below *Something must be wrong! * Seventy seconds to run one test! Then to accept the new output is another 70 seconds. If I have a couple of dozen test-output wibbles to fix, that adds up to a lot of time. Simon ]0;Starting...(/home/simonpj/code/HEAD-31) ]0;Running for 5s [119/38037], predicted 264m08s (0%)(/home/simonpj/code/HEAD-31) ]0;Running for 10s [8853/38038], predicted 36m59s (0%)(/home/simonpj/code/HEAD-31) ]0;Running for 15s [12109/38038], predicted 9m46s (2%)(/home/simonpj/code/HEAD-31) ]0;Running for 20s [13119/38038], predicted 7m03s (4%)(/home/simonpj/code/HEAD-31) ]0;Running for 25s [13879/38038], predicted 7m19s (5%)(/home/simonpj/code/HEAD-31) ]0;Running for 30s [14485/38038], predicted 6m58s (6%)(/home/simonpj/code/HEAD-31) ]0;Running for 35s [15338/38038], predicted 6m06s (8%)(/home/simonpj/code/HEAD-31) ]0;Running for 40s [16434/38038], predicted 2m56s (17%)(/home/simonpj/code/HEAD-31) ]0;Running for 45s [20588/38038], predicted 3m32s (16%)(/home/simonpj/code/HEAD-31) ]0;Running for 50s [26354/38038], predicted 63m21s (1%)(/home/simonpj/code/HEAD-31) ]0;Running for 55s [30040/38038], predicted 49m36s (1%)(/home/simonpj/code/HEAD-31) ]0;Running for 1m00s [35123/38038], predicted 19m59s (4%)(/home/simonpj/code/HEAD-31) # ghc

3 2

Currently no native x86_64 darwin runner
by Magnus Viernickel 25 Sep '26

25 Sep '26

Dear GHC Devs, Alpha, our beloved native x86_64 darwin (MacOS) runner has perished. From my perspective, this is final since I cannot touch the system and all remote trouble shooting seems to point me at its demise. A potential touching of the system of a third party may make it come back. The only workflow affected is test-primops x86_64 darwin. I have switched that to use emulation via rosetta for now (run on our aarch64-darwin runners). If you think this is a bad idea, please contact me. There also was a few minutes of downtime yesterday and today because I applied a critical security patch to gitlab. (path traversal vulnerability, aka ../) Best Magnus

1 0

GHC 10.0.1-alpha1 is now available
by Zubin Duggal 20 Sep '26

20 Sep '26

The GHC developers are very pleased to announce the availability of the first alpha prerelease of GHC 10.0.1. Binary distributions, source distributions, and documentation are available at [downloads.haskell.org][] and via [GHCup](https://www.haskell.org/ghcup/). GHC 10.0 will bring a number of new features and improvements, including: * The default language edition is now `GHC2024` ([GHC Proposal #632][ghc2024], #26039). * `Type` and `Constraint` are now completely distinct types, just as much as `Int` and `Bool` (#24279). * The new [QualifiedStrings][] language extension ([GHC Proposal #723][qualified-strings]) allows string literals to be qualified using module qualification syntax, so that `M."my string"` desugars to`M.fromString "my string"`. * The treatment of static forms has been simplified, implementing [GHC Proposal #732][static-forms] (#26556). The free term variables of `(static e)` must now be bound at top level. * `-fpolymorphic-specialisation` is now (re)enabled by default (#23559), * Bytecode can now be written to disk with `-fwrite-byte-code` and packaged into bytecode libraries with `-bytecodelib`, which the interpreter can use to satisfy package dependencies (#26298). * Executables can now be properly statically linked with the new `-fully-static` and `-static-external` flags (#26434). * SIMD support in the AArch64 native code generator (#26536). * A new `poll` I/O manager, which is now the default in the single-threaded RTS on all POSIX platforms except macOS (!9677). * Version 2 of the [GHC Jobserver Protocol][jsem] for GHC's `-jsem` jobserver on Linux and other POSIX platforms (#25087, #27253). This is sadly a necessary breaking change. `-jsem` requires cabal-install 3.18 or later, and is otherwise ignored with a warning, falling back to sequential compilation. * Changes to `base`: * `GHC.Num.{BigNat,Integer,Natural}` are no longer exposed ([CLC #359][clc-359]) and GHC internals in `GHC.Num` are deprecated ([CLC #360][clc-360]). * `Data.List.init` and `Data.List.last` now carry an `x-partial` warning ([CLC #292][clc-292]). * The minimum bootstrap compiler is now GHC 9.10, LLVM versions up to 23 are supported (#26813, #27764), and the Debian 9, Debian 10, Ubuntu 18.04 and Ubuntu 20.04 bindists have been dropped in favour of a new Debian 13 bindist (#25876). * ... and many more A full accounting of changes can be found in the [release notes][]. See the [migration guide][] for guidance on migrating programs to this release. As always, GHC's release status, including planned future releases, can be found on the GHC Wiki [status][]. Given the many changes in this major release, we would very much appreciate testing on downstream workloads. GHC development is sponsored by: * [Juspay](https://juspay.com/) * [QBayLogic](https://qbaylogic.com/) * [Channable](https://www.channable.com/) * [Haskell Foundation](https://haskell.foundation/) * [Serokell](https://serokell.io/) * [Well-Typed](https://well-typed.com/) * [Tweag](https://www.tweag.io/) * [Dotcom-Monitor](https://www.dotcom-monitor.com/) * [LoadView](https://www.loadview-testing.com/) * [Web Hosting Buddy](https://webhostingbuddy.com/) * [Find My Electric](https://www.findmyelectric.com/) * [Standard Chartered](https://www.sc.com) * [UpCloud](https://upcloud.com) * [Mercury](https://mercury.com) We would like to thank these sponsors and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do give this release a try and open a [ticket][] if you see anything amiss. [downloads.haskell.org] https://downloads.haskell.org/ghc/10.0.1-alpha1 [release notes]: https://downloads.haskell.org/ghc/10.0.1-alpha1/docs/users_guide/10.0.1-not… [migration guide]: https://gitlab.haskell.org/ghc/ghc/-/wikis/migration/10.0 [status]: https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [ghc2024]: https://github.com/ghc-proposals/ghc-proposals/pull/632 [static-forms]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0732-s… [QualifiedStrings]: https://downloads.haskell.org/ghc/10.0.1-alpha1/docs/users_guide/exts/quali… [qualified-strings]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0723-q… [jsem]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0540-j… [clc-292]: https://github.com/haskell/core-libraries-committee/issues/292 [clc-359]: https://github.com/haskell/core-libraries-committee/issues/359 [clc-360]: https://github.com/haskell/core-libraries-committee/issues/360

2 1

GHC 9.14.2-rc2 is now available
by Zubin Duggal 17 Sep '26

17 Sep '26

The GHC developers are very pleased to announce the availability of the second release candidate for GHC 9.14.2. Binary distributions, source distributions, and documentation are available at [downloads.haskell.org][] and via [GHCup](https://www.haskell.org/ghcup/). See also the [previous announcement of 9.14.2-rc1][rc1]. The changes since the first release candidate are: * Several fixes to the specialiser and demand analyser for miscompilations causing incorrect runtime results, crashes, or hangs (#27626, #27627, #27629, #27703, #27704, #27705, #27717). * Fixes for a number of runtime system bugs: * a missing memory barrier in the parallel garbage collector, which could crash or silently corrupt the heap on weakly-ordered architectures such as AArch64 (#27477). * a use-after-free with TSOs (#26716, #26717). * an "unknown/strange object" crash in the compacting collector when collecting the large data constructors that the bytecode interpreter allocates (#27649). * a segfault when querying the label of an unlabelled thread (#27618). * a crash when capturing or resuming a delimited continuation that adjusts the asynchronous exception masking state (#27651). * stack corruption when returning large unboxed tuples in GHCi (#27633). * Further fixes to the AArch64 native code generator, addressing bugs that caused incorrect runtime results from subword operations (#27430, #27533, #27537, #27538, #27539, #27550). * `toException` for `SomeException` no longer drops the attached `ExceptionContext`, and a `catchSTM` handler no longer breaks `retry` or asynchronous exception delivery (#27455, #27657). * Reduced memory usage with multiple home units (#26423, #27308, #27500, #27748). * Fixes for panics and spurious out-of-scope errors involving type arguments in pattern synonym right-hand sides (#27440, #27583, #27586). * The pattern-match checker now recognises `considerAccessible` under ticks, and no longer emits a spurious `-Wincomplete-uni-patterns` warning under `-finfo-table-map` (#27314, #27360). * The deprecation warning for static forms, added in rc1, no longer fires on free type variables (#27664). * A fix for a regression preventing modules from being loaded into GHCi after startup (#27202, #27640). * A fix for representation-polymorphism checks producing a coercion that fails Core Lint (#27639). * Support for LLVM up to version 23 (#27764). * Updates for libffi (3.8.0), `directory` (1.3.11.0), `file-io` (0.1.6), `haskeline` (0.8.5.0) and `os-string` (2.0.10). GHC 9.14.2 is a bug-fix release fixing many issues of a variety of severities and scopes, including: * Version 2 of the [GHC Jobserver Protocol][jsem] for GHC's `-jsem` jobserver on Linux and other POSIX platforms (#25087, #27253). This is sadly a necessary breaking change: `-jsem` requires cabal-install 3.18 or later, and is otherwise ignored with a [warning][jsem-warning], falling back to sequential compilation. * A new deprecation warning for static forms that mention nested let-bound variables. This will become an error in GHC 10.0 ([GHC Proposal #732][static-forms], #26718). * A fix for a CorePrep miscompilation that could project a field out of an absent dictionary, resulting in a segfault (#25924). * A fix for demand analysis giving an absent demand to an argument that was still used by the function's stable unfolding, which could cause a runtime crash (#26416). * Numerous fixes for register allocation and Cmm register-conflict analysis bugs, preventing incorrect code generation and corruption of vector registers when spilling and reloading (#26411, #26526, #26537, #26542, #26550, #26668). * Many NCG fixes on AArch64: `MOVK` clobbering live values (#26980), register clobbering and an incorrect overflow bit in `MUL2` (#27046, #27047), and incorrect sign extension (#26978) and unsigned right shift (#26979) at subword widths. * A fix for a stack alignment bug on x86 that could cause segfaults or corrupted registers when using AVX/AVX-512 vector code (#26595, #26822). * Fixes for several black hole handling bugs that could lead to deadlocks or crashes in multithreaded programs, showing up as hangs or "END_TSO_QUEUE object entered" errors (#26922, #26936). * Fixes for many other runtime system crashes and races (#26341, #26573, #26640, #27007, #27008, #27009, #27082). * A fix for an "unknown/strange object" crash in the compacting garbage collector (#27434). * Fixes for split sections on Windows (#26696, #26494) and the LLVM backend (#26770). * Fixes for the Wasm backend (#26916, #27257), and the RISC-V (#27300, #27303, #27306) and PowerPC (#23969, #24145, #26828) native code generators. * The JavaScript backend now supports more than 128 registers, fixing runtime `ReferenceError` failures for functions taking very many arguments (#26558). * Correctness and performance improvements in the bytecode interpreter (#12953, #26287, #26946, #26995, #27001). * Fixes for several compiler panics, including issues with SetLevels (#26681), the type-class specialiser (#26682), `mkTick` (#26772, #27121), CoreToStg (#27182, #27386), the pattern-match checker (#25926, #27124), module graph reachability (#26568), and continuation trimming for bottoming functions (#27261). * Fixes for several cases where the compiler could hang or loop, including with negative type literals (#26861), deep subsumption (#26823), and when simplifying the right-hand sides of rewrite rules (#26323, #26826). * A fix for cast worker/wrapper incorrectly firing on INLINE functions (#26903). * A fix for exponential-time desugaring of nested `case` expressions (#27383, #20251). * A fix for a regression that caused overloaded functions to no longer be specialised as effectively as in previous releases, hurting runtime performance (#26831). * A fix for associated type family and data family instance changes not triggering recompilation (#26183, #26705). * Fixes for Explicit Level Imports and Template Haskell staging (#26088, #26098, #26099, #26616, #27385). * Improvements to determinism of compiler output, including the order in which `:info` lists instances (#26846, #26858, #26877, #27532). * Additions for GHCi and GHC API users: the `-fimport-loaded-targets` flag (#26866), custom external interpreter commands (#26652), `decodeStackWithIpe` and related stack-decoding helpers (#27065), an optional `SrcLoc` on `StackAnnotation` (#26806), and a `gc_sync_elapsed_ns` counter in `RTSStats` (#26944). * ... and many more. A full accounting of these fixes can be found in the [release notes][]. As always, GHC's release status, including planned future releases, can be found on the GHC Wiki [status][]. This release candidate will have a two-week testing period. If all goes well the final release will be available the week of 1 October 2026. GHC development is sponsored by: * [Juspay](https://juspay.com/) * [QBayLogic](https://qbaylogic.com/) * [Channable](https://www.channable.com/) * [Haskell Foundation](https://haskell.foundation/) * [Serokell](https://serokell.io/) * [Well-Typed](https://well-typed.com/) * [Tweag](https://www.tweag.io/) * [Dotcom-Monitor](https://www.dotcom-monitor.com/) * [LoadView](https://www.loadview-testing.com/) * [Web Hosting Buddy](https://webhostingbuddy.com/) * [Find My Electric](https://www.findmyelectric.com/) * [Standard Chartered](https://www.sc.com) * [UpCloud](https://upcloud.com) * [Mercury](https://mercury.com) We would like to thank these sponsors and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do give this release a try and open a [ticket][] if you see anything amiss. [release notes]: https://gitlab.haskell.org/ghc/ghc/-/blob/ghc-9.14/docs/users_guide/9.14.2-… [status]: https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status [downloads.haskell.org] https://downloads.haskell.org/ghc/9.14.2-rc2 [jsem]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0540-j… [static-forms]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0732-s… [jsem-warning]: https://downloads.haskell.org/ghc/9.14.2-rc2/docs/users_guide/using-warning… [rc1]: https://www.haskell.org/ghc/blog/20260730-ghc-9.14.2-rc1-released.html [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new

1 0

short downtime to revert a bug in gitlab-registry
by Magnus Viernickel 15 Sep '26

15 Sep '26

Dear GHC Devs, looks like we pulled in a bug when I recently updated gitlab for security reasons. I hope to revert it, which will cause a few minutes of downtime. Best Magnus

1 1

Re: GHC LLM policy vs copyright
by Carter Schonwald 15 Sep '26

15 Sep '26

yes, because code is math, and sometimes theres only one proof, and copyright doesnt protect factual stuff just the ultra soecific exact sentence (except when its literally the only sane way to say soemthing). there is a huge amount of law / case law / history for how this works, and fortunately literally here means verbatim naively these two remarks sound contradictory, but its really a reflection of the anthropogenic complexity of humanity On Tue, Sep 1, 2026 at 1:56 PM <code(a)jaro.addy.io> wrote: > If you define “exact literal content” so broadly as to allow for > translations > of prose, why wouldn't it also apply to translating software to different > languages or using different naming conventions and other minor code style > elements? > > On 9/1/26 19:50, Carter Schonwald 'carter.schonwald at gmail.com' wrote: > > translations are explicitly reusing the exact literal content, and > theres > > explicitly carve outs in modern law around translated works > > > > > > math and food recipes are explicitly not protected by copyright law. > > > > i hope that helps clarify? > > > > On Tue, Sep 1, 2026 at 1:41 PM <code(a)jaro.addy.io <mailto: > code(a)jaro.addy.io>> > > wrote: > > > > > building dimilar code for a similar task in a > > > different language is definitely not infringing unless its also > copying > > all > > > the text from the source application like some sort of text rpg. > > What if we compare this to literature? Surely a translation of a > book into > > another language is still considered a derivative work, even if it > reuses none > > of the “literal text”. > > > > >

3 3

Bootstrapping GHC 9.14.2-rc1 with GHC-9.12.4?
by Viktor Dukhovni 14 Sep '26

14 Sep '26

When trying to build GHC 9.14.2-rc1 with GHC 9.12.4 as the boot compiler the build failed due to a missing "Binary" instance for "HalfWord". I see that Ben Gamari already had to implement a work-around for this: commit b965fa766c6bdf1bf3c8be63a6187e1100051599 Author: Ben Gamari <bgamari.foss(a)gmail.com> Date: Sat Oct 4 11:45:32 2025 -0400 ghci: Fix CPP guarding Binary HalfWord instance diff --git a/libraries/ghci/GHCi/Message.hs b/libraries/ghci/GHCi/Message.hs index 072f46cd32..c731d33e31 100644 --- a/libraries/ghci/GHCi/Message.hs +++ b/libraries/ghci/GHCi/Message.hs @@ -522,7 +522,7 @@ instance Binary (FunPtr a) where put = put . castFunPtrToPtr get = castPtrToFunPtr <$> get -#if MIN_VERSION_ghc_internal(9,1500,0) +#if MIN_VERSION_ghc_internal(9,1400,0) instance Binary Heap.HalfWord where put x = put (fromIntegral x :: Word32) get = fromIntegral <$> (get :: Get Word32) I had to further reduce this from 1400 to 1204. -- Viktor. 🇺🇦 Слава Україні!

2 2

Windows CI runner sponsorship extended
by Bryan Richter 09 Sep '26

09 Sep '26

Hi folks, For the last year, UpCloud (https://upcloud.com/) through the Haskell Foundation, has donated credits on their platform for two Windows CI runners. I'm happy to report that they've just extended the sponsorship for another year, i.e. until October 2027. -Bryan

1 0

Test failure
by Simon Peyton Jones 09 Sep '26

09 Sep '26

Friends On https://gitlab.haskell.org/ghc/ghc/-/merge_requests/16447 I'm getting a mysterious failure in the testsuite. The error, below, is not very informative. Can anyone help, please? Thanks Simon Build failed. hadrian/build-cabal --flavour=release -j4 --broken-test= --bignum=gmp test --summary-junit=./junit.xml --test-have-intree-files --test-compiler=/builds/ghc/ghc/_build/install/bin/ghc runtest.opts+= --force-colors runtest.opts+=--unexpected-output-dir=/builds/ghc/ghc/unexpected-test-output failed error: hadrian main testsuite test took 5339 seconds

3 3

Re: GHC LLM policy vs copyright
by Carter Schonwald 02 Sep '26

02 Sep '26

No. Please do some background reading before making these bald assertions. wikipedia or any search engine. also depends on which countries laws. i can only speak confidently about US ip law. but international treaties kinda unify how copyright works, mostly. theres a thing called moral rights outside the us, i dont really understand it and perhaps thats what youre thinkjng of, idk theres absolutely no mysticism needed, but you need to find some background reading for thr regions law. law logic is not like formal methods. itd like deciding who gets hen in the disagreement based on applicable live statutes and or in english style court systems: any precedent in related disputes. but it can involve a dispute frkm 150 yrs ago ans how it was decided also pragmatically: every copyright dispute that holds any water tends to involve naked theft. show me these open source gpl/agpl/closed source but in training sets for coding that have capabilitirs that would work verbatim in ghc. i reallly reallly want to look at these compilers!! On Tue, Sep 1, 2026 at 4:07 PM <code(a)jaro.addy.io> wrote: > Re 1: I think it is quite a tall order to require a concrete example of > copyright infringement. > > I don't see how 2 & 3 are related to my messages in this thread. I did not > mention morality nor did I assume no laws were written as jokes or out of > spite. If you think I did, please explain your reasoning more clearly and > point > to specific parts of my responses. > > Also, if the law is really so complex, contradictory, and sometimes > written or > enforced as a joke or out of spite, shouldn't we be extra careful to avoid > even > a tiny risk of being sued? > > On 9/1/26 21:25, Carter Schonwald via ghc-devs 'ghc-devs at haskell.org' > wrote: > > 1) i want haskell native examples of the actual worrys, not abstract ones > > > > 2) people have literally written enforced laws as a joke or spite, > please do > > some supplementary reading to ground your conjecture in legal writings, > even > > from wikipedia > > > > 3) morals and law are not the same. llms do conflate thise all the time. > i > > totally beleive you have better moral values thanapplicable law, but > thats not > > law. > > > > > > On Tue, Sep 1, 2026 at 2:37 PM <code(a)jaro.addy.io <mailto: > code(a)jaro.addy.io>> > > wrote: > > > > It's true that sometimes there is only one way to implement > something and I > > know copyright does not cover such cases. However, I think that is > quite rare > > in software development, especially once we start looking at > combinations of > > two or three functions. > > > > > and fortunately literally here means verbatim > > > > > > naively these two remarks sound contradictory, but its really a > > reflection of > > > the anthropogenic complexity of humanity > > > > I remain utterly confused about what you mean with “literally” and > “verbatim”, > > and thus unconvinced by your arguments. Like, are you saying that > renaming all > > variables and functions and changing all for-loops to while-loops > (using C for > > this example) is a valid way to avoid copyright infringement because > it is no > > longer a literal or verbatim copy? I refuse to believe that. > > > > On 9/1/26 20:12, Carter Schonwald via ghc-devs 'ghc-devs at > haskell.org > > <http://haskell.org>' wrote: > > > yes, because code is math, and sometimes theres only one proof, > and > > copyright > > > doesnt protect factual stuff just the ultra soecific exact > sentence (except > > > when its literally the only sane way to say soemthing). > > > > > > there is a huge amount of law / case law / history for how this > works, and > > > fortunately literally here means verbatim > > > > > > naively these two remarks sound contradictory, but its really a > > reflection of > > > the anthropogenic complexity of humanity > > > > > > On Tue, Sep 1, 2026 at 1:56 PM <code(a)jaro.addy.io > > <mailto:code@jaro.addy.io> <mailto:code@jaro.addy.io > > <mailto:code@jaro.addy.io>>> > > > wrote: > > > > > > If you define “exact literal content” so broadly as to allow > for > > translations > > > of prose, why wouldn't it also apply to translating software > to > > different > > > languages or using different naming conventions and other > minor code > > style > > > elements? > > > > > > On 9/1/26 19:50, Carter Schonwald 'carter.schonwald at > gmail.com > > <http://gmail.com> <http:// > > > gmail.com <http://gmail.com>>' wrote: > > > > translations are explicitly reusing the exact literal > content, > > and theres > > > > explicitly carve outs in modern law around translated works > > > > > > > > > > > > math and food recipes are explicitly not protected by > copyright law. > > > > > > > > i hope that helps clarify? > > > > > > > > On Tue, Sep 1, 2026 at 1:41 PM <code(a)jaro.addy.io > > <mailto:code@jaro.addy.io> > > > <mailto:code@jaro.addy.io <mailto:code@jaro.addy.io>> > > <mailto:code@jaro.addy.io <mailto:code@jaro.addy.io> > > > <mailto:code@jaro.addy.io <mailto:code@jaro.addy.io>>>> > > > > wrote: > > > > > > > > > building dimilar code for a similar task in a > > > > > different language is definitely not infringing > unless > > its also > > > copying > > > > all > > > > > the text from the source application like some sort > of > > text rpg. > > > > What if we compare this to literature? Surely a > translation of a > > > book into > > > > another language is still considered a derivative > work, even > > if it > > > reuses none > > > > of the “literal text”. > > > > > > > > > > > > > > > > >

2 1