- ghc-devs - Haskell.org

Does it sound a good idea to implement "backend plugins"?
by Shao, Cheng 05 Oct '18

05 Oct '18

Hi all, I'm thinking of adding "backend plugins" in the current Plugins mechanism which allows one to inspect/modify the IRs post simplifier pass (STG/Cmm), similar to the recently added source plugins for HsSyn IRs. This can be useful for anyone creating a custom GHC backend to target an experimental platform (e.g. the Asterius compiler which targets WebAssembly), and previously in order to retrieve those IRs from the regular pipeline, we need to use Hooks which is somewhat hacky. Does this sound a good idea to you? If so, I can open a trac ticket and a Phab diff for this feature. Best, Shao Cheng

5 6

nofib oldest GHC to support?
by Ömer Sinan Ağacan 04 Oct '18

04 Oct '18

Do we have a policy on the oldest GHC to support in nofib? I'm currently doing some hacking on nofib to parse some new info printed by a modified GHC, and I think we can do a lot of cleaning (at the very least remove some regexes and parsers) if we decide on which GHCs to support. I checked the README and RunningNoFib wiki page but couldn't see anything relevant. Thanks Ömer

3 3

typed holes inferring very polymorphic types
by Sreenidhi Nair 01 Oct '18

01 Oct '18

Hello, We tried the following code with ghc-8.6.1 testFailure :: Char testFailure = let x = Prelude.id _ in x which gave the following suggestion /home/sreenidhi/Work/typeql/typeql-dbrecord/test/Test/Database/Postgres/Read/Combinator.hs:83:22: error: • Found hole: _ :: a Where: ‘a’ is a rigid type variable bound by the inferred type of x :: a at /home/sreenidhi/Work/typeql/typeql-dbrecord/test/Test/Database/Postgres/Read/Combinator.hs:83:7-22 And then this testSuccess :: Char testSuccess = _ which gave a much better suggestion /home/sreenidhi/Work/typeql/typeql-dbrecord/test/Test/Database/Postgres/Read/Combinator.hs:87:15: error: • Found hole: _ :: Char • In the expression: _ In an equation for ‘testSuccess’: testSuccess = _ Is there any way to get better suggestions with 'let' version?

2 1

Re: Stable name allocation
by David Feuer 27 Sep '18

27 Sep '18

