- ghc-devs - Haskell.org

Grand Plan for 8.0.2
by Ben Gamari 19 Sep '16

19 Sep '16

tl;dr: GHC 8.0.2 is coming, however there are a number of issues we would like to see resolved. Consequently it's not entirely clear when it will arrive, but if things go well it may be as early as this Friday. Hello everyone, Over the past few weeks I've been making preparations for the coming 8.0.2 release. I've merged a few more patches to the stable branch in response to last week's call for merge requests, bringing the total up to 180 commits since 8.0.1. At this point there are only a couple things that remain to be cleared up, * #12220, #12533: These are unfortunate behaviors of default signatures, #12220 being an interaction with type applications and #12533 being an obscure corner case. While we have a fix for these (d2958bd0), the fix changes the behavior of the typechecker's inaccessible code check, breaking some code on Hackage; this is documented as #12466. There are some tricky unresolved questions here regarding how we want the inaccessible code here to behave. At the moment I am leaning towards simply punting these off to 8.2.1. If you would like to see them fixed in 8.0.2, please say so. Moreover, please contribute your thoughts on #12466 as resolving the remaining questions on that ticket is a prerequisite for merging the fix for #12220. * #12954: Currently Haddock does not produce documentation for bundled pattern synonyms. There is a pull request [1] that may fix this but it is currently needing reviewers. It would be great to fix this for 8.0.2, but ultimately someone is going to need to finish this up. * #10986: This is a rather unfortunate leak of temporary files which we would ideally fix since it can produce rather large temporary directories on the user's system. * #12519: Haddock inexplicably forgets to render the class members of Eq and Ord. It would be great if someone could get to the bottom of this. * #12433 is a rather nasty correctness bug which currently has no resolution. * #11819: There are still a number of full validation issues which would be nice to sort out. I would like to be able to say that we have a concrete timeline for a 8.0.2 release and I was originally planning to propose a candidate source release for late this week, however in light of the the large number of unresolved issues, I think it would be unwise to commit to this timeframe. I'll say that the candidate source tarball could come as early as Friday, although sometime next week is far more likely. As always, any help that you could offer on any of the above issues would be greatly appreciated. Cheers, - Ben [1] https://github.com/haskell/haddock/pull/494/commits/7984c8fb8f238793641a419…

4 7

8.0 tip doesn't build sans reverting c51caafae7669d
by Carter Schonwald 18 Sep '16

18 Sep '16

I had to revert c51caafae7669d4246f4efd3d1a6858020780e02 to get the tip of 8.0 to work current tip for me as of this checkout d3ac6ce08f282060ca6dc61de527b5b77885ab88

1 0

Do we have free bits in the info pointer itself?
by Ryan Newton 16 Sep '16

16 Sep '16

Our heap object header is one word -- an info table pointer <https://ghc.haskell.org/trac/ghc/wiki/Commentary/Rts/Storage/HeapObjects>. Well, a 64 bit info table pointer leaves *at least* 16 high bits inside the object header for other purposes, right? Is there any problem with using these other than having to mask the info table pointer each time it is dereferenced? Thanks, -Ryan

4 4

Is Safe Haskell intended to allow segfaults?
by Ryan Newton 16 Sep '16

16 Sep '16

We're trying to spend some cycles pushing on Safe Haskell within the stackage packages. (It's looking like a slog.) But we're running up against some basic questions regarding the core packages and Safe Haskell guarantees. The manual currently says: <https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/safe_haskel…> *Functions in the IO monad are still allowed and behave as usual. * As usual? So it is ok to segfault GHC? Elsewhere it says "in the safe language you can trust the types", and I'd always assumed that meant Safe Haskell is a type safe language, even in the IO fragment. Was there an explicit decision to allow segfaults and memory corruption? This can happen not just with FFI calls but with uses of Ptrs within Haskell, for example the following: ``` {-# LANGUAGE Safe #-} module Main where import Foreign.Marshal.Alloc import Foreign.Storable import Foreign.Ptr import System.Random fn :: Ptr Int -> IO () fn p = do -- This is kosher: poke p 3 print =<< peek p -- This should crash the system: ix <- randomIO pokeElemOff p ix 0xcc main = alloca fn ``` -Ryan

