From ganesh at earth.li Mon Aug 5 13:01:30 2019 From: ganesh at earth.li (Ganesh Sittampalam) Date: Mon, 5 Aug 2019 14:01:30 +0100 Subject: exhausted simplifier ticks and hs-boot files Message-ID: Hi, The code below (also attached - unzip and run go.sh) triggers the GHC panic "Simplifier ticks exhausted", and I'm unsure whether I should view it as an instance of the known infelicity in the inliner (https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/bugs.html#bugs-ghc) My code does have a recursive datatype, but the recursion isn't contravariant, which is the case described in "Secrets of the GHC inliner" (https://www.microsoft.com/en-us/research/wp-content/uploads/2002/07/inline.pdf, section 4). It's cut down from some real code where I have a mutually recursive datatype that I want to define across two modules for code structuring reasons, meaning I need a .hs-boot file. I haven't been able to reproduce it without the .hs-boot file - if I put everything in one module it stops happening. I've tried with a range of GHC versions from 8.2.x to an early version of 8.8. It happens with -O1 and not -O0, but I haven't managed to find a specific optimisation that triggers it. Is this just an instance of the known problem in a different guise, or is it something different and worth a bug report? Cheers, Ganesh T2.hs-boot ----------- module T2 where data T2 mapP_T2 :: (Int -> Int) -> T2 -> T2 T1.hs ----- module T1 where import {-# SOURCE #-} T2 data T1 = T1 T2 mapP_T1 :: (Int -> Int) -> T1 -> T1 mapP_T1 _ (T1 xs) = T1 (mapP_T2 id xs) T2.hs ----- module T2 where import T1 data T2 = T2 T1 mapP_T2 :: (Int -> Int) -> T2 -> T2 mapP_T2 f (T2 t) = T2 (mapP_T1 f t) go :: T1 -> T1 go = mapP_T1 id GHC output ---------- $ ghc --make T2.hs -O1 -fsimpl-tick-factor=1000 -ddump-simpl-stats) [...] ghc.exe: panic! (the 'impossible' happened) (GHC version 8.2.2 for x86_64-unknown-mingw32): Simplifier ticks exhausted When trying UnfoldingDone mapP_T2 To increase the limit, use -fsimpl-tick-factor=N (default 100) If you need to do this, let GHC HQ know, and what factor you needed Total ticks: 61203 24481 PreInlineUnconditionally 6121 ds_i17h 6120 f_a16p 6120 ds_d17d 6120 ds1_i17i 12241 UnfoldingDone 6121 mapP_T1 6120 mapP_T2 24481 BetaReduction 6121 ds_i17h 6120 f_a16p 6120 ds_d17d 6120 ds1_i17i -------------- next part -------------- A non-text attachment was scrubbed... Name: Simpl.zip Type: application/x-zip-compressed Size: 934 bytes Desc: not available URL: From strake888 at gmail.com Tue Aug 20 21:59:49 2019 From: strake888 at gmail.com (Matthew Farkas-Dyck) Date: Tue, 20 Aug 2019 13:59:49 -0800 Subject: `StablePtr` in `ST` Message-ID: I have been doing some work where i want `StablePtr`, but also to not be confined to `IO`. I saw the following comment in "compiler/prelude/PrimOp.hs": Question: Why @RealWorld@ - won't any instance of @_ST@ do the job? [ADR] It has been there for 20 years. What is the answer? If it is safe i'll send the patch generalizing these operations. From david.feuer at gmail.com Wed Aug 21 00:39:10 2019 From: david.feuer at gmail.com (David Feuer) Date: Wed, 21 Aug 2019 07:39:10 +0700 Subject: `StablePtr` in `ST` In-Reply-To: References: Message-ID: So something like newtype StablePtr a = StablePtr (StablePtrST RealWorld a)? I suppose that could work with some discipline. You have to assume that foreign code doesn't pick its address out of a hat and so something silly, but I guess you pretty much have to assume that anyway. On Wed, Aug 21, 2019, 5:00 AM Matthew Farkas-Dyck wrote: > I have been doing some work where i want `StablePtr`, but also to not > be confined to `IO`. I saw the following comment in > "compiler/prelude/PrimOp.hs": > > Question: Why @RealWorld@ - won't any instance of @_ST@ do the job? [ADR] > > It has been there for 20 years. What is the answer? If it is safe i'll > send the patch generalizing these operations. > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Wed Aug 21 01:08:52 2019 From: david.feuer at gmail.com (David Feuer) Date: Wed, 21 Aug 2019 08:08:52 +0700 Subject: `StablePtr` in `ST` In-Reply-To: References: Message-ID: You also need to avoid inspecting the StablePtr itself, which is just a number, to maintain purity. The whole thing is a bit weird. Why do you want this anyway? On Wed, Aug 21, 2019, 7:39 AM David Feuer wrote: > So something like > > newtype StablePtr a = StablePtr (StablePtrST RealWorld a)? > > I suppose that could work with some discipline. You have to assume that > foreign code doesn't pick its address out of a hat and so something silly, > but I guess you pretty much have to assume that anyway. > > On Wed, Aug 21, 2019, 5:00 AM Matthew Farkas-Dyck > wrote: > >> I have been doing some work where i want `StablePtr`, but also to not >> be confined to `IO`. I saw the following comment in >> "compiler/prelude/PrimOp.hs": >> >> Question: Why @RealWorld@ - won't any instance of @_ST@ do the job? [ADR] >> >> It has been there for 20 years. What is the answer? If it is safe i'll >> send the patch generalizing these operations. >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From evincarofautumn at gmail.com Wed Aug 21 19:38:14 2019 From: evincarofautumn at gmail.com (Jon Purdy) Date: Wed, 21 Aug 2019 12:38:14 -0700 Subject: `StablePtr` in `ST` In-Reply-To: References: Message-ID: Our use case is unsafeCoercing a mutable reference to use as a key in an IntMap. Our reasoning is that coercing an IORef/STRef is unsuitable because the underlying MutVar# may move, invalidating the key (i.e., you cannot safely coerce back if a GC has happened between insertion and reading). (If that’s incorrect, do enlighten us!) This is a “very nice to have” for our purposes—with the understanding that it’s wicked unsafe. ;) On Tue, Aug 20, 2019, 18:09 David Feuer wrote: > You also need to avoid inspecting the StablePtr itself, which is just a > number, to maintain purity. The whole thing is a bit weird. Why do you want > this anyway? > > On Wed, Aug 21, 2019, 7:39 AM David Feuer wrote: > >> So something like >> >> newtype StablePtr a = StablePtr (StablePtrST RealWorld a)? >> >> I suppose that could work with some discipline. You have to assume that >> foreign code doesn't pick its address out of a hat and so something silly, >> but I guess you pretty much have to assume that anyway. >> >> On Wed, Aug 21, 2019, 5:00 AM Matthew Farkas-Dyck >> wrote: >> >>> I have been doing some work where i want `StablePtr`, but also to not >>> be confined to `IO`. I saw the following comment in >>> "compiler/prelude/PrimOp.hs": >>> >>> Question: Why @RealWorld@ - won't any instance of @_ST@ do the job? >>> [ADR] >>> >>> It has been there for 20 years. What is the answer? If it is safe i'll >>> send the patch generalizing these operations. >>> _______________________________________________ >>> Glasgow-haskell-users mailing list >>> Glasgow-haskell-users at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users >>> >> _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Mon Aug 26 09:25:12 2019 From: ben at well-typed.com (Ben Gamari) Date: Mon, 26 Aug 2019 05:25:12 -0400 Subject: [ANNOUNCE] GHC 8.8.1 is now available Message-ID: <87zhjwl1mx.fsf@smart-cactus.org> Hello everyone, The GHC team is pleased to announce the release candidate for GHC 8.8.1. The source distribution, binary distributions, and documentation are available at https://downloads.haskell.org/ghc/8.8.1 This release is the culmination of over 3000 commits by over one hundred contributors and has several new features and numerous bug fixes relative to GHC 8.6: * Visible kind applications are now supported (GHC Proposal #15) * Profiling now works correctly on 64-bit Windows (although still may be problematic on 32-bit Windows due to platform limitations; see #15934) * A new code layout algorithm for amd64's native code generator significantly improving the runtime performance of some kernels * The introduction of a late lambda-lifting pass which may reduce allocations significantly for some programs. * Further work on Trees That Grow, enabling improved code re-use of the Haskell AST in tooling * Users can write `forall` in more contexts (GHC Proposal #7) * The pattern-match checker is now more precise in the presence of strict fields with uninhabited types. * A comprehensive audit of GHC's memory ordering barriers has been performed, resulting in a number of fixes that should significantly improve the reliability of programs on architectures with weakly-ordered memory models (e.g. PowerPC, many ARM and AArch64 implementations). * A long-standing linker limitation rendering GHCi unusable with projects with cyclic symbol dependencies has been fixed (#13786) * Further work on the Hadrian build system * Countless miscellaneous bug-fixes Unfortunately, due to a build issue (#17108) found late in the release process i386 Windows builds are currently unavailable. These will be provided in the coming weeks. As always, if anything looks amiss do let us know. Happy compiling! Cheers, - Ben [1] https://downloads.haskell.org/ghc/8.8.1/docs/html/users_guide/8.8.1-notes.html -------------- 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 Fri Aug 30 21:59:14 2019 From: simonpj at microsoft.com (Simon Peyton Jones) Date: Fri, 30 Aug 2019 21:59:14 +0000 Subject: exhausted simplifier ticks and hs-boot files In-Reply-To: References: Message-ID: Ganesh It's an old bug that has somehow reappeared. I opened https://gitlab.haskell.org/ghc/ghc/issues/17140 But it seems OK in HEAD, and hence probably in GHC 8.8. Can you try? Maybe put further comments on the issue tracker, rather than here. thanks Simon | -----Original Message----- | From: Glasgow-haskell-users On | Behalf Of Ganesh Sittampalam | Sent: 05 August 2019 14:02 | To: glasgow-haskell-users at haskell.org | Subject: exhausted simplifier ticks and hs-boot files | | Hi, | | The code below (also attached - unzip and run go.sh) triggers the GHC | panic "Simplifier ticks exhausted", and I'm unsure whether I should view | it as an instance of the known infelicity in the inliner | (https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/bugs.html | #bugs-ghc) | | My code does have a recursive datatype, but the recursion isn't | contravariant, which is the case described in "Secrets of the GHC inliner" | (https://www.microsoft.com/en-us/research/wp- | content/uploads/2002/07/inline.pdf, | section 4). | | It's cut down from some real code where I have a mutually recursive | datatype that I want to define across two modules for code structuring | reasons, meaning I need a .hs-boot file. I haven't been able to reproduce | it without the .hs-boot file - if I put everything in one module it stops | happening. | | I've tried with a range of GHC versions from 8.2.x to an early version of | 8.8. It happens with -O1 and not -O0, but I haven't managed to find a | specific optimisation that triggers it. | | Is this just an instance of the known problem in a different guise, or is | it something different and worth a bug report? | | Cheers, | | Ganesh | | T2.hs-boot | ----------- | module T2 where | | data T2 | | mapP_T2 :: (Int -> Int) -> T2 -> T2 | | T1.hs | ----- | module T1 where | | import {-# SOURCE #-} T2 | | data T1 = T1 T2 | | mapP_T1 :: (Int -> Int) -> T1 -> T1 | mapP_T1 _ (T1 xs) = T1 (mapP_T2 id xs) | | T2.hs | ----- | | module T2 where | | import T1 | | data T2 = T2 T1 | | mapP_T2 :: (Int -> Int) -> T2 -> T2 | mapP_T2 f (T2 t) = T2 (mapP_T1 f t) | | go :: T1 -> T1 | go = mapP_T1 id | | GHC output | ---------- | $ ghc --make T2.hs -O1 -fsimpl-tick-factor=1000 -ddump-simpl-stats) [...] | ghc.exe: panic! (the 'impossible' happened) | (GHC version 8.2.2 for x86_64-unknown-mingw32): | Simplifier ticks exhausted | When trying UnfoldingDone mapP_T2 | To increase the limit, use -fsimpl-tick-factor=N (default 100) | If you need to do this, let GHC HQ know, and what factor you needed | Total ticks: 61203 | | 24481 PreInlineUnconditionally | 6121 ds_i17h | 6120 f_a16p | 6120 ds_d17d | 6120 ds1_i17i | 12241 UnfoldingDone | 6121 mapP_T1 | 6120 mapP_T2 | 24481 BetaReduction | 6121 ds_i17h | 6120 f_a16p | 6120 ds_d17d | 6120 ds1_i17i