- ghc-devs - Haskell.org

WSL2
by Simon Peyton Jones 10 Mar '21

10 Mar '21

Friends I've just installed WSL2 and built GHC. I get this (single) validation failure in libraries/unix/tests/getGroupEntryForName. It seems to be just an error message wibble, but I can't push a change to master because that'll affect everyone else. Any ideas? Simon =====> 1 of 1 [0, 0, 0] ]0;getGroupEntryForName(normal) 1 of 1 [0, 0, 0]Actual stderr output differs from expected: --- getGroupEntryForName.run/getGroupEntryForName.stderr.normalised 2021-03-09 22:36:01.300421100 +0000 +++ getGroupEntryForName.run/getGroupEntryForName.run.stderr.normalised 2021-03-09 22:36:01.300421100 +0000 @@ -1 +1 @@ -getGroupEntryForName: getGroupEntryForName: does not exist (no such group) +getGroupEntryForName: getGroupEntryForName: does not exist (No such process) *** unexpected failure for getGroupEntryForName(normal)

2 2

Running ghc-debug on ghc
by Matthew Pickering 09 Mar '21

09 Mar '21

Hi, I now have some simple instructions for running ghc-debug on GHC. 1. Cherry-pick 4be70967f1f1ab70cbe31aad8ae69aea87c6f4c4 commit 4be70967f1f1ab70cbe31aad8ae69aea87c6f4c4 (HEAD -> wip/ghc-with-debug) Author: Matthew Pickering <matthewtpickering(a)gmail.com> Date: Fri Jan 8 11:26:17 2021 +0000 Add support for ghc-debug to ghc executable 2. Build GHC * Add the following to _build/hadrian.settings ``` stage1.*.ghc.hs.opts += -finfo-table-map -fdistinct-constructor-tables ``` * Build GHC as normal ``` ./hadrian/build -j8 ``` * The result is a ghc-debug enabled compiler # Building a debugger * Use the compiler you just built to build ghc-debug ``` cd ghc-debug cabal update cabal new-build debugger -w ../_build/stage1/bin/ghc ``` # Running the debugger Modify `test/Test.hs` to implement the debugging thing you want to do. Perhaps start with `p30`, which is a program to generate a profile. * Start the process you want to debug ``` GHC_DEBUG_SOCKET=/tmp/ghc-debug build-cabal ``` * Start the debugger ``` cabal new-run debugger -w ... ``` * Open a ticket about the memory issue you find. There is the start of some more documentation here - http://ghc.gitlab.haskell.org/ghc-debug/docs.html These instructions are also in the instructions.md file in the commit. Cheers, Matt

2 1

What changed between GHC 8.8 and 8.10 that could cause this?
by ÉRDI Gergő 09 Mar '21

09 Mar '21

Hi, I'm trying to figure out a Clash problem and managed to track it down to a GHC upgrade; specifically, a given Clash version, when based on GHC 8.8, has no problem synthesizing one module after another from one process; but the same Clash version with GHC 8.10 fails with link-time errors on the second compilation. The details are at https://github.com/clash-lang/clash-compiler/issues/1686 but for now I'm just hoping that some lightbulb will go off for someone if some handling of internal state has changed in GHC that could mean that the symbol tables of loaded modules could persist between GHC invocations from the same process. So, does this ring a bell for anyone? Thanks, Gergo

5 8

Requesting help with unregisterized backend failure of !4717
by John Ericson 09 Mar '21

09 Mar '21

Hi everyone, https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4717 fails some numerical boundary checking tests with the unregisterized backend. In particular, `minBound / (-1)` and `pred minBound` are *not* diverging as expected. This stumped me a few days ago, and no new ideas have struct me since. I would very much appreciate some help. This does seem like something that is very likely to be backend-dependent, as different instructions/arches handle such edge cases in different ways. What makes this so peculiar, however, is that the boundary condition checking/branching is done *in regular Haskell*. I'm thus quite baffled as to what could be going wrong. If anyone wants to dive in, see my last comment https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4717#note_329840, which has a minimization to declutter the code without doing enough constant folding that the problem is avoided entirely. (I went with a compilation unit trick, but in hindsight NOINLINE should also work and be simpler.) Finally, let my provide some context for why I am hoping to get this merged soon. To be clear, !4492 was the main MR relating to the numerics primops critical to get in for 9.2 and it thankfully already landed. But landing this MR too would be nice: It shrinks the intermediate representations of numerical code probably smaller than it was originally, whereas now it is perhaps larger than it was before due to more size<->native conversions. Also, I think this MR will help get !3658 over the finish line, which, while again not as critical for 9.2 as !4492 was, would be awfully nice to do to fully realize the new simplicity of the plan set forth in https://gitlab.haskell.org/ghc/ghc/-/wikis/Unboxed-Numerics. Thanks, John N.B. I just rebased and repushed the MR, so CI might be still running or failing due to something else, but based on local testing this is still the an issue. https://gitlab.haskell.org/ghc/ghc/-/pipelines/31002 is an earlier pipeline run that one can look at until CI finishes again.

