From ben at smart-cactus.org Thu Nov 1 15:19:23 2018 From: ben at smart-cactus.org (Ben Gamari) Date: Thu, 01 Nov 2018 11:19:23 -0400 Subject: Validating with LLVM In-Reply-To: References: Message-ID: <875zxg25c9.fsf@smart-cactus.org> Travis Whitaker writes: > Hello GHC Devs, > > I'm working on a very tiny patch for GHC. The patch concerns the LLVM code > generator, and I'd like to run the validate script. ./validate ignores mk/ > build.mk (which is probably correct) and it doesn't seem to be using the > LLVM backend. LLVM tools are on the PATH; I'm working from the ghc-8.4 > branch so I'm using LLVM 5. > > Is it possible to validate with the LLVM backend? If not, what's considered > a sufficiently thorough test? Apologies if I'm missing something obvious. > The validate script doesn't support this directly. I would do the following: ./validate --build-only make test WAY=llvm That should do what you want (and IIRC is what we do in the LLVM CI script). Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From michal.terepeta at gmail.com Thu Nov 1 18:17:23 2018 From: michal.terepeta at gmail.com (Michal Terepeta) Date: Thu, 1 Nov 2018 19:17:23 +0100 Subject: [GHC DevOps Group] The future of Phabricator In-Reply-To: References: <87zhuw2fw2.fsf@smart-cactus.org> <2377A9DA-7459-4321-995D-EFB67D0104FE@justtesting.org> <87lg6f33my.fsf@smart-cactus.org> <87y3af1g3n.fsf@smart-cactus.org> Message-ID: Hope you don't mind if I add an opinion of a small/occasional contributor to the thread. Personally, I would prefer a move to GitHub. Mostly due to familiarity and network effect (pretty much everyone is on GitHub). But I would also consider a move to GitLab a big improvement over the current Phab-based setup. A git-based workflow would be great - I use arc/Phab too rarely to really invest in learning them better. (I just figured out the simplest way to use them that seems to work and I'm sticking to it :) I haven't actually used GitLab before, but it seems super easy to sign in using GitHub credentials and the interface seems quite familiar. One thing that was already mentioned is the ticket handling and I just wanted to say "+1". I *really* dislike Trac - it's slow, unintuitive and every time I use it I need to spend a couple of minutes to find the guide to its own weird version of markdown... So a better place for tickets that's tightly integrated with code code hosting/review tools would be really cool! Which brings an interesting aspect of this discussion - if I had to choose between "GitHub for code hosting/review & Trac for tickets" vs "GitLab for everything", I'd prefer the latter. - Michal On Tue, Oct 30, 2018 at 10:51 PM Boespflug, Mathieu wrote: > Hi Ben, > > On Tue, 30 Oct 2018 at 18:47, Ben Gamari wrote: > > > > ... > > > > It occurs to me that I never did sit down to write up my thoughts on > > reviewable. I tried doing a few reviews with it [1] and indeed it is > > quite good; in many ways it is comparable to Differential. [...] > > However, it really feels like a band-aid, introducing another layer of > > indirection and a distinct conversation venue all to make up for what > > are plain deficiencies in GitHub's core product. > > Sure. That sounds fine to me though, or indeed no different than say, > using GitHub XOR Gitlab for code hosting, Phabricator for review (and > only for that), and Trac for tickets (not ideal but no worse than > status quo). If Phabricator (the paid for hosted version) or > Reviewable.io really are the superior review tools, and if as review > tools they integrate seamlessy with GitHub (or Gitlab), then that's an > option worth considering. > > The important things are: reducing the maintenance burden (by > preferring hosted solutions) while still meeting developer > requirements and supporting a workflow that is familiar to most. > > > > So keeping the review UX issues aside for a moment, are there other > > > GitHub limitations that you anticipate would warrant automation bots à > > > la Rust-lang? > > > > > Ultimately Rust's tools all exist for a reason. Bors works around > > GitHub's lacking ability to merge-on-CI-pass, Highfive addresses the > > lack of a flexible code owner notification system, among other things. > > Both of these are features that we either have already or would like to > > have. > > ... and I assume based on your positive assessment, are both > out-of-the-box features of Gitlab that meet the requirements? > > > On the whole, I simply see very few advantages to using GitHub over > > GitLab; the latter simply seems to me to be a generally superior product. > > That may well be the case. The main argument for GitHub is taking > advantage of its network effect. But a big part of that is not having > to manage a new set of credentials elsewhere, as well as remembering > different user names for the same collaborators on different > platforms. You're saying I can use my GitHub credentials to > authenticate on Gitlab. So in the end we possibly wouldn't be losing > much of that network effect. > > > > I'm not too worried about the CI story. The hard part with CircleCI > > > isn't CircleCI, it's getting to a green CircleCI. But once we're > > > there, moving to a green OtherCI shouldn't be much work. > > > > > Right, and we are largely already there! > > That's great to hear. > _______________________________________________ > Ghc-devops-group mailing list > Ghc-devops-group at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devops-group > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yotam2206 at gmail.com Thu Nov 1 18:33:14 2018 From: yotam2206 at gmail.com (Yotam Ohad) Date: Thu, 1 Nov 2018 20:33:14 +0200 Subject: Hadrian build failed Message-ID: Hi, I'm trying to build with hadrian ( https://blogs.ncl.ac.uk/andreymokhov/building-ghc-on-windows/) I get an error when running: stack exec hadrian -- --directory ".." -j --flavour=quickest --configure md5sum: 'standard input': no properly formatted MD5 checksum lines found ERROR: mingw-w64-x86_64-crt-git-5.0.0.4795.e3d96cb1-1-any.pkg.tar.xz appears to be corrupted, please delete it and try again. ) Deleting and trying again results in the same error. Any idea on how to solve this? Yotam -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrey.mokhov at newcastle.ac.uk Thu Nov 1 19:57:01 2018 From: andrey.mokhov at newcastle.ac.uk (Andrey Mokhov) Date: Thu, 1 Nov 2018 19:57:01 +0000 Subject: Hadrian build failed In-Reply-To: References: <3f6ee543-f042-fc7f-f0e4-e2558f8c3f13@well-typed.com> Message-ID: Hello Yotam, Could you please report this as a bug on GHC Trac? https://ghc.haskell.org/trac/ghc/wiki/ReportABug I couldn’t quickly reproduce your issue, however, I run into another seemingly unrelated problem. P.S.: Note that build instructions in my blog post got slightly out of date after the Hadrian move – I’ve fixed this. Cheers, Andrey -------- Forwarded Message -------- Subject: Hadrian build failed Date: Thu, 1 Nov 2018 20:33:14 +0200 From: Yotam Ohad To: ghc-devs at haskell.org Hi, I'm trying to build with hadrian (https://blogs.ncl.ac.uk/andreymokhov/building-ghc-on-windows/) I get an error when running: stack exec hadrian -- --directory ".." -j --flavour=quickest --configure md5sum: 'standard input': no properly formatted MD5 checksum lines found ERROR: mingw-w64-x86_64-crt-git-5.0.0.4795.e3d96cb1-1-any.pkg.tar.xz appears to be corrupted, please delete it and try again. ) Deleting and trying again results in the same error. Any idea on how to solve this? Yotam -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Thu Nov 1 22:43:11 2018 From: ben at well-typed.com (Ben Gamari) Date: Thu, 01 Nov 2018 18:43:11 -0400 Subject: [GHC DevOps Group] The future of Phabricator In-Reply-To: References: <87zhuw2fw2.fsf@smart-cactus.org> <2377A9DA-7459-4321-995D-EFB67D0104FE@justtesting.org> <87lg6f33my.fsf@smart-cactus.org> <87y3af1g3n.fsf@smart-cactus.org> Message-ID: <87y3aczaf8.fsf@smart-cactus.org> "Boespflug, Mathieu" writes: > Hi Ben, > > On Tue, 30 Oct 2018 at 18:47, Ben Gamari wrote: ... > > The important things are: reducing the maintenance burden (by > preferring hosted solutions) while still meeting developer > requirements and supporting a workflow that is familiar to most. > Right; I believe that GitLab checks all of these boxes. >> Ultimately Rust's tools all exist for a reason. Bors works around >> GitHub's lacking ability to merge-on-CI-pass, Highfive addresses the >> lack of a flexible code owner notification system, among other things. >> Both of these are features that we either have already or would like to >> have. > > ... and I assume based on your positive assessment, are both > out-of-the-box features of Gitlab that meet the requirements? > Yes, GitLab has support for both of these features natively. >> On the whole, I simply see very few advantages to using GitHub over >> GitLab; the latter simply seems to me to be a generally superior product. > > That may well be the case. The main argument for GitHub is taking > advantage of its network effect. But a big part of that is not having > to manage a new set of credentials elsewhere, as well as remembering > different user names for the same collaborators on different > platforms. You're saying I can use my GitHub credentials to > authenticate on Gitlab. So in the end we possibly wouldn't be losing > much of that network effect. > Precisely, GitLab supports OAuth authentication, so one can login with GitHub credentials. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ben at smart-cactus.org Thu Nov 1 22:43:37 2018 From: ben at smart-cactus.org (Ben Gamari) Date: Thu, 01 Nov 2018 18:43:37 -0400 Subject: [GHC DevOps Group] The future of Phabricator In-Reply-To: References: <87zhuw2fw2.fsf@smart-cactus.org> <2377A9DA-7459-4321-995D-EFB67D0104FE@justtesting.org> <87lg6f33my.fsf@smart-cactus.org> <87y3af1g3n.fsf@smart-cactus.org> Message-ID: <87va5gzaeg.fsf@smart-cactus.org> Michal Terepeta writes: > Hope you don't mind if I add an opinion of a small/occasional > contributor to the thread. > > Personally, I would prefer a move to GitHub. Mostly due to familiarity > and network effect (pretty much everyone is on GitHub). > > But I would also consider a move to GitLab a big improvement over the > current Phab-based setup. A git-based workflow would be great - I use > arc/Phab too rarely to really invest in learning them better. (I just > figured out the simplest way to use them that seems to work and I'm > sticking to it :) I haven't actually used GitLab before, but it seems > super easy to sign in using GitHub credentials and the interface seems > quite familiar. > > One thing that was already mentioned is the ticket handling and I just > wanted to say "+1". I *really* dislike Trac - it's slow, unintuitive and > every time I use it I need to spend a couple of minutes to find the > guide to its own weird version of markdown... So a better place for > tickets that's tightly integrated with code code hosting/review tools > would be really cool! Which brings an interesting aspect of this > discussion - if I had to choose between "GitHub for code hosting/review > & Trac for tickets" vs "GitLab for everything", I'd prefer the latter. > Thanks for this data point, Michal! Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From vladislav at serokell.io Thu Nov 1 23:27:15 2018 From: vladislav at serokell.io (Vladislav Zavialov) Date: Fri, 2 Nov 2018 02:27:15 +0300 Subject: [GHC DevOps Group] The future of Phabricator In-Reply-To: <87va5gzaeg.fsf@smart-cactus.org> References: <87zhuw2fw2.fsf@smart-cactus.org> <2377A9DA-7459-4321-995D-EFB67D0104FE@justtesting.org> <87lg6f33my.fsf@smart-cactus.org> <87y3af1g3n.fsf@smart-cactus.org> <87va5gzaeg.fsf@smart-cactus.org> Message-ID: To put my 2¢ – I will be happy with whatever service provides the most reliable CI. In terms of workflow, I like Ben's suggestion: * Consider a PR to be a stack of differentials, with each commit being an atomic change in that stack. From carter.schonwald at gmail.com Thu Nov 1 23:34:01 2018 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Thu, 1 Nov 2018 19:34:01 -0400 Subject: [GHC DevOps Group] The future of Phabricator In-Reply-To: References: <87zhuw2fw2.fsf@smart-cactus.org> <2377A9DA-7459-4321-995D-EFB67D0104FE@justtesting.org> <87lg6f33my.fsf@smart-cactus.org> <87y3af1g3n.fsf@smart-cactus.org> <87va5gzaeg.fsf@smart-cactus.org> Message-ID: For what it’s worth, I’ve never found phab / arc to be the bottle neck / actual time consuming piece of doing anything for ghc It’s defintely the nicest code review substrate I’ve engaged with One question I have : how does the llvm org manage / handle their phabricator instance and or ci substrate. Maybe they have wisdom that can help ? On Thu, Nov 1, 2018 at 7:27 PM Vladislav Zavialov wrote: > To put my 2¢ – I will be happy with whatever service provides the most > reliable CI. > > In terms of workflow, I like Ben's suggestion: > > * Consider a PR to be a stack of differentials, with each commit > being an atomic change in that stack. > _______________________________________________ > 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 ben at smart-cactus.org Fri Nov 2 00:42:32 2018 From: ben at smart-cactus.org (Ben Gamari) Date: Thu, 01 Nov 2018 20:42:32 -0400 Subject: [GHC DevOps Group] The future of Phabricator In-Reply-To: References: <87zhuw2fw2.fsf@smart-cactus.org> <2377A9DA-7459-4321-995D-EFB67D0104FE@justtesting.org> <87lg6f33my.fsf@smart-cactus.org> <87y3af1g3n.fsf@smart-cactus.org> <87va5gzaeg.fsf@smart-cactus.org> Message-ID: <87muqsz4wc.fsf@smart-cactus.org> Carter Schonwald writes: > For what it’s worth, I’ve never found phab / arc to be the bottle neck / > actual time consuming piece of doing anything for ghc > > It’s defintely the nicest code review substrate I’ve engaged with > > One question I have : how does the llvm org manage / handle their > phabricator instance and or ci substrate. Maybe they have wisdom that can > help ? > LLVM uses Jenkins primarily for CI; it is not integrated with their Phabricator instance. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From marlowsd at gmail.com Fri Nov 2 08:13:37 2018 From: marlowsd at gmail.com (Simon Marlow) Date: Fri, 2 Nov 2018 08:13:37 +0000 Subject: [GHC DevOps Group] The future of Phabricator In-Reply-To: <87tvl31bps.fsf@smart-cactus.org> References: <87zhuw2fw2.fsf@smart-cactus.org> <87tvl31bps.fsf@smart-cactus.org> Message-ID: What about the wiki? Can we migrate that off Trac too? We'd have to keep redirects in place on ghc.haskell.org to avoid breaking links to tickets and wiki pages from elsewhere. If we really can do a stacked-diff-style workflow using PRs on GitLab then that at least for me removes one of the big drawbacks of moving. But how easy will it be to enforce that workflow and will it be going against the grain on GitLab? I imagine people used to adding extra commits to a PR will tend to do that rather than amending+rebasing. I suppose we can do a squash-merge when committing to keep the history clean, but then contributors have a choice - either do GitHub-style where you add commits to a PR to update it and we squash on merge, OR Phabricator-style where you keep the same set of commits and rebase the stack to update it. If you want to do dependent commits then you have to use Phabricator style. Choices between workflows make things more complicated for contributors, and that worries me. Does GitLab keep the history of a PR after it has been updated, like in Phabricator? So we can see what happened between versions of a PR? Cheers Simon On Tue, 30 Oct 2018 at 19:22, Ben Gamari wrote: > Simon Marlow writes: > > > I'm entirely happy to move, provided (1) whatever we move to provides the > > functionality we need, and (2) it's clearly what the community wants > > (considering both current and future contributors). In the past when > moving > > to GitHub was brought up, there were a handful of core contributors who > > argued strongly in favour of Phabricator, do we think that's changed? Do > we > > have any indication of whether the survey respondents who were > > anti-Phabricator would be pro- or anti-GitLab? > > > The comments fell into several buckets: > > a. Those who spoke in favor of GitHub in particular > b. Those who spoke in favor of GitHub and GitLab > c. Those who spoke against Phabricator > > I seem to recall that (a) was the largest group. No one explicitly > stated that they would be against GitLab, although this is not terribly > surprising given we didn't ask. > > Frankly I doubt there would be people who would actively support GitHub > but not GitLab given how similar the workflows are. However, collecting > data for this hunch is one of the reasons for this thread. > > > Personally I'd like to optimise for more code review, because I think > that > > more than anything else will increase quality and community ownership of > > the project. If using new tooling will make code review a more central > part > > of our workflow, then that would be a good thing. > > Agreed, currently we have too few reviewers for the volume of code we > are pushing into the tree. > > > Right now I think we're > > very Trac-centric, and the integration between Trac and Phabricator isn't > > great; if we could move to a solution with tighter integration between > > tickets/code-review/wiki, that would be an improvement in my view. But > not > > GitHub, for the reasons you gave. > > > Yes, I agree. Currently I spend too much time keeping tickets in sync and > this is almost entirely wasted time. > > > > Would GitLab solve the CI issues? I don't think you mentioned that > > explicitly. > > > It helps, yes. As Andres pointed out, Appveyor has native support for > GitLab, which we use for Windows validation. Furthermore, GitLab's > native CI would allow us to test non-x86 platforms. > > CircleCI lacks GitLab support however I believe the integration we have > already developed to support integration with Phabricator could be > easily adapted for GitLab. > > Moreover, given that the "Add GitLab support" request is at the top of > CircleCI's feature request tracker, it seems likely that there will be > native support in the future. > > Cheers, > > - Ben > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From imantc at gmail.com Fri Nov 2 08:24:03 2018 From: imantc at gmail.com (Imants Cekusins) Date: Fri, 2 Nov 2018 09:24:03 +0100 Subject: [GHC DevOps Group] The future of Phabricator In-Reply-To: References: <87zhuw2fw2.fsf@smart-cactus.org> <87tvl31bps.fsf@smart-cactus.org> Message-ID: Are other alternatives being considered? You may find these examples relevant: TFS https://visualstudio.microsoft.com/tfs/ (Git repos is an option) Atlassian https://www.atlassian.com/ Atlassian offers rich set of integrated products. https://www.atlassian.com/software/views/open-source-license-request -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvriedel at gmail.com Fri Nov 2 08:59:15 2018 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Fri, 02 Nov 2018 09:59:15 +0100 Subject: [GHC DevOps Group] The future of Phabricator In-Reply-To: (Simon Marlow's message of "Fri, 2 Nov 2018 08:13:37 +0000") References: <87zhuw2fw2.fsf@smart-cactus.org> <87tvl31bps.fsf@smart-cactus.org> Message-ID: <87tvkzsvmk.fsf@gmail.com> On 2018-11-02 at 08:13:37 +0000, Simon Marlow wrote: > What about the wiki? Can we migrate that off Trac too? I worry that it's a lot of work to migrate it away while preserving the special markup and features that Trac provides; so the resulting pages will require a significant amount of manual cleanup and finding ways to emulate the previous features; for instance, I've been using features like https://ghc.haskell.org/trac/ghc/wiki/WikiBoxes a lot as they allow to highlight important information and footnote-like annotations in; and thus IMO help contribute to present the information less wall-of-text-ish which is harder to digest. [...] > I suppose we can do a squash-merge when committing to keep the history > clean, but then contributors have a choice - either do GitHub-style > where you add commits to a PR to update it and we squash on merge, OR > Phabricator-style where you keep the same set of commits and rebase > the stack to update it. (Minor nitpick: in GitLab there are no pull-requests (PRs) anymore; they're called "MRs" for "merge-request", which is probably a more accurate term to describe the concept than "PR" is) Well, if MRs are to be squashed on merge anyway, I'm definitely not going to waste my time carefully grooming a stack of atomic individually validating commits via git-rebase-interactive... > If you want to do dependent commits then you have to use Phabricator > style. Choices between workflows make things more complicated for > contributors, and that worries me. ...submitting a stacked set of commits as invidual overlapping MRs (i.e. where the first MR has only the first commit, the 2nd has the first two commits from the stack, and so on) -- if that's what you're referring to as "Phabricator-style" -- sounds like an awkward workflow to me. > Does GitLab keep the history of a PR after it has been updated, like in > Phabricator? So we can see what happened between versions of a PR? I wonder too how this is represented in GitLab... especially when a MR is comprised of multiple commits, and those individual commits evolve, might get reordered, commits added or removed fromt he stack, or when the whole MR gets rebased in the process... From arian.vanputten at gmail.com Fri Nov 2 09:23:11 2018 From: arian.vanputten at gmail.com (Arian van Putten) Date: Fri, 2 Nov 2018 10:23:11 +0100 Subject: [GHC DevOps Group] The future of Phabricator In-Reply-To: <87tvkzsvmk.fsf@gmail.com> References: <87zhuw2fw2.fsf@smart-cactus.org> <87tvl31bps.fsf@smart-cactus.org> <87tvkzsvmk.fsf@gmail.com> Message-ID: Once you rebase you simply move the branch pointer to a new chain of commits (they're rewritten because of the rebase, and thus have different hashes), however the old version of the branch still exists in the reflog. So locally you can definitely see your previous versions of your 'commit stack' by just pointing the branch pointer to the old commit hash or checking out that commit hash directly. However as far as I'm aware neither GitHub and gitlab expose this in their UI. On Fri, Nov 2, 2018, 09:59 Herbert Valerio Riedel On 2018-11-02 at 08:13:37 +0000, Simon Marlow wrote: > > > What about the wiki? Can we migrate that off Trac too? > > I worry that it's a lot of work to migrate it away while preserving the > special markup and features that Trac provides; so the resulting pages > will require a significant amount of manual cleanup and finding ways to > emulate the previous features; for instance, I've been using features > like https://ghc.haskell.org/trac/ghc/wiki/WikiBoxes a lot as they allow > to highlight important information and footnote-like annotations in; and > thus IMO help contribute to present the information less > wall-of-text-ish which is harder to digest. > > [...] > > > I suppose we can do a squash-merge when committing to keep the history > > clean, but then contributors have a choice - either do GitHub-style > > where you add commits to a PR to update it and we squash on merge, OR > > Phabricator-style where you keep the same set of commits and rebase > > the stack to update it. > > (Minor nitpick: in GitLab there are no pull-requests (PRs) anymore; > they're called "MRs" for "merge-request", which is probably a more > accurate term to describe the concept than "PR" is) > > Well, if MRs are to be squashed on merge anyway, I'm definitely not > going to waste my time carefully grooming a stack of atomic individually > validating commits via git-rebase-interactive... > > > If you want to do dependent commits then you have to use Phabricator > > style. Choices between workflows make things more complicated for > > contributors, and that worries me. > > ...submitting a stacked set of commits as invidual overlapping MRs > (i.e. where the first MR has only the first commit, the 2nd has the > first two commits from the stack, and so on) -- if that's what you're > referring to as "Phabricator-style" -- sounds like an awkward workflow > to me. > > > Does GitLab keep the history of a PR after it has been updated, like in > > Phabricator? So we can see what happened between versions of a PR? > > I wonder too how this is represented in GitLab... especially when a MR > is comprised of multiple commits, and those individual commits evolve, > might get reordered, commits added or removed fromt he stack, or when > the whole MR gets rebased in the process... > _______________________________________________ > 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 ben at well-typed.com Fri Nov 2 12:47:56 2018 From: ben at well-typed.com (Ben Gamari) Date: Fri, 02 Nov 2018 08:47:56 -0400 Subject: [GHC DevOps Group] The future of Phabricator In-Reply-To: References: <87zhuw2fw2.fsf@smart-cactus.org> <87tvl31bps.fsf@smart-cactus.org> Message-ID: <875zxfzlvs.fsf@smart-cactus.org> Simon Marlow writes: > What about the wiki? Can we migrate that off Trac too? > Yes, we certainly can. As Herbert mentioned, some of the fancier markup in Trac will require a bit of manual grooming. However, the basic idea is easily implemented with the migration that I already developed. > We'd have to keep redirects in place on ghc.haskell.org to avoid breaking > links to tickets and wiki pages from elsewhere. > Yes, absolutely. > If we really can do a stacked-diff-style workflow using PRs on GitLab then > that at least for me removes one of the big drawbacks of moving. But how > easy will it be to enforce that workflow and will it be going against the > grain on GitLab? I imagine people used to adding extra commits to a PR will > tend to do that rather than amending+rebasing. I suppose we can do a > squash-merge when committing to keep the history clean, but then > contributors have a choice - either do GitHub-style where you add commits > to a PR to update it and we squash on merge, OR Phabricator-style where you > keep the same set of commits and rebase the stack to update it. If you want > to do dependent commits then you have to use Phabricator style. Choices > between workflows make things more complicated for contributors, and that > worries me. > This shouldn't be a problem. One can easily configure a project such that users are *only* allowed to fast-forward/rebase, disallowing the creation of merge commits. > Does GitLab keep the history of a PR after it has been updated, like in > Phabricator? So we can see what happened between versions of a PR? > Yes it does. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ben at smart-cactus.org Fri Nov 2 13:46:13 2018 From: ben at smart-cactus.org (Ben Gamari) Date: Fri, 02 Nov 2018 09:46:13 -0400 Subject: [GHC DevOps Group] The future of Phabricator In-Reply-To: <87tvkzsvmk.fsf@gmail.com> References: <87zhuw2fw2.fsf@smart-cactus.org> <87tvl31bps.fsf@smart-cactus.org> <87tvkzsvmk.fsf@gmail.com> Message-ID: <871s83zj6m.fsf@smart-cactus.org> Herbert Valerio Riedel writes: > On 2018-11-02 at 08:13:37 +0000, Simon Marlow wrote: > >> What about the wiki? Can we migrate that off Trac too? > > I worry that it's a lot of work to migrate it away while preserving the > special markup and features that Trac provides; so the resulting pages > will require a significant amount of manual cleanup and finding ways to > emulate the previous features; for instance, I've been using features > like https://ghc.haskell.org/trac/ghc/wiki/WikiBoxes a lot as they allow > to highlight important information and footnote-like annotations in; and > thus IMO help contribute to present the information less > wall-of-text-ish which is harder to digest. > > [...] > >> I suppose we can do a squash-merge when committing to keep the history >> clean, but then contributors have a choice - either do GitHub-style >> where you add commits to a PR to update it and we squash on merge, OR >> Phabricator-style where you keep the same set of commits and rebase >> the stack to update it. > > (Minor nitpick: in GitLab there are no pull-requests (PRs) anymore; > they're called "MRs" for "merge-request", which is probably a more > accurate term to describe the concept than "PR" is) > > Well, if MRs are to be squashed on merge anyway, I'm definitely not > going to waste my time carefully grooming a stack of atomic individually > validating commits via git-rebase-interactive... > >> If you want to do dependent commits then you have to use Phabricator >> style. Choices between workflows make things more complicated for >> contributors, and that worries me. > > ...submitting a stacked set of commits as invidual overlapping MRs > (i.e. where the first MR has only the first commit, the 2nd has the > first two commits from the stack, and so on) -- if that's what you're > referring to as "Phabricator-style" -- sounds like an awkward workflow > to me. > Right this is not the workflow I would advocate. Rather, just submit a single MR with your atomic changes represented as commits. In fact, this is already what I do locally when preparing stacked Phabricator differentials (to put another way, one commit == one differential). GitLab has good support for reviewing commit-by-commit. >> Does GitLab keep the history of a PR after it has been updated, like in >> Phabricator? So we can see what happened between versions of a PR? > > I wonder too how this is represented in GitLab... especially when a MR > is comprised of multiple commits, and those individual commits evolve, > might get reordered, commits added or removed fromt he stack, or when > the whole MR gets rebased in the process... To be clear, GitLab saves each head commit that you push to an MR branch. These iterations are known in the review interface as "versions". The review interface then allows you to view differences between either a. any two versions b. any version and the target branch (e.g. master) Unfortunately (but perhaps not unexpectedly) this scheme does not deal well with changes due to a change in base commit (as would happen in the case of rebasing). It appears that GitLab must just run `git diff` between the two heads when asked to compare two versions of a MR. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ben at smart-cactus.org Fri Nov 2 13:55:50 2018 From: ben at smart-cactus.org (Ben Gamari) Date: Fri, 02 Nov 2018 09:55:50 -0400 Subject: [GHC DevOps Group] The future of Phabricator In-Reply-To: References: <87zhuw2fw2.fsf@smart-cactus.org> <87tvl31bps.fsf@smart-cactus.org> <87tvkzsvmk.fsf@gmail.com> Message-ID: <87y3aby464.fsf@smart-cactus.org> Arian van Putten writes: > Once you rebase you simply move the branch pointer to a new chain of > commits (they're rewritten because of the rebase, and thus have different > hashes), however the old version of the branch still exists in the reflog. > So locally you can definitely see your previous versions of your 'commit > stack' by just pointing the branch pointer to the old commit hash or > checking out that commit hash directly. However as far as I'm aware neither > GitHub and gitlab expose this in their UI. > As pointed out earlier in the thread, GitLab does expose this in its UI [1] Cheers, - Ben [1] https://gitlab.com/gitlab-org/gitlab-ce/issues/13570 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ben at smart-cactus.org Fri Nov 2 14:01:16 2018 From: ben at smart-cactus.org (Ben Gamari) Date: Fri, 02 Nov 2018 10:01:16 -0400 Subject: [GHC DevOps Group] The future of Phabricator In-Reply-To: References: <87zhuw2fw2.fsf@smart-cactus.org> <87tvl31bps.fsf@smart-cactus.org> Message-ID: <87tvkzy3x2.fsf@smart-cactus.org> Imants Cekusins writes: > Are other alternatives being considered? > I generally focused on GitHub and GitLab as these are the two options that are widely used in the open-source community and received the most attention in our survey results. > You may find these examples relevant: > > TFS > https://visualstudio.microsoft.com/tfs/ (Git repos is an option) > It seems the server requires a Windows machine to run. I consider this to be an immediate dealbreaker. > Atlassian > https://www.atlassian.com/ I have worked with Atlassian products in the past and have not found them to be convenient to use. Furthermore, neither of these options are open source, which raises some serious lock-in concerns. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ben at smart-cactus.org Fri Nov 2 14:07:18 2018 From: ben at smart-cactus.org (Ben Gamari) Date: Fri, 02 Nov 2018 10:07:18 -0400 Subject: [GHC DevOps Group] The future of Phabricator In-Reply-To: <871s83zj6m.fsf@smart-cactus.org> References: <87zhuw2fw2.fsf@smart-cactus.org> <87tvl31bps.fsf@smart-cactus.org> <87tvkzsvmk.fsf@gmail.com> <871s83zj6m.fsf@smart-cactus.org> Message-ID: <87r2g3y3mz.fsf@smart-cactus.org> Ben Gamari writes: > Herbert Valerio Riedel writes: > ... >> I wonder too how this is represented in GitLab... especially when a MR >> is comprised of multiple commits, and those individual commits evolve, >> might get reordered, commits added or removed fromt he stack, or when >> the whole MR gets rebased in the process... > > To be clear, GitLab saves each head commit that you push to an MR > branch. These iterations are known in the review interface as "versions". > The review interface then allows you to view differences between either > > a. any two versions > b. any version and the target branch (e.g. master) > > Unfortunately (but perhaps not unexpectedly) this scheme does not deal > well with changes due to a change in base commit (as would happen in the > case of rebasing). It appears that GitLab must just run `git diff` > between the two heads when asked to compare two versions of a MR. > It sounds as though this is something on upstream's radar as something to improve upon in the near future [1]. Cheers, - Ben [1] https://gitlab.com/gitlab-org/gitlab-ce/issues/23269 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ben at well-typed.com Fri Nov 2 17:00:44 2018 From: ben at well-typed.com (Ben Gamari) Date: Fri, 02 Nov 2018 13:00:44 -0400 Subject: Visible dependent quantification / CUSKs In-Reply-To: References: Message-ID: <87d0rnxvly.fsf@smart-cactus.org> Richard Eisenberg writes: > Hi all, > > I see visible dependent quantification and top-level kind signatures > on the release plan for GHC 8.8. Is there a diff for these I've > missed? Or is something in the works? > I don't believe so; it sounds like this was just a mistake. If anyone was to know about these happening I would expect it to be you. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From rae at cs.brynmawr.edu Fri Nov 2 18:39:34 2018 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Fri, 2 Nov 2018 14:39:34 -0400 Subject: Visible dependent quantification / CUSKs In-Reply-To: <87d0rnxvly.fsf@smart-cactus.org> References: <87d0rnxvly.fsf@smart-cactus.org> Message-ID: Feared as much. I'd love for these to be implemented and was excited to see them listed! I do expect to implement these some day. But certainly not for 8.8. Thanks, Richard > On Nov 2, 2018, at 1:00 PM, Ben Gamari wrote: > > Richard Eisenberg writes: > >> Hi all, >> >> I see visible dependent quantification and top-level kind signatures >> on the release plan for GHC 8.8. Is there a diff for these I've >> missed? Or is something in the works? >> > I don't believe so; it sounds like this was just a mistake. If anyone > was to know about these happening I would expect it to be you. > > Cheers, > > - Ben > From csaba.hruska at gmail.com Fri Nov 2 21:18:49 2018 From: csaba.hruska at gmail.com (Csaba Hruska) Date: Fri, 2 Nov 2018 22:18:49 +0100 Subject: multiple top level Main.main binders in STG Message-ID: Hello, I added an STG exporter to my modified GHC to do experiments with the STG representation of the program. I noticed that there are multiple top-level binders for *Main.main* function. Is this a convention or a bug? Regards, Csaba Hruska Here is an example code snippet of the exported STG of the Main module: Main.main2 = closure (F:) (B:) { case Main.$wupto 1# 10000000# of sat.s16537 { DEFAULT -> case Main.$wxsum 0# sat.s16537 of ww.s16538 { DEFAULT -> case GHC.Show.$wshowSignedInt 0# ww.s16538 GHC.Types.[] of ww4.s16539 { GHC.Prim.(#,#) ww5.s16540 ww6.s16541 -> GHC.Types.: ww5.s16540 ww6.s16541 } } }} Main.main1 = closure (F:) (B: void.040) { GHC.IO.Handle.Text.hPutStr2 GHC.IO.Handle.FD.stdout Main.main2 GHC.Types.True GHC.Prim.void#} *Main.main* = closure (F:) (B: void.040) { Main.main1 GHC.Prim.void#} Main.main3 = closure (F:) (B: void.040) { GHC.TopHandler.runMainIO1 Main.main1 GHC.Prim.void#} *Main.main* = closure (F:) (B: void.040) { Main.main3 GHC.Prim.void#} -------------- next part -------------- An HTML attachment was scrubbed... URL: From csaba.hruska at gmail.com Fri Nov 2 21:50:27 2018 From: csaba.hruska at gmail.com (Csaba Hruska) Date: Fri, 2 Nov 2018 22:50:27 +0100 Subject: multiple top level Main.main binders in STG References: Message-ID: P.S. I'd like to emphasize that this is produced by GHC and GHC's codegen compiles it properly to a working executable. On Fri, Nov 2, 2018 at 10:18 PM Csaba Hruska wrote: > Hello, > > I added an STG exporter to my modified GHC to do experiments with the STG > representation of the program. > I noticed that there are multiple top-level binders for *Main.main* > function. > Is this a convention or a bug? > > Regards, > Csaba Hruska > > Here is an example code snippet of the exported STG of the Main module: > Main.main2 = > closure (F:) (B:) { > case Main.$wupto 1# 10000000# > of sat.s16537 { > DEFAULT -> > case Main.$wxsum 0# sat.s16537 > of ww.s16538 { > DEFAULT -> > case GHC.Show.$wshowSignedInt > 0# ww.s16538 GHC.Types.[] > of ww4.s16539 { > GHC.Prim.(#,#) ww5.s16540 ww6.s16541 -> > GHC.Types.: > ww5.s16540 ww6.s16541 > } > } > }} > > Main.main1 = > closure (F:) (B: void.040) { > GHC.IO.Handle.Text.hPutStr2 > GHC.IO.Handle.FD.stdout > Main.main2 > GHC.Types.True > GHC.Prim.void#} > > *Main.main* = > closure (F:) (B: void.040) { > Main.main1 GHC.Prim.void#} > > Main.main3 = > closure (F:) (B: void.040) { > GHC.TopHandler.runMainIO1 > Main.main1 GHC.Prim.void#} > > *Main.main* = > closure (F:) (B: void.040) { > Main.main3 GHC.Prim.void#} > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Fri Nov 2 22:18:22 2018 From: ben at well-typed.com (Ben Gamari) Date: Fri, 02 Nov 2018 18:18:22 -0400 Subject: multiple top level Main.main binders in STG In-Reply-To: References: Message-ID: <8736sjxgwm.fsf@smart-cactus.org> Csaba Hruska writes: > Hello, > > I added an STG exporter to my modified GHC to do experiments with the STG > representation of the program. > I noticed that there are multiple top-level binders for *Main.main* > function. > Is this a convention or a bug? > What GHC command line did you use to produce this output? Is it possible that you passed -dsuppress-uniques? If so the multiple `main`s probably differ in unique. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From csaba.hruska at gmail.com Fri Nov 2 22:35:15 2018 From: csaba.hruska at gmail.com (Csaba Hruska) Date: Fri, 2 Nov 2018 23:35:15 +0100 Subject: multiple top level Main.main binders in STG In-Reply-To: <8736sjxgwm.fsf@smart-cactus.org> References: <8736sjxgwm.fsf@smart-cactus.org> Message-ID: Unfortunately it is dumped by my custom added code. (source code ) I rerun my custom stg dump and it seems the unique values (in {--} comments) are different. How can I tell which is the real *Main.main* function? Cheers, Csaba *Main.main {-r1550-}* = closure (F:) (B: void.040 {-040-}) { Main.main1 {-r16514-} GHC.Prim.void# {-021-}} Main.main3 {-r16518-} = closure (F:) (B: void.040 {-040-}) { GHC.TopHandler.runMainIO1 {-r9161-} Main.main1 {-r16514-} GHC.Prim.void# {-021-}} *Main.main {-0101-}* = closure (F:) (B: void.040 {-040-}) { Main.main3 {-r16518-} GHC.Prim.void# {-021-}} On Fri, Nov 2, 2018 at 11:18 PM Ben Gamari wrote: > Csaba Hruska writes: > > > Hello, > > > > I added an STG exporter to my modified GHC to do experiments with the STG > > representation of the program. > > I noticed that there are multiple top-level binders for *Main.main* > > function. > > Is this a convention or a bug? > > > What GHC command line did you use to produce this output? Is it possible > that you passed -dsuppress-uniques? If so the multiple `main`s probably > differ in unique. > > Cheers, > > - Ben > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From csaba.hruska at gmail.com Sat Nov 3 08:53:30 2018 From: csaba.hruska at gmail.com (Csaba Hruska) Date: Sat, 3 Nov 2018 09:53:30 +0100 Subject: StgRhsClosure freevar and argument name duplicates Message-ID: Hi, Can StgRhsClosure's freevar list ([occ]) or argument list ([bndr]) contain duplicates? Cheers, Csaba data GenStgRhs bndr occ = StgRhsClosure CostCentreStack -- CCS to be attached (default is CurrentCCS) StgBinderInfo -- Info about how this binder is used (see below) *[occ]* -- non-global free vars; a list, rather than -- a set, because order is important !UpdateFlag -- ReEntrant | Updatable | SingleEntry *[bndr]* -- arguments; if empty, then not a function; -- as above, order is important. (GenStgExpr bndr occ) -- body -------------- next part -------------- An HTML attachment was scrubbed... URL: From marlowsd at gmail.com Sat Nov 3 10:59:15 2018 From: marlowsd at gmail.com (Simon Marlow) Date: Sat, 3 Nov 2018 10:59:15 +0000 Subject: [GHC DevOps Group] The future of Phabricator In-Reply-To: <87tvkzsvmk.fsf@gmail.com> References: <87zhuw2fw2.fsf@smart-cactus.org> <87tvl31bps.fsf@smart-cactus.org> <87tvkzsvmk.fsf@gmail.com> Message-ID: On Fri, 2 Nov 2018 at 08:59, Herbert Valerio Riedel wrote: > On 2018-11-02 at 08:13:37 +0000, Simon Marlow wrote: > > > I suppose we can do a squash-merge when committing to keep the history > > clean, but then contributors have a choice - either do GitHub-style > > where you add commits to a PR to update it and we squash on merge, OR > > Phabricator-style where you keep the same set of commits and rebase > > the stack to update it. > [..] > > Well, if MRs are to be squashed on merge anyway, I'm definitely not > going to waste my time carefully grooming a stack of atomic individually > validating commits via git-rebase-interactive... > Sorry I wasn't very clear. We would *only* squash if the author had been using the workflow where they add commits to revise the MR. If the author wants to use the stacked-diff-like workflow where they keep a groomed set of commits in the MR, then we would rebase and fast-forward the MR. My concern here is that we have two different workflows. People used to GitHub would want to use one, and people used to Phabricator would want to use the other. We have to check which workflow people are using so that we can decide whether to squash on merge or not. Ben said: > This shouldn't be a problem. One can easily configure a project such that users are *only* allowed to fast-forward/rebase, disallowing the creation of merge commits. but that doesn't fully address the problem, because the series of commits that would get rebased onto master would include all the commits added to the MR to update it during the review process. Actually what we wanted to do in this case was squash, not rebase+fast-forward. If there was a nice way to guide people into using the Phabricator-style workflow, I think that would help a lot. Cheers Simon > > > If you want to do dependent commits then you have to use Phabricator > > style. Choices between workflows make things more complicated for > > contributors, and that worries me. > > ...submitting a stacked set of commits as invidual overlapping MRs > (i.e. where the first MR has only the first commit, the 2nd has the > first two commits from the stack, and so on) -- if that's what you're > referring to as "Phabricator-style" -- sounds like an awkward workflow > to me. > > > Does GitLab keep the history of a PR after it has been updated, like in > > Phabricator? So we can see what happened between versions of a PR? > > I wonder too how this is represented in GitLab... especially when a MR > is comprised of multiple commits, and those individual commits evolve, > might get reordered, commits added or removed fromt he stack, or when > the whole MR gets rebased in the process... > _______________________________________________ > 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 alan.zimm at gmail.com Sat Nov 3 13:17:43 2018 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Sat, 3 Nov 2018 15:17:43 +0200 Subject: [GHC DevOps Group] The future of Phabricator In-Reply-To: References: <87zhuw2fw2.fsf@smart-cactus.org> <87tvl31bps.fsf@smart-cactus.org> <87tvkzsvmk.fsf@gmail.com> Message-ID: As part of the silent bystander grouping, I just want to voice a weak ok for switching to gitlab, especially as a way to eventually bring the code, issues, wiki, etc into one place. To me the main benefit is that it is open source, allows own deployments and is under active development, which means that we can address any shortcomings it may have over time. Alan On Sat, 3 Nov 2018 at 12:59, Simon Marlow wrote: > On Fri, 2 Nov 2018 at 08:59, Herbert Valerio Riedel > wrote: > >> On 2018-11-02 at 08:13:37 +0000, Simon Marlow wrote: >> >> > I suppose we can do a squash-merge when committing to keep the history >> > clean, but then contributors have a choice - either do GitHub-style >> > where you add commits to a PR to update it and we squash on merge, OR >> > Phabricator-style where you keep the same set of commits and rebase >> > the stack to update it. >> [..] >> >> Well, if MRs are to be squashed on merge anyway, I'm definitely not >> going to waste my time carefully grooming a stack of atomic individually >> validating commits via git-rebase-interactive... >> > > Sorry I wasn't very clear. We would *only* squash if the author had been > using the workflow where they add commits to revise the MR. If the author > wants to use the stacked-diff-like workflow where they keep a groomed set > of commits in the MR, then we would rebase and fast-forward the MR. > > My concern here is that we have two different workflows. People used to > GitHub would want to use one, and people used to Phabricator would want to > use the other. We have to check which workflow people are using so that we > can decide whether to squash on merge or not. > > Ben said: > > > This shouldn't be a problem. One can easily configure a project such > that users are *only* allowed to fast-forward/rebase, disallowing the > creation of merge commits. > > but that doesn't fully address the problem, because the series of commits > that would get rebased onto master would include all the commits added to > the MR to update it during the review process. Actually what we wanted to > do in this case was squash, not rebase+fast-forward. > > If there was a nice way to guide people into using the Phabricator-style > workflow, I think that would help a lot. > > Cheers > Simon > > > >> >> > If you want to do dependent commits then you have to use Phabricator >> > style. Choices between workflows make things more complicated for >> > contributors, and that worries me. >> >> ...submitting a stacked set of commits as invidual overlapping MRs >> (i.e. where the first MR has only the first commit, the 2nd has the >> first two commits from the stack, and so on) -- if that's what you're >> referring to as "Phabricator-style" -- sounds like an awkward workflow >> to me. >> >> > Does GitLab keep the history of a PR after it has been updated, like in >> > Phabricator? So we can see what happened between versions of a PR? >> >> I wonder too how this is represented in GitLab... especially when a MR >> is comprised of multiple commits, and those individual commits evolve, >> might get reordered, commits added or removed fromt he stack, or when >> the whole MR gets rebased in the process... >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://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 rae at cs.brynmawr.edu Sat Nov 3 13:38:12 2018 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Sat, 3 Nov 2018 09:38:12 -0400 Subject: [GHC DevOps Group] The future of Phabricator In-Reply-To: References: <87zhuw2fw2.fsf@smart-cactus.org> <87tvl31bps.fsf@smart-cactus.org> <87tvkzsvmk.fsf@gmail.com> Message-ID: > On Nov 3, 2018, at 9:17 AM, Alan & Kim Zimmerman wrote: > > As part of the silent bystander grouping, I just want to voice a weak ok for switching to gitlab, +1 to this exact sentiment from me, and for the same reasons Alan voiced. I have a horse in this race and care about the outcome, but don't have enough of an informed opinion to really say anything of substance. I'm very grateful to those who have informed opinions and will debate (and then implement) our way into the future. Richard From me at ara.io Sat Nov 3 14:11:44 2018 From: me at ara.io (Ara Adkins) Date: Sat, 3 Nov 2018 14:11:44 +0000 Subject: [GHC DevOps Group] The future of Phabricator In-Reply-To: References: <87zhuw2fw2.fsf@smart-cactus.org> <87tvl31bps.fsf@smart-cactus.org> <87tvkzsvmk.fsf@gmail.com> Message-ID: <2D5E5A93-25D6-4FE9-A197-250C9C843F16@ara.io> Also as part of the silent bystander group, I would definitely be okay with a swap to GitLab. I don’t have anything particularly against Phab and Trac, but I recognise the reduction in general friction the swap would create. _ara > On 3 Nov 2018, at 13:38, Richard Eisenberg wrote: > > > >> On Nov 3, 2018, at 9:17 AM, Alan & Kim Zimmerman wrote: >> >> As part of the silent bystander grouping, I just want to voice a weak ok for switching to gitlab, > > +1 to this exact sentiment from me, and for the same reasons Alan voiced. I have a horse in this race and care about the outcome, but don't have enough of an informed opinion to really say anything of substance. I'm very grateful to those who have informed opinions and will debate (and then implement) our way into the future. > > Richard > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From ben at well-typed.com Sat Nov 3 16:34:58 2018 From: ben at well-typed.com (Ben Gamari) Date: Sat, 03 Nov 2018 12:34:58 -0400 Subject: [GHC DevOps Group] The future of Phabricator In-Reply-To: References: <87zhuw2fw2.fsf@smart-cactus.org> <87tvl31bps.fsf@smart-cactus.org> <87tvkzsvmk.fsf@gmail.com> Message-ID: <87in1ew24z.fsf@smart-cactus.org> Simon Marlow writes: > On Fri, 2 Nov 2018 at 08:59, Herbert Valerio Riedel > wrote: > >> On 2018-11-02 at 08:13:37 +0000, Simon Marlow wrote: >> >> > I suppose we can do a squash-merge when committing to keep the history >> > clean, but then contributors have a choice - either do GitHub-style >> > where you add commits to a PR to update it and we squash on merge, OR >> > Phabricator-style where you keep the same set of commits and rebase >> > the stack to update it. >> [..] >> >> Well, if MRs are to be squashed on merge anyway, I'm definitely not >> going to waste my time carefully grooming a stack of atomic individually >> validating commits via git-rebase-interactive... >> > > Sorry I wasn't very clear. We would *only* squash if the author had been > using the workflow where they add commits to revise the MR. If the author > wants to use the stacked-diff-like workflow where they keep a groomed set > of commits in the MR, then we would rebase and fast-forward the MR. > > My concern here is that we have two different workflows. People used to > GitHub would want to use one, and people used to Phabricator would want to > use the other. We have to check which workflow people are using so that we > can decide whether to squash on merge or not. > Ahh, yes, I see. > Ben said: > >> This shouldn't be a problem. One can easily configure a project such > that users are *only* allowed to fast-forward/rebase, disallowing the > creation of merge commits. > > but that doesn't fully address the problem, because the series of commits > that would get rebased onto master would include all the commits added to > the MR to update it during the review process. Actually what we wanted to > do in this case was squash, not rebase+fast-forward. > Indeed, this is a problem that we already have in the case of GitHub pull requests. In most of these cases I end up squashing the branch myself when I merge (in practice this contributes very little overhead; I need to merge GitHub PR's myself anyways as we cannot use GitHub's merge button since github.com:ghc/ghc is merely a mirror of git.haskell.org:ghc). Of course, if we start taking *all* of our patches via MRs then I agree that this may become a bit more tiresome. > If there was a nice way to guide people into using the Phabricator-style > workflow, I think that would help a lot. > I think this is primarily a social problem and consequently it is probably best handled by a combination of documentation (both in the contributor documentation and the MR template text) and code review. One of the things I would like to do in the near future is consolidate (and, in some cases, rewrite) our contributor documentation. The survey indicated that there is plenty of room for improvement here. In this past we have discussed improving in this area but lacked the bandwidth to give the task the attention it deserves. I think now we are in better shape to resource it sufficiently. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From csaba.hruska at gmail.com Sun Nov 4 11:21:37 2018 From: csaba.hruska at gmail.com (Csaba Hruska) Date: Sun, 4 Nov 2018 12:21:37 +0100 Subject: StgRhsClosure freevar and argument name duplicates In-Reply-To: References: Message-ID: Is it possible that GHC generates STG with invalid binding semantics for certain cases that the Cmm codegen fix or ignore? This could explain my observations. I've checked the Stg linter source (StgLint.hs ; GHC 8.2.2 and github master) and it does not check StgRhsClosure free var and binder list at all. And the scope checker function (addInScopeVars) does not check for duplicates. Any thoughts? Cheers, Csaba On Sat, Nov 3, 2018 at 9:53 AM Csaba Hruska wrote: > Hi, > > Can StgRhsClosure's freevar list ([occ]) or argument list ([bndr]) contain > duplicates? > > Cheers, > Csaba > > data GenStgRhs bndr occ > = StgRhsClosure > CostCentreStack -- CCS to be attached (default is > CurrentCCS) > StgBinderInfo -- Info about how this binder is used (see > below) > *[occ]* -- non-global free vars; a list, rather > than > -- a set, because order is important > !UpdateFlag -- ReEntrant | Updatable | SingleEntry > *[bndr]* -- arguments; if empty, then not a > function; > -- as above, order is important. > (GenStgExpr bndr occ) -- body > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chak at justtesting.org Sun Nov 4 15:27:37 2018 From: chak at justtesting.org (Manuel M T Chakravarty) Date: Sun, 4 Nov 2018 16:27:37 +0100 Subject: [GHC DevOps Group] The future of Phabricator In-Reply-To: References: <87zhuw2fw2.fsf@smart-cactus.org> Message-ID: > Am 30.10.2018 um 10:07 schrieb Simon Marlow : > > I'm entirely happy to move, provided (1) whatever we move to provides the functionality we need, and (2) it's clearly what the community wants (considering both current and future contributors). In the past when moving to GitHub was brought up, there were a handful of core contributors who argued strongly in favour of Phabricator, do we think that's changed? Do we have any indication of whether the survey respondents who were anti-Phabricator would be pro- or anti-GitLab? FWIW, while I still think GitHub is preferable, GitLab would be an improvement over Phabricator IMHO. Cheers, Manuel From carter.schonwald at gmail.com Sun Nov 4 16:08:35 2018 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sun, 4 Nov 2018 11:08:35 -0500 Subject: [GHC DevOps Group] The future of Phabricator In-Reply-To: References: <87zhuw2fw2.fsf@smart-cactus.org> Message-ID: I’ve found that GitHub encourages git commits as a project journal even though gits originating prject has a very diff / change set oriented workflow. And The latter is a more useful granularity of contribution for complex prjects like ghc. On Sun, Nov 4, 2018 at 10:27 AM Manuel M T Chakravarty wrote: > > Am 30.10.2018 um 10:07 schrieb Simon Marlow : > > > > I'm entirely happy to move, provided (1) whatever we move to provides > the functionality we need, and (2) it's clearly what the community wants > (considering both current and future contributors). In the past when moving > to GitHub was brought up, there were a handful of core contributors who > argued strongly in favour of Phabricator, do we think that's changed? Do we > have any indication of whether the survey respondents who were > anti-Phabricator would be pro- or anti-GitLab? > > FWIW, while I still think GitHub is preferable, GitLab would be an > improvement over Phabricator IMHO. > > Cheers, > Manuel > > _______________________________________________ > 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 m at tweag.io Mon Nov 5 11:30:12 2018 From: m at tweag.io (Boespflug, Mathieu) Date: Mon, 5 Nov 2018 12:30:12 +0100 Subject: [GHC DevOps Group] The future of Phabricator In-Reply-To: References: <87zhuw2fw2.fsf@smart-cactus.org> Message-ID: So IIUC Gitlab features: - Good multi-platform *hosted* CI or at least workable integration with other (existing) CI solutions - Hosted review tool that we don't have to maintain ourselves (though a little bit less good than Phabricator, allegedly) - familiar GitHub-like workflow with no requirement to install extra software locally - Reuse of GitHub credentials - Realistic path forward for migrating tickets from Trac This combination sounds pretty good to me! Best, -- Mathieu Boespflug Founder at http://tweag.io. On Sun, 4 Nov 2018 at 16:27, Manuel M T Chakravarty wrote: > > > Am 30.10.2018 um 10:07 schrieb Simon Marlow : > > > > I'm entirely happy to move, provided (1) whatever we move to provides the functionality we need, and (2) it's clearly what the community wants (considering both current and future contributors). In the past when moving to GitHub was brought up, there were a handful of core contributors who argued strongly in favour of Phabricator, do we think that's changed? Do we have any indication of whether the survey respondents who were anti-Phabricator would be pro- or anti-GitLab? > > FWIW, while I still think GitHub is preferable, GitLab would be an improvement over Phabricator IMHO. > > Cheers, > Manuel > > _______________________________________________ > Ghc-devops-group mailing list > Ghc-devops-group at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devops-group From simonpj at microsoft.com Mon Nov 5 13:08:06 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 5 Nov 2018 13:08:06 +0000 Subject: StgRhsClosure freevar and argument name duplicates In-Reply-To: References: Message-ID: I don’t think there should be duplicates in either. Do you have a test case that shows duplicates? Simon From: ghc-devs On Behalf Of Csaba Hruska Sent: 04 November 2018 11:22 To: ghc-devs at haskell.org Subject: Re: StgRhsClosure freevar and argument name duplicates Is it possible that GHC generates STG with invalid binding semantics for certain cases that the Cmm codegen fix or ignore? This could explain my observations. I've checked the Stg linter source (StgLint.hs ; GHC 8.2.2 and github master) and it does not check StgRhsClosure free var and binder list at all. And the scope checker function (addInScopeVars) does not check for duplicates. Any thoughts? Cheers, Csaba On Sat, Nov 3, 2018 at 9:53 AM Csaba Hruska > wrote: Hi, Can StgRhsClosure's freevar list ([occ]) or argument list ([bndr]) contain duplicates? Cheers, Csaba data GenStgRhs bndr occ = StgRhsClosure CostCentreStack -- CCS to be attached (default is CurrentCCS) StgBinderInfo -- Info about how this binder is used (see below) [occ] -- non-global free vars; a list, rather than -- a set, because order is important !UpdateFlag -- ReEntrant | Updatable | SingleEntry [bndr] -- arguments; if empty, then not a function; -- as above, order is important. (GenStgExpr bndr occ) -- body -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.colpitts at gmail.com Mon Nov 5 16:05:37 2018 From: george.colpitts at gmail.com (George Colpitts) Date: Mon, 5 Nov 2018 09:05:37 -0700 Subject: GHC 8.8 freeze in three weeks In-Reply-To: <874ld65518.fsf@smart-cactus.org> References: <874ld65518.fsf@smart-cactus.org> Message-ID: will we be moving to llvm 7? On Sun, Oct 28, 2018 at 2:56 PM Ben Gamari wrote: > Hello everyone, > > Incredibly enough we are quickly coming up on three months since the > nominal GHC 8.6.1 release date. This means that the GHC 8.8 branch is > quickly approaching. We will plan on cutting the branch on November > 18th. Note that this is in three weeks. > > If you have a patch that you would like to see in GHC 8.8 and it isn't > yet up on Phabricator, do let me know. Moreover, if you have something > that will be in GHC 8.8 and you haven't yet added it to the release > status page [1], please add it. > > Cheers, > > - Ben > > > [1] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.8.1 > > _______________________________________________ > 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 csaba.hruska at gmail.com Mon Nov 5 16:27:31 2018 From: csaba.hruska at gmail.com (Csaba Hruska) Date: Mon, 5 Nov 2018 17:27:31 +0100 Subject: StgRhsClosure freevar and argument name duplicates In-Reply-To: References: Message-ID: An example for the duplication please check the divModInteger function from integer-simple GHC.Integer.Type. The STG (GHC 8.2.2) generated from *divModInteger **:: Integer -> Integer -> (# Integer, Integer #) *contains duplications in a closure binder list. Using my custom STG printer it looks like: module GHC.Integer.Type where using GHC.Prim using GHC.Tuple using GHC.Types GHC.Integer.Type.divModInteger {-083-} = closure (F:) (B: n.s84123 {-s84123-} d.s84124 {-s84124-}) { case GHC.Integer.Type.quotRemInteger {-084-} n.s84123 {-s84123-} d.s84124 {-s84124-} of qr.s84125 {-s84125-} { GHC.Prim.(#,#) {-86-} ipv.s84126 {-s84126-} ipv1.s84127 {-s84127-} -> let $j.s84128 {-s84128-} = closure (F: d.s84124 {-s84124-} * ipv.s84126 {-s84126-}* * ipv1.s84127 {-s84127-}* * ipv.s84126 {-s84126-}* *ipv1.s84127 {-s84127-}*) (B: wild.s84129 {-s84129-}) { let $j1.s84130 {-s84130-} = closure (F: d.s84124 {-s84124-} ipv.s84126 {-s84126-} ipv1.s84127 {-s84127-} ipv.s84126 {-s84126-} ipv1.s84127 {-s84127-} wild.s84129 {-s84129-}) (B: wild1.s84131 {-s84131-}) { case _stg_prim_negateInt# wild.s84129 {-s84129-} of sat.s84132 {-s84132-} { DEFAULT -> case _stg_prim_==# wild1.s84131 {-s84131-} sat.s84132 {-s84132-} of sat.s84133 {-s84133-} { DEFAULT -> case _stg_prim_tagToEnum# sat.s84133 {-s84133-} of wild2.s84134 {-s84134-} { GHC.Types.False {-612-} -> GHC.Prim.(#,#) {-86-} ipv.s84126 {-s84126-} ipv1.s84127 {-s84127-} GHC.Types.True {-645-} -> case GHC.Integer.Type.plusInteger {-066-} ipv1.s84127 {-s84127-} d.s84124 {-s84124-} of r'.s84135 {-s84135-} { DEFAULT -> case GHC.Integer.Type.plusInteger {-066-} ipv.s84126 {-s84126-} GHC.Integer.Type.lvl11 {-r50574-} of q'.s84136 {-s84136-} { DEFAULT -> GHC.Prim.(#,#) {-86-} q'.s84136 {-s84136-} r'.s84135 {-s84135-} } } } } }} in case ipv1.s84127 {-s84127-} of wild1.s84137 {-s84137-} { GHC.Integer.Type.S# {-621-} i#.s84138 {-s84138-} -> case _stg_prim_<# i#.s84138 {-s84138-} 0# of sat.s84140 {-s84140-} { DEFAULT -> case _stg_prim_># i#.s84138 {-s84138-} 0# of sat.s84139 {-s84139-} { DEFAULT -> case _stg_prim_-# sat.s84139 {-s84139-} sat.s84140 {-s84140-} of sat.s84141 {-s84141-} { DEFAULT -> $j1.s84130 {-s84130-} sat.s84141 {-s84141-} } } } GHC.Integer.Type.Jp# {-r5813-} dt.s84142 {-s84142-} -> $j1.s84130 {-s84130-} 1# GHC.Integer.Type.Jn# {-r5814-} dt.s84143 {-s84143-} -> $j1.s84130 {-s84130-} -1# }} in case d.s84124 {-s84124-} of wild.s84144 {-s84144-} { GHC.Integer.Type.S# {-621-} i#.s84145 {-s84145-} -> case _stg_prim_<# i#.s84145 {-s84145-} 0# of sat.s84147 {-s84147-} { DEFAULT -> case _stg_prim_># i#.s84145 {-s84145-} 0# of sat.s84146 {-s84146-} { DEFAULT -> case _stg_prim_-# sat.s84146 {-s84146-} sat.s84147 {-s84147-} of sat.s84148 {-s84148-} { DEFAULT -> $j.s84128 {-s84128-} sat.s84148 {-s84148-} } } } GHC.Integer.Type.Jp# {-r5813-} dt.s84149 {-s84149-} -> $j.s84128 {-s84128-} 1# GHC.Integer.Type.Jn# {-r5814-} dt.s84150 {-s84150-} -> $j.s84128 {-s84128-} -1# } }} On Mon, Nov 5, 2018 at 2:08 PM Simon Peyton Jones wrote: > I don’t think there should be duplicates in either. Do you have a test > case that shows duplicates? > > > > Simon > > > > *From:* ghc-devs *On Behalf Of *Csaba > Hruska > *Sent:* 04 November 2018 11:22 > *To:* ghc-devs at haskell.org > *Subject:* Re: StgRhsClosure freevar and argument name duplicates > > > > Is it possible that GHC generates STG with invalid binding semantics for > certain cases that the Cmm codegen fix or ignore? > > This could explain my observations. > > I've checked the Stg linter source (StgLint.hs ; GHC 8.2.2 and github > master) and it does not check StgRhsClosure free var and binder list at all. > > And the scope checker function (addInScopeVars) does not check for > duplicates. > > > > Any thoughts? > > > > Cheers, > > Csaba > > > > On Sat, Nov 3, 2018 at 9:53 AM Csaba Hruska > wrote: > > Hi, > > > > Can StgRhsClosure's freevar list ([occ]) or argument list ([bndr]) contain > duplicates? > > > > Cheers, > > Csaba > > > > data GenStgRhs bndr occ > = StgRhsClosure > CostCentreStack -- CCS to be attached (default is > CurrentCCS) > StgBinderInfo -- Info about how this binder is used (see > below) > *[occ]* -- non-global free vars; a list, rather > than > -- a set, because order is important > !UpdateFlag -- ReEntrant | Updatable | SingleEntry > *[bndr]* -- arguments; if empty, then not a > function; > -- as above, order is important. > (GenStgExpr bndr occ) -- body > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Mon Nov 5 16:29:20 2018 From: ben at well-typed.com (Ben Gamari) Date: Mon, 05 Nov 2018 11:29:20 -0500 Subject: [ANNOUNCE] GHC 8.6.2 is now available Message-ID: <87h8gvwkrp.fsf@smart-cactus.org> Hello everyone, The GHC team is very happy to announce the availability of GHC 8.6.2, a bugfix release to GHC 8.6.1. The source distribution, binary distributions, and documentation for this release are available at https://downloads.haskell.org/~ghc/8.6.2 The 8.6 release fixes several regressions present in 8.6.1 including: * A long-standing (but previously hard to manifest) bug resulting in undefined behavior for some applications of dataToTag# has been fixed (#15696) * An incorrect linker path to libgmp in the Mac OS binary distributions (#15404) * A regression rendering Windows installations to read-only directories unusable (#15667) * A regression resulting in panics while compiling some record updates of GADTs constructors (#15499) * A regression resulting in incorrect type errors when splicing types into constraint contexts has been fixed (#15815) * Around a dozen other issues. See Trac [1] for a full list of issues resolved in this release. Note that this release ships with one significant but long-standing bug (#14251): Calls to functions taking both Float# and Double# may result in incorrect code generation when compiled using the LLVM code generator. This is not a new issue, it has existed as long as the LLVM code generator has existed; however, changes in code generation in 8.6 made it more likely that user code using only lifted types will trigger it. Happy compiling! Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/query?status=closed&milestone=8.6.2&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component&order=priority -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From csaba.hruska at gmail.com Mon Nov 5 16:33:20 2018 From: csaba.hruska at gmail.com (Csaba Hruska) Date: Mon, 5 Nov 2018 17:33:20 +0100 Subject: StgRhsClosure freevar and argument name duplicates In-Reply-To: References: Message-ID: Correction! The problem happens in integer-gmp: https://github.com/ghc/ghc/blob/master/libraries/integer-gmp/src/GHC/Integer/Type.hs#L761-L770 On Mon, Nov 5, 2018 at 5:27 PM Csaba Hruska wrote: > An example for the duplication please check the divModInteger > > function from integer-simple GHC.Integer.Type. > The STG (GHC 8.2.2) generated from *divModInteger **:: Integer -> Integer > -> (# Integer, Integer #) *contains duplications in a closure binder list. > > Using my custom STG printer it looks like: > module GHC.Integer.Type where > > using GHC.Prim > using GHC.Tuple > using GHC.Types > > GHC.Integer.Type.divModInteger {-083-} = > closure (F:) (B: > n.s84123 {-s84123-} > d.s84124 {-s84124-}) { > case GHC.Integer.Type.quotRemInteger {-084-} > n.s84123 {-s84123-} > d.s84124 {-s84124-} > of qr.s84125 {-s84125-} { > GHC.Prim.(#,#) {-86-} ipv.s84126 {-s84126-} ipv1.s84127 {-s84127-} -> > let $j.s84128 {-s84128-} = > closure (F: > d.s84124 {-s84124-} > * ipv.s84126 {-s84126-}* > * ipv1.s84127 {-s84127-}* > * ipv.s84126 {-s84126-}* > *ipv1.s84127 {-s84127-}*) (B: > wild.s84129 {-s84129-}) { > let $j1.s84130 {-s84130-} = > closure (F: > d.s84124 {-s84124-} > ipv.s84126 {-s84126-} > ipv1.s84127 {-s84127-} > ipv.s84126 {-s84126-} > ipv1.s84127 {-s84127-} > wild.s84129 {-s84129-}) (B: > wild1.s84131 {-s84131-}) { > case _stg_prim_negateInt# > wild.s84129 {-s84129-} > of sat.s84132 {-s84132-} { > DEFAULT -> > case _stg_prim_==# > wild1.s84131 {-s84131-} > sat.s84132 {-s84132-} > of sat.s84133 {-s84133-} { > DEFAULT -> > case _stg_prim_tagToEnum# > sat.s84133 {-s84133-} > of wild2.s84134 {-s84134-} { > GHC.Types.False {-612-} -> > GHC.Prim.(#,#) {-86-} > ipv.s84126 {-s84126-} > ipv1.s84127 {-s84127-} > GHC.Types.True {-645-} -> > case GHC.Integer.Type.plusInteger {-066-} > ipv1.s84127 {-s84127-} > d.s84124 {-s84124-} > of r'.s84135 {-s84135-} { > DEFAULT -> > case GHC.Integer.Type.plusInteger {-066-} > ipv.s84126 {-s84126-} > GHC.Integer.Type.lvl11 {-r50574-} > of q'.s84136 {-s84136-} { > DEFAULT -> > GHC.Prim.(#,#) {-86-} > q'.s84136 {-s84136-} > r'.s84135 {-s84135-} > } > } > } > } > }} > > in case ipv1.s84127 {-s84127-} > of wild1.s84137 {-s84137-} { > GHC.Integer.Type.S# {-621-} i#.s84138 {-s84138-} -> > case _stg_prim_<# > i#.s84138 {-s84138-} 0# > of sat.s84140 {-s84140-} { > DEFAULT -> > case _stg_prim_># > i#.s84138 {-s84138-} 0# > of sat.s84139 {-s84139-} { > DEFAULT -> > case _stg_prim_-# > sat.s84139 {-s84139-} > sat.s84140 {-s84140-} > of sat.s84141 {-s84141-} { > DEFAULT -> > $j1.s84130 {-s84130-} > sat.s84141 {-s84141-} > } > } > } > GHC.Integer.Type.Jp# {-r5813-} dt.s84142 {-s84142-} -> > $j1.s84130 {-s84130-} 1# > GHC.Integer.Type.Jn# {-r5814-} dt.s84143 {-s84143-} -> > $j1.s84130 {-s84130-} -1# > }} > > in case d.s84124 {-s84124-} > of wild.s84144 {-s84144-} { > GHC.Integer.Type.S# {-621-} i#.s84145 {-s84145-} -> > case _stg_prim_<# > i#.s84145 {-s84145-} 0# > of sat.s84147 {-s84147-} { > DEFAULT -> > case _stg_prim_># > i#.s84145 {-s84145-} 0# > of sat.s84146 {-s84146-} { > DEFAULT -> > case _stg_prim_-# > sat.s84146 {-s84146-} > sat.s84147 {-s84147-} > of sat.s84148 {-s84148-} { > DEFAULT -> > $j.s84128 {-s84128-} > sat.s84148 {-s84148-} > } > } > } > GHC.Integer.Type.Jp# {-r5813-} dt.s84149 {-s84149-} -> > $j.s84128 {-s84128-} 1# > GHC.Integer.Type.Jn# {-r5814-} dt.s84150 {-s84150-} -> > $j.s84128 {-s84128-} -1# > } > }} > > > On Mon, Nov 5, 2018 at 2:08 PM Simon Peyton Jones > wrote: > >> I don’t think there should be duplicates in either. Do you have a test >> case that shows duplicates? >> >> >> >> Simon >> >> >> >> *From:* ghc-devs *On Behalf Of *Csaba >> Hruska >> *Sent:* 04 November 2018 11:22 >> *To:* ghc-devs at haskell.org >> *Subject:* Re: StgRhsClosure freevar and argument name duplicates >> >> >> >> Is it possible that GHC generates STG with invalid binding semantics for >> certain cases that the Cmm codegen fix or ignore? >> >> This could explain my observations. >> >> I've checked the Stg linter source (StgLint.hs ; GHC 8.2.2 and github >> master) and it does not check StgRhsClosure free var and binder list at all. >> >> And the scope checker function (addInScopeVars) does not check for >> duplicates. >> >> >> >> Any thoughts? >> >> >> >> Cheers, >> >> Csaba >> >> >> >> On Sat, Nov 3, 2018 at 9:53 AM Csaba Hruska >> wrote: >> >> Hi, >> >> >> >> Can StgRhsClosure's freevar list ([occ]) or argument list ([bndr]) >> contain duplicates? >> >> >> >> Cheers, >> >> Csaba >> >> >> >> data GenStgRhs bndr occ >> = StgRhsClosure >> CostCentreStack -- CCS to be attached (default is >> CurrentCCS) >> StgBinderInfo -- Info about how this binder is used >> (see below) >> *[occ]* -- non-global free vars; a list, >> rather than >> -- a set, because order is important >> !UpdateFlag -- ReEntrant | Updatable | SingleEntry >> *[bndr]* -- arguments; if empty, then not a >> function; >> -- as above, order is important. >> (GenStgExpr bndr occ) -- body >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Mon Nov 5 17:02:33 2018 From: ben at well-typed.com (Ben Gamari) Date: Mon, 05 Nov 2018 12:02:33 -0500 Subject: GHC 8.8 freeze in three weeks In-Reply-To: References: <874ld65518.fsf@smart-cactus.org> Message-ID: <878t27wj88.fsf@smart-cactus.org> George Colpitts writes: > will we be moving to llvm 7? > This is something that I'll need to look at. Likely yes. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From simonpj at microsoft.com Tue Nov 6 10:13:05 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 6 Nov 2018 10:13:05 +0000 Subject: StgRhsClosure freevar and argument name duplicates In-Reply-To: References: Message-ID: Does this happen in HEAD with GHC’s own STG printer? If so, could you file a Trac ticket – it’s clearly wrong. But I do wonder if it could perhaps be something to do with your branch? Thanks Simon From: Csaba Hruska Sent: 05 November 2018 16:33 To: Simon Peyton Jones Cc: ghc-devs at haskell.org Subject: Re: StgRhsClosure freevar and argument name duplicates Correction! The problem happens in integer-gmp: https://github.com/ghc/ghc/blob/master/libraries/integer-gmp/src/GHC/Integer/Type.hs#L761-L770 On Mon, Nov 5, 2018 at 5:27 PM Csaba Hruska > wrote: An example for the duplication please check the divModInteger function from integer-simple GHC.Integer.Type. The STG (GHC 8.2.2) generated from divModInteger :: Integer -> Integer -> (# Integer, Integer #) contains duplications in a closure binder list. Using my custom STG printer it looks like: module GHC.Integer.Type where using GHC.Prim using GHC.Tuple using GHC.Types GHC.Integer.Type.divModInteger {-083-} = closure (F:) (B: n.s84123 {-s84123-} d.s84124 {-s84124-}) { case GHC.Integer.Type.quotRemInteger {-084-} n.s84123 {-s84123-} d.s84124 {-s84124-} of qr.s84125 {-s84125-} { GHC.Prim.(#,#) {-86-} ipv.s84126 {-s84126-} ipv1.s84127 {-s84127-} -> let $j.s84128 {-s84128-} = closure (F: d.s84124 {-s84124-} ipv.s84126 {-s84126-} ipv1.s84127 {-s84127-} ipv.s84126 {-s84126-} ipv1.s84127 {-s84127-}) (B: wild.s84129 {-s84129-}) { let $j1.s84130 {-s84130-} = closure (F: d.s84124 {-s84124-} ipv.s84126 {-s84126-} ipv1.s84127 {-s84127-} ipv.s84126 {-s84126-} ipv1.s84127 {-s84127-} wild.s84129 {-s84129-}) (B: wild1.s84131 {-s84131-}) { case _stg_prim_negateInt# wild.s84129 {-s84129-} of sat.s84132 {-s84132-} { DEFAULT -> case _stg_prim_==# wild1.s84131 {-s84131-} sat.s84132 {-s84132-} of sat.s84133 {-s84133-} { DEFAULT -> case _stg_prim_tagToEnum# sat.s84133 {-s84133-} of wild2.s84134 {-s84134-} { GHC.Types.False {-612-} -> GHC.Prim.(#,#) {-86-} ipv.s84126 {-s84126-} ipv1.s84127 {-s84127-} GHC.Types.True {-645-} -> case GHC.Integer.Type.plusInteger {-066-} ipv1.s84127 {-s84127-} d.s84124 {-s84124-} of r'.s84135 {-s84135-} { DEFAULT -> case GHC.Integer.Type.plusInteger {-066-} ipv.s84126 {-s84126-} GHC.Integer.Type.lvl11 {-r50574-} of q'.s84136 {-s84136-} { DEFAULT -> GHC.Prim.(#,#) {-86-} q'.s84136 {-s84136-} r'.s84135 {-s84135-} } } } } }} in case ipv1.s84127 {-s84127-} of wild1.s84137 {-s84137-} { GHC.Integer.Type.S# {-621-} i#.s84138 {-s84138-} -> case _stg_prim_<# i#.s84138 {-s84138-} 0# of sat.s84140 {-s84140-} { DEFAULT -> case _stg_prim_># i#.s84138 {-s84138-} 0# of sat.s84139 {-s84139-} { DEFAULT -> case _stg_prim_-# sat.s84139 {-s84139-} sat.s84140 {-s84140-} of sat.s84141 {-s84141-} { DEFAULT -> $j1.s84130 {-s84130-} sat.s84141 {-s84141-} } } } GHC.Integer.Type.Jp# {-r5813-} dt.s84142 {-s84142-} -> $j1.s84130 {-s84130-} 1# GHC.Integer.Type.Jn# {-r5814-} dt.s84143 {-s84143-} -> $j1.s84130 {-s84130-} -1# }} in case d.s84124 {-s84124-} of wild.s84144 {-s84144-} { GHC.Integer.Type.S# {-621-} i#.s84145 {-s84145-} -> case _stg_prim_<# i#.s84145 {-s84145-} 0# of sat.s84147 {-s84147-} { DEFAULT -> case _stg_prim_># i#.s84145 {-s84145-} 0# of sat.s84146 {-s84146-} { DEFAULT -> case _stg_prim_-# sat.s84146 {-s84146-} sat.s84147 {-s84147-} of sat.s84148 {-s84148-} { DEFAULT -> $j.s84128 {-s84128-} sat.s84148 {-s84148-} } } } GHC.Integer.Type.Jp# {-r5813-} dt.s84149 {-s84149-} -> $j.s84128 {-s84128-} 1# GHC.Integer.Type.Jn# {-r5814-} dt.s84150 {-s84150-} -> $j.s84128 {-s84128-} -1# } }} On Mon, Nov 5, 2018 at 2:08 PM Simon Peyton Jones > wrote: I don’t think there should be duplicates in either. Do you have a test case that shows duplicates? Simon From: ghc-devs > On Behalf Of Csaba Hruska Sent: 04 November 2018 11:22 To: ghc-devs at haskell.org Subject: Re: StgRhsClosure freevar and argument name duplicates Is it possible that GHC generates STG with invalid binding semantics for certain cases that the Cmm codegen fix or ignore? This could explain my observations. I've checked the Stg linter source (StgLint.hs ; GHC 8.2.2 and github master) and it does not check StgRhsClosure free var and binder list at all. And the scope checker function (addInScopeVars) does not check for duplicates. Any thoughts? Cheers, Csaba On Sat, Nov 3, 2018 at 9:53 AM Csaba Hruska > wrote: Hi, Can StgRhsClosure's freevar list ([occ]) or argument list ([bndr]) contain duplicates? Cheers, Csaba data GenStgRhs bndr occ = StgRhsClosure CostCentreStack -- CCS to be attached (default is CurrentCCS) StgBinderInfo -- Info about how this binder is used (see below) [occ] -- non-global free vars; a list, rather than -- a set, because order is important !UpdateFlag -- ReEntrant | Updatable | SingleEntry [bndr] -- arguments; if empty, then not a function; -- as above, order is important. (GenStgExpr bndr occ) -- body -------------- next part -------------- An HTML attachment was scrubbed... URL: From csaba.hruska at gmail.com Tue Nov 6 11:00:42 2018 From: csaba.hruska at gmail.com (Csaba Hruska) Date: Tue, 6 Nov 2018 12:00:42 +0100 Subject: StgRhsClosure freevar and argument name duplicates In-Reply-To: References: Message-ID: My plan is to extend GHC's STG linter to check the following properties: - uniqueness of free var and arg list of StgRhsClosure - top level binding name uniqueness I'll patch my local GHC 8.2.2 and GHC HEAD. I'll also attach the patch to the ticket. I have a question regarding top level names. Should the top-level names be unique as occ names or just in unique values? If not, then what is the rule? Thanks, Csaba On Tue, Nov 6, 2018 at 11:13 AM Simon Peyton Jones wrote: > Does this happen in HEAD with GHC’s own STG printer? If so, could you > file a Trac ticket – it’s clearly wrong. > > > > But I do wonder if it could perhaps be something to do with your branch? > > > > Thanks > > > > Simon > > > > *From:* Csaba Hruska > *Sent:* 05 November 2018 16:33 > *To:* Simon Peyton Jones > *Cc:* ghc-devs at haskell.org > *Subject:* Re: StgRhsClosure freevar and argument name duplicates > > > > Correction! > > The problem happens in integer-gmp: > > https://github.com/ghc/ghc/blob/master/libraries/integer-gmp/src/GHC/Integer/Type.hs#L761-L770 > > > > > On Mon, Nov 5, 2018 at 5:27 PM Csaba Hruska > wrote: > > An example for the duplication please check the divModInteger > > function from integer-simple GHC.Integer.Type. > > The STG (GHC 8.2.2) generated from *divModInteger* *::** Integer -> > Integer -> (# Integer, Integer #) *contains duplications in a closure > binder list. > > > > Using my custom STG printer it looks like: > > module GHC.Integer.Type where > > > > using GHC.Prim > using GHC.Tuple > using GHC.Types > > > > GHC.Integer.Type.divModInteger {-083-} = > closure (F:) (B: > n.s84123 {-s84123-} > d.s84124 {-s84124-}) { > case GHC.Integer.Type.quotRemInteger {-084-} > n.s84123 {-s84123-} > d.s84124 {-s84124-} > of qr.s84125 {-s84125-} { > GHC.Prim.(#,#) {-86-} ipv.s84126 {-s84126-} ipv1.s84127 {-s84127-} -> > let $j.s84128 {-s84128-} = > closure (F: > d.s84124 {-s84124-} > * ipv.s84126 {-s84126-}* > * ipv1.s84127 {-s84127-}* > * ipv.s84126 {-s84126-}* > *ipv1.s84127 {-s84127-}*) (B: > wild.s84129 {-s84129-}) { > let $j1.s84130 {-s84130-} = > closure (F: > d.s84124 {-s84124-} > ipv.s84126 {-s84126-} > ipv1.s84127 {-s84127-} > ipv.s84126 {-s84126-} > ipv1.s84127 {-s84127-} > wild.s84129 {-s84129-}) (B: > wild1.s84131 {-s84131-}) { > case _stg_prim_negateInt# > wild.s84129 {-s84129-} > of sat.s84132 {-s84132-} { > DEFAULT -> > case _stg_prim_==# > wild1.s84131 {-s84131-} > sat.s84132 {-s84132-} > of sat.s84133 {-s84133-} { > DEFAULT -> > case _stg_prim_tagToEnum# > sat.s84133 {-s84133-} > of wild2.s84134 {-s84134-} { > GHC.Types.False {-612-} -> > GHC.Prim.(#,#) {-86-} > ipv.s84126 {-s84126-} > ipv1.s84127 {-s84127-} > GHC.Types.True {-645-} -> > case GHC.Integer.Type.plusInteger {-066-} > ipv1.s84127 {-s84127-} > d.s84124 {-s84124-} > of r'.s84135 {-s84135-} { > DEFAULT -> > case GHC.Integer.Type.plusInteger {-066-} > ipv.s84126 {-s84126-} > GHC.Integer.Type.lvl11 {-r50574-} > of q'.s84136 {-s84136-} { > DEFAULT -> > GHC.Prim.(#,#) {-86-} > q'.s84136 {-s84136-} > r'.s84135 {-s84135-} > } > } > } > } > }} > > in case ipv1.s84127 {-s84127-} > of wild1.s84137 {-s84137-} { > GHC.Integer.Type.S# {-621-} i#.s84138 {-s84138-} -> > case _stg_prim_<# > i#.s84138 {-s84138-} 0# > of sat.s84140 {-s84140-} { > DEFAULT -> > case _stg_prim_># > i#.s84138 {-s84138-} 0# > of sat.s84139 {-s84139-} { > DEFAULT -> > case _stg_prim_-# > sat.s84139 {-s84139-} > sat.s84140 {-s84140-} > of sat.s84141 {-s84141-} { > DEFAULT -> > $j1.s84130 {-s84130-} > sat.s84141 {-s84141-} > } > } > } > GHC.Integer.Type.Jp# > > {-r5813-} dt.s84142 {-s84142-} -> > $j1.s84130 {-s84130-} 1# > GHC.Integer.Type.Jn# {-r5814-} dt.s84143 {-s84143-} -> > $j1.s84130 {-s84130-} -1# > }} > > in case d.s84124 {-s84124-} > of wild.s84144 {-s84144-} { > GHC.Integer.Type.S# {-621-} i#.s84145 {-s84145-} -> > case _stg_prim_<# > i#.s84145 {-s84145-} 0# > of sat.s84147 {-s84147-} { > DEFAULT -> > case _stg_prim_># > i#.s84145 {-s84145-} 0# > of sat.s84146 {-s84146-} { > DEFAULT -> > case _stg_prim_-# > sat.s84146 {-s84146-} > sat.s84147 {-s84147-} > of sat.s84148 {-s84148-} { > DEFAULT -> > $j.s84128 {-s84128-} > sat.s84148 {-s84148-} > } > } > } > GHC.Integer.Type.Jp# > > {-r5813-} dt.s84149 {-s84149-} -> > $j.s84128 {-s84128-} 1# > GHC.Integer.Type.Jn# {-r5814-} dt.s84150 {-s84150-} -> > $j.s84128 {-s84128-} -1# > } > }} > > > > On Mon, Nov 5, 2018 at 2:08 PM Simon Peyton Jones > wrote: > > I don’t think there should be duplicates in either. Do you have a test > case that shows duplicates? > > > > Simon > > > > *From:* ghc-devs *On Behalf Of *Csaba > Hruska > *Sent:* 04 November 2018 11:22 > *To:* ghc-devs at haskell.org > *Subject:* Re: StgRhsClosure freevar and argument name duplicates > > > > Is it possible that GHC generates STG with invalid binding semantics for > certain cases that the Cmm codegen fix or ignore? > > This could explain my observations. > > I've checked the Stg linter source (StgLint.hs ; GHC 8.2.2 and github > master) and it does not check StgRhsClosure free var and binder list at all. > > And the scope checker function (addInScopeVars) does not check for > duplicates. > > > > Any thoughts? > > > > Cheers, > > Csaba > > > > On Sat, Nov 3, 2018 at 9:53 AM Csaba Hruska > wrote: > > Hi, > > > > Can StgRhsClosure's freevar list ([occ]) or argument list ([bndr]) contain > duplicates? > > > > Cheers, > > Csaba > > > > data GenStgRhs bndr occ > = StgRhsClosure > CostCentreStack -- CCS to be attached (default is > CurrentCCS) > StgBinderInfo -- Info about how this binder is used (see > below) > *[occ]* -- non-global free vars; a list, rather > than > -- a set, because order is important > !UpdateFlag -- ReEntrant | Updatable | SingleEntry > *[bndr]* -- arguments; if empty, then not a > function; > -- as above, order is important. > (GenStgExpr bndr occ) -- body > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Tue Nov 6 11:02:33 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 6 Nov 2018 11:02:33 +0000 Subject: StgRhsClosure freevar and argument name duplicates In-Reply-To: References: Message-ID: I think top level names should be unique in occ-names; because those occ-names generate the symbols in the binary. Simon From: Csaba Hruska Sent: 06 November 2018 11:01 To: Simon Peyton Jones Cc: ghc-devs at haskell.org Subject: Re: StgRhsClosure freevar and argument name duplicates My plan is to extend GHC's STG linter to check the following properties: * uniqueness of free var and arg list of StgRhsClosure * top level binding name uniqueness I'll patch my local GHC 8.2.2 and GHC HEAD. I'll also attach the patch to the ticket. I have a question regarding top level names. Should the top-level names be unique as occ names or just in unique values? If not, then what is the rule? Thanks, Csaba On Tue, Nov 6, 2018 at 11:13 AM Simon Peyton Jones > wrote: Does this happen in HEAD with GHC’s own STG printer? If so, could you file a Trac ticket – it’s clearly wrong. But I do wonder if it could perhaps be something to do with your branch? Thanks Simon From: Csaba Hruska > Sent: 05 November 2018 16:33 To: Simon Peyton Jones > Cc: ghc-devs at haskell.org Subject: Re: StgRhsClosure freevar and argument name duplicates Correction! The problem happens in integer-gmp: https://github.com/ghc/ghc/blob/master/libraries/integer-gmp/src/GHC/Integer/Type.hs#L761-L770 On Mon, Nov 5, 2018 at 5:27 PM Csaba Hruska > wrote: An example for the duplication please check the divModInteger function from integer-simple GHC.Integer.Type. The STG (GHC 8.2.2) generated from divModInteger :: Integer -> Integer -> (# Integer, Integer #) contains duplications in a closure binder list. Using my custom STG printer it looks like: module GHC.Integer.Type where using GHC.Prim using GHC.Tuple using GHC.Types GHC.Integer.Type.divModInteger {-083-} = closure (F:) (B: n.s84123 {-s84123-} d.s84124 {-s84124-}) { case GHC.Integer.Type.quotRemInteger {-084-} n.s84123 {-s84123-} d.s84124 {-s84124-} of qr.s84125 {-s84125-} { GHC.Prim.(#,#) {-86-} ipv.s84126 {-s84126-} ipv1.s84127 {-s84127-} -> let $j.s84128 {-s84128-} = closure (F: d.s84124 {-s84124-} ipv.s84126 {-s84126-} ipv1.s84127 {-s84127-} ipv.s84126 {-s84126-} ipv1.s84127 {-s84127-}) (B: wild.s84129 {-s84129-}) { let $j1.s84130 {-s84130-} = closure (F: d.s84124 {-s84124-} ipv.s84126 {-s84126-} ipv1.s84127 {-s84127-} ipv.s84126 {-s84126-} ipv1.s84127 {-s84127-} wild.s84129 {-s84129-}) (B: wild1.s84131 {-s84131-}) { case _stg_prim_negateInt# wild.s84129 {-s84129-} of sat.s84132 {-s84132-} { DEFAULT -> case _stg_prim_==# wild1.s84131 {-s84131-} sat.s84132 {-s84132-} of sat.s84133 {-s84133-} { DEFAULT -> case _stg_prim_tagToEnum# sat.s84133 {-s84133-} of wild2.s84134 {-s84134-} { GHC.Types.False {-612-} -> GHC.Prim.(#,#) {-86-} ipv.s84126 {-s84126-} ipv1.s84127 {-s84127-} GHC.Types.True {-645-} -> case GHC.Integer.Type.plusInteger {-066-} ipv1.s84127 {-s84127-} d.s84124 {-s84124-} of r'.s84135 {-s84135-} { DEFAULT -> case GHC.Integer.Type.plusInteger {-066-} ipv.s84126 {-s84126-} GHC.Integer.Type.lvl11 {-r50574-} of q'.s84136 {-s84136-} { DEFAULT -> GHC.Prim.(#,#) {-86-} q'.s84136 {-s84136-} r'.s84135 {-s84135-} } } } } }} in case ipv1.s84127 {-s84127-} of wild1.s84137 {-s84137-} { GHC.Integer.Type.S# {-621-} i#.s84138 {-s84138-} -> case _stg_prim_<# i#.s84138 {-s84138-} 0# of sat.s84140 {-s84140-} { DEFAULT -> case _stg_prim_># i#.s84138 {-s84138-} 0# of sat.s84139 {-s84139-} { DEFAULT -> case _stg_prim_-# sat.s84139 {-s84139-} sat.s84140 {-s84140-} of sat.s84141 {-s84141-} { DEFAULT -> $j1.s84130 {-s84130-} sat.s84141 {-s84141-} } } } GHC.Integer.Type.Jp# {-r5813-} dt.s84142 {-s84142-} -> $j1.s84130 {-s84130-} 1# GHC.Integer.Type.Jn# {-r5814-} dt.s84143 {-s84143-} -> $j1.s84130 {-s84130-} -1# }} in case d.s84124 {-s84124-} of wild.s84144 {-s84144-} { GHC.Integer.Type.S# {-621-} i#.s84145 {-s84145-} -> case _stg_prim_<# i#.s84145 {-s84145-} 0# of sat.s84147 {-s84147-} { DEFAULT -> case _stg_prim_># i#.s84145 {-s84145-} 0# of sat.s84146 {-s84146-} { DEFAULT -> case _stg_prim_-# sat.s84146 {-s84146-} sat.s84147 {-s84147-} of sat.s84148 {-s84148-} { DEFAULT -> $j.s84128 {-s84128-} sat.s84148 {-s84148-} } } } GHC.Integer.Type.Jp# {-r5813-} dt.s84149 {-s84149-} -> $j.s84128 {-s84128-} 1# GHC.Integer.Type.Jn# {-r5814-} dt.s84150 {-s84150-} -> $j.s84128 {-s84128-} -1# } }} On Mon, Nov 5, 2018 at 2:08 PM Simon Peyton Jones > wrote: I don’t think there should be duplicates in either. Do you have a test case that shows duplicates? Simon From: ghc-devs > On Behalf Of Csaba Hruska Sent: 04 November 2018 11:22 To: ghc-devs at haskell.org Subject: Re: StgRhsClosure freevar and argument name duplicates Is it possible that GHC generates STG with invalid binding semantics for certain cases that the Cmm codegen fix or ignore? This could explain my observations. I've checked the Stg linter source (StgLint.hs ; GHC 8.2.2 and github master) and it does not check StgRhsClosure free var and binder list at all. And the scope checker function (addInScopeVars) does not check for duplicates. Any thoughts? Cheers, Csaba On Sat, Nov 3, 2018 at 9:53 AM Csaba Hruska > wrote: Hi, Can StgRhsClosure's freevar list ([occ]) or argument list ([bndr]) contain duplicates? Cheers, Csaba data GenStgRhs bndr occ = StgRhsClosure CostCentreStack -- CCS to be attached (default is CurrentCCS) StgBinderInfo -- Info about how this binder is used (see below) [occ] -- non-global free vars; a list, rather than -- a set, because order is important !UpdateFlag -- ReEntrant | Updatable | SingleEntry [bndr] -- arguments; if empty, then not a function; -- as above, order is important. (GenStgExpr bndr occ) -- body -------------- next part -------------- An HTML attachment was scrubbed... URL: From marlowsd at gmail.com Tue Nov 6 11:09:40 2018 From: marlowsd at gmail.com (Simon Marlow) Date: Tue, 6 Nov 2018 11:09:40 +0000 Subject: [GHC DevOps Group] The future of Phabricator In-Reply-To: <87in1ew24z.fsf@smart-cactus.org> References: <87zhuw2fw2.fsf@smart-cactus.org> <87tvl31bps.fsf@smart-cactus.org> <87tvkzsvmk.fsf@gmail.com> <87in1ew24z.fsf@smart-cactus.org> Message-ID: For those of us that like to upload code for review without having to go to a website and click buttons, it looks like there's this CLI tool for GitLab: https://github.com/zaquestion/lab Unfortunately it's written in Go. But I guess that's an improvement over PHP :) Cheers Simon On Sat, 3 Nov 2018 at 16:35, Ben Gamari wrote: > Simon Marlow writes: > > > On Fri, 2 Nov 2018 at 08:59, Herbert Valerio Riedel > > wrote: > > > >> On 2018-11-02 at 08:13:37 +0000, Simon Marlow wrote: > >> > >> > I suppose we can do a squash-merge when committing to keep the history > >> > clean, but then contributors have a choice - either do GitHub-style > >> > where you add commits to a PR to update it and we squash on merge, OR > >> > Phabricator-style where you keep the same set of commits and rebase > >> > the stack to update it. > >> [..] > >> > >> Well, if MRs are to be squashed on merge anyway, I'm definitely not > >> going to waste my time carefully grooming a stack of atomic individually > >> validating commits via git-rebase-interactive... > >> > > > > Sorry I wasn't very clear. We would *only* squash if the author had been > > using the workflow where they add commits to revise the MR. If the author > > wants to use the stacked-diff-like workflow where they keep a groomed set > > of commits in the MR, then we would rebase and fast-forward the MR. > > > > My concern here is that we have two different workflows. People used to > > GitHub would want to use one, and people used to Phabricator would want > to > > use the other. We have to check which workflow people are using so that > we > > can decide whether to squash on merge or not. > > > Ahh, yes, I see. > > > Ben said: > > > >> This shouldn't be a problem. One can easily configure a project such > > that users are *only* allowed to fast-forward/rebase, disallowing the > > creation of merge commits. > > > > but that doesn't fully address the problem, because the series of commits > > that would get rebased onto master would include all the commits added to > > the MR to update it during the review process. Actually what we wanted to > > do in this case was squash, not rebase+fast-forward. > > > Indeed, this is a problem that we already have in the case of GitHub > pull requests. In most of these cases I end up squashing the branch > myself when I merge (in practice this contributes very little overhead; > I need to merge GitHub PR's myself anyways as we cannot use GitHub's > merge button since github.com:ghc/ghc is merely a mirror of > git.haskell.org:ghc). > > Of course, if we start taking *all* of our patches via MRs then I agree > that this may become a bit more tiresome. > > > If there was a nice way to guide people into using the Phabricator-style > > workflow, I think that would help a lot. > > > I think this is primarily a social problem and consequently it is > probably best handled by a combination of documentation (both in the > contributor documentation and the MR template text) and code review. > > One of the things I would like to do in the near future is consolidate > (and, in some cases, rewrite) our contributor documentation. The survey > indicated that there is plenty of room for improvement here. In this > past we have discussed improving in this area but lacked the bandwidth > to give the task the attention it deserves. I think now we are in better > shape to resource it sufficiently. > > Cheers, > > - Ben > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From csaba.hruska at gmail.com Tue Nov 6 11:19:13 2018 From: csaba.hruska at gmail.com (Csaba Hruska) Date: Tue, 6 Nov 2018 12:19:13 +0100 Subject: StgRhsClosure freevar and argument name duplicates In-Reply-To: References: Message-ID: I've also noticed that there are two Main.main top-level binders in the generated STG with different uniques? And GHC produces a working executable. Is Main.main an exception or does top-level names have some kind of "should be exported" property? On Tue, Nov 6, 2018 at 12:02 PM Simon Peyton Jones wrote: > I think top level names should be unique in occ-names; because those > occ-names generate the symbols in the binary. > > > > Simon > > > > *From:* Csaba Hruska > *Sent:* 06 November 2018 11:01 > *To:* Simon Peyton Jones > *Cc:* ghc-devs at haskell.org > *Subject:* Re: StgRhsClosure freevar and argument name duplicates > > > > My plan is to extend GHC's STG linter to check the following properties: > > - uniqueness of free var and arg list of StgRhsClosure > - top level binding name uniqueness > > I'll patch my local GHC 8.2.2 and GHC HEAD. I'll also attach the patch to > the ticket. > > I have a question regarding top level names. > > Should the top-level names be unique as occ names or just in unique values? > > If not, then what is the rule? > > > > Thanks, > > Csaba > > > > On Tue, Nov 6, 2018 at 11:13 AM Simon Peyton Jones > wrote: > > Does this happen in HEAD with GHC’s own STG printer? If so, could you > file a Trac ticket – it’s clearly wrong. > > > > But I do wonder if it could perhaps be something to do with your branch? > > > > Thanks > > > > Simon > > > > *From:* Csaba Hruska > *Sent:* 05 November 2018 16:33 > *To:* Simon Peyton Jones > *Cc:* ghc-devs at haskell.org > *Subject:* Re: StgRhsClosure freevar and argument name duplicates > > > > Correction! > > The problem happens in integer-gmp: > > https://github.com/ghc/ghc/blob/master/libraries/integer-gmp/src/GHC/Integer/Type.hs#L761-L770 > > > > > On Mon, Nov 5, 2018 at 5:27 PM Csaba Hruska > wrote: > > An example for the duplication please check the divModInteger > > function from integer-simple GHC.Integer.Type. > > The STG (GHC 8.2.2) generated from *divModInteger* *::** Integer -> > Integer -> (# Integer, Integer #) *contains duplications in a closure > binder list. > > > > Using my custom STG printer it looks like: > > module GHC.Integer.Type where > > > > using GHC.Prim > using GHC.Tuple > using GHC.Types > > > > GHC.Integer.Type.divModInteger {-083-} = > closure (F:) (B: > n.s84123 {-s84123-} > d.s84124 {-s84124-}) { > case GHC.Integer.Type.quotRemInteger {-084-} > n.s84123 {-s84123-} > d.s84124 {-s84124-} > of qr.s84125 {-s84125-} { > GHC.Prim.(#,#) {-86-} ipv.s84126 {-s84126-} ipv1.s84127 {-s84127-} -> > let $j.s84128 {-s84128-} = > closure (F: > d.s84124 {-s84124-} > * ipv.s84126 {-s84126-}* > * ipv1.s84127 {-s84127-}* > * ipv.s84126 {-s84126-}* > *ipv1.s84127 {-s84127-}*) (B: > wild.s84129 {-s84129-}) { > let $j1.s84130 {-s84130-} = > closure (F: > d.s84124 {-s84124-} > ipv.s84126 {-s84126-} > ipv1.s84127 {-s84127-} > ipv.s84126 {-s84126-} > ipv1.s84127 {-s84127-} > wild.s84129 {-s84129-}) (B: > wild1.s84131 {-s84131-}) { > case _stg_prim_negateInt# > wild.s84129 {-s84129-} > of sat.s84132 {-s84132-} { > DEFAULT -> > case _stg_prim_==# > wild1.s84131 {-s84131-} > sat.s84132 {-s84132-} > of sat.s84133 {-s84133-} { > DEFAULT -> > case _stg_prim_tagToEnum# > sat.s84133 {-s84133-} > of wild2.s84134 {-s84134-} { > GHC.Types.False {-612-} -> > GHC.Prim.(#,#) {-86-} > ipv.s84126 {-s84126-} > ipv1.s84127 {-s84127-} > GHC.Types.True {-645-} -> > case GHC.Integer.Type.plusInteger {-066-} > ipv1.s84127 {-s84127-} > d.s84124 {-s84124-} > of r'.s84135 {-s84135-} { > DEFAULT -> > case GHC.Integer.Type.plusInteger {-066-} > ipv.s84126 {-s84126-} > GHC.Integer.Type.lvl11 {-r50574-} > of q'.s84136 {-s84136-} { > DEFAULT -> > GHC.Prim.(#,#) {-86-} > q'.s84136 {-s84136-} > r'.s84135 {-s84135-} > } > } > } > } > }} > > in case ipv1.s84127 {-s84127-} > of wild1.s84137 {-s84137-} { > GHC.Integer.Type.S# {-621-} i#.s84138 {-s84138-} -> > case _stg_prim_<# > i#.s84138 {-s84138-} 0# > of sat.s84140 {-s84140-} { > DEFAULT -> > case _stg_prim_># > i#.s84138 {-s84138-} 0# > of sat.s84139 {-s84139-} { > DEFAULT -> > case _stg_prim_-# > sat.s84139 {-s84139-} > sat.s84140 {-s84140-} > of sat.s84141 {-s84141-} { > DEFAULT -> > $j1.s84130 {-s84130-} > sat.s84141 {-s84141-} > } > } > } > GHC.Integer.Type.Jp# > > {-r5813-} dt.s84142 {-s84142-} -> > $j1.s84130 {-s84130-} 1# > GHC.Integer.Type.Jn# {-r5814-} dt.s84143 {-s84143-} -> > $j1.s84130 {-s84130-} -1# > }} > > in case d.s84124 {-s84124-} > of wild.s84144 {-s84144-} { > GHC.Integer.Type.S# {-621-} i#.s84145 {-s84145-} -> > case _stg_prim_<# > i#.s84145 {-s84145-} 0# > of sat.s84147 {-s84147-} { > DEFAULT -> > case _stg_prim_># > i#.s84145 {-s84145-} 0# > of sat.s84146 {-s84146-} { > DEFAULT -> > case _stg_prim_-# > sat.s84146 {-s84146-} > sat.s84147 {-s84147-} > of sat.s84148 {-s84148-} { > DEFAULT -> > $j.s84128 {-s84128-} > sat.s84148 {-s84148-} > } > } > } > GHC.Integer.Type.Jp# > > {-r5813-} dt.s84149 {-s84149-} -> > $j.s84128 {-s84128-} 1# > GHC.Integer.Type.Jn# {-r5814-} dt.s84150 {-s84150-} -> > $j.s84128 {-s84128-} -1# > } > }} > > > > On Mon, Nov 5, 2018 at 2:08 PM Simon Peyton Jones > wrote: > > I don’t think there should be duplicates in either. Do you have a test > case that shows duplicates? > > > > Simon > > > > *From:* ghc-devs *On Behalf Of *Csaba > Hruska > *Sent:* 04 November 2018 11:22 > *To:* ghc-devs at haskell.org > *Subject:* Re: StgRhsClosure freevar and argument name duplicates > > > > Is it possible that GHC generates STG with invalid binding semantics for > certain cases that the Cmm codegen fix or ignore? > > This could explain my observations. > > I've checked the Stg linter source (StgLint.hs ; GHC 8.2.2 and github > master) and it does not check StgRhsClosure free var and binder list at all. > > And the scope checker function (addInScopeVars) does not check for > duplicates. > > > > Any thoughts? > > > > Cheers, > > Csaba > > > > On Sat, Nov 3, 2018 at 9:53 AM Csaba Hruska > wrote: > > Hi, > > > > Can StgRhsClosure's freevar list ([occ]) or argument list ([bndr]) contain > duplicates? > > > > Cheers, > > Csaba > > > > data GenStgRhs bndr occ > = StgRhsClosure > CostCentreStack -- CCS to be attached (default is > CurrentCCS) > StgBinderInfo -- Info about how this binder is used (see > below) > *[occ]* -- non-global free vars; a list, rather > than > -- a set, because order is important > !UpdateFlag -- ReEntrant | Updatable | SingleEntry > *[bndr]* -- arguments; if empty, then not a > function; > -- as above, order is important. > (GenStgExpr bndr occ) -- body > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From csaba.hruska at gmail.com Tue Nov 6 11:19:51 2018 From: csaba.hruska at gmail.com (Csaba Hruska) Date: Tue, 6 Nov 2018 12:19:51 +0100 Subject: StgRhsClosure freevar and argument name duplicates In-Reply-To: References: Message-ID: Correction: I've also noticed that there are two Main.main top-level binders in the generated STG with different uniques. On Tue, Nov 6, 2018 at 12:19 PM Csaba Hruska wrote: > I've also noticed that there are two Main.main top-level binders in the > generated STG with different uniques? > And GHC produces a working executable. > Is Main.main an exception or does top-level names have some kind of > "should be exported" property? > > On Tue, Nov 6, 2018 at 12:02 PM Simon Peyton Jones > wrote: > >> I think top level names should be unique in occ-names; because those >> occ-names generate the symbols in the binary. >> >> >> >> Simon >> >> >> >> *From:* Csaba Hruska >> *Sent:* 06 November 2018 11:01 >> *To:* Simon Peyton Jones >> *Cc:* ghc-devs at haskell.org >> *Subject:* Re: StgRhsClosure freevar and argument name duplicates >> >> >> >> My plan is to extend GHC's STG linter to check the following properties: >> >> - uniqueness of free var and arg list of StgRhsClosure >> - top level binding name uniqueness >> >> I'll patch my local GHC 8.2.2 and GHC HEAD. I'll also attach the patch to >> the ticket. >> >> I have a question regarding top level names. >> >> Should the top-level names be unique as occ names or just in unique >> values? >> >> If not, then what is the rule? >> >> >> >> Thanks, >> >> Csaba >> >> >> >> On Tue, Nov 6, 2018 at 11:13 AM Simon Peyton Jones >> wrote: >> >> Does this happen in HEAD with GHC’s own STG printer? If so, could you >> file a Trac ticket – it’s clearly wrong. >> >> >> >> But I do wonder if it could perhaps be something to do with your branch? >> >> >> >> Thanks >> >> >> >> Simon >> >> >> >> *From:* Csaba Hruska >> *Sent:* 05 November 2018 16:33 >> *To:* Simon Peyton Jones >> *Cc:* ghc-devs at haskell.org >> *Subject:* Re: StgRhsClosure freevar and argument name duplicates >> >> >> >> Correction! >> >> The problem happens in integer-gmp: >> >> https://github.com/ghc/ghc/blob/master/libraries/integer-gmp/src/GHC/Integer/Type.hs#L761-L770 >> >> >> >> >> On Mon, Nov 5, 2018 at 5:27 PM Csaba Hruska >> wrote: >> >> An example for the duplication please check the divModInteger >> >> function from integer-simple GHC.Integer.Type. >> >> The STG (GHC 8.2.2) generated from *divModInteger* *::** Integer -> >> Integer -> (# Integer, Integer #) *contains duplications in a closure >> binder list. >> >> >> >> Using my custom STG printer it looks like: >> >> module GHC.Integer.Type where >> >> >> >> using GHC.Prim >> using GHC.Tuple >> using GHC.Types >> >> >> >> GHC.Integer.Type.divModInteger {-083-} = >> closure (F:) (B: >> n.s84123 {-s84123-} >> d.s84124 {-s84124-}) { >> case GHC.Integer.Type.quotRemInteger {-084-} >> n.s84123 {-s84123-} >> d.s84124 {-s84124-} >> of qr.s84125 {-s84125-} { >> GHC.Prim.(#,#) {-86-} ipv.s84126 {-s84126-} ipv1.s84127 {-s84127-} -> >> let $j.s84128 {-s84128-} = >> closure (F: >> d.s84124 {-s84124-} >> * ipv.s84126 {-s84126-}* >> * ipv1.s84127 {-s84127-}* >> * ipv.s84126 {-s84126-}* >> *ipv1.s84127 {-s84127-}*) (B: >> wild.s84129 {-s84129-}) { >> let $j1.s84130 {-s84130-} = >> closure (F: >> d.s84124 {-s84124-} >> ipv.s84126 {-s84126-} >> ipv1.s84127 {-s84127-} >> ipv.s84126 {-s84126-} >> ipv1.s84127 {-s84127-} >> wild.s84129 {-s84129-}) (B: >> wild1.s84131 {-s84131-}) { >> case _stg_prim_negateInt# >> wild.s84129 {-s84129-} >> of sat.s84132 {-s84132-} { >> DEFAULT -> >> case _stg_prim_==# >> wild1.s84131 {-s84131-} >> sat.s84132 {-s84132-} >> of sat.s84133 {-s84133-} { >> DEFAULT -> >> case _stg_prim_tagToEnum# >> sat.s84133 {-s84133-} >> of wild2.s84134 {-s84134-} { >> GHC.Types.False {-612-} -> >> GHC.Prim.(#,#) {-86-} >> ipv.s84126 {-s84126-} >> ipv1.s84127 {-s84127-} >> GHC.Types.True {-645-} -> >> case GHC.Integer.Type.plusInteger {-066-} >> ipv1.s84127 {-s84127-} >> d.s84124 {-s84124-} >> of r'.s84135 {-s84135-} { >> DEFAULT -> >> case GHC.Integer.Type.plusInteger >> {-066-} >> ipv.s84126 {-s84126-} >> GHC.Integer.Type.lvl11 {-r50574-} >> of q'.s84136 {-s84136-} { >> DEFAULT -> >> GHC.Prim.(#,#) {-86-} >> q'.s84136 {-s84136-} >> r'.s84135 {-s84135-} >> } >> } >> } >> } >> }} >> >> in case ipv1.s84127 {-s84127-} >> of wild1.s84137 {-s84137-} { >> GHC.Integer.Type.S# {-621-} i#.s84138 {-s84138-} -> >> case _stg_prim_<# >> i#.s84138 {-s84138-} 0# >> of sat.s84140 {-s84140-} { >> DEFAULT -> >> case _stg_prim_># >> i#.s84138 {-s84138-} 0# >> of sat.s84139 {-s84139-} { >> DEFAULT -> >> case _stg_prim_-# >> sat.s84139 {-s84139-} >> sat.s84140 {-s84140-} >> of sat.s84141 {-s84141-} { >> DEFAULT -> >> $j1.s84130 {-s84130-} >> sat.s84141 {-s84141-} >> } >> } >> } >> GHC.Integer.Type.Jp# >> >> {-r5813-} dt.s84142 {-s84142-} -> >> $j1.s84130 {-s84130-} 1# >> GHC.Integer.Type.Jn# {-r5814-} dt.s84143 {-s84143-} -> >> $j1.s84130 {-s84130-} -1# >> }} >> >> in case d.s84124 {-s84124-} >> of wild.s84144 {-s84144-} { >> GHC.Integer.Type.S# {-621-} i#.s84145 {-s84145-} -> >> case _stg_prim_<# >> i#.s84145 {-s84145-} 0# >> of sat.s84147 {-s84147-} { >> DEFAULT -> >> case _stg_prim_># >> i#.s84145 {-s84145-} 0# >> of sat.s84146 {-s84146-} { >> DEFAULT -> >> case _stg_prim_-# >> sat.s84146 {-s84146-} >> sat.s84147 {-s84147-} >> of sat.s84148 {-s84148-} { >> DEFAULT -> >> $j.s84128 {-s84128-} >> sat.s84148 {-s84148-} >> } >> } >> } >> GHC.Integer.Type.Jp# >> >> {-r5813-} dt.s84149 {-s84149-} -> >> $j.s84128 {-s84128-} 1# >> GHC.Integer.Type.Jn# {-r5814-} dt.s84150 {-s84150-} -> >> $j.s84128 {-s84128-} -1# >> } >> }} >> >> >> >> On Mon, Nov 5, 2018 at 2:08 PM Simon Peyton Jones >> wrote: >> >> I don’t think there should be duplicates in either. Do you have a test >> case that shows duplicates? >> >> >> >> Simon >> >> >> >> *From:* ghc-devs *On Behalf Of *Csaba >> Hruska >> *Sent:* 04 November 2018 11:22 >> *To:* ghc-devs at haskell.org >> *Subject:* Re: StgRhsClosure freevar and argument name duplicates >> >> >> >> Is it possible that GHC generates STG with invalid binding semantics for >> certain cases that the Cmm codegen fix or ignore? >> >> This could explain my observations. >> >> I've checked the Stg linter source (StgLint.hs ; GHC 8.2.2 and github >> master) and it does not check StgRhsClosure free var and binder list at all. >> >> And the scope checker function (addInScopeVars) does not check for >> duplicates. >> >> >> >> Any thoughts? >> >> >> >> Cheers, >> >> Csaba >> >> >> >> On Sat, Nov 3, 2018 at 9:53 AM Csaba Hruska >> wrote: >> >> Hi, >> >> >> >> Can StgRhsClosure's freevar list ([occ]) or argument list ([bndr]) >> contain duplicates? >> >> >> >> Cheers, >> >> Csaba >> >> >> >> data GenStgRhs bndr occ >> = StgRhsClosure >> CostCentreStack -- CCS to be attached (default is >> CurrentCCS) >> StgBinderInfo -- Info about how this binder is used >> (see below) >> *[occ]* -- non-global free vars; a list, >> rather than >> -- a set, because order is important >> !UpdateFlag -- ReEntrant | Updatable | SingleEntry >> *[bndr]* -- arguments; if empty, then not a >> function; >> -- as above, order is important. >> (GenStgExpr bndr occ) -- body >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From csaba.hruska at gmail.com Tue Nov 6 15:36:22 2018 From: csaba.hruska at gmail.com (Csaba Hruska) Date: Tue, 6 Nov 2018 16:36:22 +0100 Subject: StgRhsClosure freevar and argument name duplicates In-Reply-To: References: Message-ID: You can reproduce the error with the GHC HEAD and with the attached patch for StgLinter. The patch adds scope checking for the linter. I've also attached the linter's error output against GHC HEAD. Compile GHC HEAD with the following settings: GhcStage1HcOpts= GhcStage2HcOpts=-O2 -haddock -dstg-lint GhcStage3HcOpts=-O2 -haddock -dstg-lint Regards, Csaba On Tue, Nov 6, 2018 at 12:19 PM Csaba Hruska wrote: > Correction: I've also noticed that there are two Main.main top-level > binders in the generated STG with different uniques. > > On Tue, Nov 6, 2018 at 12:19 PM Csaba Hruska > wrote: > >> I've also noticed that there are two Main.main top-level binders in the >> generated STG with different uniques? >> And GHC produces a working executable. >> Is Main.main an exception or does top-level names have some kind of >> "should be exported" property? >> >> On Tue, Nov 6, 2018 at 12:02 PM Simon Peyton Jones >> wrote: >> >>> I think top level names should be unique in occ-names; because those >>> occ-names generate the symbols in the binary. >>> >>> >>> >>> Simon >>> >>> >>> >>> *From:* Csaba Hruska >>> *Sent:* 06 November 2018 11:01 >>> *To:* Simon Peyton Jones >>> *Cc:* ghc-devs at haskell.org >>> *Subject:* Re: StgRhsClosure freevar and argument name duplicates >>> >>> >>> >>> My plan is to extend GHC's STG linter to check the following properties: >>> >>> - uniqueness of free var and arg list of StgRhsClosure >>> - top level binding name uniqueness >>> >>> I'll patch my local GHC 8.2.2 and GHC HEAD. I'll also attach the patch >>> to the ticket. >>> >>> I have a question regarding top level names. >>> >>> Should the top-level names be unique as occ names or just in unique >>> values? >>> >>> If not, then what is the rule? >>> >>> >>> >>> Thanks, >>> >>> Csaba >>> >>> >>> >>> On Tue, Nov 6, 2018 at 11:13 AM Simon Peyton Jones < >>> simonpj at microsoft.com> wrote: >>> >>> Does this happen in HEAD with GHC’s own STG printer? If so, could you >>> file a Trac ticket – it’s clearly wrong. >>> >>> >>> >>> But I do wonder if it could perhaps be something to do with your branch? >>> >>> >>> >>> Thanks >>> >>> >>> >>> Simon >>> >>> >>> >>> *From:* Csaba Hruska >>> *Sent:* 05 November 2018 16:33 >>> *To:* Simon Peyton Jones >>> *Cc:* ghc-devs at haskell.org >>> *Subject:* Re: StgRhsClosure freevar and argument name duplicates >>> >>> >>> >>> Correction! >>> >>> The problem happens in integer-gmp: >>> >>> https://github.com/ghc/ghc/blob/master/libraries/integer-gmp/src/GHC/Integer/Type.hs#L761-L770 >>> >>> >>> >>> >>> On Mon, Nov 5, 2018 at 5:27 PM Csaba Hruska >>> wrote: >>> >>> An example for the duplication please check the divModInteger >>> >>> function from integer-simple GHC.Integer.Type. >>> >>> The STG (GHC 8.2.2) generated from *divModInteger* *::** Integer -> >>> Integer -> (# Integer, Integer #) *contains duplications in a closure >>> binder list. >>> >>> >>> >>> Using my custom STG printer it looks like: >>> >>> module GHC.Integer.Type where >>> >>> >>> >>> using GHC.Prim >>> using GHC.Tuple >>> using GHC.Types >>> >>> >>> >>> GHC.Integer.Type.divModInteger {-083-} = >>> closure (F:) (B: >>> n.s84123 {-s84123-} >>> d.s84124 {-s84124-}) { >>> case GHC.Integer.Type.quotRemInteger {-084-} >>> n.s84123 {-s84123-} >>> d.s84124 {-s84124-} >>> of qr.s84125 {-s84125-} { >>> GHC.Prim.(#,#) {-86-} ipv.s84126 {-s84126-} ipv1.s84127 {-s84127-} -> >>> let $j.s84128 {-s84128-} = >>> closure (F: >>> d.s84124 {-s84124-} >>> * ipv.s84126 {-s84126-}* >>> * ipv1.s84127 {-s84127-}* >>> * ipv.s84126 {-s84126-}* >>> *ipv1.s84127 {-s84127-}*) (B: >>> wild.s84129 {-s84129-}) { >>> let $j1.s84130 {-s84130-} = >>> closure (F: >>> d.s84124 {-s84124-} >>> ipv.s84126 {-s84126-} >>> ipv1.s84127 {-s84127-} >>> ipv.s84126 {-s84126-} >>> ipv1.s84127 {-s84127-} >>> wild.s84129 {-s84129-}) (B: >>> wild1.s84131 {-s84131-}) { >>> case _stg_prim_negateInt# >>> wild.s84129 {-s84129-} >>> of sat.s84132 {-s84132-} { >>> DEFAULT -> >>> case _stg_prim_==# >>> wild1.s84131 {-s84131-} >>> sat.s84132 {-s84132-} >>> of sat.s84133 {-s84133-} { >>> DEFAULT -> >>> case _stg_prim_tagToEnum# >>> sat.s84133 {-s84133-} >>> of wild2.s84134 {-s84134-} { >>> GHC.Types.False {-612-} -> >>> GHC.Prim.(#,#) {-86-} >>> ipv.s84126 {-s84126-} >>> ipv1.s84127 {-s84127-} >>> GHC.Types.True {-645-} -> >>> case GHC.Integer.Type.plusInteger {-066-} >>> ipv1.s84127 {-s84127-} >>> d.s84124 {-s84124-} >>> of r'.s84135 {-s84135-} { >>> DEFAULT -> >>> case GHC.Integer.Type.plusInteger >>> {-066-} >>> ipv.s84126 {-s84126-} >>> GHC.Integer.Type.lvl11 >>> {-r50574-} >>> of q'.s84136 {-s84136-} { >>> DEFAULT -> >>> GHC.Prim.(#,#) {-86-} >>> q'.s84136 {-s84136-} >>> r'.s84135 {-s84135-} >>> } >>> } >>> } >>> } >>> }} >>> >>> in case ipv1.s84127 {-s84127-} >>> of wild1.s84137 {-s84137-} { >>> GHC.Integer.Type.S# {-621-} i#.s84138 {-s84138-} -> >>> case _stg_prim_<# >>> i#.s84138 {-s84138-} 0# >>> of sat.s84140 {-s84140-} { >>> DEFAULT -> >>> case _stg_prim_># >>> i#.s84138 {-s84138-} 0# >>> of sat.s84139 {-s84139-} { >>> DEFAULT -> >>> case _stg_prim_-# >>> sat.s84139 {-s84139-} >>> sat.s84140 {-s84140-} >>> of sat.s84141 {-s84141-} { >>> DEFAULT -> >>> $j1.s84130 {-s84130-} >>> sat.s84141 {-s84141-} >>> } >>> } >>> } >>> GHC.Integer.Type.Jp# >>> >>> {-r5813-} dt.s84142 {-s84142-} -> >>> $j1.s84130 {-s84130-} 1# >>> GHC.Integer.Type.Jn# {-r5814-} dt.s84143 {-s84143-} -> >>> $j1.s84130 {-s84130-} -1# >>> }} >>> >>> in case d.s84124 {-s84124-} >>> of wild.s84144 {-s84144-} { >>> GHC.Integer.Type.S# {-621-} i#.s84145 {-s84145-} -> >>> case _stg_prim_<# >>> i#.s84145 {-s84145-} 0# >>> of sat.s84147 {-s84147-} { >>> DEFAULT -> >>> case _stg_prim_># >>> i#.s84145 {-s84145-} 0# >>> of sat.s84146 {-s84146-} { >>> DEFAULT -> >>> case _stg_prim_-# >>> sat.s84146 {-s84146-} >>> sat.s84147 {-s84147-} >>> of sat.s84148 {-s84148-} { >>> DEFAULT -> >>> $j.s84128 {-s84128-} >>> sat.s84148 {-s84148-} >>> } >>> } >>> } >>> GHC.Integer.Type.Jp# >>> >>> {-r5813-} dt.s84149 {-s84149-} -> >>> $j.s84128 {-s84128-} 1# >>> GHC.Integer.Type.Jn# {-r5814-} dt.s84150 {-s84150-} -> >>> $j.s84128 {-s84128-} -1# >>> } >>> }} >>> >>> >>> >>> On Mon, Nov 5, 2018 at 2:08 PM Simon Peyton Jones >>> wrote: >>> >>> I don’t think there should be duplicates in either. Do you have a test >>> case that shows duplicates? >>> >>> >>> >>> Simon >>> >>> >>> >>> *From:* ghc-devs *On Behalf Of *Csaba >>> Hruska >>> *Sent:* 04 November 2018 11:22 >>> *To:* ghc-devs at haskell.org >>> *Subject:* Re: StgRhsClosure freevar and argument name duplicates >>> >>> >>> >>> Is it possible that GHC generates STG with invalid binding semantics for >>> certain cases that the Cmm codegen fix or ignore? >>> >>> This could explain my observations. >>> >>> I've checked the Stg linter source (StgLint.hs ; GHC 8.2.2 and github >>> master) and it does not check StgRhsClosure free var and binder list at all. >>> >>> And the scope checker function (addInScopeVars) does not check for >>> duplicates. >>> >>> >>> >>> Any thoughts? >>> >>> >>> >>> Cheers, >>> >>> Csaba >>> >>> >>> >>> On Sat, Nov 3, 2018 at 9:53 AM Csaba Hruska >>> wrote: >>> >>> Hi, >>> >>> >>> >>> Can StgRhsClosure's freevar list ([occ]) or argument list ([bndr]) >>> contain duplicates? >>> >>> >>> >>> Cheers, >>> >>> Csaba >>> >>> >>> >>> data GenStgRhs bndr occ >>> = StgRhsClosure >>> CostCentreStack -- CCS to be attached (default is >>> CurrentCCS) >>> StgBinderInfo -- Info about how this binder is used >>> (see below) >>> *[occ]* -- non-global free vars; a list, >>> rather than >>> -- a set, because order is important >>> !UpdateFlag -- ReEntrant | Updatable | SingleEntry >>> *[bndr]* -- arguments; if empty, then not a >>> function; >>> -- as above, order is important. >>> (GenStgExpr bndr occ) -- body >>> >>> >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: StgScopeCheck.patch Type: text/x-patch Size: 4203 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: stg-error.out Type: application/octet-stream Size: 1547973 bytes Desc: not available URL: From simonpj at microsoft.com Tue Nov 6 15:39:01 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Tue, 6 Nov 2018 15:39:01 +0000 Subject: StgRhsClosure freevar and argument name duplicates In-Reply-To: References: Message-ID: can you open a Trac ticket, and explain how to reproduce it? Does it require a patch, or does -ddump-stg show it? thanks Simion From: Csaba Hruska Sent: 06 November 2018 15:36 To: Simon Peyton Jones Cc: ghc-devs at haskell.org Subject: Re: StgRhsClosure freevar and argument name duplicates You can reproduce the error with the GHC HEAD and with the attached patch for StgLinter. The patch adds scope checking for the linter. I've also attached the linter's error output against GHC HEAD. Compile GHC HEAD with the following settings: GhcStage1HcOpts= GhcStage2HcOpts=-O2 -haddock -dstg-lint GhcStage3HcOpts=-O2 -haddock -dstg-lint Regards, Csaba On Tue, Nov 6, 2018 at 12:19 PM Csaba Hruska > wrote: Correction: I've also noticed that there are two Main.main top-level binders in the generated STG with different uniques. On Tue, Nov 6, 2018 at 12:19 PM Csaba Hruska > wrote: I've also noticed that there are two Main.main top-level binders in the generated STG with different uniques? And GHC produces a working executable. Is Main.main an exception or does top-level names have some kind of "should be exported" property? On Tue, Nov 6, 2018 at 12:02 PM Simon Peyton Jones > wrote: I think top level names should be unique in occ-names; because those occ-names generate the symbols in the binary. Simon From: Csaba Hruska > Sent: 06 November 2018 11:01 To: Simon Peyton Jones > Cc: ghc-devs at haskell.org Subject: Re: StgRhsClosure freevar and argument name duplicates My plan is to extend GHC's STG linter to check the following properties: * uniqueness of free var and arg list of StgRhsClosure * top level binding name uniqueness I'll patch my local GHC 8.2.2 and GHC HEAD. I'll also attach the patch to the ticket. I have a question regarding top level names. Should the top-level names be unique as occ names or just in unique values? If not, then what is the rule? Thanks, Csaba On Tue, Nov 6, 2018 at 11:13 AM Simon Peyton Jones > wrote: Does this happen in HEAD with GHC’s own STG printer? If so, could you file a Trac ticket – it’s clearly wrong. But I do wonder if it could perhaps be something to do with your branch? Thanks Simon From: Csaba Hruska > Sent: 05 November 2018 16:33 To: Simon Peyton Jones > Cc: ghc-devs at haskell.org Subject: Re: StgRhsClosure freevar and argument name duplicates Correction! The problem happens in integer-gmp: https://github.com/ghc/ghc/blob/master/libraries/integer-gmp/src/GHC/Integer/Type.hs#L761-L770 On Mon, Nov 5, 2018 at 5:27 PM Csaba Hruska > wrote: An example for the duplication please check the divModInteger function from integer-simple GHC.Integer.Type. The STG (GHC 8.2.2) generated from divModInteger :: Integer -> Integer -> (# Integer, Integer #) contains duplications in a closure binder list. Using my custom STG printer it looks like: module GHC.Integer.Type where using GHC.Prim using GHC.Tuple using GHC.Types GHC.Integer.Type.divModInteger {-083-} = closure (F:) (B: n.s84123 {-s84123-} d.s84124 {-s84124-}) { case GHC.Integer.Type.quotRemInteger {-084-} n.s84123 {-s84123-} d.s84124 {-s84124-} of qr.s84125 {-s84125-} { GHC.Prim.(#,#) {-86-} ipv.s84126 {-s84126-} ipv1.s84127 {-s84127-} -> let $j.s84128 {-s84128-} = closure (F: d.s84124 {-s84124-} ipv.s84126 {-s84126-} ipv1.s84127 {-s84127-} ipv.s84126 {-s84126-} ipv1.s84127 {-s84127-}) (B: wild.s84129 {-s84129-}) { let $j1.s84130 {-s84130-} = closure (F: d.s84124 {-s84124-} ipv.s84126 {-s84126-} ipv1.s84127 {-s84127-} ipv.s84126 {-s84126-} ipv1.s84127 {-s84127-} wild.s84129 {-s84129-}) (B: wild1.s84131 {-s84131-}) { case _stg_prim_negateInt# wild.s84129 {-s84129-} of sat.s84132 {-s84132-} { DEFAULT -> case _stg_prim_==# wild1.s84131 {-s84131-} sat.s84132 {-s84132-} of sat.s84133 {-s84133-} { DEFAULT -> case _stg_prim_tagToEnum# sat.s84133 {-s84133-} of wild2.s84134 {-s84134-} { GHC.Types.False {-612-} -> GHC.Prim.(#,#) {-86-} ipv.s84126 {-s84126-} ipv1.s84127 {-s84127-} GHC.Types.True {-645-} -> case GHC.Integer.Type.plusInteger {-066-} ipv1.s84127 {-s84127-} d.s84124 {-s84124-} of r'.s84135 {-s84135-} { DEFAULT -> case GHC.Integer.Type.plusInteger {-066-} ipv.s84126 {-s84126-} GHC.Integer.Type.lvl11 {-r50574-} of q'.s84136 {-s84136-} { DEFAULT -> GHC.Prim.(#,#) {-86-} q'.s84136 {-s84136-} r'.s84135 {-s84135-} } } } } }} in case ipv1.s84127 {-s84127-} of wild1.s84137 {-s84137-} { GHC.Integer.Type.S# {-621-} i#.s84138 {-s84138-} -> case _stg_prim_<# i#.s84138 {-s84138-} 0# of sat.s84140 {-s84140-} { DEFAULT -> case _stg_prim_># i#.s84138 {-s84138-} 0# of sat.s84139 {-s84139-} { DEFAULT -> case _stg_prim_-# sat.s84139 {-s84139-} sat.s84140 {-s84140-} of sat.s84141 {-s84141-} { DEFAULT -> $j1.s84130 {-s84130-} sat.s84141 {-s84141-} } } } GHC.Integer.Type.Jp# {-r5813-} dt.s84142 {-s84142-} -> $j1.s84130 {-s84130-} 1# GHC.Integer.Type.Jn# {-r5814-} dt.s84143 {-s84143-} -> $j1.s84130 {-s84130-} -1# }} in case d.s84124 {-s84124-} of wild.s84144 {-s84144-} { GHC.Integer.Type.S# {-621-} i#.s84145 {-s84145-} -> case _stg_prim_<# i#.s84145 {-s84145-} 0# of sat.s84147 {-s84147-} { DEFAULT -> case _stg_prim_># i#.s84145 {-s84145-} 0# of sat.s84146 {-s84146-} { DEFAULT -> case _stg_prim_-# sat.s84146 {-s84146-} sat.s84147 {-s84147-} of sat.s84148 {-s84148-} { DEFAULT -> $j.s84128 {-s84128-} sat.s84148 {-s84148-} } } } GHC.Integer.Type.Jp# {-r5813-} dt.s84149 {-s84149-} -> $j.s84128 {-s84128-} 1# GHC.Integer.Type.Jn# {-r5814-} dt.s84150 {-s84150-} -> $j.s84128 {-s84128-} -1# } }} On Mon, Nov 5, 2018 at 2:08 PM Simon Peyton Jones > wrote: I don’t think there should be duplicates in either. Do you have a test case that shows duplicates? Simon From: ghc-devs > On Behalf Of Csaba Hruska Sent: 04 November 2018 11:22 To: ghc-devs at haskell.org Subject: Re: StgRhsClosure freevar and argument name duplicates Is it possible that GHC generates STG with invalid binding semantics for certain cases that the Cmm codegen fix or ignore? This could explain my observations. I've checked the Stg linter source (StgLint.hs ; GHC 8.2.2 and github master) and it does not check StgRhsClosure free var and binder list at all. And the scope checker function (addInScopeVars) does not check for duplicates. Any thoughts? Cheers, Csaba On Sat, Nov 3, 2018 at 9:53 AM Csaba Hruska > wrote: Hi, Can StgRhsClosure's freevar list ([occ]) or argument list ([bndr]) contain duplicates? Cheers, Csaba data GenStgRhs bndr occ = StgRhsClosure CostCentreStack -- CCS to be attached (default is CurrentCCS) StgBinderInfo -- Info about how this binder is used (see below) [occ] -- non-global free vars; a list, rather than -- a set, because order is important !UpdateFlag -- ReEntrant | Updatable | SingleEntry [bndr] -- arguments; if empty, then not a function; -- as above, order is important. (GenStgExpr bndr occ) -- body -------------- next part -------------- An HTML attachment was scrubbed... URL: From csaba.hruska at gmail.com Tue Nov 6 15:47:35 2018 From: csaba.hruska at gmail.com (Csaba Hruska) Date: Tue, 6 Nov 2018 16:47:35 +0100 Subject: StgRhsClosure freevar and argument name duplicates In-Reply-To: References: Message-ID: Ok, I'll open a ticket. To reproduce: 1. patch GHC head: *git apply StgScopeCheck.patch* 2. make sure every compiled stg is linted: *add -dstg-lint* to GhcStage2HcOpts GhcLibHcOpts GhcRtsHcOpts config vars 3. compile GHC HEAD On Tue, Nov 6, 2018 at 4:39 PM Simon Peyton Jones wrote: > can you open a Trac ticket, and explain how to reproduce it? Does it > require a patch, or does -ddump-stg show it? > > > > thanks > > > > Simion > > > > *From:* Csaba Hruska > *Sent:* 06 November 2018 15:36 > *To:* Simon Peyton Jones > *Cc:* ghc-devs at haskell.org > *Subject:* Re: StgRhsClosure freevar and argument name duplicates > > > > You can reproduce the error with the GHC HEAD and with the attached patch > for StgLinter. > > The patch adds scope checking for the linter. > > I've also attached the linter's error output against GHC HEAD. > > Compile GHC HEAD with the following settings: > > GhcStage1HcOpts= > GhcStage2HcOpts=-O2 -haddock -dstg-lint > GhcStage3HcOpts=-O2 -haddock -dstg-lint > > > > Regards, > > Csaba > > > > > > On Tue, Nov 6, 2018 at 12:19 PM Csaba Hruska > wrote: > > Correction: I've also noticed that there are two Main.main top-level > binders in the generated STG with different uniques. > > > > On Tue, Nov 6, 2018 at 12:19 PM Csaba Hruska > wrote: > > I've also noticed that there are two Main.main top-level binders in the > generated STG with different uniques? > > And GHC produces a working executable. > > Is Main.main an exception or does top-level names have some kind of > "should be exported" property? > > > > On Tue, Nov 6, 2018 at 12:02 PM Simon Peyton Jones > wrote: > > I think top level names should be unique in occ-names; because those > occ-names generate the symbols in the binary. > > > > Simon > > > > *From:* Csaba Hruska > *Sent:* 06 November 2018 11:01 > *To:* Simon Peyton Jones > *Cc:* ghc-devs at haskell.org > *Subject:* Re: StgRhsClosure freevar and argument name duplicates > > > > My plan is to extend GHC's STG linter to check the following properties: > > - uniqueness of free var and arg list of StgRhsClosure > - top level binding name uniqueness > > I'll patch my local GHC 8.2.2 and GHC HEAD. I'll also attach the patch to > the ticket. > > I have a question regarding top level names. > > Should the top-level names be unique as occ names or just in unique values? > > If not, then what is the rule? > > > > Thanks, > > Csaba > > > > On Tue, Nov 6, 2018 at 11:13 AM Simon Peyton Jones > wrote: > > Does this happen in HEAD with GHC’s own STG printer? If so, could you > file a Trac ticket – it’s clearly wrong. > > > > But I do wonder if it could perhaps be something to do with your branch? > > > > Thanks > > > > Simon > > > > *From:* Csaba Hruska > *Sent:* 05 November 2018 16:33 > *To:* Simon Peyton Jones > *Cc:* ghc-devs at haskell.org > *Subject:* Re: StgRhsClosure freevar and argument name duplicates > > > > Correction! > > The problem happens in integer-gmp: > > https://github.com/ghc/ghc/blob/master/libraries/integer-gmp/src/GHC/Integer/Type.hs#L761-L770 > > > > > On Mon, Nov 5, 2018 at 5:27 PM Csaba Hruska > wrote: > > An example for the duplication please check the divModInteger > > function from integer-simple GHC.Integer.Type. > > The STG (GHC 8.2.2) generated from *divModInteger* *::** Integer -> > Integer -> (# Integer, Integer #) *contains duplications in a closure > binder list. > > > > Using my custom STG printer it looks like: > > module GHC.Integer.Type where > > > > using GHC.Prim > using GHC.Tuple > using GHC.Types > > > > GHC.Integer.Type.divModInteger {-083-} = > closure (F:) (B: > n.s84123 {-s84123-} > d.s84124 {-s84124-}) { > case GHC.Integer.Type.quotRemInteger {-084-} > n.s84123 {-s84123-} > d.s84124 {-s84124-} > of qr.s84125 {-s84125-} { > GHC.Prim.(#,#) {-86-} ipv.s84126 {-s84126-} ipv1.s84127 {-s84127-} -> > let $j.s84128 {-s84128-} = > closure (F: > d.s84124 {-s84124-} > * ipv.s84126 {-s84126-}* > * ipv1.s84127 {-s84127-}* > * ipv.s84126 {-s84126-}* > *ipv1.s84127 {-s84127-}*) (B: > wild.s84129 {-s84129-}) { > let $j1.s84130 {-s84130-} = > closure (F: > d.s84124 {-s84124-} > ipv.s84126 {-s84126-} > ipv1.s84127 {-s84127-} > ipv.s84126 {-s84126-} > ipv1.s84127 {-s84127-} > wild.s84129 {-s84129-}) (B: > wild1.s84131 {-s84131-}) { > case _stg_prim_negateInt# > wild.s84129 {-s84129-} > of sat.s84132 {-s84132-} { > DEFAULT -> > case _stg_prim_==# > wild1.s84131 {-s84131-} > sat.s84132 {-s84132-} > of sat.s84133 {-s84133-} { > DEFAULT -> > case _stg_prim_tagToEnum# > sat.s84133 {-s84133-} > of wild2.s84134 {-s84134-} { > GHC.Types.False {-612-} -> > GHC.Prim.(#,#) {-86-} > ipv.s84126 {-s84126-} > ipv1.s84127 {-s84127-} > GHC.Types.True {-645-} -> > case GHC.Integer.Type.plusInteger {-066-} > ipv1.s84127 {-s84127-} > d.s84124 {-s84124-} > of r'.s84135 {-s84135-} { > DEFAULT -> > case GHC.Integer.Type.plusInteger {-066-} > ipv.s84126 {-s84126-} > GHC.Integer.Type.lvl11 {-r50574-} > of q'.s84136 {-s84136-} { > DEFAULT -> > GHC.Prim.(#,#) {-86-} > q'.s84136 {-s84136-} > r'.s84135 {-s84135-} > } > } > } > } > }} > > in case ipv1.s84127 {-s84127-} > of wild1.s84137 {-s84137-} { > GHC.Integer.Type.S# {-621-} i#.s84138 {-s84138-} -> > case _stg_prim_<# > i#.s84138 {-s84138-} 0# > of sat.s84140 {-s84140-} { > DEFAULT -> > case _stg_prim_># > i#.s84138 {-s84138-} 0# > of sat.s84139 {-s84139-} { > DEFAULT -> > case _stg_prim_-# > sat.s84139 {-s84139-} > sat.s84140 {-s84140-} > of sat.s84141 {-s84141-} { > DEFAULT -> > $j1.s84130 {-s84130-} > sat.s84141 {-s84141-} > } > } > } > GHC.Integer.Type.Jp# > > {-r5813-} dt.s84142 {-s84142-} -> > $j1.s84130 {-s84130-} 1# > GHC.Integer.Type.Jn# {-r5814-} dt.s84143 {-s84143-} -> > $j1.s84130 {-s84130-} -1# > }} > > in case d.s84124 {-s84124-} > of wild.s84144 {-s84144-} { > GHC.Integer.Type.S# {-621-} i#.s84145 {-s84145-} -> > case _stg_prim_<# > i#.s84145 {-s84145-} 0# > of sat.s84147 {-s84147-} { > DEFAULT -> > case _stg_prim_># > i#.s84145 {-s84145-} 0# > of sat.s84146 {-s84146-} { > DEFAULT -> > case _stg_prim_-# > sat.s84146 {-s84146-} > sat.s84147 {-s84147-} > of sat.s84148 {-s84148-} { > DEFAULT -> > $j.s84128 {-s84128-} > sat.s84148 {-s84148-} > } > } > } > GHC.Integer.Type.Jp# > > {-r5813-} dt.s84149 {-s84149-} -> > $j.s84128 {-s84128-} 1# > GHC.Integer.Type.Jn# {-r5814-} dt.s84150 {-s84150-} -> > $j.s84128 {-s84128-} -1# > } > }} > > > > On Mon, Nov 5, 2018 at 2:08 PM Simon Peyton Jones > wrote: > > I don’t think there should be duplicates in either. Do you have a test > case that shows duplicates? > > > > Simon > > > > *From:* ghc-devs *On Behalf Of *Csaba > Hruska > *Sent:* 04 November 2018 11:22 > *To:* ghc-devs at haskell.org > *Subject:* Re: StgRhsClosure freevar and argument name duplicates > > > > Is it possible that GHC generates STG with invalid binding semantics for > certain cases that the Cmm codegen fix or ignore? > > This could explain my observations. > > I've checked the Stg linter source (StgLint.hs ; GHC 8.2.2 and github > master) and it does not check StgRhsClosure free var and binder list at all. > > And the scope checker function (addInScopeVars) does not check for > duplicates. > > > > Any thoughts? > > > > Cheers, > > Csaba > > > > On Sat, Nov 3, 2018 at 9:53 AM Csaba Hruska > wrote: > > Hi, > > > > Can StgRhsClosure's freevar list ([occ]) or argument list ([bndr]) contain > duplicates? > > > > Cheers, > > Csaba > > > > data GenStgRhs bndr occ > = StgRhsClosure > CostCentreStack -- CCS to be attached (default is > CurrentCCS) > StgBinderInfo -- Info about how this binder is used (see > below) > *[occ]* -- non-global free vars; a list, rather > than > -- a set, because order is important > !UpdateFlag -- ReEntrant | Updatable | SingleEntry > *[bndr]* -- arguments; if empty, then not a > function; > -- as above, order is important. > (GenStgExpr bndr occ) -- body > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From csaba.hruska at gmail.com Tue Nov 6 16:10:18 2018 From: csaba.hruska at gmail.com (Csaba Hruska) Date: Tue, 6 Nov 2018 17:10:18 +0100 Subject: StgRhsClosure freevar and argument name duplicates In-Reply-To: References: Message-ID: https://ghc.haskell.org/trac/ghc/ticket/15867 On Tue, Nov 6, 2018 at 4:47 PM Csaba Hruska wrote: > Ok, I'll open a ticket. > To reproduce: > > 1. patch GHC head: *git apply StgScopeCheck.patch* > 2. make sure every compiled stg is linted: *add -dstg-lint* to GhcStage2HcOpts > GhcLibHcOpts GhcRtsHcOpts config vars > 3. compile GHC HEAD > > > On Tue, Nov 6, 2018 at 4:39 PM Simon Peyton Jones > wrote: > >> can you open a Trac ticket, and explain how to reproduce it? Does it >> require a patch, or does -ddump-stg show it? >> >> >> >> thanks >> >> >> >> Simion >> >> >> >> *From:* Csaba Hruska >> *Sent:* 06 November 2018 15:36 >> *To:* Simon Peyton Jones >> *Cc:* ghc-devs at haskell.org >> *Subject:* Re: StgRhsClosure freevar and argument name duplicates >> >> >> >> You can reproduce the error with the GHC HEAD and with the attached patch >> for StgLinter. >> >> The patch adds scope checking for the linter. >> >> I've also attached the linter's error output against GHC HEAD. >> >> Compile GHC HEAD with the following settings: >> >> GhcStage1HcOpts= >> GhcStage2HcOpts=-O2 -haddock -dstg-lint >> GhcStage3HcOpts=-O2 -haddock -dstg-lint >> >> >> >> Regards, >> >> Csaba >> >> >> >> >> >> On Tue, Nov 6, 2018 at 12:19 PM Csaba Hruska >> wrote: >> >> Correction: I've also noticed that there are two Main.main top-level >> binders in the generated STG with different uniques. >> >> >> >> On Tue, Nov 6, 2018 at 12:19 PM Csaba Hruska >> wrote: >> >> I've also noticed that there are two Main.main top-level binders in the >> generated STG with different uniques? >> >> And GHC produces a working executable. >> >> Is Main.main an exception or does top-level names have some kind of >> "should be exported" property? >> >> >> >> On Tue, Nov 6, 2018 at 12:02 PM Simon Peyton Jones >> wrote: >> >> I think top level names should be unique in occ-names; because those >> occ-names generate the symbols in the binary. >> >> >> >> Simon >> >> >> >> *From:* Csaba Hruska >> *Sent:* 06 November 2018 11:01 >> *To:* Simon Peyton Jones >> *Cc:* ghc-devs at haskell.org >> *Subject:* Re: StgRhsClosure freevar and argument name duplicates >> >> >> >> My plan is to extend GHC's STG linter to check the following properties: >> >> - uniqueness of free var and arg list of StgRhsClosure >> - top level binding name uniqueness >> >> I'll patch my local GHC 8.2.2 and GHC HEAD. I'll also attach the patch to >> the ticket. >> >> I have a question regarding top level names. >> >> Should the top-level names be unique as occ names or just in unique >> values? >> >> If not, then what is the rule? >> >> >> >> Thanks, >> >> Csaba >> >> >> >> On Tue, Nov 6, 2018 at 11:13 AM Simon Peyton Jones >> wrote: >> >> Does this happen in HEAD with GHC’s own STG printer? If so, could you >> file a Trac ticket – it’s clearly wrong. >> >> >> >> But I do wonder if it could perhaps be something to do with your branch? >> >> >> >> Thanks >> >> >> >> Simon >> >> >> >> *From:* Csaba Hruska >> *Sent:* 05 November 2018 16:33 >> *To:* Simon Peyton Jones >> *Cc:* ghc-devs at haskell.org >> *Subject:* Re: StgRhsClosure freevar and argument name duplicates >> >> >> >> Correction! >> >> The problem happens in integer-gmp: >> >> https://github.com/ghc/ghc/blob/master/libraries/integer-gmp/src/GHC/Integer/Type.hs#L761-L770 >> >> >> >> >> On Mon, Nov 5, 2018 at 5:27 PM Csaba Hruska >> wrote: >> >> An example for the duplication please check the divModInteger >> >> function from integer-simple GHC.Integer.Type. >> >> The STG (GHC 8.2.2) generated from *divModInteger* *::** Integer -> >> Integer -> (# Integer, Integer #) *contains duplications in a closure >> binder list. >> >> >> >> Using my custom STG printer it looks like: >> >> module GHC.Integer.Type where >> >> >> >> using GHC.Prim >> using GHC.Tuple >> using GHC.Types >> >> >> >> GHC.Integer.Type.divModInteger {-083-} = >> closure (F:) (B: >> n.s84123 {-s84123-} >> d.s84124 {-s84124-}) { >> case GHC.Integer.Type.quotRemInteger {-084-} >> n.s84123 {-s84123-} >> d.s84124 {-s84124-} >> of qr.s84125 {-s84125-} { >> GHC.Prim.(#,#) {-86-} ipv.s84126 {-s84126-} ipv1.s84127 {-s84127-} -> >> let $j.s84128 {-s84128-} = >> closure (F: >> d.s84124 {-s84124-} >> * ipv.s84126 {-s84126-}* >> * ipv1.s84127 {-s84127-}* >> * ipv.s84126 {-s84126-}* >> *ipv1.s84127 {-s84127-}*) (B: >> wild.s84129 {-s84129-}) { >> let $j1.s84130 {-s84130-} = >> closure (F: >> d.s84124 {-s84124-} >> ipv.s84126 {-s84126-} >> ipv1.s84127 {-s84127-} >> ipv.s84126 {-s84126-} >> ipv1.s84127 {-s84127-} >> wild.s84129 {-s84129-}) (B: >> wild1.s84131 {-s84131-}) { >> case _stg_prim_negateInt# >> wild.s84129 {-s84129-} >> of sat.s84132 {-s84132-} { >> DEFAULT -> >> case _stg_prim_==# >> wild1.s84131 {-s84131-} >> sat.s84132 {-s84132-} >> of sat.s84133 {-s84133-} { >> DEFAULT -> >> case _stg_prim_tagToEnum# >> sat.s84133 {-s84133-} >> of wild2.s84134 {-s84134-} { >> GHC.Types.False {-612-} -> >> GHC.Prim.(#,#) {-86-} >> ipv.s84126 {-s84126-} >> ipv1.s84127 {-s84127-} >> GHC.Types.True {-645-} -> >> case GHC.Integer.Type.plusInteger {-066-} >> ipv1.s84127 {-s84127-} >> d.s84124 {-s84124-} >> of r'.s84135 {-s84135-} { >> DEFAULT -> >> case GHC.Integer.Type.plusInteger >> {-066-} >> ipv.s84126 {-s84126-} >> GHC.Integer.Type.lvl11 {-r50574-} >> of q'.s84136 {-s84136-} { >> DEFAULT -> >> GHC.Prim.(#,#) {-86-} >> q'.s84136 {-s84136-} >> r'.s84135 {-s84135-} >> } >> } >> } >> } >> }} >> >> in case ipv1.s84127 {-s84127-} >> of wild1.s84137 {-s84137-} { >> GHC.Integer.Type.S# {-621-} i#.s84138 {-s84138-} -> >> case _stg_prim_<# >> i#.s84138 {-s84138-} 0# >> of sat.s84140 {-s84140-} { >> DEFAULT -> >> case _stg_prim_># >> i#.s84138 {-s84138-} 0# >> of sat.s84139 {-s84139-} { >> DEFAULT -> >> case _stg_prim_-# >> sat.s84139 {-s84139-} >> sat.s84140 {-s84140-} >> of sat.s84141 {-s84141-} { >> DEFAULT -> >> $j1.s84130 {-s84130-} >> sat.s84141 {-s84141-} >> } >> } >> } >> GHC.Integer.Type.Jp# >> >> {-r5813-} dt.s84142 {-s84142-} -> >> $j1.s84130 {-s84130-} 1# >> GHC.Integer.Type.Jn# {-r5814-} dt.s84143 {-s84143-} -> >> $j1.s84130 {-s84130-} -1# >> }} >> >> in case d.s84124 {-s84124-} >> of wild.s84144 {-s84144-} { >> GHC.Integer.Type.S# {-621-} i#.s84145 {-s84145-} -> >> case _stg_prim_<# >> i#.s84145 {-s84145-} 0# >> of sat.s84147 {-s84147-} { >> DEFAULT -> >> case _stg_prim_># >> i#.s84145 {-s84145-} 0# >> of sat.s84146 {-s84146-} { >> DEFAULT -> >> case _stg_prim_-# >> sat.s84146 {-s84146-} >> sat.s84147 {-s84147-} >> of sat.s84148 {-s84148-} { >> DEFAULT -> >> $j.s84128 {-s84128-} >> sat.s84148 {-s84148-} >> } >> } >> } >> GHC.Integer.Type.Jp# >> >> {-r5813-} dt.s84149 {-s84149-} -> >> $j.s84128 {-s84128-} 1# >> GHC.Integer.Type.Jn# {-r5814-} dt.s84150 {-s84150-} -> >> $j.s84128 {-s84128-} -1# >> } >> }} >> >> >> >> On Mon, Nov 5, 2018 at 2:08 PM Simon Peyton Jones >> wrote: >> >> I don’t think there should be duplicates in either. Do you have a test >> case that shows duplicates? >> >> >> >> Simon >> >> >> >> *From:* ghc-devs *On Behalf Of *Csaba >> Hruska >> *Sent:* 04 November 2018 11:22 >> *To:* ghc-devs at haskell.org >> *Subject:* Re: StgRhsClosure freevar and argument name duplicates >> >> >> >> Is it possible that GHC generates STG with invalid binding semantics for >> certain cases that the Cmm codegen fix or ignore? >> >> This could explain my observations. >> >> I've checked the Stg linter source (StgLint.hs ; GHC 8.2.2 and github >> master) and it does not check StgRhsClosure free var and binder list at all. >> >> And the scope checker function (addInScopeVars) does not check for >> duplicates. >> >> >> >> Any thoughts? >> >> >> >> Cheers, >> >> Csaba >> >> >> >> On Sat, Nov 3, 2018 at 9:53 AM Csaba Hruska >> wrote: >> >> Hi, >> >> >> >> Can StgRhsClosure's freevar list ([occ]) or argument list ([bndr]) >> contain duplicates? >> >> >> >> Cheers, >> >> Csaba >> >> >> >> data GenStgRhs bndr occ >> = StgRhsClosure >> CostCentreStack -- CCS to be attached (default is >> CurrentCCS) >> StgBinderInfo -- Info about how this binder is used >> (see below) >> *[occ]* -- non-global free vars; a list, >> rather than >> -- a set, because order is important >> !UpdateFlag -- ReEntrant | Updatable | SingleEntry >> *[bndr]* -- arguments; if empty, then not a >> function; >> -- as above, order is important. >> (GenStgExpr bndr occ) -- body >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From csaba.hruska at gmail.com Tue Nov 6 18:30:22 2018 From: csaba.hruska at gmail.com (Csaba Hruska) Date: Tue, 6 Nov 2018 19:30:22 +0100 Subject: StgRhsClosure freevar and argument name duplicates In-Reply-To: References: Message-ID: I have a question. Do unique names have SSA semantic in STG? Can multiple (StgRec/StgNonRec) binding id have the same unique value? On Tue, Nov 6, 2018 at 5:10 PM Csaba Hruska wrote: > https://ghc.haskell.org/trac/ghc/ticket/15867 > > On Tue, Nov 6, 2018 at 4:47 PM Csaba Hruska > wrote: > >> Ok, I'll open a ticket. >> To reproduce: >> >> 1. patch GHC head: *git apply StgScopeCheck.patch* >> 2. make sure every compiled stg is linted: *add -dstg-lint* to GhcStage2HcOpts >> GhcLibHcOpts GhcRtsHcOpts config vars >> 3. compile GHC HEAD >> >> >> On Tue, Nov 6, 2018 at 4:39 PM Simon Peyton Jones >> wrote: >> >>> can you open a Trac ticket, and explain how to reproduce it? Does it >>> require a patch, or does -ddump-stg show it? >>> >>> >>> >>> thanks >>> >>> >>> >>> Simion >>> >>> >>> >>> *From:* Csaba Hruska >>> *Sent:* 06 November 2018 15:36 >>> *To:* Simon Peyton Jones >>> *Cc:* ghc-devs at haskell.org >>> *Subject:* Re: StgRhsClosure freevar and argument name duplicates >>> >>> >>> >>> You can reproduce the error with the GHC HEAD and with the attached >>> patch for StgLinter. >>> >>> The patch adds scope checking for the linter. >>> >>> I've also attached the linter's error output against GHC HEAD. >>> >>> Compile GHC HEAD with the following settings: >>> >>> GhcStage1HcOpts= >>> GhcStage2HcOpts=-O2 -haddock -dstg-lint >>> GhcStage3HcOpts=-O2 -haddock -dstg-lint >>> >>> >>> >>> Regards, >>> >>> Csaba >>> >>> >>> >>> >>> >>> On Tue, Nov 6, 2018 at 12:19 PM Csaba Hruska >>> wrote: >>> >>> Correction: I've also noticed that there are two Main.main top-level >>> binders in the generated STG with different uniques. >>> >>> >>> >>> On Tue, Nov 6, 2018 at 12:19 PM Csaba Hruska >>> wrote: >>> >>> I've also noticed that there are two Main.main top-level binders in the >>> generated STG with different uniques? >>> >>> And GHC produces a working executable. >>> >>> Is Main.main an exception or does top-level names have some kind of >>> "should be exported" property? >>> >>> >>> >>> On Tue, Nov 6, 2018 at 12:02 PM Simon Peyton Jones < >>> simonpj at microsoft.com> wrote: >>> >>> I think top level names should be unique in occ-names; because those >>> occ-names generate the symbols in the binary. >>> >>> >>> >>> Simon >>> >>> >>> >>> *From:* Csaba Hruska >>> *Sent:* 06 November 2018 11:01 >>> *To:* Simon Peyton Jones >>> *Cc:* ghc-devs at haskell.org >>> *Subject:* Re: StgRhsClosure freevar and argument name duplicates >>> >>> >>> >>> My plan is to extend GHC's STG linter to check the following properties: >>> >>> - uniqueness of free var and arg list of StgRhsClosure >>> - top level binding name uniqueness >>> >>> I'll patch my local GHC 8.2.2 and GHC HEAD. I'll also attach the patch >>> to the ticket. >>> >>> I have a question regarding top level names. >>> >>> Should the top-level names be unique as occ names or just in unique >>> values? >>> >>> If not, then what is the rule? >>> >>> >>> >>> Thanks, >>> >>> Csaba >>> >>> >>> >>> On Tue, Nov 6, 2018 at 11:13 AM Simon Peyton Jones < >>> simonpj at microsoft.com> wrote: >>> >>> Does this happen in HEAD with GHC’s own STG printer? If so, could you >>> file a Trac ticket – it’s clearly wrong. >>> >>> >>> >>> But I do wonder if it could perhaps be something to do with your branch? >>> >>> >>> >>> Thanks >>> >>> >>> >>> Simon >>> >>> >>> >>> *From:* Csaba Hruska >>> *Sent:* 05 November 2018 16:33 >>> *To:* Simon Peyton Jones >>> *Cc:* ghc-devs at haskell.org >>> *Subject:* Re: StgRhsClosure freevar and argument name duplicates >>> >>> >>> >>> Correction! >>> >>> The problem happens in integer-gmp: >>> >>> https://github.com/ghc/ghc/blob/master/libraries/integer-gmp/src/GHC/Integer/Type.hs#L761-L770 >>> >>> >>> >>> >>> On Mon, Nov 5, 2018 at 5:27 PM Csaba Hruska >>> wrote: >>> >>> An example for the duplication please check the divModInteger >>> >>> function from integer-simple GHC.Integer.Type. >>> >>> The STG (GHC 8.2.2) generated from *divModInteger* *::** Integer -> >>> Integer -> (# Integer, Integer #) *contains duplications in a closure >>> binder list. >>> >>> >>> >>> Using my custom STG printer it looks like: >>> >>> module GHC.Integer.Type where >>> >>> >>> >>> using GHC.Prim >>> using GHC.Tuple >>> using GHC.Types >>> >>> >>> >>> GHC.Integer.Type.divModInteger {-083-} = >>> closure (F:) (B: >>> n.s84123 {-s84123-} >>> d.s84124 {-s84124-}) { >>> case GHC.Integer.Type.quotRemInteger {-084-} >>> n.s84123 {-s84123-} >>> d.s84124 {-s84124-} >>> of qr.s84125 {-s84125-} { >>> GHC.Prim.(#,#) {-86-} ipv.s84126 {-s84126-} ipv1.s84127 {-s84127-} -> >>> let $j.s84128 {-s84128-} = >>> closure (F: >>> d.s84124 {-s84124-} >>> * ipv.s84126 {-s84126-}* >>> * ipv1.s84127 {-s84127-}* >>> * ipv.s84126 {-s84126-}* >>> *ipv1.s84127 {-s84127-}*) (B: >>> wild.s84129 {-s84129-}) { >>> let $j1.s84130 {-s84130-} = >>> closure (F: >>> d.s84124 {-s84124-} >>> ipv.s84126 {-s84126-} >>> ipv1.s84127 {-s84127-} >>> ipv.s84126 {-s84126-} >>> ipv1.s84127 {-s84127-} >>> wild.s84129 {-s84129-}) (B: >>> wild1.s84131 {-s84131-}) { >>> case _stg_prim_negateInt# >>> wild.s84129 {-s84129-} >>> of sat.s84132 {-s84132-} { >>> DEFAULT -> >>> case _stg_prim_==# >>> wild1.s84131 {-s84131-} >>> sat.s84132 {-s84132-} >>> of sat.s84133 {-s84133-} { >>> DEFAULT -> >>> case _stg_prim_tagToEnum# >>> sat.s84133 {-s84133-} >>> of wild2.s84134 {-s84134-} { >>> GHC.Types.False {-612-} -> >>> GHC.Prim.(#,#) {-86-} >>> ipv.s84126 {-s84126-} >>> ipv1.s84127 {-s84127-} >>> GHC.Types.True {-645-} -> >>> case GHC.Integer.Type.plusInteger {-066-} >>> ipv1.s84127 {-s84127-} >>> d.s84124 {-s84124-} >>> of r'.s84135 {-s84135-} { >>> DEFAULT -> >>> case GHC.Integer.Type.plusInteger >>> {-066-} >>> ipv.s84126 {-s84126-} >>> GHC.Integer.Type.lvl11 >>> {-r50574-} >>> of q'.s84136 {-s84136-} { >>> DEFAULT -> >>> GHC.Prim.(#,#) {-86-} >>> q'.s84136 {-s84136-} >>> r'.s84135 {-s84135-} >>> } >>> } >>> } >>> } >>> }} >>> >>> in case ipv1.s84127 {-s84127-} >>> of wild1.s84137 {-s84137-} { >>> GHC.Integer.Type.S# {-621-} i#.s84138 {-s84138-} -> >>> case _stg_prim_<# >>> i#.s84138 {-s84138-} 0# >>> of sat.s84140 {-s84140-} { >>> DEFAULT -> >>> case _stg_prim_># >>> i#.s84138 {-s84138-} 0# >>> of sat.s84139 {-s84139-} { >>> DEFAULT -> >>> case _stg_prim_-# >>> sat.s84139 {-s84139-} >>> sat.s84140 {-s84140-} >>> of sat.s84141 {-s84141-} { >>> DEFAULT -> >>> $j1.s84130 {-s84130-} >>> sat.s84141 {-s84141-} >>> } >>> } >>> } >>> GHC.Integer.Type.Jp# >>> >>> {-r5813-} dt.s84142 {-s84142-} -> >>> $j1.s84130 {-s84130-} 1# >>> GHC.Integer.Type.Jn# {-r5814-} dt.s84143 {-s84143-} -> >>> $j1.s84130 {-s84130-} -1# >>> }} >>> >>> in case d.s84124 {-s84124-} >>> of wild.s84144 {-s84144-} { >>> GHC.Integer.Type.S# {-621-} i#.s84145 {-s84145-} -> >>> case _stg_prim_<# >>> i#.s84145 {-s84145-} 0# >>> of sat.s84147 {-s84147-} { >>> DEFAULT -> >>> case _stg_prim_># >>> i#.s84145 {-s84145-} 0# >>> of sat.s84146 {-s84146-} { >>> DEFAULT -> >>> case _stg_prim_-# >>> sat.s84146 {-s84146-} >>> sat.s84147 {-s84147-} >>> of sat.s84148 {-s84148-} { >>> DEFAULT -> >>> $j.s84128 {-s84128-} >>> sat.s84148 {-s84148-} >>> } >>> } >>> } >>> GHC.Integer.Type.Jp# >>> >>> {-r5813-} dt.s84149 {-s84149-} -> >>> $j.s84128 {-s84128-} 1# >>> GHC.Integer.Type.Jn# {-r5814-} dt.s84150 {-s84150-} -> >>> $j.s84128 {-s84128-} -1# >>> } >>> }} >>> >>> >>> >>> On Mon, Nov 5, 2018 at 2:08 PM Simon Peyton Jones >>> wrote: >>> >>> I don’t think there should be duplicates in either. Do you have a test >>> case that shows duplicates? >>> >>> >>> >>> Simon >>> >>> >>> >>> *From:* ghc-devs *On Behalf Of *Csaba >>> Hruska >>> *Sent:* 04 November 2018 11:22 >>> *To:* ghc-devs at haskell.org >>> *Subject:* Re: StgRhsClosure freevar and argument name duplicates >>> >>> >>> >>> Is it possible that GHC generates STG with invalid binding semantics for >>> certain cases that the Cmm codegen fix or ignore? >>> >>> This could explain my observations. >>> >>> I've checked the Stg linter source (StgLint.hs ; GHC 8.2.2 and github >>> master) and it does not check StgRhsClosure free var and binder list at all. >>> >>> And the scope checker function (addInScopeVars) does not check for >>> duplicates. >>> >>> >>> >>> Any thoughts? >>> >>> >>> >>> Cheers, >>> >>> Csaba >>> >>> >>> >>> On Sat, Nov 3, 2018 at 9:53 AM Csaba Hruska >>> wrote: >>> >>> Hi, >>> >>> >>> >>> Can StgRhsClosure's freevar list ([occ]) or argument list ([bndr]) >>> contain duplicates? >>> >>> >>> >>> Cheers, >>> >>> Csaba >>> >>> >>> >>> data GenStgRhs bndr occ >>> = StgRhsClosure >>> CostCentreStack -- CCS to be attached (default is >>> CurrentCCS) >>> StgBinderInfo -- Info about how this binder is used >>> (see below) >>> *[occ]* -- non-global free vars; a list, >>> rather than >>> -- a set, because order is important >>> !UpdateFlag -- ReEntrant | Updatable | SingleEntry >>> *[bndr]* -- arguments; if empty, then not a >>> function; >>> -- as above, order is important. >>> (GenStgExpr bndr occ) -- body >>> >>> >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at cs.brynmawr.edu Wed Nov 7 22:33:37 2018 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Wed, 7 Nov 2018 17:33:37 -0500 Subject: slow execution of built executables on a Mac In-Reply-To: References: Message-ID: Sadly, none of the suggestions on this thread worked. But here is some more detail: - During stage-1, my machine's CPU is maxed out (or nearly so) in user mode. - After stage-1 (most obviously during rts_dist_HC), my machine spends roughly 80% of its CPU in *system* mode. - Testing on my other machine (which is slower, but much faster at building GHC), I never see high *system* percentages. - Both machines use APFS, which was one candidate for the slowdown. - The slow machine uses XCode 10.1; the fast one uses XCode 9.4.1 - The slow machine uses clang 10.0.0; the fast one uses clang 9.1.0 - `brew install gmp` on the slow machine tells me that gmp is already installed. - As a reminder: the slow machine is macOS 10.13.6; the fast one is macOS 10.13.5. I don't wish to try upgrading the fast one... lest that slow it down! Does anyone have any insight? Thanks! Richard > On Oct 30, 2018, at 2:32 PM, Gabor Greif wrote: > > Maybe a symptom of an AFPS bug? > https://gregoryszorc.com/blog/2018/10/29/global-kernel-locks-in-apfs/ > > Just came across this, might be worth a look. > > Cheers, > > Gabor > > On 10/26/18, Richard Eisenberg wrote: >> Hi devs, >> >> I have a shiny, new iMac in my office. It's thus frustrating that it takes >> my iMac longer to build GHC than my trusty 28-month-old laptop. Building >> devel2 on a fresh checkout takes just about an hour. By contrast, my laptop >> is done after 30 minutes of work (same build settings). The laptop has a >> 2.8GHz Intel i7 running macOS 10.13.5; the desktop has a 3.5GHz Intel i5 >> running macOS 10.13.6. Both bootstrapped from the binary distro of GHC >> 8.6.1. >> >> Watching GHC build, everything is snappy enough during the stage-1 build. >> But then, as soon as we start using GHC-produced executables, things slow >> down. It's most noticeable in the rts_dist_HC phase, which crawls. Stage 2 >> is pretty slow, too. >> >> So: is there anything anyone knows about recent Macs not liking locally >> built executables? Or is there some local setting that I need to update? The >> prepackaged GHC seems to work well, so that gives me hope that someone knows >> what setting to tweak. >> >> Thanks! >> Richard >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> From simonpj at microsoft.com Wed Nov 7 23:06:25 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Wed, 7 Nov 2018 23:06:25 +0000 Subject: StgRhsClosure freevar and argument name duplicates In-Reply-To: References: Message-ID: Do unique names have SSA semantic in STG? I’m not sure what you mean. STG just obeys normal lexical scoping. Can multiple (StgRec/StgNonRec) binding id have the same unique value? No: the uniques are used during code generation to general labels that should be globally unique. At least I think this is so. Simon From: Csaba Hruska Sent: 06 November 2018 18:30 To: Simon Peyton Jones Cc: ghc-devs at haskell.org Subject: Re: StgRhsClosure freevar and argument name duplicates I have a question. Do unique names have SSA semantic in STG? Can multiple (StgRec/StgNonRec) binding id have the same unique value? On Tue, Nov 6, 2018 at 5:10 PM Csaba Hruska > wrote: https://ghc.haskell.org/trac/ghc/ticket/15867 On Tue, Nov 6, 2018 at 4:47 PM Csaba Hruska > wrote: Ok, I'll open a ticket. To reproduce: 1. patch GHC head: git apply StgScopeCheck.patch 2. make sure every compiled stg is linted: add -dstg-lint to GhcStage2HcOpts GhcLibHcOpts GhcRtsHcOpts config vars 3. compile GHC HEAD On Tue, Nov 6, 2018 at 4:39 PM Simon Peyton Jones > wrote: can you open a Trac ticket, and explain how to reproduce it? Does it require a patch, or does -ddump-stg show it? thanks Simion From: Csaba Hruska > Sent: 06 November 2018 15:36 To: Simon Peyton Jones > Cc: ghc-devs at haskell.org Subject: Re: StgRhsClosure freevar and argument name duplicates You can reproduce the error with the GHC HEAD and with the attached patch for StgLinter. The patch adds scope checking for the linter. I've also attached the linter's error output against GHC HEAD. Compile GHC HEAD with the following settings: GhcStage1HcOpts= GhcStage2HcOpts=-O2 -haddock -dstg-lint GhcStage3HcOpts=-O2 -haddock -dstg-lint Regards, Csaba On Tue, Nov 6, 2018 at 12:19 PM Csaba Hruska > wrote: Correction: I've also noticed that there are two Main.main top-level binders in the generated STG with different uniques. On Tue, Nov 6, 2018 at 12:19 PM Csaba Hruska > wrote: I've also noticed that there are two Main.main top-level binders in the generated STG with different uniques? And GHC produces a working executable. Is Main.main an exception or does top-level names have some kind of "should be exported" property? On Tue, Nov 6, 2018 at 12:02 PM Simon Peyton Jones > wrote: I think top level names should be unique in occ-names; because those occ-names generate the symbols in the binary. Simon From: Csaba Hruska > Sent: 06 November 2018 11:01 To: Simon Peyton Jones > Cc: ghc-devs at haskell.org Subject: Re: StgRhsClosure freevar and argument name duplicates My plan is to extend GHC's STG linter to check the following properties: * uniqueness of free var and arg list of StgRhsClosure * top level binding name uniqueness I'll patch my local GHC 8.2.2 and GHC HEAD. I'll also attach the patch to the ticket. I have a question regarding top level names. Should the top-level names be unique as occ names or just in unique values? If not, then what is the rule? Thanks, Csaba On Tue, Nov 6, 2018 at 11:13 AM Simon Peyton Jones > wrote: Does this happen in HEAD with GHC’s own STG printer? If so, could you file a Trac ticket – it’s clearly wrong. But I do wonder if it could perhaps be something to do with your branch? Thanks Simon From: Csaba Hruska > Sent: 05 November 2018 16:33 To: Simon Peyton Jones > Cc: ghc-devs at haskell.org Subject: Re: StgRhsClosure freevar and argument name duplicates Correction! The problem happens in integer-gmp: https://github.com/ghc/ghc/blob/master/libraries/integer-gmp/src/GHC/Integer/Type.hs#L761-L770 On Mon, Nov 5, 2018 at 5:27 PM Csaba Hruska > wrote: An example for the duplication please check the divModInteger function from integer-simple GHC.Integer.Type. The STG (GHC 8.2.2) generated from divModInteger :: Integer -> Integer -> (# Integer, Integer #) contains duplications in a closure binder list. Using my custom STG printer it looks like: module GHC.Integer.Type where using GHC.Prim using GHC.Tuple using GHC.Types GHC.Integer.Type.divModInteger {-083-} = closure (F:) (B: n.s84123 {-s84123-} d.s84124 {-s84124-}) { case GHC.Integer.Type.quotRemInteger {-084-} n.s84123 {-s84123-} d.s84124 {-s84124-} of qr.s84125 {-s84125-} { GHC.Prim.(#,#) {-86-} ipv.s84126 {-s84126-} ipv1.s84127 {-s84127-} -> let $j.s84128 {-s84128-} = closure (F: d.s84124 {-s84124-} ipv.s84126 {-s84126-} ipv1.s84127 {-s84127-} ipv.s84126 {-s84126-} ipv1.s84127 {-s84127-}) (B: wild.s84129 {-s84129-}) { let $j1.s84130 {-s84130-} = closure (F: d.s84124 {-s84124-} ipv.s84126 {-s84126-} ipv1.s84127 {-s84127-} ipv.s84126 {-s84126-} ipv1.s84127 {-s84127-} wild.s84129 {-s84129-}) (B: wild1.s84131 {-s84131-}) { case _stg_prim_negateInt# wild.s84129 {-s84129-} of sat.s84132 {-s84132-} { DEFAULT -> case _stg_prim_==# wild1.s84131 {-s84131-} sat.s84132 {-s84132-} of sat.s84133 {-s84133-} { DEFAULT -> case _stg_prim_tagToEnum# sat.s84133 {-s84133-} of wild2.s84134 {-s84134-} { GHC.Types.False {-612-} -> GHC.Prim.(#,#) {-86-} ipv.s84126 {-s84126-} ipv1.s84127 {-s84127-} GHC.Types.True {-645-} -> case GHC.Integer.Type.plusInteger {-066-} ipv1.s84127 {-s84127-} d.s84124 {-s84124-} of r'.s84135 {-s84135-} { DEFAULT -> case GHC.Integer.Type.plusInteger {-066-} ipv.s84126 {-s84126-} GHC.Integer.Type.lvl11 {-r50574-} of q'.s84136 {-s84136-} { DEFAULT -> GHC.Prim.(#,#) {-86-} q'.s84136 {-s84136-} r'.s84135 {-s84135-} } } } } }} in case ipv1.s84127 {-s84127-} of wild1.s84137 {-s84137-} { GHC.Integer.Type.S# {-621-} i#.s84138 {-s84138-} -> case _stg_prim_<# i#.s84138 {-s84138-} 0# of sat.s84140 {-s84140-} { DEFAULT -> case _stg_prim_># i#.s84138 {-s84138-} 0# of sat.s84139 {-s84139-} { DEFAULT -> case _stg_prim_-# sat.s84139 {-s84139-} sat.s84140 {-s84140-} of sat.s84141 {-s84141-} { DEFAULT -> $j1.s84130 {-s84130-} sat.s84141 {-s84141-} } } } GHC.Integer.Type.Jp# {-r5813-} dt.s84142 {-s84142-} -> $j1.s84130 {-s84130-} 1# GHC.Integer.Type.Jn# {-r5814-} dt.s84143 {-s84143-} -> $j1.s84130 {-s84130-} -1# }} in case d.s84124 {-s84124-} of wild.s84144 {-s84144-} { GHC.Integer.Type.S# {-621-} i#.s84145 {-s84145-} -> case _stg_prim_<# i#.s84145 {-s84145-} 0# of sat.s84147 {-s84147-} { DEFAULT -> case _stg_prim_># i#.s84145 {-s84145-} 0# of sat.s84146 {-s84146-} { DEFAULT -> case _stg_prim_-# sat.s84146 {-s84146-} sat.s84147 {-s84147-} of sat.s84148 {-s84148-} { DEFAULT -> $j.s84128 {-s84128-} sat.s84148 {-s84148-} } } } GHC.Integer.Type.Jp# {-r5813-} dt.s84149 {-s84149-} -> $j.s84128 {-s84128-} 1# GHC.Integer.Type.Jn# {-r5814-} dt.s84150 {-s84150-} -> $j.s84128 {-s84128-} -1# } }} On Mon, Nov 5, 2018 at 2:08 PM Simon Peyton Jones > wrote: I don’t think there should be duplicates in either. Do you have a test case that shows duplicates? Simon From: ghc-devs > On Behalf Of Csaba Hruska Sent: 04 November 2018 11:22 To: ghc-devs at haskell.org Subject: Re: StgRhsClosure freevar and argument name duplicates Is it possible that GHC generates STG with invalid binding semantics for certain cases that the Cmm codegen fix or ignore? This could explain my observations. I've checked the Stg linter source (StgLint.hs ; GHC 8.2.2 and github master) and it does not check StgRhsClosure free var and binder list at all. And the scope checker function (addInScopeVars) does not check for duplicates. Any thoughts? Cheers, Csaba On Sat, Nov 3, 2018 at 9:53 AM Csaba Hruska > wrote: Hi, Can StgRhsClosure's freevar list ([occ]) or argument list ([bndr]) contain duplicates? Cheers, Csaba data GenStgRhs bndr occ = StgRhsClosure CostCentreStack -- CCS to be attached (default is CurrentCCS) StgBinderInfo -- Info about how this binder is used (see below) [occ] -- non-global free vars; a list, rather than -- a set, because order is important !UpdateFlag -- ReEntrant | Updatable | SingleEntry [bndr] -- arguments; if empty, then not a function; -- as above, order is important. (GenStgExpr bndr occ) -- body -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Wed Nov 7 23:09:44 2018 From: ben at well-typed.com (Ben Gamari) Date: Wed, 07 Nov 2018 18:09:44 -0500 Subject: slow execution of built executables on a Mac In-Reply-To: References: Message-ID: <87wopolc25.fsf@smart-cactus.org> Richard Eisenberg writes: > Sadly, none of the suggestions on this thread worked. > > But here is some more detail: > > - During stage-1, my machine's CPU is maxed out (or nearly so) in user mode. > - After stage-1 (most obviously during rts_dist_HC), my machine spends roughly 80% of its CPU in *system* mode. > - Testing on my other machine (which is slower, but much faster at building GHC), I never see high *system* percentages. > - Both machines use APFS, which was one candidate for the slowdown. > - The slow machine uses XCode 10.1; the fast one uses XCode 9.4.1 > - The slow machine uses clang 10.0.0; the fast one uses clang 9.1.0 > - `brew install gmp` on the slow machine tells me that gmp is already installed. > - As a reminder: the slow machine is macOS 10.13.6; the fast one is macOS 10.13.5. I don't wish to try upgrading the fast one... lest that slow it down! > > Does anyone have any insight? > Were you able to collect a few stacks from the slow processes? It sounds like the author of the original post was somehow able to do this. Under Linux I would just fire up perf and grab a system-wide profile. Knowing precisely what slow path you are hitting would help localize any possible problem in GHC. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From george.colpitts at gmail.com Wed Nov 7 23:23:51 2018 From: george.colpitts at gmail.com (George Colpitts) Date: Wed, 7 Nov 2018 19:23:51 -0400 Subject: slow execution of built executables on a Mac In-Reply-To: <87wopolc25.fsf@smart-cactus.org> References: <87wopolc25.fsf@smart-cactus.org> Message-ID: Ben, yeah, good point, probabilistically speaking, a few stack traces are often all you need to pinpoint an egregious performance problem, at least that's been my experience. Richard, as you probably know, you can get stack traces by using the Activity Monitor, select a ghc process and choose sample process from the drop down of the gear icon on the left hand side of the top of the activity monitor. It also shows cpu times which may be helpful. On Wed, Nov 7, 2018 at 7:10 PM Ben Gamari wrote: > Richard Eisenberg writes: > > > Sadly, none of the suggestions on this thread worked. > > > > But here is some more detail: > > > > - During stage-1, my machine's CPU is maxed out (or nearly so) in user > mode. > > - After stage-1 (most obviously during rts_dist_HC), my machine spends > roughly 80% of its CPU in *system* mode. > > - Testing on my other machine (which is slower, but much faster at > building GHC), I never see high *system* percentages. > > - Both machines use APFS, which was one candidate for the slowdown. > > - The slow machine uses XCode 10.1; the fast one uses XCode 9.4.1 > > - The slow machine uses clang 10.0.0; the fast one uses clang 9.1.0 > > - `brew install gmp` on the slow machine tells me that gmp is already > installed. > > - As a reminder: the slow machine is macOS 10.13.6; the fast one is > macOS 10.13.5. I don't wish to try upgrading the fast one... lest that slow > it down! > > > > Does anyone have any insight? > > > Were you able to collect a few stacks from the slow processes? It sounds > like the author of the original post was somehow able to do this. Under > Linux I would just fire up perf and grab a system-wide profile. Knowing > precisely what slow path you are hitting would help localize any > possible problem in GHC. > > Cheers, > > - Ben > _______________________________________________ > 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 carter.schonwald at gmail.com Fri Nov 9 18:06:39 2018 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Fri, 9 Nov 2018 13:06:39 -0500 Subject: trac ticket about missing in tree gmp on newest mac ghc builds Message-ID: hey Ben, HVR https://ghc.haskell.org/trac/ghc/ticket/15769 seems to indicate there was quite a serious faux pas in the mac builds, do you folk need help? -Carter -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at cs.brynmawr.edu Fri Nov 9 20:03:15 2018 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Fri, 9 Nov 2018 15:03:15 -0500 Subject: slow execution of built executables on a Mac In-Reply-To: References: <87wopolc25.fsf@smart-cactus.org> Message-ID: OK. Well, I couldn't sample from Activity Monitor, because the processes came and went too quickly. But the terminal command `sample` takes a *name* as an argument, and so passing ghc-stage1 worked nicely. Samples were taken during rts_dist_HC calls. Here's the first bit: Call graph: 880 Thread_2569398 DispatchQueue_1: com.apple.main-thread (serial) + 868 _pthread_cond_wait (in libsystem_pthread.dylib) + 732 [0x7fff51e2e589] + ! 868 __psynch_cvwait (in libsystem_kernel.dylib) + 10 [0x7fff51c65a16] + 11 exitTicker (in ghc-stage1) + 80 [0x106ad2c30] + ! 11 _pthread_join (in libsystem_pthread.dylib) + 626 [0x7fff51e31824] + ! 11 __semwait_signal (in libsystem_kernel.dylib) + 10 [0x7fff51c65d82] + 1 osDecommitMemory (in ghc-stage1) + 20 [0x106ad2fc4] + 1 madvise (in libsystem_kernel.dylib) + 10 [0x7fff51c66d0a] 880 Thread_2569402 + 880 thread_start (in libsystem_pthread.dylib) + 13 [0x7fff51e2cbf9] + 880 _pthread_start (in libsystem_pthread.dylib) + 377 [0x7fff51e2d50d] I also sampled gcc. Full output at https://gist.github.com/goldfirere/7316920ad37d776c25c15dbb0ed5996f I'm utterly lost here, but the results suggest that the scheduler is at fault, somehow. Does anyone have a next step to suggest? Thanks, Richard > On Nov 7, 2018, at 6:23 PM, George Colpitts wrote: > > Ben, yeah, good point, probabilistically speaking, a few stack traces are often all you need to pinpoint an egregious performance problem, at least that's been my experience. > > Richard, as you probably know, you can get stack traces by using the Activity Monitor, select a ghc process and choose sample process from the drop down of the gear icon on the left hand side of the top of the activity monitor. It also shows cpu times which may be helpful. > > On Wed, Nov 7, 2018 at 7:10 PM Ben Gamari > wrote: > Richard Eisenberg > writes: > > > Sadly, none of the suggestions on this thread worked. > > > > But here is some more detail: > > > > - During stage-1, my machine's CPU is maxed out (or nearly so) in user mode. > > - After stage-1 (most obviously during rts_dist_HC), my machine spends roughly 80% of its CPU in *system* mode. > > - Testing on my other machine (which is slower, but much faster at building GHC), I never see high *system* percentages. > > - Both machines use APFS, which was one candidate for the slowdown. > > - The slow machine uses XCode 10.1; the fast one uses XCode 9.4.1 > > - The slow machine uses clang 10.0.0; the fast one uses clang 9.1.0 > > - `brew install gmp` on the slow machine tells me that gmp is already installed. > > - As a reminder: the slow machine is macOS 10.13.6; the fast one is macOS 10.13.5. I don't wish to try upgrading the fast one... lest that slow it down! > > > > Does anyone have any insight? > > > Were you able to collect a few stacks from the slow processes? It sounds > like the author of the original post was somehow able to do this. Under > Linux I would just fire up perf and grab a system-wide profile. Knowing > precisely what slow path you are hitting would help localize any > possible problem in GHC. > > Cheers, > > - Ben > _______________________________________________ > 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 sh.najd at gmail.com Sat Nov 10 01:37:25 2018 From: sh.najd at gmail.com (Shayan Najd) Date: Sat, 10 Nov 2018 02:37:25 +0100 Subject: Suppressing False Incomplete Pattern Matching Warnings for Polymorphic Pattern Synonyms In-Reply-To: <574c5795-97cb-481a-6c1e-44f06b55fc87@haskus.fr> References: <7031558E-BDD9-4571-A5C3-CFF486455BEA@cs.brynmawr.edu> <46855143-c211-92d8-5106-6ea0ae972b68@haskus.fr> <574c5795-97cb-481a-6c1e-44f06b55fc87@haskus.fr> Message-ID: I also realised the COMPLETE pragmas are even less helpful (at least for my case mentioned above) as they cannot be used when orphaned. For example, I tried to follow the partial solution of introducing multiple COMPLETE pragmas, one per a concrete instance of `HasSrcSpan`. I defined the pattern synonym `LL` in `basicTypes/SrcLoc.hs` and wanted to naturally define a COMPLETE pragma for when `LL` is used for `Pat` in `hsSyn/HsPat.hs`. I got an error complaining about orphaned COMPLETE pragmas. The only unacceptable way (that I can see) that makes it work is to have a module defining `LL`, importing all the instances of `HasSrcSpan`, and all the COMPLETE pragmas (one per instance). I have made a ticket about the original concern here: https://ghc.haskell.org/trac/ghc/ticket/15885 Until we come up with a good and general solution to this ticket, do you know of a hack to suppress the false incomplete pattern matching warnings in GHC? Should we add clauses like `foo _ = panic "Impossible! How did you manage to bypass a complete matching?"`? /Shayan On Mon, 29 Oct 2018 at 14:52, Sylvain Henry wrote: > > I've just found this related ticket: https://ghc.haskell.org/trac/ghc/ticket/14422 > > > On 10/26/18 7:04 PM, Richard Eisenberg wrote: > > Aha. So you're viewing complete sets as a type-directed property, where we can take a type and look up what complete sets of patterns of that type might be. > > Then, when checking a pattern-match for completeness, we use the inferred type of the pattern, access its complete sets, and if these match up. (Perhaps an implementation may optimize this process.) > > What I like about this approach is that it works well with GADTs, where, e.g., VNil is a complete set for type Vec a Zero but not for Vec a n. > > I take back my claim of "No types!" then, as this does sound like it has the right properties. > > For now, I don't want to get bogged down by syntax -- let's figure out how the idea should work first, and then we can worry about syntax. > > Here's a stab at a formalization of this idea, written in metatheory, not Haskell: > > Let C : Type -> Set of set of patterns. C will be the lookup function for complete sets. Suppose we have a pattern match, at type tau, matching against patterns Ps. Let S = C(tau). S is then a set of sets of patterns. The question is this: Is there a set s in S such that Ps is a superset of s? If yes, then the match is complete. > > What do we think of this design? Of course, the challenge is in building C, but we'll tackle that next. > > Richard > > On Oct 26, 2018, at 5:20 AM, Sylvain Henry wrote: > > Sorry I wasn't clear. I'm not an expert on the topic but it seems to me that there are two orthogonal concerns: > > 1) How does the checker retrieve COMPLETE sets. > > Currently it seems to "attach" them to data type constructors (e.g. Maybe). If instead it retrieved them by matching types (e.g. "Maybe a", "a") we could write: > > {-# COMPLETE LL #-} > > From an implementation point of view, it seems to me that finding complete sets would become similar to finding (flexible, overlapping) class instances. Pseudo-code: > > class Complete a where > conlikes :: [ConLike] > instance Complete (Maybe a) where > conlikes = [Nothing @a, Just @a] > instance Complete (Maybe a) where > conlikes = [N @a, J @a] > instance Complete a where > conlikes = [LL @a] > ... > > > 2) COMPLETE set depending on the matched type. > > It is a thread hijack from me but while we are thinking about refactoring COMPLETE pragmas to support polymorphism, maybe we could support this too. The idea is to build a different set of conlikes depending on the matched type. Pseudo-code: > > instance Complete (Variant cs) where > conlikes = [V @c | c <- cs] -- cs is a type list > > (I don't really care about the pragma syntax) > > Sorry for the thread hijack! > Regards, > Sylvain > > > On 10/26/18 5:59 AM, Richard Eisenberg wrote: > > I'm afraid I don't understand what your new syntax means. And, while I know it doesn't work today, what's wrong (in theory) with > > {-# COMPLETE LL #-} > > No types! (That's a rare thing for me to extol...) > > I feel I must be missing something here. > > Thanks, > Richard > > On Oct 25, 2018, at 12:24 PM, Sylvain Henry wrote: > > > In the case where all the patterns are polymorphic, a user must > > provide a type signature but we accept the definition regardless of > > the type signature they provide. > > Currently we can specify the type *constructor* in a COMPLETE pragma: > > pattern J :: a -> Maybe a > pattern J a = Just a > > pattern N :: Maybe a > pattern N = Nothing > > {-# COMPLETE N, J :: Maybe #-} > > > Instead if we could specify the type with its free vars, we could refer to them in conlike signatures: > > {-# COMPLETE N, [ J :: a -> Maybe a ] :: Maybe a #-} > > The COMPLETE pragma for LL could be: > > {-# COMPLETE [ LL :: HasSrcSpan a => SrcSpan -> SrcSpanLess a -> a ] :: a #-} > > > I'm borrowing the list comprehension syntax on purpose because it would allow to define a set of conlikes from a type-list (see my request [1]): > > {-# COMPLETE [ V :: (c :< cs) => c -> Variant cs > | c <- cs > ] :: Variant cs > #-} > > > To make things more formal, when the pattern-match checker > > requests a set of constructors for some data type constructor T, the > > checker returns: > > > > * The original set of data constructors for T > > * Any COMPLETE sets of type T > > > > Note the use of the phrase *type constructor*. The return type of all > > constructor-like things in a COMPLETE set must all be headed by the > > same type constructor T. Since `LL`'s return type is simply a type > > variable `a`, this simply doesn't work with the design of COMPLETE > > sets. > > Could we use a mechanism similar to instance resolution (with FlexibleInstances) for the checker to return matching COMPLETE sets instead? > > --Sylvain > > > [1] https://mail.haskell.org/pipermail/ghc-devs/2018-July/016053.html > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://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 From yotam2206 at gmail.com Sat Nov 10 11:19:08 2018 From: yotam2206 at gmail.com (Yotam Ohad) Date: Sat, 10 Nov 2018 13:19:08 +0200 Subject: Help on tuple section in TH Message-ID: Hello, I'm a wannabe ghc contributor on my first patch. I'm trying to do #15843 and I would like some help. I understand that I need to change repE in DsMeta.hs An explanation of the type signatures and the types would be very helpful. Also, What does repLEs do? Thanks for your help Yotam -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.jakobi at googlemail.com Sat Nov 10 11:48:41 2018 From: simon.jakobi at googlemail.com (Simon Jakobi) Date: Sat, 10 Nov 2018 12:48:41 +0100 Subject: Help on tuple section in TH In-Reply-To: References: Message-ID: Hi Yotam, welcome to GHC development! :) I'll try to give you a few pointers although I'm not really familiar with this part of of the code. * Read the module header at the top of DsMeta.hs. * Note that DsMeta exposes a single function, dsBracket. All code in DsMeta is ultimately used via this entrypoint. * Look up the types that dsBracket and the functions between it and repE accept and return. * You may find background info in the GHC Commentary: https://ghc.haskell.org/trac/ghc/wiki/Commentary * Join #ghc on IRC and ask away! :) Hope that helps! Have fun! Simon Am Sa., 10. Nov. 2018 um 12:19 Uhr schrieb Yotam Ohad : > Hello, > > I'm a wannabe ghc contributor on my first patch. I'm trying to do #15843 > and I would like some help. > I understand that I need to change repE in DsMeta.hs > An explanation of the type signatures and the types would be very helpful. > Also, What does repLEs do? > > Thanks for your help > > Yotam > _______________________________________________ > 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 ben at well-typed.com Sun Nov 11 03:10:35 2018 From: ben at well-typed.com (Ben Gamari) Date: Sat, 10 Nov 2018 22:10:35 -0500 Subject: slow execution of built executables on a Mac In-Reply-To: References: <87wopolc25.fsf@smart-cactus.org> Message-ID: <87in14l36h.fsf@smart-cactus.org> Richard Eisenberg writes: > OK. Well, I couldn't sample from Activity Monitor, because the > processes came and went too quickly. But the terminal command `sample` > takes a *name* as an argument, and so passing ghc-stage1 worked > nicely. Samples were taken during rts_dist_HC calls. > Hmmm, it looks to me like all of these are from GHC waiting on various things (e.g. _pthread_cond_wait, nanosleep, and pthread_join). It's quite surprising that these operations are chewing through cycles in kernel mode. I wonder how rapidly we are context switching. Perhaps we are quickly jumping between kernel and user mode? Perhaps strace (or I think the OS X equivalent is truss?) will shed some light? Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From george.colpitts at gmail.com Sun Nov 11 13:13:40 2018 From: george.colpitts at gmail.com (George Colpitts) Date: Sun, 11 Nov 2018 09:13:40 -0400 Subject: slow execution of built executables on a Mac In-Reply-To: <87in14l36h.fsf@smart-cactus.org> References: <87wopolc25.fsf@smart-cactus.org> <87in14l36h.fsf@smart-cactus.org> Message-ID: I couldn't duplicate this, when system times were high they were usually between 20-40% which seems high but not 80%. I am on Xcode 10.1, macOS 10.13.6 , a 4 core imac with 12 gb RAM and a hard drive not SSDs. I can't go to Mojave as it is an old iMac. I did make -j5 using ghc 8.6.2. The Mac doesn't have truss or strace. It does have dtrace which I believe is the equivalent. It might be good to open a ticket for this. As the description of how to reproduce are a bit vague and the steps are manual, it would be ideal if there were modified make file(s) to capture statistics using sample and maybe dtrace or even time. Cheers George On Sat, Nov 10, 2018 at 11:10 PM Ben Gamari wrote: > Richard Eisenberg writes: > > > OK. Well, I couldn't sample from Activity Monitor, because the > > processes came and went too quickly. But the terminal command `sample` > > takes a *name* as an argument, and so passing ghc-stage1 worked > > nicely. Samples were taken during rts_dist_HC calls. > > > Hmmm, it looks to me like all of these are from GHC waiting on various > things (e.g. _pthread_cond_wait, nanosleep, and pthread_join). It's > quite surprising that these operations are chewing through cycles in > kernel mode. I wonder how rapidly we are context switching. Perhaps we > are quickly jumping between kernel and user mode? Perhaps strace (or I > think the OS X equivalent is truss?) will shed some light? > > Cheers, > > - Ben > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rae at cs.brynmawr.edu Mon Nov 12 03:51:45 2018 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Sun, 11 Nov 2018 22:51:45 -0500 Subject: Help on tuple section in TH In-Reply-To: References: Message-ID: <6B9A3D65-9D43-47EC-BD26-95B37B3ABC56@cs.brynmawr.edu> Though it's starting to show its age, https://www.aosabook.org/en/ghc.html is still very relevant. Some names have changed. As for your other questions: can you expand on them? As stated, the questions would take a long post to answer, as they're very broad. Better would be pick a specific type or type signature that you don't understand, and ask about that. When doing so, show us what you've been able to learn by poking through the source code (I have rgrep on a hotkey in emacs), so that we can answer more efficiently. For example, repLEs shouldn't be terribly hard to understand, once you look at what the relationship between LHsExpr and HsExpr is. By pointing us to a precise place where you've looked for but not found an answer, we'll be able to help you along much better. Thanks for getting involved! Richard > On Nov 10, 2018, at 6:48 AM, Simon Jakobi via ghc-devs wrote: > > Hi Yotam, > > welcome to GHC development! :) > > I'll try to give you a few pointers although I'm not really familiar with this part of of the code. > > * Read the module header at the top of DsMeta.hs. > * Note that DsMeta exposes a single function, dsBracket. All code in DsMeta is ultimately used via this entrypoint. > * Look up the types that dsBracket and the functions between it and repE accept and return. > * You may find background info in the GHC Commentary: https://ghc.haskell.org/trac/ghc/wiki/Commentary > * Join #ghc on IRC and ask away! :) > > Hope that helps! Have fun! > Simon > > Am Sa., 10. Nov. 2018 um 12:19 Uhr schrieb Yotam Ohad >: > Hello, > > I'm a wannabe ghc contributor on my first patch. I'm trying to do #15843 and I would like some help. > I understand that I need to change repE in DsMeta.hs > An explanation of the type signatures and the types would be very helpful. > Also, What does repLEs do? > > Thanks for your help > > Yotam > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://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 simonpj at microsoft.com Mon Nov 12 10:14:22 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 12 Nov 2018 10:14:22 +0000 Subject: GHC's Fall 2018 HCAR submission In-Reply-To: <87va5l4kau.fsf@smart-cactus.org> References: <87va5l4kau.fsf@smart-cactus.org> Message-ID: Ben What's the deadline for this? * Under GHC proposals, can you list proposals that are - Accepted but not yet implemented - Accepted and implemented in 8.8, but not in 8.6 Thanks Simon | -----Original Message----- | From: ghc-devs On Behalf Of Ben Gamari | Sent: 29 October 2018 01:24 | To: GHC developers | Subject: GHC's Fall 2018 HCAR submission | | Hello everyone, | | The Haskell Community Activities Report is coming up and I have prepared | the skeleton for GHC's contribution [1]. If you have a project cooking or | have recently had a patch land do have a look to make sure it's recognized | in the submission. | | Cheers, | | - Ben | | | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fghc.haskel | l.org%2Ftrac%2Fghc%2Fwiki%2FStatus%2FOct18&data=02%7C01%7Csimonpj%40mic | rosoft.com%7C1273ad22650740f389de08d63d3d4800%7C72f988bf86f141af91ab2d7cd01 | 1db47%7C1%7C0%7C636763730743640484&sdata=PeAMJVxYq8%2FfTg5QEDjrF2N98ui3 | lJPnQOA6nrufBtg%3D&reserved=0 From mikhail.glushenkov at gmail.com Mon Nov 12 10:49:03 2018 From: mikhail.glushenkov at gmail.com (Mikhail Glushenkov) Date: Mon, 12 Nov 2018 10:49:03 +0000 Subject: GHC's Fall 2018 HCAR submission In-Reply-To: References: <87va5l4kau.fsf@smart-cactus.org> Message-ID: Hello Simon, On Mon, 12 Nov 2018 at 10:14, Simon Peyton Jones via ghc-devs wrote: > > Ben > > What's the deadline for this? Nov 4, according to Mihai Maruseac's original e-mail [1]. Though this month's edition hasn't been published yet. [1] https://mail.haskell.org/pipermail/haskell-cafe/2018-October/130071.html From ben at smart-cactus.org Mon Nov 12 13:34:24 2018 From: ben at smart-cactus.org (Ben Gamari) Date: Mon, 12 Nov 2018 08:34:24 -0500 Subject: GHC's Fall 2018 HCAR submission In-Reply-To: References: <87va5l4kau.fsf@smart-cactus.org> Message-ID: <26EE904A-2537-4F11-9D0A-850D56721259@smart-cactus.org> On November 12, 2018 5:14:22 AM EST, Simon Peyton Jones via ghc-devs wrote: >Ben > >What's the deadline for this? > I have sent the division but I suspect it's not too late to amend it if necessary. Cheers, - Ben >* Under GHC proposals, can you list proposals that are > - Accepted but not yet implemented > - Accepted and implemented in 8.8, but not in 8.6 > >Thanks > >Simon > > >| -----Original Message----- >| From: ghc-devs On Behalf Of Ben >Gamari >| Sent: 29 October 2018 01:24 >| To: GHC developers >| Subject: GHC's Fall 2018 HCAR submission >| >| Hello everyone, >| >| The Haskell Community Activities Report is coming up and I have >prepared >| the skeleton for GHC's contribution [1]. If you have a project >cooking or >| have recently had a patch land do have a look to make sure it's >recognized >| in the submission. >| >| Cheers, >| >| - Ben >| >| >| >https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fghc.haskel >| >l.org%2Ftrac%2Fghc%2Fwiki%2FStatus%2FOct18&data=02%7C01%7Csimonpj%40mic >| >rosoft.com%7C1273ad22650740f389de08d63d3d4800%7C72f988bf86f141af91ab2d7cd01 >| >1db47%7C1%7C0%7C636763730743640484&sdata=PeAMJVxYq8%2FfTg5QEDjrF2N98ui3 >| lJPnQOA6nrufBtg%3D&reserved=0 >_______________________________________________ >ghc-devs mailing list >ghc-devs at haskell.org >http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From simonpj at microsoft.com Mon Nov 12 23:03:36 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 12 Nov 2018 23:03:36 +0000 Subject: [commit: ghc] wip/az-namemap: Introduce map from RdrName to Name for GHC API (2745981) In-Reply-To: <20181112183204.9FEAA3AC04@ghc.haskell.org> References: <20181112183204.9FEAA3AC04@ghc.haskell.org> Message-ID: Alan Interesting. The GlobalRdrEnv is such a mapping. I'm not sure what the goal is here. Would it be worth a ticket and/or wiki page to explain the problem you are trying to solve? Simon | -----Original Message----- | From: ghc-commits On Behalf Of | git at git.haskell.org | Sent: 12 November 2018 18:32 | To: ghc-commits at haskell.org | Subject: [commit: ghc] wip/az-namemap: Introduce map from RdrName to Name | for GHC API (2745981) | | Repository : ssh://git at git.haskell.org/ghc | | On branch : wip/az-namemap | Link : | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.haskel | l.org%2Ftrac%2Fghc%2Fchangeset%2F2745981fb8a558cd486b674e4b15db8528f0cc78% | 2Fghc&data=02%7C01%7Csimonpj%40microsoft.com%7C9d848ba78ecd428ff7a508d | 648cd2a74%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636776443360189215& | amp;sdata=o7swv001G%2Bc%2FQAw23xr6GA18iXS8YratFJahszIIRH4%3D&reserved= | 0 | | >--------------------------------------------------------------- | | commit 2745981fb8a558cd486b674e4b15db8528f0cc78 | Author: Alan Zimmerman | Date: Mon Nov 12 20:26:40 2018 +0200 | | Introduce map from RdrName to Name for GHC API | | Tools need to work with the ParsedSource as a accurate representation | of the compiled source, but sometimes need access to the actual Names | used from the renaming phase. | | Introduce a function that initialises a NameMap from a TypechedModule, | for use by GHC API consumers. | | | >--------------------------------------------------------------- | | 2745981fb8a558cd486b674e4b15db8528f0cc78 | compiler/main/GHC.hs | 133 | +++++++++++++++++++++++++++++++++++++++++++++++++++ | 1 file changed, 133 insertions(+) | | diff --git a/compiler/main/GHC.hs b/compiler/main/GHC.hs | index cf9c74f..9d9cf17 100644 | --- a/compiler/main/GHC.hs | +++ b/compiler/main/GHC.hs | @@ -1,5 +1,6 @@ | {-# LANGUAGE CPP, NondecreasingIndentation, ScopedTypeVariables #-} | {-# LANGUAGE TupleSections, NamedFieldPuns #-} | +{-# LANGUAGE RankNTypes #-} | | -- ---------------------------------------------------------------------- | ------- | -- | @@ -125,6 +126,7 @@ module GHC ( | -- ** Looking up a Name | parseName, | lookupName, | + initRdrNameMap, NameMap, | | -- ** Compiling expressions | HValue, parseExpr, compileParsedExpr, | @@ -306,6 +308,7 @@ import TcRnTypes | import Packages | import NameSet | import RdrName | +import Var | import HsSyn | import Type hiding( typeKind ) | import TcType hiding( typeKind ) | @@ -352,7 +355,9 @@ import TcRnDriver | import Inst | import FamInst | import FileCleanup | +import Unique ( mkUnique ) | | +import Data.Data ( Data, gmapQ, cast ) | import Data.Foldable | import qualified Data.Map.Strict as Map | import Data.Set (Set) | @@ -1531,6 +1536,134 @@ lookupName :: GhcMonad m => Name -> m (Maybe | TyThing) | lookupName name = | withSession $ \hsc_env -> | liftIO $ hscTcRcLookupName hsc_env name | +-- ---------------------------------------------------------------------- | ------- | + | +-- | Map of 'SrcSpan's from 'Located' 'RdrName's in the 'ParsedSource' | +-- to the corresponding 'Name' from renaming. | +type NameMap = Map.Map SrcSpan Name | + | +-- | Tools prefer to work with the 'ParsedSource' because it more | +-- closely reflects the actual source code, but must be able to work | +-- with the renamed representation of the names involved. This | +-- function constructs a map from every 'Located' 'RdrName' in the | +-- 'ParsedSource' to its corresponding name in the 'RenamedSource' and | +-- 'TypecheckedSource'. | +initRdrNameMap :: TypecheckedModule -> NameMap | +initRdrNameMap tm = r | + where | + parsed = pm_parsed_source $ tm_parsed_module tm | + renamed = tm_renamed_source tm | + typechecked = tm_typechecked_source tm | + | + checkRdr :: Located RdrName -> Maybe [(SrcSpan,RdrName)] | + checkRdr (L l n@(Unqual _)) = Just [(l,n)] | + checkRdr (L l n@(Qual _ _)) = Just [(l,n)] | + checkRdr (L _ _)= Nothing | + | + checkName :: Located Name -> Maybe [Located Name] | + checkName ln = Just [ln] | + | + rdrNames = fromMaybe (panic "initRdrNameMap") | + $ everything mappend (nameSybQuery checkRdr ) parsed | + names1 = fromMaybe (panic "initRdrNameMap") | + $ everything mappend (nameSybQuery checkName) renamed | + names2 = names1 ++ everything (++) ([] `mkQ` fieldOcc | + `extQ` hsRecFieldN) renamed | + names = names2 ++ everything (++) ([] `mkQ` hsRecFieldT) | typechecked | + | + fieldOcc :: FieldOcc GhcRn -> [Located Name] | + fieldOcc (FieldOcc n (L l _)) = [(L l n)] | + fieldOcc XFieldOcc {} = [] | + | + hsRecFieldN :: LHsExpr GhcRn -> [Located Name] | + hsRecFieldN (L _ (HsRecFld _ (Unambiguous n (L l _) ))) = [L l n] | + hsRecFieldN _ = [] | + | + hsRecFieldT :: LHsExpr GhcTc -> [Located Name] | + hsRecFieldT (L _ (HsRecFld _ (Ambiguous n (L l _)) )) | + = [L l (Var.varName n)] | + hsRecFieldT _ = [] | + | + nameMap = Map.fromList $ map (\(L l n) -> (l,n)) names | + | + -- If the name does not exist (e.g. a TH Splice that has been | + -- expanded, make a new one) | + -- No attempt is made to make sure that equivalent ones have | + -- equivalent names. | + lookupName l n i = case Map.lookup l nameMap of | + Just v -> v | + Nothing -> | + case n of | + Unqual u -> mkNewGhcNamePure 'h' i Nothing (occNameString u) | + Qual q u -> mkNewGhcNamePure 'h' i | + (Just (Module (stringToUnitId "") q)) | (occNameString u) | + _ -> panic "initRdrNameMap" | + | + r = Map.fromList $ map (\((l,n),i) -> (l,lookupName l n i)) | + $ zip rdrNames [1..] | + | + nameSybQuery :: (Typeable a, Typeable t) | + => (Located a -> Maybe r) -> t -> Maybe r | + nameSybQuery checker = q | + where | + q = Nothing `mkQ` worker | + | + worker (pnt :: (Located a)) | + = checker pnt | + | + mkNewGhcNamePure :: Char -> Int -> Maybe Module -> String -> Name | + mkNewGhcNamePure c i maybeMod name = | + let un = mkUnique c i -- H for HaRe :) | + n = case maybeMod of | + Nothing -> mkInternalName un (mkVarOcc name) | noSrcSpan | + Just modu -> mkExternalName un modu (mkVarOcc name) | noSrcSpan | + in n | + | + | +-- Copied from SYB | + | + | +-- | Generic queries of type \"r\", | +-- i.e., take any \"a\" and return an \"r\" | +-- | +type GenericQ r = forall a. Data a => a -> r | + | + | +-- | Make a generic query; | +-- start from a type-specific case; | +-- return a constant otherwise | +-- | +mkQ :: ( Typeable a | + , Typeable b | + ) | + => r | + -> (b -> r) | + -> a | + -> r | +(r `mkQ` br) a = case cast a of | + Just b -> br b | + Nothing -> r | + | +-- | Extend a generic query by a type-specific case | +extQ :: ( Typeable a | + , Typeable b | + ) | + => (a -> q) | + -> (b -> q) | + -> a | + -> q | +extQ f g a = maybe (f a) g (cast a) | + | + | + | +-- | Summarise all nodes in top-down, left-to-right order | +everything :: (r -> r -> r) -> GenericQ r -> GenericQ r | + | +-- Apply f to x to summarise top-level node; | +-- use gmapQ to recurse into immediate subterms; | +-- use ordinary foldl to reduce list of intermediate results | + | +everything k f x = foldl k (f x) (gmapQ (everything k f) x) | | -- ---------------------------------------------------------------------- | ------- | -- Pure API | | _______________________________________________ | ghc-commits mailing list | ghc-commits at haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haske | ll.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- | commits&data=02%7C01%7Csimonpj%40microsoft.com%7C9d848ba78ecd428ff7a50 | 8d648cd2a74%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63677644336018921 | 5&sdata=fLoupgPItcbuELQ%2B7bnPKHXZ595utTpqL%2FzwLELpSuk%3D&reserve | d=0 From rae at cs.brynmawr.edu Tue Nov 13 22:48:59 2018 From: rae at cs.brynmawr.edu (Richard Eisenberg) Date: Tue, 13 Nov 2018 17:48:59 -0500 Subject: slow execution of built executables on a Mac In-Reply-To: References: <87wopolc25.fsf@smart-cactus.org> <87in14l36h.fsf@smart-cactus.org> Message-ID: OK. I've posted a bug: https://ghc.haskell.org/trac/ghc/ticket/15891 Thanks much for the attempts thus far! Richard > On Nov 11, 2018, at 8:13 AM, George Colpitts wrote: > > I couldn't duplicate this, when system times were high they were usually between 20-40% which seems high but not 80%. I am on Xcode 10.1, macOS 10.13.6 , a 4 core imac with 12 gb RAM and a hard drive not SSDs. I can't go to Mojave as it is an old iMac. I did make -j5 using ghc 8.6.2. > > The Mac doesn't have truss or strace. It does have dtrace which I believe is the equivalent. > > It might be good to open a ticket for this. As the description of how to reproduce are a bit vague and the steps are manual, it would be ideal if there were modified make file(s) to capture statistics using sample and maybe dtrace or even time. > > Cheers > George > > > > On Sat, Nov 10, 2018 at 11:10 PM Ben Gamari > wrote: > Richard Eisenberg > writes: > > > OK. Well, I couldn't sample from Activity Monitor, because the > > processes came and went too quickly. But the terminal command `sample` > > takes a *name* as an argument, and so passing ghc-stage1 worked > > nicely. Samples were taken during rts_dist_HC calls. > > > Hmmm, it looks to me like all of these are from GHC waiting on various > things (e.g. _pthread_cond_wait, nanosleep, and pthread_join). It's > quite surprising that these operations are chewing through cycles in > kernel mode. I wonder how rapidly we are context switching. Perhaps we > are quickly jumping between kernel and user mode? Perhaps strace (or I > think the OS X equivalent is truss?) will shed some light? > > Cheers, > > - Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From omeragacan at gmail.com Thu Nov 15 07:16:37 2018 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Thu, 15 Nov 2018 10:16:37 +0300 Subject: Unused RTS symbols disappearing in some flavors? Message-ID: Hi, When I build RTS with flavors other than quick (and maybe others) unused symbols get removed, which makes debugging harder. Does anyone know what setting to add to build.mk to make sure symbols won't be removed? Ideally I should be able to add one line at the end of build.mk and the symbols should not be removed regardless of the flavor. Thanks, Ömer From simonpj at microsoft.com Thu Nov 15 11:43:28 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 15 Nov 2018 11:43:28 +0000 Subject: perf stats Message-ID: This has just started happening in my local build tree Appending 0 stats to git notes. fatal: Not a git repository (or any parent up to mount point /5playpen) Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set). fatal: Not a git repository (or any parent up to mount point /5playpen) Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set). fatal: Not a git repository (or any parent up to mount point /5playpen) Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set). fatal: Not a git repository (or any parent up to mount point /5playpen) Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set). fatal: Not a git repository (or any parent up to mount point /5playpen) Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set). An error occured while writing the performance metrics to git notes. ​ This is usually due to a lock-file existing somewhere in the git repo. ../../mk/test.mk:344: recipe for target 'test' failed make: *** [test] Error 1 Should I worry? it looks bad. I definitely don’t want to monkey with git notes when I’m just developing/testing/validating, which I do endlessly Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Thu Nov 15 11:46:09 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 15 Nov 2018 11:46:09 +0000 Subject: perf stats In-Reply-To: References: Message-ID: Moreover it takes more than 50% of the time when doing make TEST=T1535 which I do a lot Simon From: Simon Peyton Jones Sent: 15 November 2018 11:43 To: 'ghc-devs at haskell.org' Subject: perf stats This has just started happening in my local build tree Appending 0 stats to git notes. fatal: Not a git repository (or any parent up to mount point /5playpen) Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set). fatal: Not a git repository (or any parent up to mount point /5playpen) Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set). fatal: Not a git repository (or any parent up to mount point /5playpen) Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set). fatal: Not a git repository (or any parent up to mount point /5playpen) Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set). fatal: Not a git repository (or any parent up to mount point /5playpen) Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set). An error occured while writing the performance metrics to git notes. ​ This is usually due to a lock-file existing somewhere in the git repo. ../../mk/test.mk:344: recipe for target 'test' failed make: *** [test] Error 1 Should I worry? it looks bad. I definitely don’t want to monkey with git notes when I’m just developing/testing/validating, which I do endlessly Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From klebinger.andreas at gmx.at Thu Nov 15 21:28:50 2018 From: klebinger.andreas at gmx.at (Andreas Klebinger) Date: Thu, 15 Nov 2018 22:28:50 +0100 Subject: Validate on master broken. Message-ID: <5BEDE512.3020102@gmx.at> Hello Devs, it seems Simons patch "Smarter HsType pretty-print for promoted datacons" broke ./validate. > I discovered that there were two copies of the PromotionFlag > type (a boolean, with helpfully named data cons), one in > IfaceType and one in HsType. So I combined into one, > PromotionFlag, and moved it to BasicTypes. In particular haddock seems to have depended on the changed constructors. If anyone with access and knowledge of haddock could fix this I would be grateful. Cheers Andreas From alec.theriault at gmail.com Thu Nov 15 21:41:06 2018 From: alec.theriault at gmail.com (Alec Theriault) Date: Thu, 15 Nov 2018 13:41:06 -0800 Subject: Validate on master broken. In-Reply-To: <5BEDE512.3020102@gmx.at> References: <5BEDE512.3020102@gmx.at> Message-ID: Thanks for noticing! I’m fixing this right now. The changes needed are really quite mundane… -Alec > On Nov 15, 2018, at 1:28 PM, Andreas Klebinger wrote: > > Hello Devs, > > it seems Simons patch "Smarter HsType pretty-print for promoted datacons" broke ./validate. > > > >> I discovered that there were two copies of the PromotionFlag >> type (a boolean, with helpfully named data cons), one in >> IfaceType and one in HsType. So I combined into one, >> PromotionFlag, and moved it to BasicTypes. > > In particular haddock seems to have depended on the changed constructors. > If anyone with access and knowledge of haddock could fix this I would be grateful. > > > Cheers > Andreas > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From simonpj at microsoft.com Thu Nov 15 23:33:01 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 15 Nov 2018 23:33:01 +0000 Subject: Validate on master broken. In-Reply-To: References: <5BEDE512.3020102@gmx.at> Message-ID: Bother -- my fault. Sorry about that. I should have thought of Haddock. Thanks for fixing. Simon | -----Original Message----- | From: ghc-devs On Behalf Of Alec Theriault | Sent: 15 November 2018 21:41 | To: Andreas Klebinger | Cc: ghc-devs at haskell.org | Subject: Re: Validate on master broken. | | Thanks for noticing! | | I’m fixing this right now. The changes needed are really quite mundane… | | -Alec | | > On Nov 15, 2018, at 1:28 PM, Andreas Klebinger | wrote: | > | > Hello Devs, | > | > it seems Simons patch "Smarter HsType pretty-print for promoted | datacons" broke ./validate. | > | > | > | >> I discovered that there were two copies of the PromotionFlag | >> type (a boolean, with helpfully named data cons), one in | >> IfaceType and one in HsType. So I combined into one, | >> PromotionFlag, and moved it to BasicTypes. | > | > In particular haddock seems to have depended on the changed | constructors. | > If anyone with access and knowledge of haddock could fix this I would | be grateful. | > | > | > Cheers | > Andreas | > _______________________________________________ | > ghc-devs mailing list | > ghc-devs at haskell.org | > | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haske | ll.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- | devs&data=02%7C01%7Csimonpj%40microsoft.com%7Cd72f4aad7f794904722108d6 | 4b43130f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636779148787876537&a | mp;sdata=rdOrnWF4V6hUy%2FHm9UYaEowR2T8ND0DXuCj15rPY0CY%3D&reserved=0 | | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haske | ll.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- | devs&data=02%7C01%7Csimonpj%40microsoft.com%7Cd72f4aad7f794904722108d6 | 4b43130f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636779148787876537&a | mp;sdata=rdOrnWF4V6hUy%2FHm9UYaEowR2T8ND0DXuCj15rPY0CY%3D&reserved=0 From omeragacan at gmail.com Fri Nov 16 04:39:59 2018 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Fri, 16 Nov 2018 07:39:59 +0300 Subject: Validate on master broken. In-Reply-To: References: <5BEDE512.3020102@gmx.at> Message-ID: This was also reported as #15900. Ömer Simon Peyton Jones via ghc-devs , 16 Kas 2018 Cum, 02:33 tarihinde şunu yazdı: > > Bother -- my fault. Sorry about that. I should have > thought of Haddock. > > Thanks for fixing. > > Simon > > | -----Original Message----- > | From: ghc-devs On Behalf Of Alec Theriault > | Sent: 15 November 2018 21:41 > | To: Andreas Klebinger > | Cc: ghc-devs at haskell.org > | Subject: Re: Validate on master broken. > | > | Thanks for noticing! > | > | I’m fixing this right now. The changes needed are really quite mundane… > | > | -Alec > | > | > On Nov 15, 2018, at 1:28 PM, Andreas Klebinger > | wrote: > | > > | > Hello Devs, > | > > | > it seems Simons patch "Smarter HsType pretty-print for promoted > | datacons" broke ./validate. > | > > | > > | > > | >> I discovered that there were two copies of the PromotionFlag > | >> type (a boolean, with helpfully named data cons), one in > | >> IfaceType and one in HsType. So I combined into one, > | >> PromotionFlag, and moved it to BasicTypes. > | > > | > In particular haddock seems to have depended on the changed > | constructors. > | > If anyone with access and knowledge of haddock could fix this I would > | be grateful. > | > > | > > | > Cheers > | > Andreas > | > _______________________________________________ > | > ghc-devs mailing list > | > ghc-devs at haskell.org > | > > | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haske > | ll.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- > | devs&data=02%7C01%7Csimonpj%40microsoft.com%7Cd72f4aad7f794904722108d6 > | 4b43130f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636779148787876537&a > | mp;sdata=rdOrnWF4V6hUy%2FHm9UYaEowR2T8ND0DXuCj15rPY0CY%3D&reserved=0 > | > | _______________________________________________ > | ghc-devs mailing list > | ghc-devs at haskell.org > | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haske > | ll.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- > | devs&data=02%7C01%7Csimonpj%40microsoft.com%7Cd72f4aad7f794904722108d6 > | 4b43130f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636779148787876537&a > | mp;sdata=rdOrnWF4V6hUy%2FHm9UYaEowR2T8ND0DXuCj15rPY0CY%3D&reserved=0 > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From omeragacan at gmail.com Fri Nov 16 10:28:36 2018 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Fri, 16 Nov 2018 13:28:36 +0300 Subject: Validate on master broken. In-Reply-To: References: <5BEDE512.3020102@gmx.at> Message-ID: 4efd1b487e fixed the build but the test T15898 now fails when run in ghci way. Ömer Ömer Sinan Ağacan , 16 Kas 2018 Cum, 07:39 tarihinde şunu yazdı: > > This was also reported as #15900. > > Ömer > > Simon Peyton Jones via ghc-devs , 16 Kas 2018 > Cum, 02:33 tarihinde şunu yazdı: > > > > Bother -- my fault. Sorry about that. I should have > > thought of Haddock. > > > > Thanks for fixing. > > > > Simon > > > > | -----Original Message----- > > | From: ghc-devs On Behalf Of Alec Theriault > > | Sent: 15 November 2018 21:41 > > | To: Andreas Klebinger > > | Cc: ghc-devs at haskell.org > > | Subject: Re: Validate on master broken. > > | > > | Thanks for noticing! > > | > > | I’m fixing this right now. The changes needed are really quite mundane… > > | > > | -Alec > > | > > | > On Nov 15, 2018, at 1:28 PM, Andreas Klebinger > > | wrote: > > | > > > | > Hello Devs, > > | > > > | > it seems Simons patch "Smarter HsType pretty-print for promoted > > | datacons" broke ./validate. > > | > > > | > > > | > > > | >> I discovered that there were two copies of the PromotionFlag > > | >> type (a boolean, with helpfully named data cons), one in > > | >> IfaceType and one in HsType. So I combined into one, > > | >> PromotionFlag, and moved it to BasicTypes. > > | > > > | > In particular haddock seems to have depended on the changed > > | constructors. > > | > If anyone with access and knowledge of haddock could fix this I would > > | be grateful. > > | > > > | > > > | > Cheers > > | > Andreas > > | > _______________________________________________ > > | > ghc-devs mailing list > > | > ghc-devs at haskell.org > > | > > > | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haske > > | ll.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- > > | devs&data=02%7C01%7Csimonpj%40microsoft.com%7Cd72f4aad7f794904722108d6 > > | 4b43130f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636779148787876537&a > > | mp;sdata=rdOrnWF4V6hUy%2FHm9UYaEowR2T8ND0DXuCj15rPY0CY%3D&reserved=0 > > | > > | _______________________________________________ > > | ghc-devs mailing list > > | ghc-devs at haskell.org > > | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haske > > | ll.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- > > | devs&data=02%7C01%7Csimonpj%40microsoft.com%7Cd72f4aad7f794904722108d6 > > | 4b43130f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636779148787876537&a > > | mp;sdata=rdOrnWF4V6hUy%2FHm9UYaEowR2T8ND0DXuCj15rPY0CY%3D&reserved=0 > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From alp at well-typed.com Fri Nov 16 10:29:57 2018 From: alp at well-typed.com (Alp Mestanogullari) Date: Fri, 16 Nov 2018 11:29:57 +0100 Subject: Validate on master broken. In-Reply-To: References: <5BEDE512.3020102@gmx.at> Message-ID: <755f4d1f-e7f1-cc7e-544e-e4875226b637@well-typed.com> I reported the exact error in https://ghc.haskell.org/trac/ghc/ticket/15898#comment:3. On 16/11/2018 11:28, Ömer Sinan Ağacan wrote: > 4efd1b487e fixed the build but the test T15898 now fails when run in ghci way. > > Ömer > > Ömer Sinan Ağacan , 16 Kas 2018 Cum, 07:39 > tarihinde şunu yazdı: >> This was also reported as #15900. >> >> Ömer >> >> Simon Peyton Jones via ghc-devs , 16 Kas 2018 >> Cum, 02:33 tarihinde şunu yazdı: >>> Bother -- my fault. Sorry about that. I should have >>> thought of Haddock. >>> >>> Thanks for fixing. >>> >>> Simon >>> >>> | -----Original Message----- >>> | From: ghc-devs On Behalf Of Alec Theriault >>> | Sent: 15 November 2018 21:41 >>> | To: Andreas Klebinger >>> | Cc: ghc-devs at haskell.org >>> | Subject: Re: Validate on master broken. >>> | >>> | Thanks for noticing! >>> | >>> | I’m fixing this right now. The changes needed are really quite mundane… >>> | >>> | -Alec >>> | >>> | > On Nov 15, 2018, at 1:28 PM, Andreas Klebinger >>> | wrote: >>> | > >>> | > Hello Devs, >>> | > >>> | > it seems Simons patch "Smarter HsType pretty-print for promoted >>> | datacons" broke ./validate. >>> | > >>> | > >>> | > >>> | >> I discovered that there were two copies of the PromotionFlag >>> | >> type (a boolean, with helpfully named data cons), one in >>> | >> IfaceType and one in HsType. So I combined into one, >>> | >> PromotionFlag, and moved it to BasicTypes. >>> | > >>> | > In particular haddock seems to have depended on the changed >>> | constructors. >>> | > If anyone with access and knowledge of haddock could fix this I would >>> | be grateful. >>> | > >>> | > >>> | > Cheers >>> | > Andreas >>> | > _______________________________________________ >>> | > ghc-devs mailing list >>> | > ghc-devs at haskell.org >>> | > >>> | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haske >>> | ll.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- >>> | devs&data=02%7C01%7Csimonpj%40microsoft.com%7Cd72f4aad7f794904722108d6 >>> | 4b43130f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636779148787876537&a >>> | mp;sdata=rdOrnWF4V6hUy%2FHm9UYaEowR2T8ND0DXuCj15rPY0CY%3D&reserved=0 >>> | >>> | _______________________________________________ >>> | ghc-devs mailing list >>> | ghc-devs at haskell.org >>> | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haske >>> | ll.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- >>> | devs&data=02%7C01%7Csimonpj%40microsoft.com%7Cd72f4aad7f794904722108d6 >>> | 4b43130f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636779148787876537&a >>> | mp;sdata=rdOrnWF4V6hUy%2FHm9UYaEowR2T8ND0DXuCj15rPY0CY%3D&reserved=0 >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://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 -- Alp Mestanogullari, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/ Registered in England and Wales, OC335890 118 Wymering Mansions, Wymering Road, London, W9 2NF, England From omeragacan at gmail.com Fri Nov 16 11:39:51 2018 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Fri, 16 Nov 2018 14:39:51 +0300 Subject: Using same stdout/stderr files for multiple tests? Message-ID: I have a test that I want to run with different compile and runtime parameters. I managed to reuse the source file across different tests by adding a extra_files(['source.hs']) to the tests, but I don't know how to do the same for stdout/stderr files. Any ideas? In more details, I have test.hs test.stdout and two tests test('test', [extra_run_opts('...')], compile_and_run, []) test('test_debug', [extra_run_opts('...'), extra_hc_opts('-debug'), extra_files(['test.hs'])], compile_and_run, []) The first test works fine, but the second test fails because I don't know how to tell it to use test.stdout as the stdout file and it looks for test_debug.stdout. Thanks Ömer From simonpj at microsoft.com Sat Nov 17 10:05:17 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Sat, 17 Nov 2018 10:05:17 +0000 Subject: More teststuite woes Message-ID: David I got this error on Windows today. It's during the testuite run of 'sh validate' =====> T7969(normal) 3998 of 6647 [0, 25, 1] cd "/c/Users/simonpj/AppData/Local/Temp/ghctest-b2z6dfqg/test spaces/rename/should_compile/T7969.run" && $MAKE -s --no-print-directory T7969 =====> T9127(normal) 3999 of 6647 [0, 25, 1] cd "/c/Users/simonpj/AppData/Local/Temp/ghctest-b2z6dfqg/test spaces/rename/should_compile/T9127.run" && "/c/code/HEAD/bindisttest/install dir/bin/ghc.exe" -c T9127.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output =====> T4426(normal) 4000 of 6647 [0, 25, 1] cd "/c/Users/simonpj/AppData/Local/Temp/ghctest-b2z6dfqg/test spaces/rename/should_compile/T4426.run" && "/c/code/HEAD/bindisttest/install dir/bin/ghc.exe" -c T4426.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output cd "/c/Users/simonpj/AppData/Local/Temp/ghctest-b2z6dfqg/test spaces/rename/should_compile/T5592.run" && ./T5592 =====> T9778(normal) 4001 of 6647 [0, 25, 1] cd "/c/Users/simonpj/AppData/Local/Temp/ghctest-b2z6dfqg/test spaces/rename/should_compile/T9778.run" && "/c/code/HEAD/bindisttest/install dir/bin/ghc.exe" -c T9778.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output -fwarn-unticked-promoted-constructors =====> T10816(normal) 4002 of 6647 [0, 25, 1] cd "/c/Users/simonpj/AppData/Local/Temp/ghctest-b2z6dfqg/test spaces/rename/should_compile/T10816.run" && "/c/code/HEAD/bindisttest/install dir/bin/ghc.exe" -c T10816.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output Traceback (most recent call last): File "/usr/lib/python3.6/threading.py", line 426, in acquire self._cond.wait(timeout) File "/usr/lib/python3.6/threading.py", line 287, in wait raise RuntimeError("cannot wait on un-acquired lock") RuntimeError: cannot wait on un-acquired lock During handling of the above exception, another exception occurred: Traceback (most recent call last): File "../driver/runtests.py", line 336, in oneTest(watcher) File "/c/code/HEAD/testsuite/driver/testlib.py", line 717, in thisTest = lambda watcher: runTest(watcher, myTestOpts, name, func, args) File "/c/code/HEAD/testsuite/driver/testlib.py", line 678, in runTest pool_sema.acquire() File "/usr/lib/python3.6/threading.py", line 429, in acquire rc = True File "/usr/lib/python3.6/threading.py", line 243, in __exit__ return self._lock.__exit__(*args) RuntimeError: release unlocked lock make: *** [../mk/test.mk:344: test] Error 1 make: Leaving directory '/c/code/HEAD/testsuite/tests' make: Entering directory '/c/code/HEAD/testsuite/tests/stage1' Does this ring any bells. It means I can't validate at all. Thanks Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From davide at well-typed.com Sat Nov 17 16:47:48 2018 From: davide at well-typed.com (David Eichmann) Date: Sat, 17 Nov 2018 16:47:48 +0000 Subject: More teststuite woes In-Reply-To: References: Message-ID: Hello Simon, I had a quick look into this today, and spoke a bit with Ben about it. We don't have a clear answer as to what is causing this at the moment. We'll have to look more into this early next week. > It means I can’t validate at all. So you've tried to validate multiple times? I.e. does the error happen deterministically or was it more of a one off event? - David E On 17/11/18 10:05, Simon Peyton Jones via ghc-devs wrote: > > David > > I got this error on Windows today.  It’s during the testuite run of > ‘sh validate’ > > =====> T7969(normal) 3998 of 6647 [0, 25, 1] > > cd "/c/Users/simonpj/AppData/Local/Temp/ghctest-b2z6dfqg/test > spaces/rename/should_compile/T7969.run" && $MAKE -s > --no-print-directory T7969 > > =====> T9127(normal) 3999 of 6647 [0, 25, 1] > > cd "/c/Users/simonpj/AppData/Local/Temp/ghctest-b2z6dfqg/test > spaces/rename/should_compile/T9127.run" && > "/c/code/HEAD/bindisttest/install   dir/bin/ghc.exe" -c T9127.hs > -dcore-lint -dcmm-lint -no-user-package-db -rtsopts > -fno-warn-missed-specialisations -fshow-warning-groups > -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat > -dno-debug-output > > =====> T4426(normal) 4000 of 6647 [0, 25, 1] > > cd "/c/Users/simonpj/AppData/Local/Temp/ghctest-b2z6dfqg/test > spaces/rename/should_compile/T4426.run" && > "/c/code/HEAD/bindisttest/install   dir/bin/ghc.exe" -c T4426.hs > -dcore-lint -dcmm-lint -no-user-package-db -rtsopts > -fno-warn-missed-specialisations -fshow-warning-groups > -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat > -dno-debug-output > > cd "/c/Users/simonpj/AppData/Local/Temp/ghctest-b2z6dfqg/test > spaces/rename/should_compile/T5592.run" && ./T5592 > > =====> T9778(normal) 4001 of 6647 [0, 25, 1] > > cd "/c/Users/simonpj/AppData/Local/Temp/ghctest-b2z6dfqg/test > spaces/rename/should_compile/T9778.run" && > "/c/code/HEAD/bindisttest/install   dir/bin/ghc.exe" -c T9778.hs > -dcore-lint -dcmm-lint -no-user-package-db -rtsopts > -fno-warn-missed-specialisations -fshow-warning-groups > -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat > -dno-debug-output -fwarn-unticked-promoted-constructors > > =====> T10816(normal) 4002 of 6647 [0, 25, 1] > > cd "/c/Users/simonpj/AppData/Local/Temp/ghctest-b2z6dfqg/test > spaces/rename/should_compile/T10816.run" && > "/c/code/HEAD/bindisttest/install   dir/bin/ghc.exe" -c T10816.hs > -dcore-lint -dcmm-lint -no-user-package-db -rtsopts > -fno-warn-missed-specialisations -fshow-warning-groups > -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat > -dno-debug-output > > Traceback (most recent call last): > >   File "/usr/lib/python3.6/threading.py", line 426, in acquire > >     self._cond.wait(timeout) > >   File "/usr/lib/python3.6/threading.py", line 287, in wait > >     raise RuntimeError("cannot wait on un-acquired lock") > > *RuntimeError: cannot wait on un-acquired lock* > > During handling of the above exception, another exception occurred: > > Traceback (most recent call last): > >   File "../driver/runtests.py", line 336, in > >     oneTest(watcher) > >   File "/c/code/HEAD/testsuite/driver/testlib.py", line 717, in > >     thisTest = lambda watcher: runTest(watcher, myTestOpts, name, > func, args) > >   File "/c/code/HEAD/testsuite/driver/testlib.py", line 678, in runTest > >     pool_sema.acquire() > >   File "/usr/lib/python3.6/threading.py", line 429, in acquire > >     rc = True > >   File "/usr/lib/python3.6/threading.py", line 243, in __exit__ > >     return self._lock.__exit__(*args) > > *RuntimeError: release unlocked lock* > > make: *** [../mk/test.mk:344: test] Error 1 > > make: Leaving directory '/c/code/HEAD/testsuite/tests' > > make: Entering directory '/c/code/HEAD/testsuite/tests/stage1' > > Does this ring any bells.  It means I can’t validate at all. > > Thanks > > Simon > > > > _______________________________________________ > 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 simonpj at microsoft.com Sat Nov 17 17:56:43 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Sat, 17 Nov 2018 17:56:43 +0000 Subject: More teststuite woes In-Reply-To: References: Message-ID: I'll try validating again to see if the same thing happens. Simon From: David Eichmann Sent: 17 November 2018 16:48 To: Simon Peyton Jones Cc: ghc-devs at haskell.org Subject: Re: More teststuite woes Hello Simon, I had a quick look into this today, and spoke a bit with Ben about it. We don't have a clear answer as to what is causing this at the moment. We'll have to look more into this early next week. > It means I can't validate at all. So you've tried to validate multiple times? I.e. does the error happen deterministically or was it more of a one off event? - David E On 17/11/18 10:05, Simon Peyton Jones via ghc-devs wrote: David I got this error on Windows today. It's during the testuite run of 'sh validate' =====> T7969(normal) 3998 of 6647 [0, 25, 1] cd "/c/Users/simonpj/AppData/Local/Temp/ghctest-b2z6dfqg/test spaces/rename/should_compile/T7969.run" && $MAKE -s --no-print-directory T7969 =====> T9127(normal) 3999 of 6647 [0, 25, 1] cd "/c/Users/simonpj/AppData/Local/Temp/ghctest-b2z6dfqg/test spaces/rename/should_compile/T9127.run" && "/c/code/HEAD/bindisttest/install dir/bin/ghc.exe" -c T9127.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output =====> T4426(normal) 4000 of 6647 [0, 25, 1] cd "/c/Users/simonpj/AppData/Local/Temp/ghctest-b2z6dfqg/test spaces/rename/should_compile/T4426.run" && "/c/code/HEAD/bindisttest/install dir/bin/ghc.exe" -c T4426.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output cd "/c/Users/simonpj/AppData/Local/Temp/ghctest-b2z6dfqg/test spaces/rename/should_compile/T5592.run" && ./T5592 =====> T9778(normal) 4001 of 6647 [0, 25, 1] cd "/c/Users/simonpj/AppData/Local/Temp/ghctest-b2z6dfqg/test spaces/rename/should_compile/T9778.run" && "/c/code/HEAD/bindisttest/install dir/bin/ghc.exe" -c T9778.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output -fwarn-unticked-promoted-constructors =====> T10816(normal) 4002 of 6647 [0, 25, 1] cd "/c/Users/simonpj/AppData/Local/Temp/ghctest-b2z6dfqg/test spaces/rename/should_compile/T10816.run" && "/c/code/HEAD/bindisttest/install dir/bin/ghc.exe" -c T10816.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output Traceback (most recent call last): File "/usr/lib/python3.6/threading.py", line 426, in acquire self._cond.wait(timeout) File "/usr/lib/python3.6/threading.py", line 287, in wait raise RuntimeError("cannot wait on un-acquired lock") RuntimeError: cannot wait on un-acquired lock During handling of the above exception, another exception occurred: Traceback (most recent call last): File "../driver/runtests.py", line 336, in oneTest(watcher) File "/c/code/HEAD/testsuite/driver/testlib.py", line 717, in thisTest = lambda watcher: runTest(watcher, myTestOpts, name, func, args) File "/c/code/HEAD/testsuite/driver/testlib.py", line 678, in runTest pool_sema.acquire() File "/usr/lib/python3.6/threading.py", line 429, in acquire rc = True File "/usr/lib/python3.6/threading.py", line 243, in __exit__ return self._lock.__exit__(*args) RuntimeError: release unlocked lock make: *** [../mk/test.mk:344: test] Error 1 make: Leaving directory '/c/code/HEAD/testsuite/tests' make: Entering directory '/c/code/HEAD/testsuite/tests/stage1' Does this ring any bells. It means I can't validate at all. Thanks Simon _______________________________________________ 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 simonpj at microsoft.com Sat Nov 17 21:55:46 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Sat, 17 Nov 2018 21:55:46 +0000 Subject: More teststuite woes In-Reply-To: References: Message-ID: Hmm. The second run worked fine. That's unhelpful from a debugging point of view, but it means I'm not stuck! Simon From: Simon Peyton Jones Sent: 17 November 2018 17:57 To: 'David Eichmann' Cc: ghc-devs at haskell.org Subject: RE: More teststuite woes I'll try validating again to see if the same thing happens. Simon From: David Eichmann > Sent: 17 November 2018 16:48 To: Simon Peyton Jones > Cc: ghc-devs at haskell.org Subject: Re: More teststuite woes Hello Simon, I had a quick look into this today, and spoke a bit with Ben about it. We don't have a clear answer as to what is causing this at the moment. We'll have to look more into this early next week. > It means I can't validate at all. So you've tried to validate multiple times? I.e. does the error happen deterministically or was it more of a one off event? - David E On 17/11/18 10:05, Simon Peyton Jones via ghc-devs wrote: David I got this error on Windows today. It's during the testuite run of 'sh validate' =====> T7969(normal) 3998 of 6647 [0, 25, 1] cd "/c/Users/simonpj/AppData/Local/Temp/ghctest-b2z6dfqg/test spaces/rename/should_compile/T7969.run" && $MAKE -s --no-print-directory T7969 =====> T9127(normal) 3999 of 6647 [0, 25, 1] cd "/c/Users/simonpj/AppData/Local/Temp/ghctest-b2z6dfqg/test spaces/rename/should_compile/T9127.run" && "/c/code/HEAD/bindisttest/install dir/bin/ghc.exe" -c T9127.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output =====> T4426(normal) 4000 of 6647 [0, 25, 1] cd "/c/Users/simonpj/AppData/Local/Temp/ghctest-b2z6dfqg/test spaces/rename/should_compile/T4426.run" && "/c/code/HEAD/bindisttest/install dir/bin/ghc.exe" -c T4426.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output cd "/c/Users/simonpj/AppData/Local/Temp/ghctest-b2z6dfqg/test spaces/rename/should_compile/T5592.run" && ./T5592 =====> T9778(normal) 4001 of 6647 [0, 25, 1] cd "/c/Users/simonpj/AppData/Local/Temp/ghctest-b2z6dfqg/test spaces/rename/should_compile/T9778.run" && "/c/code/HEAD/bindisttest/install dir/bin/ghc.exe" -c T9778.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output -fwarn-unticked-promoted-constructors =====> T10816(normal) 4002 of 6647 [0, 25, 1] cd "/c/Users/simonpj/AppData/Local/Temp/ghctest-b2z6dfqg/test spaces/rename/should_compile/T10816.run" && "/c/code/HEAD/bindisttest/install dir/bin/ghc.exe" -c T10816.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output Traceback (most recent call last): File "/usr/lib/python3.6/threading.py", line 426, in acquire self._cond.wait(timeout) File "/usr/lib/python3.6/threading.py", line 287, in wait raise RuntimeError("cannot wait on un-acquired lock") RuntimeError: cannot wait on un-acquired lock During handling of the above exception, another exception occurred: Traceback (most recent call last): File "../driver/runtests.py", line 336, in oneTest(watcher) File "/c/code/HEAD/testsuite/driver/testlib.py", line 717, in thisTest = lambda watcher: runTest(watcher, myTestOpts, name, func, args) File "/c/code/HEAD/testsuite/driver/testlib.py", line 678, in runTest pool_sema.acquire() File "/usr/lib/python3.6/threading.py", line 429, in acquire rc = True File "/usr/lib/python3.6/threading.py", line 243, in __exit__ return self._lock.__exit__(*args) RuntimeError: release unlocked lock make: *** [../mk/test.mk:344: test] Error 1 make: Leaving directory '/c/code/HEAD/testsuite/tests' make: Entering directory '/c/code/HEAD/testsuite/tests/stage1' Does this ring any bells. It means I can't validate at all. Thanks Simon _______________________________________________ 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 davide at well-typed.com Sat Nov 17 22:39:55 2018 From: davide at well-typed.com (David Eichmann) Date: Sat, 17 Nov 2018 22:39:55 +0000 Subject: More teststuite woes In-Reply-To: References: Message-ID: <283c95a1-3985-7396-1d03-aaaaae6678e9@well-typed.com> The exception is thrown by python's semaphore class. We are using it to limit the number of tests running concurrently, though I couldn't see anything obviously wrong with the relevant code. If possible, could you find out what `python --version` you have? David E On 17/11/18 21:55, Simon Peyton Jones wrote: > > Hmm.   The second run worked fine.  That’s unhelpful from a debugging > point of view, but it means I’m not stuck! > > Simon > > *From:*Simon Peyton Jones > *Sent:* 17 November 2018 17:57 > *To:* 'David Eichmann' > *Cc:* ghc-devs at haskell.org > *Subject:* RE: More teststuite woes > > I’ll try validating again to see if the same thing happens. > > Simon > > *From:*David Eichmann > > *Sent:* 17 November 2018 16:48 > *To:* Simon Peyton Jones > > *Cc:* ghc-devs at haskell.org > *Subject:* Re: More teststuite woes > > Hello Simon, > > I had a quick look into this today, and spoke a bit with Ben about it. > We don't have a clear answer as to what is causing this at the moment. > We'll have to look more into this early next week. > > > It means I can’t validate at all. > > So you've tried to validate multiple times? I.e. does the error happen > deterministically or was it more of a one off event? > > - David E > > On 17/11/18 10:05, Simon Peyton Jones via ghc-devs wrote: > > David > > I got this error on Windows today. It’s during the testuite run of > ‘sh validate’ > > =====> T7969(normal) 3998 of 6647 [0, 25, 1] > > cd "/c/Users/simonpj/AppData/Local/Temp/ghctest-b2z6dfqg/test > spaces/rename/should_compile/T7969.run" && $MAKE -s > --no-print-directory T7969 > > =====> T9127(normal) 3999 of 6647 [0, 25, 1] > > cd "/c/Users/simonpj/AppData/Local/Temp/ghctest-b2z6dfqg/test > spaces/rename/should_compile/T9127.run" && > "/c/code/HEAD/bindisttest/install   dir/bin/ghc.exe" -c T9127.hs > -dcore-lint -dcmm-lint -no-user-package-db -rtsopts > -fno-warn-missed-specialisations -fshow-warning-groups > -fdiagnostics-color=never -fno-diagnostics-show-caret > -Werror=compat -dno-debug-output > > =====> T4426(normal) 4000 of 6647 [0, 25, 1] > > cd "/c/Users/simonpj/AppData/Local/Temp/ghctest-b2z6dfqg/test > spaces/rename/should_compile/T4426.run" && > "/c/code/HEAD/bindisttest/install   dir/bin/ghc.exe" -c T4426.hs > -dcore-lint -dcmm-lint -no-user-package-db -rtsopts > -fno-warn-missed-specialisations -fshow-warning-groups > -fdiagnostics-color=never -fno-diagnostics-show-caret > -Werror=compat -dno-debug-output > > cd "/c/Users/simonpj/AppData/Local/Temp/ghctest-b2z6dfqg/test > spaces/rename/should_compile/T5592.run" && ./T5592 > > =====> T9778(normal) 4001 of 6647 [0, 25, 1] > > cd "/c/Users/simonpj/AppData/Local/Temp/ghctest-b2z6dfqg/test > spaces/rename/should_compile/T9778.run" && > "/c/code/HEAD/bindisttest/install   dir/bin/ghc.exe" -c T9778.hs > -dcore-lint -dcmm-lint -no-user-package-db -rtsopts > -fno-warn-missed-specialisations -fshow-warning-groups > -fdiagnostics-color=never -fno-diagnostics-show-caret > -Werror=compat -dno-debug-output  > -fwarn-unticked-promoted-constructors > > =====> T10816(normal) 4002 of 6647 [0, 25, 1] > > cd "/c/Users/simonpj/AppData/Local/Temp/ghctest-b2z6dfqg/test > spaces/rename/should_compile/T10816.run" && > "/c/code/HEAD/bindisttest/install   dir/bin/ghc.exe" -c T10816.hs > -dcore-lint -dcmm-lint -no-user-package-db -rtsopts > -fno-warn-missed-specialisations -fshow-warning-groups > -fdiagnostics-color=never -fno-diagnostics-show-caret > -Werror=compat -dno-debug-output > > Traceback (most recent call last): > >   File "/usr/lib/python3.6/threading.py", line 426, in acquire > >     self._cond.wait(timeout) > >   File "/usr/lib/python3.6/threading.py", line 287, in wait > >     raise RuntimeError("cannot wait on un-acquired lock") > > *RuntimeError: cannot wait on un-acquired lock* > > During handling of the above exception, another exception occurred: > > Traceback (most recent call last): > >   File "../driver/runtests.py", line 336, in > >     oneTest(watcher) > >   File "/c/code/HEAD/testsuite/driver/testlib.py", line 717, in > > >     thisTest = lambda watcher: runTest(watcher, myTestOpts, name, > func, args) > >   File "/c/code/HEAD/testsuite/driver/testlib.py", line 678, in > runTest > >     pool_sema.acquire() > >   File "/usr/lib/python3.6/threading.py", line 429, in acquire > >     rc = True > >   File "/usr/lib/python3.6/threading.py", line 243, in __exit__ > >     return self._lock.__exit__(*args) > > *RuntimeError: release unlocked lock* > > make: *** [../mk/test.mk:344: test] Error 1 > > make: Leaving directory '/c/code/HEAD/testsuite/tests' > > make: Entering directory '/c/code/HEAD/testsuite/tests/stage1' > > Does this ring any bells.  It means I can’t validate at all. > > Thanks > > Simon > > > > _______________________________________________ > > 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 ggreif at gmail.com Sun Nov 18 12:02:36 2018 From: ggreif at gmail.com (Gabor Greif) Date: Sun, 18 Nov 2018 13:02:36 +0100 Subject: [commit: ghc] master: Introduce Int16# and Word16# (36fcf9e) In-Reply-To: <20181117150345.08F463A8E4@ghc.haskell.org> References: <20181117150345.08F463A8E4@ghc.haskell.org> Message-ID: Hello Abhiroop! LLVM backend seems to choke on this still: ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.7.20181118 for x86_64-unknown-linux): LlvmCodeGen.CodeGen.cmmPrimOpFunctions: MO_S_QuotRem W16 not supported here Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Cheers, Gabor On 11/17/18, git at git.haskell.org wrote: > Repository : ssh://git at git.haskell.org/ghc > > On branch : master > Link : > http://ghc.haskell.org/trac/ghc/changeset/36fcf9edee31513db2ddbf716ee0aa79766cbe69/ghc > >>--------------------------------------------------------------- > > commit 36fcf9edee31513db2ddbf716ee0aa79766cbe69 > Author: Abhiroop Sarkar > Date: Mon Nov 5 12:06:58 2018 -0500 > > Introduce Int16# and Word16# > > This builds off of D4475. > > Bumps binary submodule. > > Reviewers: carter, AndreasK, hvr, goldfire, bgamari, simonmar > > Subscribers: rwbarton, thomie > > Differential Revision: https://phabricator.haskell.org/D5006 > > >>--------------------------------------------------------------- > > 36fcf9edee31513db2ddbf716ee0aa79766cbe69 > compiler/cmm/CmmUtils.hs | 4 + > compiler/codeGen/StgCmmArgRep.hs | 2 + > compiler/codeGen/StgCmmPrim.hs | 45 +++++ > compiler/prelude/PrelNames.hs | 115 ++++++------ > compiler/prelude/TysPrim.hs | 22 ++- > compiler/prelude/TysWiredIn.hs | 15 +- > compiler/prelude/TysWiredIn.hs-boot | 1 + > compiler/prelude/primops.txt.pp | 82 +++++++++ > compiler/simplStg/RepType.hs | 2 + > compiler/typecheck/TcGenDeriv.hs | 42 ++++- > compiler/types/TyCon.hs | 4 + > compiler/utils/Binary.hs | 4 + > libraries/base/Data/Typeable/Internal.hs | 2 + > libraries/binary | 2 +- > libraries/ghc-prim/GHC/Types.hs | 6 +- > testsuite/tests/ffi/should_run/PrimFFIInt16.hs | 28 +++ > .../{PrimFFIInt8.stdout => PrimFFIInt16.stdout} | 0 > testsuite/tests/ffi/should_run/PrimFFIInt16_c.c | 7 + > testsuite/tests/ffi/should_run/PrimFFIWord16.hs | 28 +++ > .../{PrimFFIInt8.stdout => PrimFFIWord16.stdout} | 0 > testsuite/tests/ffi/should_run/PrimFFIWord16_c.c | 7 + > testsuite/tests/ffi/should_run/all.T | 4 + > testsuite/tests/primops/should_run/ArithInt16.hs | 197 > +++++++++++++++++++++ > .../tests/primops/should_run/ArithInt16.stdout | 8 + > testsuite/tests/primops/should_run/ArithWord16.hs | 194 > ++++++++++++++++++++ > .../tests/primops/should_run/ArithWord16.stdout | 8 + > .../primops/should_run/{CmpInt8.hs => CmpInt16.hs} | 34 ++-- > .../should_run/{CmpInt8.stdout => CmpInt16.stdout} | 0 > .../should_run/{CmpWord8.hs => CmpWord16.hs} | 34 ++-- > .../{CmpInt8.stdout => CmpWord16.stdout} | 0 > testsuite/tests/primops/should_run/ShowPrim.hs | 16 +- > testsuite/tests/primops/should_run/ShowPrim.stdout | 3 +- > testsuite/tests/primops/should_run/all.T | 5 + > utils/genprimopcode/Main.hs | 4 +- > 34 files changed, 809 insertions(+), 116 deletions(-) > > Diff suppressed because of size. To see it, use: > > git diff-tree --root --patch-with-stat --no-color --find-copies-harder > --ignore-space-at-eol --cc 36fcf9edee31513db2ddbf716ee0aa79766cbe69 > _______________________________________________ > ghc-commits mailing list > ghc-commits at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-commits > From omeragacan at gmail.com Sun Nov 18 13:44:52 2018 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Sun, 18 Nov 2018 16:44:52 +0300 Subject: More teststuite woes In-Reply-To: <283c95a1-3985-7396-1d03-aaaaae6678e9@well-typed.com> References: <283c95a1-3985-7396-1d03-aaaaae6678e9@well-typed.com> Message-ID: This isprobably not the same problem, but I also started to get an error today when running the test suite. I think the problem is with the test runner because if I directly run the test command that the test runner prints the test works as expected. Error reported during validate: Unexpected results from: TEST="T14052" ... Unexpected failures: /tmp/ghctest-_w8smutp/test spaces/perf/should_run/T14052.run T14052 [[Errno 2] No such file or directory: '/tmp/ghctest-_w8smutp/test spaces/perf/should_run/T14052.run/T14052.stats'] (ghci) If I run only this test I get a slightly different error: $ make test TEST=T14052 WAY=ghci ... Unexpected failures: perf/should_run/T14052.run T14052 [[Errno 2] No such file or directory: 'perf/should_run/T14052.run/T14052.stats'] (ghci) (note that the file path is different) However if I copy the command printed when running the test and run it the test works fine. $ HC="/home/omer/haskell/ghc/inplace/test spaces/ghc-stage2" HC_OPTS="-dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output " "/home/omer/haskell/ghc/inplace/test spaces/ghc-stage2" --interactive -v0 -ignore-dot-ghci -fno-ghci-history +RTS -I0.1 -RTS -fghci-leak-check -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output < T14052.script > T14052.out ... $ diff T14052.out T14052.stdout (output matches the expected output) Ömer David Eichmann , 18 Kas 2018 Paz, 01:40 tarihinde şunu yazdı: > > The exception is thrown by python's semaphore class. We are using it to limit the number of tests running concurrently, though I couldn't see anything obviously wrong with the relevant code. If possible, could you find out what `python --version` you have? > > David E > > > On 17/11/18 21:55, Simon Peyton Jones wrote: > > Hmm. The second run worked fine. That’s unhelpful from a debugging point of view, but it means I’m not stuck! > > > > Simon > > > > From: Simon Peyton Jones > Sent: 17 November 2018 17:57 > To: 'David Eichmann' > Cc: ghc-devs at haskell.org > Subject: RE: More teststuite woes > > > > I’ll try validating again to see if the same thing happens. > > Simon > > > > From: David Eichmann > Sent: 17 November 2018 16:48 > To: Simon Peyton Jones > Cc: ghc-devs at haskell.org > Subject: Re: More teststuite woes > > > > Hello Simon, > > I had a quick look into this today, and spoke a bit with Ben about it. We don't have a clear answer as to what is causing this at the moment. We'll have to look more into this early next week. > > > It means I can’t validate at all. > > So you've tried to validate multiple times? I.e. does the error happen deterministically or was it more of a one off event? > > - David E > > > > On 17/11/18 10:05, Simon Peyton Jones via ghc-devs wrote: > > David > > I got this error on Windows today. It’s during the testuite run of ‘sh validate’ > > =====> T7969(normal) 3998 of 6647 [0, 25, 1] > > cd "/c/Users/simonpj/AppData/Local/Temp/ghctest-b2z6dfqg/test spaces/rename/should_compile/T7969.run" && $MAKE -s --no-print-directory T7969 > > =====> T9127(normal) 3999 of 6647 [0, 25, 1] > > cd "/c/Users/simonpj/AppData/Local/Temp/ghctest-b2z6dfqg/test spaces/rename/should_compile/T9127.run" && "/c/code/HEAD/bindisttest/install dir/bin/ghc.exe" -c T9127.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output > > =====> T4426(normal) 4000 of 6647 [0, 25, 1] > > cd "/c/Users/simonpj/AppData/Local/Temp/ghctest-b2z6dfqg/test spaces/rename/should_compile/T4426.run" && "/c/code/HEAD/bindisttest/install dir/bin/ghc.exe" -c T4426.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output > > cd "/c/Users/simonpj/AppData/Local/Temp/ghctest-b2z6dfqg/test spaces/rename/should_compile/T5592.run" && ./T5592 > > =====> T9778(normal) 4001 of 6647 [0, 25, 1] > > cd "/c/Users/simonpj/AppData/Local/Temp/ghctest-b2z6dfqg/test spaces/rename/should_compile/T9778.run" && "/c/code/HEAD/bindisttest/install dir/bin/ghc.exe" -c T9778.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output -fwarn-unticked-promoted-constructors > > =====> T10816(normal) 4002 of 6647 [0, 25, 1] > > cd "/c/Users/simonpj/AppData/Local/Temp/ghctest-b2z6dfqg/test spaces/rename/should_compile/T10816.run" && "/c/code/HEAD/bindisttest/install dir/bin/ghc.exe" -c T10816.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output > > Traceback (most recent call last): > > File "/usr/lib/python3.6/threading.py", line 426, in acquire > > self._cond.wait(timeout) > > File "/usr/lib/python3.6/threading.py", line 287, in wait > > raise RuntimeError("cannot wait on un-acquired lock") > > RuntimeError: cannot wait on un-acquired lock > > > > During handling of the above exception, another exception occurred: > > > > Traceback (most recent call last): > > File "../driver/runtests.py", line 336, in > > oneTest(watcher) > > File "/c/code/HEAD/testsuite/driver/testlib.py", line 717, in > > thisTest = lambda watcher: runTest(watcher, myTestOpts, name, func, args) > > File "/c/code/HEAD/testsuite/driver/testlib.py", line 678, in runTest > > pool_sema.acquire() > > File "/usr/lib/python3.6/threading.py", line 429, in acquire > > rc = True > > File "/usr/lib/python3.6/threading.py", line 243, in __exit__ > > return self._lock.__exit__(*args) > > RuntimeError: release unlocked lock > > make: *** [../mk/test.mk:344: test] Error 1 > > make: Leaving directory '/c/code/HEAD/testsuite/tests' > > make: Entering directory '/c/code/HEAD/testsuite/tests/stage1' > > > > Does this ring any bells. It means I can’t validate at all. > > Thanks > > > > Simon > > > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://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 From trp at bluewin.ch Sun Nov 18 15:37:57 2018 From: trp at bluewin.ch (Peter Trommler) Date: Sun, 18 Nov 2018 16:37:57 +0100 Subject: [commit: ghc] master: Introduce Int16# and Word16# (36fcf9e) In-Reply-To: References: <20181117150345.08F463A8E4@ghc.haskell.org> Message-ID: <057D8385-4CE2-4059-BBAE-53BD14F7DE70@bluewin.ch> Hi Gabor, I sent a pull request with a fix to GHC on github. Cheers, Peter > On 18. Nov 2018, at 13:02, Gabor Greif wrote: > > Hello Abhiroop! > > LLVM backend seems to choke on this still: > > ghc-stage1: panic! (the 'impossible' happened) > (GHC version 8.7.20181118 for x86_64-unknown-linux): > LlvmCodeGen.CodeGen.cmmPrimOpFunctions: MO_S_QuotRem W16 not supported here > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > > Cheers, > > Gabor > > On 11/17/18, git at git.haskell.org wrote: >> Repository : ssh://git at git.haskell.org/ghc >> >> On branch : master >> Link : >> http://ghc.haskell.org/trac/ghc/changeset/36fcf9edee31513db2ddbf716ee0aa79766cbe69/ghc >> >>> --------------------------------------------------------------- >> >> commit 36fcf9edee31513db2ddbf716ee0aa79766cbe69 >> Author: Abhiroop Sarkar >> Date: Mon Nov 5 12:06:58 2018 -0500 >> >> Introduce Int16# and Word16# >> >> This builds off of D4475. >> >> Bumps binary submodule. >> >> Reviewers: carter, AndreasK, hvr, goldfire, bgamari, simonmar >> >> Subscribers: rwbarton, thomie >> >> Differential Revision: https://phabricator.haskell.org/D5006 >> >> >>> --------------------------------------------------------------- >> >> 36fcf9edee31513db2ddbf716ee0aa79766cbe69 >> compiler/cmm/CmmUtils.hs | 4 + >> compiler/codeGen/StgCmmArgRep.hs | 2 + >> compiler/codeGen/StgCmmPrim.hs | 45 +++++ >> compiler/prelude/PrelNames.hs | 115 ++++++------ >> compiler/prelude/TysPrim.hs | 22 ++- >> compiler/prelude/TysWiredIn.hs | 15 +- >> compiler/prelude/TysWiredIn.hs-boot | 1 + >> compiler/prelude/primops.txt.pp | 82 +++++++++ >> compiler/simplStg/RepType.hs | 2 + >> compiler/typecheck/TcGenDeriv.hs | 42 ++++- >> compiler/types/TyCon.hs | 4 + >> compiler/utils/Binary.hs | 4 + >> libraries/base/Data/Typeable/Internal.hs | 2 + >> libraries/binary | 2 +- >> libraries/ghc-prim/GHC/Types.hs | 6 +- >> testsuite/tests/ffi/should_run/PrimFFIInt16.hs | 28 +++ >> .../{PrimFFIInt8.stdout => PrimFFIInt16.stdout} | 0 >> testsuite/tests/ffi/should_run/PrimFFIInt16_c.c | 7 + >> testsuite/tests/ffi/should_run/PrimFFIWord16.hs | 28 +++ >> .../{PrimFFIInt8.stdout => PrimFFIWord16.stdout} | 0 >> testsuite/tests/ffi/should_run/PrimFFIWord16_c.c | 7 + >> testsuite/tests/ffi/should_run/all.T | 4 + >> testsuite/tests/primops/should_run/ArithInt16.hs | 197 >> +++++++++++++++++++++ >> .../tests/primops/should_run/ArithInt16.stdout | 8 + >> testsuite/tests/primops/should_run/ArithWord16.hs | 194 >> ++++++++++++++++++++ >> .../tests/primops/should_run/ArithWord16.stdout | 8 + >> .../primops/should_run/{CmpInt8.hs => CmpInt16.hs} | 34 ++-- >> .../should_run/{CmpInt8.stdout => CmpInt16.stdout} | 0 >> .../should_run/{CmpWord8.hs => CmpWord16.hs} | 34 ++-- >> .../{CmpInt8.stdout => CmpWord16.stdout} | 0 >> testsuite/tests/primops/should_run/ShowPrim.hs | 16 +- >> testsuite/tests/primops/should_run/ShowPrim.stdout | 3 +- >> testsuite/tests/primops/should_run/all.T | 5 + >> utils/genprimopcode/Main.hs | 4 +- >> 34 files changed, 809 insertions(+), 116 deletions(-) >> >> Diff suppressed because of size. To see it, use: >> >> git diff-tree --root --patch-with-stat --no-color --find-copies-harder >> --ignore-space-at-eol --cc 36fcf9edee31513db2ddbf716ee0aa79766cbe69 >> _______________________________________________ >> ghc-commits mailing list >> ghc-commits at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-commits >> > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From carter.schonwald at gmail.com Mon Nov 19 03:36:42 2018 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sun, 18 Nov 2018 22:36:42 -0500 Subject: [commit: ghc] master: Introduce Int16# and Word16# (36fcf9e) In-Reply-To: <057D8385-4CE2-4059-BBAE-53BD14F7DE70@bluewin.ch> References: <20181117150345.08F463A8E4@ghc.haskell.org> <057D8385-4CE2-4059-BBAE-53BD14F7DE70@bluewin.ch> Message-ID: thanks Peter! On Sun, Nov 18, 2018 at 10:38 AM Peter Trommler wrote: > Hi Gabor, > > I sent a pull request with a fix to GHC on github. > > Cheers, Peter > > > On 18. Nov 2018, at 13:02, Gabor Greif wrote: > > > > Hello Abhiroop! > > > > LLVM backend seems to choke on this still: > > > > ghc-stage1: panic! (the 'impossible' happened) > > (GHC version 8.7.20181118 for x86_64-unknown-linux): > > LlvmCodeGen.CodeGen.cmmPrimOpFunctions: MO_S_QuotRem W16 not > supported here > > > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > > > > Cheers, > > > > Gabor > > > > On 11/17/18, git at git.haskell.org wrote: > >> Repository : ssh://git at git.haskell.org/ghc > >> > >> On branch : master > >> Link : > >> > http://ghc.haskell.org/trac/ghc/changeset/36fcf9edee31513db2ddbf716ee0aa79766cbe69/ghc > >> > >>> --------------------------------------------------------------- > >> > >> commit 36fcf9edee31513db2ddbf716ee0aa79766cbe69 > >> Author: Abhiroop Sarkar > >> Date: Mon Nov 5 12:06:58 2018 -0500 > >> > >> Introduce Int16# and Word16# > >> > >> This builds off of D4475. > >> > >> Bumps binary submodule. > >> > >> Reviewers: carter, AndreasK, hvr, goldfire, bgamari, simonmar > >> > >> Subscribers: rwbarton, thomie > >> > >> Differential Revision: https://phabricator.haskell.org/D5006 > >> > >> > >>> --------------------------------------------------------------- > >> > >> 36fcf9edee31513db2ddbf716ee0aa79766cbe69 > >> compiler/cmm/CmmUtils.hs | 4 + > >> compiler/codeGen/StgCmmArgRep.hs | 2 + > >> compiler/codeGen/StgCmmPrim.hs | 45 +++++ > >> compiler/prelude/PrelNames.hs | 115 ++++++------ > >> compiler/prelude/TysPrim.hs | 22 ++- > >> compiler/prelude/TysWiredIn.hs | 15 +- > >> compiler/prelude/TysWiredIn.hs-boot | 1 + > >> compiler/prelude/primops.txt.pp | 82 +++++++++ > >> compiler/simplStg/RepType.hs | 2 + > >> compiler/typecheck/TcGenDeriv.hs | 42 ++++- > >> compiler/types/TyCon.hs | 4 + > >> compiler/utils/Binary.hs | 4 + > >> libraries/base/Data/Typeable/Internal.hs | 2 + > >> libraries/binary | 2 +- > >> libraries/ghc-prim/GHC/Types.hs | 6 +- > >> testsuite/tests/ffi/should_run/PrimFFIInt16.hs | 28 +++ > >> .../{PrimFFIInt8.stdout => PrimFFIInt16.stdout} | 0 > >> testsuite/tests/ffi/should_run/PrimFFIInt16_c.c | 7 + > >> testsuite/tests/ffi/should_run/PrimFFIWord16.hs | 28 +++ > >> .../{PrimFFIInt8.stdout => PrimFFIWord16.stdout} | 0 > >> testsuite/tests/ffi/should_run/PrimFFIWord16_c.c | 7 + > >> testsuite/tests/ffi/should_run/all.T | 4 + > >> testsuite/tests/primops/should_run/ArithInt16.hs | 197 > >> +++++++++++++++++++++ > >> .../tests/primops/should_run/ArithInt16.stdout | 8 + > >> testsuite/tests/primops/should_run/ArithWord16.hs | 194 > >> ++++++++++++++++++++ > >> .../tests/primops/should_run/ArithWord16.stdout | 8 + > >> .../primops/should_run/{CmpInt8.hs => CmpInt16.hs} | 34 ++-- > >> .../should_run/{CmpInt8.stdout => CmpInt16.stdout} | 0 > >> .../should_run/{CmpWord8.hs => CmpWord16.hs} | 34 ++-- > >> .../{CmpInt8.stdout => CmpWord16.stdout} | 0 > >> testsuite/tests/primops/should_run/ShowPrim.hs | 16 +- > >> testsuite/tests/primops/should_run/ShowPrim.stdout | 3 +- > >> testsuite/tests/primops/should_run/all.T | 5 + > >> utils/genprimopcode/Main.hs | 4 +- > >> 34 files changed, 809 insertions(+), 116 deletions(-) > >> > >> Diff suppressed because of size. To see it, use: > >> > >> git diff-tree --root --patch-with-stat --no-color > --find-copies-harder > >> --ignore-space-at-eol --cc 36fcf9edee31513db2ddbf716ee0aa79766cbe69 > >> _______________________________________________ > >> ghc-commits mailing list > >> ghc-commits at haskell.org > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-commits > >> > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://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 simonpj at microsoft.com Mon Nov 19 14:53:17 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 19 Nov 2018 14:53:17 +0000 Subject: split_marker crash Message-ID: Urrgh. I have this panic in a clean validate (sh validate -fast) on my branch wip/T15809. ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.7.20181119 for x86_64-unknown-linux): split_marker_entry Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug libraries/ghc-prim/ghc.mk:4: recipe for target 'libraries/ghc-prim/dist-install/build/GHC/Types.o' failed Yes, it's a branch not identical to HEAD, but I have done nothing concerning split_markers. Sigh. What should I do? Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Nov 19 17:15:24 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 19 Nov 2018 17:15:24 +0000 Subject: split_marker crash In-Reply-To: References: Message-ID: OK I have verified that * This split_marker crash happens on a clean HEAD build * Reverting "NCG: New code layout algorithm.", 575515b4909f3d77b3d31f2f6c22d14a92d8b8e0, solves the problem. Andreas: I propose to revert in HEAD unless you have a rapid fix, or believe that is somehow my fault. (Or maybe someone else can revert.) Simon From: Simon Peyton Jones Sent: 19 November 2018 14:53 To: 'ghc-devs at haskell.org' Subject: split_marker crash Urrgh. I have this panic in a clean validate (sh validate -fast) on my branch wip/T15809. ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.7.20181119 for x86_64-unknown-linux): split_marker_entry Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug libraries/ghc-prim/ghc.mk:4: recipe for target 'libraries/ghc-prim/dist-install/build/GHC/Types.o' failed Yes, it's a branch not identical to HEAD, but I have done nothing concerning split_markers. Sigh. What should I do? Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Mon Nov 19 18:05:37 2018 From: ben at smart-cactus.org (Ben Gamari) Date: Mon, 19 Nov 2018 13:05:37 -0500 Subject: split_marker crash In-Reply-To: References: Message-ID: <87d0r1eyds.fsf@smart-cactus.org> Simon Peyton Jones via ghc-devs writes: > OK I have verified that > > * This split_marker crash happens on a clean HEAD build > * Reverting "NCG: New code layout algorithm.", 575515b4909f3d77b3d31f2f6c22d14a92d8b8e0, solves the problem. > Andreas: I propose to revert in HEAD unless you have a rapid fix, or believe that is somehow my fault. > (Or maybe someone else can revert.) Simon, are you using split-objs by any chance? Regardless, yes, let's revert until we work out what is going on here. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From klebinger.andreas at gmx.at Mon Nov 19 19:32:32 2018 From: klebinger.andreas at gmx.at (Andreas Klebinger) Date: Mon, 19 Nov 2018 20:32:32 +0100 Subject: split_marker crash In-Reply-To: <87d0r1eyds.fsf@smart-cactus.org> References: <87d0r1eyds.fsf@smart-cactus.org> Message-ID: <5BF30FD0.2040803@gmx.at> Hello, I'm fine with reverting for now. But could you give me a way to reproduce this error? I've not seen crashes on either linux and windows in various configs. Cheers, Andreas Ben Gamari schrieb: > Simon Peyton Jones via ghc-devs writes: > >> OK I have verified that >> >> * This split_marker crash happens on a clean HEAD build >> * Reverting "NCG: New code layout algorithm.", 575515b4909f3d77b3d31f2f6c22d14a92d8b8e0, solves the problem. >> Andreas: I propose to revert in HEAD unless you have a rapid fix, or believe that is somehow my fault. >> (Or maybe someone else can revert.) > > Simon, are you using split-objs by any chance? > > Regardless, yes, let's revert until we work out what is going on here. > > Cheers, > > - Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Mon Nov 19 20:33:12 2018 From: ben at well-typed.com (Ben Gamari) Date: Mon, 19 Nov 2018 15:33:12 -0500 Subject: split_marker crash In-Reply-To: <5BF30FD0.2040803@gmx.at> References: <87d0r1eyds.fsf@smart-cactus.org> <5BF30FD0.2040803@gmx.at> Message-ID: <8736rwg64b.fsf@smart-cactus.org> Andreas Klebinger writes: > Hello, > > I'm fine with reverting for now. But could you give me a way to > reproduce this error? > > I've not seen crashes on either linux and windows in various configs. > I suspect that Simon is building with SplitObjects enabled. To be honest, I would really like to remove this feature; SplitSections is better in nearly every regard. However, we have been stalled since SplitSections doesn't quite work yet on Windows (or, IIRC, the toolchain is prohibitively slow when it's used). I believe Tamar was working on fixing this. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From klebinger.andreas at gmx.at Mon Nov 19 20:37:41 2018 From: klebinger.andreas at gmx.at (Andreas Klebinger) Date: Mon, 19 Nov 2018 21:37:41 +0100 Subject: split_marker crash In-Reply-To: <8736rwg64b.fsf@smart-cactus.org> References: <87d0r1eyds.fsf@smart-cactus.org> <5BF30FD0.2040803@gmx.at> <8736rwg64b.fsf@smart-cactus.org> Message-ID: <5BF31F15.2050400@gmx.at> I might already have found the specific cause. It seems with split sections we generate a dummy CmmProc, which has as entry label > error (split_sections_entry) My patch likely introduces strictness on that field where it was lazy before. If this is the cause I expect to have a patch up in a hour or two and will merge it after it validates. Cheers, Andreas Ben Gamari schrieb: > Andreas Klebinger writes: > >> Hello, >> >> I'm fine with reverting for now. But could you give me a way to >> reproduce this error? >> >> I've not seen crashes on either linux and windows in various configs. >> > I suspect that Simon is building with SplitObjects enabled. To be > honest, I would really like to remove this feature; SplitSections is > better in nearly every regard. However, we have been stalled since > SplitSections doesn't quite work yet on Windows (or, IIRC, the toolchain > is prohibitively slow when it's used). I believe Tamar was working on > fixing this. > > Cheers, > > - Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Nov 19 20:49:55 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 19 Nov 2018 20:49:55 +0000 Subject: Force-push Message-ID: Devs When I rebase wip/T15809 (which has about 40 patches on it), and force-push, it generate a lot of Trac mail. Sorry about this. I don't know how I can make that not-happen. You can safely delete it! Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Mon Nov 19 20:50:21 2018 From: ben at well-typed.com (Ben Gamari) Date: Mon, 19 Nov 2018 15:50:21 -0500 Subject: split_marker crash In-Reply-To: <5BF31F15.2050400@gmx.at> References: <87d0r1eyds.fsf@smart-cactus.org> <5BF30FD0.2040803@gmx.at> <8736rwg64b.fsf@smart-cactus.org> <5BF31F15.2050400@gmx.at> Message-ID: <87wop8eqr9.fsf@smart-cactus.org> Andreas Klebinger writes: > I might already have found the specific cause. > > It seems with split sections we generate a dummy CmmProc, which has as > entry label > > error (split_sections_entry) > > My patch likely introduces strictness on that field where it was lazy > before. If this is the cause I expect to have a patch up in a hour or > two and will merge it after it validates. > Ahhh, yes, that sounds like it may be the culprit. Good sleuthing! Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From simonpj at microsoft.com Mon Nov 19 20:53:50 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 19 Nov 2018 20:53:50 +0000 Subject: split_marker crash In-Reply-To: <5BF31F15.2050400@gmx.at> References: <87d0r1eyds.fsf@smart-cactus.org> <5BF30FD0.2040803@gmx.at> <8736rwg64b.fsf@smart-cactus.org> <5BF31F15.2050400@gmx.at> Message-ID: I do indeed have SplitObs=YES in my validate.mk. In the past at least, that made binaries quite a bit smaller. Happy to change it to SplitSections=YES if that is more kosher these days? Simon From: Andreas Klebinger Sent: 19 November 2018 20:38 To: Ben Gamari Cc: Phyx ; Simon Peyton Jones ; ghc-devs at haskell.org Subject: Re: split_marker crash I might already have found the specific cause. It seems with split sections we generate a dummy CmmProc, which has as entry label > error (split_sections_entry) My patch likely introduces strictness on that field where it was lazy before. If this is the cause I expect to have a patch up in a hour or two and will merge it after it validates. Cheers, Andreas Ben Gamari schrieb: Andreas Klebinger writes: Hello, I'm fine with reverting for now. But could you give me a way to reproduce this error? I've not seen crashes on either linux and windows in various configs. I suspect that Simon is building with SplitObjects enabled. To be honest, I would really like to remove this feature; SplitSections is better in nearly every regard. However, we have been stalled since SplitSections doesn't quite work yet on Windows (or, IIRC, the toolchain is prohibitively slow when it's used). I believe Tamar was working on fixing this. Cheers, - Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From lonetiger at gmail.com Mon Nov 19 20:57:59 2018 From: lonetiger at gmail.com (Phyx) Date: Mon, 19 Nov 2018 20:57:59 +0000 Subject: split_marker crash In-Reply-To: <8736rwg64b.fsf@smart-cactus.org> References: <87d0r1eyds.fsf@smart-cactus.org> <5BF30FD0.2040803@gmx.at> <8736rwg64b.fsf@smart-cactus.org> Message-ID: On Mon, Nov 19, 2018 at 8:33 PM Ben Gamari wrote: > Andreas Klebinger writes: > > > Hello, > > > > I'm fine with reverting for now. But could you give me a way to > > reproduce this error? > > > > I've not seen crashes on either linux and windows in various configs. > > > I suspect that Simon is building with SplitObjects enabled. To be > honest, I would really like to remove this feature; SplitSections is > better in nearly every regard. However, we have been stalled since > SplitSections doesn't quite work yet on Windows (or, IIRC, the toolchain > is prohibitively slow when it's used). I believe Tamar was working on > fixing this. > SplitObjects has been off in favor of SplitSections on Windows since Aug. https://github.com/ghc/ghc/commit/23774c98f1368b41515cbd5223b87ea6dbf644e1 SplitObjects is not usable on Windows anymore so it was disabled https://ghc.haskell.org/trac/ghc/ticket/15051 > Cheers, > > - Ben > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lonetiger at gmail.com Mon Nov 19 21:02:17 2018 From: lonetiger at gmail.com (Phyx) Date: Mon, 19 Nov 2018 21:02:17 +0000 Subject: split_marker crash In-Reply-To: References: <87d0r1eyds.fsf@smart-cactus.org> <5BF30FD0.2040803@gmx.at> <8736rwg64b.fsf@smart-cactus.org> <5BF31F15.2050400@gmx.at> Message-ID: On Mon, Nov 19, 2018 at 8:53 PM Simon Peyton Jones wrote: > I do indeed have SplitObs=YES in my validate.mk. > > In the past at least, that made binaries quite a bit smaller. > > Happy to change it to SplitSections=YES if that is more kosher these days? > Yes, SplitObjs is no longer supported, will also cause an extremely slow compilation depending on your optimization level and ways. Removing the line should let the compiler default to the best choice, in this case it should go to SplitSections on its own when compiling stage2. Regards, Tamar > > Simon > > > > *From:* Andreas Klebinger > *Sent:* 19 November 2018 20:38 > *To:* Ben Gamari > *Cc:* Phyx ; Simon Peyton Jones < > simonpj at microsoft.com>; ghc-devs at haskell.org > *Subject:* Re: split_marker crash > > > > I might already have found the specific cause. > > It seems with split sections we generate a dummy CmmProc, which has as > entry label > > error (split_sections_entry) > > My patch likely introduces strictness on that field where it was lazy > before. > If this is the cause I expect to have a patch up in a hour or two and will > merge > it after it validates. > > Cheers, > Andreas > > Ben Gamari schrieb: > > Andreas Klebinger writes: > > > > Hello, > > > > I'm fine with reverting for now. But could you give me a way to > > reproduce this error? > > > > I've not seen crashes on either linux and windows in various configs. > > > > I suspect that Simon is building with SplitObjects enabled. To be > > honest, I would really like to remove this feature; SplitSections is > > better in nearly every regard. However, we have been stalled since > > SplitSections doesn't quite work yet on Windows (or, IIRC, the toolchain > > is prohibitively slow when it's used). I believe Tamar was working on > > fixing this. > > > > Cheers, > > > > - Ben > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Mon Nov 19 21:04:11 2018 From: ben at well-typed.com (Ben Gamari) Date: Mon, 19 Nov 2018 16:04:11 -0500 Subject: split_marker crash In-Reply-To: References: <87d0r1eyds.fsf@smart-cactus.org> <5BF30FD0.2040803@gmx.at> <8736rwg64b.fsf@smart-cactus.org> <5BF31F15.2050400@gmx.at> Message-ID: <87r2fgeq46.fsf@smart-cactus.org> Simon Peyton Jones via ghc-devs writes: > I do indeed have SplitObs=YES in my validate.mk. > Ahh, so perhaps Andreas's finding isn't the culprit afterall. Looking at the source it looks like `split_marker_entry` is indeed emitted for split objects support.c > In the past at least, that made binaries quite a bit smaller. > Happy to change it to SplitSections=YES if that is more kosher these days? > We generally recommend SplitSections at this point. Not only is it simpler, but it may reduce build times, result in smaller binaries, and generally stays closer to what C compilers do, avoiding toolchain bugs. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ben at well-typed.com Mon Nov 19 21:06:08 2018 From: ben at well-typed.com (Ben Gamari) Date: Mon, 19 Nov 2018 16:06:08 -0500 Subject: split_marker crash In-Reply-To: References: <87d0r1eyds.fsf@smart-cactus.org> <5BF30FD0.2040803@gmx.at> <8736rwg64b.fsf@smart-cactus.org> Message-ID: <87o9akeq0y.fsf@smart-cactus.org> Phyx writes: > On Mon, Nov 19, 2018 at 8:33 PM Ben Gamari wrote: > >> Andreas Klebinger writes: >> >> > Hello, >> > >> > I'm fine with reverting for now. But could you give me a way to >> > reproduce this error? >> > >> > I've not seen crashes on either linux and windows in various configs. >> > >> I suspect that Simon is building with SplitObjects enabled. To be >> honest, I would really like to remove this feature; SplitSections is >> better in nearly every regard. However, we have been stalled since >> SplitSections doesn't quite work yet on Windows (or, IIRC, the toolchain >> is prohibitively slow when it's used). I believe Tamar was working on >> fixing this. >> > > SplitObjects has been off in favor of SplitSections on Windows since Aug. > https://github.com/ghc/ghc/commit/23774c98f1368b41515cbd5223b87ea6dbf644e1 > Ahh, I had forgotten about this. I'll need to check this when I'm back home but I suspect this means that we can finally rip out (or at least deprecate) split object support for 8.8. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From carter.schonwald at gmail.com Tue Nov 20 02:06:55 2018 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Mon, 19 Nov 2018 21:06:55 -0500 Subject: ghc 8.6.x release clearly fails validate or even make test, some help please! Message-ID: Hey Everyone ... I'm concerned, it looks like ghc 8.6.2 on OSX doens't pass validate or even a rudimentary `make test` I'm not sure how to make heads or tails of all these errors, and it looks like a huge amount of dev work over time has accumulated some failures .... could the code owners on these sub systems at least help me make heads or tails of these errors? SUMMARY for test run started at Mon Nov 19 19:48:18 2018 EST 0:28:32 spent to go through 6516 total tests, which gave rise to 25425 test cases, of which 18538 were skipped 41 had missing libraries 6380 expected passes 92 expected failures 2 caused framework failures 0 caused framework warnings 0 unexpected passes 365 unexpected failures 7 unexpected stat failures Unexpected failures: backpack/cabal/bkpcabal05/bkpcabal05.run bkpcabal05 [bad stderr] (normal) backpack/cabal/bkpcabal02/bkpcabal02.run bkpcabal02 [bad stderr] (normal) backpack/cabal/bkpcabal06/bkpcabal06.run bkpcabal06 [bad stderr] (normal) backpack/cabal/bkpcabal04/bkpcabal04.run bkpcabal04 [bad stderr] (normal) backpack/cabal/bkpcabal07/bkpcabal07.run bkpcabal07 [bad stderr] (normal) backpack/cabal/bkpcabal03/bkpcabal03.run bkpcabal03 [bad stderr] (normal) backpack/cabal/T14304/T14304.run T14304 [bad stderr] (normal) cabal/T12485/T12485.run T12485 [bad stderr] (normal) backpack/cabal/bkpcabal01/bkpcabal01.run bkpcabal01 [bad stderr] (normal) cabal/cabal04/cabal04.run cabal04 [bad stderr] (normal) cabal/T12733/T12733.run T12733 [bad stderr] (normal) cabal/cabal01/cabal01.run cabal01 [bad stderr] (normal) cabal/cabal09/cabal09.run cabal09 [bad stderr] (normal) cabal/cabal03/cabal03.run cabal03 [bad stderr] (normal) codeGen/should_compile/T2578.run T2578 [bad stderr] (normal) cabal/cabal08/cabal08.run cabal08 [bad stderr] (normal) codeGen/should_compile/debug.run debug [bad stderr] (normal) cabal/cabal05/cabal05.run cabal05 [bad stderr] (normal) cabal/cabal06/cabal06.run cabal06 [bad stderr] (normal) deSugar/should_run/T5522.run T5522 [stderr mismatch] (optasm) driver/driver062a.run driver062a [bad stderr] (normal) driver/driver062b.run driver062b [bad stderr] (normal) driver/driver062c.run driver062c [bad stderr] (normal) driver/driver062d.run driver062d [bad stderr] (normal) driver/driver062e.run driver062e [bad stderr] (normal) driver/driver081a.run driver081a [bad stderr] (normal) driver/driver081b.run driver081b [bad stderr] (normal) driver/rtsopts002.run rtsopts002 [bad stderr] (normal) driver/T3674.run T3674 [bad stderr] (normal) driver/rtsopts001.run rtsopts001 [bad stderr] (normal) driver/withRtsOpts.run withRtsOpts [bad stderr] (normal) driver/T703.run T703 [bad stderr] (normal) driver/T5313.run T5313 [bad exit code] (normal) driver/T9938.run T9938 [bad stderr] (normal) driver/T9938B.run T9938B [bad stderr] (normal) driver/T12971.run T12971 [bad stderr] (normal) driver/T10320.run T10320 [bad stderr] (normal) driver/T7835/T7835.run T7835 [bad stderr] (normal) driver/T437/T437.run T437 [bad stderr] (normal) driver/T13914/T13914.run T13914 [bad stderr] (normal) driver/T1959/T1959.run T1959 [bad stderr] (normal) driver/dynamic_flags_001/dynamic_flags_001.run dynamic_flags_001 [bad stderr] (normal) driver/dynamicToo/dynamicToo001/dynamicToo001.run dynamicToo001 [bad stderr] (normal) driver/recomp001/recomp001.run recomp001 [bad stderr] (normal) driver/linkwhole/linkwhole.run linkwhole [bad stderr] (normal) driver/T3007/T3007.run T3007 [bad stderr] (normal) driver/recomp004/recomp004.run recomp004 [bad stderr] (normal) driver/T1372/T1372.run T1372 [bad stderr] (normal) driver/recomp010/recomp010.run recomp010 [bad stderr] (normal) driver/recomp008/recomp008.run recomp008 [bad stderr] (normal) driver/recomp012/recomp012.run recomp012 [bad stderr] (normal) driver/recomp011/recomp011.run recomp011 [bad stderr] (normal) driver/recomp007/recomp007.run recomp007 [bad stderr] (normal) ffi/should_run/Capi_Ctype_002.run Capi_Ctype_002 [bad stderr] (normal) ffi/should_run/Capi_Ctype_001.run Capi_Ctype_001 [bad stderr] (normal) gadt/gadt23.run gadt23 [bad stderr] (normal) ghc-api/T10508_api.run T10508_api [bad exit code] (normal) ghc-api/T8628.run T8628 [bad exit code] (normal) ghc-api/T6145.run T6145 [bad stderr] (normal) ghc-api/T8639_api.run T8639_api [bad exit code] (normal) ghc-api/T10052/T10052.run T10052 [bad exit code] (normal) ghc-api/T4891/T4891.run T4891 [bad stderr] (normal) ghc-api/T7478/T7478.run T7478 [bad stderr] (normal) ghc-api/dynCompileExpr/dynCompileExpr.run dynCompileExpr [bad exit code] (normal) ghc-api/show-srcspan/showsrcspan.run showsrcspan [bad stderr] (normal) ghc-api/annotations-literals/literals.run literals [bad stderr] (normal) ghc-api/annotations-literals/parsed.run parsed [bad stderr] (normal) ghci/linking/dyn/T10955dyn.run T10955dyn [bad stderr] (normal) ghci/prog001/prog001.run prog001 [bad exit code] (ghci-ext) ghci/scripts/ghci063.run ghci063 [bad stderr] (ghci) ghci/scripts/ghci062.run ghci062 [bad exit code] (ghci-ext) hsc2hs/hsc2hs003.run hsc2hs003 [bad stderr] (normal) hsc2hs/hsc2hs004.run hsc2hs004 [bad stderr] (normal) hsc2hs/T4340.run T4340 [bad stderr] (normal) hsc2hs/T10272.run T10272 [bad stderr] (normal) lib/integer/integerConstantFolding.run integerConstantFolding [bad stderr] (normal) module/mod179.run mod179 [stderr mismatch] (normal) numeric/should_compile/T7116.run T7116 [bad stdout] (normal) numeric/should_compile/T14170.run T14170 [bad stdout] (normal) numeric/should_compile/T14465.run T14465 [bad stdout] (normal) module/mod175/mod175.run mod175 [bad stderr] (normal) numeric/should_run/T7014.run T7014 [bad stderr] (normal) parser/should_compile/T5243.run T5243 [stderr mismatch] (normal) parser/should_compile/T7476/T7476.run T7476 [bad stderr] (normal) patsyn/should_compile/T13350/T13350.run T13350 [bad stderr] (normal) perf/should_run/T3736.run T3736 [bad stderr] (normal) perf/should_run/T149.run T149 [bad stderr] (normal) perf/should_run/T2902.run T2902 [bad stderr] (normal) plugins/plugin-recomp-change.run plugin-recomp-change [bad stderr] (normal) plugins/plugin-recomp-change-prof.run plugin-recomp-change-prof [bad stderr] (normal) programs/hs-boot/hs-boot.run hs-boot [stderr mismatch] (normal) rename/prog006/rn.prog006.run rn.prog006 [bad stderr] (normal) rename/should_compile/T15149.run T15149 [stderr mismatch] (normal) rts/outofmem2.run outofmem2 [bad stderr] (normal) rts/T4059.run T4059 [bad stderr] (normal) rts/T4850.run T4850 [bad stderr] (normal) rts/T5423.run T5423 [bad stderr] (normal) rts/T5435_v_asm_a.run T5435_v_asm_a [bad stderr] (normal) rts/T5435_v_gcc.run T5435_v_gcc [bad stderr] (normal) rts/T5435_dyn_asm.run T5435_dyn_asm [bad stderr] (normal) rts/T5435_dyn_gcc.run T5435_dyn_gcc [bad stderr] (normal) rts/T7037.run T7037 [bad stderr] (normal) rts/linker_unload.run linker_unload [bad exit code] (normal) rts/T9405.run T9405 [bad stderr] (normal) rts/T10296a.run T10296a [bad stderr] (normal) rts/T1791/T1791.run T1791 [bad stderr] (normal) rts/T8308/T8308.run T8308 [bad stderr] (normal) rts/T9579/T9579_stackoverflow_rtsnone.run T9579_stackoverflow_rtsnone [bad stderr] (normal) rts/T9579/T9579_stackoverflow_rtssome.run T9579_stackoverflow_rtssome [bad stderr] (normal) rts/T9579/T9579_stackoverflow_rtsall.run T9579_stackoverflow_rtsall [bad stderr] (normal) rts/T9579/T9579_stackoverflow_rtsall_no_suggestions.run T9579_stackoverflow_rtsall_no_suggestions [bad stderr] (normal) rts/T9579/T9579_outofheap_rtsnone.run T9579_outofheap_rtsnone [bad stderr] (normal) rts/T9579/T9579_outofheap_rtssome.run T9579_outofheap_rtssome [bad stderr] (normal) rts/T9579/T9579_outofheap_rtsall.run T9579_outofheap_rtsall [bad stderr] (normal) rts/T9579/T9579_outofheap_rtsall_no_suggestions.run T9579_outofheap_rtsall_no_suggestions [bad stderr] (normal) safeHaskell/check/Check04.run Check04 [stderr mismatch] (normal) safeHaskell/check/pkg01/safePkg01.run safePkg01 [bad stderr] (normal) simplCore/should_compile/T3717.run T3717 [stderr mismatch] (optasm) simplCore/should_compile/spec-inline.run spec-inline [stderr mismatch] (optasm) simplCore/should_compile/T4908.run T4908 [stderr mismatch] (optasm) simplCore/should_compile/T4930.run T4930 [stderr mismatch] (optasm) simplCore/should_compile/T3772.run T3772 [bad stdout] (normal) simplCore/should_compile/T4918.run T4918 [bad stdout] (normal) simplCore/should_compile/T7360.run T7360 [stderr mismatch] (optasm) simplCore/should_compile/T8832.run T8832 [bad stdout] (normal) simplCore/should_compile/T12076.run T12076 [stderr mismatch] (normal) simplCore/should_compile/par01.run par01 [stderr mismatch] (optasm) simplCore/should_compile/T13143.run T13143 [stderr mismatch] (optasm) simplCore/should_compile/T12603.run T12603 [bad stdout] (normal) simplCore/should_compile/str-rules.run str-rules [bad stdout] (normal) simplCore/should_compile/T14186.run T14186 [stderr mismatch] (optasm) th/TH_overloadedlabels.run TH_overloadedlabels [exit code non-0] (ext-interp) th/TH_mkName.run TH_mkName [exit code non-0] (ext-interp) th/TH_1tuple.run TH_1tuple [stderr mismatch] (ext-interp) th/TH_repPrim.run TH_repPrim [exit code non-0] (ext-interp) th/TH_repPrim2.run TH_repPrim2 [exit code non-0] (ext-interp) th/TH_repUnboxedTuples.run TH_repUnboxedTuples [exit code non-0] (ext-interp) th/TH_repE2.run TH_repE2 [exit code non-0] (ext-interp) th/TH_spliceGuard.run TH_spliceGuard [exit code non-0] (ext-interp) th/TH_repGuard.run TH_repGuard [exit code non-0] (ext-interp) th/TH_repPrimOutput.run TH_repPrimOutput [exit code non-0] (ext-interp) th/TH_repPrimOutput2.run TH_repPrimOutput2 [exit code non-0] (ext-interp) th/TH_repGuardOutput.run TH_repGuardOutput [exit code non-0] (ext-interp) th/TH_overlaps.run TH_overlaps [exit code non-0] (ext-interp) th/TH_spliceE6.run TH_spliceE6 [exit code non-0] (ext-interp) th/TH_spliceD2.run TH_spliceD2 [exit code non-0] (ext-interp) th/TH_reifyDecl1.run TH_reifyDecl1 [exit code non-0] (ext-interp) th/TH_reifyDecl2.run TH_reifyDecl2 [exit code non-0] (ext-interp) th/TH_reifyLocalDefs.run TH_reifyLocalDefs [exit code non-0] (ext-interp) th/TH_reifyLocalDefs2.run TH_reifyLocalDefs2 [exit code non-0] (ext-interp) th/TH_reifyMkName.run TH_reifyMkName [exit code non-0] (ext-interp) th/TH_reifyInstances.run TH_reifyInstances [exit code non-0] (ext-interp) th/TH_spliceDecl1.run TH_spliceDecl1 [exit code non-0] (ext-interp) th/TH_spliceDecl2.run TH_spliceDecl2 [exit code non-0] (ext-interp) th/TH_spliceE1.run TH_spliceE1 [exit code non-0] (ext-interp) th/TH_spliceExpr1.run TH_spliceExpr1 [exit code non-0] (ext-interp) th/TH_class1.run TH_class1 [exit code non-0] (ext-interp) th/TH_spliceE3.run TH_spliceE3 [exit code non-0] (ext-interp) th/TH_tuple1.run TH_tuple1 [exit code non-0] (ext-interp) th/TH_spliceE4.run TH_spliceE4 [exit code non-0] (ext-interp) th/TH_spliceInst.run TH_spliceInst [exit code non-0] (ext-interp) th/TH_exn1.run TH_exn1 [stderr mismatch] (ext-interp) th/TH_dupdecl.run TH_dupdecl [stderr mismatch] (ext-interp) th/TH_exn2.run TH_exn2 [stderr mismatch] (ext-interp) th/TH_fail.run TH_fail [stderr mismatch] (ext-interp) th/TH_scopedTvs.run TH_scopedTvs [exit code non-0] (ext-interp) th/TH_recover.run TH_recover [exit code non-0] (ext-interp) th/TH_runIO.run TH_runIO [stderr mismatch] (ext-interp) th/TH_linePragma.run TH_linePragma [stderr mismatch] (ext-interp) th/T2700.run T2700 [exit code non-0] (ext-interp) th/T2817.run T2817 [exit code non-0] (ext-interp) th/T2713.run T2713 [stderr mismatch] (ext-interp) th/T2674.run T2674 [stderr mismatch] (ext-interp) th/TH_emptycase.run TH_emptycase [exit code non-0] (ext-interp) th/TH_sections.run TH_sections [exit code non-0] (ext-interp) th/TH_tf1.run TH_tf1 [exit code non-0] (ext-interp) th/TH_tf3.run TH_tf3 [exit code non-0] (ext-interp) th/TH_pragma.run TH_pragma [exit code non-0] (ext-interp) th/T3177.run T3177 [exit code non-0] (ext-interp) th/T3177a.run T3177a [stderr mismatch] (ext-interp) th/T3319.run T3319 [exit code non-0] (ext-interp) th/TH_foreignInterruptible.run TH_foreignInterruptible [exit code non-0] (ext-interp) th/TH_foreignCallingConventions.run TH_foreignCallingConventions [exit code non-0] (ext-interp) th/T3395.run T3395 [stderr mismatch] (ext-interp) th/T3100.run T3100 [exit code non-0] (ext-interp) th/T3920.run T3920 [exit code non-0] (ext-interp) th/T4188.run T4188 [exit code non-0] (ext-interp) th/T4436.run T4436 [exit code non-0] (ext-interp) th/T1835.run T1835 [exit code non-0] (ext-interp) th/T5217.run T5217 [exit code non-0] (ext-interp) th/T5037.run T5037 [exit code non-0] (ext-interp) th/TH_unboxedSingleton.run TH_unboxedSingleton [exit code non-0] (ext-interp) th/T5290.run T5290 [exit code non-0] (ext-interp) th/T5362.run T5362 [exit code non-0] (ext-interp) th/TH_unresolvedInfix2.run TH_unresolvedInfix2 [stderr mismatch] (ext-interp) th/T5358.run T5358 [stderr mismatch] (ext-interp) th/T5404.run T5404 [exit code non-0] (ext-interp) th/T5452.run T5452 [exit code non-0] (ext-interp) th/T5379.run T5379 [exit code non-0] (ext-interp) th/T5410.run T5410 [exit code non-0] (ext-interp) th/T5508.run T5508 [exit code non-0] (ext-interp) th/TH_PromotedTuple.run TH_PromotedTuple [exit code non-0] (ext-interp) th/TH_PromotedList.run TH_PromotedList [exit code non-0] (ext-interp) th/TH_Promoted1Tuple.run TH_Promoted1Tuple [stderr mismatch] (ext-interp) th/TH_RichKinds2.run TH_RichKinds2 [exit code non-0] (ext-interp) th/TH_RichKinds.run TH_RichKinds [exit code non-0] (ext-interp) th/T5882.run T5882 [exit code non-0] (ext-interp) th/T5883.run T5883 [exit code non-0] (ext-interp) th/T1541.run T1541 [exit code non-0] (ext-interp) th/T4135.run T4135 [exit code non-0] (ext-interp) th/T5968.run T5968 [exit code non-0] (ext-interp) th/T5971.run T5971 [stderr mismatch] (ext-interp) th/T5976.run T5976 [stderr mismatch] (ext-interp) th/T6005.run T6005 [exit code non-0] (ext-interp) th/T6005a.run T6005a [exit code non-0] (ext-interp) th/T6114.run T6114 [exit code non-0] (ext-interp) th/TH_TyInstWhere1.run TH_TyInstWhere1 [exit code non-0] (ext-interp) th/TH_StringPrimL.run TH_StringPrimL [exit code non-0] (ext-interp) th/TH_TyInstWhere2.run TH_TyInstWhere2 [exit code non-0] (ext-interp) th/T2222.run T2222 [exit code non-0] (ext-interp) th/T7681.run T7681 [exit code non-0] (ext-interp) th/ClosedFam1TH.run ClosedFam1TH [exit code non-0] (ext-interp) th/ClosedFam2TH.run ClosedFam2TH [exit code non-0] (ext-interp) th/T7910.run T7910 [exit code non-0] (ext-interp) th/TH_Roles1.run TH_Roles1 [stderr mismatch] (ext-interp) th/TH_Roles2.run TH_Roles2 [exit code non-0] (ext-interp) th/TH_Roles3.run TH_Roles3 [exit code non-0] (ext-interp) th/TH_Roles4.run TH_Roles4 [exit code non-0] (ext-interp) th/T4124.run T4124 [exit code non-0] (ext-interp) th/T4128.run T4128 [exit code non-0] (ext-interp) th/T4364.run T4364 [exit code non-0] (ext-interp) th/T8412.run T8412 [stderr mismatch] (ext-interp) th/T8186.run T8186 [exit code non-0] (ext-interp) th/T7667.run T7667 [exit code non-0] (ext-interp) th/T7667a.run T7667a [stderr mismatch] (ext-interp) th/T8499.run T8499 [exit code non-0] (ext-interp) th/T7477.run T7477 [exit code non-0] (ext-interp) th/T8507.run T8507 [exit code non-0] (ext-interp) th/T8759.run T8759 [exit code non-0] (ext-interp) th/TH_StaticPointers.run TH_StaticPointers [exit code non-0] (ext-interp) th/T8807.run T8807 [exit code non-0] (ext-interp) th/T8884.run T8884 [exit code non-0] (ext-interp) th/T8954.run T8954 [exit code non-0] (ext-interp) th/T8932.run T8932 [stderr mismatch] (ext-interp) th/T8987.run T8987 [stderr mismatch] (ext-interp) th/T7241.run T7241 [stderr mismatch] (ext-interp) th/T9199.run T9199 [exit code non-0] (ext-interp) th/T9262.run T9262 [exit code non-0] (ext-interp) th/T9692.run T9692 [exit code non-0] (ext-interp) th/T8953.run T8953 [exit code non-0] (ext-interp) th/T9738.run T9738 [exit code non-0] (ext-interp) th/T9081.run T9081 [exit code non-0] (ext-interp) th/T9066.run T9066 [exit code non-0] (ext-interp) th/T8100.run T8100 [exit code non-0] (ext-interp) th/T9064.run T9064 [exit code non-0] (ext-interp) th/T7484.run T7484 [stderr mismatch] (ext-interp) th/T1476.run T1476 [exit code non-0] (ext-interp) th/T8031.run T8031 [exit code non-0] (ext-interp) th/TH_Lift.run TH_Lift [exit code non-0] (ext-interp) th/T10279.run T10279 [stderr mismatch] (ext-interp) th/T10306.run T10306 [exit code non-0] (ext-interp) th/T10596.run T10596 [exit code non-0] (ext-interp) th/T10598_TH.run T10598_TH [exit code non-0] (ext-interp) th/T10638.run T10638 [stderr mismatch] (ext-interp) th/T10620.run T10620 [exit code non-0] (ext-interp) th/T10697_decided_1.run T10697_decided_1 [exit code non-0] (ext-interp) th/T10697_decided_2.run T10697_decided_2 [exit code non-0] (ext-interp) th/T10697_decided_3.run T10697_decided_3 [exit code non-0] (ext-interp) th/T6018th.run T6018th [stderr mismatch] (ext-interp) th/T10811.run T10811 [exit code non-0] (ext-interp) th/T10796a.run T10796a [exit code non-0] (ext-interp) th/T10796b.run T10796b [stderr mismatch] (ext-interp) th/T10810.run T10810 [exit code non-0] (ext-interp) th/T10828.run T10828 [exit code non-0] (ext-interp) th/T10828a.run T10828a [stderr mismatch] (ext-interp) th/T10828b.run T10828b [stderr mismatch] (ext-interp) th/T10891.run T10891 [exit code non-0] (ext-interp) th/T11341.run T11341 [exit code non-0] (ext-interp) th/TH_finalizer.run TH_finalizer [exit code non-0] (ext-interp) th/T10820.run T10820 [exit code non-0] (ext-interp) th/T11345.run T11345 [exit code non-0] (ext-interp) th/T10603.run T10603 [exit code non-0] (ext-interp) th/T11145.run T11145 [stderr mismatch] (ext-interp) th/T11721_TH.run T11721_TH [exit code non-0] (ext-interp) th/T11680.run T11680 [stderr mismatch] (ext-interp) th/T11809.run T11809 [exit code non-0] (ext-interp) th/T11463.run T11463 [exit code non-0] (ext-interp) th/T11797.run T11797 [exit code non-0] (ext-interp) th/T11484.run T11484 [exit code non-0] (ext-interp) th/T11629.run T11629 [exit code non-0] (ext-interp) th/T12387.run T12387 [stderr mismatch] (ext-interp) th/T8761.run T8761 [exit code non-0] (ext-interp) th/T12407.run T12407 [exit code non-0] (ext-interp) th/T12403.run T12403 [exit code non-0] (ext-interp) th/T12478_3.run T12478_3 [exit code non-0] (ext-interp) th/T12478_4.run T12478_4 [stderr mismatch] (ext-interp) th/T12478_5.run T12478_5 [exit code non-0] (ext-interp) th/T12503.run T12503 [exit code non-0] (ext-interp) th/T12478_1.run T12478_1 [exit code non-0] (ext-interp) th/T12478_2.run T12478_2 [exit code non-0] (ext-interp) th/T12513.run T12513 [stderr mismatch] (ext-interp) th/T12646.run T12646 [exit code non-0] (ext-interp) th/T12530.run T12530 [exit code non-0] (ext-interp) th/T12977.run T12977 [exit code non-0] (ext-interp) th/T13018.run T13018 [exit code non-0] (ext-interp) th/T12993.run T12993 [exit code non-0] (ext-interp) th/T13123.run T13123 [exit code non-0] (ext-interp) th/T13098.run T13098 [exit code non-0] (ext-interp) th/T11046.run T11046 [exit code non-0] (ext-interp) th/T13642.run T13642 [exit code non-0] (ext-interp) th/T13618.run T13618 [exit code non-0] (ext-interp) th/T13781.run T13781 [exit code non-0] (ext-interp) th/T13366.run T13366 [exit code non-0] (ext-interp) th/T13782.run T13782 [exit code non-0] (ext-interp) th/T13837.run T13837 [stderr mismatch] (ext-interp) th/T13856.run T13856 [exit code non-0] (ext-interp) th/T13968.run T13968 [stderr mismatch] (ext-interp) th/T13885.run T13885 [exit code non-0] (ext-interp) th/T14204.run T14204 [stderr mismatch] (ext-interp) th/T14646.run T14646 [exit code non-0] (ext-interp) th/T13887.run T13887 [exit code non-0] (ext-interp) th/T14681.run T14681 [exit code non-0] (ext-interp) th/T14060.run T14060 [exit code non-0] (ext-interp) th/T14817.run T14817 [exit code non-0] (ext-interp) th/T14843.run T14843 [exit code non-0] (ext-interp) th/T13776.run T13776 [exit code non-0] (ext-interp) th/T14875.run T14875 [exit code non-0] (ext-interp) th/T14885a.run T14885a [exit code non-0] (ext-interp) th/T14298.run T14298 [exit code non-0] (ext-interp) th/T14885b.run T14885b [exit code non-0] (ext-interp) th/T14885c.run T14885c [exit code non-0] (ext-interp) th/T15243.run T15243 [exit code non-0] (ext-interp) th/T15331.run T15331 [exit code non-0] (ext-interp) th/T15324.run T15324 [exit code non-0] (ext-interp) th/T15365.run T15365 [exit code non-0] (ext-interp) th/T15518.run T15518 [exit code non-0] (ext-interp) th/T15502.run T15502 [exit code non-0] (ext-interp) th/T15550.run T15550 [exit code non-0] (ext-interp) th/T15572.run T15572 [exit code non-0] (ext-interp) th/T15481.run T15481 [exit code non-0] (ext-interp) th/TH_recover_warns.run TH_recover_warns [exit code non-0] (ext-interp) typecheck/T13168/T13168.run T13168 [bad stderr] (normal) typecheck/bug1465/bug1465.run bug1465 [bad stderr] (normal) typecheck/should_compile/tc263.run tc263 [stderr mismatch] (normal) typecheck/should_fail/T13292.run T13292 [stderr mismatch] (normal) unboxedsums/T14051.run T14051 [stderr mismatch] (normal) unboxedsums/module/sum_mod.run sum_mod [bad stderr] (normal) warnings/should_compile/T10890/T10890.run T10890 [stderr mismatch] (normal) warnings/should_compile/T10890/T10890_1.run T10890_1 [stderr mismatch] (normal) warnings/should_compile/T13727/T13727a.run T13727a [stderr mismatch] (normal) warnings/should_compile/T13727/T13727b.run T13727b [stderr mismatch] (normal) warnings/should_compile/T13727/T13727c.run T13727c [stderr mismatch] (normal) warnings/should_compile/T13727/T13727d.run T13727d [stderr mismatch] (normal) warnings/should_compile/T13727/T13727e.run T13727e [stderr mismatch] (normal) warnings/should_compile/T13727/T13727f.run T13727f [stderr mismatch] (normal) warnings/should_compile/T13727/T13727g.run T13727g [stderr mismatch] (normal) warnings/should_compile/T13727/T13727h.run T13727h [stderr mismatch] (normal) warnings/should_compile/T13727/T13727i.run T13727i [stderr mismatch] (normal) warnings/should_compile/T13727/T13727j.run T13727j [stderr mismatch] (normal) warnings/should_compile/T13727/T13727k.run T13727k [stderr mismatch] (normal) ../../libraries/base/tests/IO/T3307.run T3307 [bad stderr] (normal) ../../libraries/base/tests/IO/environment001.run environment001 [bad stderr] (normal) ../../libraries/base/tests/IO/T12010/T12010.run T12010 [bad stderr] (threaded1) ../../libraries/base/tests/IO/concio001.run concio001 [bad stderr] (normal) ../../libraries/base/tests/IO/concio001.thr.run concio001.thr [bad stderr] (normal) Unexpected stat failures: perf/compiler/T12425.run T12425 [stat not good enough] (optasm) perf/compiler/T10370.run T10370 [stat not good enough] (optasm) perf/compiler/T9630.run T9630 [stat not good enough] (normal) perf/haddock/haddock.base.run haddock.base [stat not good enough] (normal) perf/haddock/haddock.Cabal.run haddock.Cabal [stat not good enough] (normal) perf/haddock/haddock.compiler.run haddock.compiler [stat not good enough] (normal) perf/should_run/T9203.run T9203 [stat too good] (normal) -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Tue Nov 20 07:10:37 2018 From: ben at well-typed.com (Ben Gamari) Date: Tue, 20 Nov 2018 07:10:37 +0000 Subject: ghc 8.6.x release clearly fails validate or even make test, some help please! In-Reply-To: References: Message-ID: <88888782-0531-4DF2-86D5-877B3925BDFC@well-typed.com> On November 20, 2018 2:06:55 AM GMT+00:00, Carter Schonwald wrote: >Hey Everyone ... >I'm concerned, it looks like ghc 8.6.2 on OSX doens't pass validate or >even >a rudimentary `make test` > >I'm not sure how to make heads or tails of all these errors, and it >looks >like a huge amount of dev work over time has accumulated some failures >.... > I can't reproduce this. The binary distributions are produced by CircleCI , which runs the test suite. Can you be more specific about how you are running this test? Cheers, - Ben -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From omeragacan at gmail.com Tue Nov 20 08:47:57 2018 From: omeragacan at gmail.com (=?UTF-8?Q?=C3=96mer_Sinan_A=C4=9Facan?=) Date: Tue, 20 Nov 2018 11:47:57 +0300 Subject: How to distinguish local ids from imported ones in Stg? Confused about isLocalId/isLocalVar Message-ID: Hi, I just found out that semantics of isLocalId/isLocalVar change during compilation. I realized this the hard way (after some debugging) but later realized that this is documented in this note: (the last line) Note [GlobalId/LocalId] ~~~~~~~~~~~~~~~~~~~~~~~ A GlobalId is * always a constant (top-level) * imported, or data constructor, or primop, or record selector * has a Unique that is globally unique across the whole GHC invocation (a single invocation may compile multiple modules) * never treated as a candidate by the free-variable finder; it's a constant! A LocalId is * bound within an expression (lambda, case, local let(rec)) * or defined at top level in the module being compiled * always treated as a candidate by the free-variable finder After CoreTidy, top-level LocalIds are turned into GlobalIds So after after simplification we can't distinguish a local id from an imported one. Apparently I'm not the only one who was confused by this. In StgLint we check in-scope variables with this: checkInScope :: Id -> LintM () checkInScope id = LintM $ \_lf loc scope errs -> if isLocalId id && not (id `elemVarSet` scope) then ((), addErr errs (hsep [ppr id, dcolon, ppr (idType id), text "is out of scope"]) loc) else ((), errs) Note that isLocalId here returns false for local but top-level bindings. Because of this if I drop some top-level bindings in the module I don't get a lint error even though some ids become unbound. I need to distinguish a top-level bound id from an imported id for two things: - I want to make sure, in StgLint, that bindings in the Stg program are in dependency order (uses come after definitions). For this I need to treat imported ids as already bound, but for top-level bound ids I need to check if I already saw the definition. - I want to run an analysis to map top-level bindings to whether they can contain CAF refs. For this for a top-level bound id I should check the environment, but for imported ids I should check idInfo. The second analysis depends on the first property for efficiency. I could assume that the first property holds and then always check the environment first in the analysis, and treat ids that are not in the environment as imported, but that seems fragile. I'm wondering why we have to turn LocalIds into GlobalIds after simplification. The note doesn't explain the reasoning. Would it be possible to preserve idScope of ids during the whole compilation? Thanks, Ömer From carter.schonwald at gmail.com Tue Nov 20 15:42:49 2018 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Tue, 20 Nov 2018 10:42:49 -0500 Subject: are ghc commits only getting make fast test'd on OSX? Message-ID: thats the only explanation of why i see soooo many test suite failues of a GHC RELEASE when i do make test ... why do we not have a full ./validate run on each tier one platform as part of some official release check list? DO WE HAVE a checklist for releases? if not, we should, this shouldn't be happening -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Tue Nov 20 18:23:29 2018 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Tue, 20 Nov 2018 13:23:29 -0500 Subject: ghc 8.6.x release clearly fails validate or even make test, some help please! In-Reply-To: <88888782-0531-4DF2-86D5-877B3925BDFC@well-typed.com> References: <88888782-0531-4DF2-86D5-877B3925BDFC@well-typed.com> Message-ID: Happy to: What’s the best way to look at the Diffs / expected actual for 50 or so tests? So I can better triage these things as important or not going forward? For all I know it could be as simple as our passing diff stuff is white space significant. But I need some guidance on what files I should be looking at I can’t find any docs on how to poke at / read those on the wiki. Alp suggested just running a single test at a time, but that’s no ideal when it’s so many ... I ran that ghc build with clang from llvm 7 on high Sierra and no carter patches. I did cd testsuite ; make test THREADS=7 On Tue, Nov 20, 2018 at 2:10 AM Ben Gamari wrote: > > > On November 20, 2018 2:06:55 AM GMT+00:00, Carter Schonwald < > carter.schonwald at gmail.com> wrote: > >Hey Everyone ... > >I'm concerned, it looks like ghc 8.6.2 on OSX doens't pass validate or > >even > >a rudimentary `make test` > > > >I'm not sure how to make heads or tails of all these errors, and it > >looks > >like a huge amount of dev work over time has accumulated some failures > >.... > > > I can't reproduce this. The binary distributions are produced by CircleCI > , which runs the test suite. > > Can you be more specific about how you are running this test? > > Cheers, > > - Ben > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Tue Nov 20 19:40:40 2018 From: ben at well-typed.com (Ben Gamari) Date: Tue, 20 Nov 2018 14:40:40 -0500 Subject: ghc 8.6.x release clearly fails validate or even make test, some help please! In-Reply-To: References: <88888782-0531-4DF2-86D5-877B3925BDFC@well-typed.com> Message-ID: On November 20, 2018 1:23:29 PM EST, Carter Schonwald wrote: >Happy to: > >What’s the best way to look at the Diffs / expected actual for 50 or so >tests? So I can better triage these things as important or not going >forward? For all I know it could be as simple as our passing diff >stuff is >white space significant. But I need some guidance on what files I >should >be looking at > >I can’t find any docs on how to poke at / read those on the wiki. Alp >suggested just running a single test at a time, but that’s no ideal >when >it’s so many ... > >I ran that ghc build with clang from llvm 7 on high Sierra and no >carter >patches. > >I did cd testsuite ; make test THREADS=7 > You can add TEST="T1234 T5678" to the "make test" command line. This is documented here [1]. Does this help? Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/wiki/Building/RunningTests/Running#Commonlyusedoptions -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From carter.schonwald at gmail.com Tue Nov 20 21:33:33 2018 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Tue, 20 Nov 2018 16:33:33 -0500 Subject: ghc 8.6.x release clearly fails validate or even make test, some help please! In-Reply-To: References: <88888782-0531-4DF2-86D5-877B3925BDFC@well-typed.com> Message-ID: That doesn’t help when I want to look at the output for 50 failed tests ... is this a gap in our current tooling? On Tue, Nov 20, 2018 at 2:40 PM Ben Gamari wrote: > > > On November 20, 2018 1:23:29 PM EST, Carter Schonwald < > carter.schonwald at gmail.com> wrote: > >Happy to: > > > >What’s the best way to look at the Diffs / expected actual for 50 or so > >tests? So I can better triage these things as important or not going > >forward? For all I know it could be as simple as our passing diff > >stuff is > >white space significant. But I need some guidance on what files I > >should > >be looking at > > > >I can’t find any docs on how to poke at / read those on the wiki. Alp > >suggested just running a single test at a time, but that’s no ideal > >when > >it’s so many ... > > > >I ran that ghc build with clang from llvm 7 on high Sierra and no > >carter > >patches. > > > >I did cd testsuite ; make test THREADS=7 > > > You can add TEST="T1234 T5678" to the "make test" command line. This is > documented here [1]. Does this help? > > Cheers, > > - Ben > > > [1] > https://ghc.haskell.org/trac/ghc/wiki/Building/RunningTests/Running#Commonlyusedoptions > > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnaud.spiwack at tweag.io Wed Nov 21 08:09:12 2018 From: arnaud.spiwack at tweag.io (Spiwack, Arnaud) Date: Wed, 21 Nov 2018 09:09:12 +0100 Subject: ghc 8.6.x release clearly fails validate or even make test, some help please! In-Reply-To: References: <88888782-0531-4DF2-86D5-877B3925BDFC@well-typed.com> Message-ID: My favourite way is (in the testsuite/ directory) to make accept (usually make TEST= accept), then inspect the diff with git diff (well, I use magit, but same difference, or whatever your favourite git diff inspector is). On Tue, Nov 20, 2018 at 10:34 PM Carter Schonwald < carter.schonwald at gmail.com> wrote: > That doesn’t help when I want to look at the output for 50 failed tests > ... is this a gap in our current tooling? > > On Tue, Nov 20, 2018 at 2:40 PM Ben Gamari wrote: > >> >> >> On November 20, 2018 1:23:29 PM EST, Carter Schonwald < >> carter.schonwald at gmail.com> wrote: >> >Happy to: >> > >> >What’s the best way to look at the Diffs / expected actual for 50 or so >> >tests? So I can better triage these things as important or not going >> >forward? For all I know it could be as simple as our passing diff >> >stuff is >> >white space significant. But I need some guidance on what files I >> >should >> >be looking at >> > >> >I can’t find any docs on how to poke at / read those on the wiki. Alp >> >suggested just running a single test at a time, but that’s no ideal >> >when >> >it’s so many ... >> > >> >I ran that ghc build with clang from llvm 7 on high Sierra and no >> >carter >> >patches. >> > >> >I did cd testsuite ; make test THREADS=7 >> > >> You can add TEST="T1234 T5678" to the "make test" command line. This is >> documented here [1]. Does this help? >> >> Cheers, >> >> - Ben >> >> >> [1] >> https://ghc.haskell.org/trac/ghc/wiki/Building/RunningTests/Running#Commonlyusedoptions >> >> >> -- >> Sent from my Android device with K-9 Mail. Please excuse my brevity. >> > _______________________________________________ > 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 steven at steshaw.org Wed Nov 21 23:46:00 2018 From: steven at steshaw.org (Steven Shaw) Date: Thu, 22 Nov 2018 09:46:00 +1000 Subject: split_marker crash In-Reply-To: <87o9akeq0y.fsf@smart-cactus.org> References: <87d0r1eyds.fsf@smart-cactus.org> <5BF30FD0.2040803@gmx.at> <8736rwg64b.fsf@smart-cactus.org> <87o9akeq0y.fsf@smart-cactus.org> Message-ID: Curious if the GHC libraries _are_ still built with the `-split-objs` flag, as pointed out in the latest documentation. https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/phases.html?highlight=split-objs#ghc-flag--split-objs -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Thu Nov 22 00:21:14 2018 From: ben at well-typed.com (Ben Gamari) Date: Wed, 21 Nov 2018 19:21:14 -0500 Subject: split_marker crash In-Reply-To: References: <87d0r1eyds.fsf@smart-cactus.org> <5BF30FD0.2040803@gmx.at> <8736rwg64b.fsf@smart-cactus.org> <87o9akeq0y.fsf@smart-cactus.org> Message-ID: <87ftvuq7wq.fsf@smart-cactus.org> Steven Shaw writes: > Curious if the GHC libraries _are_ still built with the `-split-objs` flag, > as pointed out in the latest documentation. > Good catch; the build system uses split sections by default if supported. If not it instead uses split objects, if supported. I do not believe there are any cases where we support split objects but not split sections. Consequently I believe we should always use split sections. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From steven at steshaw.org Thu Nov 22 02:32:12 2018 From: steven at steshaw.org (Steven Shaw) Date: Thu, 22 Nov 2018 12:32:12 +1000 Subject: split_marker crash In-Reply-To: <87ftvuq7wq.fsf@smart-cactus.org> References: <87d0r1eyds.fsf@smart-cactus.org> <5BF30FD0.2040803@gmx.at> <8736rwg64b.fsf@smart-cactus.org> <87o9akeq0y.fsf@smart-cactus.org> <87ftvuq7wq.fsf@smart-cactus.org> Message-ID: On Thu, 22 Nov 2018 at 10:21, Ben Gamari wrote: > Steven Shaw writes: > > > Curious if the GHC libraries _are_ still built with the `-split-objs` > flag, > > as pointed out in the latest documentation. > > > Good catch; the build system uses split sections by default if > supported. If not it instead uses split objects, if supported. I do not > believe there are any cases where we support split objects but not split > sections. Consequently I believe we should always use split sections. > 👍 split sections sounds best. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Fri Nov 23 14:31:33 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 23 Nov 2018 14:31:33 +0000 Subject: Unused imports Message-ID: I'm getting lots of these failures. Has someone forgotten to do a submodule update? I'm up to date on a clean head and have done 'git submodule update' Help! Simon libraries/containers/Data/IntSet/Internal.hs:198:1: error: [-Wunused-imports, -Werror=unused-imports] The import of '<>' from module 'Data.Semigroup' is redundant | 198 | import Data.Semigroup (Semigroup((<>), stimes), stimesIdempotentMonoid) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ libraries/containers/Data/IntSet/Internal.hs:220:1: error: [-Wunused-imports, -Werror=unused-imports] The import of 'Data.Foldable' is redundant except perhaps to import instances from 'Data.Foldable' To import instances alone, use: import Data.Foldable() | 220 | import Data.Foldable (Foldable()) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Fri Nov 23 15:02:14 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 23 Nov 2018 15:02:14 +0000 Subject: How to distinguish local ids from imported ones in Stg? Confused about isLocalId/isLocalVar In-Reply-To: References: Message-ID: | After CoreTidy, top-level LocalIds are turned into GlobalIds | I'm wondering why we have to turn LocalIds into GlobalIds after simplification. The original reason was this: after TidyPgm we extract the binders and put them into a TypeEnv for the module that is used when compiling other modules (in --make and GHCi). So the Id was "local" for this module but it is "global" for others. At some point that transition must be made, and that's where it happens right now. HOWEVER, separately you are working to get arity and CAF info from the final, downstream STG world. (I forget the ticket.) So the output of TidyPgm is *not* the utterly-final Id. Somehow that info from downstream needs to get into the interface file, and into the TypeEnv used for subsequent modules. So we could use that moment, when building that final TypeEnv, to turn the LocalId into a GlobalId. And that would indeed be cleaner; and would solve your problem. Make a ticket to document the idea? I suspect it should follow the "get CAF/arity from downstream" patch. How is that going? Simon | -----Original Message----- | From: ghc-devs On Behalf Of Ömer Sinan | Agacan | Sent: 20 November 2018 08:48 | To: ghc-devs | Subject: How to distinguish local ids from imported ones in Stg? Confused | about isLocalId/isLocalVar | | Hi, | | I just found out that semantics of isLocalId/isLocalVar change during | compilation. I realized this the hard way (after some debugging) but later | realized that this is documented in this note: (the last line) | | Note [GlobalId/LocalId] | ~~~~~~~~~~~~~~~~~~~~~~~ | A GlobalId is | * always a constant (top-level) | * imported, or data constructor, or primop, or record selector | * has a Unique that is globally unique across the whole | GHC invocation (a single invocation may compile multiple modules) | * never treated as a candidate by the free-variable finder; | it's a constant! | | A LocalId is | * bound within an expression (lambda, case, local let(rec)) | * or defined at top level in the module being compiled | * always treated as a candidate by the free-variable finder | | After CoreTidy, top-level LocalIds are turned into GlobalIds | | So after after simplification we can't distinguish a local id from an | imported one. | | Apparently I'm not the only one who was confused by this. In StgLint we | check in-scope variables with this: | | checkInScope :: Id -> LintM () | checkInScope id = LintM $ \_lf loc scope errs | -> if isLocalId id && not (id `elemVarSet` scope) then | ((), addErr errs (hsep [ppr id, dcolon, ppr (idType id), | text "is out of scope"]) loc) | else | ((), errs) | | Note that isLocalId here returns false for local but top-level bindings. | Because of this if I drop some top-level bindings in the module I don't get | a lint error even though some ids become unbound. | | I need to distinguish a top-level bound id from an imported id for two | things: | | - I want to make sure, in StgLint, that bindings in the Stg program are in | dependency order (uses come after definitions). For this I need to treat | imported ids as already bound, but for top-level bound ids I need to | check if | I already saw the definition. | | - I want to run an analysis to map top-level bindings to whether they can | contain CAF refs. For this for a top-level bound id I should check the | environment, but for imported ids I should check idInfo. | | The second analysis depends on the first property for efficiency. I could | assume that the first property holds and then always check the environment | first in the analysis, and treat ids that are not in the environment as | imported, but that seems fragile. | | I'm wondering why we have to turn LocalIds into GlobalIds after | simplification. | The note doesn't explain the reasoning. Would it be possible to preserve | idScope of ids during the whole compilation? | | Thanks, | | Ömer | _______________________________________________ | ghc-devs mailing list | ghc-devs at haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskel | l.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- | devs&data=02%7C01%7Csimonpj%40microsoft.com%7C705682586b304bf21d7508d64 | ec4fe14%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636783005318044462& | ;sdata=TU%2FPW16Lmd5FlF16K50cWpDSeMjdKszcXP1FYkhuIFg%3D&reserved=0 From simonpj at microsoft.com Fri Nov 23 15:41:41 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 23 Nov 2018 15:41:41 +0000 Subject: Head badly broken Message-ID: >From a clean build of HEAD, I’m getting tons of failures like this T5490.hs:19:22: error: Illegal symbol '.' in type Perhaps you meant to write 'forall . '? | 19 | | ∀ e . Exception e ⇒ Failure e | ^ This is in typecheck/should_compile Then I also get errors in things like typecheck/should_fail/tcfail190, where the output differs from the .stderr file in by the presence of bullets in GHC’s output. The bullets seem to be missing from the tcfail190.stderr file. This is really painful. I can’t validate. Any ideas? Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From davide at well-typed.com Fri Nov 23 23:14:37 2018 From: davide at well-typed.com (David Eichmann) Date: Fri, 23 Nov 2018 23:14:37 +0000 Subject: Unused imports In-Reply-To: References: Message-ID: <2e57b749-3034-1977-c09b-5677a50611dd@well-typed.com> Hello Simon, Sorry for my late reply here, My patch that incorporates you're unused imports fix and some core library updates has recently been merged. This is likely the cause of the errors/warnings you see. I've just checked out a recent master and validated. I do see an unused import in compiler/simplStg/StgLiftLams/LiftM.hs introduced in a commit from earlier today (b2950e03b5). This needs to be fixed, but it's easy: https://phabricator.haskell.org/D5374. Baring that, I don't see any other unused imports when I validate. Looking at the exact error in your email (libraries/containers/Data/IntSet/Internal.hs:198), I see that the line of code is outdated. Please double check that you are on the most recent master (or perhaps b2950e03b5^ to avoid the previously mentioned unused import). Then, since many submodules have been bumped, make sure to do a `git submodule update --init` I suspect this will fix your validate problems. Have a great weekend, David E On 23/11/2018 14:31, Simon Peyton Jones via ghc-devs wrote: > > I’m getting lots of these failures.  Has someone forgotten to do a > submodule update?   I’m up to date on a clean head and have done ‘git > submodule update’ > > Help! > > Simon > > libraries/containers/Data/IntSet/Internal.hs:198:1: error: > [-Wunused-imports, -Werror=unused-imports] > >     The import of ‘<>’ from module ‘Data.Semigroup’ is redundant > >     | > > 198 | import Data.Semigroup (Semigroup((<>), stimes), > stimesIdempotentMonoid) > >     | > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > libraries/containers/Data/IntSet/Internal.hs:220:1: error: > [-Wunused-imports, -Werror=unused-imports] > >     The import of ‘Data.Foldable’ is redundant > >       except perhaps to import instances from ‘Data.Foldable’ > >     To import instances alone, use: import Data.Foldable() > >     | > > 220 | import Data.Foldable (Foldable()) > >     | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -- David Eichmann, Haskell Consultant Well-Typed LLP, http://www.well-typed.com Registered in England & Wales, OC335890 118 Wymering Mansions, Wymering Road, London W9 2NF, England -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.colpitts at gmail.com Sat Nov 24 23:40:58 2018 From: george.colpitts at gmail.com (George Colpitts) Date: Sat, 24 Nov 2018 19:40:58 -0400 Subject: ghc 8.6.x release clearly fails validate or even make test, some help please! In-Reply-To: <88888782-0531-4DF2-86D5-877B3925BDFC@well-typed.com> References: <88888782-0531-4DF2-86D5-877B3925BDFC@well-typed.com> Message-ID: I'm seeing a lot of issues with make test on the Mac also. Basically I'm running "make test >& test.log", I have 80 unexpected failures, The end of the log is at the end of this email. Should I open a bug ? Details about my env, ghc version etc. Are there other command I should run to give more info, e.g. ghc --info? ghc --version The Glorious Glasgow Haskell Compilation System, version 8.6.2 bash-3.2$ uname -a Darwin iMac27.local 17.7.0 Darwin Kernel Version 17.7.0: Wed Oct 10 23:06:14 PDT 2018; root:xnu-4570.71.13~1/RELEASE_X86_64 x86_64 bash-3.2$ gcc -v Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/4.2.1 Apple LLVM version 10.0.0 (clang-1000.11.45.5) Target: x86_64-apple-darwin17.7.0 Thread model: posix InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin Unexpected results from: TEST="Ppr001 Ppr002 Ppr003 Ppr004 Ppr005 Ppr006 Ppr007 Ppr008 Ppr009 Ppr010 Ppr011 Ppr012 Ppr013 Ppr014 Ppr015 Ppr016 Ppr017 Ppr018 Ppr019 Ppr020 Ppr021 Ppr022 Ppr023 Ppr024 Ppr025 Ppr026 Ppr027 Ppr028 Ppr029 Ppr030 Ppr031 Ppr032 Ppr033 Ppr034 Ppr035 Ppr036 Ppr037 Ppr038 Ppr039 Ppr040 Ppr041 Ppr042 Ppr043 Ppr044 Ppr045 Ppr046 Ppr048 T10255 T10268 T10269 T10276 T10278 T10280 T10307 T10309 T10312 T10354 T10357 T10358 T10370 T10396 T10399 T10598 T11018 T11321 T11332 T12417 T13050p T13163 T13199 T13550 T13942 T14289 T14289b T14289c T14306 T15303 T9203 T9630 boolFormula bundle-export exampleTest load-main" SUMMARY for test run started at Sat Nov 24 11:18:00 2018 AST 1:49:06 spent to go through 6180 total tests, which gave rise to 22774 test cases, of which 16244 were skipped 33 had missing libraries 6324 expected passes 90 expected failures 0 caused framework failures 0 caused framework warnings 0 unexpected passes 80 unexpected failures 3 unexpected stat failures Unexpected failures: ghc-api/annotations/exampleTest.run exampleTest [bad exit code] (normal) ghc-api/annotations/T10255.run T10255 [bad exit code] (normal) ghc-api/annotations/T10268.run T10268 [bad exit code] (normal) ghc-api/annotations/T10269.run T10269 [bad stdout] (normal) ghc-api/annotations/T10280.run T10280 [bad exit code] (normal) ghc-api/annotations/T10312.run T10312 [bad exit code] (normal) ghc-api/annotations/T10307.run T10307 [bad exit code] (normal) ghc-api/annotations/T10309.run T10309 [bad exit code] (normal) ghc-api/annotations/boolFormula.run boolFormula [bad exit code] (normal) ghc-api/annotations/T10357.run T10357 [bad exit code] (normal) ghc-api/annotations/T10358.run T10358 [bad exit code] (normal) ghc-api/annotations/T10278.run T10278 [bad exit code] (normal) ghc-api/annotations/T10354.run T10354 [bad exit code] (normal) ghc-api/annotations/T10396.run T10396 [bad exit code] (normal) ghc-api/annotations/T10399.run T10399 [bad exit code] (normal) ghc-api/annotations/T11018.run T11018 [bad exit code] (normal) ghc-api/annotations/bundle-export.run bundle-export [bad exit code] (normal) ghc-api/annotations/T10276.run T10276 [bad exit code] (normal) ghc-api/annotations/T10598.run T10598 [bad exit code] (normal) ghc-api/annotations/T11321.run T11321 [bad exit code] (normal) ghc-api/annotations/T11332.run T11332 [bad exit code] (normal) ghc-api/annotations/load-main.run load-main [bad exit code] (normal) ghc-api/annotations/T12417.run T12417 [bad exit code] (normal) ghc-api/annotations/T13163.run T13163 [bad exit code] (normal) ghc-api/annotations/T15303.run T15303 [bad exit code] (normal) printer/Ppr001.run Ppr001 [bad exit code] (normal) printer/Ppr002.run Ppr002 [bad exit code] (normal) printer/Ppr003.run Ppr003 [bad exit code] (normal) printer/Ppr004.run Ppr004 [bad exit code] (normal) printer/Ppr005.run Ppr005 [bad exit code] (normal) printer/Ppr006.run Ppr006 [bad exit code] (normal) printer/Ppr007.run Ppr007 [bad exit code] (normal) printer/Ppr008.run Ppr008 [bad exit code] (normal) printer/Ppr009.run Ppr009 [bad exit code] (normal) printer/Ppr010.run Ppr010 [bad exit code] (normal) printer/Ppr011.run Ppr011 [bad exit code] (normal) printer/Ppr012.run Ppr012 [bad exit code] (normal) printer/Ppr013.run Ppr013 [bad exit code] (normal) printer/Ppr014.run Ppr014 [bad exit code] (normal) printer/Ppr015.run Ppr015 [bad exit code] (normal) printer/Ppr016.run Ppr016 [bad exit code] (normal) printer/Ppr017.run Ppr017 [bad exit code] (normal) printer/Ppr018.run Ppr018 [bad exit code] (normal) printer/Ppr019.run Ppr019 [bad exit code] (normal) printer/Ppr020.run Ppr020 [bad exit code] (normal) printer/Ppr021.run Ppr021 [bad exit code] (normal) printer/Ppr022.run Ppr022 [bad exit code] (normal) printer/Ppr023.run Ppr023 [bad exit code] (normal) printer/Ppr024.run Ppr024 [bad exit code] (normal) printer/Ppr025.run Ppr025 [bad exit code] (normal) printer/Ppr026.run Ppr026 [bad exit code] (normal) printer/Ppr027.run Ppr027 [bad exit code] (normal) printer/Ppr028.run Ppr028 [bad exit code] (normal) printer/Ppr029.run Ppr029 [bad exit code] (normal) printer/Ppr030.run Ppr030 [bad exit code] (normal) printer/Ppr031.run Ppr031 [bad exit code] (normal) printer/Ppr032.run Ppr032 [bad exit code] (normal) printer/Ppr033.run Ppr033 [bad exit code] (normal) printer/Ppr034.run Ppr034 [bad exit code] (normal) printer/Ppr035.run Ppr035 [bad exit code] (normal) printer/Ppr036.run Ppr036 [bad exit code] (normal) printer/Ppr037.run Ppr037 [bad exit code] (normal) printer/Ppr038.run Ppr038 [bad exit code] (normal) printer/Ppr039.run Ppr039 [bad exit code] (normal) printer/Ppr040.run Ppr040 [bad exit code] (normal) printer/Ppr041.run Ppr041 [bad exit code] (normal) printer/Ppr042.run Ppr042 [bad exit code] (normal) printer/Ppr043.run Ppr043 [bad exit code] (normal) printer/Ppr044.run Ppr044 [bad exit code] (normal) printer/Ppr045.run Ppr045 [bad exit code] (normal) printer/Ppr046.run Ppr046 [bad exit code] (normal) printer/Ppr048.run Ppr048 [bad exit code] (normal) printer/T13199.run T13199 [bad exit code] (normal) printer/T13050p.run T13050p [bad exit code] (normal) printer/T13550.run T13550 [bad exit code] (normal) printer/T13942.run T13942 [bad exit code] (normal) printer/T14289.run T14289 [bad exit code] (normal) printer/T14289b.run T14289b [bad exit code] (normal) printer/T14289c.run T14289c [bad exit code] (normal) printer/T14306.run T14306 [bad exit code] (normal) Unexpected stat failures: perf/compiler/T10370.run T10370 [stat not good enough] (optasm) perf/compiler/T9630.run T9630 [stat not good enough] (normal) perf/should_run/T9203.run T9203 [stat too good] (normal) make[1]: *** [test] Error 1 make: *** [all] Error 2 On Tue, Nov 20, 2018 at 3:10 AM Ben Gamari wrote: > > > On November 20, 2018 2:06:55 AM GMT+00:00, Carter Schonwald < > carter.schonwald at gmail.com> wrote: > >Hey Everyone ... > >I'm concerned, it looks like ghc 8.6.2 on OSX doens't pass validate or > >even > >a rudimentary `make test` > > > >I'm not sure how to make heads or tails of all these errors, and it > >looks > >like a huge amount of dev work over time has accumulated some failures > >.... > > > I can't reproduce this. The binary distributions are produced by CircleCI > , which runs the test suite. > > Can you be more specific about how you are running this test? > > Cheers, > > - Ben > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > _______________________________________________ > 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 ben at well-typed.com Sun Nov 25 00:44:43 2018 From: ben at well-typed.com (Ben Gamari) Date: Sat, 24 Nov 2018 19:44:43 -0500 Subject: ghc 8.6.x release clearly fails validate or even make test, some help please! In-Reply-To: References: <88888782-0531-4DF2-86D5-877B3925BDFC@well-typed.com> Message-ID: <875zwm0yva.fsf@smart-cactus.org> George Colpitts writes: > I'm seeing a lot of issues with make test on the Mac also. Basically I'm > running "make test >& test.log", I have 80 unexpected failures, The end of > the log is at the end of this email. > > Should I open a bug ? > Yes, that would be great. When you do so it would be helpful if you could attach the test log. It would also be good to know what OS X and XCode version you are using. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ggreif at gmail.com Sun Nov 25 09:29:58 2018 From: ggreif at gmail.com (Gabor Greif) Date: Sun, 25 Nov 2018 10:29:58 +0100 Subject: llvm way only tests? Message-ID: Hi all, what is the magic incantation for running tests only when the llvm tools (e.g. `opt`) are around? I am currently declaring the test as test('T15155l', [ only_ways(llvm_ways), ], run_command, ['$MAKE -s --no-print-directory T15155l']) but it won't be included neither in the optasm builds (which is okay) nor in the llvm builds (gets skipped unexpetedly) I looked at the other test which are declared similarly, and they behave just like mine. What I am doing wrong? Thanks, Gabor From george.colpitts at gmail.com Sun Nov 25 23:52:24 2018 From: george.colpitts at gmail.com (George Colpitts) Date: Sun, 25 Nov 2018 19:52:24 -0400 Subject: ghc 8.6.x release clearly fails validate or even make test, some help please! In-Reply-To: <875zwm0yva.fsf@smart-cactus.org> References: <88888782-0531-4DF2-86D5-877B3925BDFC@well-typed.com> <875zwm0yva.fsf@smart-cactus.org> Message-ID: Done. https://ghc.haskell.org/trac/ghc/ticket/15947 On Sat, Nov 24, 2018 at 8:44 PM Ben Gamari wrote: > George Colpitts writes: > > > I'm seeing a lot of issues with make test on the Mac also. Basically I'm > > running "make test >& test.log", I have 80 unexpected failures, The end > of > > the log is at the end of this email. > > > > Should I open a bug ? > > > Yes, that would be great. When you do so it would be helpful if you > could attach the test log. It would also be good to know what OS X and > XCode version you are using. > > Cheers, > > - Ben > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Mon Nov 26 16:28:05 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Mon, 26 Nov 2018 16:28:05 +0000 Subject: git stats Message-ID: David I’m still getting all these fatal errors when making a single test. Plus it takes several seconds for them all to happen. Any thoughts about supressing this stuff? I know you made some progress here. Thanks Simon simonpj at cam-05-unx:~/5builds/HEAD-4/testsuite/tests/typecheck/should_compile$ make stage=1 TEST=T13871 PYTHON="python3" "python3" ../../../driver/runtests.py -e "ghc_compiler_always_flags='-dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output'" -e config.compiler_debugged=True -e ghc_with_native_codegen=True -e config.have_vanilla=True -e config.have_dynamic=True -e config.have_profiling=False -e ghc_with_threaded_rts=True -e ghc_with_dynamic_rts=True -e config.have_interp=False -e config.unregisterised=False -e config.have_gdb=False -e config.have_readelf=True -e config.ghc_dynamic_by_default=False -e config.ghc_dynamic=False -e ghc_with_smp=True -e ghc_with_llvm=False -e windows=False -e darwin=False -e config.in_tree_compiler=True -e config.cleanup=True -e config.local=True --rootdir=. --config-file=../../../config/ghc -e 'config.platform="x86_64-unknown-linux"' -e 'config.os="linux"' -e 'config.arch="x86_64"' -e 'config.wordsize="64"' -e 'config.timeout=int() or config.timeout' -e 'config.exeext=""' -e 'config.top="/5playpen/simonpj/HEAD-4/testsuite"' --config 'compiler="/5playpen/simonpj/HEAD-4/inplace/test spaces/ghc-stage1"' --config 'ghc_pkg="/5playpen/simonpj/HEAD-4/inplace/test spaces/ghc-pkg"' --config 'haddock=' --config 'hp2ps="/5playpen/simonpj/HEAD-4/inplace/test spaces/hp2ps"' --config 'hpc="/5playpen/simonpj/HEAD-4/inplace/test spaces/hpc"' --config 'gs="gs"' --config 'timeout_prog="../../../timeout/install-inplace/bin/timeout"' -e "config.stage=1" \ --only=T13871 \ \ \ \ \ \ Timeout is 300 fatal: Not a git repository (or any parent up to mount point /5playpen) Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set). Failed to get allowed metric changes from the HEAD git commit message. 0 Found 1 .T files... Beginning test run at Mon Nov 26 16:26:18 2018 GMT ====> Scanning ./all.T =====> T13871(normal) 1 of 1 [0, 0, 0] cd "T13871.run" && "/5playpen/simonpj/HEAD-4/inplace/test spaces/ghc-stage1" -c T13871.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output -fno-warn-incomplete-patterns SUMMARY for test run started at Mon Nov 26 16:26:18 2018 GMT 0:00:01 spent to go through 1 total tests, which gave rise to 3 test cases, of which 2 were skipped 0 had missing libraries 1 expected passes 0 expected failures 0 caused framework failures 0 caused framework warnings 0 unexpected passes 0 unexpected failures 0 unexpected stat failures Appending 0 stats to git notes. fatal: Not a git repository (or any parent up to mount point /5playpen) Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set). fatal: Not a git repository (or any parent up to mount point /5playpen) Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set). fatal: Not a git repository (or any parent up to mount point /5playpen) Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set). fatal: Not a git repository (or any parent up to mount point /5playpen) Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set). fatal: Not a git repository (or any parent up to mount point /5playpen) Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set). An error occured while writing the performance metrics to git notes. ​ This is usually due to a lock-file existing somewhere in the git repo. simonpj at cam-05-unx:~/5builds/HEAD-4/testsuite/tests/typecheck/should_compile$ -------------- next part -------------- An HTML attachment was scrubbed... URL: From lonetiger at gmail.com Mon Nov 26 21:19:56 2018 From: lonetiger at gmail.com (lonetiger at gmail.com) Date: Mon, 26 Nov 2018 21:19:56 +0000 Subject: Running IO function from RTS Message-ID: <5bfc637d.1c69fb81.98040.2456@mx.google.com> Hi all, I’m looking for a way to initiate a call from the RTS into Haskell (base function) running and evaluating an IO function using the non-threaded RTS. For the threaded RTS I can use rts_evalIO with the RTS capability, but for the non-threaded I can’t find a way that doesn’t trigger the if (cap->in_haskell) { errorBelch("schedule: re-entered unsafely.\n" " Perhaps a 'foreign import unsafe' should be 'safe'?"); stg_exit(EXIT_FAILURE); } Clause in the scheduler. Taking a look at how the non-threaded I/O manager currently works on Windows, it seems that re-uses the TSO from the blocked thread doing the I/O call to give notifications back. This approach doesn’t work for me since the new I/O manager doesn’t block doing a foreign call boundary, instead It blocks in Haskell on an MVar, and I only want to wake up very specific threads. In short, does anyone know of a way to initialize an I/O operation from the non-threaded RTS? Thanks, Tamar -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Tue Nov 27 17:03:13 2018 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Tue, 27 Nov 2018 12:03:13 -0500 Subject: condensed summary of vanilla mojave ghc 8.6.2 errors with clang Message-ID: the vast majority of the errors i previously shared seem to be "can't find atom for stabs BNSYM at 0000AF80 in /Users/carter/dev-checkouts/ghc-tree/ghc-8.6.X-checkout-clang-build/libraries/base/dist-install/build/libHSbase-4.12.0.0.a(Internals.o)" which corresponds with this code in the apple linker https://github.com/llvm-mirror/lld/blob/master/lib/ReaderWriter/MachO/MachONormalizedFileToAtoms.cpp#L749 i dont know to what to make of this -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Tue Nov 27 17:21:18 2018 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Tue, 27 Nov 2018 12:21:18 -0500 Subject: condensed summary of vanilla mojave ghc 8.6.2 errors with clang In-Reply-To: References: Message-ID: it looks like after the 8.6.2 release there was some fixes cherry picked into the 8.6 branch for the Mach O linker that I believe were the cause of the errors i've been seeing, i'm doing a fresh build to confirm On Tue, Nov 27, 2018 at 12:03 PM Carter Schonwald < carter.schonwald at gmail.com> wrote: > the vast majority of the errors i previously shared seem to be > > "can't find atom for stabs BNSYM at 0000AF80 in > /Users/carter/dev-checkouts/ghc-tree/ghc-8.6.X-checkout-clang-build/libraries/base/dist-install/build/libHSbase-4.12.0.0.a(Internals.o)" > > which corresponds with this code in the apple linker > > https://github.com/llvm-mirror/lld/blob/master/lib/ReaderWriter/MachO/MachONormalizedFileToAtoms.cpp#L749 > > i dont know to what to make of this > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chrisdone at gmail.com Tue Nov 27 17:59:38 2018 From: chrisdone at gmail.com (Christopher Done) Date: Tue, 27 Nov 2018 17:59:38 +0000 Subject: Writing a simple Core evaluator, having trouble with name lookups Message-ID: Hi all, I'm attempting to make a simple evaluator for GHC core, but I'm not clear on how to reliably looking up names. I'm compiling each of ghc-prim, integer-simple and base with a patched version of GHC which performs an extra output step with the Core AST to a file for each module. Later, I load those files in. So for an input Haskell file like this: module Main (main,Foo(..)) where class Foo a where foo :: a -> Int instance Foo Int where foo x = x * x instance Foo Char where foo x = 99 main = print (foo (123 :: Int)) I have an output set of bindings like this: https://gist.github.com/chrisdone/cb05a77d3fcb081a4580b5f85289674a One thing that I immediately notice is that the names of things are completely non-unique, especially in generated names. So here are two implementations of the method "foo" for the class "Foo": ( Id {idStableName = "main:Main:$cfoo", idUnique = Unique 6989586621679010917}, ...) -- Int ( Id {idStableName = "main:Main:$cfoo", idUnique = Unique 6989586621679010923}, ...) -- Char So e.g. the instance for "Foo Int" refers to the above method implementation via its Unique (6989586621679010923): ( Id {idStableName = "main:Main:$fFooInt", idUnique = Unique 8214565720323784705} , CastE (VarE (Id { idStableName = "main:Main:$cfoo" , idUnique = Unique 6989586621679010923 <---- HERE }))) At first, I thought I would use the Unique associated with every Name to make a lookup. This is completely reliable within one GHC compilation, but I've read in the docs that it's not stable across multiple invocations? What does that mean for my case? Another thing I notice is that type-class methods are not generated at the core level. I have, for example, this method call that provides it the instance dictionary, (AppE (AppE (VarE (Id { idStableName = "main:Main:foo" , idUnique = Unique 8214565720323784707 <---- MISSING })) (TypE (Typ "Int"))) (VarE (Id { idStableName = "main:Main:$fFooInt" , idUnique = Unique 8214565720323784705 }))) But the "main:Main:foo" (8214565720323784707) is not produced in the CoreProgram, it seems. My compile step is very simple: compile :: GHC.GhcMonad m => GHC.ModSummary -> m [CoreSyn.Bind GHC.Var] compile modSummary = do parsedModule <- GHC.parseModule modSummary typecheckedModule <- GHC.typecheckModule parsedModule desugared <- GHC.desugarModule typecheckedModule let binds = GHC.mg_binds (GHC.dm_core_module desugared) pure binds It simply gets the bindings and that's all from the ModGuts. mg_binds :: !CoreProgram Two questions: 1) How do I recognize class methods when I see one, like the "main:Main:foo" above? Maybe this? isClassOpId_maybe :: Id -> Maybe Class Is an "op" what GHC calls type-class methods? 2) If I compile e.g. ghc-prim and that generates a binding Name with ID 123, and then I compile base -- will the ID 123 be re-used by base for something else, or will any reference to 123 in the compiled Names for base refer ONLY to that one in ghc-prim? In other words, when GHC loads the iface for ghc-prim, does it generate a fresh set of names for everything in ghc-prim, or does it load them from file? Cheers! -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Tue Nov 27 23:19:14 2018 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Tue, 27 Nov 2018 18:19:14 -0500 Subject: condensed summary of vanilla mojave ghc 8.6.2 errors with clang In-Reply-To: References: Message-ID: andreask pointed out that large amounts of dwarf code might overflow a signed 32 bit or 16 bit field in object code, it looks like thats what happens On Tue, Nov 27, 2018 at 12:21 PM Carter Schonwald < carter.schonwald at gmail.com> wrote: > it looks like after the 8.6.2 release there was some fixes cherry picked > into the 8.6 branch for the Mach O linker that I believe were the cause of > the errors i've been seeing, i'm doing a fresh build to confirm > > On Tue, Nov 27, 2018 at 12:03 PM Carter Schonwald < > carter.schonwald at gmail.com> wrote: > >> the vast majority of the errors i previously shared seem to be >> >> "can't find atom for stabs BNSYM at 0000AF80 in >> /Users/carter/dev-checkouts/ghc-tree/ghc-8.6.X-checkout-clang-build/libraries/base/dist-install/build/libHSbase-4.12.0.0.a(Internals.o)" >> >> which corresponds with this code in the apple linker >> >> https://github.com/llvm-mirror/lld/blob/master/lib/ReaderWriter/MachO/MachONormalizedFileToAtoms.cpp#L749 >> >> i dont know to what to make of this >> >> >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From pi.boy.travis at gmail.com Thu Nov 29 04:44:17 2018 From: pi.boy.travis at gmail.com (Travis Whitaker) Date: Wed, 28 Nov 2018 20:44:17 -0800 Subject: Cmm Memory Model (Understanding #15449) Message-ID: Hello GHC Devs, I'm trying to get my head around ticket #15449 ( https://ghc.haskell.org/trac/ghc/ticket/15449). This gist of things is that GHC generates incorrect aarch64 code that causes memory corruption in multithreaded programs run on out-of-order machines. User trommler discovered that similar issues are present on PowerPC, and indeed ARMv7 and PowerPC support the same types of load/store reorderings. The LLVM code emitted by GHC may be incorrect with respect to LLVM's memory model, but this isn't a problem on architectures with minimal reordering like x86. I had initially thought that GHC simply wasn't emitting the appropriate LLVM fences; there's an elephant-gun-approach here ( https://github.com/TravisWhitaker/ghc/commits/ghc843-wip/T15449) that guards each atomic operation with a full barrier. I still believe that GHC is omitting necessary LLVM fences, but this change is insufficient to fix the behavior of the test case (which is simply GHC itself compiling a test package with '-jN', N > 1). It seems there's a long and foggy history of the Cmm memory model. Edward Yang discusses this a bit in his post here ( http://blog.ezyang.com/2014/01/so-you-want-to-add-a-new-concurrency-primitive-to-ghc/) and issues similar to #15449 have plagued GHC in the past, like #12469 ( https://ghc.haskell.org/trac/ghc/ticket/12469). Worryingly, GHC only has MO_WriteBarrier, whereas PowerPC and ARMv7 really need read, write, and full memory barriers. On ARM an instruction memory barrier might be required as well, but I don't know enough about STG/Cmm to say for sure, and it'd likely be LLVM's responsibility to emit that anyway. I'm hoping that someone with more tribal knowledge than I might be able to give me some pointers with regards to the following areas: - Does STG itself have anything like a memory model? My intuition says 'definitely not', but given that STG expressions may contain Cmm operations (via StgCmmPrim), there may be STG-to-STG transformations that need to care about the target machine's memory model. - With respect to Cmm, what reorderings does GHC perform? What are the relevant parts of the compiler to begin studying? - Are the LLVM atomics that GHC emits correct with respect to the LLVM memory model? As it stands now LLVM fences are only emitted for MO_WriteBarrier. Without fences accompanying the atomics, it seems the LLVM compiler could float dependent loads/stores past atomic operations. - Why is MO_WriteBarrier the only provided memory barrier? My hunch is that it's because this is the only sort of barrier required on x86, which only allows loads to be reordered with older stores, but perhaps I'm missing something? Is it plausible that Cmm simply needs additional barrier primitives to target these weaker memory models? Conversely, is there some property of Cmm that let's us get away without read barriers at all? Naturally, if I've got any of this wrong or are otherwise barking up the wrong tree, please let me know. Thanks for all your efforts! Travis Whitaker -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Thu Nov 29 11:33:24 2018 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu, 29 Nov 2018 12:33:24 +0100 Subject: nofib output difference Message-ID: <08dbfd27b35817f86200b5c5565df372801b8703.camel@joachim-breitner.de> Hi, currently, perf.haskell.org has stopped because recent commits fail to build with: expected stdout not matched by reality --- fft2.stdout7 2018-11-28 12:00:24.126015465 -0500 +++ /tmp/runtest6392.1 2018-11-28 12:59:59.329423367 -0500 @@ -1,3 +1,3 @@ -result1 = 2.59635799135966e-12 -result2 = 2.59635799135966e-12 -result3 = 4.8279900966008427e-8 +result1 = 2.649891777856828e-12 +result2 = 2.649891777856828e-12 +result3 = 4.830900479646516e-8 make[2]: *** [../../mk/target.mk:102: runtests] Error 1 do others observe this as well? This is worrying, because there has been no change to nofib since it last worked. Can we add a check of the functional correctness of the nofib programs to the CI somehow? Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From ben at smart-cactus.org Thu Nov 29 14:45:39 2018 From: ben at smart-cactus.org (Ben Gamari) Date: Thu, 29 Nov 2018 09:45:39 -0500 Subject: Cmm Memory Model (Understanding #15449) In-Reply-To: References: Message-ID: <87bm68ymb7.fsf@smart-cactus.org> Travis Whitaker writes: > Hello GHC Devs, > > I'm trying to get my head around ticket #15449 ( > https://ghc.haskell.org/trac/ghc/ticket/15449). This gist of things is that > GHC generates incorrect aarch64 code that causes memory corruption in > multithreaded programs run on out-of-order machines. User trommler > discovered that similar issues are present on PowerPC, and indeed ARMv7 and > PowerPC support the same types of load/store reorderings. The LLVM code > emitted by GHC may be incorrect with respect to LLVM's memory model, but > this isn't a problem on architectures with minimal reordering like x86. > Thank you for picking this up! > I had initially thought that GHC simply wasn't emitting the appropriate > LLVM fences; there's an elephant-gun-approach here ( > https://github.com/TravisWhitaker/ghc/commits/ghc843-wip/T15449) that > guards each atomic operation with a full barrier. I still believe that GHC > is omitting necessary LLVM fences, but this change is insufficient to fix > the behavior of the test case (which is simply GHC itself compiling a test > package with '-jN', N > 1). > > It seems there's a long and foggy history of the Cmm memory model. Edward > Yang discusses this a bit in his post here ( > http://blog.ezyang.com/2014/01/so-you-want-to-add-a-new-concurrency-primitive-to-ghc/) > and issues similar to #15449 have plagued GHC in the past, like #12469 ( > https://ghc.haskell.org/trac/ghc/ticket/12469). Worryingly, GHC only has > MO_WriteBarrier, whereas PowerPC and ARMv7 really need read, write, and > full memory barriers. On ARM an instruction memory barrier might be > required as well, but I don't know enough about STG/Cmm to say for sure, > and it'd likely be LLVM's responsibility to emit that anyway. > In my opinion GHC's current memory model story is quite unsustainable. As you point out, we currently have a limited selection of plain barriers and a few atomic operations, none of which are adequately documented given the subtlety they involve. I think we would at this point be foolish not to take advantage of the research that has been done in this area by moving to C11-style acquire/release semantics wherever possible. While following through on this is not a small task, these semantics are both well defined and easier to reason about intuitively. We might also be able to benefit from the wealth of model checking tools that are now available for this formalism. Ulan Degenbaev (CC'd) and I discussed him possibly picking up the task of moving to C11 atomics a few weeks ago. > I'm hoping that someone with more tribal knowledge than I might be able to > give me some pointers with regards to the following areas: > > > - Does STG itself have anything like a memory model? My intuition says > 'definitely not', but given that STG expressions may contain Cmm operations > (via StgCmmPrim), there may be STG-to-STG transformations that need to care > about the target machine's memory model. As far as I know, it has nothing formally, or even informally, defined. That being said, relatively few of our primops make any guarantees about their operation in a concurrent setting. The cases that I can think of include `casArray#`, `atomicModifyIORef#`, `atomic{Read,Write}*Array#` and the STM operations. > - With respect to Cmm, what reorderings does GHC perform? What are the > relevant parts of the compiler to begin studying? As far as I know, very few. We only perform a handful of optimizations on C--. These include, * Sinking of assignments (see compiler/cmm/CmmSink.hs); see CmmSink.conflicts for what commutation we allow. We notably don't allow sinking of any memory assignments past calls (including primops) * Simple constant folding (see CmmOpt.cmmMachOpFoldM) * Common block elimination (see CmmCommonBlockElim) * Some simple control-flow optimisation (see CmmContFlowOpt) > - Are the LLVM atomics that GHC emits correct with respect to the LLVM > memory model? As it stands now LLVM fences are only emitted for > MO_WriteBarrier. Without fences accompanying the atomics, it seems the LLVM > compiler could float dependent loads/stores past atomic operations. Frankly, I would be surprised if they are correct. Few people have really looked at GHC's memory ordering properties and even fewer have looked at those of the LLVM backend. > - Why is MO_WriteBarrier the only provided memory barrier? My hunch is > that it's because this is the only sort of barrier required on x86, which > only allows loads to be reordered with older stores, but perhaps I'm > missing something? Is it plausible that Cmm simply needs additional barrier > primitives to target these weaker memory models? Conversely, is there some > property of Cmm that let's us get away without read barriers at all? > Note that there are a few others defined in SMP.h (namely store_load_barrier and load_load_barrier). However, see the discussion above. My understanding is that there were just very few formalisms for reasoning about weak memory models when this code was written. The literature now contains a much better understanding of this field but GHC has yet to catch up. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ben at well-typed.com Thu Nov 29 15:06:07 2018 From: ben at well-typed.com (Ben Gamari) Date: Thu, 29 Nov 2018 10:06:07 -0500 Subject: llvm way only tests? In-Reply-To: References: Message-ID: <875zwfzzxj.fsf@smart-cactus.org> Gabor Greif writes: > Hi all, > > what is the magic incantation for running tests only when the llvm > tools (e.g. `opt`) are around? > > I am currently declaring the test as > > test('T15155l', > [ only_ways(llvm_ways), > ], run_command, ['$MAKE -s --no-print-directory T15155l']) > > but it won't be included neither in the optasm builds (which is okay) > nor in the llvm builds (gets skipped unexpetedly) I looked at the > other test which are declared similarly, and they behave just like > mine. > Hmm, I suspect the logic in testsuite/mk/test.mk for determining whether LLVM is available is flawed. It concludes that LLVM is unavailable if LLC=llc. I can only assume that the reason for this is that configure will often find the system's on PATH (in which case LLC=llc) which likely isn't the LLVM release that we expect. However, we probably ought to be more careful here. Could you comment on what LLC is set to in your environment? Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ben at well-typed.com Thu Nov 29 15:13:24 2018 From: ben at well-typed.com (Ben Gamari) Date: Thu, 29 Nov 2018 10:13:24 -0500 Subject: nofib output difference In-Reply-To: <08dbfd27b35817f86200b5c5565df372801b8703.camel@joachim-breitner.de> References: <08dbfd27b35817f86200b5c5565df372801b8703.camel@joachim-breitner.de> Message-ID: <874lbzzzla.fsf@smart-cactus.org> Joachim Breitner writes: > Hi, > > currently, perf.haskell.org has stopped because recent commits fail to > build with: > > expected stdout not matched by reality > --- fft2.stdout7 2018-11-28 12:00:24.126015465 -0500 > +++ /tmp/runtest6392.1 2018-11-28 12:59:59.329423367 -0500 > @@ -1,3 +1,3 @@ > -result1 = 2.59635799135966e-12 > -result2 = 2.59635799135966e-12 > -result3 = 4.8279900966008427e-8 > +result1 = 2.649891777856828e-12 > +result2 = 2.649891777856828e-12 > +result3 = 4.830900479646516e-8 > make[2]: *** [../../mk/target.mk:102: runtests] Error 1 > > do others observe this as well? This is worrying, because there has > been no change to nofib since it last worked. > > Can we add a check of the functional correctness of the nofib programs > to the CI somehow? > Yikes, this is indeed somewhat worrying. I see the same result as you for result1 and result2 but a slightly different number for result3. Looking at this particular test it appears to be quite numerically unstable. I count over ten distinct sets of .stdout files in spectral/fft2, some of which match what the results I observe quite closely. Overall we should indeed make sure these get tested in CI. Do you know how long ago this change occurred? Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ggreif at gmail.com Thu Nov 29 15:14:53 2018 From: ggreif at gmail.com (Gabor Greif) Date: Thu, 29 Nov 2018 16:14:53 +0100 Subject: llvm way only tests? In-Reply-To: <875zwfzzxj.fsf@smart-cactus.org> References: <875zwfzzxj.fsf@smart-cactus.org> Message-ID: Hi Ben, from my config.status: S["OptCmd"]="" S["ac_ct_OPT"]="opt" S["OPT"]="" S["LlcCmd"]="" S["ac_ct_LLC"]="llc" S["LLC"]="" S["ClangCmd"]="clang" S["CLANG"]="clang" This is also what my config summary visualizes. I have LLVM 5.0.2 installed. It *seems* to do the job. Cheers, Gabor On 11/29/18, Ben Gamari wrote: > Gabor Greif writes: > >> Hi all, >> >> what is the magic incantation for running tests only when the llvm >> tools (e.g. `opt`) are around? >> >> I am currently declaring the test as >> >> test('T15155l', >> [ only_ways(llvm_ways), >> ], run_command, ['$MAKE -s --no-print-directory T15155l']) >> >> but it won't be included neither in the optasm builds (which is okay) >> nor in the llvm builds (gets skipped unexpetedly) I looked at the >> other test which are declared similarly, and they behave just like >> mine. >> > Hmm, I suspect the logic in testsuite/mk/test.mk for determining whether > LLVM is available is flawed. It concludes that LLVM is unavailable if > LLC=llc. I can only assume that the reason for this is that configure > will often find the system's on PATH (in which case LLC=llc) which > likely isn't the LLVM release that we expect. > > However, we probably ought to be more careful here. > > Could you comment on what LLC is set to in your environment? > > Cheers, > > - Ben > > From ben at smart-cactus.org Thu Nov 29 15:15:43 2018 From: ben at smart-cactus.org (Ben Gamari) Date: Thu, 29 Nov 2018 10:15:43 -0500 Subject: nofib output difference In-Reply-To: <08dbfd27b35817f86200b5c5565df372801b8703.camel@joachim-breitner.de> References: <08dbfd27b35817f86200b5c5565df372801b8703.camel@joachim-breitner.de> Message-ID: <871s73zzhe.fsf@smart-cactus.org> Joachim Breitner writes: > Hi, > > currently, perf.haskell.org has stopped because recent commits fail to > build with: > I have opened #15972 to track this. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From mail at joachim-breitner.de Thu Nov 29 15:28:57 2018 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu, 29 Nov 2018 16:28:57 +0100 Subject: nofib output difference In-Reply-To: <874lbzzzla.fsf@smart-cactus.org> References: <08dbfd27b35817f86200b5c5565df372801b8703.camel@joachim-breitner.de> <874lbzzzla.fsf@smart-cactus.org> Message-ID: <0c4a719c6a4c0a547a643f12339e6111d13604c0.camel@joachim-breitner.de> Hi, Am Donnerstag, den 29.11.2018, 10:13 -0500 schrieb Ben Gamari: > Yikes, this is indeed somewhat worrying. I see the same result as you > for result1 and result2 but a slightly different number for result3. > > Looking at this particular test it appears to be quite numerically > unstable. I count over ten distinct sets of .stdout files in > spectral/fft2, some of which match what the results I observe quite > closely. > > Overall we should indeed make sure these get tested in CI. > > Do you know how long ago this change occurred? Not easily, there were other breakages on perf.haskell.org that probably shadowed this. Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From simonpj at microsoft.com Thu Nov 29 17:30:52 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Thu, 29 Nov 2018 17:30:52 +0000 Subject: Kind inference Message-ID: I have been working for longer than I care to admit on a significant refactoring of kind inference. I've just pushed it. It's a pretty big patch, which Richard and I have been discussing for some weeks. It validates, and fixes at least nine troublesome open tickets. But of course I could have made a mistake. Be vigilant. My: there will almost certainly be conflicts with your visible kind application patch, especially in tcInferApps. But that function has gotten substantially simpler in my patch so I don't think it'll be hard to fix things up. Phew! Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Fri Nov 30 07:46:28 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 30 Nov 2018 07:46:28 +0000 Subject: Windows test failures Message-ID: Ben, Phyx, and other CI folk 'sh validate -fast' still gives a lot of failures on Window. The output is below. I would be so good to get this to zero! (another minor thing is that it would be great to eliminate the long path at the beginning - this is platform independent - I have to delete manually many times each day. Thanks Simon Unexpected passes: /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/rts/T9405.run T9405 [unexpected] (normal) Unexpected failures: /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/driver/T14452.run T14452 [bad stdout] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/ghci/linking/ghcilink001.run ghcilink001 [bad exit code] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/ghci/prog010/ghci.prog010.run ghci.prog010 [bad exit code] (ghci) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/ghci/scripts/ghci050.run ghci050 [bad exit code] (ghci) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/ghci/should_run/T14963a.run T14963a [bad exit code] (ghci) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/ghci.debugger/scripts/print012.run print012 [bad exit code] (ghci) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/ghci.debugger/scripts/print016.run print016 [bad exit code] (ghci) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/ghci.debugger/scripts/break019.run break019 [bad exit code] (ghci) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/ghci.debugger/scripts/break028.run break028 [bad exit code] (ghci) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/ghci.debugger/scripts/dynbrk002.run dynbrk002 [bad exit code] (ghci) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/ghci.debugger/scripts/T2740.run T2740 [bad exit code] (ghci) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/indexed-types/should_fail/T7102a.run T7102a [bad exit code] (ghci) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/plugins/plugin-recomp-change.run plugin-recomp-change [bad exit code] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/rts/T10672/T10672_x64.run T10672_x64 [bad exit code] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/th/TH_spliceGuard.run TH_spliceGuard [exit code non-0] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/th/TH_overlaps.run TH_overlaps [exit code non-0] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/th/T5886.run T5886 [exit code non-0] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/th/T10697_decided_3.run T10697_decided_3 [exit code non-0] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/th/T11629.run T11629 [exit code non-0] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/libraries/base/tests/T4006.run T4006 [bad stdout] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/libraries/base/tests/IO/environment001.run environment001 [bad stdout] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/ghci/should_run/T15633b.run T15633b [bad exit code] (ghci) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/plugins/plugins07.run plugins07 [bad exit code] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/plugins/plugins09.run plugins09 [bad stdout] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/plugins/plugins10.run plugins10 [bad stdout] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/plugins/plugins11.run plugins11 [bad stdout] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/plugins/T10420.run T10420 [bad exit code] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/plugins/plugin-recomp-pure.run plugin-recomp-pure [bad exit code] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/plugins/plugin-recomp-impure.run plugin-recomp-impure [bad exit code] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/plugins/plugin-recomp-flags.run plugin-recomp-flags [bad exit code] (normal) Framework failures: /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/perf/compiler/MultiLayerModules.run MultiLayerModules [runTest] (Unhandled exception during cleanup: Unable to remove folder '/c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/perf/compiler/MultiLayerModules.run': [Errno 13] Permission denied: '/c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/perf/compiler/MultiLayerModules.run' Unable to start current test.) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/libraries/base/tests/IO/T3307.run T3307 [normal] ('latin-1' codec can't encode characters in position 24-25: ordinal not in range(256)) -------------- next part -------------- An HTML attachment was scrubbed... URL: From lonetiger at gmail.com Fri Nov 30 08:04:37 2018 From: lonetiger at gmail.com (Phyx) Date: Fri, 30 Nov 2018 08:04:37 +0000 Subject: Windows test failures In-Reply-To: References: Message-ID: Hi Simon, Could you try rerunning those failing tests with make TEST? No threads? I have been trying to clean up the testsuite and there should be only 3 failing tests, two plugin tests with bad stdout and T10672_x64 which I am looking into. I have however noticed that the testsuite has become increasingly unstable under threads for some reason. I also haven't run trunk yet since last week so they could be new.. But rerunning the fails with no threads should give a better idea. Regards, Tamar On Fri, Nov 30, 2018, 07:46 Simon Peyton Jones via ghc-devs < ghc-devs at haskell.org> wrote: > Ben, Phyx, and other CI folk > > ‘sh validate –fast’ still gives a lot of failures on Window. The output > is below. I would be so good to get this to zero! > > (another minor thing is that it would be great to eliminate the long path > at the beginning – this is platform independent – I have to delete manually > many times each day. > > Thanks > > Simon > > Unexpected passes: > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/rts/T9405.run T9405 [unexpected] (normal) > > > > Unexpected failures: > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/driver/T14452.run T14452 [bad stdout] > (normal) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/ghci/linking/ghcilink001.run ghcilink001 [bad exit > code] (normal) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/ghci/prog010/ghci.prog010.run ghci.prog010 [bad exit > code] (ghci) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/ghci/scripts/ghci050.run ghci050 [bad exit code] > (ghci) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/ghci/should_run/T14963a.run T14963a [bad exit code] > (ghci) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/ghci.debugger/scripts/print012.run print012 [bad exit code] > (ghci) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/ghci.debugger/scripts/print016.run print016 [bad exit code] > (ghci) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/ghci.debugger/scripts/break019.run break019 [bad exit code] > (ghci) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/ghci.debugger/scripts/break028.run break028 [bad exit code] > (ghci) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/ghci.debugger/scripts/dynbrk002.run dynbrk002 [bad exit > code] (ghci) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/ghci.debugger/scripts/T2740.run T2740 [bad exit code] > (ghci) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/indexed-types/should_fail/T7102a.run T7102a [bad exit code] > (ghci) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/plugins/plugin-recomp-change.run plugin-recomp-change > [bad exit code] (normal) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/rts/T10672/T10672_x64.run T10672_x64 [bad exit > code] (normal) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/th/TH_spliceGuard.run TH_spliceGuard [exit > code non-0] (normal) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/th/TH_overlaps.run TH_overlaps [exit code > non-0] (normal) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/th/T5886.run T5886 [exit code non-0] > (normal) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/th/T10697_decided_3.run T10697_decided_3 [exit > code non-0] (normal) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/th/T11629.run T11629 [exit code non-0] > (normal) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/libraries/base/tests/T4006.run T4006 [bad stdout] > (normal) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/libraries/base/tests/IO/environment001.run environment001 [bad > stdout] (normal) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/ghci/should_run/T15633b.run T15633b [bad exit code] > (ghci) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/plugins/plugins07.run plugins07 [bad exit > code] (normal) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/plugins/plugins09.run plugins09 [bad stdout] > (normal) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/plugins/plugins10.run plugins10 [bad stdout] > (normal) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/plugins/plugins11.run plugins11 [bad stdout] > (normal) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/plugins/T10420.run T10420 [bad exit code] > (normal) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/plugins/plugin-recomp-pure.run plugin-recomp-pure [bad > exit code] (normal) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/plugins/plugin-recomp-impure.run plugin-recomp-impure > [bad exit code] (normal) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/plugins/plugin-recomp-flags.run plugin-recomp-flags [bad > exit code] (normal) > > > > Framework failures: > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/perf/compiler/MultiLayerModules.run MultiLayerModules [runTest] > (Unhandled exception during cleanup: Unable to remove folder > '/c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/perf/compiler/MultiLayerModules.run': [Errno 13] Permission denied: > '/c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/perf/compiler/MultiLayerModules.run' > > Unable to start current test.) > > /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test > spaces/libraries/base/tests/IO/T3307.run T3307 [normal] ('latin-1' codec > can't encode characters in position 24-25: ordinal not in range(256)) > > > _______________________________________________ > 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 csaba.hruska at gmail.com Fri Nov 30 08:17:59 2018 From: csaba.hruska at gmail.com (Csaba Hruska) Date: Fri, 30 Nov 2018 09:17:59 +0100 Subject: Writing a simple Core evaluator, having trouble with name lookups In-Reply-To: References: Message-ID: Hi! I can give some info for your second question. GHC uses wired-in id's for the primitives and some other AST construction too. Read more here: https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/WiredIn Regarding the names you can use qualified (module + occ) names for exported ids. (see: *Var.isExportedId*). For non exported Id's you can rely on unique values. Use the *Name.nameModule_maybe* and *Name.getName* function to get the id's module name. In my project I export STG for further compilation. Here is the conversion code with proper name conversion: https://github.com/grin-tech/ghc-grin/blob/master/ghc-dump-core/GhcDump_StgConvert.hs I've also learned that GHC wraps the* Main.main* function with another function called *:Main.main* which is the first function called by the RTS. Cheers, Csaba On Tue, Nov 27, 2018 at 7:00 PM Christopher Done wrote: > Hi all, > > I'm attempting to make a simple evaluator for GHC core, but I'm not > clear on how to reliably looking up names. I'm compiling each of > ghc-prim, integer-simple and base with a patched version of GHC which > performs an extra output step with the Core AST to a file for each > module. > > Later, I load those files in. So for an input Haskell file like this: > > module Main (main,Foo(..)) where > class Foo a where foo :: a -> Int > instance Foo Int where foo x = x * x > instance Foo Char where foo x = 99 > main = print (foo (123 :: Int)) > > I have an output set of bindings like this: > > https://gist.github.com/chrisdone/cb05a77d3fcb081a4580b5f85289674a > > One thing that I immediately notice is that the names of things are > completely non-unique, especially in generated names. So here are two > implementations of the method "foo" for the class "Foo": > > ( Id {idStableName = "main:Main:$cfoo", idUnique = Unique > 6989586621679010917}, ...) -- Int > ( Id {idStableName = "main:Main:$cfoo", idUnique = Unique > 6989586621679010923}, ...) -- Char > > So e.g. the instance for "Foo Int" refers to the above method > implementation via its Unique (6989586621679010923): > > ( Id > {idStableName = "main:Main:$fFooInt", idUnique = Unique > 8214565720323784705} > , CastE > (VarE > (Id > { idStableName = "main:Main:$cfoo" > , idUnique = Unique 6989586621679010923 <---- HERE > }))) > > At first, I thought I would use the Unique associated with every Name to > make a lookup. This is completely reliable within one GHC compilation, > but I've read in the docs that it's not stable across multiple > invocations? What does that mean for my case? > > Another thing I notice is that type-class methods are not generated at > the core level. I have, for example, this method call that provides it > the instance dictionary, > > (AppE > (AppE > (VarE > (Id > { idStableName = "main:Main:foo" > , idUnique = Unique 8214565720323784707 <---- MISSING > })) > (TypE (Typ "Int"))) > (VarE > (Id > { idStableName = "main:Main:$fFooInt" > , idUnique = Unique 8214565720323784705 > }))) > > But the "main:Main:foo" (8214565720323784707) is not produced in the > CoreProgram, it seems. My compile step is very simple: > > compile :: > GHC.GhcMonad m > => GHC.ModSummary > -> m [CoreSyn.Bind GHC.Var] > compile modSummary = do > parsedModule <- GHC.parseModule modSummary > typecheckedModule <- GHC.typecheckModule parsedModule > desugared <- GHC.desugarModule typecheckedModule > let binds = GHC.mg_binds (GHC.dm_core_module desugared) > pure binds > > It simply gets the bindings and that's all from the ModGuts. > > mg_binds :: !CoreProgram > > Two questions: > > 1) How do I recognize class methods when I see one, like the > "main:Main:foo" above? > > Maybe this? isClassOpId_maybe :: Id -> Maybe Class > > Is an "op" what GHC calls type-class methods? > > 2) If I compile e.g. ghc-prim and that generates a binding Name with ID > 123, and then I compile base -- will the ID 123 be re-used by base > for something else, or will any reference to 123 in the compiled > Names for base refer ONLY to that one in ghc-prim? In other words, > when GHC loads the iface for ghc-prim, does it generate a fresh set > of names for everything in ghc-prim, or does it load them from file? > > Cheers! > _______________________________________________ > 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 chrisdone at gmail.com Fri Nov 30 11:23:45 2018 From: chrisdone at gmail.com (Christopher Done) Date: Fri, 30 Nov 2018 11:23:45 +0000 Subject: Writing a simple Core evaluator, having trouble with name lookups In-Reply-To: References: Message-ID: Hi Csaba, Thanks for your answer. I think I'm doing something very similar to you. I'm converting the GHC AST to my own AST with this code: https://gist.github.com/chrisdone/96e228f12bdbc3c43d06718467e69029#file-main-hs-L815--L915 I have an Id type that's similar to yours, data Id = Id { idStableName :: {-# UNPACK #-}!ByteString , idUnique :: {-# UNPACK #-}!Unique , idCategory :: !Cat } deriving (Generic, Data, Typeable, Eq, Show, Ord) And (I think) I've solved my first question by adding that category field, which can be one of: data Cat = ValCat | DataCat | ClassCat deriving (Generic, Data, Typeable, Eq, Show, Ord) When an expression like this comes along: AppE (AppE (VarE (Id { idStableName = "main:Main.C:Wiggle" , idUnique = Unique 8214565720323785205 , idCategory = ClassCat })) (TypE (Typ "Int"))) (VarE (Id { idStableName = "main:Main.$cfoo" , idUnique = Unique 6989586621679010971 , idCategory = ValCat })) VarE (Id { idStableName = "main:Main.$cbar" , idUnique = Unique 6989586621679010975 , idCategory = ValCat }) It constructs a class dictionary for the class "Wiggle", with the methods "foo" and "bar", and the interpreter treats Wiggle as a regular data constructor. Meanwhile, when an nth class method (like "main:Main.$cfoo") is resolved, it produces a Method, and when applying a method to a data constructor Wiggle, the interpreter access the nth slot. That works out. An example is here: https://gist.github.com/chrisdone/771292425a9f1bb428ef4eda3779dc40 See how the "main:Main.$fWiggleInt" is resolved to the above dictionary. As for the second question, and your answer, I am a bit puzzled, maybe you can clarify? > Regarding the names you can use qualified (module + occ) names for > exported ids. (see: Var.isExportedId). > > For non exported Id's you can rely on unique values. You say that for exported names I can rely soley on the stable name (package+module+ident), and for internal IDs I can use the Unique? I believe that's what I'm reproducing, here. The following name isn't resolved: Id { idStableName = "base:GHC.Base.$fApplicativeIO" , idUnique = Unique 8214565720323784738 , idCategory = ValCat } If I list all bindings available, I find this name, which has a different Unique: Id { idStableName = "base:GHC.Base.$fApplicativeIO" , idUnique = Unique 8214565720323793553 <--- differing , idCategory = ValCat } So if I were to apply your approach and do exported lookups by idStableName, and local-module lookups (beta substitution) by Unique, it should work out. The question is whether "base:GHC.Base.$fApplicativeIO" is actually exported -- I presume all instance dictionaries are exported. I will give it a try and report back to you! Cheers! From klebinger.andreas at gmx.at Fri Nov 30 11:36:55 2018 From: klebinger.andreas at gmx.at (Andreas Klebinger) Date: Fri, 30 Nov 2018 12:36:55 +0100 Subject: Considerations for Control flow hint implementation. Message-ID: <5C0120D7.1010608@gmx.at> Hello Devs, I've started thinking about the implementation of https://github.com/ghc-proposals/ghc-proposals/pull/182 recently. (Add control flow hint pragmas.) For this purpose I've rebased D4327 "WIP: Add likelyhood to alternatives from stg onwards" which already does a lot of the work at the Cmm/Stg level. The issue I ask you for feedback now is how to best attach branch weights to case alternatives in core. My prefered approach would be to expand core data types to include them unconditionally. While this is quite far reaching in the amount of code it touches it would be rather straight forward to implement: Alternative 1: Putting the weights directly into the case alternative tuple: + It it's trivial to check which places manipulate case alternatives as they will initially fail to compile. + It's very mechanical, almost all use sites won't actually change the weight. + It's easy to keep this working going forward as any new optimizations can't "forget" they have to consider them. - It will introduce a cost in compiler performance. - New optimization who don't have to care about branchweights still have to at least pipe them through. - While syntactically heavy in terms of real complexity it's a simply approach. Alternative 2: Putting the weights into the case constructor. + Might give better compiler performance as I expect us to rebuild cases less often than alternatives. - Seems kind of clunky. - Weaker coupling between case alternatives and their weights. Or we could use ticks: + There is some machinery already there + Can be turned off for -O0 + Can be ignored when convenient. - Can be ignored when convenient. - Very weak coupling between case alternatives and their weights. - The existing machinery doesn't exactly match the needs of this. - We would have to extend tick semantics to a degree where complexity might grow too large for me to successfully implement this. - If new optimizations end up just removing these ticks because they are allowed to then the whole exercise becomes rather pointless. - Makes it harder to ensure all relevant code paths in GHC are actually updated. In particular there is currently no tick category which can stick to case alternatives but just get's removed in case it get's in the way of optimizations. The closest match is SoftScope which allows ticks to be floated up, something that could impact performance quite badly in this case. As then we might float something intended to mark a branch as unlikely into another branch that is actually along the hot path. I think the core variant(s) mostly stand and fall with the actual compile time impact. For -O0 the impact would be negligible as the compile time is already dominated by codegen and typechecking. For the rest it's hard to say. So I'm looking for feedback on this. Maybe you have other suggestions I haven't considered? How much compile time cost increase would be acceptable for what kind of performance boost? Cheers, Andreas Klebinger -------------- next part -------------- An HTML attachment was scrubbed... URL: From csaba.hruska at gmail.com Fri Nov 30 11:46:37 2018 From: csaba.hruska at gmail.com (Csaba Hruska) Date: Fri, 30 Nov 2018 12:46:37 +0100 Subject: Writing a simple Core evaluator, having trouble with name lookups In-Reply-To: References: Message-ID: Just to clarify, for exported names ignore the unique value completely and use module name + occurrence name. In your case that is the idStableName field. For non exported names use idStableName + idUnique. I'll also check your project. Cheers, Csaba On Fri, Nov 30, 2018 at 12:23 PM Christopher Done wrote: > Hi Csaba, > > Thanks for your answer. I think I'm doing something very similar to > you. I'm converting the GHC AST to my own AST with this code: > > > https://gist.github.com/chrisdone/96e228f12bdbc3c43d06718467e69029#file-main-hs-L815--L915 > > I have an Id type that's similar to yours, > > data Id = Id > { idStableName :: {-# UNPACK #-}!ByteString > , idUnique :: {-# UNPACK #-}!Unique > , idCategory :: !Cat > } deriving (Generic, Data, Typeable, Eq, Show, Ord) > > And (I think) I've solved my first question by adding that category > field, which can be one of: > > data Cat > = ValCat > | DataCat > | ClassCat > deriving (Generic, Data, Typeable, Eq, Show, Ord) > > When an expression like this comes along: > > AppE > (AppE > (VarE > (Id > { idStableName = "main:Main.C:Wiggle" > , idUnique = Unique 8214565720323785205 > , idCategory = ClassCat > })) > (TypE (Typ "Int"))) > (VarE > (Id > { idStableName = "main:Main.$cfoo" > , idUnique = Unique 6989586621679010971 > , idCategory = ValCat > })) > VarE > (Id > { idStableName = "main:Main.$cbar" > , idUnique = Unique 6989586621679010975 > , idCategory = ValCat > }) > > It constructs a class dictionary for the class "Wiggle", with the > methods "foo" and "bar", and the interpreter treats Wiggle as a regular > data constructor. Meanwhile, when an nth class method (like > "main:Main.$cfoo") is resolved, it produces a Method, and when applying > a method to a data constructor Wiggle, the interpreter access the nth > slot. > > That works out. An example is here: > > https://gist.github.com/chrisdone/771292425a9f1bb428ef4eda3779dc40 > > See how the "main:Main.$fWiggleInt" is resolved to the above dictionary. > > As for the second question, and your answer, I am a bit puzzled, maybe > you can clarify? > > > Regarding the names you can use qualified (module + occ) names for > > exported ids. (see: Var.isExportedId). > > > > For non exported Id's you can rely on unique values. > > You say that for exported names I can rely soley on the stable name > (package+module+ident), and for internal IDs I can use the Unique? > > I believe that's what I'm reproducing, here. The following name isn't > resolved: > > Id > { idStableName = "base:GHC.Base.$fApplicativeIO" > , idUnique = Unique 8214565720323784738 > , idCategory = ValCat > } > > If I list all bindings available, I find this name, which has a > different Unique: > > Id > { idStableName = "base:GHC.Base.$fApplicativeIO" > , idUnique = Unique 8214565720323793553 <--- differing > , idCategory = ValCat > } > > So if I were to apply your approach and do exported lookups by > idStableName, and local-module lookups (beta substitution) by Unique, it > should work out. > > The question is whether "base:GHC.Base.$fApplicativeIO" is actually > exported -- I presume all instance dictionaries are exported. > > I will give it a try and report back to you! > > Cheers! > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Fri Nov 30 12:22:12 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 30 Nov 2018 12:22:12 +0000 Subject: Considerations for Control flow hint implementation. In-Reply-To: <5C0120D7.1010608@gmx.at> References: <5C0120D7.1010608@gmx.at> Message-ID: Alternative 1: Putting the weights directly into the case alternative tuple Rather than putting it in the tuple, you could put it in the AltCon type Alt b = (AltCon, [b], Expr b) data AltCon = DataAlt Freq DataCon | LitAlt Freq Literal | DEFAULT Freq My guess is that a lot more current code pattern matches on those triples than pattern matches on the AltCon itself. And AltCon isn't used for anything else Simon From: ghc-devs On Behalf Of Andreas Klebinger Sent: 30 November 2018 11:37 To: ghc-devs at haskell.org Subject: Considerations for Control flow hint implementation. Hello Devs, I've started thinking about the implementation of https://github.com/ghc-proposals/ghc-proposals/pull/182 recently. (Add control flow hint pragmas.) For this purpose I've rebased D4327 "WIP: Add likelyhood to alternatives from stg onwards" which already does a lot of the work at the Cmm/Stg level. The issue I ask you for feedback now is how to best attach branch weights to case alternatives in core. My prefered approach would be to expand core data types to include them unconditionally. While this is quite far reaching in the amount of code it touches it would be rather straight forward to implement: Alternative 1: Putting the weights directly into the case alternative tuple: + It it's trivial to check which places manipulate case alternatives as they will initially fail to compile. + It's very mechanical, almost all use sites won't actually change the weight. + It's easy to keep this working going forward as any new optimizations can't "forget" they have to consider them. - It will introduce a cost in compiler performance. - New optimization who don't have to care about branchweights still have to at least pipe them through. - While syntactically heavy in terms of real complexity it's a simply approach. Alternative 2: Putting the weights into the case constructor. + Might give better compiler performance as I expect us to rebuild cases less often than alternatives. - Seems kind of clunky. - Weaker coupling between case alternatives and their weights. Or we could use ticks: + There is some machinery already there + Can be turned off for -O0 + Can be ignored when convenient. - Can be ignored when convenient. - Very weak coupling between case alternatives and their weights. - The existing machinery doesn't exactly match the needs of this. - We would have to extend tick semantics to a degree where complexity might grow too large for me to successfully implement this. - If new optimizations end up just removing these ticks because they are allowed to then the whole exercise becomes rather pointless. - Makes it harder to ensure all relevant code paths in GHC are actually updated. In particular there is currently no tick category which can stick to case alternatives but just get's removed in case it get's in the way of optimizations. The closest match is SoftScope which allows ticks to be floated up, something that could impact performance quite badly in this case. As then we might float something intended to mark a branch as unlikely into another branch that is actually along the hot path. I think the core variant(s) mostly stand and fall with the actual compile time impact. For -O0 the impact would be negligible as the compile time is already dominated by codegen and typechecking. For the rest it's hard to say. So I'm looking for feedback on this. Maybe you have other suggestions I haven't considered? How much compile time cost increase would be acceptable for what kind of performance boost? Cheers, Andreas Klebinger -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Fri Nov 30 13:58:53 2018 From: ben at smart-cactus.org (Ben Gamari) Date: Fri, 30 Nov 2018 08:58:53 -0500 Subject: Writing a simple Core evaluator, having trouble with name lookups In-Reply-To: References: Message-ID: <87woouy8dk.fsf@smart-cactus.org> Christopher Done writes: > Hi all, > > I'm attempting to make a simple evaluator for GHC core, but I'm not > clear on how to reliably looking up names. I'm compiling each of > ghc-prim, integer-simple and base with a patched version of GHC which > performs an extra output step with the Core AST to a file for each > module. > ... > > Two questions: > > 1) How do I recognize class methods when I see one, like the > "main:Main:foo" above? > > Maybe this? isClassOpId_maybe :: Id -> Maybe Class > > Is an "op" what GHC calls type-class methods? > Yes, I believe this will do what you are looking for. > 2) If I compile e.g. ghc-prim and that generates a binding Name with ID > 123, and then I compile base -- will the ID 123 be re-used by base > for something else, or will any reference to 123 in the compiled > Names for base refer ONLY to that one in ghc-prim? In other words, > when GHC loads the iface for ghc-prim, does it generate a fresh set > of names for everything in ghc-prim, or does it load them from file? > Perhaps I am misunderstanding Csaba's point, but I don't believe you can rely on uniques here. Except in the case of known key things (which is certainly the minority of things), uniques are generated afresh with every GHC compilation. While it's possible that the same compiler run will happen to produce the same Name/Unique correspondence, this is not guaranteed and may be broken by GHC `-j`, different recompilation-checker conditions, etc. The only part of the name that we guarantee will be stable across compiler sessions is the OccName of Names coming from interface files. The uniqueness of these names is ensured when we create the interface file by TidyPgm.chooseExternalIds. In principle you could do something similar to the entire Core program before you dump it. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From rsx at bluewin.ch Fri Nov 30 14:15:07 2018 From: rsx at bluewin.ch (Roland Senn) Date: Fri, 30 Nov 2018 15:15:07 +0100 Subject: Windows test failures In-Reply-To: References: Message-ID: <1543587307.1692.1.camel@bluewin.ch> Hi, I'm the author of test T14452. This is test #2 in the list of failing tests of Simon. I looked into it and found, indeed, this test is broken under Windows. Under Windows we get quotes around the -O3 ("-O3") but not under Linux.  I'll reopen Trac ticket #14452 and prepare a patch with an improved test!    Roland   Am Freitag, den 30.11.2018, 07:46 +0000 schrieb Simon Peyton Jones via ghc-devs: > Ben, Phyx, and other CI folk > ‘sh validate –fast’ still gives a lot of failures on Window.  The > output is below. I would be so good to get this to zero! > (another minor thing is that it would be great to eliminate the long > path at the beginning – this is platform independent – I have to > delete manually many times each day. > Thanks > Simon > Unexpected passes: >    /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test   > spaces/rts/T9405.run  T9405 [unexpected] (normal) >   > Unexpected failures: >    /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test   > spaces/driver/T14452.run                           T14452 [bad > stdout] (normal) >    /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test   > spaces/ghci/linking/ghcilink001.run                ghcilink001 [bad > exit code] (normal) >    /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test   > spaces/ghci/prog010/ghci.prog010.run               ghci.prog010 [bad > exit code] (ghci) >    /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test   > spaces/ghci/scripts/ghci050.run                    ghci050 [bad exit > code] (ghci) >    /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test   > spaces/ghci/should_run/T14963a.run                 T14963a [bad exit > code] (ghci) >    /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test   > spaces/ghci.debugger/scripts/print012.run          print012 [bad exit > code] (ghci) >    /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test   > spaces/ghci.debugger/scripts/print016.run          print016 [bad exit > code] (ghci) >    /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test   > spaces/ghci.debugger/scripts/break019.run          break019 [bad exit > code] (ghci) >    /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test   > spaces/ghci.debugger/scripts/break028.run          break028 [bad exit > code] (ghci) >    /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test   > spaces/ghci.debugger/scripts/dynbrk002.run         dynbrk002 [bad > exit code] (ghci) >    /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test   > spaces/ghci.debugger/scripts/T2740.run             T2740 [bad exit > code] (ghci) >    /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test   > spaces/indexed-types/should_fail/T7102a.run        T7102a [bad exit > code] (ghci) >    /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test   > spaces/plugins/plugin-recomp-change.run            plugin-recomp- > change [bad exit code] (normal) >    /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test   > spaces/rts/T10672/T10672_x64.run                   T10672_x64 [bad > exit code] (normal) >    /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test   > spaces/th/TH_spliceGuard.run                       TH_spliceGuard > [exit code non-0] (normal) >    /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test   > spaces/th/TH_overlaps.run                          TH_overlaps [exit > code non-0] (normal) >    /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test   > spaces/th/T5886.run                                T5886 [exit code > non-0] (normal) >    /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test   > spaces/th/T10697_decided_3.run                     T10697_decided_3 > [exit code non-0] (normal) >    /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test   > spaces/th/T11629.run                               T11629 [exit code > non-0] (normal) >    /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test   > spaces/libraries/base/tests/T4006.run              T4006 [bad stdout] > (normal) >    /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test   > spaces/libraries/base/tests/IO/environment001.run  environment001 > [bad stdout] (normal) >    /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test   > spaces/ghci/should_run/T15633b.run                 T15633b [bad exit > code] (ghci) >    /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test   > spaces/plugins/plugins07.run                       plugins07 [bad > exit code] (normal) >    /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test   > spaces/plugins/plugins09.run                       plugins09 [bad > stdout] (normal) >    /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test   > spaces/plugins/plugins10.run                       plugins10 [bad > stdout] (normal) >    /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test   > spaces/plugins/plugins11.run                       plugins11 [bad > stdout] (normal) >    /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test   > spaces/plugins/T10420.run                          T10420 [bad exit > code] (normal) >    /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test   > spaces/plugins/plugin-recomp-pure.run              plugin-recomp-pure > [bad exit code] (normal) >    /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test   > spaces/plugins/plugin-recomp-impure.run            plugin-recomp- > impure [bad exit code] (normal) >    /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test   > spaces/plugins/plugin-recomp-flags.run             plugin-recomp- > flags [bad exit code] (normal) >   > Framework failures: >    /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test   > spaces/perf/compiler/MultiLayerModules.run  MultiLayerModules > [runTest] (Unhandled exception during cleanup: Unable to remove > folder '/c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test   >  spaces/perf/compiler/MultiLayerModules.run': [Errno 13] Permission > denied: '/c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test   > spaces/perf/compiler/MultiLayerModules.run' > Unable to start current test.) >    /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test   > spaces/libraries/base/tests/IO/T3307.run    T3307 [normal] ('latin-1' > codec can't encode characters in position 24-25: ordinal not in > range(256)) >   > > > > > _______________________________________________ > 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 sgraf1337 at gmail.com Fri Nov 30 15:32:10 2018 From: sgraf1337 at gmail.com (Sebastian Graf) Date: Fri, 30 Nov 2018 16:32:10 +0100 Subject: perf.haskell.org functional again In-Reply-To: <1509318833.9503.4.camel@joachim-breitner.de> References: <2C073EBF-8019-4734-9617-BE9A577EEEA9@joachim-breitner.de> <1508816773.31327.5.camel@joachim-breitner.de> <1509318833.9503.4.camel@joachim-breitner.de> Message-ID: Hi, just came here to resurrect the thread and point out that nofib currently isn't really run in parallel: https://ghc.haskell.org/trac/ghc/ticket/15976#ticket Also it's unclear to me how that would be possible without rewriting the whole benchmark harness in Python or Haskell, because make parallelism would probably interleave outputs of different rules, giving nofib-analyse a hard time. Greetings Sebastian Am Mo., 30. Okt. 2017 um 00:14 Uhr schrieb Joachim Breitner < mail at joachim-breitner.de>: > Hi, > > Am Sonntag, den 29.10.2017, 23:58 +0100 schrieb Sebastian Graf: > > Hi, > > > > just wanted to throw in the idea of parallelising the benchmark suite > > (hurts to even write that, but cachegrind) to speed up the build, if > > ever need be. > > https://github.com/nomeata/gipeda/blob/master/ghc/run-speed.sh#L143 > > good idea indeed – I’ve been doing that since I started running > cachegrind ;-) > > > Joachim > > -- > Joachim Breitner > mail at joachim-breitner.de > http://www.joachim-breitner.de/ > _______________________________________________ > 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 carter.schonwald at gmail.com Fri Nov 30 16:31:59 2018 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Fri, 30 Nov 2018 11:31:59 -0500 Subject: make slow test suite failures (at least on OSX ) for 8.6 branch Message-ID: to reproduce cd testsuite make slow TEST="EtaExpandLevPoly ManyAlternatives ManyConstructors MultiLayerModules T10370 T11535 T12707 T13379 T13701 T13719 T14683 T14697 T14936 T15349 T4334 T6132 T7702 T9203 T9630 ghci063 haddock.Cabal haddock.base haddock.compiler hpc_fork signals004 space_leak_001" -------------------- Unexpected results from: TEST="EtaExpandLevPoly ManyAlternatives ManyConstructors MultiLayerModules T10370 T11535 T12707 T13379 T13701 T13719 T14683 T14697 T14936 T15349 T4334 T6132 T7702 T9203 T9630 ghci063 haddock.Cabal haddock.base haddock.compiler hpc_fork signals004 space_leak_001" SUMMARY for test run started at Thu Nov 29 21:03:34 2018 EST 0:55:09 spent to go through 26 total tests, which gave rise to 137 test cases, of which 20 were skipped 0 had missing libraries 63 expected passes 0 expected failures 4 caused framework failures 0 caused framework warnings 6 unexpected passes 6 unexpected failures 38 unexpected stat failures Unexpected passes: runghc/T6132.run T6132 [unexpected] (normal) runghc/T6132.run T6132 [unexpected] (hpc) runghc/T6132.run T6132 [unexpected] (optasm) runghc/T6132.run T6132 [unexpected] (profasm) typecheck/should_run/EtaExpandLevPoly.run EtaExpandLevPoly [unexpected] (profasm) typecheck/should_run/EtaExpandLevPoly.run EtaExpandLevPoly [unexpected] (profthreaded) Unexpected failures: deriving/should_run/T11535.run T11535 [bad exit code] (ghci) ghci/scripts/ghci063.run ghci063 [bad stderr] (ghci) simplCore/should_compile/T7702.run T7702 [exit code non-0] (profasm) ../../libraries/base/tests/T15349.run T15349 [bad exit code] (ghci) ../../libraries/hpc/tests/fork/hpc_fork.run hpc_fork [bad heap profile] (profasm) ../../libraries/unix/tests/signals004.run signals004 [bad exit code] (threaded2) Unexpected stat failures: perf/compiler/T10370.run T10370 [stat not good enough] (optasm) perf/compiler/T12707.run T12707 [stat not good enough] (hpc) perf/compiler/T12707.run T12707 [stat not good enough] (optasm) perf/compiler/T12707.run T12707 [stat not good enough] (profasm) perf/compiler/T13379.run T13379 [stat not good enough] (hpc) perf/compiler/MultiLayerModules.run MultiLayerModules [stat not good enough] (optasm) perf/compiler/ManyConstructors.run ManyConstructors [stat not good enough] (hpc) perf/compiler/ManyConstructors.run ManyConstructors [stat not good enough] -------------- next part -------------- An HTML attachment was scrubbed... URL: From csaba.hruska at gmail.com Fri Nov 30 16:34:35 2018 From: csaba.hruska at gmail.com (Csaba Hruska) Date: Fri, 30 Nov 2018 17:34:35 +0100 Subject: Writing a simple Core evaluator, having trouble with name lookups In-Reply-To: <87woouy8dk.fsf@smart-cactus.org> References: <87woouy8dk.fsf@smart-cactus.org> Message-ID: Hi Ben, I thought that it is possible to rely on unique values *in case of non exported Ids* because they are local to a specific module and can not appear in expressions in other modules because they are not exported. Do I miss something? Cheers, Csaba On Fri, Nov 30, 2018 at 2:59 PM Ben Gamari wrote: > Christopher Done writes: > > > Hi all, > > > > I'm attempting to make a simple evaluator for GHC core, but I'm not > > clear on how to reliably looking up names. I'm compiling each of > > ghc-prim, integer-simple and base with a patched version of GHC which > > performs an extra output step with the Core AST to a file for each > > module. > > > ... > > > > Two questions: > > > > 1) How do I recognize class methods when I see one, like the > > "main:Main:foo" above? > > > > Maybe this? isClassOpId_maybe :: Id -> Maybe Class > > > > Is an "op" what GHC calls type-class methods? > > > Yes, I believe this will do what you are looking for. > > > 2) If I compile e.g. ghc-prim and that generates a binding Name with ID > > 123, and then I compile base -- will the ID 123 be re-used by base > > for something else, or will any reference to 123 in the compiled > > Names for base refer ONLY to that one in ghc-prim? In other words, > > when GHC loads the iface for ghc-prim, does it generate a fresh set > > of names for everything in ghc-prim, or does it load them from file? > > > Perhaps I am misunderstanding Csaba's point, but I don't believe you can > rely on uniques here. Except in the case of known key things (which is > certainly the minority of things), uniques are generated afresh with > every GHC compilation. While it's possible that the same compiler run > will happen to produce the same Name/Unique correspondence, this is not > guaranteed and may be broken by GHC `-j`, different > recompilation-checker conditions, etc. > > The only part of the name that we guarantee will be stable across > compiler sessions is the OccName of Names coming from interface files. > The uniqueness of these names is ensured when we create the interface > file by TidyPgm.chooseExternalIds. In principle you could do something > similar to the entire Core program before you dump it. > > Cheers, > > - Ben > _______________________________________________ > 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 ben at well-typed.com Fri Nov 30 18:20:33 2018 From: ben at well-typed.com (Ben Gamari) Date: Fri, 30 Nov 2018 13:20:33 -0500 Subject: Writing a simple Core evaluator, having trouble with name lookups In-Reply-To: References: <87woouy8dk.fsf@smart-cactus.org> Message-ID: <87r2f2xw9e.fsf@smart-cactus.org> Csaba Hruska writes: > Hi Ben, > > I thought that it is possible to rely on unique values *in case of non > exported Ids* because they are local to a specific module and can not > appear in expressions in other modules because they are not exported. > Do I miss something? > Uniques should be treated as being non-reproducible across compiler sessions. To make this more concrete: if GHC compiles the same module twice it will not necessarily assign the same uniques to the module's Names. Uniques are derived from local UniqSupplies conjured up at a variety of points in the compilation pipeline (search from mkSplitUniqSupply). These supplies are themselves derived from an impure global counter (see compiler/cbits/genSym.c). The state of this counter (and consequently the uniques derived from it) should be treated as being entirely unpredictable. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From csaba.hruska at gmail.com Fri Nov 30 18:28:07 2018 From: csaba.hruska at gmail.com (Csaba Hruska) Date: Fri, 30 Nov 2018 19:28:07 +0100 Subject: Writing a simple Core evaluator, having trouble with name lookups In-Reply-To: <87r2f2xw9e.fsf@smart-cactus.org> References: <87woouy8dk.fsf@smart-cactus.org> <87r2f2xw9e.fsf@smart-cactus.org> Message-ID: I'm aware that unique names are unique in a GHC invocation. But my statements sill holds. On Fri, Nov 30, 2018 at 7:20 PM Ben Gamari wrote: > Csaba Hruska writes: > > > Hi Ben, > > > > I thought that it is possible to rely on unique values *in case of non > > exported Ids* because they are local to a specific module and can not > > appear in expressions in other modules because they are not exported. > > Do I miss something? > > > Uniques should be treated as being non-reproducible across compiler > sessions. > > To make this more concrete: if GHC compiles the same module twice it > will not necessarily assign the same uniques to the module's Names. > Uniques are derived from local UniqSupplies conjured up at a variety of > points in the compilation pipeline (search from mkSplitUniqSupply). > > These supplies are themselves derived from an impure global counter (see > compiler/cbits/genSym.c). The state of this counter (and consequently > the uniques derived from it) should be treated as being entirely > unpredictable. > > Cheers, > > - Ben > -------------- next part -------------- An HTML attachment was scrubbed... URL: From csaba.hruska at gmail.com Fri Nov 30 21:47:46 2018 From: csaba.hruska at gmail.com (Csaba Hruska) Date: Fri, 30 Nov 2018 22:47:46 +0100 Subject: typePrimRep invariants Message-ID: Hi, I'd like to export the PrimRep of every binder and data con from Haskell modules. I have a modified GHC 8.6 which serializes the PrimRep for every binder during the compilation. It uses the *typePrimRep* function. When my customised GHC compiles the base library it always thows the following error for the *libraries/base/GHC/Err.hs* module. 1. Does that mean that there is hidden requirement for typePrimRep input? 2. If so what are the restrictions? 3. Can you see anything in the Err module source code that could not be a proper input for typePrimRep function? Thanks, Csaba "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -Wall -this-unit-id base-4.12.0.0 -hide-all-packages -i -ilibraries/base/. -ilibraries/base/dist-install/build -Ilibraries/base/dist-install/build -ilibraries/base/dist-install/build/./autogen -Ilibraries/base/dist-install/build/./autogen -Ilibraries/base/include -Ilibraries/base/dist-install/build/include -optP-DOPTIMISE_INTEGER_GCD_LCM -optP-include -optPlibraries/base/dist-install/build/./autogen/cabal_macros.h -package-id ghc-prim-0.5.3 -package-id integer-gmp-1.0.2.0 -package-id rts -this-unit-id base -Wcompat -Wnoncanonical-monad-instances -XHaskell2010 -O2 -haddock -no-user-package-db -rtsopts -Wno-trustworthy-safe -Wno-deprecated-flags -Wnoncanonical-monad-instances -odir libraries/base/dist-install/build -hidir libraries/base/dist-install/build -stubdir libraries/base/dist-install/build -split-sections -dynamic-too -c libraries/base/./GHC/Err.hs -o libraries/base/dist-install/build/GHC/Err.o -dyno libraries/base/dist-install/build/GHC/Err.dyn_o ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.6.2 for x86_64-unknown-linux): runtimeRepPrimRep typePrimRep (a_a1ML :: TYPE r_a1MK) r_a1MK Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable pprPanic, called at compiler/simplStg/RepType.hs:358:5 in ghc:RepType Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug libraries/base/ghc.mk:4: recipe for target 'libraries/base/dist-install/build/GHC/Err.o' failed make[1]: *** [libraries/base/dist-install/build/GHC/Err.o] Error 1 Makefile:122: recipe for target 'all' failed make: *** [all] Error 2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From simonpj at microsoft.com Fri Nov 30 21:49:48 2018 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 30 Nov 2018 21:49:48 +0000 Subject: Windows test failures In-Reply-To: References: Message-ID: At the end of the first test run it would have given a list of tests that failed and a line saying TEST=".... List of tests..." Copy that line and at the root of the checkout do make TEST=".... List of tests..." test -C testsuite/tests (that's uppercase C). This will run everything using one thread. :) OK, done. Results below. Simon /c/code/HEAD$ make TEST="T10420 T10672_x64 T13385 T14452 T15815 T3307 T3319 T4006 TH_scopedTvs environment001 plugin-recomp-change plugin-recomp-flags plugin-recomp-impure plugin-recomp-pure plugins07 plugins09 plugins10 plugins11 plugins13 plugins14 print017" test -C testsuite/tests make: Entering directory '/c/code/HEAD/testsuite/tests' PYTHON="python3" "python3" ../driver/runtests.py -e "ghc_compiler_always_flags='-dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output'" -e config.compiler_debugged=False -e ghc_with_native_codegen=True -e config.have_vanilla=True -e config.have_dynamic=False -e config.have_profiling=False -e ghc_with_threaded_rts=True -e ghc_with_dynamic_rts=False -e config.have_interp=True -e config.unregisterised=False -e config.have_gdb=False -e config.have_readelf=True -e config.ghc_dynamic_by_default=False -e config.ghc_dynamic=False -e ghc_with_smp=True -e ghc_with_llvm=False -e windows=True -e darwin=False -e config.in_tree_compiler=True -e config.cleanup=True -e config.local=True --rootdir=. --config-file=../config/ghc -e 'config.platform="x86_64-unknown-mingw32"' -e 'config.os="mingw32"' -e 'config.arch="x86_64"' -e 'config.wordsize="64"' -e 'config.timeout=int() or config.timeout' -e 'config.exeext=".exe"' -e 'config.top="/c/code/HEAD/testsuite"' --config 'compiler="/c/code/HEAD/inplace/bin/ghc-stage2.exe"' --config 'ghc_pkg="/c/code/HEAD/inplace/bin/ghc-pkg.exe"' --config 'haddock=' --config 'hp2ps="/c/code/HEAD/inplace/bin/hp2ps.exe"' --config 'hpc="/c/code/HEAD/inplace/bin/hpc.exe"' --config 'gs="gs"' --config 'timeout_prog="../timeout/install-inplace/bin/timeout.exe"' -e "config.stage=2" --rootdir=../../libraries/Win32/tests --rootdir=../../libraries/array/tests --rootdir=../../libraries/base/tests --rootdir=../../libraries/binary/tests --rootdir=../../libraries/bytestring/tests --rootdir=../../libraries/containers/tests --rootdir=../../libraries/deepseq/tests --rootdir=../../libraries/directory/tests --rootdir=../../libraries/filepath/tests --rootdir=../../libraries/ghc-compact/tests --rootdir=../../libraries/ghc-heap/tests --rootdir=../../libraries/ghc-prim/tests --rootdir=../../libraries/haskeline/tests --rootdir=../../libraries/hpc/tests --rootdir=../../libraries/pretty/tests --rootdir=../../libraries/process/tests --rootdir=../../libraries/stm/tests --rootdir=../../libraries/template-haskell/tests --rootdir=../../libraries/text/tests \ --only=T10420 --only=T10672_x64 --only=T13385 --only=T14452 --only=T15815 --only=T3307 --only=T3319 --only=T4006 --only=TH_scopedTvs --only=environment001 --only=plugin-recomp-change --only=plugin-recomp-flags --only=plugin-recomp-impure --only=plugin-recomp-pure --only=plugins07 --only=plugins09 --only=plugins10 --only=plugins11 --only=plugins13 --only=plugins14 --only=print017 \ \ \ \ \ \ Timeout is 300 0 Found 398 .T files... Beginning test run at Fri Nov 30 21:07:17 2018 GMTST ====> Scanning ./ado/all.T ====> Scanning ./annotations/should_compile/all.T ====> Scanning ./annotations/should_compile/T13818/all.T …lots more “Scanning” lines… ====> Scanning ../../libraries/ghc-heap/tests/all.T ====> Scanning ../../libraries/hpc/tests/fork/test.T--- driver/T14452.run/T14452.stdout.normalised 2018-11-30 21:07:36.565566000 +0000 +++ driver/T14452.run/T14452.run.stdout.normalised 2018-11-30 21:07:36.567569500 +0000 @@ -1 +1 @@ --O3 +"-O3" --- libraries/base/tests/T4006.run/T4006.stdout.normalised 2018-11-30 21:15:19.867313900 +0000 +++ libraries/base/tests/T4006.run/T4006.run.stdout.normalised 2018-11-30 21:15:19.870787900 +0000 @@ -1,2 +1,2 @@ It works here - + --- libraries/base/tests/IO/environment001.run/environment001.stdout.normalised 2018-11-30 21:16:00.645817500 +0000 +++ libraries/base/tests/IO/environment001.run/environment001.run.stdout.normalised 2018-11-30 21:16:00.654738900 +0000 @@ -1,7 +1,8 @@ - -Test 1: 3 - -Test 2: 1 + + +Test 1: 9 + +Test 2: 3 ! Test 3: 3 ["a","b"] ====> Scanning ../../libraries/hpc/tests/function/test.T ====> Scanning ../../libraries/hpc/tests/function2/test.T ====> Scanning ../../libraries/hpc/tests/ghc_ghci/test.T ====> Scanning ../../libraries/hpc/tests/raytrace/test.T ====> Scanning ../../libraries/hpc/tests/raytrace/tixs/test.T ====> Scanning ../../libraries/hpc/tests/simple/test.T ====> Scanning ../../libraries/hpc/tests/simple/tixs/test.T ====> Scanning ../../libraries/process/tests/all.T ====> Scanning ../../libraries/process/tests/T9775/all.T ====> Scanning ../../libraries/stm/tests/all.T ====> Scanning ../../libraries/template-haskell/tests/all.T =====> T14452(normal) 1 of 21 [0, 0, 0] cd "driver/T14452.run" && $MAKE -s --no-print-directory T14452 Actual stdout output differs from expected: diff -uw "driver/T14452.run/T14452.stdout.normalised" "driver/T14452.run/T14452.run.stdout.normalised" *** unexpected failure for T14452(normal) =====> T13385(ghci) 2 of 21 [0, 1, 0] cd "ghci/scripts/T13385.run" && HC="/c/code/HEAD/inplace/bin/ghc-stage2.exe" HC_OPTS="-dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output -XRebindableSyntax" "/c/code/HEAD/inplace/bin/ghc-stage2.exe" --interactive -v0 -ignore-dot-ghci -fno-ghci-history +RTS -I0.1 -RTS -fghci-leak-check -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output -XRebindableSyntax < T13385.script =====> print017(ghci) 3 of 21 [0, 1, 0] cd "ghci.debugger/scripts/print017.run" && HC="/c/code/HEAD/inplace/bin/ghc-stage2.exe" HC_OPTS="-dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output " "/c/code/HEAD/inplace/bin/ghc-stage2.exe" --interactive -v0 -ignore-dot-ghci -fno-ghci-history +RTS -I0.1 -RTS -fghci-leak-check -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output -ignore-dot-ghci< print017.script =====> print017(ghci-ext) 3 of 21 [0, 1, 0] cd "ghci.debugger/scripts/print017.run" && HC="/c/code/HEAD/inplace/bin/ghc-stage2.exe" HC_OPTS="-dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output " "/c/code/HEAD/inplace/bin/ghc-stage2.exe" --interactive -v0 -ignore-dot-ghci -fno-ghci-history -fexternal-interpreter +RTS -I0.1 -RTS -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output -ignore-dot-ghci< print017.script =====> plugin-recomp-change(normal) 4 of 21 [0, 1, 0] cd "plugins/plugin-recomp-change.run" && $MAKE -s --no-print-directory -C plugin-recomp package.plugins01 TOP=/c/code/HEAD/testsuite cd "plugins/plugin-recomp-change.run" && $MAKE -s --no-print-directory plugin-recomp-change =====> T10672_x64(normal) 5 of 21 [0, 1, 0] cd "rts/T10672/T10672_x64.run" && $MAKE -s --no-print-directory T10672_x64 Timeout happened...killed process "cd "rts/T10672/T10672_x64.run" && $MAKE -s --no-print-directory T10672_x64 "... Wrong exit code for T10672_x64()(expected 0 , actual 99 ) *** unexpected failure for T10672_x64(normal) =====> TH_scopedTvs(normal) 6 of 21 [0, 2, 0] cd "th/TH_scopedTvs.run" && "/c/code/HEAD/inplace/bin/ghc-stage2.exe" -c TH_scopedTvs.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output -XTemplateHaskell -package template-haskell -v0 =====> TH_scopedTvs(ext-interp) 6 of 21 [0, 2, 0] cd "th/TH_scopedTvs.run" && "/c/code/HEAD/inplace/bin/ghc-stage2.exe" -c TH_scopedTvs.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output -XTemplateHaskell -package template-haskell -fexternal-interpreter -v0 =====> T3319(normal) 7 of 21 [0, 2, 0] cd "th/T3319.run" && "/c/code/HEAD/inplace/bin/ghc-stage2.exe" -c T3319.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output -XTemplateHaskell -package template-haskell -ddump-splices -v0 =====> T3319(ext-interp) 7 of 21 [0, 2, 0] cd "th/T3319.run" && "/c/code/HEAD/inplace/bin/ghc-stage2.exe" -c T3319.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output -XTemplateHaskell -package template-haskell -fexternal-interpreter -ddump-splices -v0 =====> T15815(normal) 8 of 21 [0, 2, 0] cd "th/T15815.run" && "/c/code/HEAD/inplace/bin/ghc-stage2.exe" --make T15815B -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output -XTemplateHaskell -package template-haskell -v0 -static =====> T15815(ext-interp) 8 of 21 [0, 2, 0] cd "th/T15815.run" && "/c/code/HEAD/inplace/bin/ghc-stage2.exe" --make T15815B -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output -XTemplateHaskell -package template-haskell -fexternal-interpreter -v0 -static =====> T4006(normal) 9 of 21 [0, 2, 0] cd "libraries/base/tests/T4006.run" && "/c/code/HEAD/inplace/bin/ghc-stage2.exe" -o T4006 T4006.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -Werror=compat -dno-debug-output cd "libraries/base/tests/T4006.run" && ./T4006 Actual stdout output differs from expected: diff -uw "libraries/base/tests/T4006.run/T4006.stdout.normalised" "libraries/base/tests/T4006.run/T4006.run.stdout.normalised" *** unexpected failure for T4006(normal) =====> T3307(normal) 10 of 21 [0, 3, 0] cd "libraries/base/tests/IO/T3307.run" && $MAKE -s --no-print-directory T3307-test Wrong exit code for T3307()(expected 0 , actual 2 ) Stdout ( T3307 ): Test 1 [99,104,105,110,101,115,101,45,102,105,108,101,45,229,176,143,232,175,180] Ni hao Test 2 [99,104,105,110,101,115,101,45,102,105,108,101,45,229,176,143,232,175,180] Ni hao Test 3 [99,104,105,110,101,115,101,45,102,105,108,101,45,23567,35828] Stderr ( T3307 ): *** framework failure for T3307(normal) 'latin-1' codec can't encode characters in position 24-25: ordinal not in range(256) =====> environment001(normal) 11 of 21 [0, 3, 1] cd "libraries/base/tests/IO/environment001.run" && $MAKE -s --no-print-directory environment001-test Actual stdout output differs from expected: diff -uw "libraries/base/tests/IO/environment001.run/environment001.stdout.normalised" "libraries/base/tests/IO/environment001.run/environment001.run.stdout.normalised" *** unexpected failure for environment001(normal) =====> plugins07(normal) 12 of 21 [0, 4, 1] cd "plugins/plugins07.run" && $MAKE -s --no-print-directory -C rule-defining-plugin package.plugins07 TOP=/c/code/HEAD/testsuite cd "plugins/plugins07.run" && $MAKE -s --no-print-directory plugins07 =====> plugins09(normal) 13 of 21 [0, 4, 1] cd "plugins/plugins09.run" && $MAKE -s --no-print-directory -C simple-plugin package.plugins09 TOP=/c/code/HEAD/testsuite cd "plugins/plugins09.run" && $MAKE -s --no-print-directory plugins09 Actual stdout output differs from expected: diff -uw "plugins/plugins09.run/plugins09.stdout.normalised" "plugins/plugins09.run/plugins09.run.stdout.normalised"--- plugins/plugins09.run/plugins09.stdout.normalised 2018-11-30 21:17:20.709370700 +0000 +++ plugins/plugins09.run/plugins09.run.stdout.normalised 2018-11-30 21:17:20.711314000 +0000 @@ -1,9 +0,0 @@ -parsePlugin(a,b) -interfacePlugin: Prelude -interfacePlugin: GHC.Float -interfacePlugin: GHC.Base -typeCheckPlugin (rn) -interfacePlugin: GHC.Types -typeCheckPlugin (tc) -interfacePlugin: GHC.Integer.Type -interfacePlugin: GHC.Natural --- plugins/plugins10.run/plugins10.stdout.normalised 2018-11-30 21:17:57.644357800 +0000 +++ plugins/plugins10.run/plugins10.run.stdout.normalised 2018-11-30 21:17:57.646078700 +0000 @@ -1,21 +0,0 @@ -parsePlugin() -interfacePlugin: Prelude -interfacePlugin: Language.Haskell.TH -interfacePlugin: Language.Haskell.TH.Quote -interfacePlugin: GHC.Float -interfacePlugin: GHC.Base -interfacePlugin: Language.Haskell.TH.Syntax -typeCheckPlugin (rn) -interfacePlugin: GHC.Types -typeCheckPlugin (tc) -interfacePlugin: GHC.Integer.Type -interfacePlugin: GHC.Natural -parsePlugin(a) -typeCheckPlugin (rn) -interfacePlugin: Language.Haskell.TH.Lib.Internal -metaPlugin: return [] -metaPlugin: quoteExp stringify "x" -interfacePlugin: GHC.CString -typeCheckPlugin (rn) -typeCheckPlugin (rn) -typeCheckPlugin (tc) *** unexpected failure for plugins09(normal) =====> plugins10(normal) 14 of 21 [0, 5, 1] cd "plugins/plugins10.run" && $MAKE -s --no-print-directory -C simple-plugin package.plugins10 TOP=/c/code/HEAD/testsuite cd "plugins/plugins10.run" && $MAKE -s --no-print-directory plugins10 Actual stdout output differs from expected: diff -uw "plugins/plugins10.run/plugins10.stdout.normalised" "plugins/plugins10.run/plugins10.run.stdout.normalised" *** unexpected failure for plugins10(normal) =====> plugins11(normal) 15 of 21 [0, 6, 1] cd "plugins/plugins11.run" && $MAKE -s --no-print-directory -C simple-plugin package.plugins11 TOP=/c/code/HEAD/testsuite cd "plugins/plugins11.run" && $MAKE -s --no-print-directory plugins11 Timeout happened...killed process "cd "plugins/plugins11.run" && $MAKE -s --no-print-directory plugins11 "... Wrong exit code for plugins11()(expected 0 , actual 99 ) *** unexpected failure for plugins11(normal) =====> plugins13(normal) 16 of 21 [0, 7, 1] cd "plugins/plugins13.run" && $MAKE -s --no-print-directory -C simple-plugin package.plugins13 TOP=/c/code/HEAD/testsuite cd "plugins/plugins13.run" && $MAKE -s --no-print-directory plugins13 =====> plugins14(normal) 17 of 21 [0, 7, 1] cd "plugins/plugins14.run" && $MAKE -s --no-print-directory -C simple-plugin package.plugins14 TOP=/c/code/HEAD/testsuite cd "plugins/plugins14.run" && $MAKE -s --no-print-directory plugins14 =====> T10420(normal) 18 of 21 [0, 7, 1] cd "plugins/T10420.run" && $MAKE -s --no-print-directory -C rule-defining-plugin package.T10420 TOP=/c/code/HEAD/testsuite cd "plugins/T10420.run" && $MAKE -s --no-print-directory T10420 =====> plugin-recomp-pure(normal) 19 of 21 [0, 7, 1] cd "plugins/plugin-recomp-pure.run" && $MAKE -s --no-print-directory -C plugin-recomp package.plugins01 TOP=/c/code/HEAD/testsuite cd "plugins/plugin-recomp-pure.run" && $MAKE -s --no-print-directory plugin-recomp-pure Timeout happened...killed process "cd "plugins/plugin-recomp-pure.run" && $MAKE -s --no-print-directory plugin-recomp-pure "... Wrong exit code for plugin-recomp-pure()(expected 0 , actual 99 ) Stdout ( plugin-recomp-pure ): [1 of 1] Compiling Main ( plugin-recomp-test.hs, plugin-recomp-test.o ) Stderr ( plugin-recomp-pure ): Simple Plugin Passes Queried Got options: Simple Plugin Pass Run *** unexpected failure for plugin-recomp-pure(normal) =====> plugin-recomp-impure(normal) 20 of 21 [0, 8, 1] cd "plugins/plugin-recomp-impure.run" && $MAKE -s --no-print-directory -C plugin-recomp package.plugins01 TOP=/c/code/HEAD/testsuite cd "plugins/plugin-recomp-impure.run" && $MAKE -s --no-print-directory plugin-recomp-impure Wrong exit code for plugin-recomp-impure()(expected 0 , actual 2 ) Stdout ( plugin-recomp-impure ): [1 of 1] Compiling Main ( plugin-recomp-test.hs, plugin-recomp-test.o ) Linking plugin-recomp-test.exe ... [1 of 1] Compiling Main ( plugin-recomp-test.hs, plugin-recomp-test.o ) [Plugin forced recompilation] Stderr ( plugin-recomp-impure ): Simple Plugin Passes Queried Got options: Simple Plugin Pass Run Simple Plugin Passes Queried Access violation in generated code when reading 0xa824 Attempting to reconstruct a stack trace... Frame Code address * 0x49adab0 0x1eb49ec C:\code\HEAD\inplace\bin\ghc-stage2.exe+0x1ab49ec make[1]: *** [Makefile:99: plugin-recomp-impure] Error 11 *** unexpected failure for plugin-recomp-impure(normal) =====> plugin-recomp-flags(normal) 21 of 21 [0, 9, 1] cd "plugins/plugin-recomp-flags.run" && $MAKE -s --no-print-directory -C plugin-recomp package.plugins01 TOP=/c/code/HEAD/testsuite cd "plugins/plugin-recomp-flags.run" && $MAKE -s --no-print-directory plugin-recomp-flags Traceback (most recent call last): File "/c/code/HEAD/testsuite/driver/testlib.py", line 824, in test_common_work do_test(name, way, func, args, files) File "/c/code/HEAD/testsuite/driver/testlib.py", line 910, in do_test result = func(*[name,way] + args) File "/c/code/HEAD/testsuite/driver/testlib.py", line 993, in run_command return simple_run( name, '', override_options(cmd), '' ) File "/c/code/HEAD/testsuite/driver/testlib.py", line 1338, in simple_run dump_stderr(name) File "/c/code/HEAD/testsuite/driver/testlib.py", line 1501, in dump_stderr print(str) UnicodeEncodeError: 'latin-1' codec can't encode characters in position 24-25: ordinal not in range(256) Unexpected results from: TEST="T10672_x64 T14452 T3307 T4006 environment001 plugin-recomp-impure plugin-recomp-pure plugins09 plugins10 plugins11" SUMMARY for test run started at Fri Nov 30 21:07:17 2018 GMTST 0:26:45 spent to go through 21 total tests, which gave rise to 36 test cases, of which 11 were skipped 0 had missing libraries 15 expected passes 0 expected failures 1 caused framework failures 0 caused framework warnings 0 unexpected passes 9 unexpected failures 0 unexpected stat failures Unexpected failures: driver/T14452.run T14452 [bad stdout] (normal) rts/T10672/T10672_x64.run T10672_x64 [bad exit code] (normal) libraries/base/tests/T4006.run T4006 [bad stdout] (normal) libraries/base/tests/IO/environment001.run environment001 [bad stdout] (normal) plugins/plugins09.run plugins09 [bad stdout] (normal) plugins/plugins10.run plugins10 [bad stdout] (normal) plugins/plugins11.run plugins11 [bad exit code] (normal) plugins/plugin-recomp-pure.run plugin-recomp-pure [bad exit code] (normal) plugins/plugin-recomp-impure.run plugin-recomp-impure [bad exit code] (normal) Framework failures: libraries/base/tests/IO/T3307.run T3307 [normal] ('latin-1' codec can't encode characters in position 24-25: ordinal not in range(256)) Appending 0 stats to git notes. make: *** [../mk/test.mk:342: test] Error 1 make: Leaving directory '/c/code/HEAD/testsuite/tests' /c/code/HEAD$ From: Phyx Sent: 30 November 2018 11:58 To: Simon Peyton Jones Subject: Re: Windows test failures At the end of the first test run it would have given a list of tests that failed and a line saying TEST=".... List of tests..." Copy that line and at the root of the checkout do make TEST=".... List of tests..." test -C testsuite/tests (that's uppercase C). This will run everything using one thread. :) Should give a good starting point as to what's wrong. Kind regards, Tamar On Fri, Nov 30, 2018, 10:30 Simon Peyton Jones > wrote: So I just say make TEST is that right? Or is it make THREADS=1 or what? Sorry to be dim From: Phyx > Sent: 30 November 2018 08:05 To: Simon Peyton Jones > Cc: ghc-devs > Subject: Re: Windows test failures Hi Simon, Could you try rerunning those failing tests with make TEST? No threads? I have been trying to clean up the testsuite and there should be only 3 failing tests, two plugin tests with bad stdout and T10672_x64 which I am looking into. I have however noticed that the testsuite has become increasingly unstable under threads for some reason. I also haven't run trunk yet since last week so they could be new.. But rerunning the fails with no threads should give a better idea. Regards, Tamar On Fri, Nov 30, 2018, 07:46 Simon Peyton Jones via ghc-devs > wrote: Ben, Phyx, and other CI folk ‘sh validate –fast’ still gives a lot of failures on Window. The output is below. I would be so good to get this to zero! (another minor thing is that it would be great to eliminate the long path at the beginning – this is platform independent – I have to delete manually many times each day. Thanks Simon Unexpected passes: /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/rts/T9405.run T9405 [unexpected] (normal) Unexpected failures: /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/driver/T14452.run T14452 [bad stdout] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/ghci/linking/ghcilink001.run ghcilink001 [bad exit code] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/ghci/prog010/ghci.prog010.run ghci.prog010 [bad exit code] (ghci) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/ghci/scripts/ghci050.run ghci050 [bad exit code] (ghci) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/ghci/should_run/T14963a.run T14963a [bad exit code] (ghci) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/ghci.debugger/scripts/print012.run print012 [bad exit code] (ghci) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/ghci.debugger/scripts/print016.run print016 [bad exit code] (ghci) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/ghci.debugger/scripts/break019.run break019 [bad exit code] (ghci) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/ghci.debugger/scripts/break028.run break028 [bad exit code] (ghci) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/ghci.debugger/scripts/dynbrk002.run dynbrk002 [bad exit code] (ghci) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/ghci.debugger/scripts/T2740.run T2740 [bad exit code] (ghci) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/indexed-types/should_fail/T7102a.run T7102a [bad exit code] (ghci) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/plugins/plugin-recomp-change.run plugin-recomp-change [bad exit code] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/rts/T10672/T10672_x64.run T10672_x64 [bad exit code] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/th/TH_spliceGuard.run TH_spliceGuard [exit code non-0] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/th/TH_overlaps.run TH_overlaps [exit code non-0] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/th/T5886.run T5886 [exit code non-0] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/th/T10697_decided_3.run T10697_decided_3 [exit code non-0] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/th/T11629.run T11629 [exit code non-0] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/libraries/base/tests/T4006.run T4006 [bad stdout] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/libraries/base/tests/IO/environment001.run environment001 [bad stdout] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/ghci/should_run/T15633b.run T15633b [bad exit code] (ghci) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/plugins/plugins07.run plugins07 [bad exit code] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/plugins/plugins09.run plugins09 [bad stdout] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/plugins/plugins10.run plugins10 [bad stdout] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/plugins/plugins11.run plugins11 [bad stdout] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/plugins/T10420.run T10420 [bad exit code] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/plugins/plugin-recomp-pure.run plugin-recomp-pure [bad exit code] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/plugins/plugin-recomp-impure.run plugin-recomp-impure [bad exit code] (normal) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/plugins/plugin-recomp-flags.run plugin-recomp-flags [bad exit code] (normal) Framework failures: /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/perf/compiler/MultiLayerModules.run MultiLayerModules [runTest] (Unhandled exception during cleanup: Unable to remove folder '/c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/perf/compiler/MultiLayerModules.run': [Errno 13] Permission denied: '/c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/perf/compiler/MultiLayerModules.run' Unable to start current test.) /c/Users/simonpj/AppData/Local/Temp/ghctest-i30xogs3/test spaces/libraries/base/tests/IO/T3307.run T3307 [normal] ('latin-1' codec can't encode characters in position 24-25: ordinal not in range(256)) _______________________________________________ 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 csaba.hruska at gmail.com Fri Nov 30 22:08:44 2018 From: csaba.hruska at gmail.com (Csaba Hruska) Date: Fri, 30 Nov 2018 23:08:44 +0100 Subject: typePrimRep invariants References: Message-ID: Is this problem related to the following? > {- Note [Error and friends have an "open-tyvar" forall] > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 'error' and 'undefined' have types > error :: forall (v :: RuntimeRep) (a :: TYPE v). String -> a > undefined :: forall (v :: RuntimeRep) (a :: TYPE v). a > Notice the runtime-representation polymorphism. This ensures that > "error" can be instantiated at unboxed as well as boxed types. > This is OK because it never returns, so the return type is irrelevant. > > On Fri, Nov 30, 2018 at 10:47 PM Csaba Hruska wrote: > Hi, > > I'd like to export the PrimRep of every binder and data con from Haskell > modules. > > I have a modified GHC 8.6 which serializes the PrimRep for every binder > during the compilation. It uses the *typePrimRep* function. When my > customised GHC compiles the base library it always thows the following > error for the *libraries/base/GHC/Err.hs* > > module. > > 1. Does that mean that there is hidden requirement for typePrimRep > input? > 2. If so what are the restrictions? > 3. Can you see anything in the Err module source code that could not > be a proper input for typePrimRep function? > > > Thanks, > Csaba > > "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -H32m -O > -Wall -this-unit-id base-4.12.0.0 -hide-all-packages -i > -ilibraries/base/. -ilibraries/base/dist-install/build > -Ilibraries/base/dist-install/build > -ilibraries/base/dist-install/build/./autogen > -Ilibraries/base/dist-install/build/./autogen -Ilibraries/base/include > -Ilibraries/base/dist-install/build/include > -optP-DOPTIMISE_INTEGER_GCD_LCM -optP-include > -optPlibraries/base/dist-install/build/./autogen/cabal_macros.h -package-id > ghc-prim-0.5.3 -package-id integer-gmp-1.0.2.0 -package-id rts > -this-unit-id base -Wcompat -Wnoncanonical-monad-instances -XHaskell2010 > -O2 -haddock -no-user-package-db -rtsopts -Wno-trustworthy-safe > -Wno-deprecated-flags -Wnoncanonical-monad-instances -odir > libraries/base/dist-install/build -hidir libraries/base/dist-install/build > -stubdir libraries/base/dist-install/build -split-sections -dynamic-too -c > libraries/base/./GHC/Err.hs -o libraries/base/dist-install/build/GHC/Err.o > -dyno libraries/base/dist-install/build/GHC/Err.dyn_o > ghc-stage1: panic! (the 'impossible' happened) > (GHC version 8.6.2 for x86_64-unknown-linux): > runtimeRepPrimRep > typePrimRep (a_a1ML :: TYPE r_a1MK) > r_a1MK > Call stack: > CallStack (from HasCallStack): > callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in > ghc:Outputable > pprPanic, called at compiler/simplStg/RepType.hs:358:5 in > ghc:RepType > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > > libraries/base/ghc.mk:4: recipe for target > 'libraries/base/dist-install/build/GHC/Err.o' failed > make[1]: *** [libraries/base/dist-install/build/GHC/Err.o] Error 1 > Makefile:122: recipe for target 'all' failed > make: *** [all] Error 2 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: