- ghc-devs - Haskell.org

remAddr# primop inconsistency
by Csaba Hruska 06 Feb '21

06 Feb '21

Hello, I've discovered that the remAddr# primop documentation is inconsistent with the implementation. According to the docs (primops.txt.pp) the remAddr# should be the same as remInt#. > primop AddrRemOp "remAddr#" GenPrimOp Addr# -> Int# -> Int# {Return the remainder when the {\tt Addr\#} arg, treated like an {\tt Int\#}, is divided by the {\tt Int\#} arg.} > > But it is implemented with the mo_wordURem instruction, just like the WordRemOp primop. > GHC/StgToCmm/Prim.hs: > AddrRemOp -> \args -> opTranslate args (mo_wordURem platform) > WordRemOp -> \args -> opTranslate args (mo_wordURem platform) > IntRemOp -> \args -> opTranslate args (mo_wordSRem platform) > Which one is correct, the docs or the implementation? Regards, Csaba Hruska

2 2

GHC Reading Guide
by Takenobu Tani 06 Feb '21

06 Feb '21

Dear devs, I've written a simple document about "GHC source reading" for myself and potential newcomers: * https://takenobu-hs.github.io/downloads/haskell_ghc_reading_guide.pdf (https://github.com/takenobu-hs/haskell-ghc-reading-guide) Please teach me if something's wrong. I'll learn and correct them. Happy Haskelling :) Regards, Takenobu

3 3

Happy version downgrade
by Simon Peyton Jones 04 Feb '21

04 Feb '21

Friends I can't build ghc-9.0 because of this: checking for ghc-pkg matching /opt/ghc/bin/ghc... /opt/ghc/bin/ghc-pkg checking for happy... /home/simonpj/.cabal/bin/happy checking for version of happy... 1.20.0 configure: error: Happy version 1.19 is required to compile GHC. What is the easiest way to fix? I have happy 1.19.8, but it's not called plain "happy" bash$ happy-1.19.8 --version Happy Version 1.19.8 Copyright (c) 1993-1996 Andy Gill, Simon Marlow (c) 1997-2005 Simon Marlow Happy is a Yacc for Haskell, and comes with ABSOLUTELY NO WARRANTY. This program is free software; you can redistribute it and/or modify it under the terms given in the file 'LICENSE' distributed with the Happy sources. Thanks Simon

2 1

Inspecting function arguments in GHCi
by Andrew Kvapil 02 Feb '21

02 Feb '21

Hello, I'm interested in inspecting the strictness of functions at runtime and the depth of thunks "in the wild." For this reason I'm modifying GHC 8.10.2, essentially to add additional information to breakpoints. I'd like to reuse the logic behind GHCi's :print command (pprintClosureCommand, obtainTermFromId, ...) for which I suppose I need Id's. Those however don't exist for destructuring patterns, such as those in the following equations: last [x] = x last (_:xs) = last xs So I'm wondering where would be a good place in the pipeline to transform patterns like these into at-patterns, to give them Id's. However, the breakpoint logic only looks at the free variables of the right-hand sides and not transitively, which means that e.g. in the following example neither ':print arg1' nor ':print as' works when the interpreter hits a breakpoint in the top level expression on the RHS: qsort arg1@(a:as) = qsort left ++ [a] ++ qsort right where (left, right) = (filter (<=a) as, filter (>a) as) Thus I'd also like to know how to extend the free var logic for Tickish that eventually leads to CgBreakInfo and :print's ability to inspect these bindings at runtime. My goal would be to determine to what extent was a thunk evaluated during function application. Any advice would be greatly appreciated! Regards, Andrew Kvapil

4 5

Storage layout of integral types
by Stefan Schulze Frielinghaus 01 Feb '21

01 Feb '21

Hi all, I'm wondering what the supposed storage layout of integral types is. In particular for integral types with size less than the size of a word. For example, on a 64bit machine is a 32bit integer supposed to be written as a whole word and therefore as 64 bits or just as 32bits in the payload of a closure? I'm asking because since commit be5d74ca I see differently aligned integers in the payload of a closure on a 64bit big-endian machine. For example, in the following code an Int32 object is created which contains the actual integer in the high part of the payload (the snippet comes from the add operator GHC.Int.$fNumInt32_$c+_entry): Hp = Hp + 16; ... I64[Hp - 8] = GHC.Int.I32#_con_info; I32[Hp] = _scz7::I32; whereas e.g. in function rts_getInt32 the opposite is assumed and the actual integer is expected in the low part of the payload: HsInt32 rts_getInt32 (HaskellObj p) { // See comment above: // ASSERT(p->header.info == I32zh_con_info || // p->header.info == I32zh_static_info); return (HsInt32)(HsInt)(UNTAG_CLOSURE(p)->payload[0]); } The same seems to be the case for the interpreter and foreign calls (case bci_CCALL) where integral arguments are passed in the low part of a whole word. Currently, my intuition is that the payload of a closure for an integral type with size smaller than WordSize is written as a whole word where the subword is aligned according to the machines endianness. Can someone confirm this? If that is indeed true, then rts_getInt32 seems to be correct but not the former. Otherwise the converse seems to be the case. Cheers, Stefan

