- ghc-devs - Haskell.org

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

Heap allocation in the RTS
by David Feuer 20 Sep '18

20 Sep '18

I'm working on re-implementing the stable name system. For the new design, it seems much cleaner to allocate stable names in lookupStableName (in rts/StableName.c) rather than in the C-- code that calls it. But I haven't seen RTS code that does heap allocation. Is it possible? If so, how do I do it?

2 7

touch# primitive
by Daniel Cartwright 19 Sep '18

19 Sep '18

in GHC.Prim, there is a primitive 'touch#'. It seems that it is used to keep pointers alive, and takes something of any runtime representation, and a State# RealWorld, but there's really no documentation on it, so my idea of what it does is just a guess. Can anyone explain what exactly it does?

3 2

Redundant import warnings
by Simon Peyton Jones 17 Sep '18

17 Sep '18

Edward Can you perhaps bring the core libraries committee to consensus on this (I think minor) issue, and we can then get on with implementing it? Many thanks -- hope to se you at ICFP. Simon | -----Original Message----- | From: haskell-core-libraries(a)googlegroups.com <haskell-core- | libraries(a)googlegroups.com> On Behalf Of GHC | Sent: 17 September 2018 01:49 | Subject: [core libraries] Re: [GHC] #13064: Incorrect redudant imports | warning | | #13064: Incorrect redudant imports warning | -------------------------------------+---------------------------------- | --- | Reporter: phadej | Owner: (none) | Type: bug | Status: new | Priority: low | Milestone: 8.8.1 | Component: Compiler | Version: 8.0.1 | Resolution: | Keywords: | Operating System: Unknown/Multiple | Architecture: | Type of failure: Incorrect | Unknown/Multiple | error/warning at compile-time | Test Case: | Blocked By: | Blocking: | Related Tickets: #15393 | Differential Rev(s): | Wiki Page: | | -------------------------------------+---------------------------------- | --- | | Comment (by RyanGlScott): | | To follow up on my proposed experiment (in comment:29), I built about | 143 | commonly used Hackage libraries using the `wip/T13064` GHC branch. Of | those 143, I noticed new warnings being emitted in 31 of them (~22%): | | {{{ | - adjunctions-4.4 | - aeson-1.4.0.0 | - ansi-wl-pprint-0.6.8.2 | - asn1-encoding-0.9.5 | - async-2.2.1 | - attoparsec-0.13.2.2 | - blaze-builder-0.4.1.0 | - cassava-0.5.1.0 | - conduit-1.3.0.3 | - cookie-0.4.4 | - foundation-0.0.21 | - Glob-0.9.2 | - haskell-src-exts-1.20.2 | - hspec-core-2.5.6 | - lens-4.17 | - math-functions-0.3.0.2 | - memory-0.14.16 | - microstache-1.0.1.1 | - mono-traversable-1.0.9.0 | - network-2.8.0.0 | - primitive-0.6.4.0 | - resourcet-1.2.1 | - scientific-0.3.6.2 | - tasty-1.1.0.3 | - th-orphans-0.13.6 | - unordered-containers-0.2.9.0 | - uuid-types-1.0.3 | - x509-1.7.4 | - x509-store-1.6.6 | - x509-system-1.6.6 | - yaml-0.10.1.1 | }}} | | I still advocate adopting this change, but it is worth noting that a | non- | trivial number of existing libraries will need to be updated in order | to | accommodate the new warnings. | | -- | Ticket URL: | <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.has | kell.org%2Ftrac%2Fghc%2Fticket%2F13064%23comment%3A36&data=02%7C01%7 | Csimonpj%40microsoft.com%7C24e789bc20ae453ead6408d61c374eb2%7C72f988bf86 | f141af91ab2d7cd011db47%7C1%7C0%7C636727421200703644&sdata=bN0jeTbzDk | GwItLs7gfnlmNsbfvpx2LQ7VU5g7JeSwg%3D&reserved=0> | GHC | <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.has | kell.org%2Fghc%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C24e789bc2 | 0ae453ead6408d61c374eb2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636 | 727421200703644&sdata=tOARXvDO6s7m4WDjdmcNPfh2qvgusCc3qKrrUPRag9I%3D | &reserved=0> | The Glasgow Haskell Compiler | | -- | You received this message because you are subscribed to the Google | Groups "haskell-core-libraries" group. | To unsubscribe from this group and stop receiving emails from it, send | an email to haskell-core-libraries+unsubscribe(a)googlegroups.com. | For more options, visit | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups. | google.com%2Fd%2Foptout&data=02%7C01%7Csimonpj%40microsoft.com%7C24e | 789bc20ae453ead6408d61c374eb2%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0 | %7C636727421200703644&sdata=mvmddMlq2QoOaxTDZTcwv8wiMlv8VtKOYyggrrAD | 2gA%3D&reserved=0.

