- ghc-devs - Haskell.org

[Haskell] [ANNOUNCE] GHC 9.4.5 released
by Zubin Duggal 18 Apr '23

18 Apr '23

The GHC developers are happy to announce the availability of GHC 9.4.5. Binary distributions, source distributions, and documentation are available at [downloads.haskell.org](https://downloads.haskell.org/ghc/9.4.5). Download Page: https://www.haskell.org/ghc/download_ghc_9.4.5.html Blog Post: https://www.haskell.org/ghc/blog/20230418-ghc-9.4.5-released.html This release is primarily a bugfix release addressing a few issues found in 9.4.4. These include: * Fixes for a number of bug fixes in the simplifier (#22623, #22718, #22913, 22695, #23184, #22998, #22662, #22725). * Many bug fixes to the non-moving and parallel GCs (#22264, #22327, #22926, #22927, #22929, #22930, #17574, #21840, #22528) * A fix a bug with the alignment of RTS data structures that could result in segfaults when compiled with high optimisation settings on certain platforms (#22975 , #22965). * Bumping `gmp-tarballs` to a version which doesn't use the reserved `x18` register on AArch64/Darwin systems, and also has fixes for CVE-2021-43618 (#22497, #22789). * A number of improvements to recompilation avoidance with multiple home units (#22675, #22677, #22669, #22678, #22679, #22680) * Fixes for regressions in the typechecker and constraint solver (#22647, #23134, #22516, #22743) * Easier installation of binary distribution on MacOS platforms by changing the installation Makefile to remove the quarantine attribute when installing. * ... and many more. See the [release notes] for a full accounting. As some of the fixed issues do affect correctness users are encouraged to upgrade promptly. We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do give this release a try and open a [ticket][] if you see anything amiss. Happy compiling, - Zubin [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [release notes]: https://downloads.haskell.org/~ghc/9.4.5/docs/html/users_guide/9.4.5-notes.…

1 0

Performance of small allocations via prim ops
by Harendra Kumar 12 Apr '23

12 Apr '23

I was looking at the RTS code for allocating small objects via prim ops e.g. newByteArray# . The code looks like: stg_newByteArrayzh ( W_ n ) { MAYBE_GC_N(stg_newByteArrayzh, n); payload_words = ROUNDUP_BYTES_TO_WDS(n); words = BYTES_TO_WDS(SIZEOF_StgArrBytes) + payload_words; ("ptr" p) = ccall allocateMightFail(MyCapability() "ptr", words); We are making a foreign call here (ccall). I am wondering how much overhead a ccall adds? I guess it may have to save and restore registers. Would it be better to do the fast path case of allocating small objects from the nursery using cmm code like in stg_gc_noregs? -harendra

5 12

[ANNOUNCE] GHC 9.6.1 is now available
by Ben Gamari 02 Apr '23

02 Apr '23

The GHC team is very pleased to announce the availability of GHC 9.6.1. As usual, binaries and source distributions are available at downloads.haskell.org: https://downloads.haskell.org/ghc/9.6.1/ Beginning with GHC 9.6.1, GHC can be built as a cross-compiler to WebAssembly and JavaScript. This is an important step towards robust support for compiling Haskell to the Web, but there are a few caveats to be aware of in the 9.6 series: - Both the Javascript and WebAssembly backends are still at an early stage of development and are present in this release as a technology preview - Using GHC as a cross-compiler is not as easy as we would like it to be; in particular, there are challenges related to Template Haskell - GHC is not yet run-time retargetable; a given GHC binary targets exactly one platform, and both WebAssembly and JavaScript are considered platforms for this purpose. Cross-compilers must be built from source by their users We hope to lift all of these limitations in future releases. Additionally, 9.6.1 includes: - Significant latency improvements in the non-moving garbage collector - Efficient runtime support for delimited continuations - Improvements in compiler error messages - Numerous improvements in the compiler's memory usage See the [release notes] for a comprehensive accounting of changes in this release. As always, one can find a migration guide to aid in transitioning from older releases on the [GHC Wiki][migration-guide]. We have also recently started extending our release process to cover a wider set of Linux distributions. In particular, we now offer Rocky 8 and Ubuntu 20.04 binary distributions which cover RedHat-derivative and distributions using older glibc releases (namely 2.27), respectively. Thanks to everyone who has contributed code, documentation, testing, and tickets to this release process. As this release represents upstream GHC's first step towards supporting web targets, we are very excited to have this release out the door! Cheers, - Ben [ticket]: https://gitlab.haskell.org/ghc/ghc/issues/ [migration-guide]: https://gitlab.haskell.org/ghc/ghc/-/wikis/migration/9.6 [release notes]: https://downloads.haskell.org/ghc/9.6.1/docs/users_guide/9.6.1-notes.html

3 2

GHC 9.2.7 on FreeBSD - HSC2HS_EXTRA issue
by Martin Baulig 31 Mar '23

31 Mar '23

Hello, I am a FreeBSD user, running FreeBSD 13.1 with Clang 13 and GCC 12.2, and still fairly new to the Haskell Platform. When I tried to upgrade a hobby project to Stackage's latest LTS 20.15, I realized that neither the GHC 9.2.6 nor the GHC 9.2.7 binary packages from GHCUP work anymore. There are two issues - and I wrote a detailed article about my investigation on Medium: https://medium.com/@martin.baulig/ghc-9-2-7-on-freebsd-22afab71c715 The first one is a trivial one-line change - in hadrian/src/Rules/BinaryDist.hs, we need to change > ( "HSC2HS_EXTRA=\"" <> unwords ccArgs <> unwords ldFlags <> "\"" into > ( "HSC2HS_EXTRA=\"" <> unwords (ccArgs <> ldFlags) <> "\"" Otherwise, this will break when both ccArgs and ldFlags are non-empty: > HSC2HS_EXTRA="--cflag=--target=x86_64-portbld-freebsd--lflag=--target=x86_64-portbld-freebsd --lflag=-fuse-ld=lld" Unfortunately, this is not quite it just yet. The problem is that Clang supports the --target= argument, but GCC does not - and it looks like Cabal insists on always invoking hsc2hs with an explicit --cc= argument. Overriding that in ~/.cabal/config doesn't work either - because then Cabal passes "-pgmc /usr/bin/cc" to GHC, but no "-pgma" and GHC tries to invoke GCC for assembling with a Clang-only argument. I am a bit lost here now about what the correct path forward is, but would very much like to help fixing this problem, so I created an account on gitlab.haskell.org to report this issue, but got a message saying that it is awaiting admin approval. Looking a bit further in the documentation for new contributors, I saw a comment suggesting I should post on this mailing list and ask for approval. Could an admin please have a look at that? My user name is my last name in lowercase, baulig. Looking forward to hear back from you, Martin

2 3

Windows/R issue with FFI
by Dominick Samperi 30 Mar '23

30 Mar '23

Hello, FFI code that used to work now fails under Windows (still seems to work under Ubuntu), and I wonder if anybody has seen anything like this and can provide some pointers... The code uses FFI to fetch information from the R side like R_NilValue, using something like this; -- Fetch R's R_NilValue... foreign import ccall unsafe "&R_NilValue" r_NilValue_ptr :: Ptr R_EXP r_NilValue :: IO R_EXP r_NilValue = peek r_NilValue_ptr rNilValue1 :: IO REXP rNilValue1 = do x <- r_NilValue traceShow("addr=",x) extREXP x Under Windows the address displayed is obviously bad, and this causes the app to crash. This does not happen under Linux (Ubuntu). Now, replace the line containing peek with r_NilValue = trace "PEEK" peek r_NilValue_ptr The address is now valid! It seems that adding the trace "PEEK" adds some delay and somehow resolves the problem. This problem is intermittent, so it is hard to come up with a simple example that fails every time. A little background: R_NilValue is a pointer to a SEXP that is not initialized until an embedded instance of R is initialized, and the code above is not triggered until this happens. Perhaps there is a race condition between the time R initializes itself and Haskell performs the peek? I don't think R_NilValue is garbage collected once initialized. Any tips would be appreciated. Dominick

3 6

Understanding how warnings on unused functions work
by Razetime 28 Mar '23

28 Mar '23

This message is related to a feature in the futhark compiler <https://github.com/diku-dk/futhark/issues/550>, which is a language with a similar module system. I am trying to create a tool to detect unused top-level functions in Futhark, and I have been looking in the ghc codebase to find out how it does so. So far I have found these areas: 1. warning flag <https://gitlab.haskell.org/ghc/ghc/-/blob/master/compiler/GHC/Driver/Flags.…> 2. WarnUnusedTopBinds <https://gitlab.haskell.org/ghc/ghc/-/blob/master/compiler/GHC/Rename/Utils.…> The project is a bit too big for my machine to take, so HLS is not helping me with finding where the computation of unused bindings (specifically functions) is done. I would like some help with finding where ghc does this computation, and maybe some help with the naming conventions of the code. Thanks in advance.

2 1

Buy-in for technical proposal 47 which affect GHC devs
by Laurent P. René de Cotret 26 Mar '23

26 Mar '23

Dear GHC developers, In recent weeks, John Ericson has fine-tuned a Haskell Foundation Technical Proposal to split `base` into two libraries: `ghc-base` and `base`, the latter simply re-exporting everything for `ghc-base` (for now). You can read about the rationale and specifics more in details in the proposal itself: https://github.com/haskellfoundation/tech-proposals/pull/47 Note that this proposal has recently been streamlined into a form which is more focused than its initial state, and might be worth a re-read. The Haskell Foundation Technical Working Group has reached a consensus that this work will benefit the Haskell community. Moreover, the Haskell Foundation has agreed to spend some of its resources to implement this proposal, which would start by ensuring the completion of MR7898 (https://gitlab.haskell.org/ghc/ghc/-/merge_requests/7898) This work will affect GHC developers. Therefore, the Technical Working Group would like to get buy-in from the GHC developers before formally accepting this proposal. Best regards, Laurent P. René de Cotret on behalf of the Haskell Foundation Technical Working Group

8 18

GitLab partial outage - attempting to mitigate
by Bryan Richter 20 Mar '23

20 Mar '23

I am seeing a few different problems with the GitLab server right now. I am gonna try to mitigate the issues, so the server might be unavailable for a few short periods.

3 5

Re: CI
by Bryan Richter 20 Mar '23

20 Mar '23

Spam detection software, running on the system "mail.haskell.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: I'm back at my computer and am investigating. I don't see the problem I feared, but I do see some anomalies. I'll update once it's back to normal. On Sat, 18 Mar 2023 at 17:55, Bryan Richter <bryan(a)haskell.foundation> wrote: [...] Content analysis details: (5.8 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SPF_PASS SPF: sender matches SPF record 5.0 UNWANTED_LANGUAGE_BODY BODY: Message written in an undesired language 0.0 HTML_MESSAGE BODY: HTML included in message 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5000] 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid The original message was not completely plain text, and may be unsafe to open with some email clients; in particular, it may contain a virus, or confirm that your address can receive spam. If you wish to view it, it may be safer to save it to a file and open it with an editor.

1 2

CI
by Simon Peyton Jones 18 Mar '23

18 Mar '23

All GHC CI pipelines seem stalled, sadly e.g. https://gitlab.haskell.org/ghc/ghc/-/merge_requests/10123/pipelines Can someone unglue it? Thanks! Simon

3 2