From zubin at well-typed.com Sat May 3 11:53:14 2025 From: zubin at well-typed.com (Zubin Duggal) Date: Sat, 3 May 2025 17:23:14 +0530 Subject: GHC 9.10.2 is now available Message-ID: <5exf6skh63uhw3inlhqdoi52rcqqnbsgjx6ukppmnooanzkaxt@2sn6ofbqzwmu> The GHC developers are very pleased to announce the availability of the release candidate for GHC 9.10.2. Binary distributions, source distributions, and documentation are available at [downloads.haskell.org][] and via [GHCup](https://www.haskell.org/ghcup/). GHC 9.10.2 is a bug-fix release fixing over 50 issues of a variety of severities and scopes, including: * Significantly improved performance when dynamically loading Haskell symbols (#23415). * Fixing a bug where the simplifier sometimes destroyed join points during float out, which could impact performance (#24768). * Reduced memory fragmentation in the non-moving GC's segment allocator, improving resident set size by up to 26% for some applications (#24150). * Added new flags to control speculative evaluation (-fspec-eval and -fspec-eval-dictfun) to work around performance regressions (#25606). * Fixed several platform-specific issues, including segfaults with FFI on PowerPC (#23034) and improved code generation for AArch64 with multiway branches now using jump tables (#19912) * 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][]. We would like to thank Well-Typed, Tweag I/O, Juspay, QBayLogic, Channable, Serokell, SimSpace, the Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do give this release a try and open a [ticket][] if you see anything amiss. Cheers, Zubin [release notes]: https://downloads.haskell.org/~ghc/9.10.2/docs/users_guide/9.10.2-notes.html [status]: https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status [downloads.haskell.org]: https://downloads.haskell.org/ghc/9.10.2 [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: From alan.zimm at gmail.com Mon May 12 18:01:32 2025 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Mon, 12 May 2025 19:01:32 +0100 Subject: LINE and COLUMN pragmas Message-ID: I recently discovered the `UsePosPragsBit` in the lexer, which can allow emitting the LINE and COLUMN pragmas as tokens instead of processing them directly in the Lexer, updating the position. When exact printing, this behaviour is not desirable. So I am putting together an MR to parse them if they appear, so they do not cause a parser crash, and they can then be exact printed. Question: Where should these pragmas appear in HsDecl Options are - TTG, XXHsDecl - A new HsDecl constructor, with all its concomitant matching everywhere - tuck it in elsewhere, e.g. in `AnnDecl` (or `XXAnnDecl`). Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From 0.0 at owo.li Wed May 14 09:14:39 2025 From: 0.0 at owo.li (Iris) Date: Wed, 14 May 2025 17:14:39 +0800 Subject: GitLab Account creation request Message-ID: Dear GHC developers, I am interested in contributing to the GHC project and would like to have an account(iris) on the GitLab instance. Best regards, Iris -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodrigo.m.mesquita at gmail.com Wed May 14 09:31:30 2025 From: rodrigo.m.mesquita at gmail.com (Rodrigo Mesquita) Date: Wed, 14 May 2025 10:31:30 +0100 Subject: GitLab Account creation request In-Reply-To: References: Message-ID: Hi Iris, I’ve approved your request now. Welcome! Feel free to ask questions. Rodrigo > On 14 May 2025, at 10:14, Iris <0.0 at owo.li> wrote: > > Dear GHC developers, > I am interested in contributing to the GHC project and would like to have an account(iris) on the GitLab instance. > > Best regards, > Iris > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From florian.ragwitz at gmail.com Fri May 16 17:52:25 2025 From: florian.ragwitz at gmail.com (Florian Ragwitz) Date: Fri, 16 May 2025 10:52:25 -0700 Subject: GitLab account request Message-ID: Hi, I'd like for the gitlab.haskell.org account request for the account "rafl" to be approved, so that I can participate in issue discussions and submit changes for review, please. Thanks! From allbery.b at gmail.com Fri May 16 19:19:34 2025 From: allbery.b at gmail.com (Brandon Allbery) Date: Fri, 16 May 2025 15:19:34 -0400 Subject: GitLab account request In-Reply-To: References: Message-ID: I've approved you. On Fri, May 16, 2025 at 1:52 PM Florian Ragwitz wrote: > Hi, > > I'd like for the gitlab.haskell.org account request for the account > "rafl" to be approved, so that I can participate in issue discussions > and submit changes for review, please. > > Thanks! > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -- brandon s allbery kf8nh allbery.b at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.colpitts at gmail.com Sun May 25 16:32:11 2025 From: george.colpitts at gmail.com (George Colpitts) Date: Sun, 25 May 2025 13:32:11 -0300 Subject: can't move to latest version of llvm on ghc 9.12.2 In-Reply-To: References: <4db7eafd-69b0-476c-bffd-e2a8827d7346@gmx.at> Message-ID: The obvious workaround is to change the configure file to LlvmMaxVersion=21 then rerun configure and sudo make install. I did that and smoke tested llvm 20.15 and it seems to work fine. In case anybody else is interested in testing llvm 20 on 9.12.2 On Wed, Apr 2, 2025 at 9:06 AM George Colpitts wrote: > Filed https://gitlab.haskell.org/ghc/ghc/-/issues/25915 > > On Tue, Apr 1, 2025 at 2:11 PM Andreas Klebinger via ghc-devs < > ghc-devs at haskell.org> wrote: > >> Looking at https://gitlab.haskell.org/ghc/ghc/-/issues/25011 it seems >> the desire was to fail with a proper error when LLVM was not found at all. >> >> To me failing when the llvm version is too new seems like a unintended >> side effect of fixing the former. >> >> I agree that simply warning and trying anway is the better default. A >> ticket would be appreciated! >> Am 01/04/2025 um 19:05 schrieb George Colpitts: >> >> I was trying to find out if it works but I ran into the problem I >> described. Yes, there were a few years where the latest version didn't work >> but in many years it did. ghc used to give a warning, this is an >> unsupported version but we'll try it anyways. I would like to return to >> that. >> >> In any case I believe ghc dev should test to see if it works and if so >> use it in HEAD. If it doesn't work than we should file a bug and fix it. In >> the past we got a few versions behind llvm. I think we want to be on the >> latest version available for each new release if possible. The earlier we >> look into this the more chance we have to succeed at that. >> >> On Tue, Apr 1, 2025 at 1:27 PM Brandon Allbery >> wrote: >> >>> Have you demonstrated that it works? IIRC the current behavior is >>> because some LLVM version (16, IIRC) didn't work with GHC (threw errors >>> from opt, I think). >>> >>> On Tue, Apr 1, 2025 at 10:49 AM George Colpitts < >>> george.colpitts at gmail.com> wrote: >>> >>>> llvm 20 is out but unlike in earlier versions of ghc moving to it means >>>> you can no longer use llvm: >>>> >>>> compiling: >>>> >>>> ghc -fllvm hello.hs >>>> Loaded package environment from >>>> /Users/avie/.ghc/aarch64-darwin-9.12.2/environments/default >>>> [1 of 2] Compiling Main ( hello.hs, hello.o ) >>>> : error: [GHC-66599] >>>> GHC was not configured with a supported LLVM toolchain >>>> Make sure you have installed LLVM between [13 and 20) and reinstall >>>> GHC to make -fllvm work >>>> >>>> >>>> from configure: >>>> >>>> configure: We only support llvm 13 upto 20 (non-inclusive) (found >>>> 20.1.1). >>>> >>>> >>>> Can we move to llvm 20 on HEAD and can we revert to the old behavior on >>>> ghc 9.12.3? >>>> >>>> Should I file an ER? >>>> >>>> Thanks >>>> >>>> _______________________________________________ >>>> ghc-devs mailing list >>>> ghc-devs at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>>> >>> >>> >>> -- >>> brandon s allbery kf8nh >>> allbery.b at gmail.com >>> >> >> _______________________________________________ >> ghc-devs mailing listghc-devs at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From xypron.glpk at gmx.de Tue May 27 18:35:36 2025 From: xypron.glpk at gmx.de (Heinrich Schuchardt) Date: Tue, 27 May 2025 20:35:36 +0200 Subject: RTS: mmap fails on RISC-V with Linux 6.8 Message-ID: <3595c1c3-8509-41de-936e-00843acdb645@gmx.de> The following bug related to the Haskell runtime was reported in Launchpad: Haskell's default behaviour of using large-address-space is causing pandoc to stuck in an infinite loop on QEMU 10 Edit https://bugs.launchpad.net/ubuntu/+source/ghc/+bug/2111581 The problem seems to relate to the following loop in osReserveHeapMemory(): https://gitlab.haskell.org/ghc/ghc/-/blob/master/rts/posix/OSMem.c?ref_type=heads#L589 According to the mmap() manpage the address passed to the kernel in only a hint there is no guarantee that the same address will be used for allocation. As shown in the strace logs attached in Launchpad this code can lead to an endless loop when the kernel decides always to return an address below 8 GiB. It might make sense to round up the address to 8 GiB if the returned address is below 8 GiB and reduce *len accordingly instead of retrying. Best regards Heinrich