Simon seems a bit busy right now. Can anyone else advise me on the basics of heap allocation in primops? On Tue, Sep 25, 2018 at 1:42 PM, David Feuer <david.feuer(a)gmail.com> wrote: > Let's forget about allocate(). I can definitely handle this part in > C--. But I'm still lost in the macros and such. For example, I'm very > unclear on the differences among the ALLOC, HP_CHK, and MAYBE_GC > classes of macro. I can't find anything in the commentary, and the > source code documentation is very sparse. I'm okay with either of the > following approaches, but either way I need a bit more info. > > 1. First see if we need to allocate a StableName#. If so, check > whether GC would be required to allocate the StableName# (how?). If > so, drop the lock, run GC (how?) and start over. This looks cleanest > to me if it can be done easily. > > 2. First run the GC if we're low on memory (how?). Then if we need to > allocate a StableName#, we'll be sure to have room. > > > On Tue, Sep 25, 2018 at 6:25 AM, Simon Marlow <marlowsd(a)gmail.com> wrote: >> You can do it unconditionally before taking the lock, or you can do it >> conditionally as long as you release the lock if the heap check fails. I >> think in the latter case there might not be a macro that allows this, but >> you could use the `allocate()` method for allocating memory (like >> newByteArray#) and then you could write a heap check like the MAYBE_GC() >> macro. Doing it unconditionally is easier and probably not a big performance >> hit, but note that you'll have to retreat Hp if you don't use the memory. >> >> Cheers >> Simon >> >> On Sat, 22 Sep 2018 at 13:08, David Feuer <david.feuer(a)gmail.com> wrote: >>> >>> How do I check if GC will be required, and how do I trigger it? Should I >>> perform the check unconditionally at the beginning of the operation so I >>> don't have to drop the lock, GC, then retake? I don't know the right ways to >>> deal with this stuff, and the macros are mostly undocumented. >>> >>> On Sep 22, 2018 3:53 AM, "Simon Marlow" <marlowsd(a)gmail.com> wrote: >>> >>> Yes, the current implementation looks like it creates the object after >>> adding the entry to the StableName table and releasing the lock, which is >>> unsafe because another thread could read that same entry before the object >>> has been created. The easiest solution to that is to take and release the >>> lock in C-- in the right places instead of in the C lookupStableName() >>> function (you might need to make a separate version of lookupStableName() >>> that doesn't take the lock). >>> >>> Cheers >>> Simon >>> >>> >>> On Fri, 21 Sep 2018 at 12:53, David Feuer <david.feuer(a)gmail.com> wrote: >>>> >>>> It seems awkward to do it in C--, but maybe you can help me work out how. >>>> The allocation facilities definitely seem much nicer there, and allocating a >>>> small heap object in C feels like an abuse of the facilities we have there. >>>> The essential challenge, as I see it, is that we need the key to point to a >>>> valid stable name object by the time we drop the hash table lock. The >>>> process, as I imagine it: >>>> >>>> 1. Follow indirections, untag, choose the right generation. (All this is >>>> in C) >>>> 2. Take the appropriate hash table lock. (C) >>>> 3. Look up the key in the hash table (C). >>>> >>>> Now there's a branch. If we found the key, then we don't need to allocate >>>> an SNO. We just drop the lock and return. Otherwise >>>> >>>> 4. Allocate an SNO and set its info pointer (most easily done in C--). If >>>> this necessitates GC, we need to drop the lock first and might as well just >>>> go back to the very beginning afterwards. >>>> 5. Populate the SNO with its "hash value" (we can do this anywhere we >>>> like, I imagine). >>>> 6. Insert the key and SNO into the hash table and drop the hash table >>>> lock (C) >>>> 7. If necessary, insert the SNO into the remembered set (C) >>>> >>>> How would you recommend structuring this back-and-forth? >>>> >>>> On Fri, Sep 21, 2018, 3:19 AM Simon Marlow <marlowsd(a)gmail.com> wrote: >>>>> >>>>> I'm a bit sceptical that you need to allocate a heap object in C instead >>>>> of C--, but still, here's an example: >>>>> https://phabricator.haskell.org/diffusion/GHC/browse/master/rts%2FThreads.c… >>>>> >>>>> It's slightly less efficient to do this in C than C--, because >>>>> `allocate()` is slower than allocating by bumping `Hp`. >>>>> >>>>> On Mon, 17 Sep 2018 at 21:25, David Feuer <david.feuer(a)gmail.com> wrote: >>>>>> >>>>>> How can I allocate a heap object in C code in the rts? I've only seen >>>>>> heap objects allocated in C--, and doing that here would be lousy for >>>>>> performance and worse for clarity. >>>>>> >>>>>> David >>> >>> >>

2 1

RE: Windows testsuite failures
by Simon Peyton Jones 25 Sep '18

25 Sep '18

Tamar Thank you, that’s great! For the ones that need more work, can we mark them as expect-broken, so that they don’t pollute the testsuite output? Simon From: lonetiger(a)gmail.com <lonetiger(a)gmail.com> Sent: 24 September 2018 07:13 To: Simon Peyton Jones <simonpj(a)microsoft.com> Subject: RE: Windows testsuite failures Hi Simon, I created some patches to fix the majority of these https://phabricator.haskell.org/D5174 https://phabricator.haskell.org/D5175 https://phabricator.haskell.org/D5176 The remaining ones I’ve either pinged the patches that caused the issues or created tickets For them because they’re actual bugs that require a bit more time to find the cause and fix. https://ghc.haskell.org/trac/ghc/ticket/15668 https://ghc.haskell.org/trac/ghc/ticket/15669 https://ghc.haskell.org/trac/ghc/ticket/15670 https://ghc.haskell.org/trac/ghc/ticket/15671 these should bring down the amount of failing tests to about 5. Kind Regards, Tamar From: Simon Peyton Jones<mailto:simonpj@microsoft.com> Sent: Thursday, September 20, 2018 12:05 To: Phyx<mailto:lonetiger@gmail.com> Subject: RE: Windows testsuite failures Thanks Tamar. I’ll look forward to hearing back S From: Phyx <lonetiger(a)gmail.com<mailto:lonetiger@gmail.com>> Sent: 20 September 2018 12:02 To: Simon Peyton Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> Cc: ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org> Subject: Re: Windows testsuite failures Hi Simon, Thanks for the email. I haven't been building head much as I'm working on top of some older commits. From a quick look it seems like the plugin ones are probably testisms, the plugins aren't found so likely a missing path entry somewhere. The linker ones are are weird, I'll need to take a closer look at those, likely culprit is my recent patch, I had been testing in the 32 bit build and didn't notice these. There are a few worrying segfault that shouldn't be there on some random tests so I'll take a closer look at those too. And the stat changes need to be updated. The framework failures I don't see on harbormaster, so think they are again a threading artifact. Need to figure out a more effective way to debug these to find a permanent fix. The ones that harbormaster does see are encoding related. touch is failing on non-ascii names. I will take a look this weekend. Kind regards, Tamar On Thu, Sep 20, 2018, 11:33 Simon Peyton Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> wrote: Hi Tamar The list of testsuite failure on Windows has grown quite long – see below. Most seem to concern plugins or linking. Do you know what is going on here? If they can’t be fixed, can we mark them as expect_broken on Windows, so that it’s easier (when developing) to know when I’ve introduced a regression. Currently I have to do a manual diff against a rather long list. Thanks! Simon SUMMARY for test run started at Thu Sep 20 00:13:20 2018 GMTST 1:03:11 spent to go through 6530 total tests, which gave rise to 18728 test cases, of which 12206 were skipped 33 had missing libraries 6278 expected passes 173 expected failures 9 caused framework failures 1 caused framework warnings 0 unexpected passes 31 unexpected failures 7 unexpected stat failures Unexpected failures: ghci/linking/dyn/T10955dyn.run T10955dyn [bad exit code] (normal) ghci/linking/dyn/T10955.run T10955 [bad stderr] (ghci) ghci/linking/dyn/T11072gcc.run T11072gcc [bad exit code] (normal) numeric/should_run/FloatFnInverses.run FloatFnInverses [bad stdout] (normal) plugins/T11244.run T11244 [bad stderr] (normal) plugins/plugin-recomp-change.run plugin-recomp-change [bad exit code] (normal) rts/T7040_ghci.run T7040_ghci [bad stdout] (ghci) rts/linker_unload.run linker_unload [bad exit code] (normal) rts/linker_error1.run linker_error1 [bad exit code] (normal) rts/linker_error2.run linker_error2 [bad exit code] (normal) rts/T12771/T12771.run T12771 [bad exit code] (normal) rts/T13082/T13082_good.run T13082_good [bad exit code] (normal) rts/T14611/T14611.run T14611 [bad exit code] (normal) simplCore/should_compile/T7702.run T7702 [exit code non-0] (normal) rts/T10672/T10672_x64.run T10672_x64 [bad exit code] (normal) libraries/Win32/tests/T4452.run T4452 [bad exit code] (normal) plugins/plugins01.run plugins01 [bad exit code] (normal) plugins/plugins07.run plugins07 [bad exit code] (normal) plugins/plugins09.run plugins09 [bad exit code] (normal) plugins/plugins11.run plugins11 [bad exit code] (normal) plugins/plugins12.run plugins12 [bad exit code] (normal) plugins/plugins13.run plugins13 [bad exit code] (normal) plugins/plugins14.run plugins14 [bad exit code] (normal) plugins/plugins15.run plugins15 [bad exit code] (normal) plugins/T10420.run T10420 [bad exit code] (normal) plugins/T10294.run T10294 [bad exit code] (normal) plugins/T10294a.run T10294a [bad exit code] (normal) plugins/T12567a.run T12567a [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) plugins/plugin-recomp-flags.run plugin-recomp-flags [bad exit code] (normal) Unexpected stat failures: perf/compiler/T9872d.run T9872d [stat not good enough] (normal) perf/compiler/T12425.run T12425 [stat not good enough] (optasm) perf/compiler/T12234.run T12234 [stat not good enough] (optasm) perf/compiler/T12150.run T12150 [stat not good enough] (optasm) perf/should_run/T15226.run T15226 [stat too good] (normal) perf/should_run/T15226a.run T15226a [stat too good] (normal) perf/compiler/MultiLayerModules.run MultiLayerModules [stat not good enough] (normal) Framework failures: ghci/linking/dyn/T10955.run T10955 [ghci] (pre_cmd failed: 2) plugins/T11244.run T11244 [normal] (pre_cmd failed: 2) plugins/plugin-recomp-change.run plugin-recomp-change [normal] (pre_cmd failed: 2) plugins/plugins07.run plugins07 [normal] (pre_cmd failed: 2) plugins/T10420.run T10420 [normal] (pre_cmd failed: 2) plugins/T10294a.run T10294a [normal] (pre_cmd failed: 2) plugins/plugin-recomp-pure.run plugin-recomp-pure [normal] (pre_cmd failed: 2) plugins/plugin-recomp-impure.run plugin-recomp-impure [normal] (pre_cmd failed: 2) plugins/plugin-recomp-flags.run plugin-recomp-flags [normal] (pre_cmd failed: 2) Framework warnings: . T13701 [numfield-no-expected] (No expected value found for bytes allocated in num_field check)

2 1

clonetype
by Harendra Kumar 24 Sep '18

24 Sep '18

Often, we need to create a newtype that is equivalent to a given type for safety reasons. Using type synonym is useless from type safety perspective. With newtype, we have to add a "deriving" clause to it for deriving the required instances, to make it practically useful. Does it make sense, and is it possible to have something like a "clonetype" that creates a new type and derives all the instances of the parent type as well? It will be quite helpful in creating equivalent newtype synonyms quickly. Almost always, I do not use a newtype where I should just because of the inconvenience of deriving the instances. Ideally, we should just be able to say something like: clonetype MyString = String and we are good to go. What is the shortest possible way to achieve this with currently available mechanisms, if any? -harendra

1 0

bug in aclocal.m4
by Evan Laforge 22 Sep '18

22 Sep '18

Tiny bug, so I'll just throw it out here instead of trying to get arc set up again: aclocal.m4 line 2438, at head (commit 7e77f41430ae1cad84d5b0c90328331d38f3eda0) has # typo'd as $. It causes a harmless but alarming error in configure. Also `ld --version` causes an error on OS X since OS X ld doesn't have that flag, but I think it just causes it to correctly detect it as "not gnu ld".

2 1

Re: Looking for student ticket to GHC
by Carter Schonwald 21 Sep '18

21 Sep '18

you wanna email ghc devs On Fri, Sep 21, 2018 at 11:11 AM Virashree Patel <patelvirashree(a)gmail.com> wrote: > Hi, > I am looking to buy a student ticket to GHC 2018. If you are selling still > please contact me. > Thank you! > > Best, > Vira Patel, > Graduate Research Assistant at *Kansas State University * > LinkedIn: *linkedin.com/in/virashreepatel > <http://linkedin.com/in/virashreepatel> <http://twitter.com/>* > _______________________________________________ > ghc-tickets mailing list > ghc-tickets(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-tickets >

1 0

constant pooling in GHC
by Phyx 21 Sep '18

21 Sep '18

Hi All, I'm hoping someone here can save me some time. I'm working on something that relies on constants in the same translation unit being pooled before assembly. I've noticed GHC does some const pooling at -O1 , but this doesn't seem to be very consistent, which leads me to believe this is a byproduct of another optimization rather than an explicit thing. I couldn't find anything obvious in the sources, so does GHC intentionally do constant pooling already? Or do I need a new pass to guarantee it. Thanks, Tamar

2 3

Windows testsuite failures
by Simon Peyton Jones 20 Sep '18

20 Sep '18

