September 2022 - ghc-devs

Warnings in RTS
by Simon Peyton Jones 11 Oct '22

11 Oct '22

Whenever I compile the RTS I get these warnings. Are they necessary? Simon In file included from rts/Schedule.c:16:0: error: rts/Schedule.c: In function ‘schedule’: rts/Schedule.h:143:1: error: warning: inlining failed in call to ‘appendToRunQueue’: call is unlikely and code size would grow [-Winline] 143 | appendToRunQueue (Capability *cap, StgTSO *tso) | ^~~~~~~~~~~~~~~~ | 143 | appendToRunQueue (Capability *cap, StgTSO *tso) | ^ rts/Schedule.c:1226:9: error: note: called from here 1226 | appendToRunQueue(cap,t); | ^~~~~~~~~~~~~~~~~~~~~~~ | 1226 | appendToRunQueue(cap,t); | ^ In file included from rts/Schedule.c:16:0: error: rts/Schedule.h:164:1: error: warning: inlining failed in call to ‘pushOnRunQueue’: call is unlikely and code size would grow [-Winline] 164 | pushOnRunQueue (Capability *cap, StgTSO *tso) | ^~~~~~~~~~~~~~ | 164 | pushOnRunQueue (Capability *cap, StgTSO *tso) | ^ rts/Schedule.c:1228:9: error: note: called from here 1228 | pushOnRunQueue(cap,t); | ^~~~~~~~~~~~~~~~~~~~~ | 1228 | pushOnRunQueue(cap,t); | ^ rts/Schedule.c: At top level: cc1: warning: unrecognized command line option ‘-Wno-nonportable-include-path’

2 1

Implementing a compilation server
by Domínguez, Facundo 11 Oct '22

11 Oct '22

Dear ghc devs, I'm using the ghc API to write a compilation server (a.k.a. persistent worker). The idea is to serve requests to compile individual modules. In this fashion, we can compile modules with different compilation flags and yet pay only once for the startup overheads of the compiler. One challenge of this approach is to reuse as much as possible from the ghc API session/environment from one compilation request to the next, so we save the trouble of reconstructing it each time. This message is to ask for advise on how to better accomplish this reuse. I tried reusing the whole environment for multiple requests, but I'm conjecturing that this might cause troubles when the requests require building modules with different values of -this-unit-id. Another problem that streams from this is that recompiling a module which defines a type class instance fails because it encounters in the environment the type class instance from the previous compilation. My work-in-progress implementation is here [1]. There appears to be multiple ways to compile a module in the API, so far I have been trying DriverPipeline.compileFile. My best lead right now is to look for inspiration in how GHCi implements the load command, but this does a sort of --make compilation while I'm going here for the one-shot style. Thanks in advance, Facundo [1] https://github.com/tweag/rules_haskell/blob/16ba422457ea4daa5dbf40d46327ebc…

2 3

Re: Overnight CI failures
by Bryan Richter 30 Sep '22

30 Sep '22

(Adding ghc-devs) Are these fragile tests? 1. T14346 got a "bad file descriptor" on Darwin 2. linker_unload got some gold errors on Linux Neither of these have been reported to me before, so I don't know much about them. Nor have I looked deeply (or at all) at the tests themselves, yet. On Thu, Sep 29, 2022 at 3:37 PM Simon Peyton Jones < simon.peytonjones(a)gmail.com> wrote: > Bryan > > These failed overnight > > On !8897 > > - https://gitlab.haskell.org/ghc/ghc/-/jobs/1185519 > - https://gitlab.haskell.org/ghc/ghc/-/jobs/1185520 > > I think it's extremely unlikely that this had anything to do with my patch. > > Simon >

1 0

Consistent CI failure in job nightly-i386-linux-deb9-validate
by Bryan Richter 29 Sep '22

29 Sep '22

Hi all, For the past week or so, nightly-i386-linux-deb9-validate has been failing consistently. They show up on the failure dashboard because the logs contain the phrase "Cannot allocate memory". I haven't looked yet to see if they always fail in the same place, but I'll do that soon. The first example I looked at, however, has the line "xz: (stdin): Cannot allocate memory", so it's not GHC (alone) causing the problem. As a consequence of showing up on the dashboard, the jobs get restarted. Since they fail consistently, they keep getting restarted. Since the jobs keep getting restarted, the pipelines stay alive. When I checked just now, there were 8 nightly runs still running. :) Thus I'm going to cancel the still-running nightly-i386-linux-deb9-validate jobs and let the pipelines die in peace. You can still find all examples of failed jobs on the dashboard: https://grafana.gitlab.haskell.org/d/167r9v6nk/ci-spurious-failures?orgId=2… To prevent future problems, it would be good if someone could help me look into this. Otherwise I'll just disable the job. :(