10 23

Re: Add a signaling Nans rts option to ghc?
by Carter Schonwald 16 Sep '16

16 Sep '16

IEEE standard specify infinities as distinguished from NAN. Not that the IEEE standard always makes the best choices (semantics of min and max being the naughtiest ). But to the extent that hardware supoorts toggling what values trigger failure it should be reasonably toggle -able For Intel hardware I'll presume only hardware that has sse2 and newer, and maybe a warm-up or sibling patch would be to excise x87 float support from the code gen in GHC Amusingly one intended use for the large space of nan values was to encode the nature of the computation that created the nan. And this was intended to be used by language implementors. Not sure if that will be useful. Anyways, this and the other positive response is encouraging and I'll see about making the time to dig into this stuff. Merry friday all! -Carter On Sep 16, 2016 11:40 AM, "Ben Gamari" <ben(a)smart-cactus.org> wrote: Carter Schonwald <carter.schonwald(a)gmail.com> writes: > Hello All! > I had some interesting conversations yesterday with a few folks and the > take away was that I might experiment with adding an off by default rts > flag that on applicable architectures that makes all floating point > computations that yield Nans signaling , plus mayve some HS side hooks to > enable or disable that per green thread if it doesn't harm no fib. Kinda > like the way green threads track and save / restore the state of the magic > c error tracking variable > Sounds reasonable to me; debugging floating point issues is certainly a chore and this could only help. Regarding a per-thread handling I think we'd certainly need to benchmark. Note that rts/posix/Signals.c already has some logic to handle SIGFPE, although it has been disabled for over a decade due to an infinite loop where the handler immediately threw another FPE. It would be nice to have a solution to this issue; looping is quite bad. Do you lump infinities into the class of NaN values? I'm not sure how much code would fail due to "legitimate" uses of infinity if so. Cheers, - Ben

1 0

-fno-warn lines in the lexer can be removed with Alex 3.1.5
by Ömer Sinan Ağacan 16 Sep '16

16 Sep '16

I was working on the lexer today and realized that we can now remove -fno-warn lines in the lexer if we're OK with requiring Alex >=3.1.5.

2 1

Add a signaling Nans rts option to ghc?
by Carter Schonwald 16 Sep '16

16 Sep '16

Hello All! I had some interesting conversations yesterday with a few folks and the take away was that I might experiment with adding an off by default rts flag that on applicable architectures that makes all floating point computations that yield Nans signaling , plus mayve some HS side hooks to enable or disable that per green thread if it doesn't harm no fib. Kinda like the way green threads track and save / restore the state of the magic c error tracking variable Would this be something folks would be open to adding once I hack it out? Most modern CPUs have some built in support for this, but having better rts integration might make things way nicer. Plus part of the point of the sheer diversity of Nans as per the IEEE report is to encode the nature of the source of the nan error. (There are other parts of IEEE that I think should be ignored / we should change the behavior in a way that disagrees with IEEE choices that hinder debugging and such )

3 2

Better perf?
by Simon Peyton Jones 13 Sep '16

13 Sep '16

I’m getting this perf improvement from T5837, which is type-function heavy. Is anyone else seeing this bytes allocated value is too low: (If this is because you have improved GHC, please update the test so that GHC doesn't regress again) Expected T5837(normal) bytes allocated: 48507272 +/-10% Lower bound T5837(normal) bytes allocated: 43656544 Upper bound T5837(normal) bytes allocated: 53358000 Actual T5837(normal) bytes allocated: 42384144 Deviation T5837(normal) bytes allocated: -12.6 % Its good, but I’d quite like to know which patch made the difference. Could it be commit 03541cbae50f0d1cdf99120ab88698f29a278159 Author: Simon Peyton Jones <simonpj(a)microsoft.com> Date: Fri Sep 9 17:42:42 2016 +0100 Be less picky about reporing inaccessible code Seems implausible, but possible I suppose. Simon

2 2

Re: [GHC] #8763: forM_ [1..N] does not get fused (10 times slower than go function)
by George Colpitts 12 Sep '16

12 Sep '16

Thanks Ben, np. On Mon, Sep 12, 2016 at 11:33 AM GHC <ghc-devs(a)haskell.org> wrote: > #8763: forM_ [1..N] does not get fused (10 times slower than go function) > -------------------------------------+------------------------------------- > Reporter: nh2 | Owner: > Type: bug | Status: new > Priority: normal | Milestone: 8.2.1 > Component: Compiler | Version: 7.6.3 > Resolution: | Keywords: > Operating System: Unknown/Multiple | Architecture: > Type of failure: Runtime | Unknown/Multiple > performance bug | Test Case: > Blocked By: | Blocking: > Related Tickets: | Differential Rev(s): > Wiki Page: | > -------------------------------------+------------------------------------- > Changes (by bgamari): > > * milestone: 8.0.2 => 8.2.1 > > > Comment: > > I'm afraid 8.0.2 is out of the question. However, 8.2.1 is a possibility. > Of course, any help that you, the reader, can offer would expedite the > process. > > -- > Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8763#comment:25> > GHC <http://www.haskell.org/ghc/> > The Glasgow Haskell Compiler >

1 0

RE: vectorisation code?
by Simon Peyton Jones 12 Sep '16

12 Sep '16

Austin, (or anyone else) Manuel says: | > Would it be ok if we left it in the repo, but CPP'd it out so that | we | > didn't compile everything? (The DPH library is in the same state at | > the moment.) | > | > It might suffer bit-rot, but it’d still be there for resurrection. | | Sure, that’s ok. Could you action this? Just avoid compiling anything in 'vectorise/', using (I suppose) cpp to create a stub where necessary. Leave enough comments to explain! Simon | | I hope everything is fine in Cambridge! | Manuel | | > | -----Original Message----- | > | From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of | > | Manuel M T Chakravarty | > | Sent: 16 January 2015 02:58 | > | To: Richard Eisenberg | > | Cc: ghc-devs(a)haskell.org Devs | > | Subject: Re: vectorisation code? | > | | > | [Sorry, sent from the wrong account at first.] | > | | > | We currently don’t have the resources to work on DPH. I would | > | obviously prefer to leave the code in, in the hope that we will be | > | able to return to it. | > | | > | Manuel | > | | > | > Richard Eisenberg <eir(a)cis.upenn.edu>: | > | > | > | > Hi devs, | > | > | > | > There's a sizable number of modules in the `vectorise` | > | subdirectory of GHC. I'm sure these do all sorts of wonderful | > | things. But what, exactly? And, does anyone make use of these | wonderful things? | > | > | > | > A quick poking through the code shows a tiny link between the | > | vectorise code and the rest of GHC -- the function `vectorise` | > | exported from the module `Vectorise`, which is named in exactly | one | > | place from SimplCore. From what I can tell, the function will be | > | called only when `-fvectorise` is specified, and then it seems to | > | interact with a {-# VECTORISE #-} pragma. However, `{-# VECTORISE | > | #-}` doesn't appear in the manual at all, and `-fvectorise` is | > | given only a cursory explanation. It seems these work with DPH... | > | which has been disabled, no? Searching online finds several hits, | > | but nothing more recent than 2012. | > | > | > | > I hope this question doesn't offend -- it seems that | > | vectorisation probably has amazing performance gains. Yet, the | > | feature also seems unloved. In the meantime, compiling (and | > | recompiling, and | > | recompiling...) the modules takes time, as does going through | them | > | to propagate changes from elsewhere. If this feature is truly | > | orphaned, unloved, and unused at the moment, is it reasonable to | > | consider putting it on furlough? | > | > | > | > Thanks, | > | > Richard | > | > _______________________________________________ | > | > ghc-devs mailing list | > | > ghc-devs(a)haskell.org | > | > http://www.haskell.org/mailman/listinfo/ghc-devs | > | | > | _______________________________________________ | > | ghc-devs mailing list | > | ghc-devs(a)haskell.org | > | http://www.haskell.org/mailman/listinfo/ghc-devs

13 35