2 2

Pointer-or-Int 63-bit representations for Integer
by Chris Done 08 Mar '21

08 Mar '21

Hi all, In OCaml's implementation, they use a well known 63-bit representation of ints to distinguish whether a given machine word is either a pointer or to be interpreted as an integer. I was wondering whether anyone had considered the performance benefits of doing this for the venerable Integer type in Haskell? I.e. if the Int fits in 63-bits, just shift it and do regular arithmetic. If the result ever exceeds 63-bits, allocate a GMP/integer-simple integer and return a pointer to it. This way, for most applications--in my experience--integers don't really ever exceed 64-bit, so you would (possibly) pay a smaller cost than the pointer chasing involved in bignum arithmetic. Assumption: it's cheaper to do more CPU instructions than to allocate or wait for mainline memory. This would need assistance from the GC to be able to recognize said bit flag. As I understand the current implementation of integer-gimp, they also try to use an Int64 where possible using a constructor (https://hackage.haskell.org/package/integer-gmp-1.0.3.0/docs/src/GHC.Intege…) but I believe that the compiled code will still pointer chase through the constructor. Simple addition or subtraction, for example, is 24 times slower in Integer than in Int for 1000000 iterations: https://github.com/haskell-perf/numbers#addition An unboxed sum might be an improvement? e.g. (# Int# | ByteArray# #) -- would this "kind of" approximate the approach described? I don't have a good intuition of what the memory layout would be like. Just pondering. Cheers, Chris

4 4

Newcomer looking for mentorship on a HPC / Coverage related issue
by Javran Cheng 03 Mar '21

03 Mar '21

Hi all, I'm a newcomer (not entirely new as I did have some contribution few years back but the workflow seems to have changed a lot) and is working on https://gitlab.haskell.org/ghc/ghc/-/issues/15932. I'm looking for some (informal) mentorship on that issue - I think I know what the problem is <https://gitlab.haskell.org/ghc/ghc/-/issues/15932#note_283252>, but I need someone with more experience to help developing a concrete plan before working on a fix, as this might involve two parts in GHC codebase: HPC source code and GHC/HsToCore/Coverage. I tried to ask for comments and other related bits on IRC few months back but that doesn't attract much attention. Now that I'm in the mood of hacking GHC again, I figure probably finding a mentorship might work better. Thanks! Javran

2 1

Plan for GHC 9.2
by Ben Gamari 03 Mar '21

03 Mar '21