1 1

-ddump-json
by Richard Eisenberg 29 Jan '21

29 Jan '21

Hi devs, In my work with Alfredo at revising our error message infrastructure, we ran across some code that renders error messages as JSON. Given that our data structures are changing, it seems natural to change the JSON output, too, but it's unclear whether that's wise. The manual currently lists -ddump-json in the chapter on "Debugging the compiler", suggesting that a change is fine, but I'm not yet convinced. So: - Is there someone in charge of -ddump-json? Matthew Pickering authored -ddump-json in https://gitlab.haskell.org/ghc/ghc/-/commit/91691117fc194c525f58ccd5b266dd1… <https://gitlab.haskell.org/ghc/ghc/-/commit/91691117fc194c525f58ccd5b266dd1…>. - Are there clients of -ddump-json? - Is there a specification of -ddump-json? - There will likely be a desire to evolve this feature. What is the process for doing so? Thanks! Richard

5 5

safe to upgrade my Mac?
by Richard Eisenberg 28 Jan '21

28 Jan '21

Hi devs, I'm currently running MacOS High Sierra, 10.13.6. Things are fine, but I'd like to upgrade to get Dark Mode and (hopefully) to speed up Mail. (That is, upgrading is nice, but not at all necessary.) If I upgrade, will GHC hate me? That is, will GHC 8.10 continue to work? Will I continue to be able to compile GHC? Will it be as performant? (A few years ago, I had a strange issue on a secondary computer where any binary built by GHC was horribly slow; we never got to the bottom of it.) All advice is welcome. Thanks! Richard

4 3

[ANNOUNCE] Glasgow Haskell Compiler 9.0.1-rc1 released
by Ben Gamari 26 Jan '21

26 Jan '21

Hello all, The GHC team is very pleased to announce the availability of the first release candidate of GHC 9.0.1 series. Source and binary distributions are available at the usual place: https://downloads.haskell.org/ghc/9.0.1-rc1/ This release candidate comes quite a bit later than expected after difficulty finding a performance neutral fix for a critical soundness bug, #17760. See [1] for details on the solution, particularly if you are a library maintainer currently using the touch# primop or withForeignPtr. Nevertheless, this release has nevertheless seen a considerable amount of testing and consequently we hope that this should be the last pre-release before the final release. In addition to numerous bug fixes, GHC 9.0.1 will bring a number of new features: * A first cut of the new LinearTypes language extension [2], allowing use of linear function syntax and linear record fields. * A new bignum library (ghc-bignum), allowing GHC to be more easily used with integer libraries other than GMP. * Improvements in code generation, resulting in considerable performance improvements in some programs. * Improvements in pattern-match checking, allowing more precise detection of redundant cases and reduced compilation time. * Implementation of the "simplified subsumption" proposal [3] simplifying the type system and paving the way for QuickLook impredicativity in GHC 9.2. * Implementation of the QualifiedDo extension [4], allowing more convenient overloading of `do` syntax. * Improvements in compilation time. And many more. See the release notes [5] for a full accounting of the changes in this release. As always, do test this release and open tickets for whatever issues you encounter. Cheers, - Ben [1] https://gitlab.haskell.org/ghc/ghc/-/wikis/migration/9.0#ghc-prim-07 [2] https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0111-l… [3] https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0287-s… [4] https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0216-q… [5] https://downloads.haskell.org/ghc/9.0.1-rc1/docs/html/users_guide/9.0.1-not…

3 2

[hadrian] HEAD link failure
by Shayne Fletcher 25 Jan '21

25 Jan '21

Building `HEAD` just now with `hadrian/build-stack --flavour=quickest -j`, I get a link failure for stage1 `bin/ghc`: ``` ld: library not found for -lHSrts-1.0_thr_l ``` I'll try another flavour or something but in the meantime is this ringing any bells? -- Shayne Fletcher

2 1

Benchmarking experiences: Cabal test vs compiling nofib/spectral/simple/Main.hs
by Andreas Klebinger 23 Jan '21

23 Jan '21

Hello Devs, When I started to work on GHC a few years back the Wiki recommended using nofib/spectral/simple/Main.hs as a test case for compiler performance changes. I've been using this ever since. "Recently" the cabal-test (compiling cabal-the-library) has become sort of a default benchmark for GHC performance. I've used the Cabal test as well and it's probably a better test case than nofib/spectral/simple/Main.hs. I've started using both usually using spectral/simple to benchmark intermediate changes and then looking at the cabal test for the final patch at the end. So far I have rarely seen a large difference between using cabal or spectral/simple. Sometimes the magnitude of the effect was different between the two, but I've never seen one regress/improve while the other didn't. Since the topic came up recently in a discussion I wonder if others use similar means to quickly bench ghc changes and what your experiences were in terms of simpler benchmarks being representative compared to the cabal test. Cheers, Andreas

3 2