1 0

GHC state of play at HIW, in 10 days time
by Simon Peyton Jones 14 Sep '18

14 Sep '18

GHC devs I'm going to give the traditional "state of play in GHC" at the Haskell Implementors Meeting. If you have an opinion, can you say what you'd like to see in it? My current list of topics is below. Please say what else should be there, and who else should be credited. Most of the work is done by people other than me!! Simon * A Backpack segment (given by Edward) * A DevOps segment (given by Ben) * TypeInType * Zillions of fixes * Substantial internal changes: e.g. * making flattening homogeneous; * making equality homogeneous, coercion quantification (thanks Ningning) * what else? * Small but significant language proposals: * Visible dependent quantification * Top-level kind signatures * Visible kind application * what else? * New and ongoing developments in GHC * Better exhaustiveness checking (thank you Ryan) * Quantified constraints * Linear types * Trees That Grow * Deriving via * Performance, performance, performance * Hadrian... soon, soon, soon!

1 0

RE: [commit: ghc] master: Fix build (9912cdf)
by Simon Peyton Jones 14 Sep '18

14 Sep '18

Sorry about this, my fault. I had -Wwarn in my build.mk. I'll remove it! Thanks for fixing Krzysztof Simon | -----Original Message----- | From: ghc-commits <ghc-commits-bounces(a)haskell.org> On Behalf Of | git(a)git.haskell.org | Sent: 13 September 2018 22:04 | To: ghc-commits(a)haskell.org | Subject: [commit: ghc] master: Fix build (9912cdf) | | Repository : ssh://git@git.haskell.org/ghc | | On branch : master | Link : | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fghc.haske | ll.org%2Ftrac%2Fghc%2Fchangeset%2F9912cdf6dbb24a9d0188edc722ed6d9d8a3e0a1 | b%2Fghc&data=02%7C01%7Csimonpj%40microsoft.com%7C9952204b82734765e23d | 08d619bc6940%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636724694337978 | 889&sdata=867WGIQemLsbDnnOOy2jbFTidWY1opz26386sZLDSas%3D&reserved | =0 | | >--------------------------------------------------------------- | | commit 9912cdf6dbb24a9d0188edc722ed6d9d8a3e0a1b | Author: Krzysztof Gogolewski <krz.gogolewski(a)gmail.com> | Date: Thu Sep 13 22:52:05 2018 +0200 | | Fix build | | | >--------------------------------------------------------------- | | 9912cdf6dbb24a9d0188edc722ed6d9d8a3e0a1b | compiler/typecheck/TcValidity.hs | 1 - | 1 file changed, 1 deletion(-) | | diff --git a/compiler/typecheck/TcValidity.hs | b/compiler/typecheck/TcValidity.hs | index 351d0e1..df54dc2 100644 | --- a/compiler/typecheck/TcValidity.hs | +++ b/compiler/typecheck/TcValidity.hs | @@ -57,7 +57,6 @@ import Util | import ListSetOps | import SrcLoc | import Outputable | -import Module | import Bag ( emptyBag ) | import Unique ( mkAlphaTyVarUnique ) | import qualified GHC.LanguageExtensions as LangExt | | _______________________________________________ | ghc-commits mailing list | ghc-commits(a)haskell.org | https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask | ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- | commits&data=02%7C01%7Csimonpj%40microsoft.com%7C9952204b82734765e23d | 08d619bc6940%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636724694337978 | 889&sdata=57N0FGleYkiz03HRAKYxf5VVU1lqpJIreaAqcRdIvSs%3D&reserved | =0

1 0

[ANNOUNCE] GHC 8.6.1-beta1 available
by Ben Gamari 11 Sep '18

11 Sep '18

Hello everyone, The GHC development team is very pleased to announce the first beta leading up to GHC 8.6.1 release. The usual release artifacts are available from https://downloads.haskell.org/~ghc/8.6.1-beta1 This beta fixes most of the bugs reported in the first two alphas and brings all of the core libraries up to their final release versions. The 8.6 release fixes over 300 bugs from the 8.4 series and introduces a number of exciting features. These most notably include: * Significantly better handling of macOS linker command size limits, avoiding linker errors while linking large projects * A new deriving mechanism, `deriving via`, providing a convenient way for users to extend Haskell's typeclass deriving mechanism * Quantified constraints, allowing forall quantification in contexts * An early version of the GHCi `:doc` command * The `ghc-heap-view` package, allowing introspection into the structure of GHC's heap * Valid hole fit hints, helping the user to find terms to fill typed holes in their programs * The BlockArguments extension, allowing the `$` operator to be omitted in some unambiguous contexts * The next phase of the MonadFail proposal, enabling -XMonadFailDesugaring by default A full list of the changes in this release can be found in the release notes: https://downloads.haskell.org/~ghc/8.6.1-beta1/docs/html/users_guide/8.6.1-… This will very likely be the last release before the final 8.6.1 so do give it a thorough testing and, as always, report any issues you encounter. Thanks for your help! Cheers, - Ben

3 2

ForeignPtr representation
by David Feuer 06 Sep '18

06 Sep '18

I'm trying, and failing, to understand why ForeignPtr is defined the way it is. It all seems rather complicated and redundant. I was thinking we might want to switch to something simpler and more explicit, like this: data ForeignPtr a = ForeignPtr { fptr :: !(Ptr a) -- What we point to froot :: MutableByteArray# RealWorld fwk :: MutVar# RealWorld Any -- The finalizers } froot represents the object the ForeignPtr points into. When created by one of the malloc variants, this will actually be the allocated byte array. Otherwise, it will be a 0-length array. fwk should be seen as having type fwk :: MutVar# RealWorld (Weak# (MutableByteArray# RealWorld)) but we can't express that directly right now. fwk is keyed on froot, and in the malloc case also points to it, to prevent it from being freed prematurely. It seems that this representation requires a couple extra primitive features from Weak#. I think that's okay: Weak# already has some primitive features designed to support ForeignPtr. 1. An operation to add a Haskell finalizer to a Weak#, similar to the one that adds a C finalizer. 2. A way to deal with mixed finalizers: either make the finalizer-adding primops report distinguishable failure on mixing or arrange to run the C finalizers after any Haskell finalizers (since C finalizers are much more likely to actually invalidate the pointer). 3. A documented guarantee about the order in which the finalizers attached to a particular Weak# run, compatible with the ForeignPtr documentation.

3 3

Re: Unpacking coercions
by Ryan Scott 05 Sep '18

05 Sep '18

These aren't mutually exclusive ideas. While I'm sure there's many ways we could solve this problem, David's idea has the distinct advantage of being dead simple. I'd rather not block his vision on some other large refactor that may never materialize. (And if it _does_ materialize, we could revert any wiring-in of Coercible quite easily.) Ryan S.

3 6