tl;dr. Provisional release schedule for 9.2 enclosed. Please discuss, especially if you have something you would like merged for 9.2.1. Hello all, With GHC 9.0.1 at long-last out the door, it is time that we start turning attention to GHC 9.2. I would like to avoid making the mistake made in the 9.0 series in starting the fork in a state that required a significant amount of backporting to be releaseable. Consequently, I want to make sure that we have a fork schedule that is realistic given the things that need to be merged for 9.2. These include: * Update haddock submodule in `master` (Ben) * Bumping bytestring to 0.11 (#19091, Ben) * Finishing the rework of sized integer primops (#19026, John Ericson) * Merge of ghc-exactprint into GHC? (Alan Zimmerman, Henry) * Merge BoxedRep (#17526, Ben) * ARM NCG backend and further stabilize Apple ARM support? (Moritz) * Some form of coercion zapping (Ben, Simon, Richard) * Tag inference analysis and tag check elision (Andreas) If you see something that you would like to see in 9.2.1 please do holler. Otherwise, if you see your name in this list it would be great if you could let me know when you think your project may be in a mergeable state. Ideally we would strive for a schedule like the following: 4 February 2021: We are here ~4 weeks pass 3 March 2021: Release branch forked 1 week passes 10 March 2021: Alpha 1 released 3 weeks pass 31 March 2021: Alpha 2 released 2 weeks pass 14 April 2021: Alpha 3 released 2 weeks pass 28 April 2021: Alpha 4 released 1 week passes 5 May 2021: Beta 1 released 1 week passes 12 May 2021: Release candidate 1 released 2 weeks pass 26 May 2021: Final release This provides ample time for stabilization while avoiding deviation from the usual May release timeframe. However, this would require that we move aggressively to start getting the tree into shape since the fork would be less than four weeks away. I would appreciate contributors' thoughts on the viability of this timeline. Cheers, - Ben

6 7

GHC 9.1?
by Richard Eisenberg 02 Mar '21

02 Mar '21

Hi devs, I understand that GHC uses the same version numbering system as the Linux kernel did until 2003(*), using odd numbers for unstable "releases" and even ones for stable ones. I have seen this become a point of confusion, as in: "Quick Look just missed the cutoff for GHC 9.0, so it will be out in GHC 9.2" "Um, what about 9.1?" Is there a reason to keep this practice? Linux moved away from it 18 years ago and seems to have thrived despite. Giving this convention up on a new first-number change (the change from 8 to 9) seems like a good time. I don't feel strongly about this, at all -- just asking a question that maybe no one has asked in a long time. Richard (*) I actually didn't know that Linux stopped doing this until writing this email, wondering why we needed to tie ourselves to Linux. I coincidentally stopped using Linux full-time (and thus administering my own installation) in 2003, when I graduated from university.

6 8

initIface* usage in plugins
by Josh Meredith 27 Feb '21

27 Feb '21

Hi, I'm trying to use initIfaceLoad and initIfaceLcl to lookup core `Name`s within a plugin. My understanding is that functions such as `lookupIfaceTop` are used for this, but I'm running into an issue that I suspect is caused by some `Name`s being inappropriate for this function, so they fail with the error `Iface id out of scope: ...`. Is there a robust way to select which `Name` lookup function to use based on a core binding/expression? Thanks, Josh

3 2

MR template text
by Simon Peyton Jones 24 Feb '21

24 Feb '21

I often see MRs in my inbox that say Thank you for your contribution to GHC! Please take a few moments to verify that your commits fulfill the following: [ ] are either individually buildable or squashed This is because the author hasn't changed the Description of the MR, but rather has left the template text unchanged. As a way to "nudge" authors to give reviewers more information, I suggest replacing the template text with the draft below. Does anyone have any views, for or against? Simon Proposed new template PLEASE REPLACE ALL OF THIS TEXT with a description of your merge request, including * A description of what the Merge Request does. For a single-commit MR, a copy of the commit message is often perfect. * A reference (e.g. #19415) to the ticket that led to this MR, and that describes the problem that this MR solves. Almost all MRs need a ticket, except the tiniest changes (e.g. code formatting) - A ticket describes a *problem* - A merge request describes a *solution* to that problem. While you are encouraged to write a good MR Description, it's not compulsory. You could just be putting up the MR to share with a colleague, for example. But if you want (a) to get code reviews from others, or (b) to land the patch in GHC, please do follow these guidelines. For general style guidance see https://gitlab.haskell.org/ghc/ghc/wikis/commentary/coding-style For completeness, the current template is Thank you for your contribution to GHC! Please take a few moments to verify that your commits fulfill the following: * [ ] are either individually buildable or squashed * [ ] have commit messages which describe *what they do* (referring to [Notes][notes] and tickets using `#NNNN` syntax when appropriate) * [ ] have added source comments describing your change. For larger changes you likely should add a [Note][notes] and cross-reference it from the relevant places. * [ ] add a [testcase to the testsuite](https://gitlab.haskell.org/ghc/ghc/wikis/building/running-tests/…. * [ ] replace this message with a description motivating your change If you have any questions don't hesitate to open your merge request and inquire in a comment. If your patch isn't quite done yet please do add prefix your MR title with `WIP:`. [notes]: https://gitlab.haskell.org/ghc/ghc/wikis/commentary/coding-style#comments-i…

4 5