- ghc-devs - Haskell.org

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

Lexing / Parsing and final token
by Alan & Kim Zimmerman 19 Jan '21

19 Jan '21

I am (still) working on !2418 to bring the API Annotations into the GHC ParsedSource, and making good progress. I am currently making a rough port of ghc-exactprint, to ensure I can get all the tests around modifying the AST to work. One of the last pieces is being able to capture the spacing from the last token in the file to the EOF. I guess technically it is the second last token. Empirically (calling getTokenStream), it seems this is always ITsemi. I am not sure how this comes about, as the `module` parsing rule in Parser.y ends with body or body2, and those both finish with an actual or virtual '}'. Can I rely on the token before ITEof always being ITsemi? Alan

2 5

Large Haddock submodule merge landing soon
by Ben Gamari 19 Jan '21

19 Jan '21

Hi all, I have a very large Haddock change (merging Haddock's development branch, `ghc-8.10`, into the `ghc-head` branch) pending in !4819. I will try merge it as soon as Marge's next batch finishes. If you have a Haddock change outstanding you will need to perform a rather significant rebase after this change goes in. However, I am available to help with rebase if needed; just send me the MR number of your merge request and I can take of the rest. Cheers, - Ben

1 0

presentation: Next-gen Haskell Compilation Techniques
by Csaba Hruska 11 Jan '21

11 Jan '21

Hello, I did an online presentation about Haskell related (futuristic) compilation techniques. The application of these methods is also the main motivation of my work with the grin compiler project and ghc-wpc. video: https://www.youtube.com/watch?v=jyaR8E325ok slides: https://docs.google.com/presentation/d/1g_-bHgeD7lV4AYybnvjgkWa9GKuP6QFUyd2… Regards, Csaba

4 5

How to get dwarf stack trace of all live threads (HECs) on demand (e.g. SIGQUIT)?
by YueCompl 07 Jan '21

07 Jan '21

Dear GHC devs, I recently encountered 100% ~ 400% CPU hogging situations to trouble-shoot, I managed to build and use a dwarf enabled GHC-8.10.3 on Ubuntu 18.04 and 20.04 for that, then I find it seemingly dumps only the main thread's stack trace when I press Ctrl+\, but my program is a concurrent language server that will fork a new thread to handle each LSP request, so I really need to see what is going on those threads when CPU get hogged, as the situation is not trivially reproducible, only occurs occasionally after some time of active IDE activity. And I can't figure out how to do that from the user guide, so help please! Thanks & best regards, Compl

1 0