2 7

Pushing to nofib
by Simon Peyton Jones 27 Sep '22

27 Sep '22

Friends How do I push to the nofib/ repository? I just wanted to add some documentation. I'm on branch 'master' and tried to push. Got this below. What next? Thanks Simon bash$ git push Enumerating objects: 5, done. Counting objects: 100% (5/5), done. Delta compression using up to 24 threads Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 543 bytes | 543.00 KiB/s, done. Total 3 (delta 2), reused 0 (delta 0) remote: GitLab: You are not allowed to push code to protected branches on this project. To gitlab.haskell.org:ghc/nofib.git ! [remote rejected] master -> master (pre-receive hook declined) error: failed to push some refs to 'git@gitlab.haskell.org:ghc/nofib.git' simonpj@LHR-WD-22561:~/code/HEAD-1/nofib$

2 1

GItlab search
by Simon Peyton Jones 26 Sep '22

26 Sep '22

Friends I'm struggling with GitLab search. eg I was looking for #22200 I wen to https://gitlab.haskell.org/ghc/ghc/-/issues, and put "-DEEBUG" and "slow" in the search box. No #22200. Yet both of those strings appear in the title of the ticket. Looking for DEBUG or *DEBUG also fails. I find that DDEBUG succeeds. What are the rules? Thanks Simon

2 1

Tier 1 architectures
by Simon Peyton Jones 22 Sep '22

22 Sep '22

Ben, Matthew, Moritz, and friends Is this wiki page about architectures still accurate? https://gitlab.haskell.org/ghc/ghc/-/wikis/platforms For example, ARM is not Tier 1, or "apple silicon". Yet I know some of our developers have invested lots of effort in other architectures, so maybe those efforts are not reflected here. Relevant is Moritz's post about 32-bit architectures <https://discourse.haskell.org/t/running-project-built-on-raspberry-pi-with-…> . We should in due course add Javascript and Web Assembly as Tier 1 back ends? Are we saying "if your customer bases uses Tier 2 architectures, you can't rely on GHC from one release to the next"? I wonder if there are companies for which Tier-2 architectures are mission-critical. Mis-aligned expectations cause upset. I mention all this because it is relevant to our stability guarantees. Every time we release we should point to this list. Simon

3 2

Alternative to isTypeLevPoly
by Csaba Hruska 16 Sep '22

16 Sep '22

Hello GHC Devs, I've noticed that the `isTypeLevPoly` function has been removed from GHC since 9.4. I used it to decide the validity of querying the representation type of every value in the STG IR. It was mandatory to prevent GHC panics, because there are a lot of partial functions in GHC. Is there an alternative to `isTypeLevPoly` in GHC 9.4? Best regards, Csaba Hruska

4 7

Haskell program coverage
by Simon Peyton Jones 15 Sep '22

15 Sep '22

Matthias, David, David Binder <http://ps.informatik.uni-tuebingen.de/team/binder/>apparently has some PRs for GHC's HPC program coverage stuff that have somehow languished un-merged for some time. David, can you point us to them, so we can look? Matthias <https://github.com/Tritlo>wants to extend HPC in a number of ways. See here <https://github.mpg.is/posts/2022/04/26/better-hpc-traces.html>and here <https://github.com/ghc-proposals/ghc-proposals/pull/539>. Maybe you want to talk to each other? You are both here at ICFP! And it would be great to have a little team that cared about HPC more generally, and could look after it. Thanks. Apologies if I have misunderstood anyone. Simon

1 0

Runtime linker
by Lana Black 13 Sep '22

13 Sep '22

Hello, My personal project involves making a port of GHC for an almost bare-bones environment, which doesn't provide runtime linking support. GHC configure script sets `TargetHasRTSLinker` flag, but it seems to be ignored in RTS itself, and the linker is built regardless. Is this a regression, perhaps due to the migration from Makefiles to Hadrian? Or is building RTS without runtime linker no longer supported? Thank you.

2 2