Hi Tamar The list of testsuite failure on Windows has grown quite long - see below. Most seem to concern plugins or linking. Do you know what is going on here? If they can't be fixed, can we mark them as expect_broken on Windows, so that it's easier (when developing) to know when I've introduced a regression. Currently I have to do a manual diff against a rather long list. Thanks! Simon SUMMARY for test run started at Thu Sep 20 00:13:20 2018 GMTST 1:03:11 spent to go through 6530 total tests, which gave rise to 18728 test cases, of which 12206 were skipped 33 had missing libraries 6278 expected passes 173 expected failures 9 caused framework failures 1 caused framework warnings 0 unexpected passes 31 unexpected failures 7 unexpected stat failures Unexpected failures: ghci/linking/dyn/T10955dyn.run T10955dyn [bad exit code] (normal) ghci/linking/dyn/T10955.run T10955 [bad stderr] (ghci) ghci/linking/dyn/T11072gcc.run T11072gcc [bad exit code] (normal) numeric/should_run/FloatFnInverses.run FloatFnInverses [bad stdout] (normal) plugins/T11244.run T11244 [bad stderr] (normal) plugins/plugin-recomp-change.run plugin-recomp-change [bad exit code] (normal) rts/T7040_ghci.run T7040_ghci [bad stdout] (ghci) rts/linker_unload.run linker_unload [bad exit code] (normal) rts/linker_error1.run linker_error1 [bad exit code] (normal) rts/linker_error2.run linker_error2 [bad exit code] (normal) rts/T12771/T12771.run T12771 [bad exit code] (normal) rts/T13082/T13082_good.run T13082_good [bad exit code] (normal) rts/T14611/T14611.run T14611 [bad exit code] (normal) simplCore/should_compile/T7702.run T7702 [exit code non-0] (normal) rts/T10672/T10672_x64.run T10672_x64 [bad exit code] (normal) libraries/Win32/tests/T4452.run T4452 [bad exit code] (normal) plugins/plugins01.run plugins01 [bad exit code] (normal) plugins/plugins07.run plugins07 [bad exit code] (normal) plugins/plugins09.run plugins09 [bad exit code] (normal) plugins/plugins11.run plugins11 [bad exit code] (normal) plugins/plugins12.run plugins12 [bad exit code] (normal) plugins/plugins13.run plugins13 [bad exit code] (normal) plugins/plugins14.run plugins14 [bad exit code] (normal) plugins/plugins15.run plugins15 [bad exit code] (normal) plugins/T10420.run T10420 [bad exit code] (normal) plugins/T10294.run T10294 [bad exit code] (normal) plugins/T10294a.run T10294a [bad exit code] (normal) plugins/T12567a.run T12567a [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) plugins/plugin-recomp-flags.run plugin-recomp-flags [bad exit code] (normal) Unexpected stat failures: perf/compiler/T9872d.run T9872d [stat not good enough] (normal) perf/compiler/T12425.run T12425 [stat not good enough] (optasm) perf/compiler/T12234.run T12234 [stat not good enough] (optasm) perf/compiler/T12150.run T12150 [stat not good enough] (optasm) perf/should_run/T15226.run T15226 [stat too good] (normal) perf/should_run/T15226a.run T15226a [stat too good] (normal) perf/compiler/MultiLayerModules.run MultiLayerModules [stat not good enough] (normal) Framework failures: ghci/linking/dyn/T10955.run T10955 [ghci] (pre_cmd failed: 2) plugins/T11244.run T11244 [normal] (pre_cmd failed: 2) plugins/plugin-recomp-change.run plugin-recomp-change [normal] (pre_cmd failed: 2) plugins/plugins07.run plugins07 [normal] (pre_cmd failed: 2) plugins/T10420.run T10420 [normal] (pre_cmd failed: 2) plugins/T10294a.run T10294a [normal] (pre_cmd failed: 2) plugins/plugin-recomp-pure.run plugin-recomp-pure [normal] (pre_cmd failed: 2) plugins/plugin-recomp-impure.run plugin-recomp-impure [normal] (pre_cmd failed: 2) plugins/plugin-recomp-flags.run plugin-recomp-flags [normal] (pre_cmd failed: 2) Framework warnings: . T13701 [numfield-no-expected] (No expected value found for bytes allocated in num_field check)

2 1