From ghc-devs at haskell.org Thu Dec 1 00:11:17 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Dec 2016 00:11:17 -0000 Subject: [GHC] #11821: Internal error: not in scope during type checking, but it passed the renamer In-Reply-To: <046.3b1a9cc72dda92db8ed761d8d50006f8@haskell.org> References: <046.3b1a9cc72dda92db8ed761d8d50006f8@haskell.org> Message-ID: <061.ca839fc97132bac0721d5184b25d226d@haskell.org> #11821: Internal error: not in scope during type checking, but it passed the renamer -------------------------------------+------------------------------------- Reporter: darchon | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1-rc3 Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | polykinds/T11821 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2146 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"6c54fa512c4280e8047ba7891d42ba14bb88b149/ghc" 6c54fa51/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6c54fa512c4280e8047ba7891d42ba14bb88b149" testsuite: Add another testcase for #11821 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 1 00:11:42 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Dec 2016 00:11:42 -0000 Subject: [GHC] #11821: Internal error: not in scope during type checking, but it passed the renamer In-Reply-To: <046.3b1a9cc72dda92db8ed761d8d50006f8@haskell.org> References: <046.3b1a9cc72dda92db8ed761d8d50006f8@haskell.org> Message-ID: <061.fdfc4fd5a8526663eb151f88641e466d@haskell.org> #11821: Internal error: not in scope during type checking, but it passed the renamer -------------------------------------+------------------------------------- Reporter: darchon | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1-rc3 Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | polykinds/T11821, polykinds/T11821a Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2146 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * testcase: polykinds/T11821 => polykinds/T11821, polykinds/T11821a Comment: Added test for case from comment:12 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 1 00:33:37 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Dec 2016 00:33:37 -0000 Subject: [GHC] #12906: GHC fails to typecheck Main module without main Message-ID: <045.9f131820c17fbe502671d27a0102f251@haskell.org> #12906: GHC fails to typecheck Main module without main -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Given a `Main` module without a `main` value, GHC 8 reports the missing `main` and then exits, without bothering to typecheck the rest of the module. Previous versions, I believe, had the more useful behavior of reporting type errors regardless. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 1 00:34:44 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Dec 2016 00:34:44 -0000 Subject: [GHC] #12234: 'deriving Eq' on recursive datatype makes ghc eat a lot of CPU and RAM In-Reply-To: <045.352c8bb25c33b092176709513059d519@haskell.org> References: <045.352c8bb25c33b092176709513059d519@haskell.org> Message-ID: <060.bdc993dd7e99d46377fcc69b007e018c@haskell.org> #12234: 'deriving Eq' on recursive datatype makes ghc eat a lot of CPU and RAM -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: deriving-perf Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: niteria (added) Comment: Replying to [comment:7 goldfire]: > Maybe we should use "stock" for recursive newtypes? Maybe. But it bothers me that this used to work fine in 7.10.3. I did some git archaeology and discovered that this commit ( http://git.haskell.org/ghc.git/commit/9cb192ce4b34a472041010df9c30f5d741eb0261 ) is responsible for this regression, but I don't understand why a change to the digraph code led to this. niteria, any thoughts as the author of the commit? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 1 00:40:19 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Dec 2016 00:40:19 -0000 Subject: [GHC] #9832: Get rid of PERL dependency of `ghc-split` In-Reply-To: <042.a80d180822707ef08b1350d4a542cee3@haskell.org> References: <042.a80d180822707ef08b1350d4a542cee3@haskell.org> Message-ID: <057.4563137d3250efc55f2921e75fbc7fc7@haskell.org> #9832: Get rid of PERL dependency of `ghc-split` ---------------------------------+---------------------------------------- Reporter: hvr | Owner: dobenour Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Driver | Version: Resolution: | Keywords: perl Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8405 | Differential Rev(s): D2768 Wiki Page: | ---------------------------------+---------------------------------------- Changes (by dobenour): * owner: Phyx- => dobenour * differential: => D2768 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 1 01:18:55 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Dec 2016 01:18:55 -0000 Subject: [GHC] #12234: 'deriving Eq' on recursive datatype makes ghc eat a lot of CPU and RAM In-Reply-To: <045.352c8bb25c33b092176709513059d519@haskell.org> References: <045.352c8bb25c33b092176709513059d519@haskell.org> Message-ID: <060.690d89c86c9f1fe80151675e01ad9d0b@haskell.org> #12234: 'deriving Eq' on recursive datatype makes ghc eat a lot of CPU and RAM -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: deriving-perf Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by niteria): Shot in the dark: does solving coercibility for recursive newtypes involve finding fixpoints? I've run into one place in the code generator once where not returning the elements of a set in the Unique order would make it never find a fixpoint, because the insertion order would oscillate between 2 values. Otherwise, maybe using Unique order for SCC had some nice properties in this case. But under normal circumstances, I wouldn't expect my commit to cause that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 1 01:51:53 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Dec 2016 01:51:53 -0000 Subject: [GHC] #12907: ExtendedDefaultRules-related regression in GHC 8.0.2 Message-ID: <050.e7f00687e9a9a96cf3fa77c11f6cda6b@haskell.org> #12907: ExtendedDefaultRules-related regression in GHC 8.0.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 8.0.2-rc1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Commit https://git.haskell.org/ghc.git/commit/9a34bf1985035858ece043bf38b47b6ff4b88efb introduced a regression between GHC 8.0.1 and 8.0.2 regarding the behavior of `ExtendedDefaultRules`. In GHC 8.0.1, this program {{{#!hs module Bug where default (Bool) }}} would compile without issue. On GHC 8.0.2, however, it is rejected with this error message: {{{ $ /opt/ghc/8.0.2/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:3:1: error: • The default type ‘Bool’ is not an instance of ‘Num’ • When checking the types in a default declaration }}} As a result, the `shelly` library now fails to compile with GHC 8.0.2 (see https://github.com/yesodweb/Shelly.hs/issues/130). A workaround is to explicitly enable `ExtendedDefaultRules` at the top of the module. Richard, do you understand what's going on here? I'm not sure if this is a real regression or just GHC being more particular (admittedly, I don't understand many of the intricacies of `ExtendedDefaultRules`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 1 01:53:16 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Dec 2016 01:53:16 -0000 Subject: [GHC] #9775: "Failed to remove" errors during Windows build from hsc2hs In-Reply-To: <045.a3bc7893c1159a7aa08bb934a48297de@haskell.org> References: <045.a3bc7893c1159a7aa08bb934a48297de@haskell.org> Message-ID: <060.c6d0a696ae369aecd3330c06fc3c3eba@haskell.org> #9775: "Failed to remove" errors during Windows build from hsc2hs ---------------------------------+---------------------------------------- Reporter: gintas | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: hsc2hs | Version: 7.8.3 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by Phyx-): * priority: low => normal * owner: => Phyx- * milestone: => 8.2.1 Comment: This is blocking reliable clean validates. Think I have a fix for it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 1 01:55:18 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Dec 2016 01:55:18 -0000 Subject: [GHC] #12907: ExtendedDefaultRules-related regression in GHC 8.0.2 In-Reply-To: <050.e7f00687e9a9a96cf3fa77c11f6cda6b@haskell.org> References: <050.e7f00687e9a9a96cf3fa77c11f6cda6b@haskell.org> Message-ID: <065.b983c8b792d04e671c554b15948e2423@haskell.org> #12907: ExtendedDefaultRules-related regression in GHC 8.0.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.2 Component: Compiler (Type | Version: 8.0.2-rc1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: goldfire (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 1 01:57:00 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Dec 2016 01:57:00 -0000 Subject: [GHC] #11974: `default` declaration doesn't allow higher-kinded types In-Reply-To: <047.2c4be3a4c34290389efa6f45ff0342fe@haskell.org> References: <047.2c4be3a4c34290389efa6f45ff0342fe@haskell.org> Message-ID: <062.e402e8b571fd271d7c3ffdc0f2241bb5@haskell.org> #11974: `default` declaration doesn't allow higher-kinded types -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T11974, | typecheck/should_fail/T11974b Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2136 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Fixing this seems to have (inadvertently?) changed the behavior of `ExtendedDefaultRules` in a subtle way in GHC 8.0.2. See #12907. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 1 03:14:06 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Dec 2016 03:14:06 -0000 Subject: [GHC] #12234: 'deriving Eq' on recursive datatype makes ghc eat a lot of CPU and RAM In-Reply-To: <045.352c8bb25c33b092176709513059d519@haskell.org> References: <045.352c8bb25c33b092176709513059d519@haskell.org> Message-ID: <060.cbee73e7a6781fba4fd1041720408a7d@haskell.org> #12234: 'deriving Eq' on recursive datatype makes ghc eat a lot of CPU and RAM -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: deriving-perf Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by niteria): I was able to reproduce it, and indeed my commit has some effect. I narrowed it down with https://phabricator.haskell.org/P127 to ordering inside `occAnalRecBind`. It appears that the simplifier is sensitive to this order in this case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 1 03:58:05 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Dec 2016 03:58:05 -0000 Subject: [GHC] #12895: Lookup rules associated with functions/values in GHCI In-Reply-To: <050.77123088f451c66baebc2915daeb885f@haskell.org> References: <050.77123088f451c66baebc2915daeb885f@haskell.org> Message-ID: <065.fb4cdae0871e69ec0b5b2d746729f443@haskell.org> #12895: Lookup rules associated with functions/values in GHCI -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by harpocrates): Replying to [comment:1 simonpj]: > I can see the value, and I don't think it'd be hard. Happy to advise. > > First look at how `:info` works, I suggest. > > Simon After a quick survey of how `:info` works, I think I'm starting to see what needs to be done (or getting lost). As `:info` does for finding instances, I'll need to start by loading some interfaces to make sure I really do find all my `RULES`, then I should be able to get out of the `ExternalPackageState` a `RuleBase`, at which point I just need to filter for the right `CoreRule`s . However, is `CoreRule` really the abstraction I'm looking for? I noticed there is also an interface level `IfaceRule` and a type checker level `LRuleDecl Id` (from `TcGblEnv`) so I thought I'd ask... More generally, how little of this sounds right? :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 1 04:08:37 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Dec 2016 04:08:37 -0000 Subject: [GHC] #12234: 'deriving Eq' on recursive datatype makes ghc eat a lot of CPU and RAM In-Reply-To: <045.352c8bb25c33b092176709513059d519@haskell.org> References: <045.352c8bb25c33b092176709513059d519@haskell.org> Message-ID: <060.576a7ae89c30224e4fe8d68335c2fed8@haskell.org> #12234: 'deriving Eq' on recursive datatype makes ghc eat a lot of CPU and RAM -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: deriving-perf Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by niteria): Simplifier stats reveal significantly more `Class op ==` rule rewrites, and passing `-fno-enable-rewrite-rules` fixes the issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 1 04:10:57 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Dec 2016 04:10:57 -0000 Subject: [GHC] #12908: Tuple constraints refactoring seems to regress performance considerably Message-ID: <046.5462e2db6c503e4b14bcdb8c72713d1a@haskell.org> #12908: Tuple constraints refactoring seems to regress performance considerably -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: performance | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- ffc21506894c7887d3620423aaf86bc6113a1071 seems to cause compiler runtime regression as large as 15%. This deserves some attention. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 1 06:14:02 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Dec 2016 06:14:02 -0000 Subject: [GHC] #12899: ghc panics at random places with -jX In-Reply-To: <044.e06c34ff950f64285fd655be98faab7e@haskell.org> References: <044.e06c34ff950f64285fd655be98faab7e@haskell.org> Message-ID: <059.6d3a40356b6c102d81212b395350d72c@haskell.org> #12899: ghc panics at random places with -jX -------------------------------------+------------------------------------- Reporter: pacak | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by pacak): I confirmed that it no longer fails if compiled with -j1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 1 08:01:28 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Dec 2016 08:01:28 -0000 Subject: [GHC] #12907: ExtendedDefaultRules-related regression in GHC 8.0.2 In-Reply-To: <050.e7f00687e9a9a96cf3fa77c11f6cda6b@haskell.org> References: <050.e7f00687e9a9a96cf3fa77c11f6cda6b@haskell.org> Message-ID: <065.5f2e23cf113b17ae8ce83adcfaef6133@haskell.org> #12907: ExtendedDefaultRules-related regression in GHC 8.0.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.2 Component: Compiler (Type | Version: 8.0.2-rc1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): Just for the record, I consider this GHC being faithful to H2010 when it rejects the code {{{#!hs module Bug where default (Bool) }}} since [https://www.haskell.org/onlinereport/haskell2010/haskellch4.html#x10-790004.3.4 4.3.4] says: > Ambiguities in the class Num are most common, so Haskell provides another way to resolve them—with a default declaration: default (t1 , … , tn) where n ≥ 0, and each ti must be a type for which Num ti holds. And `Bool` is not an instance of `Num`, hence the code above is not legal plain Haskell2010 code. Personally, I consider this a bugfix rather than a regression :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 1 09:28:23 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Dec 2016 09:28:23 -0000 Subject: [GHC] #12908: Tuple constraints refactoring seems to regress performance considerably In-Reply-To: <046.5462e2db6c503e4b14bcdb8c72713d1a@haskell.org> References: <046.5462e2db6c503e4b14bcdb8c72713d1a@haskell.org> Message-ID: <061.b0098c2d068c0288b56c6a0e3d03ab93@haskell.org> #12908: Tuple constraints refactoring seems to regress performance considerably -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: performance Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Concrete examples? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 1 09:31:15 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Dec 2016 09:31:15 -0000 Subject: [GHC] #12895: Lookup rules associated with functions/values in GHCI In-Reply-To: <050.77123088f451c66baebc2915daeb885f@haskell.org> References: <050.77123088f451c66baebc2915daeb885f@haskell.org> Message-ID: <065.d3ca6c9c5150807120d765c72bc9f972@haskell.org> #12895: Lookup rules associated with functions/values in GHCI -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Sounds about right. You should think of `IfaceSyn` as simply a tree full of strings that is the result of parsing the bits in an interface file. It's not suitable for anythingn except printing. `TcIface` converts `IfaceSyn` to `CoreSyn`, `CoreRule`, `TyCon` etc. I suggest you work with `CoreRules`. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 1 13:19:29 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Dec 2016 13:19:29 -0000 Subject: [GHC] #11293: Compiler plugins don't work with profiling In-Reply-To: <045.b5b56c876d4358651f52b61f0cb4e70b@haskell.org> References: <045.b5b56c876d4358651f52b61f0cb4e70b@haskell.org> Message-ID: <060.5c203dd6a107a230f03071ab4b12c44c@haskell.org> #11293: Compiler plugins don't work with profiling -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by shlevy): With the ultimate goal of supporting TH in cross-compilation, I've got a WIP branch to separate out compile time and runtime code more rigorously at https://github.com/shlevy/ghc/tree/lifecycle-staging (current WIP branch is on separating out the HPT). This work is temporarily on hold while I get a quick fix working using external-interpreter running on the target, but I hope to get back to it soon as it's clearly the better long- term solution and works for plugins too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 1 13:20:28 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Dec 2016 13:20:28 -0000 Subject: [GHC] #11377: Template Haskell only imports In-Reply-To: <045.7f717f9d66578f30b0c37a668b428368@haskell.org> References: <045.7f717f9d66578f30b0c37a668b428368@haskell.org> Message-ID: <060.4ed4d8e322198b758aa0e6a906974484@haskell.org> #11377: Template Haskell only imports -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Template Haskell | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by shlevy): With the ultimate goal of supporting TH in cross-compilation, I've got a WIP branch to separate out compile time and runtime code more rigorously at https://github.com/shlevy/ghc/tree/lifecycle-staging (current WIP commit is on separating out the HPT). This work is temporarily on hold while I get a quick fix working using external-interpreter running on the target, but I hope to get back to it soon as it's clearly the better long- term solution and works for plugins too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 1 13:35:58 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Dec 2016 13:35:58 -0000 Subject: [GHC] #11378: Use the compiler that built ghc for dynamic code loading, for cross-compiling In-Reply-To: <045.6104ef63780cb1088603ac8080468c98@haskell.org> References: <045.6104ef63780cb1088603ac8080468c98@haskell.org> Message-ID: <060.ca14e401c968e6f4bb46801aa38282e6@haskell.org> #11378: Use the compiler that built ghc for dynamic code loading, for cross- compiling -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: lowest | Milestone: ⊥ Component: Template Haskell | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11470 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by shlevy): I don't think it's really most of the work, since we already need to know all of the relevant info about the host and the target to do cross- compiling at all, whereas #11470 requires info about arbitrary targets. I think the best option here is to do a 3- or 4- stage compile for cross- compilation, where the last stage is optional: 3-stage: stage 1 is normal host-native stage 1, stage 2 runs on host and can target both host and target, stage 3 is a cross-compiled target-native GHC. This has the benefit of only requiring the stage 2 compiler to be around to do TH/plugins/ghci, but requires a single ghc binary to be able to target two architectures 4-stage: stage 1 and stage 2 are normal host-native stage 1 and stage 2, stage 3 runs on host and targets target, stage 4 is a cross-compiled target-native GHC. This has the benefit of not needing to teach a single compiler multiple targets, but you'd need to keep both stage 2 and stage 3 around if you wanted to do TH/plugins/ghci. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 1 13:38:08 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Dec 2016 13:38:08 -0000 Subject: [GHC] #11378: Use the compiler that built ghc for dynamic code loading, for cross-compiling In-Reply-To: <045.6104ef63780cb1088603ac8080468c98@haskell.org> References: <045.6104ef63780cb1088603ac8080468c98@haskell.org> Message-ID: <060.3d48acda099a7d591b1cd725065c7826@haskell.org> #11378: Use the compiler that built ghc for dynamic code loading, for cross- compiling -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: lowest | Milestone: ⊥ Component: Template Haskell | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11470 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by shlevy): (and yes, in either case we need two versions of base etc.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 1 13:40:11 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Dec 2016 13:40:11 -0000 Subject: [GHC] #12907: ExtendedDefaultRules-related regression in GHC 8.0.2 In-Reply-To: <050.e7f00687e9a9a96cf3fa77c11f6cda6b@haskell.org> References: <050.e7f00687e9a9a96cf3fa77c11f6cda6b@haskell.org> Message-ID: <065.db580bef3eb0aee0e8e05e2478c1df8a@haskell.org> #12907: ExtendedDefaultRules-related regression in GHC 8.0.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.2 Component: Compiler (Type | Version: 8.0.2-rc1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I agree with comment:2. The change to reject the program reported was intentional, following the Report. When `-XExtendedDefaultRules` is in effect, the program given is accepted, as `Bool` is a member of several of the classes defaultable under the extended rules. I'd be willing to consider other designs here, but I believe what's implemented is the most faithful to the Report. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 1 14:26:15 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Dec 2016 14:26:15 -0000 Subject: [GHC] #12903: SIGINT is not handled in forked process In-Reply-To: <045.73f1eb35eda69f56b71c66e83162bd9f@haskell.org> References: <045.73f1eb35eda69f56b71c66e83162bd9f@haskell.org> Message-ID: <060.011e3d570717d76a0b7c5b1918ccd823@haskell.org> #12903: SIGINT is not handled in forked process -------------------------------------+------------------------------------- Reporter: qnikst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2770 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Khudyakov): * cc: Khudyakov (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 1 14:29:19 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Dec 2016 14:29:19 -0000 Subject: [GHC] #12907: ExtendedDefaultRules-related regression in GHC 8.0.2 In-Reply-To: <050.e7f00687e9a9a96cf3fa77c11f6cda6b@haskell.org> References: <050.e7f00687e9a9a96cf3fa77c11f6cda6b@haskell.org> Message-ID: <065.40865a9441662abfb29cff99294e02cb@haskell.org> #12907: ExtendedDefaultRules-related regression in GHC 8.0.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: patch Priority: high | Milestone: 8.0.2 Component: Compiler (Type | Version: 8.0.2-rc1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2774 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D2774 Comment: Thanks, hvr, that section of the Haskell Report is helpful. And it's also nice to know that the author (goldfire) intended for this to happen. Now that I better understand all the actors in this production, I also agree that this behavior is reasonable. The only thing missing from https://git.haskell.org/ghc.git/commit/9a34bf1985035858ece043bf38b47b6ff4b88efb was a note in the users' guide. I've opened Phab:D2774 for this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 1 14:44:12 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Dec 2016 14:44:12 -0000 Subject: [GHC] #12796: hschooks.c #include path is incorrect In-Reply-To: <046.be652681697ce65090aa6a04158d2f64@haskell.org> References: <046.be652681697ce65090aa6a04158d2f64@haskell.org> Message-ID: <061.97eba8b0bb4ef81c3b01725a91a3ccad@haskell.org> #12796: hschooks.c #include path is incorrect -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): The patch in comment:1 is very wrong. In fact, we *need* to include `Rts.h` from the bootstrap compiler; afterall, the final `ghc` executable will be linked against the bootstrap RTS. This was reverted in 795f8bd460d604c792a5df8cfec937b2a74c3956. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 1 15:31:23 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Dec 2016 15:31:23 -0000 Subject: [GHC] #11445: Turn on SplitSections by default In-Reply-To: <045.848c295688fc284737f19db2f979eda9@haskell.org> References: <045.848c295688fc284737f19db2f979eda9@haskell.org> Message-ID: <060.d7a6fd704bad6874d917acb5c6a0620f@haskell.org> #11445: Turn on SplitSections by default -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Build System | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 11285 Related Tickets: | Differential Rev(s): Phab:D1800 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dobenour): Phyx-: Ah okay. For some reason I thought that he had. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 1 16:07:41 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Dec 2016 16:07:41 -0000 Subject: [GHC] #12905: Core lint failure with pattern synonym and levity polymorphism (was: Core lint with pattern synonym) In-Reply-To: <046.5ce6798de5363e50c2fbb8c2a8dbf24c@haskell.org> References: <046.5ce6798de5363e50c2fbb8c2a8dbf24c@haskell.org> Message-ID: <061.6cb590c13c30fec76323af279e931510@haskell.org> #12905: Core lint failure with pattern synonym and levity polymorphism -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: levity- Resolution: | polymorphic, typeable Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: typeable => levity-polymorphic, typeable -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 1 16:11:02 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Dec 2016 16:11:02 -0000 Subject: [GHC] #12909: Python 3.2 doesn't support Unicode literal syntax Message-ID: <046.12ac4bd460b63f64fb7ac16b0d1a0441@haskell.org> #12909: Python 3.2 doesn't support Unicode literal syntax -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Simonpj noticed that the Python 3.2 interpreter on his Ubuntu 12.04 installation doesn't support Unicode literal syntax (e.g. `u'hello'`). Indeed it seems this syntax was dropped in Python 3 and later re- introduced in Python 3.3 (https://www.python.org/dev/peps/pep-0414/). At this point we have a decision to make: Either drop the uses of Unicode literals in the driver (and, consequently, support for Python 2) or keep things as they are and demand Python >3.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 1 16:11:30 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Dec 2016 16:11:30 -0000 Subject: [GHC] #12909: Python 3.2 doesn't support Unicode literal syntax In-Reply-To: <046.12ac4bd460b63f64fb7ac16b0d1a0441@haskell.org> References: <046.12ac4bd460b63f64fb7ac16b0d1a0441@haskell.org> Message-ID: <061.0295678caa019e9c20fbc02cbdc8be01@haskell.org> #12909: Python 3.2 doesn't support Unicode literal syntax -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2778 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * differential: => Phab:D2778 Comment: We are going to move ahead with dropping Python 2 support. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 1 16:14:27 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Dec 2016 16:14:27 -0000 Subject: [GHC] #12909: Python 3.2 doesn't support Unicode literal syntax In-Reply-To: <046.12ac4bd460b63f64fb7ac16b0d1a0441@haskell.org> References: <046.12ac4bd460b63f64fb7ac16b0d1a0441@haskell.org> Message-ID: <061.d75ffb503bc3eb4d08164b92fd0dd7ac@haskell.org> #12909: Python 3.2 doesn't support Unicode literal syntax -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9184 | Differential Rev(s): Phab:D2778 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: => #9184 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 1 17:04:30 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Dec 2016 17:04:30 -0000 Subject: [GHC] #12886: Proposal for throwLeft and throwLeftIO in Control.Exception In-Reply-To: <048.20cdb7217c9551470366c48ee53b317a@haskell.org> References: <048.20cdb7217c9551470366c48ee53b317a@haskell.org> Message-ID: <063.519a8fd35f799beb5338bb002c7644b0@haskell.org> #12886: Proposal for throwLeft and throwLeftIO in Control.Exception -------------------------------------+------------------------------------- Reporter: yfeldblum | Owner: ekmett Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): It used to be, now the process is to create a ticket on Trac, see https://wiki.haskell.org/Library_submissions#Guide_to_proposers -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 1 17:06:18 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Dec 2016 17:06:18 -0000 Subject: [GHC] #9832: Get rid of PERL dependency of `ghc-split` In-Reply-To: <042.a80d180822707ef08b1350d4a542cee3@haskell.org> References: <042.a80d180822707ef08b1350d4a542cee3@haskell.org> Message-ID: <057.c3702ccd42aeb2097d807b0dae1fdfbc@haskell.org> #9832: Get rid of PERL dependency of `ghc-split` ---------------------------------+---------------------------------------- Reporter: hvr | Owner: dobenour Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Driver | Version: Resolution: | Keywords: perl Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8405 | Differential Rev(s): D2768 Wiki Page: | ---------------------------------+---------------------------------------- Comment (by dobenour): Replying to [comment:26 olsner]: > Replying to [comment:24 dobenour]: > > I think we can deprecate it on other systems too, except (possibly) OS X (which I believe bundles Perl with the OS). > > I think GHC on OS X doesn't even support `-split-objs`, rather it uses the builtin subsections and `-dead_strip` linker flag, so that wouldn't be a blocker. > > It's just Windows support for split sections that we might want to wait for before we start ripping stuff out. GHC does support `-split-objs` on OS X, but I can't think of a good reason to use it. I also can't think of a good reason to use `-split-objs` when `-split-sections` works. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 1 17:42:44 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Dec 2016 17:42:44 -0000 Subject: [GHC] #12865: POSIX osDecommitMemory has nasty compatibility problems In-Reply-To: <046.4ae668e01490d7d770171a5fd8c666d2@haskell.org> References: <046.4ae668e01490d7d770171a5fd8c666d2@haskell.org> Message-ID: <061.e5f6ba7c73be9379c10802d1c7bb9dd1@haskell.org> #12865: POSIX osDecommitMemory has nasty compatibility problems -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: patch Priority: high | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2780 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D2780 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 1 17:52:23 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Dec 2016 17:52:23 -0000 Subject: [GHC] #12910: Mirror mingw signature files Message-ID: <046.919b607002a73f8f107ad4fda8036ab2@haskell.org> #12910: Mirror mingw signature files ----------------------------------------+--------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: high | Milestone: 8.2.1 Component: None | Version: 8.0.1 Keywords: | Operating System: POSIX Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- We should really provide signatures alongside the mingw binaries and sources on `ghc.haskell.org`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 1 17:53:01 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Dec 2016 17:53:01 -0000 Subject: [GHC] #12907: ExtendedDefaultRules-related regression in GHC 8.0.2 In-Reply-To: <050.e7f00687e9a9a96cf3fa77c11f6cda6b@haskell.org> References: <050.e7f00687e9a9a96cf3fa77c11f6cda6b@haskell.org> Message-ID: <065.c059aa6c397abed9752bbc29e79376fb@haskell.org> #12907: ExtendedDefaultRules-related regression in GHC 8.0.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: patch Priority: high | Milestone: 8.0.2 Component: Compiler (Type | Version: 8.0.2-rc1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2774 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"a452c6e57a286f3b31f0e3fbef83cbea0cee8b34/ghc" a452c6e5/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a452c6e57a286f3b31f0e3fbef83cbea0cee8b34" Make note of #12907 in 8.0.2 release notes Test Plan: Read it, commit it, merge it, ship it Reviewers: goldfire, bgamari, austin, hvr, simonpj Reviewed By: simonpj Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2774 GHC Trac Issues: #12907 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 1 17:53:01 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Dec 2016 17:53:01 -0000 Subject: [GHC] #12901: Levity polymorphic expressions mustn't be floated out In-Reply-To: <045.824b9429e978b9ce967c7d331fdd0c97@haskell.org> References: <045.824b9429e978b9ce967c7d331fdd0c97@haskell.org> Message-ID: <060.3aceec89611fee75f39348c6093b5ab4@haskell.org> #12901: Levity polymorphic expressions mustn't be floated out -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: hsyl20 Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"514c01eec5f2b23f278c29b61345dce6c37900f1/ghc" 514c01ee/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="514c01eec5f2b23f278c29b61345dce6c37900f1" Levity polymorphic expressions mustn't be floated-out in let-bindings. Reviewers: simonpj, austin, bgamari Reviewed By: simonpj, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2769 GHC Trac Issues: #12901 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 1 18:09:17 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Dec 2016 18:09:17 -0000 Subject: [GHC] #12907: ExtendedDefaultRules-related regression in GHC 8.0.2 In-Reply-To: <050.e7f00687e9a9a96cf3fa77c11f6cda6b@haskell.org> References: <050.e7f00687e9a9a96cf3fa77c11f6cda6b@haskell.org> Message-ID: <065.a96b9653e99614dc8978ac3c0c1ccd59@haskell.org> #12907: ExtendedDefaultRules-related regression in GHC 8.0.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: merge Priority: high | Milestone: 8.0.2 Component: Compiler (Type | Version: 8.0.2-rc1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2774 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => merge Comment: And with that, I think that takes care of all the 8.0.2 regressions that I discovered when smoke-testing Stackage. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 1 18:17:46 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Dec 2016 18:17:46 -0000 Subject: [GHC] #11445: Turn on SplitSections by default In-Reply-To: <045.848c295688fc284737f19db2f979eda9@haskell.org> References: <045.848c295688fc284737f19db2f979eda9@haskell.org> Message-ID: <060.8673ab63e6b12baa2cc6b190e8446a7c@haskell.org> #11445: Turn on SplitSections by default -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Build System | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 11285 Related Tickets: | Differential Rev(s): Phab:D1800 Wiki Page: | -------------------------------------+------------------------------------- Comment (by awson): Well, things are absolutely OK with `-split-sections` for 64-bit PECOFF obj files, but there exist a critical problem for the 32-bit case. The problem is that to realistically work with `-split-sections` (even to build `GHC` itself, particularly `template-haskell` package, particularly `Language.Haskell.TH.Syntax` module compiled in profiling mode) we need `big-obj` support (to have more than 32K sections per object file), but `binutils` '''has no''' `big-obj` support for 32-bit PECOFF object files. Perhaps, the simplest solution would be to have another splitter, which would split the whole assembly to chunks with no more than 32K sections in each. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 1 18:27:37 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Dec 2016 18:27:37 -0000 Subject: [GHC] #9184: Allow the use of Python 3 when building GHC In-Reply-To: <048.edd7f69f7a5b941b0de63f0fc704909f@haskell.org> References: <048.edd7f69f7a5b941b0de63f0fc704909f@haskell.org> Message-ID: <063.f589d949fb1d110f671fe8c7647d81fb@haskell.org> #9184: Allow the use of Python 3 when building GHC -------------------------------------+------------------------------------- Reporter: aspidites | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: Build System | Version: 7.8.2 Resolution: fixed | Keywords: python Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D310 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"7214e924ca690946288ccf681ef652cee3cb114c/ghc" 7214e92/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7214e924ca690946288ccf681ef652cee3cb114c" testsuite: Remove Unicode literals from driver They are not supported by Python 3.0, 3.1, and 3.2 (but are supported by >= 3.3; silliness!) Test Plan: Validate on python 3.2 Reviewers: austin Subscribers: simonpj, thomie Differential Revision: https://phabricator.haskell.org/D2778 GHC Trac Issues: #12909, #9184 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 1 18:27:37 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Dec 2016 18:27:37 -0000 Subject: [GHC] #12909: Python 3.2 doesn't support Unicode literal syntax In-Reply-To: <046.12ac4bd460b63f64fb7ac16b0d1a0441@haskell.org> References: <046.12ac4bd460b63f64fb7ac16b0d1a0441@haskell.org> Message-ID: <061.e37d388f7633cdf4b820954a1216b361@haskell.org> #12909: Python 3.2 doesn't support Unicode literal syntax -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9184 | Differential Rev(s): Phab:D2778 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"7214e924ca690946288ccf681ef652cee3cb114c/ghc" 7214e92/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7214e924ca690946288ccf681ef652cee3cb114c" testsuite: Remove Unicode literals from driver They are not supported by Python 3.0, 3.1, and 3.2 (but are supported by >= 3.3; silliness!) Test Plan: Validate on python 3.2 Reviewers: austin Subscribers: simonpj, thomie Differential Revision: https://phabricator.haskell.org/D2778 GHC Trac Issues: #12909, #9184 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 1 18:27:37 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Dec 2016 18:27:37 -0000 Subject: [GHC] #12865: POSIX osDecommitMemory has nasty compatibility problems In-Reply-To: <046.4ae668e01490d7d770171a5fd8c666d2@haskell.org> References: <046.4ae668e01490d7d770171a5fd8c666d2@haskell.org> Message-ID: <061.6bde0c45ec018b120edd4e0dfca267d8@haskell.org> #12865: POSIX osDecommitMemory has nasty compatibility problems -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: patch Priority: high | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2780 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"6576bf83cdf4eac05eb88a24aa934a736c91e3da/ghc" 6576bf83/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6576bf83cdf4eac05eb88a24aa934a736c91e3da" rts: Ensure we always give MADV_DONTNEED a chance in osDecommitMemory As described in #12865, newer Linux kernels support both MADV_FREE and MADV_DONTNEED. Previously a runtime would fail to try MADV_DONTNEED if MADV_FREE failed (e.g. since the kernel which the image is running on doesn't support the latter). Now we try MADV_DONTNEED if MADV_FREE failed to ensure that binaries compiled on a kernel supporting MADV_FREE don't fail on decommit. Test Plan: Validate Reviewers: austin, erikd, simonmar Reviewed By: simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2780 GHC Trac Issues: #12865 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 1 18:28:54 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Dec 2016 18:28:54 -0000 Subject: [GHC] #12865: POSIX osDecommitMemory has nasty compatibility problems In-Reply-To: <046.4ae668e01490d7d770171a5fd8c666d2@haskell.org> References: <046.4ae668e01490d7d770171a5fd8c666d2@haskell.org> Message-ID: <061.a82054e199c42f75fde2e21e0cec3cab@haskell.org> #12865: POSIX osDecommitMemory has nasty compatibility problems -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2780 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 1 18:33:06 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Dec 2016 18:33:06 -0000 Subject: [GHC] #12909: Python 3.2 doesn't support Unicode literal syntax In-Reply-To: <046.12ac4bd460b63f64fb7ac16b0d1a0441@haskell.org> References: <046.12ac4bd460b63f64fb7ac16b0d1a0441@haskell.org> Message-ID: <061.ec070f67a8b58f4291e091fa2bf273b4@haskell.org> #12909: Python 3.2 doesn't support Unicode literal syntax -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Test Suite | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9184 | Differential Rev(s): Phab:D2778 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 1 18:34:25 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Dec 2016 18:34:25 -0000 Subject: [GHC] #12901: Levity polymorphic expressions mustn't be floated out In-Reply-To: <045.824b9429e978b9ce967c7d331fdd0c97@haskell.org> References: <045.824b9429e978b9ce967c7d331fdd0c97@haskell.org> Message-ID: <060.0984ee150071e61e5318a2a2bf01f9d9@haskell.org> #12901: Levity polymorphic expressions mustn't be floated out -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: hsyl20 Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2769 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 1 19:02:41 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Dec 2016 19:02:41 -0000 Subject: [GHC] #11445: Turn on SplitSections by default In-Reply-To: <045.848c295688fc284737f19db2f979eda9@haskell.org> References: <045.848c295688fc284737f19db2f979eda9@haskell.org> Message-ID: <060.4f9a593e2ec9205da70d7c3d3a8c5f74@haskell.org> #11445: Turn on SplitSections by default -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Build System | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 11285 Related Tickets: | Differential Rev(s): Phab:D1800 Wiki Page: | -------------------------------------+------------------------------------- Comment (by awson): If somebody wants to enjoy the benefits of `-split-sections` vs `-split- objs` (they are tremendous) '''immediately''', she has the following options: 1. I could try to put linker script patches to upstream `binutils`. Honestly, I don't want to bother with this ATM; 2. I could publish these patches for those interested to build their own `binutils`; 3. I could publish linker scripts which could be used with existing `binutils`. Since all options require (at least) to modify any existing build scripts, I believe that, perhaps, the option 3 might be the most welcomed one. OTOH, options 2 and 3 require more involvement than the first one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 1 19:20:32 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Dec 2016 19:20:32 -0000 Subject: [GHC] #12905: Core lint failure with pattern synonym and levity polymorphism In-Reply-To: <046.5ce6798de5363e50c2fbb8c2a8dbf24c@haskell.org> References: <046.5ce6798de5363e50c2fbb8c2a8dbf24c@haskell.org> Message-ID: <061.983815ff4d59e9b0c822d43e8b360a0a@haskell.org> #12905: Core lint failure with pattern synonym and levity polymorphism -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: | LevityPolymorphism, typeable Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * keywords: levity-polymorphic, typeable => LevityPolymorphism, typeable -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 1 22:12:03 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Dec 2016 22:12:03 -0000 Subject: [GHC] #11744: Latest Xcode update violates POSIX compliance of `nm -P` In-Reply-To: <042.af01bf0c9281d3187ce47b8cda7a587e@haskell.org> References: <042.af01bf0c9281d3187ce47b8cda7a587e@haskell.org> Message-ID: <057.0cc6f7e8110c03fda59f3186eca1d369@haskell.org> #11744: Latest Xcode update violates POSIX compliance of `nm -P` ---------------------------------+-------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Build System | Version: Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D2113 Wiki Page: | ---------------------------------+-------------------------------------- Comment (by goldfire): Ping. I'm still saying `--with-nm=nm-classic` (for the `nm-classic` I have in my PATH) whenever I need to build GHC. Is this still the recommended action? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 1 22:14:13 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Dec 2016 22:14:13 -0000 Subject: [GHC] #10812: High memory usage after performing GC In-Reply-To: <046.80aa46a375cd3a278869ea812244030d@haskell.org> References: <046.80aa46a375cd3a278869ea812244030d@haskell.org> Message-ID: <061.325a065445c71951385c123897019ce9@haskell.org> #10812: High memory usage after performing GC ---------------------------------+-------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Changes (by bgamari): * cc: simonmar (added) Comment: > I've tried running performGC manually (please look again in my code - I've tried all the versions commented out above). Ahh, sorry for the misunderstanding. > So I've got 2 questions: 1) Maybe it is Mac OS X related bug? Given Kazu's observation I guess we can rule this out. > 2) You've told me that GC is performed only when memory is allocated, so when we are performing MapM ten million times, allocating each time a small chunk of memory (and returning weak pointers only), shouldn't the GC be called at last several times then? Ahh, yes, you are right; the `mapM` does need to build its result and will therefore allocate and therefore garbage collect. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 1 22:14:18 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Dec 2016 22:14:18 -0000 Subject: [GHC] #12905: Core lint failure with pattern synonym and levity polymorphism In-Reply-To: <046.5ce6798de5363e50c2fbb8c2a8dbf24c@haskell.org> References: <046.5ce6798de5363e50c2fbb8c2a8dbf24c@haskell.org> Message-ID: <061.8e8542b1377ea93f0d3cf6bdcfcc7953@haskell.org> #12905: Core lint failure with pattern synonym and levity polymorphism -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: | LevityPolymorphism, typeable Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Looks like #11714 to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 1 22:18:41 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Dec 2016 22:18:41 -0000 Subject: [GHC] #8848: Warning: Rule too complicated to desugar In-Reply-To: <045.a581fc912ad3317ed38c8bc8b996fea5@haskell.org> References: <045.a581fc912ad3317ed38c8bc8b996fea5@haskell.org> Message-ID: <060.eeea72310d4f9b0c1d76c9a89f404c1f@haskell.org> #8848: Warning: Rule too complicated to desugar -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | simplCore/should_compile/T8848, | T8848a Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nfrisby): Replying to [comment:12 yongqli]: > It is possible that > > > {{{ > {-# RULE map2 = map2_spec #-} > map2_spec :: (a->b->c)-> (Shape Z a )-> Shape Z b -> Shape Z c > map2_spec = inline map2 > }}} > > creates an infinite loop, because we end up with > > > {{{ > map2_spec = inline map2_spec > }}} > ? I noticed this happening with GHC 7.10.2. The RULE must not be in- scope/active during the definition of {{{map2_spec}}} (e.g. put it in a downstream module.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 1 22:21:17 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Dec 2016 22:21:17 -0000 Subject: [GHC] #11744: Latest Xcode update violates POSIX compliance of `nm -P` In-Reply-To: <042.af01bf0c9281d3187ce47b8cda7a587e@haskell.org> References: <042.af01bf0c9281d3187ce47b8cda7a587e@haskell.org> Message-ID: <057.a9e853da6a98de67a38c7ff01f490381@haskell.org> #11744: Latest Xcode update violates POSIX compliance of `nm -P` ---------------------------------+-------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Build System | Version: Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D2113 Wiki Page: | ---------------------------------+-------------------------------------- Comment (by bgamari): It actually appears that the latest XCode release (8.1) fixes this. It shouldn't be necessary to use `nm-classic` with, {{{ $ nm --version Apple LLVM version 8.0.0 (clang-800.0.38) Optimized build. Default target: x86_64-apple-darwin16.0.0 Host CPU: haswell }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 1 22:21:21 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Dec 2016 22:21:21 -0000 Subject: [GHC] #12911: Levity polymorphism check eliminates non-levity-polymorphic data constructor Message-ID: <047.553556d51b1a72154ff5eadb4d1146d2@haskell.org> #12911: Levity polymorphism check eliminates non-levity-polymorphic data constructor -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple LevityPolymorphism | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When I say {{{ data X where MkX :: forall (a :: TYPE r). (a -> a) -> X }}} I get {{{ • A representation-polymorphic type is not allowed here: Type: a Kind: TYPE r • In the definition of data constructor ‘MkX’ In the data type declaration for ‘X’ }}} But that's silly, because the type is not levity-polymorphic! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 1 22:23:35 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Dec 2016 22:23:35 -0000 Subject: [GHC] #11744: Latest Xcode update violates POSIX compliance of `nm -P` In-Reply-To: <042.af01bf0c9281d3187ce47b8cda7a587e@haskell.org> References: <042.af01bf0c9281d3187ce47b8cda7a587e@haskell.org> Message-ID: <057.7cd1deaa490950599baa0362a04c96ce@haskell.org> #11744: Latest Xcode update violates POSIX compliance of `nm -P` ---------------------------------+-------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Build System | Version: Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D2113 Wiki Page: | ---------------------------------+-------------------------------------- Comment (by goldfire): So should this ticket be closed then? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 1 22:27:53 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Dec 2016 22:27:53 -0000 Subject: [GHC] #12668: Program that fails Core Lint terribly In-Reply-To: <046.2f894b8049432c51a49de6a9cf9f1a5f@haskell.org> References: <046.2f894b8049432c51a49de6a9cf9f1a5f@haskell.org> Message-ID: <061.4404e00721f4b9bc15496e512d3a8332@haskell.org> #12668: Program that fails Core Lint terribly -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Keywords: Resolution: fixed | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | polykinds/T12668 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: => LevityPolymorphism -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 1 22:29:47 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Dec 2016 22:29:47 -0000 Subject: [GHC] #11431: GHC instantiates levity-polymorphic type variables with foralls In-Reply-To: <049.c965ae8386af9b35d3189b14dffe6d6e@haskell.org> References: <049.c965ae8386af9b35d3189b14dffe6d6e@haskell.org> Message-ID: <064.735818e255121e879887c383eaefe9d7@haskell.org> #11431: GHC instantiates levity-polymorphic type variables with foralls -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | TypeApplications, | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: TypeApplications => TypeApplications, LevityPolymorphism -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 1 22:30:13 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Dec 2016 22:30:13 -0000 Subject: [GHC] #11724: Must check for representation polymorphism in datatype declarations In-Reply-To: <047.e984e50f4246346ca88e79b8cc73fa2e@haskell.org> References: <047.e984e50f4246346ca88e79b8cc73fa2e@haskell.org> Message-ID: <062.456f542e91c62342b50bc300837efa39@haskell.org> #11724: Must check for representation polymorphism in datatype declarations -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | typecheck/should_fail/T11724 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: => LevityPolymorphism -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 1 22:30:50 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Dec 2016 22:30:50 -0000 Subject: [GHC] #11714: Kind of (->) type constructor is overly constrained In-Reply-To: <046.1c872034bd46f91c4f4aa91d607a8219@haskell.org> References: <046.1c872034bd46f91c4f4aa91d607a8219@haskell.org> Message-ID: <061.aaf02d7ceaa190b2bfa6f0007a110cd0@haskell.org> #11714: Kind of (->) type constructor is overly constrained -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Typeable, | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: Typeable => Typeable, LevityPolymorphism -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 1 22:42:41 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Dec 2016 22:42:41 -0000 Subject: [GHC] #11744: Latest Xcode update violates POSIX compliance of `nm -P` In-Reply-To: <042.af01bf0c9281d3187ce47b8cda7a587e@haskell.org> References: <042.af01bf0c9281d3187ce47b8cda7a587e@haskell.org> Message-ID: <057.299f57089a6141d5b05edb15dcee12ff@haskell.org> #11744: Latest Xcode update violates POSIX compliance of `nm -P` ---------------------------------+-------------------------------------- Reporter: hvr | Owner: Type: bug | Status: closed Priority: highest | Milestone: Component: Build System | Version: Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D2113 Wiki Page: | ---------------------------------+-------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: Why yes, I suppose it should be. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 1 22:43:16 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Dec 2016 22:43:16 -0000 Subject: [GHC] #11714: Kind of (->) type constructor is overly constrained In-Reply-To: <046.1c872034bd46f91c4f4aa91d607a8219@haskell.org> References: <046.1c872034bd46f91c4f4aa91d607a8219@haskell.org> Message-ID: <061.b8dce8a9c322695aba4d2af35d4c7790@haskell.org> #11714: Kind of (->) type constructor is overly constrained -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Typeable, | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I think that in the paper, and verbally, we've converged on simply generalising the kind of `(->)`, as described in the Description. Shall we just do that? Richard? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 1 22:47:07 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Dec 2016 22:47:07 -0000 Subject: [GHC] #10445: Wrong stack space size when using -Ksize In-Reply-To: <042.794c5bde83bb1d57f2fc1adc9766262f@haskell.org> References: <042.794c5bde83bb1d57f2fc1adc9766262f@haskell.org> Message-ID: <057.6cb7870cb281e78a02fc351431a0b7ef@haskell.org> #10445: Wrong stack space size when using -Ksize -------------------------------------+------------------------------------- Reporter: asr | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D938, Wiki Page: | Phab:D961 -------------------------------------+------------------------------------- Changes (by rwbarton): * owner: archblob => * status: closed => new * resolution: fixed => Comment: As far as I can tell, this was never actually fixed. It is still broken in both 8.0.1 and in HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 1 23:25:18 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Dec 2016 23:25:18 -0000 Subject: [GHC] #12425: With -O1 and above causes ghc to use all available memory before being killed by OOM killer In-Reply-To: <044.8db07ee1e56d0d370ac594dbce3dff94@haskell.org> References: <044.8db07ee1e56d0d370ac594dbce3dff94@haskell.org> Message-ID: <059.91b5812a80f36ab27f93b6e3cbc60c63@haskell.org> #12425: With -O1 and above causes ghc to use all available memory before being killed by OOM killer -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.3 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Thomie, THANK YOU for the small repro case in comment:3. With its help I rapidly nailed the bug. Here's what is happening. Suppose we have {{{ let rec { f = ...g...g... ; g = ...f...f... } in case x of True -> ...f.. False -> ..f... }}} In each iteration of the simplifier the occurrence analyser `OccAnal` chooses a loop breaker. Suppose in iteration 1 it choose `g` as the loop breaker. That means it is free to inline `f`. Suppose that GHC decides to inline `f` in the branches of the `case`, but (for some reason; eg it is not satureated) in the rhs of `g`. So we get {{{ let rec { f = ...g...g... ; g = ...f...f... } in case x of True -> ...g...g..... False -> ..g..g.... }}} Now suppose that, for some reason, in the next iteraion the occurrence analyser chooses `f` as the loop breaker, so it can freely inling `g`. And again for some reason the simplifer inlines `g` at its calls in the `case` branches, but not in the RHS of `f`. Then we get {{{ let rec { f = ...g...g... ; g = ...f...f... } in case x of True -> ...(...f...f...)...(...f..f..)..... False -> ..(...f...f...)...(..f..f...).... }}} You can see where this is going! Each iteration of the simplifier doubles the number of calls to `f` or `g`. No wonder GHC is slow! (In the particular example in comment:3, `f` and `g` are the two mutually recursive `fmap` instances for `CondT` and `Result`. They are both marked INLINE which, oddly, is why they don't inline in each other's RHS, because the call there is not saturated.) The root cause is that we flip-flop on our choice of loop breaker. I always thought it didn't matter, and indeed for any single iteration to terminate, it doesn't matter. But when we iterate, it matters a lot!! I think this was not happening before because, by a fluke, we tended to always choose the same one. But, perhaps as a resul of Bartosz's work on making GHC deterministic, the occurrence analyser now reliably flip-flops in each iteration, as above. Trac #12234 turns out to be ''exactly'' the same issue ------------------- What to do? We want the occurrence analyser to choose a loop breaker based on stable criteria, not arbitrary things. Simple idea: if two or more potential loop breakers look equally plausible, ''choose the one that was a loop breaker in the previous iteration''. That should make it stable. Stay tuned. But I thought I'd explain what is happening in case I get distracted. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 2 00:03:20 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Dec 2016 00:03:20 -0000 Subject: [GHC] #8809: Prettier error messages? In-Reply-To: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> References: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> Message-ID: <062.66ce635f7ee87b540c7b1f2e2c9a6fb1@haskell.org> #8809: Prettier error messages? -------------------------------------+------------------------------------- Reporter: joelteon | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): #8809,#10073,#10179 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by dobenour): I don't guess that the ''extremely'' hackish approach of using `unsafeInterleaveIO` would work here? The IO action (reading from a file) clearly need not be performed if its result is not used, and we can force it to happen by using `deepSeq` at the appropriate point (to make sure the `SDoc` is fully evaluated). That would avoid needing the `SDoc` to contain an `IO` action at the expense of using unsafe code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 2 00:04:59 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Dec 2016 00:04:59 -0000 Subject: [GHC] #11445: Turn on SplitSections by default In-Reply-To: <045.848c295688fc284737f19db2f979eda9@haskell.org> References: <045.848c295688fc284737f19db2f979eda9@haskell.org> Message-ID: <060.30b699ab35a020373436ed32a44a193a@haskell.org> #11445: Turn on SplitSections by default -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Build System | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 11285 Related Tickets: | Differential Rev(s): Phab:D1800 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dobenour): awson: could GHC have the new linker script embedded into it, so that GHC can use it automatically? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 2 00:05:32 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Dec 2016 00:05:32 -0000 Subject: [GHC] #11445: Turn on SplitSections by default In-Reply-To: <045.848c295688fc284737f19db2f979eda9@haskell.org> References: <045.848c295688fc284737f19db2f979eda9@haskell.org> Message-ID: <060.e113eba1937ef62958fc2253d82333d1@haskell.org> #11445: Turn on SplitSections by default -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Build System | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 11285 Related Tickets: | Differential Rev(s): Phab:D1800 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dobenour): * cc: awson (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 2 00:09:26 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Dec 2016 00:09:26 -0000 Subject: [GHC] #11238: Redesign the dynamic linking on ELF systems In-Reply-To: <047.b64204058d590ba33e44f36f6140b2e6@haskell.org> References: <047.b64204058d590ba33e44f36f6140b2e6@haskell.org> Message-ID: <062.3b0a9439bad62297784f25a1bf708548@haskell.org> #11238: Redesign the dynamic linking on ELF systems -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 7.10.3 (Linker) | Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: 9237, 9498, | 11042, 11499, 12684 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dobenour): * cc: dobenour (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 2 00:09:59 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Dec 2016 00:09:59 -0000 Subject: [GHC] #11238: Redesign the dynamic linking on ELF systems In-Reply-To: <047.b64204058d590ba33e44f36f6140b2e6@haskell.org> References: <047.b64204058d590ba33e44f36f6140b2e6@haskell.org> Message-ID: <062.3b27d6a2d6a0b10715b024d1d4aec897@haskell.org> #11238: Redesign the dynamic linking on ELF systems -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 7.10.3 (Linker) | Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: 9237, 9498, | 11042, 11499, 12684 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dobenour): Any progress made? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 2 00:12:47 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Dec 2016 00:12:47 -0000 Subject: [GHC] #12735: Evaluate the feasibility of using lld for linking In-Reply-To: <046.512cf8539c4832daf355de78db41faba@haskell.org> References: <046.512cf8539c4832daf355de78db41faba@haskell.org> Message-ID: <061.54fc68f2a4dd16345cd8725c092c4e4d@haskell.org> #12735: Evaluate the feasibility of using lld for linking -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dobenour): I would like to investigate a different approach: split the RTS linker as a C library that can be used by other projects, and which exposes a C API. GHC would then depend on this library. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 2 00:17:15 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Dec 2016 00:17:15 -0000 Subject: [GHC] #10352: Properly link Haskell shared libs on all systems In-Reply-To: <045.f54c0b53e462b1ea305eb5f3c38d7688@haskell.org> References: <045.f54c0b53e462b1ea305eb5f3c38d7688@haskell.org> Message-ID: <060.08b6571224783b31dda4c219616d8c9c@haskell.org> #10352: Properly link Haskell shared libs on all systems -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.11 (Linking) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 5987 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dobenour): Is there a way to pipe the information to where it needs to be? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 2 00:26:49 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Dec 2016 00:26:49 -0000 Subject: [GHC] #11777: RTS source code issues In-Reply-To: <046.3e69faecf0e4f69a5fcc7ec246409435@haskell.org> References: <046.3e69faecf0e4f69a5fcc7ec246409435@haskell.org> Message-ID: <061.e11081255e78b2d5ed58a5861ea2e58e@haskell.org> #11777: RTS source code issues -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dobenour): erikd: any progress? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 2 00:50:05 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Dec 2016 00:50:05 -0000 Subject: [GHC] #11445: Turn on SplitSections by default In-Reply-To: <045.848c295688fc284737f19db2f979eda9@haskell.org> References: <045.848c295688fc284737f19db2f979eda9@haskell.org> Message-ID: <060.55a19db7724f61cff0a4e14bc849ac31@haskell.org> #11445: Turn on SplitSections by default -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Build System | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 11285 Related Tickets: | Differential Rev(s): Phab:D1800 Wiki Page: | -------------------------------------+------------------------------------- Comment (by refold): @awson Please do whatever is easiest for you. If you don't want to bother with integrating your patches into upstream `binutils`, maybe someone else is, so please at least open source them. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 2 03:07:00 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Dec 2016 03:07:00 -0000 Subject: [GHC] #11777: RTS source code issues In-Reply-To: <046.3e69faecf0e4f69a5fcc7ec246409435@haskell.org> References: <046.3e69faecf0e4f69a5fcc7ec246409435@haskell.org> Message-ID: <061.12b4ae5cbe314df6a07d4a303639bd9d@haskell.org> #11777: RTS source code issues -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by erikd): I've been really busy with a new job the last 6 months, so no progress by me personally on this issue. However there are at least 3 or 4 others currently working on cleaning up the RTS and they do seem t be making definite progress. There have been dozens of commits to the `rts/` part of the tree in the last 6 months and only a small number of them were for new features. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 2 03:47:36 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Dec 2016 03:47:36 -0000 Subject: [GHC] #12735: Evaluate the feasibility of using lld for linking In-Reply-To: <046.512cf8539c4832daf355de78db41faba@haskell.org> References: <046.512cf8539c4832daf355de78db41faba@haskell.org> Message-ID: <061.ae5745eb9363600b5297733b31902855@haskell.org> #12735: Evaluate the feasibility of using lld for linking -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Replying to [comment:2 dobenour]: > I would like to investigate a different approach: split the RTS linker as a C library that can be used by other projects, and which exposes a C API. GHC would then depend on this library. I actually had a look at the `lld` codebase a few weeks ago and my initial impressions were that it isn't terribly well-suited to be used as a runtime linker. I offers a lot of parsing and relocation logic, but it lacks any support for managing mappings and the like. Consequently, I think the option that you suggest (which erikd has also advocated for in the past) is the only way forward. I would love to see it happen, but it will take some time. Currently our runtime linker is sorely in need of tests; this makes any sort of large-scale refactoring quite risky. `lld`'s testsuite may be a good source of inspiration (and perhaps even tests!) for fixing this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 2 04:01:06 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Dec 2016 04:01:06 -0000 Subject: [GHC] #12909: Python 3.2 doesn't support Unicode literal syntax In-Reply-To: <046.12ac4bd460b63f64fb7ac16b0d1a0441@haskell.org> References: <046.12ac4bd460b63f64fb7ac16b0d1a0441@haskell.org> Message-ID: <061.77ef05adc683f7292a0c6b4a9b7ada02@haskell.org> #12909: Python 3.2 doesn't support Unicode literal syntax -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Test Suite | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9184 | Differential Rev(s): Phab:D2778 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"ddc271e8ed6c5ec5e83dd50c6c5e77955a0e90ac/ghc" ddc271e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ddc271e8ed6c5ec5e83dd50c6c5e77955a0e90ac" Travis: Add dependency on python3 The testsuite now requires python >=3.0. See #12909. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 2 06:06:16 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Dec 2016 06:06:16 -0000 Subject: [GHC] #8809: Prettier error messages? In-Reply-To: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> References: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> Message-ID: <062.7ba0e501e2ee65fd08a4cd559dff2ea9@haskell.org> #8809: Prettier error messages? -------------------------------------+------------------------------------- Reporter: joelteon | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): #8809,#10073,#10179 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Rufflewind): Replying to [comment:38 dobenour]: > I don't guess that the ''extremely'' hackish approach of using `unsafeInterleaveIO` would work here? The IO action (reading from a file) clearly need not be performed if its result is not used, and we can force it to happen by using `deepSeq` at the appropriate point (to make sure the `SDoc` is fully evaluated). > > That would avoid needing the `SDoc` to contain an `IO` action at the expense of using unsafe code. I found a cleaner workaround for the problem, so IO actions in SDocs are no longer necessary. https://phabricator.haskell.org/D2718 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 2 10:08:52 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Dec 2016 10:08:52 -0000 Subject: [GHC] #11238: Redesign the dynamic linking on ELF systems In-Reply-To: <047.b64204058d590ba33e44f36f6140b2e6@haskell.org> References: <047.b64204058d590ba33e44f36f6140b2e6@haskell.org> Message-ID: <062.a5bf7448b9ce554bd94a6be04dd4185f@haskell.org> #11238: Redesign the dynamic linking on ELF systems -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 7.10.3 (Linker) | Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: 9237, 9498, | 11042, 11499, 12684 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by trommler): I have an implementation of the ideas laid out in [wiki:LinkingHaskell] that can be found at https://github.com/trommler/ghc/tree/T11238. Currently I am investigating a regression in test `ghci015`. I have not done any work on regression tests. At least for the tickets blocked by this ticket regression tests should be added. Regarding OS X support: I started out my implementation for both ELF and OS X and gave up eventually. I could not get overriding a symbol with a new definition to work with the OS X link editor. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 2 10:36:39 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Dec 2016 10:36:39 -0000 Subject: [GHC] #12912: IO library should not use select() Message-ID: <047.2c26cf965e8c4185b06cc1a4540c3c04@haskell.org> #12912: IO library should not use select() -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: | Version: 8.0.1 libraries/base | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The IO library uses `select()` in `fdReady()`, which fails in processes with more than 1024 file descriptors. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 2 10:50:31 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Dec 2016 10:50:31 -0000 Subject: [GHC] #11445: Turn on SplitSections by default In-Reply-To: <045.848c295688fc284737f19db2f979eda9@haskell.org> References: <045.848c295688fc284737f19db2f979eda9@haskell.org> Message-ID: <060.07b74d43cca7e30afcbef5a00b40038d@haskell.org> #11445: Turn on SplitSections by default -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Build System | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 11285 Related Tickets: | Differential Rev(s): Phab:D1800 Wiki Page: | -------------------------------------+------------------------------------- Comment (by awson): Well, I've updated [https://sourceware.org/bugzilla/show_bug.cgi?id=19254 relevant binutils ticket] with patches solving the problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 2 10:52:48 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Dec 2016 10:52:48 -0000 Subject: [GHC] #12495: GHC's configure script detects MADV_FREE when it shouldn't In-Reply-To: <044.997e9b75dfddfee0f98aa3aabfdabed9@haskell.org> References: <044.997e9b75dfddfee0f98aa3aabfdabed9@haskell.org> Message-ID: <059.49f90587ce2c6a2cfe27af6e3275582a@haskell.org> #12495: GHC's configure script detects MADV_FREE when it shouldn't -------------------------------------+------------------------------------- Reporter: orion | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 8.0.1 Resolution: duplicate | Keywords: MADV_FREE Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #12865 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by trommler): * status: patch => closed * resolution: => duplicate * related: => #12865 Comment: This is a duplicate of #12865. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 2 10:54:26 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Dec 2016 10:54:26 -0000 Subject: [GHC] #11445: Turn on SplitSections by default In-Reply-To: <045.848c295688fc284737f19db2f979eda9@haskell.org> References: <045.848c295688fc284737f19db2f979eda9@haskell.org> Message-ID: <060.e0a9d3ee44019b6eedce37d368d01314@haskell.org> #11445: Turn on SplitSections by default -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Build System | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 11285 Related Tickets: | Differential Rev(s): Phab:D1800 Wiki Page: | -------------------------------------+------------------------------------- Changes (by awson): * Attachment "scripts.tar.gz" added. Linker scripts for section merging on Windows -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 2 11:12:48 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Dec 2016 11:12:48 -0000 Subject: [GHC] #11445: Turn on SplitSections by default In-Reply-To: <045.848c295688fc284737f19db2f979eda9@haskell.org> References: <045.848c295688fc284737f19db2f979eda9@haskell.org> Message-ID: <060.96a68c5ca8f6adcc9713ad1e826e57cf@haskell.org> #11445: Turn on SplitSections by default -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Build System | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 11285 Related Tickets: | Differential Rev(s): Phab:D1800 Wiki Page: | -------------------------------------+------------------------------------- Comment (by awson): Scripts attached do section merging on Windows. Caveat: As far as I remember, when I worked on this (almost year ago) `cabal` (or was it GHC?) didn't respect linker flags when building library's prelinked object file (for GHCi). I may be wrong or `cabal` may be changed since that time, but if you will try to use attached linker scripts with existing binutils, please make sure `ld` receives the option, feeding the linker script to it. If this problem is still there, please ask `cabal` (or GHC?) maintainers to fix it. Also it may be a problem that we need use different linker scripts for different scenarios: "x" for building executables/dlls and "xr" for building prelinked object files. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 2 11:52:26 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Dec 2016 11:52:26 -0000 Subject: [GHC] #11445: Turn on SplitSections by default In-Reply-To: <045.848c295688fc284737f19db2f979eda9@haskell.org> References: <045.848c295688fc284737f19db2f979eda9@haskell.org> Message-ID: <060.a4a9678027a4c76a52f18fa9d2ef05c0@haskell.org> #11445: Turn on SplitSections by default -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Build System | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 11285 Related Tickets: | Differential Rev(s): Phab:D1800 Wiki Page: | -------------------------------------+------------------------------------- Comment (by awson): The summary (for Windows): 1. I always used patched binutils and never used separate linker scripts, thus can't comment on potential problems with the latter. 2. On 64-bit GHC I don't use `-split-objs` at all and use `-split- sections` exclusively for almost a year and I never had any problems with this. The only '''important''' thing one should remember is that we sometimes need to supply `-opta-Wa,-mbig-obj` to GHC to make it build correct object files (I know 2 package which require this: `template- haskell` when building GHC itself and `haskell-src-exts`). One possible option is to always use this flag if `-split-sections` is used. 3. `-split-sections` doesn't introduce any noticeable overhead when compiling and thus is '''dramatically''' faster than `-split-objs` when building packages, it is slightly slower when linking final executables though. 4. 64-bit GHC itself can be built in release configuration with `-split- objs` replaced by `-split-sections` absolutely with no problems (only `-opta-Wa,-mbig-obj` should be added to `ghc-options` in `template- haskell` cabal file). 32-bit GHC building process is less smooth and requires a special handling of `template-haskell` package (one needs to recompile `Language.Haskell.TH.Syntax` module in profiling configuration with `-split-objs`). Overall, building release GHC itself with `-split- sections` is '''much''' faster than with `-split-objs`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 2 12:40:22 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Dec 2016 12:40:22 -0000 Subject: [GHC] #11445: Turn on SplitSections by default In-Reply-To: <045.848c295688fc284737f19db2f979eda9@haskell.org> References: <045.848c295688fc284737f19db2f979eda9@haskell.org> Message-ID: <060.4795f2b4cc3c721bc2900feecff3d3be@haskell.org> #11445: Turn on SplitSections by default -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Build System | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 11285 Related Tickets: | Differential Rev(s): Phab:D1800 Wiki Page: | -------------------------------------+------------------------------------- Comment (by olsner): I assumed the linker problem and the required fix would be much more complicated, but after reading the patches it looks like it could simply be an issue with how we name sections on Windows builds? (See also https://sourceware.org/bugzilla/show_bug.cgi?id=19254#c3) That means maybe we "only" need: * unpatched binutils (but a new enough version) * `-Wa,-mbig-objs` for the assembler * fixed section names * a PE-compatible linker script for `ld -r` section merging -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 2 13:01:18 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Dec 2016 13:01:18 -0000 Subject: [GHC] #11445: Turn on SplitSections by default In-Reply-To: <045.848c295688fc284737f19db2f979eda9@haskell.org> References: <045.848c295688fc284737f19db2f979eda9@haskell.org> Message-ID: <060.4c4f91995a77cef82f5b4b0bb877a46b@haskell.org> #11445: Turn on SplitSections by default -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Build System | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 11285 Related Tickets: | Differential Rev(s): Phab:D1800 Wiki Page: | -------------------------------------+------------------------------------- Comment (by awson): I looks current binutils' linker scripts doesn't handle `rodata` sections at all, thus I believe we should patch binutils anyway. Regarding section namespace separator, indeed `gcc` on Windows generates `$` instead of `.`, and this, perhaps, would be correct to make GHC do the same thing, but even unpatched Windows bintuils have separate handling of `.text.*` sections for example. I suspect that this is because there exist another tools from GNU/Unix land, ported to Windows which also use `.` for section hierarchy handling. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 2 13:40:11 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Dec 2016 13:40:11 -0000 Subject: [GHC] #4471: Incorrect Unicode output on Windows Console In-Reply-To: <046.0459baeecbdbac5352442349bd351ed0@haskell.org> References: <046.0459baeecbdbac5352442349bd351ed0@haskell.org> Message-ID: <061.ef7d7c66aae3570ba28c85546ce2fd2d@haskell.org> #4471: Incorrect Unicode output on Windows Console -------------------------------------+------------------------------------- Reporter: sankeld | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 6.12.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Incorrect result | Test Case: at runtime | Blocked By: | Blocking: Related Tickets: #11394 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by jmn): * cc: setre3+ghc@… (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 2 14:06:30 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Dec 2016 14:06:30 -0000 Subject: [GHC] #12915: cmmImplementSwitchPlans creates duplicate blocks Message-ID: <048.450627ba0680e3fafd8b0486acc85c67@haskell.org> #12915: cmmImplementSwitchPlans creates duplicate blocks -------------------------------------+------------------------------------- Reporter: alexbiehl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Given this c-- code *after* common block elimination and *before* cmmImplementSwitchPlans: {{{#!hs ... cfzc: _sfh3::P64 = R1; _cfB7::I64 = %MO_UU_Conv_W32_W64(I32[I64[_sfh3::P64 - 1] - 4]); switch [0 .. 20] _cfB7::I64 { case 2 : goto cfAR; case 4 : goto cfAV; case 6 : goto cfAZ; default: goto cfAC; } cfAZ: _sfh6::I64 = I64[_sfh3::P64 + 7]; _sfgp::I64 = 1; goto sfgo; cfAV: _sfh5::I64 = I64[_sfh3::P64 + 7]; _sfgp::I64 = 1; goto sfgo; cfAR: _sfh4::I64 = I64[_sfh3::P64 + 7]; _sfgp::I64 = 1; goto sfgo; sfgo: ... }}} Everything is fine, the blocks cfAZ, cfAV and cfAR are all a little different. But after cmmImplementSwitchPlans the code becomes: {{{#!hs ... cfzc: _sfgl::I64 = I64[Sp + 24]; _sfgn::P64 = P64[Sp + 16]; _cfB7::I64 = %MO_UU_Conv_W32_W64(I32[I64[R1 - 1] - 4]); if (_cfB7::I64 < 5) goto ufBe; else goto ufBg; ufBe: if (_cfB7::I64 < 4) goto ufBf; else goto cfAV; ufBf: if (_cfB7::I64 != 2) goto cfAC; else goto cfAR; cfAR: _sfgp::I64 = 1; goto sfgo; cfAV: _sfgp::I64 = 1; goto sfgo; ufBg: if (_cfB7::I64 != 6) goto cfAC; else goto cfAZ; cfAZ: _sfgp::I64 = 1; goto sfgo; sfgo: ... }}} We can now see that cfAZ, cfAV and cfAR are code duplicates! Now, https://github.com/ghc/ghc/blob/master/compiler/cmm/CmmPipeline.hs#L72 states {{{ ... ----------- Eliminate common blocks ------------------------------------- g <- {-# SCC "elimCommonBlocks" #-} condPass Opt_CmmElimCommonBlocks elimCommonBlocks g Opt_D_dump_cmm_cbe "Post common block elimination" -- Any work storing block Labels must be performed _after_ -- elimCommonBlocks g <- {-# SCC "createSwitchPlans" #-} runUniqSM $ cmmImplementSwitchPlans dflags g dump Opt_D_dump_cmm_switch "Post switch plan" g ... }}} For some reason I don't understand cmmImplementSwitchPlans is run *after* elimCommonBlocks. Although it seems elimCommonBlocks can deal with the constructs introduced in cmmImplementSwitchPlans. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 2 14:16:48 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Dec 2016 14:16:48 -0000 Subject: [GHC] #12916: GHC 8.0.1 vs GHC HEAD (8.1.20161202) doesn't do inlining and unboxing very well Message-ID: <048.78c7dbc5b6c2354f4f01a2e0b9be7926@haskell.org> #12916: GHC 8.0.1 vs GHC HEAD (8.1.20161202) doesn't do inlining and unboxing very well -------------------------------------+------------------------------------- Reporter: alexbiehl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Comparing the core output for a small program of mine I found that GHC HEAD produced binary runs 26x slower than with GHC 8.0.1. I have uploaded an example: https://gist.github.com/alexbiehl/0a1b5016223e00ae79a1399176e14eef The following is the output for the empResult function. We can see that GHC 8.0.1 nicely unboxed the accumulator in the loop. While GHC HEAD uses boxed values all over the place and doesn't even do dictionary inlining. For GHC 8.0.1 it produces: {{{#!hs -- RHS size: {terms: 175, types: 184, coercions: 4} $wempResult :: IO (Maybe (Vector ColValue)) -> State# RealWorld -> (# State# RealWorld, Either Error Int #) $wempResult = \ (ww :: IO (Maybe (Vector ColValue))) (w :: State# RealWorld) -> letrec { $sloop :: State# RealWorld -> Int# -> (# State# RealWorld, Either Error Int #) $sloop = \ (sc :: State# RealWorld) (sc1 :: Int#) -> case (ww `cast` ...) sc of _ { (# ipv, ipv1 #) -> case ipv1 of _ { Nothing -> (# ipv, Right (I# sc1) #); Just a -> case length $fVectorVectora a of _ { I# y -> case y of _ { __DEFAULT -> (# ipv, empResult2 #); 4# -> case a of _ { Vector dt dt1 dt2 -> let { $wsucc_ :: Int# -> State# RealWorld -> (# State# RealWorld, Either Error Int #) $wsucc_ = \ (ww1 :: Int#) (w1 :: State# RealWorld) -> let { $wsucc_1 :: Int# -> State# RealWorld -> (# State# RealWorld, Either Error Int #) $wsucc_1 = \ (ww2 :: Int#) (w2 :: State# RealWorld) -> case indexArray# dt2 (+# dt ww2) of _ { (# ipv2 #) -> case ipv2 of _ { __DEFAULT -> (# w2, empResult2 #); CV_Int8 dt4 -> case indexArray# dt2 (+# dt (+# ww2 1#)) of _ { (# ipv3 #) -> case ipv3 of _ { __DEFAULT -> (# w2, empResult2 #); CV_Text t -> $sloop w2 (+# sc1 1#) } }; CV_Int16 dt4 -> case indexArray# dt2 (+# dt (+# ww2 1#)) of _ { (# ipv3 #) -> case ipv3 of _ { __DEFAULT -> (# w2, empResult2 #); CV_Text t -> $sloop w2 (+# sc1 1#) } }; CV_Int32 dt4 -> case indexArray# dt2 (+# dt (+# ww2 1#)) of _ { (# ipv3 #) -> case ipv3 of _ { __DEFAULT -> (# w2, empResult2 #); CV_Text t -> $sloop w2 (+# sc1 1#) } } } } } in case indexArray# dt2 (+# dt ww1) of _ { (# ipv2 #) -> case ipv2 of _ { __DEFAULT -> (# w1, empResult2 #); CV_Int8 dt4 -> $wsucc_1 (+# ww1 1#) w1; CV_Int16 dt4 -> $wsucc_1 (+# ww1 1#) w1; CV_Int32 dt4 -> $wsucc_1 (+# ww1 1#) w1 } } } in case indexArray# dt2 dt of _ { (# ipv2 #) -> case ipv2 of _ { __DEFAULT -> (# ipv, empResult2 #); CV_Int8 dt4 -> $wsucc_ 1# ipv; CV_Int16 dt4 -> $wsucc_ 1# ipv; CV_Int32 dt4 -> $wsucc_ 1# ipv } } } } } } }; } in $sloop w 0# }}} and for GHC HEAD it produces {{{#!hs -- RHS size: {terms: 193, types: 182, coercions: 3} empResult :: Result Int empResult = case <$> $fFunctorRow $WEmp lvl19 of { Row dt fm -> case + $fNumInt (I# dt) lvl17 of dt1 { I# dt2 -> case + $fNumInt dt1 lvl17 of dt3 { I# dt4 -> case + $fNumInt dt3 lvl17 of dt5 { I# dt6 -> (\ (is :: InputStream (Vector ColValue)) -> let { lvl23 :: IO (Maybe (Vector ColValue)) lvl23 = case is of { InputStream ds1 ds2 -> ds1 } } in $! (letrec { loop :: Int -> IO (Either Error Int) loop = \ (s :: Int) -> let { lvl24 :: IO (Either Error Int) lvl24 = $! loop (+ $fNumInt s lvl17) } in let { lvl25 :: IO (Either Error Int) lvl25 = return $fMonadIO (Right s) } in >>= $fMonadIO lvl23 (\ (ma :: Maybe (Vector ColValue)) -> case ma of { Nothing -> lvl25; Just a -> case == $fEqInt dt5 (lvl13 a) of { False -> lvl21; True -> fm (\ _ (j :: Int) -> case a of { Vector dt7 dt8 dt9 -> case + $fNumInt (I# dt7) j of { I# i# -> let { $wsucc_ :: Int -> IO (Either Error Int) $wsucc_ = \ (w :: Int) -> case + $fNumInt (I# dt7) w of { I# i#1 -> case indexArray# dt9 i#1 of { (# ipv #) -> case ipv of { __DEFAULT -> lvl21; CV_Int8 dt10 -> case + $fNumInt (I# dt7) (+ $fNumInt w lvl17) of { I# i#2 -> case indexArray# dt9 i#2 of { (# ipv1 #) -> case ipv1 of { __DEFAULT -> lvl21; CV_Text t -> lvl24 } } }; CV_Int16 dt10 -> case + $fNumInt (I# dt7) (+ $fNumInt w lvl17) of { I# i#2 -> case indexArray# dt9 i#2 of { (# ipv1 #) -> case ipv1 of { __DEFAULT -> lvl21; CV_Text t -> lvl24 } } }; CV_Int32 dt10 -> case + $fNumInt (I# dt7) (+ $fNumInt w lvl17) of { I# i#2 -> case indexArray# dt9 i#2 of { (# ipv1 #) -> case ipv1 of { __DEFAULT -> lvl21; CV_Text t -> lvl24 } } } } } } } in case indexArray# dt9 i# of { (# ipv #) -> case ipv of { __DEFAULT -> lvl21; CV_Int8 dt10 -> $wsucc_ (+ $fNumInt j lvl17); CV_Int16 dt10 -> $wsucc_ (+ $fNumInt j lvl17); CV_Int32 dt10 -> $wsucc_ (+ $fNumInt j lvl17) } } } }) lvl22 a $fShowColValue2 } }); } in loop) $fShowColValue2) `cast` ... } } } } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 2 15:07:17 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Dec 2016 15:07:17 -0000 Subject: [GHC] #3384: Add HsSyn prettyprinter tests In-Reply-To: <044.d11e412e7968bb1bf100410e6ff17081@haskell.org> References: <044.d11e412e7968bb1bf100410e6ff17081@haskell.org> Message-ID: <059.0afd19231ef72bb4a41aad5091065751@haskell.org> #3384: Add HsSyn prettyprinter tests -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: task | Status: patch Priority: normal | Milestone: 8.2.1 Component: Test Suite | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2752 Wiki Page: | -------------------------------------+------------------------------------- Comment (by alanz): This is passing all its tests on phab now, please review. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 2 15:09:34 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Dec 2016 15:09:34 -0000 Subject: [GHC] #12917: Location info for error message with multiple source locations Message-ID: <046.8fa3cd74098de3ddbea2196041ea22a0@haskell.org> #12917: Location info for error message with multiple source locations -------------------------------------+------------------------------------- Reporter: gracjan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently: {{{ MonadFailErrors.hs:16:5: error: • Could not deduce (MonadFail m) arising from a do statement with the failable pattern ‘Just x’ from the context: Monad m bound by the type signature for: general :: Monad m => m a at MonadFailErrors.hs:14:1-25 }}} better: {{{ MonadFailErrors.hs:16:5: error: • Could not deduce (MonadFail m) arising from a do statement with the failable pattern ‘Just x’ from the context: Monad m bound by the type signature for: general :: Monad m => m a MonadFailErrors.hs:14:1-25: defined here }}} Rationale: Code editors (Emacs) react to file paths and line numbers in the first column and provide affordances, like go to file after clicking. Related work: Similar mechanism is used by VisualStudio C compiler, gcc, clang. All location information is put in front, so that jump to source code works reliably. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 2 15:29:47 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Dec 2016 15:29:47 -0000 Subject: [GHC] #12917: Location info for error message with multiple source locations In-Reply-To: <046.8fa3cd74098de3ddbea2196041ea22a0@haskell.org> References: <046.8fa3cd74098de3ddbea2196041ea22a0@haskell.org> Message-ID: <061.ce0f3119dd2c774225c6ebf511d87101@haskell.org> #12917: Location info for error message with multiple source locations -------------------------------------+------------------------------------- Reporter: gracjan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by gracjan): This: {{{ MonadFailErrors.hs:44:5: error: • No instance for (MonadFail (ST s)) arising from a do statement with the failable pattern ‘Just x’ • In a stmt of a 'do' block: Just x <- undefined In the expression: do { Just x <- undefined; undefined } In an equation for ‘st’: st = do { Just x <- undefined; undefined } }}} Could be better described with: {{{ MonadFailErrors.hs:44:5-11: No instance for (MonadFail (ST s)) arising from a failable patter in a do statement }}} And count on Emacs to highlight relevant source code part, that is `Just x`. We could try to be more mouthful: {{{ MonadFailErrors.hs:44:5-11: No instance for (MonadFail (ST s)) arising from a failable patter in a do statement MonadFailErrors.hs:41:4: that begins here }}} but in this case this is overkill. In other cases it might be useful. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 2 16:02:43 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Dec 2016 16:02:43 -0000 Subject: [GHC] #12880: Update to Cabal-1.24.1.1 In-Reply-To: <042.fed2f725f41f6702d6c9570271c8e9a1@haskell.org> References: <042.fed2f725f41f6702d6c9570271c8e9a1@haskell.org> Message-ID: <057.fe0718ae18736bf1b3d5103cc0b8364b@haskell.org> #12880: Update to Cabal-1.24.1.1 -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: upstream Priority: high | Milestone: 8.0.2 Component: libraries | Version: 8.0.2-rc1 (other) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => upstream -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 2 16:02:49 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Dec 2016 16:02:49 -0000 Subject: [GHC] #12894: Bump directory In-Reply-To: <046.4beed447095342b2603c24699e3a82bd@haskell.org> References: <046.4beed447095342b2603c24699e3a82bd@haskell.org> Message-ID: <061.4a2b4d3715e8f3ad6faf6d66da3ffc1a@haskell.org> #12894: Bump directory -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: upstream Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => upstream -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 2 16:03:20 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Dec 2016 16:03:20 -0000 Subject: [GHC] #12881: GHC 8.0.2 regression involving OVERLAP annotations In-Reply-To: <050.3e50f8575cc951925264bdd37326ec16@haskell.org> References: <050.3e50f8575cc951925264bdd37326ec16@haskell.org> Message-ID: <065.ace914b01011eb2feaf8137a165ccc11@haskell.org> #12881: GHC 8.0.2 regression involving OVERLAP annotations -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 8.0.2-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2760 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.0` as 80c26da81ff3764887f272845388248ba34cacde. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 2 16:03:43 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Dec 2016 16:03:43 -0000 Subject: [GHC] #12844: No Skolem Info with PartialTypeSignatures In-Reply-To: <047.2c635f7d8f9e46b10ebe3b29b92a477c@haskell.org> References: <047.2c635f7d8f9e46b10ebe3b29b92a477c@haskell.org> Message-ID: <062.0fbaf97e559e6ebedd2e2eacd3017ca4@haskell.org> #12844: No Skolem Info with PartialTypeSignatures -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: partial- crash or panic | sigs/should_compile/T12844 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed * milestone: => 8.0.2 @@ -3,1 +3,1 @@ - {{{ + {{{#!hs New description: The following program triggers a panic: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE PartialTypeSignatures #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeOperators #-} barWraper :: ('(r,r') ~ Head rngs, Foo rngs) => FooData rngs barWraper = bar bar :: (_) => FooData rngs bar = foo data FooData rngs class Foo xs where foo :: (Head xs ~ '(r,r')) => FooData xs type family Head (xs :: [k]) where Head (x ': xs) = x }}} {{{ > ghci NoSkolem.hs [1 of 1] Compiling Main ( NoSkolem.hs, NoSkolem.o ) NoSkolem.hs:8:13: error:ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): No skolem info: k_aYV[sk] }}} I haven't tested with 8.0.2 or head. -- Comment: Merged to `ghc-8.0` as 4212674ba92971734eec064809f8e1a45bca992a. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 2 16:04:10 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Dec 2016 16:04:10 -0000 Subject: [GHC] #12907: ExtendedDefaultRules-related regression in GHC 8.0.2 In-Reply-To: <050.e7f00687e9a9a96cf3fa77c11f6cda6b@haskell.org> References: <050.e7f00687e9a9a96cf3fa77c11f6cda6b@haskell.org> Message-ID: <065.67fa065f45f1db6ed087248413fbbbf0@haskell.org> #12907: ExtendedDefaultRules-related regression in GHC 8.0.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.2 Component: Compiler (Type | Version: 8.0.2-rc1 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2774 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.0` as 706d708a4bb74e27437ea2ec37e4999a4615b0e8. Thanks Ryan! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 2 16:04:44 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Dec 2016 16:04:44 -0000 Subject: [GHC] #12784: Typechecker regression in GHC 8.0.2 involving DefaultSignatures In-Reply-To: <050.9a0edf2bdaab8860178dd08e2e10d2b7@haskell.org> References: <050.9a0edf2bdaab8860178dd08e2e10d2b7@haskell.org> Message-ID: <065.645965c2e6a54295bfbe386ed0beb263@haskell.org> #12784: Typechecker regression in GHC 8.0.2 involving DefaultSignatures -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2682 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.0.2 => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 2 16:09:20 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Dec 2016 16:09:20 -0000 Subject: [GHC] #12784: Typechecker regression in GHC 8.0.2 involving DefaultSignatures In-Reply-To: <050.9a0edf2bdaab8860178dd08e2e10d2b7@haskell.org> References: <050.9a0edf2bdaab8860178dd08e2e10d2b7@haskell.org> Message-ID: <065.51223cd0621eea7113e276ee98c45784@haskell.org> #12784: Typechecker regression in GHC 8.0.2 involving DefaultSignatures -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2682 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Perhaps we should open a separate ticket for this? I think the plan in https://ghc.haskell.org/trac/ghc/ticket/12784#comment:15 goes beyond the original scope of this ticket, which was to identify a regression between 8.0.1 and 8.0.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 2 16:19:05 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Dec 2016 16:19:05 -0000 Subject: [GHC] #12784: Typechecker regression in GHC 8.0.2 involving DefaultSignatures In-Reply-To: <050.9a0edf2bdaab8860178dd08e2e10d2b7@haskell.org> References: <050.9a0edf2bdaab8860178dd08e2e10d2b7@haskell.org> Message-ID: <065.835ed75424116a2c737b1e043d91a072@haskell.org> #12784: Typechecker regression in GHC 8.0.2 involving DefaultSignatures -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2682 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Perhaps we should open a separate ticket for this? Yes, please do! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 2 16:32:57 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Dec 2016 16:32:57 -0000 Subject: [GHC] #12711: GHC Internal error, unboxed sums In-Reply-To: <051.a12a8fc6356677226bbea18551f74f3b@haskell.org> References: <051.a12a8fc6356677226bbea18551f74f3b@haskell.org> Message-ID: <066.6723cbb2b80756ef6e16a46fe1104a7f@haskell.org> #12711: GHC Internal error, unboxed sums -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: osa1 Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: UnboxedSums Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2753 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Punting to 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 2 16:33:39 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Dec 2016 16:33:39 -0000 Subject: [GHC] #11767: Add @since annotations for base instances In-Reply-To: <046.80486230653199e8f5fef1dcd513180c@haskell.org> References: <046.80486230653199e8f5fef1dcd513180c@haskell.org> Message-ID: <061.99a94bec08bfd82ced3ef1ee0ca9ef4f@haskell.org> #11767: Add @since annotations for base instances -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Core Libraries | Version: 7.10.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11768 | Differential Rev(s): Phab:D2277 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: seraphime => * status: patch => new -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 2 16:34:01 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Dec 2016 16:34:01 -0000 Subject: [GHC] #9793: Some as-patterns could be accepted in pattern synonyms In-Reply-To: <045.e251d4b7f57881692430bb7253319357@haskell.org> References: <045.e251d4b7f57881692430bb7253319357@haskell.org> Message-ID: <060.38028e94e5bbdb3ba6d256ce8d74c4e6@haskell.org> #9793: Some as-patterns could be accepted in pattern synonyms -------------------------------------+------------------------------------- Reporter: cactus | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 7.8.3 checker) | Keywords: Resolution: | PatternSynonyms, newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1666 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => new -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 2 16:35:31 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Dec 2016 16:35:31 -0000 Subject: [GHC] #3399: Generalize the type of Data.List.{deleteBy, deleteFirstsBy} In-Reply-To: <043.61bcbfbf5cb528673d0b1d82854dcbb9@haskell.org> References: <043.61bcbfbf5cb528673d0b1d82854dcbb9@haskell.org> Message-ID: <058.ffe891a24354e5ab5ec29657f73f9caa@haskell.org> #3399: Generalize the type of Data.List.{deleteBy, deleteFirstsBy} -------------------------------------+------------------------------------- Reporter: iago | Owner: Type: proposal | Status: patch Priority: normal | Milestone: Component: libraries/base | Version: 6.10.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2526 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => Comment: This won't happen for 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 2 16:38:00 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Dec 2016 16:38:00 -0000 Subject: [GHC] #10600: -fwarn-incomplete-patterns doesn't work with -fno-code In-Reply-To: <043.972d3170891da80a4e96bca7b675a836@haskell.org> References: <043.972d3170891da80a4e96bca7b675a836@haskell.org> Message-ID: <058.30a87e680e023a55bb0cc6928a832b20@haskell.org> #10600: -fwarn-incomplete-patterns doesn't work with -fno-code -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: driver/T8101b Blocked By: | Blocking: Related Tickets: #8101 | Differential Rev(s): Phab:D1278 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: ezyang => * status: patch => new * milestone: 8.2.1 => 8.4.1 Comment: It looks unlikely that this will happen for 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 2 16:39:42 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Dec 2016 16:39:42 -0000 Subject: [GHC] #11767: Add @since annotations for base instances In-Reply-To: <046.80486230653199e8f5fef1dcd513180c@haskell.org> References: <046.80486230653199e8f5fef1dcd513180c@haskell.org> Message-ID: <061.3dcba8dddf5a7c95d2a6d6663e623148@haskell.org> #11767: Add @since annotations for base instances -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Core Libraries | Version: 7.10.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11768 | Differential Rev(s): Phab:D2277 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.4.1 Comment: It seems unlikely that this will happen for 8.2. Punting. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 2 16:40:34 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Dec 2016 16:40:34 -0000 Subject: [GHC] #10803: New SignatureSections extension In-Reply-To: <042.499b2af8de1376e7739ef3516bd5a45e@haskell.org> References: <042.499b2af8de1376e7739ef3516bd5a45e@haskell.org> Message-ID: <057.60d3093ba6fcfab3556e22689bb68500@haskell.org> #10803: New SignatureSections extension -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: feature request | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1185 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.4.1 Comment: It seems unlikely that this will happen for 8.2. Punting. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 2 16:41:27 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Dec 2016 16:41:27 -0000 Subject: [GHC] #10812: High memory usage after performing GC In-Reply-To: <046.80aa46a375cd3a278869ea812244030d@haskell.org> References: <046.80aa46a375cd3a278869ea812244030d@haskell.org> Message-ID: <061.241eea10de00f8e57ad9f480982690ea@haskell.org> #10812: High memory usage after performing GC ---------------------------------+-------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by simonmar): Firstly I think the huge list is being lifted out and shared between the two computations, which accounts for all the memory still live at the end of "A". Also, after all the weak pointers have died, it takes a little while for all the finalizers to complete, so the memory won't be free at the point where we do the `performGC`. If you compile with `-threaded` you'll get an idle GC during the waiting period which will release some memory. Overall I haven't seen anything going wrong here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 2 16:41:35 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Dec 2016 16:41:35 -0000 Subject: [GHC] #10812: High memory usage after performing GC In-Reply-To: <046.80aa46a375cd3a278869ea812244030d@haskell.org> References: <046.80aa46a375cd3a278869ea812244030d@haskell.org> Message-ID: <061.7d547d033a73596fe71d35fba6578b31@haskell.org> #10812: High memory usage after performing GC ---------------------------------+-------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: closed Priority: high | Milestone: Component: Compiler | Version: 7.10.2 Resolution: invalid | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => invalid -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 2 17:01:33 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Dec 2016 17:01:33 -0000 Subject: [GHC] #12916: GHC 8.0.1 vs GHC HEAD (8.1.20161202) doesn't do inlining and unboxing very well In-Reply-To: <048.78c7dbc5b6c2354f4f01a2e0b9be7926@haskell.org> References: <048.78c7dbc5b6c2354f4f01a2e0b9be7926@haskell.org> Message-ID: <063.c84157d6e5fd4b11c70e86bfd90b6fd3@haskell.org> #12916: GHC 8.0.1 vs GHC HEAD (8.1.20161202) doesn't do inlining and unboxing very well -------------------------------------+------------------------------------- Reporter: alexbiehl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I'm having difficulty reproducing this with a build of GHC HEAD at commit ddc271e8ed6c5ec5e83dd50c6c5e77955a0e90ac. In fact, the Core I get looks just about identical to the one that GHC 8.0.1 produces (with `$wempResult`). FWIW, this is using `io-streams-1.3.5.0` and `vector-0.11.0.0`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 2 17:04:50 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Dec 2016 17:04:50 -0000 Subject: [GHC] #12916: GHC 8.0.1 vs GHC HEAD (8.1.20161202) doesn't do inlining and unboxing very well In-Reply-To: <048.78c7dbc5b6c2354f4f01a2e0b9be7926@haskell.org> References: <048.78c7dbc5b6c2354f4f01a2e0b9be7926@haskell.org> Message-ID: <063.389a0c2f94334f2f01a61a044ed10313@haskell.org> #12916: GHC 8.0.1 vs GHC HEAD (8.1.20161202) doesn't do inlining and unboxing very well -------------------------------------+------------------------------------- Reporter: alexbiehl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): If GHC starts producing bad code, it's important to look into it, so thanks for reporting. Let hope it's a false alarm, though, in the light of comment:1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 2 17:08:35 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Dec 2016 17:08:35 -0000 Subject: [GHC] #12916: GHC 8.0.1 vs GHC HEAD (8.1.20161202) doesn't do inlining and unboxing very well In-Reply-To: <048.78c7dbc5b6c2354f4f01a2e0b9be7926@haskell.org> References: <048.78c7dbc5b6c2354f4f01a2e0b9be7926@haskell.org> Message-ID: <063.58505716b5fa10123f0058562f708228@haskell.org> #12916: GHC 8.0.1 vs GHC HEAD (8.1.20161202) doesn't do inlining and unboxing very well -------------------------------------+------------------------------------- Reporter: alexbiehl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alexbiehl): Strange, my ghc-stage2 is at the same git revision! This is how I invoked it to get to the core: {{{#!bash /Users/alexbiehl/git/ghc/inplace/bin/ghc-stage2 test.hs -O2 -threaded -rtsopts -ddump-simpl -dsupress-idinfo -dsuppress-coercions -dsuppress- type-applications -dsuppress-uniques -dsuppress-module-prefixes -fforce- recomp | less }}} (where test.hs is the decode.hs from github link) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 2 17:10:14 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Dec 2016 17:10:14 -0000 Subject: [GHC] #12918: Make DefaultSignatures more particular about their types on the RHS of a context Message-ID: <050.d16ce32d20f959d1e744b2dfaad73e22@haskell.org> #12918: Make DefaultSignatures more particular about their types on the RHS of a context -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.2-rc1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #12784 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Quoting [https://ghc.haskell.org/trac/ghc/ticket/12784#comment:15 simonpj] in #12784: > This keeps bugging me. Is this ok or not? > {{{ > class Monad m => MonadSupply m where > fresh :: m Integer > default fresh :: MonadTrans t => t m Integer > fresh = lift fresh > }}} > It's accepted right now. But I think it should not be; specifically, '''I think the type of the default method should differ from the main method only in its context'''. Thus if > {{{ > fresh :: C => blah > }}} > then the default method should look like > {{{ > default fresh :: C' => blah > }}} > with the same `blah`. So we should write > {{{ > class Monad m => MonadSupply m where > fresh :: m Integer > default fresh :: (MonadTrans t, MonadSupply m', m ~ t m') => m Integer > -- NB: same 'm Integer' after the '=>' > fresh = lift fresh > }}} > Why? Several reasons: > > * It would make no sense at all to have a type that was actually ''incompatible'' with the main method type, e.g. > {{{ > default fresh :: m Bool > }}} > That would ''always'' fail in an instance decl. > > * We use Visible Type Application to instantiate the default method in an instance, for reasons discussed in `Note [Default methods in instances]` in `TcInstDcls`. So we need to know exactly what the universally quantified type variables are, and when instantaited that way the type of the default method must match the expected type. > > * Perhaps by changing only the context, we are making it a bit more explicit the ways in which the default method is less polymorphic than the original method. > > With this change, the patches to Agda in comment:14 would all be signalled at the ''class'' decl, which is the right place, not the instance decl. The patches to Agda would still be needed, of course. > > Does that rule make sense to everyone? The [http://downloads.haskell.org/~ghc/master/users-guide/glasgow_exts.html #class-default-signatures user manual] is silent on what rules the default signature should obey. It's just formalising the idea that the default signature should match the main one, but perhaps with some additional constraints. > > -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 2 17:11:04 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Dec 2016 17:11:04 -0000 Subject: [GHC] #12784: Typechecker regression in GHC 8.0.2 involving DefaultSignatures In-Reply-To: <050.9a0edf2bdaab8860178dd08e2e10d2b7@haskell.org> References: <050.9a0edf2bdaab8860178dd08e2e10d2b7@haskell.org> Message-ID: <065.15ee6f0d366441225639d6f1fff6e01f@haskell.org> #12784: Typechecker regression in GHC 8.0.2 involving DefaultSignatures -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #12918 | Differential Rev(s): Phab:D2682 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => fixed * related: => #12918 Comment: I've opened #12918 for this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 2 17:17:53 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Dec 2016 17:17:53 -0000 Subject: [GHC] #12916: GHC 8.0.1 vs GHC HEAD (8.1.20161202) doesn't do inlining and unboxing very well In-Reply-To: <048.78c7dbc5b6c2354f4f01a2e0b9be7926@haskell.org> References: <048.78c7dbc5b6c2354f4f01a2e0b9be7926@haskell.org> Message-ID: <063.ad508fc8d1d4fe5c75f23f08b5499186@haskell.org> #12916: GHC 8.0.1 vs GHC HEAD (8.1.20161202) doesn't do inlining and unboxing very well -------------------------------------+------------------------------------- Reporter: alexbiehl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Well, something must be different... {{{ ghc4/inplace/bin/ghc-stage2 Bug.hs -O2 -threaded -rtsopts -ddump-simpl -dsuppress-idinfo -dsuppress-coercions -dsuppress-type-applications -dsuppress-uniques -dsuppress-module-prefixes -fforce-recomp [1 of 1] Compiling X ( Bug.hs, Bug.o ) ... -- RHS size: {terms: 2, types: 2, coercions: 0} empResult2 :: Either Error Int empResult2 = Left Error -- RHS size: {terms: 175, types: 184, coercions: 4} $wempResult :: IO (Maybe (Vector ColValue)) -> State# RealWorld -> (# State# RealWorld, Either Error Int #) $wempResult = \ (ww :: IO (Maybe (Vector ColValue))) (w :: State# RealWorld) -> letrec { $sloop :: State# RealWorld -> Int# -> (# State# RealWorld, Either Error Int #) $sloop = \ (sc :: State# RealWorld) (sc1 :: Int#) -> case (ww `cast` ...) sc of { (# ipv, ipv1 #) -> case ipv1 of { Nothing -> (# ipv, Right (I# sc1) #); Just a -> case length $fVectorVectora a of { I# y -> case y of { __DEFAULT -> (# ipv, empResult2 #); 4# -> case a of { Vector dt dt1 dt2 -> let { $wsucc_ :: Int# -> State# RealWorld -> (# State# RealWorld, Either Error Int #) $wsucc_ = \ (ww1 :: Int#) (w1 :: State# RealWorld) -> let { $wsucc_1 :: Int# -> State# RealWorld -> (# State# RealWorld, Either Error Int #) $wsucc_1 = \ (ww2 :: Int#) (w2 :: State# RealWorld) -> case indexArray# dt2 (+# dt ww2) of { (# ipv2 #) -> case ipv2 of { __DEFAULT -> (# w2, empResult2 #); CV_Int8 dt4 -> case indexArray# dt2 (+# dt (+# ww2 1#)) of { (# ipv3 #) -> case ipv3 of { __DEFAULT -> (# w2, empResult2 #); CV_Text t -> $sloop w2 (+# sc1 1#) } }; CV_Int16 dt4 -> case indexArray# dt2 (+# dt (+# ww2 1#)) of { (# ipv3 #) -> case ipv3 of { __DEFAULT -> (# w2, empResult2 #); CV_Text t -> $sloop w2 (+# sc1 1#) } }; CV_Int32 dt4 -> case indexArray# dt2 (+# dt (+# ww2 1#)) of { (# ipv3 #) -> case ipv3 of { __DEFAULT -> (# w2, empResult2 #); CV_Text t -> $sloop w2 (+# sc1 1#) } } } } } in case indexArray# dt2 (+# dt ww1) of { (# ipv2 #) -> case ipv2 of { __DEFAULT -> (# w1, empResult2 #); CV_Int8 dt4 -> $wsucc_1 (+# ww1 1#) w1; CV_Int16 dt4 -> $wsucc_1 (+# ww1 1#) w1; CV_Int32 dt4 -> $wsucc_1 (+# ww1 1#) w1 } } } in case indexArray# dt2 dt of { (# ipv2 #) -> case ipv2 of { __DEFAULT -> (# ipv, empResult2 #); CV_Int8 dt4 -> $wsucc_ 1# ipv; CV_Int16 dt4 -> $wsucc_ 1# ipv; CV_Int32 dt4 -> $wsucc_ 1# ipv } } } } } } }; } in $sloop w 0# -- RHS size: {terms: 8, types: 16, coercions: 0} empResult1 :: InputStream (Vector ColValue) -> State# RealWorld -> (# State# RealWorld, Either Error Int #) empResult1 = \ (w :: InputStream (Vector ColValue)) (w1 :: State# RealWorld) -> case w of { InputStream ww1 ww2 -> $wempResult ww1 w1 } -- RHS size: {terms: 1, types: 0, coercions: 13} empResult :: Result Int empResult = empResult1 `cast` ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 2 17:21:11 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Dec 2016 17:21:11 -0000 Subject: [GHC] #12916: GHC 8.0.1 vs GHC HEAD (8.1.20161202) doesn't do inlining and unboxing very well In-Reply-To: <048.78c7dbc5b6c2354f4f01a2e0b9be7926@haskell.org> References: <048.78c7dbc5b6c2354f4f01a2e0b9be7926@haskell.org> Message-ID: <063.ca29ff75ea3f769ff808b196e3e07211@haskell.org> #12916: GHC 8.0.1 vs GHC HEAD (8.1.20161202) doesn't do inlining and unboxing very well -------------------------------------+------------------------------------- Reporter: alexbiehl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): I haven't looked at the Core at all, but maybe the original reporter is comparing a release (perf) build of GHC 8.0.1 to a devel build of HEAD? The difference could be due to different strictness/unfolding info in a library. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 2 17:24:21 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Dec 2016 17:24:21 -0000 Subject: [GHC] #12916: GHC 8.0.1 vs GHC HEAD (8.1.20161202) doesn't do inlining and unboxing very well In-Reply-To: <048.78c7dbc5b6c2354f4f01a2e0b9be7926@haskell.org> References: <048.78c7dbc5b6c2354f4f01a2e0b9be7926@haskell.org> Message-ID: <063.d01cccbdf45164d73a2a42a845d3b368@haskell.org> #12916: GHC 8.0.1 vs GHC HEAD (8.1.20161202) doesn't do inlining and unboxing very well -------------------------------------+------------------------------------- Reporter: alexbiehl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alexbiehl): That could be the case indeed: I invoked `hadrian -j --flavour=quickest` to build the compiler. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 2 17:25:01 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Dec 2016 17:25:01 -0000 Subject: [GHC] #12784: Typechecker regression in GHC 8.0.2 involving DefaultSignatures In-Reply-To: <050.9a0edf2bdaab8860178dd08e2e10d2b7@haskell.org> References: <050.9a0edf2bdaab8860178dd08e2e10d2b7@haskell.org> Message-ID: <065.06e955ab32107e7f80575e61554e44d2@haskell.org> #12784: Typechecker regression in GHC 8.0.2 involving DefaultSignatures -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #12918 | Differential Rev(s): Phab:D2682 Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): By the way it seems I was pretty far off in my estimation of how frequent this pattern is in user code (it even showed up on StackOverflow); RyanGlScott if you want to add some minimal example of this issue to the release notes I'd be in favor of that after all. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 2 17:29:20 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Dec 2016 17:29:20 -0000 Subject: [GHC] #12916: GHC 8.0.1 vs GHC HEAD (8.1.20161202) doesn't do inlining and unboxing very well In-Reply-To: <048.78c7dbc5b6c2354f4f01a2e0b9be7926@haskell.org> References: <048.78c7dbc5b6c2354f4f01a2e0b9be7926@haskell.org> Message-ID: <063.ad2c05b3dda2087c6e5e861d5a0c2075@haskell.org> #12916: GHC 8.0.1 vs GHC HEAD (8.1.20161202) doesn't do inlining and unboxing very well -------------------------------------+------------------------------------- Reporter: alexbiehl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:6 alexbiehl]: > That could be the case indeed: I invoked `hadrian -j --flavour=quickest` to build the compiler. I think `quickest` might very well be the culprit. From `mk/build.mk`: {{{ # Even faster build. NOT RECOMMENDED: the libraries will be # completely unoptimised, so any code built with this compiler # (including stage2) will run very slowly: #BuildFlavour = quickest }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 2 17:31:37 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Dec 2016 17:31:37 -0000 Subject: [GHC] #12916: GHC 8.0.1 vs GHC HEAD (8.1.20161202) doesn't do inlining and unboxing very well In-Reply-To: <048.78c7dbc5b6c2354f4f01a2e0b9be7926@haskell.org> References: <048.78c7dbc5b6c2354f4f01a2e0b9be7926@haskell.org> Message-ID: <063.80eab3943dd196557ba4c84c2c41d6fc@haskell.org> #12916: GHC 8.0.1 vs GHC HEAD (8.1.20161202) doesn't do inlining and unboxing very well -------------------------------------+------------------------------------- Reporter: alexbiehl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Right, `quickest` is basically designed to see whether the stage2 compiler works at all, as fast as possible. So it doesn't bother optimizing the libraries (and you will get a slow stage2 compiler that generates slow code). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 2 17:32:54 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Dec 2016 17:32:54 -0000 Subject: [GHC] #12141: Testsuite failures when GHC is built with 'quickest' profile In-Reply-To: <050.60c5f2d7be4e31d33b031ee5a79af463@haskell.org> References: <050.60c5f2d7be4e31d33b031ee5a79af463@haskell.org> Message-ID: <065.86d310f5a175716529d130a6c4947a67@haskell.org> #12141: Testsuite failures when GHC is built with 'quickest' profile -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Test Suite | Version: 8.1 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => invalid Comment: On second thought, this probably isn't a worthwhile endeavor. I forgot that when built with `quickest` setting, GHC compiles code without any optimizations at all, which means that the generated Core is necessarily going to be quite different on most test cases (not to mention the performance implications). Besides, there's a disclaimer on the `quickest` setting in `mk/build.mk` anyway, so if you try running the testsuite after knowingly choosing `quickest`, you get what you deserve :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 2 17:33:19 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Dec 2016 17:33:19 -0000 Subject: [GHC] #12916: GHC 8.0.1 vs GHC HEAD (8.1.20161202) doesn't do inlining and unboxing very well In-Reply-To: <048.78c7dbc5b6c2354f4f01a2e0b9be7926@haskell.org> References: <048.78c7dbc5b6c2354f4f01a2e0b9be7926@haskell.org> Message-ID: <063.f91e2843bc4cd2cb01bce0a9f93b583d@haskell.org> #12916: GHC 8.0.1 vs GHC HEAD (8.1.20161202) doesn't do inlining and unboxing very well -------------------------------------+------------------------------------- Reporter: alexbiehl | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => closed * resolution: => invalid -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 2 17:39:36 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Dec 2016 17:39:36 -0000 Subject: [GHC] #12781: Significantly higher allocation with INLINE vs NOINLINE In-Reply-To: <054.6f4a7487425e98bbdafe84ff94c63a9b@haskell.org> References: <054.6f4a7487425e98bbdafe84ff94c63a9b@haskell.org> Message-ID: <069.bbd314645debf22d38750eb2406f0caa@haskell.org> #12781: Significantly higher allocation with INLINE vs NOINLINE -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #12747 #12603 | Differential Rev(s): #5775 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: maurerl@…, pdownen@…, ariola@… (added) Comment: Interesting. I know exactly what is going on. With `NOINLINE dis` we get {{{ dis = \p. let $w$j ww = blah in case p of -1# -> $w$j (...) DEFAULT -> $w$j (..) go xs z = case xs of [] -> ... (y:ys) -> case dis y of () -> go ys z }}} Note that `$w$j` is a join point, so incurs no allocation cost. There is just one call to `dis` in the body of `go`. So without the `NOINLINE dis`, the function `dis` inlines in the body of `go`. But then we get something like {{{ go xs z = case xs of [] -> ... (y:ys) -> let $w$j ww = blah in case p of -1# -> case ($w$j (...)) of () -> go ys z DEFAULT -> case ($w$j (...)) of () -> go yz z }}} Yikes! `$w$j` is no longer a join point, so allocation goes up. Six months ago I would have felt sad. But today I feel happy. In our paper [https://www.microsoft.com/en-us/research/publication/compiling- without-continuations/ Compiling without continuations], we explain how to ensure that join points are never destroyed. Moreover, Luke Maurer is well advanced on a full implementation in GHC. Luke, how is it going? When will it land in GHC? We need this! This ticket would make a lovely example to add to the paper, because it's a true "from the wild" example. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 2 17:42:24 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Dec 2016 17:42:24 -0000 Subject: [GHC] #12141: Testsuite failures when GHC is built with 'quickest' profile In-Reply-To: <050.60c5f2d7be4e31d33b031ee5a79af463@haskell.org> References: <050.60c5f2d7be4e31d33b031ee5a79af463@haskell.org> Message-ID: <065.dd55c7cc41e6b9af4ac2206a17440677@haskell.org> #12141: Testsuite failures when GHC is built with 'quickest' profile -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Test Suite | Version: 8.1 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Could add "and many tests will fail (Trac #12141)" to that disclaimer. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 2 17:43:19 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Dec 2016 17:43:19 -0000 Subject: [GHC] #12781: Significantly higher allocation with INLINE vs NOINLINE In-Reply-To: <054.6f4a7487425e98bbdafe84ff94c63a9b@haskell.org> References: <054.6f4a7487425e98bbdafe84ff94c63a9b@haskell.org> Message-ID: <069.9a2906db95083e68beff495eb2bc1283@haskell.org> #12781: Significantly higher allocation with INLINE vs NOINLINE -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: JoinPoints Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #12747 #12603 | Differential Rev(s): #5775 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => JoinPoints -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 2 17:49:50 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Dec 2016 17:49:50 -0000 Subject: [GHC] #12916: GHC 8.0.1 vs GHC HEAD (8.1.20161202) doesn't do inlining and unboxing very well In-Reply-To: <048.78c7dbc5b6c2354f4f01a2e0b9be7926@haskell.org> References: <048.78c7dbc5b6c2354f4f01a2e0b9be7926@haskell.org> Message-ID: <063.8540adeffac9b1deb4bee141b582af5b@haskell.org> #12916: GHC 8.0.1 vs GHC HEAD (8.1.20161202) doesn't do inlining and unboxing very well -------------------------------------+------------------------------------- Reporter: alexbiehl | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alexbiehl): Ok, thanks for the explanation! But one last question: Why is GHC 8.0.1 and HEAD even in perf flavour not able to inline the length function on the vector? {{{#!hs ... Just a -> case length $fVectorVectora a of { I# y -> case y of { ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 2 19:32:45 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Dec 2016 19:32:45 -0000 Subject: [GHC] #10445: Wrong stack space size when using -Ksize In-Reply-To: <042.794c5bde83bb1d57f2fc1adc9766262f@haskell.org> References: <042.794c5bde83bb1d57f2fc1adc9766262f@haskell.org> Message-ID: <057.8a2a0fb36ae1dff99b0c8e1fbe061ec2@haskell.org> #10445: Wrong stack space size when using -Ksize -------------------------------------+------------------------------------- Reporter: asr | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D938, Wiki Page: | Phab:D961 -------------------------------------+------------------------------------- Description changed by asr: @@ -37,1 +37,1 @@ - and GHC 7.10.1 reports + GHC 7.10.1 reports @@ -43,1 +43,8 @@ - GHC 7.8.3 and 7.10.1 report an incorrect stack space size. + and GHC 7.10.2, 7.10.3. 8.0.1 and 8.0.2-rc1 report + + {{{ + Stack space overflow: current size 33624 bytes. + }}} + + + GHC >= 7.8.4 report an incorrect stack space size. New description: After compiling the first example in https://wiki.haskell.org/Performance/Accumulating_parameter: {{{ $ cat Test.hs len :: [a] -> Int len [] = 0 len (x:xs) = len xs + 1 main :: IO () main = print $ len [1..1000000] }}} {{{ $ ghc Test.hs -rtsopts }}} and running {{{ ./Test +RTS -K10K }}} GHC 7.6.3 reports {{{ Stack space overflow: current size 10240 bytes. }}} GHC 7.8.4 reports {{{ Stack space overflow: current size 33632 bytes. }}} GHC 7.10.1 reports {{{ Stack space overflow: current size 99136 bytes. }}} and GHC 7.10.2, 7.10.3. 8.0.1 and 8.0.2-rc1 report {{{ Stack space overflow: current size 33624 bytes. }}} GHC >= 7.8.4 report an incorrect stack space size. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 2 19:43:59 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Dec 2016 19:43:59 -0000 Subject: [GHC] #12141: Testsuite failures when GHC is built with 'quickest' profile In-Reply-To: <050.60c5f2d7be4e31d33b031ee5a79af463@haskell.org> References: <050.60c5f2d7be4e31d33b031ee5a79af463@haskell.org> Message-ID: <065.e914d5fd620abe8a6aa6f1ff6424f973@haskell.org> #12141: Testsuite failures when GHC is built with 'quickest' profile -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Test Suite | Version: 8.1 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"27731f144fb676d3117cd7e04eb71c13d53bb170/ghc" 27731f14/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="27731f144fb676d3117cd7e04eb71c13d53bb170" Note Trac #12141 in mk/build.mk.sample Mention that many GHC testsuite tests will fail with a compiler built with the quickest profile. See Trac #12141. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 2 19:59:07 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Dec 2016 19:59:07 -0000 Subject: [GHC] #12784: Typechecker regression in GHC 8.0.2 involving DefaultSignatures In-Reply-To: <050.9a0edf2bdaab8860178dd08e2e10d2b7@haskell.org> References: <050.9a0edf2bdaab8860178dd08e2e10d2b7@haskell.org> Message-ID: <065.1bbac1074e2c073e4538d361d3979ef6@haskell.org> #12784: Typechecker regression in GHC 8.0.2 involving DefaultSignatures -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #12918 | Differential Rev(s): Phab:D2682 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: closed => new * resolution: fixed => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 2 19:59:23 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Dec 2016 19:59:23 -0000 Subject: [GHC] #12784: Typechecker regression in GHC 8.0.2 involving DefaultSignatures In-Reply-To: <050.9a0edf2bdaab8860178dd08e2e10d2b7@haskell.org> References: <050.9a0edf2bdaab8860178dd08e2e10d2b7@haskell.org> Message-ID: <065.c41ab696d3fb2dfabb71bb5c0337077c@haskell.org> #12784: Typechecker regression in GHC 8.0.2 involving DefaultSignatures -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: patch Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #12918 | Differential Rev(s): Phab:D2682, Wiki Page: | Phab:D2786 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: Phab:D2682 => Phab:D2682, Phab:D2786 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 2 20:07:45 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Dec 2016 20:07:45 -0000 Subject: [GHC] #12911: Levity polymorphism check eliminates non-levity-polymorphic data constructor In-Reply-To: <047.553556d51b1a72154ff5eadb4d1146d2@haskell.org> References: <047.553556d51b1a72154ff5eadb4d1146d2@haskell.org> Message-ID: <062.9fbc75fdf779f93483ff019faaed0712@haskell.org> #12911: Levity polymorphism check eliminates non-levity-polymorphic data constructor -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by josef): I think I hit upon this restriction when trying to implement some of the code from the levity polymorphism paper. The section on levity polymorphic type classes explains how the dictionary from levity polymorphic Num is perfectly safe. {{{ data Num (a :: TYPE r) = MkNum {(+) :: a → a → a, abs :: a → a} }}} But sadly GHC rejects the data type declaration above. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 2 20:29:23 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Dec 2016 20:29:23 -0000 Subject: [GHC] #12549: Panic on ":t datatypeName" In-Reply-To: <046.93c629409627bd964a188fb34004cca8@haskell.org> References: <046.93c629409627bd964a188fb34004cca8@haskell.org> Message-ID: <061.df00a16dcbc944eff51319b229f7ed1a@haskell.org> #12549: Panic on ":t datatypeName" ---------------------------------+-------------------------------------- Reporter: johnleo | Owner: johnleo Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by Ben Gamari ): In [changeset:"2350906bfb496758d81caf3b66b232e1950285e9/ghc" 2350906/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2350906bfb496758d81caf3b66b232e1950285e9" Maintain in-scope set in deeply_instantiate (fixes #12549). Maintain in-scope set in deeply_instantiate (Fixes T12549). lint fixes Test Plan: validate Reviewers: simonpj, austin, goldfire, bgamari Reviewed By: simonpj, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2757 GHC Trac Issues: #12549 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 2 20:29:23 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Dec 2016 20:29:23 -0000 Subject: [GHC] #12903: SIGINT is not handled in forked process In-Reply-To: <045.73f1eb35eda69f56b71c66e83162bd9f@haskell.org> References: <045.73f1eb35eda69f56b71c66e83162bd9f@haskell.org> Message-ID: <060.9bfdca2a1c9a9e6235c2790cf68ef9a7@haskell.org> #12903: SIGINT is not handled in forked process -------------------------------------+------------------------------------- Reporter: qnikst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2770 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"895a131f6e56847d9ebca2e9bfe19a3189e49d72/ghc" 895a131f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="895a131f6e56847d9ebca2e9bfe19a3189e49d72" Install toplevel handler inside fork. When rts is forked it doesn't update toplevel handler, so UserInterrupt exception is sent to Thread1 that doesn't exist in forked process. We install toplevel handler when fork so signal will be delivered to the new main thread. Fixes #12903 Reviewers: simonmar, austin, erikd, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2770 GHC Trac Issues: #12903 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 2 20:29:23 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Dec 2016 20:29:23 -0000 Subject: [GHC] #12912: IO library should not use select() In-Reply-To: <047.2c26cf965e8c4185b06cc1a4540c3c04@haskell.org> References: <047.2c26cf965e8c4185b06cc1a4540c3c04@haskell.org> Message-ID: <062.62d4e55166f3e078c29af95a3621edd8@haskell.org> #12912: IO library should not use select() -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"f46369b8a1bf90a3bdc30f2b566c3a7e03672518/ghc" f46369b8/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f46369b8a1bf90a3bdc30f2b566c3a7e03672518" fdReady: use poll() instead of select() select() is limited to 1024 file descriptors. This actually blew up in a very hard-to-debug way in our production system when using the hinotify package. Test Plan: libraries/tests pass, paricularly hGetBuf001 which exercises this code. Reviewers: niteria, erikd, austin, hvr, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2785 GHC Trac Issues: #12912 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 2 20:29:35 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Dec 2016 20:29:35 -0000 Subject: [GHC] #12903: SIGINT is not handled in forked process In-Reply-To: <045.73f1eb35eda69f56b71c66e83162bd9f@haskell.org> References: <045.73f1eb35eda69f56b71c66e83162bd9f@haskell.org> Message-ID: <060.779654c78dbe6b6c70aa3667bf0b57ba@haskell.org> #12903: SIGINT is not handled in forked process -------------------------------------+------------------------------------- Reporter: qnikst | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2770 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 2 20:30:54 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Dec 2016 20:30:54 -0000 Subject: [GHC] #12549: Panic on ":t datatypeName" In-Reply-To: <046.93c629409627bd964a188fb34004cca8@haskell.org> References: <046.93c629409627bd964a188fb34004cca8@haskell.org> Message-ID: <061.0a5f1452644e2158a21f7c6728fae530@haskell.org> #12549: Panic on ":t datatypeName" ---------------------------------+-------------------------------------- Reporter: johnleo | Owner: johnleo Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Changes (by bgamari): * milestone: => 8.2.1 Comment: Thanks John! Is there a bug describing the `tc_infer_args` issue mentioned in comment:26? I'll keep this ticket open until one is opened so we don't lose track of this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 2 20:31:28 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Dec 2016 20:31:28 -0000 Subject: [GHC] #12912: IO library should not use select() In-Reply-To: <047.2c26cf965e8c4185b06cc1a4540c3c04@haskell.org> References: <047.2c26cf965e8c4185b06cc1a4540c3c04@haskell.org> Message-ID: <062.28636cdf5e926b958414c2e9731cf53c@haskell.org> #12912: IO library should not use select() -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: libraries/base | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 2 20:41:34 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Dec 2016 20:41:34 -0000 Subject: [GHC] #12915: cmmImplementSwitchPlans creates duplicate blocks In-Reply-To: <048.450627ba0680e3fafd8b0486acc85c67@haskell.org> References: <048.450627ba0680e3fafd8b0486acc85c67@haskell.org> Message-ID: <063.97cbecd13debfbf9f9f4522ece0e6295@haskell.org> #12915: cmmImplementSwitchPlans creates duplicate blocks -------------------------------------+------------------------------------- Reporter: alexbiehl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): `cmmImplementSwitchPlans` is run after `elimCommonBlocks` in order to avoid making unnecessary decisions in the branching code if the blocks happen to be the same ones any ways. I was not aware that `cmmImplementSwitchPlans` itself could make new blocks that are identical. In your examples, what happend to the assignments ` _sfh6::I64 = I64[_sfh3::P64 + 7];`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 2 20:42:13 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Dec 2016 20:42:13 -0000 Subject: [GHC] #12549: Panic on ":t datatypeName" In-Reply-To: <046.93c629409627bd964a188fb34004cca8@haskell.org> References: <046.93c629409627bd964a188fb34004cca8@haskell.org> Message-ID: <061.697f1bcb4f527a4eaff7c67dcca02b27@haskell.org> #12549: Panic on ":t datatypeName" ---------------------------------+-------------------------------------- Reporter: johnleo | Owner: johnleo Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by johnleo): Thanks for merging! There is a bug #12785 in which Simon changed a `substTy` to `substTyUnchecked` and mentions it is due to `tc_infer_args` not setting up the in-scope set correctly. However I'm not sure if fixing the `tc_infer_args` problem fixes that bug or if this is a separate issue. Richard and Simon, is it enough to track the `tc_infer_args` problem in #12785? If not I can create a new bug for it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 2 21:10:08 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Dec 2016 21:10:08 -0000 Subject: [GHC] #12912: IO library should not use select() In-Reply-To: <047.2c26cf965e8c4185b06cc1a4540c3c04@haskell.org> References: <047.2c26cf965e8c4185b06cc1a4540c3c04@haskell.org> Message-ID: <062.aa6ad3239886e5816648d5f6d4e311f5@haskell.org> #12912: IO library should not use select() -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: libraries/base | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Merged to `ghc-8.0` as d9e7a69290c39f6075b70c218fbcf7f85682e9cb. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 2 21:11:14 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Dec 2016 21:11:14 -0000 Subject: [GHC] #12903: SIGINT is not handled in forked process In-Reply-To: <045.73f1eb35eda69f56b71c66e83162bd9f@haskell.org> References: <045.73f1eb35eda69f56b71c66e83162bd9f@haskell.org> Message-ID: <060.95d2fb6585dc71cbab3a644312a7a81a@haskell.org> #12903: SIGINT is not handled in forked process -------------------------------------+------------------------------------- Reporter: qnikst | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Runtime System | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2770 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.0.2 Comment: I looked at this again and it actually seemed simple enough to merge and a sensible fix. Merged to `ghc-8.0` as fb0f4cf66f3fc7590821e6688440bf86c25aced1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 2 21:29:56 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Dec 2016 21:29:56 -0000 Subject: [GHC] #9291: Don't reconstruct sum types if the type subtly changes In-Reply-To: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> References: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> Message-ID: <061.74884a6a59d821df5cf6cf9dd8e1b3ad@haskell.org> #9291: Don't reconstruct sum types if the type subtly changes -------------------------------------+------------------------------------- Reporter: schyler | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 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: | -------------------------------------+------------------------------------- Comment (by nomeata): I was considering this problem a bit more today, and my best shot at this so far turned out to be quite similar to what [comment:6 rwbarton] already suggested above. Richard thinks this might be interesting to get right (with type safety proofs and all that). Replying to [comment:13 simonpj]: > I hate the fact that a type-system question forces us to lose a potential optimisation. Me too! Although any solution will likely incur some changes to Core, and that probably needs to be justified by more than the unhappy feeling I have about Core’s type system getting in the way of producing the obviously right code. Does anyone have a practical example where this bug bytes a lot? Maybe something with lenses, or with generic programs? It seems to affect, for example, every `Functor` instance for a sum type where the type parameter is not used in at least one of the branches. Anyways, I started writing down a possible approach with more detail at CaseBinderGeneralisation. Comments welcome. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 2 22:23:03 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Dec 2016 22:23:03 -0000 Subject: [GHC] #12919: Equality not used for substitution Message-ID: <048.c4e450c7b401a6295cbd8b394ff2a079@haskell.org> #12919: Equality not used for substitution -------------------------------------+------------------------------------- Reporter: int-index | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This code {{{ {-# LANGUAGE TypeInType, TypeFamilies, GADTs, ConstraintKinds #-} import Data.Kind data N = Z data V :: N -> Type where VZ :: V Z type family VC (n :: N) :: Type where VC Z = Type type family VF (xs :: V n) (f :: VC n) :: Type where VF VZ f = f data Dict c where Dict :: c => Dict c prop :: xs ~ VZ => Dict (VF xs f ~ f) prop = Dict }}} fails with this error: {{{ Op.hs:20:8: error: • Couldn't match type ‘f’ with ‘VF 'VZ f’ arising from a use of ‘Dict’ ‘f’ is a rigid type variable bound by the type signature for: prop :: forall (xs :: V 'Z) f. xs ~ 'VZ => Dict VF xs f ~ f at Op.hs:19:9 • In the expression: Dict In an equation for ‘prop’: prop = Dict • Relevant bindings include prop :: Dict VF xs f ~ f (bound at Op.hs:20:1) }}} However, if I substitute `xs` with `VZ` (by hand) in the type of `prop`, it compiles. Can be reproduced with GHC 8.0.1 but not HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 2 23:13:00 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Dec 2016 23:13:00 -0000 Subject: [GHC] #12919: Equality not used for substitution In-Reply-To: <048.c4e450c7b401a6295cbd8b394ff2a079@haskell.org> References: <048.c4e450c7b401a6295cbd8b394ff2a079@haskell.org> Message-ID: <063.6ddea2a86417dae25df404126d10e742@haskell.org> #12919: Equality not used for substitution -------------------------------------+------------------------------------- Reporter: int-index | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by int-index): Running the test actually resulted in a Core Lint error: {{{ Compile failed (exit code 1) errors were: *** Core Lint errors : in result of Desugar (after optimization) *** : warning: [in body of lambda with binder $d~_aEs :: (xs :: V 'Z) ~ ('VZ :: V 'Z)] From-type of Cast differs from type of enclosed expression From-type: VC 'Z Type of enclosed expr: Type Actual enclosed expr: f Coercion used in cast: D:R:VC[0] *** Offending Program *** prop :: forall (xs :: V 'Z) f. (xs :: V 'Z) ~ ('VZ :: V 'Z) => Dict (VF xs (f |> Sym (D:R:VC[0])) :: Type) ~ (f :: Type) [LclIdX] prop = \ (@ (xs_aEp :: V 'Z)) (@ f_aEq) ($d~_aEs :: (xs :: V 'Z) ~ ('VZ :: V 'Z)) -> case HEq_sc @ (V 'Z) @ (V 'Z) @ xs @ 'VZ ($p1~ @ (V 'Z) @ xs @ 'VZ $d~_aEs) of cobox_aEM { __DEFAULT -> (Dict @ (f :: Type) ~ (f :: Type) ($f~kab @ * @ f @ f (Eq# @ * @ * @ f @ f @~ (_N :: (f :: Type) ~# (f :: Type))))) `cast` ((Dict ((~) <*>_N (Trans (Sym (D:R:VF[0] (Coh _N (D:R:VC[0])))) (VF <'Z>_N (Sym cobox) (Sym (Coh (Sym (Coh _N _N)) (Sym (D:R:VC[0])))))_N) _N)_R)_R :: (Dict (f :: *) ~ (f :: *) :: *) ~R# (Dict (VF xs (f |> Sym (D:R:VC[0])) :: *) ~ (f :: *) :: *)) } $trModule :: Module [LclIdX] $trModule = Module (TrNameS "main"#) (TrNameS "T12919"#) $tc'Z :: TyCon [LclIdX] $tc'Z = TyCon 4444267892940526647## 16578485670798467485## $trModule (TrNameS "'Z"#) $tcN :: TyCon [LclIdX] $tcN = TyCon 17882793663470508219## 7927123420536316171## $trModule (TrNameS "N"#) $tc'VZ :: TyCon [LclIdX] $tc'VZ = TyCon 17982818364639448466## 3866213651802933295## $trModule (TrNameS "'VZ"#) $tcV :: TyCon [LclIdX] $tcV = TyCon 2444936942366493139## 17118784387149548812## $trModule (TrNameS "V"#) $tc'Dict :: TyCon [LclIdX] $tc'Dict = TyCon 12076319013818359472## 5127630525431558702## $trModule (TrNameS "'Dict"#) $tcDict :: TyCon [LclIdX] $tcDict = TyCon 8038429513029328469## 10238893879637068951## $trModule (TrNameS "Dict"#) *** End of Offense *** }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 2 23:20:52 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Dec 2016 23:20:52 -0000 Subject: [GHC] #9509: No automatic specialization of inlinable imports in 7.8 In-Reply-To: <044.78a0dc81057ff6a68effbbb3815481da@haskell.org> References: <044.78a0dc81057ff6a68effbbb3815481da@haskell.org> Message-ID: <059.17f2d92aba7d3afb86102a9eef7acfcc@haskell.org> #9509: No automatic specialization of inlinable imports in 7.8 -------------------------------------+------------------------------------- Reporter: dolio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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 nfrisby): * cc: nfrisby (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 3 00:34:56 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Dec 2016 00:34:56 -0000 Subject: [GHC] #9509: No automatic specialization of inlinable imports in 7.8 In-Reply-To: <044.78a0dc81057ff6a68effbbb3815481da@haskell.org> References: <044.78a0dc81057ff6a68effbbb3815481da@haskell.org> Message-ID: <059.40cf58ef950349250cdc15e952352d1f@haskell.org> #9509: No automatic specialization of inlinable imports in 7.8 -------------------------------------+------------------------------------- Reporter: dolio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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: | -------------------------------------+------------------------------------- Comment (by nfrisby): With no pragma, {{{foo}}} has the following unfolding and gets inlined. {{{ Unf=Unf{Src=InlineStable, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=0,unsat_ok=True,boring_ok=True) }}} With the {{{INLINABLE}}} pragma, {{{foo}}} has the following unfolding and does not get inlined. {{{ Unf=Unf{Src=InlineStable, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 210 60 }}} In both cases, its RHS is just a cast. I think the inferred {{{IF_ARGS}}} guidance is the cause of this unexpected behavior, because it violates the {{{"Mind you, then 'choose' will be inlined (since RHS is trivial)"}}} assumption in {{{Note [Specialisation shape]}}}, which otherwise anticipated this consequence of the ({{{IO}}}) newtype. https://github.com/ghc/ghc/blob/c36904d66f30d4386a231ce365a056962a881767/compiler/specialise/Specialise.hs#L1607 I did not investigate where the {{{IF_ARGS}}} guidance is coming from for such a trivial declaration. Seems like a leftover from the "actual" RHS (at the newtype's representative type), in this specific example and context. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 3 01:35:34 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Dec 2016 01:35:34 -0000 Subject: [GHC] #12809: TYPE 'UnboxedTupleRep is still a lie In-Reply-To: <047.e76db1a74f10a41a50c71596cd333981@haskell.org> References: <047.e76db1a74f10a41a50c71596cd333981@haskell.org> Message-ID: <062.a3d04de9291ff92041c8309407705f99@haskell.org> #12809: TYPE 'UnboxedTupleRep is still a lie -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by monoidal): Out of curiosity, what about unboxed sums? Is the `TYPE 'UnboxedSumRep` also a lie? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 3 08:26:08 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Dec 2016 08:26:08 -0000 Subject: [GHC] #12915: cmmImplementSwitchPlans creates duplicate blocks In-Reply-To: <048.450627ba0680e3fafd8b0486acc85c67@haskell.org> References: <048.450627ba0680e3fafd8b0486acc85c67@haskell.org> Message-ID: <063.c5765bab0af2cdaf443fca0d94b56f12@haskell.org> #12915: cmmImplementSwitchPlans creates duplicate blocks -------------------------------------+------------------------------------- Reporter: alexbiehl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alexbiehl): Ah, it is not `cmmImplementSwitchPlans` directly! After `cmmSwitchPlans` it is still {{{ cfzc: _sfh3::P64 = R1; _cfB7::I64 = %MO_UU_Conv_W32_W64(I32[I64[_sfh3::P64 - 1] - 4]); if (_cfB7::I64 < 5) goto ufBe; else goto ufBg; ufBe: if (_cfB7::I64 < 4) goto ufBf; else goto cfAV; ufBf: if (_cfB7::I64 != 2) goto cfAC; else goto cfAR; cfAR: _sfh4::I64 = I64[_sfh3::P64 + 7]; _sfgp::I64 = 1; goto sfgo; cfAV: _sfh5::I64 = I64[_sfh3::P64 + 7]; _sfgp::I64 = 1; goto sfgo; ufBg: if (_cfB7::I64 != 6) goto cfAC; else goto cfAZ; cfAZ: _sfh6::I64 = I64[_sfh3::P64 + 7]; _sfgp::I64 = 1; goto sfgo; sfgo: }}} `_sfh4`, `_sfh5`, `_sfh6` are dead. The sinking pass eliminates those and we end up with duplicate blocks! This code is part of an inner loop which just counts the occurrence of certain constructors. Here is the core for the mentioned loop: {{{#!hs letrec { $sloop :: State# RealWorld -> Int# -> (# State# RealWorld, Either Error Int #) $sloop = \ (sc :: State# RealWorld) (sc1 :: Int#) -> case (ww `cast` ...) sc of _ { (# ipv, ipv1 #) -> case ipv1 of _ { Nothing -> (# ipv, Right (I# sc1) #); Just a -> case length $fVectorVectora a of _ { I# y -> case y of _ { __DEFAULT -> (# ipv, empResult2 #); 4# -> case a of _ { Vector dt dt1 dt2 -> let { $wsucc_ :: Int# -> State# RealWorld -> (# State# RealWorld, Either Error Int #) $wsucc_ = \ (ww1 :: Int#) (w1 :: State# RealWorld) -> let { $wsucc_1 :: Int# -> State# RealWorld -> (# State# RealWorld, Either Error Int #) $wsucc_1 = \ (ww2 :: Int#) (w2 :: State# RealWorld) -> case indexArray# dt2 (+# dt ww2) of _ { (# ipv2 #) -> case ipv2 of _ { __DEFAULT -> (# w2, empResult2 #); CV_Int8 dt4 -> case indexArray# dt2 (+# dt (+# ww2 1#)) of _ { (# ipv3 #) -> case ipv3 of _ { __DEFAULT -> (# w2, empResult2 #); CV_Text t -> $sloop w2 (+# sc1 1#) } }; CV_Int16 dt4 -> case indexArray# dt2 (+# dt (+# ww2 1#)) of _ { (# ipv3 #) -> case ipv3 of _ { __DEFAULT -> (# w2, empResult2 #); CV_Text t -> $sloop w2 (+# sc1 1#) } }; CV_Int32 dt4 -> case indexArray# dt2 (+# dt (+# ww2 1#)) of _ { (# ipv3 #) -> case ipv3 of _ { __DEFAULT -> (# w2, empResult2 #); CV_Text t -> $sloop w2 (+# sc1 1#) } } } } } in case indexArray# dt2 (+# dt ww1) of _ { (# ipv2 #) -> case ipv2 of _ { __DEFAULT -> (# w1, empResult2 #); CV_Int8 dt4 -> $wsucc_1 (+# ww1 1#) w1; CV_Int16 dt4 -> $wsucc_1 (+# ww1 1#) w1; CV_Int32 dt4 -> $wsucc_1 (+# ww1 1#) w1 } } } in case indexArray# dt2 dt of _ { (# ipv2 #) -> case ipv2 of _ { __DEFAULT -> (# ipv, empResult2 #); CV_Int8 dt4 -> $wsucc_ 1# ipv; CV_Int16 dt4 -> $wsucc_ 1# ipv; CV_Int32 dt4 -> $wsucc_ 1# ipv } } } } } }}} You can see a minimized example of the original code here: https://gist.github.com/alexbiehl/0a1b5016223e00ae79a1399176e14eef -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 3 14:29:20 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Dec 2016 14:29:20 -0000 Subject: [GHC] #12915: cmmImplementSwitchPlans creates duplicate blocks In-Reply-To: <048.450627ba0680e3fafd8b0486acc85c67@haskell.org> References: <048.450627ba0680e3fafd8b0486acc85c67@haskell.org> Message-ID: <063.f787aeb4e1f600b7a3d2fb3f7be4b7dc@haskell.org> #12915: cmmImplementSwitchPlans creates duplicate blocks -------------------------------------+------------------------------------- Reporter: alexbiehl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Just guessing here, but we should probably not run sinking earlier, before `layoutStack`. We could run `elimCommonBlocks` again later, but that might be expensive and not very often kick in. Maybe with `-O2`? My gut feeling is that this comes up rather rarely. If someone wants to find evidence to the contrary: Add a late `elimCommonBlocks` pass, dump number of blocks before and after, run `nofib` and see how often it fires. Or (easier) report the change in code size. There is probably no obvious way of avoiding to generate these dead assignments in the first place? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 3 14:58:17 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Dec 2016 14:58:17 -0000 Subject: [GHC] #12920: Overzealous unused-top-binds Message-ID: <047.901081a81082358202634643f971c0b9@haskell.org> #12920: Overzealous unused-top-binds -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following example produces three warnings: {{{ module Foo () where type A = Int type B = A foo :: IO () foo = print (bar 3 :: B) bar :: a -> a bar = id }}} `ghci Foo -Wall` produces {{{ GHCi, version 8.0.1.20161117: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Foo ( Foo.hs, interpreted ) Foo.hs:5:1: warning: [-Wunused-top-binds] Defined but not used: type constructor or class ‘B’ Foo.hs:8:1: warning: [-Wunused-top-binds] Defined but not used: ‘foo’ Foo.hs:11:1: warning: [-Wunused-top-binds] Defined but not used: ‘bar’ Ok, modules loaded: Foo. }}} The three errors reported are inconsistent because GHC reports that `B` is unused, but somehow feels that `A` *is* used. It seems to me that two possibilities could work: 1. GHC reports 1 error: GHC should only report that `foo` is unused, since `A` is used in `B`, `B` is used in `foo`, and `bar` is used in `foo`. This seems like the best approach to me. 2. GHC reports 4 errors: One might choose to apply the definition of "unused" transitively so that, since `foo` is unused, everything used in `foo` is considered unused (unless "used" elsewhere). In this case, `A` should also be reported as unused, but it currently isn't. This definition would be exceedingly useful for removing dead code, but it also produces very noisy output when there is a lot of dead code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 3 14:58:22 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Dec 2016 14:58:22 -0000 Subject: [GHC] #12906: GHC fails to typecheck Main module without main In-Reply-To: <045.9f131820c17fbe502671d27a0102f251@haskell.org> References: <045.9f131820c17fbe502671d27a0102f251@haskell.org> Message-ID: <060.1ff7e2d6681827aee1f0bd38c207bf3f@haskell.org> #12906: GHC fails to typecheck Main module without main -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): I tried this module using 8.0, 7.10 and 7.8 and they all failed with the same error message: {{{#!haskell module Main where x :: String -> String x s = print (reverse s + 1) }}} {{{ > t12906 /home/omer/ghc_bins/ghc-8.0.1/bin/ghc test [1 of 1] Compiling Main ( test.hs, test.o ) test.hs:1:1: error: The IO action ‘main’ is not defined in module ‘Main’ > t12906 /home/omer/ghc_bins/ghc-7.10.1/bin/ghc test [1 of 1] Compiling Main ( test.hs, test.o ) test.hs:1:1: The IO action ‘main’ is not defined in module ‘Main’ > t12906 /home/omer/ghc_bins/ghc-7.8.1/bin/ghc test [1 of 1] Compiling Main ( test.hs, test.o ) test.hs:1:1: The IO action ‘main’ is not defined in module ‘Main’ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 3 16:17:49 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Dec 2016 16:17:49 -0000 Subject: [GHC] #12921: initTc: unsolved constraints Message-ID: <042.c3b03f98e30de2e2cd01ee79787ef3cf@haskell.org> #12921: initTc: unsolved constraints -------------------------------------+------------------------------------- Reporter: jlp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: | Operating System: MacOS X Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While working on a small project of mine, GHC panicked with the following error: {{{ lua-types-0.1.0.0: build Preprocessing executable 'lua-types' for lua-types-0.1.0.0... [2 of 3] Compiling Lua.Parser ( src/Lua/Parser.hs, .stack- work/dist/x86_64-osx/Cabal-1.24.1.0/build/lua-types/lua-types- tmp/Lua/Parser.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.1.20161117 for x86_64-apple-darwin): initTc: unsolved constraints WC {wc_insol = [W] explist_a3nf :: t_a3ne[tau:1] (CHoleCan: explist) [W] funccall_a4dv :: t_a4du[tau:1] (CHoleCan: funccall)} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} From a quick google search, it seems like this is a bug in the type checker. I'm not willing nor able to dive any further into the GHC code myself, though. I'll attach the code as it is, before looking for a workaround. I'm using stack, GHC version 8.0.1.20161117 for x86_64-apple-darwin. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 3 16:22:12 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Dec 2016 16:22:12 -0000 Subject: [GHC] #12921: initTc: unsolved constraints In-Reply-To: <042.c3b03f98e30de2e2cd01ee79787ef3cf@haskell.org> References: <042.c3b03f98e30de2e2cd01ee79787ef3cf@haskell.org> Message-ID: <057.a3175b08d76ca9d729f66e3e11202c39@haskell.org> #12921: initTc: unsolved constraints -------------------------------------+------------------------------------- Reporter: jlp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by jlp): * Attachment "GHCticket12921.tar.gz" added. Bug-producing project folder -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 3 18:20:21 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Dec 2016 18:20:21 -0000 Subject: [GHC] #11138: Kill the terrible LLVM Mangler In-Reply-To: <046.1671c4fce95e0eb48491b5a743b485ce@haskell.org> References: <046.1671c4fce95e0eb48491b5a743b485ce@haskell.org> Message-ID: <061.043b9166ae4a75dc173e0a4696e568ad@haskell.org> #11138: Kill the terrible LLVM Mangler -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dobenour): LLVM 3.8 (and presumably later) has the `-stack-alignment` option, which we could use. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 3 23:27:12 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Dec 2016 23:27:12 -0000 Subject: [GHC] #12922: Kind classes compile with PolyKinds Message-ID: <045.cda8d73aa7f5c75c71cb112094b7aabc@haskell.org> #12922: Kind classes compile with PolyKinds -------------------------------------+------------------------------------- Reporter: Tritlo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I was asking around on #haskell to better understand the new language extension, -XTypeInType, and how it is different from -XPolyKinds. To study it, I was working with the following small example: {{{ {-# LANGUAGE TypeFamilies, GADTs, TypeOperators, DataKinds, PolyKinds #-} module Main where import Data.Kind (Type) -- Define a Type for the natural numbers, Zero and a successor data Nat = Z | S Nat class Addable k where type (a :: k) + (b :: k) :: k instance Addable Nat where type (Z + a) = a }}} (for more context, see https://gist.github.com/Tritlo/ce5510e80935ac398a33934ee47c7930) Since according to a responder on #haskell, the ability to have kind classes required TypeInType, and should not work with PolyKinds. As the documentation mentions that there could be leakage between PolyKinds and TypeInType and to report such leaks, I felt that I should report it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 4 01:05:51 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Dec 2016 01:05:51 -0000 Subject: [GHC] #12922: Kind classes compile with PolyKinds In-Reply-To: <045.cda8d73aa7f5c75c71cb112094b7aabc@haskell.org> References: <045.cda8d73aa7f5c75c71cb112094b7aabc@haskell.org> Message-ID: <060.4bc5132d9eef754983182e9a2bdb3b13@haskell.org> #12922: Kind classes compile with PolyKinds -------------------------------------+------------------------------------- Reporter: Tritlo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Tritlo: @@ -20,0 +20,1 @@ + type (S a) + b = S (a + b) New description: I was asking around on #haskell to better understand the new language extension, -XTypeInType, and how it is different from -XPolyKinds. To study it, I was working with the following small example: {{{ {-# LANGUAGE TypeFamilies, GADTs, TypeOperators, DataKinds, PolyKinds #-} module Main where import Data.Kind (Type) -- Define a Type for the natural numbers, Zero and a successor data Nat = Z | S Nat class Addable k where type (a :: k) + (b :: k) :: k instance Addable Nat where type (Z + a) = a type (S a) + b = S (a + b) }}} (for more context, see https://gist.github.com/Tritlo/ce5510e80935ac398a33934ee47c7930) Since according to a responder on #haskell, the ability to have kind classes required TypeInType, and should not work with PolyKinds. As the documentation mentions that there could be leakage between PolyKinds and TypeInType and to report such leaks, I felt that I should report it. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 4 01:06:19 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Dec 2016 01:06:19 -0000 Subject: [GHC] #12922: Kind classes compile with PolyKinds In-Reply-To: <045.cda8d73aa7f5c75c71cb112094b7aabc@haskell.org> References: <045.cda8d73aa7f5c75c71cb112094b7aabc@haskell.org> Message-ID: <060.83d43d3eb9632c0e8e6c8bf763704a3a@haskell.org> #12922: Kind classes compile with PolyKinds -------------------------------------+------------------------------------- Reporter: Tritlo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Tritlo: @@ -20,1 +20,1 @@ - type (S a) + b = S (a + b) + type (S a) + b = S (a + b) New description: I was asking around on #haskell to better understand the new language extension, -XTypeInType, and how it is different from -XPolyKinds. To study it, I was working with the following small example: {{{ {-# LANGUAGE TypeFamilies, GADTs, TypeOperators, DataKinds, PolyKinds #-} module Main where import Data.Kind (Type) -- Define a Type for the natural numbers, Zero and a successor data Nat = Z | S Nat class Addable k where type (a :: k) + (b :: k) :: k instance Addable Nat where type (Z + a) = a type (S a) + b = S (a + b) }}} (for more context, see https://gist.github.com/Tritlo/ce5510e80935ac398a33934ee47c7930) Since according to a responder on #haskell, the ability to have kind classes required TypeInType, and should not work with PolyKinds. As the documentation mentions that there could be leakage between PolyKinds and TypeInType and to report such leaks, I felt that I should report it. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 4 07:03:39 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Dec 2016 07:03:39 -0000 Subject: [GHC] #12899: ghc panics at random places with -jX In-Reply-To: <044.e06c34ff950f64285fd655be98faab7e@haskell.org> References: <044.e06c34ff950f64285fd655be98faab7e@haskell.org> Message-ID: <059.bc6dd36338a24a6532a33909e4b8453b@haskell.org> #12899: ghc panics at random places with -jX -------------------------------------+------------------------------------- Reporter: pacak | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by pacak): {{{ : error: ghc: panic! (the 'impossible' happened) (GHC version 8.1.20161202 for x86_64-unknown-linux): ASSERT failed! in_scope InScope {wild_00 eta_Xb8 ds4_azye z_azyh s7_azyl ds5_azyr wild5_azBv v3_azBx i_azBy wild7_azBI x_azBP y_azCG wild9_azCK wild_a2Buo x_a2Bux xs1_a2BuC wild_azHBp dt_azHBx ds1_azHBz ds2_azHBA ds3_azHBB $c==_aCmLf $c/=_aCmLs $cshowsPrec_aCmLH $cshow_aCmMu $cshowList_aCmME $cshowsPrec_aCn9Q $cshow_aCnbg $cshowList_aCnbs $cbasicUnsafeFreeze_aCnbK $cbasicUnsafeThaw_aCncb $cbasicLength_aCncD $cbasicUnsafeSlice_aCncL $cbasicUnsafeIndexM_aCncX $cbasicUnsafeCopy_aCndC $celemseq_aCndV $cbasicLength_aCneq $cbasicUnsafeSlice_aCneE $cbasicOverlaps_aCneW $cbasicUnsafeNew_aCnfa $cbasicInitialize_aCnfz $cbasicUnsafeReplicate_aCnfQ $cbasicUnsafeRead_aCngr $cbasicUnsafeWrite_aCnhc $cbasicClear_aCnhG $cbasicSet_aCnhZ $cbasicUnsafeCopy_aCnix $cbasicUnsafeMove_aCniW $cbasicUnsafeGrow_aCnjj $dVector_aCnST $cbasicUnsafeFreeze_aCogp $cbasicUnsafeThaw_aCogP $cbasicLength_aCohe $cbasicUnsafeSlice_aCohm $cbasicUnsafeIndexM_aCohw $cbasicUnsafeCopy_aCoi7 $celemseq_aCois $cbasicLength_aCoj5 $cbasicUnsafeSlice_aCojo $cbasicOverlaps_aCojH $cbasicUnsafeNew_aCojY $cbasicInitialize_aCokp $cbasicUnsafeReplicate_aCokL $cbasicUnsafeRead_aColG $cbasicUnsafeWrite_aComl $cbasicClear_aCon3 $cbasicSet_aConq $cbasicUnsafeCopy_aCooe $cbasicUnsafeMove_aCooD $cbasicUnsafeGrow_aCop0 xs_aCqkO ibaInst ibaBid ibaAsk $tc'IBA $tcInstBidAsk $fEqInstBidAsk $fShowInstBidAsk ibaAsk_ ibaBid_ ibaInst_ ibaBary makeOTMSpreads useMaxQty otmSampleAndWeight evalInstFitness $fVectorVectorInstBidAsk $fMVectorMVectorInstBidAsk $fUnboxInstBidAsk $tc'InstFitnessFunction $tcInstFitnessFunction $fShowInstFitnessFunction mkInstFitnessFunction fitnessFunction evalFitnessFunction modifyFitnessFunctionForSpotChange calcFitness calcDeltaVector td_now td_inst unitTests $fVectorVectorInstFitnessFunction $fMVectorMVectorInstFitnessFunction $fUnboxInstFitnessFunction $trModule $cbasicUnsafeSlice_sCqRU $cbasicUnsafeSlice_sCqXB $cbasicUnsafeSlice_sCryL $cbasicUnsafeSlice_sCrJw $trModule_sCrSA $trModule_sCrSB $tc'IBA_sCrSD $tcInstBidAsk_sCrSE $tc'InstFitnessFunction_sCrSF $tcInstFitnessFunction_sCrSH $cshowList_sCrTr $cshowList_sCrTH $cbasicUnsafeThaw_sCueJ $cbasicUnsafeThaw_sCuEw $dVector_sCvzg $dUnbox_sCvzh $sunzip_sCvHL $snew_sCvHV $sunstream_sCvI0 $sunstream_sCvID $szipWithM_sCvJj $slift_sCvJo $sstream_sCvJv $sconsume_sCvJE $s$fVectorVector(,)_$cbasicUnsafeFreeze_sCvJS $s$fVectorVector(,)_$cbasicUnsafeThaw_sCvK1 $s$fVectorVector(,)_$cbasicUnsafeIndexM_sCvKg $s$fVectorVector(,)_$celemseq_sCvKs $s$fMVectorMVector(,)_$cbasicUnsafeNew_sCvKV $s$fMVectorMVector(,)_$cbasicUnsafeReplicate_sCvL9 $s$fMVectorMVector(,)_$cbasicUnsafeRead_sCvLh $s$fMVectorMVector(,)_$cbasicUnsafeGrow_sCvLH $slength_sCvLX $sfilter_sCvM5 $simap_sCvMq $simap_sCvMw $sunstream_sCvME $sstream_sCvNg $ssum_sCvNx $sfoldlM'_sCvNF $sstream_sCvNL $szipWith_sCvNX $szipWithM_sCvO8 $sstream_sCvOi $sstream_sCvOu $sunstream_sCvOI $snew_sCvPg $stoNum_sCvPk $smergeWithKey_sCvPv $sfromList_sCvQX $sunstreamR_sCvVf $sstreamR_sCvWB $snull_sCvWZ $s$dmshow_sCvX6 $sshows_sCvXa $slookup_sCvXm $slift_sCvXv $smapM_sCvXE $sunstreamM_sCvXK $s$fVectorVector(,)_$cbasicUnsafeFreeze_sCvYt $s$fVectorVector(,)_$cbasicUnsafeThaw_sCvYE $s$fVectorVector(,)_$cbasicUnsafeIndexM_sCvYV $s$fVectorVector(,)_$celemseq_sCvZ5 $s$fVectorVector(,,)_$cbasicUnsafeFreeze_sCvZh $s$fVectorVector(,,)_$cbasicUnsafeThaw_sCvZt $s$fVectorVector(,,)_$cbasicUnsafeIndexM_sCvZR $s$fVectorVector(,,)_$cbasicUnsafeCopy_sCw00 $s$fVectorVector(,,)_$celemseq_sCw09 $s$fMVectorMVector(,,)_$cbasicUnsafeNew_sCw0E $s$fMVectorMVector(,,)_$cbasicInitialize_sCw0Q $s$fMVectorMVector(,,)_$cbasicUnsafeReplicate_sCw0Z $s$fMVectorMVector(,,)_$cbasicUnsafeRead_sCw1c $s$fMVectorMVector(,,)_$cbasicUnsafeWrite_sCw1p $s$fMVectorMVector(,,)_$cbasicClear_sCw1y $s$fMVectorMVector(,,)_$cbasicSet_sCw1H $s$fMVectorMVector(,,)_$cbasicUnsafeCopy_sCw1P $s$fMVectorMVector(,,)_$cbasicUnsafeMove_sCw1W $s$fMVectorMVector(,,)_$cbasicUnsafeGrow_sCw27 $s$fVectorVector(,,,)_$cbasicUnsafeFreeze_sCw2m $s$fVectorVector(,,,)_$cbasicUnsafeThaw_sCw2D $s$fVectorVector(,,,)_$cbasicUnsafeIndexM_sCw34 $s$fVectorVector(,,,)_$cbasicUnsafeCopy_sCw3i $s$fVectorVector(,,,)_$celemseq_sCw3t $s$fMVectorMVector(,,,)_$cbasicUnsafeNew_sCw42 $s$fMVectorMVector(,,,)_$cbasicInitialize_sCw4j $s$fMVectorMVector(,,,)_$cbasicUnsafeReplicate_sCw4s $s$fMVectorMVector(,,,)_$cbasicUnsafeRead_sCw4G $s$fMVectorMVector(,,,)_$cbasicUnsafeWrite_sCw4W $s$fMVectorMVector(,,,)_$cbasicClear_sCw55 $s$fMVectorMVector(,,,)_$cbasicSet_sCw5f $s$fMVectorMVector(,,,)_$cbasicUnsafeCopy_sCw5r $s$fMVectorMVector(,,,)_$cbasicUnsafeMove_sCw5B $s$fMVectorMVector(,,,)_$cbasicUnsafeGrow_sCw5K $s$fMVectorMVector(,,,)_$cbasicOverlaps_sCw5Z $s$fMVectorMVector(,,,)_$cbasicUnsafeSlice_sCw60 $s$fMVectorMVector(,,,)_$cbasicLength_sCw61 $s$fVectorVector(,,,)_$cbasicUnsafeSlice_sCw62 $s$fVectorVector(,,,)_$cbasicLength_sCw63 $s$fMVectorMVector(,,)_$cbasicOverlaps_sCw65 $s$fMVectorMVector(,,)_$cbasicUnsafeSlice_sCw66 $s$fMVectorMVector(,,)_$cbasicLength_sCw67 $s$fVectorVector(,,)_$cbasicUnsafeSlice_sCw69 $s$fVectorVector(,,)_$cbasicLength_sCw6a $s$fVectorVector(,)_sCw6b $s$fVectorVector(,)_$cbasicUnsafeCopy_sCw6c $s$fVectorVector(,)_$cbasicUnsafeSlice_sCw6d $s$fVectorVector(,)_$cbasicLength_sCw6e $smapM_sCw6f $s=<<_sCw6h $s$fEq(,)_$c==_sCw6i $s$fShow(,)_$cshowsPrec_sCw6j $s$dmshow_sCw6k $sshows_sCw6l $snull_sCw6m $sscanl1'_sCw6n $sscanr1'_sCw6o $sfromList_sCw6p $sbyEq_sCw6q $stoNum_sCw6r $szipWith_sCw6s $s!?_sCw6u $snew_sCw6v $slength_sCw6w $sapproxEq_sCw6x $s$fUnbox(,)_sCw6y $s$fMVectorMVector(,)_sCw6z $s$fMVectorMVector(,)_$cbasicUnsafeMove_sCw6A $s$fMVectorMVector(,)_$cbasicUnsafeCopy_sCw6B $s$fMVectorMVector(,)_$cbasicSet_sCw6C $s$fMVectorMVector(,)_$cbasicClear_sCw6D $s$fMVectorMVector(,)_$cbasicUnsafeWrite_sCw6E $s$fMVectorMVector(,)_$cbasicInitialize_sCw6G $s$fMVectorMVector(,)_$cbasicOverlaps_sCw6H $s$fMVectorMVector(,)_$cbasicUnsafeSlice_sCw6I $s$fMVectorMVector(,)_$cbasicLength_sCw6J $s$fVectorVector(,)_sCw6K $s$fVectorVector(,)_$cbasicUnsafeCopy_sCw6L $s$fVectorVector(,)_$cbasicUnsafeSlice_sCw6M $s$fVectorVector(,)_$cbasicLength_sCw6N $szipWithM__sCw6P $snew_sCw6Q lvl_sCw72 lvl_sCw76 lvl_sCw7c lvl_sCw7h lvl_sCw7r lvl_sCw7C lvl_sCw7I lvl_sCw7O lvl_sCw7R lvl_sCw7Z lvl_sCw88 lvl_sCwn8 lvl_sCwuy lvl_sCwyz ipv1_sCwzG lvl_sCx2j lvl_sCx2I $stoNum_sCACQ $ssum_sCBcu $slength_sCOwz $snull_sCRhQ lvl_sCRwH lvl_sCSUV evalFitnessFunction_sCTgx ds_sCTtG ~~~_sCTtR $sconsume_sCWPn foldlM_loop_sCYyL unitTests_sDkwU unitTests_sDkwV unitTests_sDkxV unitTests_sDkxW unitTests_sDkxX unitTests_sDkxY unitTests_sDkxZ unitTests_sDky0 unitTests_sDky2 unitTests_sDky3 unitTests_sDkya unitTests_sDkyb unitTests_sDkyc unitTests_sDkye unitTests_sDkyf unitTests_sDkyh unitTests_sDkyi unitTests_sDkyj unitTests_sDkyl unitTests_sDkym unitTests_sDkyp unitTests_sDkyq unitTests_sDkyr unitTests_sDkyt unitTests_sDkyu unitTests_sDkyx unitTests_sDkyy unitTests_sDkyz unitTests_sDkyC unitTests_sDkyD unitTests_sDkyG unitTests_sDkyH unitTests_sDkyI unitTests_sDkyK unitTests_sDkyL unitTests_sDkyN unitTests_sDkyO unitTests_sDkyP unitTests_sDkyR unitTests_sDkyS unitTests_sDkyU unitTests_sDkyW unitTests_sDkyX unitTests_sDkyZ unitTests_sDkz0 unitTests_sDkz4 unitTests_sDkz5 unitTests_sDkz6 unitTests_sDkz8 unitTests_sDkza unitTests_sDkze unitTests_sDkzf unitTests_sDkzg unitTests_sDkzi unitTests_sDkzj unitTests_sDkzn unitTests_sDkzo unitTests_sDkzp unitTests_sDkzs unitTests_sDkzt unitTests_sDkzy unitTests_sDkzz unitTests_sDkzA unitTests_sDkzD unitTests_sDkzE unitTests_sDkzG unitTests_sDkzH unitTests_sDkzI unitTests_sDkzK unitTests_sDkzL unitTests_sDkzO unitTests_sDkzP unitTests_sDkzQ unitTests_sDkzT unitTests_sDkzU unitTests_sDkzW unitTests_sDkzY unitTests_sDkzZ unitTests_sDkA6 unitTests_sDkA7 unitTests_sDkA8 $szipWithM__sDm6V unitTests_sDoQH $j_sDylm $wotmSampleAndWeight_sE07u $w$c==_sE08Z $wtoOrdinal1_sE09E $wfromOrd2_sE0a3 $w$cshowsPrec_sE0aB $w$cshowsPrec_sE0aZ $wcalcDeltaVector_sE0pa $wuseMaxQty_sE0qL $w$ssum_sE0UI lvl_sEhjh lvl_sEhjC lvl_sEhkq lvl_sEhkr lvl_sEhks lvl_sEhku lvl_sEhkG lvl_sEhkH $wtoDiff2_sEhkJ lvl_sEhkK lvl_sEhkL lvl_sEhkM lvl_sEhle lvl_sEhlf lvl_sEhlg lvl_sEhlh lvl_sEhly lvl_sEhlz lvl_sEhlA lvl_sEhlB lvl_sEhwT lvl_sEhwU lvl_sEhwV lvl_sEhwW lvl_sEhwX lvl_sEhwY lvl_sEhx0 lvl_sEhx1 lvl_sEhx2 lvl_sEhx3 lvl_sEhx8 lvl_sEhx9 lvl_sEhxc lvl_sEhxd lvl_sEhxe lvl_sEhxf lvl_sEhFI lvl_sEhFU foldlM_loop_sEhGN wild_sEhH7 dt_sEhH8 dt1_sEhH9 dt2_sEhHa wild_sEhHc dt_sEhHd dt1_sEhHe dt2_sEhHf wild_sEhHh dt_sEhHi dt1_sEhHj dt2_sEhHk lvl_sEhJh lvl_sEhJi lvl_sEhJj lvl_sEhJk lvl_sEhN8 lvl_sEhNk lvl_sEhNx lvl_sEhNI lvl_sEhOD foldlM_loop_sEhRb go2_sEhTm go2_sEhTo lvl_sEhTt lvl_sEhTw merge_sEhUl lvl_sEhV5 merge_sEhVc $j_sEhWi lvl_sEi3O lvl_sEi41 lvl_sEiwB lvl_sEiwN lvl_sEiNk lvl_sEiNy lvl_sEiWh lvl_sEiX4 lvl_sEiX5 lvl_sEiX6 poly_$j_sEj1Y lvl_sEj20 foldlM_loop_sEj3j foldlM_loop_sEjal lvl_sEjdN lvl_sEjdO lvl_sEjdR lvl_sEjdT lvl_sEjdU lvl_sEjdY lvl_sEje3 lvl_sEje4 lvl_sEje7 lvl_sEjeb lvl_sEjed lvl_sEjee lvl_sEjei lvl_sEjel lvl_sEjem lvl_sEjen lvl_sEjeo lvl_sEjes lvl_sEjet lvl_sEjev lvl_sEjex lvl_sEjey lvl_sEjeC lvl_sEjeD lvl_sEjeG lvl_sEjeH lvl_sEjeI lvl_sEjeS lvl_sEjeT lvl_sEjf2 lvl_sEjf3 lvl_sEjfd lvl_sEjfe lvl_sEjfh lvl_sEjfm lvl_sEjfn lvl_sEjfq lvl_sEjfv lvl_sEjfw lvl_sEjfz lvl_sEjfC lvl_sEjfE lvl_sEjfF lvl_sEjfI lvl_sEjfN lvl_sEjfO lvl_sEjfY lvl_sEjfZ lvl_sEjg8 lvl_sEjg9 lvl_sEjgb lvl_sEjgc lvl_sEjgd lvl_sEjge lvl_sEjgf lvl_sEjgg lvl_sEjgh lvl_sEjgi lvl_sEjgj lvl_sEjgk lvl_sEjgl lvl_sEjgm lvl_sEjgn lvl_sEjgo lvl_sEjgp lvl_sEjh7 loc_sEjj2 loc_sEjj4 loc_sEjja loc_sEjjc loc_sEjje $dIP_sEjjg $dIP_sEjji $dIP_sEjjk lvl_sEjjX lvl_sEjjY lvl_sEjk7 lvl_sEjk9 lvl_sEjka lvl_sEjkb lvl_sEjkc lvl_sEjki lvl_sEjkj lvl_sEjkk lvl_sEjkl lvl_sEjkn lvl_sEjko lvl_sEjkp lvl_sEjkq lvl_sEjmW lvl_sEjmX lvl_sEjmY lvl_sEjmZ lvl_sEjnR lvl_sEjnS lvl_sEjnT lvl_sEjnU lvl_sEjnZ lvl_sEjo0 lvl_sEjo1 lvl_sEjo2 lvl_sEjo8 lvl_sEjo9 lvl_sEjoa lvl_sEjob lvl_sEjoh lvl_sEjoi lvl_sEjoj lvl_sEjok lvl_sEjor lvl_sEjos lvl_sEjot lvl_sEjou lvl_sEjox lvl_sEjoy lvl_sEjoz lvl_sEjoA lvl_sEjoM lvl_sEjoN lvl_sEjoO lvl_sEjoP $sfoldlM_loop_sEwVd $sgo2_sExlJ $sgo2_sExlL $smerge_sExnj $smerge_sExnm $smerge_sExo8 $smerge_sExon sc_sExtw sc_sExtx sc_sExty $s$j_sExtS} tenv [] tenvFVs [] cenv [sExtz :-> sg_sExtz] cenvFVs [sExtz :-> sg_sExtz] tys [PrimState (ST RealWorld)] cos [] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1114:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1163:22 in ghc:Outputable assertPprPanic, called at compiler/types/TyCoRep.hs:2023:56 in ghc:TyCoRep checkValidSubst, called at compiler/types/TyCoRep.hs:2056:17 in ghc:TyCoRep substTy, called at compiler/types/Coercion.hs:1457:33 in ghc:Coercion Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1114:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1118:37 in ghc:Outputable pprPanic, called at compiler/utils/Outputable.hs:1161:5 in ghc:Outputable assertPprPanic, called at compiler/types/TyCoRep.hs:2023:56 in ghc:TyCoRep checkValidSubst, called at compiler/types/TyCoRep.hs:2056:17 in ghc:TyCoRep substTy, called at compiler/types/Coercion.hs:1457:33 in ghc:Coercion Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 4 08:04:27 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Dec 2016 08:04:27 -0000 Subject: [GHC] #12923: MultiParamTypeClasses + ExtendedDefaultRules Message-ID: <046.9ae3ec8e366c95f2b64ecec80ccef95a@haskell.org> #12923: MultiParamTypeClasses + ExtendedDefaultRules -------------------------------------+------------------------------------- Reporter: amindfv | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- -XExtendedDefaultRules allows us to avoid ambiguity for unannotated numeric literals: {{{#!hs {-# LANGUAGE ExtendedDefaultRules #-} data A = A deriving Show class ToA a where toA :: a -> A instance ToA Double where toA _ = A main = print (toA 5 :: A) }}} But if we have a multi-param typeclass, -XExtendedDefaultRules doesn't help us: {{{#!hs {-# LANGUAGE ExtendedDefaultRules #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE FlexibleInstances #-} data A x = A deriving Show class ToA a x where toA :: a -> A x instance ToA Double x where toA _ = A main = print (toA 5 :: A Bool) }}} It would be really nice for an EDSL I'm working on to be able to use extended defaults here! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 4 08:05:52 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Dec 2016 08:05:52 -0000 Subject: [GHC] #12923: MultiParamTypeClasses + ExtendedDefaultRules In-Reply-To: <046.9ae3ec8e366c95f2b64ecec80ccef95a@haskell.org> References: <046.9ae3ec8e366c95f2b64ecec80ccef95a@haskell.org> Message-ID: <061.3cae4a7cd9950ce955382543a25d3db0@haskell.org> #12923: MultiParamTypeClasses + ExtendedDefaultRules -------------------------------------+------------------------------------- Reporter: amindfv | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by amindfv: @@ -44,2 +44,3 @@ - It would be really nice for an EDSL I'm working on to be able to use - extended defaults here! + It would be really nice for an EDSL of mine to be able to use extended + defaults here! At the moment my only option has been to use incoherent + instances, which has resulted in incoherent behavior... New description: -XExtendedDefaultRules allows us to avoid ambiguity for unannotated numeric literals: {{{#!hs {-# LANGUAGE ExtendedDefaultRules #-} data A = A deriving Show class ToA a where toA :: a -> A instance ToA Double where toA _ = A main = print (toA 5 :: A) }}} But if we have a multi-param typeclass, -XExtendedDefaultRules doesn't help us: {{{#!hs {-# LANGUAGE ExtendedDefaultRules #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE FlexibleInstances #-} data A x = A deriving Show class ToA a x where toA :: a -> A x instance ToA Double x where toA _ = A main = print (toA 5 :: A Bool) }}} It would be really nice for an EDSL of mine to be able to use extended defaults here! At the moment my only option has been to use incoherent instances, which has resulted in incoherent behavior... -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 4 15:42:45 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Dec 2016 15:42:45 -0000 Subject: [GHC] #12924: Pattern Synonyms in Typeclasses Message-ID: <043.a66a4c7059b80a3d08e25273aaaf35d0@haskell.org> #12924: Pattern Synonyms in Typeclasses -------------------------------------+------------------------------------- Reporter: xcmw | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: pattern | Operating System: Unknown/Multiple synonym type class | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs data A t where AX :: A X AY :: A Y AZ :: A Z class HasX a where data pattern X :: a X instance HasX A where data pattern X = AX d :: A t -> String d = \case X -> "" AY -> "" AZ -> "" }}} The above example should compile and emit no warnings with -fwarn- incomplete-patterns. Would require https://ghc.haskell.org/trac/ghc/ticket/8779 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 4 16:02:45 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Dec 2016 16:02:45 -0000 Subject: [GHC] #12924: Pattern Synonyms in Typeclasses In-Reply-To: <043.a66a4c7059b80a3d08e25273aaaf35d0@haskell.org> References: <043.a66a4c7059b80a3d08e25273aaaf35d0@haskell.org> Message-ID: <058.425bf8b351912be8cf3f0d5ea684df19@haskell.org> #12924: Pattern Synonyms in Typeclasses -------------------------------------+------------------------------------- Reporter: xcmw | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: pattern | synonym type class Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => closed * resolution: => duplicate Comment: See #11461 and #8583 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 4 16:31:03 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Dec 2016 16:31:03 -0000 Subject: [GHC] #12915: cmmImplementSwitchPlans creates duplicate blocks In-Reply-To: <048.450627ba0680e3fafd8b0486acc85c67@haskell.org> References: <048.450627ba0680e3fafd8b0486acc85c67@haskell.org> Message-ID: <063.cedf8a7d7cadfb39942b22af431fc8f7@haskell.org> #12915: cmmImplementSwitchPlans creates duplicate blocks -------------------------------------+------------------------------------- Reporter: alexbiehl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by michalt): * cc: michalt (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 4 17:07:42 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Dec 2016 17:07:42 -0000 Subject: [GHC] #12915: cmmImplementSwitchPlans creates duplicate blocks In-Reply-To: <048.450627ba0680e3fafd8b0486acc85c67@haskell.org> References: <048.450627ba0680e3fafd8b0486acc85c67@haskell.org> Message-ID: <063.7c3fc1bc92b45e45dca6e6599ff1c731@haskell.org> #12915: cmmImplementSwitchPlans creates duplicate blocks -------------------------------------+------------------------------------- Reporter: alexbiehl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by michalt): @nomeata: Yes, we definitely don't want to move the sinking pass before stack layout. Stack layout can generate a lot of unnecessary stuff that the sinking pass removes. There's also a `Node [Sinking after stack layout]` that explains why we don't currently run sinking twice (before and after stack layout). As for the comment in code: {{{ -- Any work storing block Labels must be performed _after_ -- elimCommonBlocks }}} IIUC it refers to things like proc point analysis that stores the labels for later use (and since `elimCommonBlock` can remove blocks/labels, it might no longer be safe to use those results). Anyway, I did a quick experiment and modified `CmmPipeline`: - Added a call to `elimCommonBlocks` directly after the sinking pass. - Duplicated the proc point analysis so that the actual splitting uses up to date information. Results: - Binary size: {{{ -1 s.d. ----- -1.0% +1 s.d. ----- -0.8% Average ----- -0.9% }}} - Module sizes: {{{ -1 s.d. ----- -1.8% +1 s.d. ----- +0.6% Average ----- -0.6% }}} - Compile times: {{{ -1 s.d. ----- -1.6% +1 s.d. ----- +3.3% Average ----- +0.8% }}} - Compiler allocations: {{{ -1 s.d. ----- +0.3% +1 s.d. ----- +1.0% Average ----- +0.7% }}} Runtime didn't seem to change (there were some outliers in the 1-2% area, but I think that's just noise). So it seems that there is actually some potential to decrease binary size, but I'm not sure it's worth the compile time overhead. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 4 17:18:16 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Dec 2016 17:18:16 -0000 Subject: [GHC] #12915: cmmImplementSwitchPlans creates duplicate blocks In-Reply-To: <048.450627ba0680e3fafd8b0486acc85c67@haskell.org> References: <048.450627ba0680e3fafd8b0486acc85c67@haskell.org> Message-ID: <063.c5d638d75d4843fc000c3b455ffc1c3e@haskell.org> #12915: cmmImplementSwitchPlans creates duplicate blocks -------------------------------------+------------------------------------- Reporter: alexbiehl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Thanks for the empirical data! Much appreciated. > I'm not sure it's worth the compile time overhead. I also doubt it. Shall we close this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 4 19:37:11 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Dec 2016 19:37:11 -0000 Subject: [GHC] #12915: cmmImplementSwitchPlans creates duplicate blocks In-Reply-To: <048.450627ba0680e3fafd8b0486acc85c67@haskell.org> References: <048.450627ba0680e3fafd8b0486acc85c67@haskell.org> Message-ID: <063.17343881f5f6f004812623676680b25c@haskell.org> #12915: cmmImplementSwitchPlans creates duplicate blocks -------------------------------------+------------------------------------- Reporter: alexbiehl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by michalt): I'm also leaning towards closing. Trading ~1% compile time for a similar decrease of binary size doesn't sound like a great deal... @alexbiehl: Is this causing you some problems/performance issues? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 4 23:02:09 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Dec 2016 23:02:09 -0000 Subject: [GHC] #12603: INLINE and manually inlining produce different code In-Reply-To: <046.944cd4788eed55470361e7f38358ac43@haskell.org> References: <046.944cd4788eed55470361e7f38358ac43@haskell.org> Message-ID: <061.6126d781ec3d3f608d15f03a72845269@haskell.org> #12603: INLINE and manually inlining produce different code -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #12747 #12781 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): OK I know what is happening here. Without an INLINE on `fgFromInt` we get: {{{ -- Initially fgFromInt w = w + (2^8) attrFromIntINLINE w = Attr (fgFromInt w) -- After float-out lvl = 2^8 fgFromInt w = w + lvl attrFromIntINLINE w = Attr (fgFromInt w) -- After inlining attrFromIntINLINE w = case w of I# w' -> case lvl of I# lvl' -> Attr (w' +# lvl') }}} The `Attr` constructor has one strict field, which is reprsented unboxed. We only compute `(2^8)` once. But with an INLINE on `fgFromInt` we get this: {{{ -- Initially fgFromInt w = w + (2^8) attrFromIntINLINE w = Attr (fgFromInt w) -- After float-out lvl = 2^8 fgFromInt w = w + lvl {- INLINE rhs = w + (2^8) -} attrFromIntINLINE w = Attr (fgFromInt w) -- After inlining attrFromIntINLINE w = case w of I# w' -> case 2# ^# 8# of lvl' -> Attr (w' +# lvl') }}} The INLINE pragma promises to inline what you wrote, not some optimised version thereof. So we inline `w + (2^8)`. In pcinciple we should optimise that just as well after it has been inlined. We've missed the float-out pass, but there's another one later. Alas, however, by the time the second float-out pass runs, the `(2^8)` has been transformed to its unboxed form, and currently we don't float those. Result we compute `(2^8)` on each iteration, rather than just once. There's even a `Note` about it in `SetLevels`: {{{ Note [Unlifted MFEs] ~~~~~~~~~~~~~~~~~~~~ We don't float unlifted MFEs, which potentially loses big opportunites. For example: \x -> f (h y) where h :: Int -> Int# is expensive. We'd like to float the (h y) outside the \x, but we don't because it's unboxed. Possible solution: box it. }}} --------------- What do do? The bad thing is really the inability to float expressions of unboxed type, because that inability makes GHC vulnerable to these "phase effects" when optimisation depends declicately on the exact order things happen in. Perhaps we could fix that by boxing. So, just before doing the floating stuff `SetLevels` could do {{{ e :: Int# ---> (case e of y -> \void. y) void ---> let v = /\a -> case e of y -> \void. y in v a void }}} at least when `e` is not cheap. Now it can float the `(case e of y -> I# y)`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 5 00:01:02 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Dec 2016 00:01:02 -0000 Subject: [GHC] #12603: INLINE and manually inlining produce different code In-Reply-To: <046.944cd4788eed55470361e7f38358ac43@haskell.org> References: <046.944cd4788eed55470361e7f38358ac43@haskell.org> Message-ID: <061.a5685e51313ebd0232dda7d3033d3f70@haskell.org> #12603: INLINE and manually inlining produce different code -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #12747 #12781 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by MikolajKonarski): Thank you for looking into this. A naive question: why can't we perform the programmer-accesible INLINE very, very early, macro-like and save the smart stuff for INLINE[k] or some new INLINE* or the spontaneous inlining that GHC does without pragmas? Why not assume a programmer brave enough to use a pragma knows his code and his data and that he benchmarked his code well enough to be sure he wants something totally equivalent to manual inlining but without sacrificing code quality? For me 'INLINE' (or 'INLINABLE' and 'inline', when I need more control) serves 2 purposes. The first is just forcing the particular trade-off between code duplication and speed. The second is benchmarking and optimization, when I add INLINE and NOINLINE to several related functions and based on which combination compiles to faster code with GHC, I then rewrite the functions to make sure the ones that need to be inlined have only one call site, etc. (I know GHC can do that for me sometimes, but I don't need nor want to rely on that). Of these two, the second purpose is more important, because I can always inline things manually in the final code, but if I had to inline manually when tweaking and benchmarking I'd go mad. And this is, why INLINE has to have a clear, simple, deterministic semantics, close enough to the semantics of manual inlining. If GHC outsmarts me and compiles to faster code without any pragmas (or with the INLINE* superpragma), all the better, I would experiment and remove some (NO)INLINEs from the final code. But for benchmarking, I need GHC to be dumb wrt the matrix of variables (INLINE/NOINLINE on a few functions) that I tweak. And ideally, I'd like to be able to tweak manually a few more knobs that also translate directly to source code manipulations, like FLOATOUT and NOFLOATOUT, etc. Perhaps I should just switch to Rust, which is specifically designed for manual control, but perhaps it's possible to make optimizing with GHC more like computer-aided proving, where the proof can always be inspected manually (and based on that, the set of tactics and orders for the prover modified) and less like a operating an immensely powerful black box that knows better. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 5 00:42:18 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Dec 2016 00:42:18 -0000 Subject: [GHC] #12922: Kind classes compile with PolyKinds In-Reply-To: <045.cda8d73aa7f5c75c71cb112094b7aabc@haskell.org> References: <045.cda8d73aa7f5c75c71cb112094b7aabc@haskell.org> Message-ID: <060.a002e6a1cc927468bccfc923af688edb@haskell.org> #12922: Kind classes compile with PolyKinds -------------------------------------+------------------------------------- Reporter: Tritlo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): For a simpler example, this compiles in GHC 8.0.1 (but probably shouldn't) without `TypeInType`: {{{#!hs {-# LANGUAGE PolyKinds #-} type KindOf (a :: k) = k }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 5 01:40:17 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Dec 2016 01:40:17 -0000 Subject: [GHC] #12906: GHC fails to typecheck Main module without main In-Reply-To: <045.9f131820c17fbe502671d27a0102f251@haskell.org> References: <045.9f131820c17fbe502671d27a0102f251@haskell.org> Message-ID: <060.226f2cde40401bad92188bae7d2af628@haskell.org> #12906: GHC fails to typecheck Main module without main -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Well, you are right in that GHC //did// use to report more information—you just have to dig back a bit further: {{{ $ /opt/ghc/7.4.2/bin/ghc Bug.hs [1 of 1] Compiling Main ( Bug.hs, Bug.o ) Bug.hs:1:1: The function `main' is not defined in module `Main' Bug.hs:4:7: Couldn't match expected type `String' with actual type `IO ()' In the return type of a call of `print' In the expression: print (reverse s + 1) In an equation for `x': x s = print (reverse s + 1) ryanglscott at T450s-Linux64 in ~/Documents/Hacking/Haskell $ /opt/ghc/7.6.3/bin/ghc Bug.hs [1 of 1] Compiling Main ( Bug.hs, Bug.o ) Bug.hs:1:1: The function `main' is not defined in module `Main' }}} So this happened sometime between GHC 7.4 and 7.6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 5 01:47:29 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Dec 2016 01:47:29 -0000 Subject: [GHC] #12906: GHC fails to typecheck Main module without main In-Reply-To: <045.9f131820c17fbe502671d27a0102f251@haskell.org> References: <045.9f131820c17fbe502671d27a0102f251@haskell.org> Message-ID: <060.36edebf55357a817b3733d364225b74f@haskell.org> #12906: GHC fails to typecheck Main module without main -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:2 RyanGlScott]: > Well, you are right in that GHC //did// use to report more information—you just have to dig back a bit further: > [...] > So this happened sometime between GHC 7.4 and 7.6. Thanks for the dig! I clearly remembered this all wrong. But my main point is really that whatever the history, it is far more ''useful'' to run the type checker on the module whether or not `main` is found. Requiring a `module` line or a `main` binding just to run the type checker is annoying, and has no apparent benefit. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 5 01:49:21 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Dec 2016 01:49:21 -0000 Subject: [GHC] #12922: Kind classes compile with PolyKinds In-Reply-To: <045.cda8d73aa7f5c75c71cb112094b7aabc@haskell.org> References: <045.cda8d73aa7f5c75c71cb112094b7aabc@haskell.org> Message-ID: <060.2a5e734c27cc57a7353ed7264d9de15d@haskell.org> #12922: Kind classes compile with PolyKinds -------------------------------------+------------------------------------- Reporter: Tritlo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Tritlo: @@ -7,1 +7,1 @@ - {-# LANGUAGE TypeFamilies, GADTs, TypeOperators, DataKinds, PolyKinds #-} + {-# LANGUAGE TypeFamilies, TypeOperators, DataKinds, PolyKinds #-} @@ -10,3 +10,1 @@ - import Data.Kind (Type) - - -- Define a Type for the natural numbers, Zero and a successor + -- Define a Type for the natural numbers, zero and a successor @@ -21,0 +19,3 @@ + + main :: IO () + main = putStrLn "Shouldn't this need TypeInType?" New description: I was asking around on #haskell to better understand the new language extension, -XTypeInType, and how it is different from -XPolyKinds. To study it, I was working with the following small example: {{{ {-# LANGUAGE TypeFamilies, TypeOperators, DataKinds, PolyKinds #-} module Main where -- Define a Type for the natural numbers, zero and a successor data Nat = Z | S Nat class Addable k where type (a :: k) + (b :: k) :: k instance Addable Nat where type (Z + a) = a type (S a) + b = S (a + b) main :: IO () main = putStrLn "Shouldn't this need TypeInType?" }}} (for more context, see https://gist.github.com/Tritlo/ce5510e80935ac398a33934ee47c7930) Since according to a responder on #haskell, the ability to have kind classes required TypeInType, and should not work with PolyKinds. As the documentation mentions that there could be leakage between PolyKinds and TypeInType and to report such leaks, I felt that I should report it. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 5 02:23:21 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Dec 2016 02:23:21 -0000 Subject: [GHC] #12925: GHC panic: Can't serialise IfaceTcTyVar Message-ID: <050.14e6e8b4799060d85fdbe9ea4c2ffb75@haskell.org> #12925: GHC panic: Can't serialise IfaceTcTyVar -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This bug currently prevents `vector` from being built with GHC HEAD. Here is a minimized test case: {{{ module Bug where data Foo a x = Foo x refoo :: Foo a x -> Foo b x refoo (Foo x) = Foo x {-# RULES "refoo/refoo" forall s. refoo (refoo s) = s #-} }}} You'll need to compile with optimizations on to trigger this: {{{ $ /opt/ghc/head/bin/ghc -O1 Bug.hs [1 of 1] Compiling Bug (.hs -> .o) Bug.hs:10:1: warning: [-Winline-rule-shadowing] Rule "refoo/refoo" may never fire because ‘refoo’ might inline first Probable fix: add an INLINE[n] or NOINLINE[n] pragma for ‘refoo’ Bug.hs:10:1: warning: [-Winline-rule-shadowing] Rule "refoo/refoo" may never fire because ‘refoo’ might inline first Probable fix: add an INLINE[n] or NOINLINE[n] pragma for ‘refoo’ ghc: panic! (the 'impossible' happened) (GHC version 8.1.20161125 for x86_64-unknown-linux): Can't serialise IfaceTcTyVar a_ary[sk:1] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1076:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1080:37 in ghc:Outputable pprPanic, called at compiler/iface/IfaceType.hs:1331:10 in ghc:IfaceType Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} If I had to guess, this commit ( http://git.haskell.org/ghc.git/commit/5f349fe24066e7b0af85934664e27636d2e84fe5 ) is responsible. Simon, do you know what's going on here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 5 06:42:48 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Dec 2016 06:42:48 -0000 Subject: [GHC] #12926: ghc master (8.1.20161202) panics with assertion failure with devel2 flavor and -O2 Message-ID: <044.d632e605d759db42e889e2bb2d7fb6bc@haskell.org> #12926: ghc master (8.1.20161202) panics with assertion failure with devel2 flavor and -O2 -------------------------------------+------------------------------------- Reporter: pacak | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Following code if compiled with -O2 (but not -O1) causes assertion failure. Depends only on vector. {{{#!hs {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE MultiParamTypeClasses #-} module A where import GHC.Base import qualified Data.Vector.Unboxed.Base import qualified Data.Vector.Generic.Base import Data.Vector.Generic.Mutable import qualified Data.Vector.Generic.Mutable.Base import Data.Vector.Generic (fromList) data A = A Int Int Int instance Data.Vector.Unboxed.Base.Unbox A newtype instance Data.Vector.Unboxed.Base.MVector s_a4iX A = MV_A (Data.Vector.Unboxed.Base.MVector s_a4iX (Int, Int, Int)) instance MVector Data.Vector.Unboxed.Base.MVector A where basicLength (MV_A v) = basicLength v basicUnsafeSlice idx len (MV_A v) = MV_A (basicUnsafeSlice idx len v) basicUnsafeNew len = (MV_A `liftM` (basicUnsafeNew len)) basicUnsafeWrite (MV_A v) idx val_a4iW = basicUnsafeWrite v idx ( (\ (A a_a4iT b_a4iU c_a4iV) -> (a_a4iT, b_a4iU, c_a4iV)) val_a4iW) newtype instance Data.Vector.Unboxed.Base.Vector A = V_A (Data.Vector.Unboxed.Base.Vector (Int, Int, Int)) instance Data.Vector.Generic.Base.Vector Data.Vector.Unboxed.Base.Vector A where mkA :: Data.Vector.Unboxed.Base.Vector A mkA = fromList [] }}} {{{ ghc: panic! (the 'impossible' happened) [7/1644] (GHC version 8.1.20161202 for x86_64-unknown-linux): ASSERT failed! in_scope InScope {wild_00 eta_X1T $cbasicUnsafeFreeze_a6sr $cbasicUnsafeThaw_a6st $cbasicLength_a6sv $cbasicUnsafeSlice_a6sx $cbasicUnsafeIndexM_a6sz $cbasicUnsafeCopy_a6sF $celemseq_a6t3 $cbasicLength_a6tm $cbasicUnsafeSlice_a6ty $cbasicOverlaps_a6tL $cbasicUnsafeNew_a6tN $cbasicInitialize_a6uj $cbasicUnsafeReplicate_a6up $cbasicUnsafeRead_a6uJ $cbasicUnsafeWrite_a6uL $cbasicClear_a6vg $cbasicSet_a6vE $cbasicUnsafeCopy_a6w2 $cbasicUnsafeMove_a6wr $cbasicUnsafeGrow_a6wQ wild_a7QO dt_a7QQ ds1_a7QR ds2_a7QS ds3_a7QT wild_a80U x_a819 xs1_a81a ds4_a84V z_a84W s7_a84X ds5_a851 wild5_a85V v3_a85X i_a85Y wild7_a866 x_a868 y_a86k wild9_a86m $tcA $trModule $tc'A $fVectorVectorA $fUnboxA $fMVectorMVectorA mkA $cbasicUnsafeSlice_s7QF $trModule_s7Su $trModule_s7Sv $tc'A_s7Sw $s$dmbasicUnsafeGrow_s7Vp $s$dmbasicUnsafeMove_s7Vw $s$dmbasicUnsafeReplicate_s7VB $s$dmbasicSet_s7VG $s$dmbasicUnsafeCopy_s7VN $s$dmbasicUnsafeCopy_s7VW $sunstream_s886 $s$fMVectorMVector(,,)_$cbasicUnsafeNew_s896 $s$fMVectorMVector(,,)_$cbasicUnsafeWrite_s89h $s$fMVectorMVector(,,)_$cbasicUnsafeSlice_s89k $s$fMVectorMVector(,,)_$cbasicLength_s89l $sfromList_s89m $snew_s89n $s$dmelemseq_s89o $s$dmbasicClear_s89p lvl_s89Y $j_sa8p lvl_sbhM lvl_sbhN lvl_sbhO lvl_sbhP lvl_sbhQ lvl_sbhR lvl_sbhT lvl_sbhU lvl_sbhV lvl_sbhW lvl_sbi1 lvl_sbi2 lvl_sbi4 lvl_sbi5 lvl_sbi6 lvl_sbi7 foldlM_loop_sbns foldlM_loop_sbnL lvl_sbo2 $sfoldlM_loop_sbHS $s$j_sbI5 $sfoldlM_loop_sbIa $sfoldlM_loop_sbIx} tenv [] tenvFVs [] cenv [sbHY :-> sg_sbHY] cenvFVs [sbHY :-> sg_sbHY] tys [PrimState (ST RealWorld)] cos [] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1114:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1163:22 in ghc:Outputable assertPprPanic, called at compiler/types/TyCoRep.hs:2023:56 in ghc:TyCoRep checkValidSubst, called at compiler/types/TyCoRep.hs:2056:17 in ghc:TyCoRep substTy, called at compiler/types/Coercion.hs:1457:33 in ghc:Coercion Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1114:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1118:37 in ghc:Outputable pprPanic, called at compiler/utils/Outputable.hs:1161:5 in ghc:Outputable assertPprPanic, called at compiler/types/TyCoRep.hs:2023:56 in ghc:TyCoRep checkValidSubst, called at compiler/types/TyCoRep.hs:2056:17 in ghc:TyCoRep substTy, called at compiler/types/Coercion.hs:1457:33 in ghc:Coercion Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 5 08:42:57 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Dec 2016 08:42:57 -0000 Subject: [GHC] #12915: cmmImplementSwitchPlans creates duplicate blocks In-Reply-To: <048.450627ba0680e3fafd8b0486acc85c67@haskell.org> References: <048.450627ba0680e3fafd8b0486acc85c67@haskell.org> Message-ID: <063.d917c59c5338e715424964063758e33b@haskell.org> #12915: cmmImplementSwitchPlans creates duplicate blocks -------------------------------------+------------------------------------- Reporter: alexbiehl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hsyl20): Could we allow this additional pass with an optimization flag? It would be a good candidate for a `-O2` (“Apply every non-dangerous optimisation, even if it means significantly longer compile times.” so you get what you ask for) or a potential `-Os`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 5 09:57:37 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Dec 2016 09:57:37 -0000 Subject: [GHC] #12920: Overzealous unused-top-binds In-Reply-To: <047.901081a81082358202634643f971c0b9@haskell.org> References: <047.901081a81082358202634643f971c0b9@haskell.org> Message-ID: <062.5b04e9655761d64e29b69fe7fed46617@haskell.org> #12920: Overzealous unused-top-binds -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2-rc1 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes, that does look inconsistent; I'm not sure why. > This definition would be exceedingly useful for removing dead code, but it also produces very noisy output when there is a lot of dead code. Yes, this is a tension, but I don't know how to resolve it. Until now we have done the transitive thing, but mostly I think that the non-transitive version might be better. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 5 09:58:32 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Dec 2016 09:58:32 -0000 Subject: [GHC] #12906: GHC fails to typecheck Main module without main In-Reply-To: <045.9f131820c17fbe502671d27a0102f251@haskell.org> References: <045.9f131820c17fbe502671d27a0102f251@haskell.org> Message-ID: <060.248ea0573174f502d44b78bfa3f12574@haskell.org> #12906: GHC fails to typecheck Main module without main -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm sure this would be easy to fix, if someone would like to have a go -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 5 10:17:55 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Dec 2016 10:17:55 -0000 Subject: [GHC] #12922: Kind classes compile with PolyKinds In-Reply-To: <045.cda8d73aa7f5c75c71cb112094b7aabc@haskell.org> References: <045.cda8d73aa7f5c75c71cb112094b7aabc@haskell.org> Message-ID: <060.768d4b420e3eee1e3b5f2c7e249ed9e3@haskell.org> #12922: Kind classes compile with PolyKinds -------------------------------------+------------------------------------- Reporter: Tritlo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Without thinking too deeply * `TypeInType` should imply `PolyKinds`. * `PolyKinds` should be enough for kind classes, if by "kind classes" you mean polymorphism over types of kind `Constraint`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 5 10:28:08 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Dec 2016 10:28:08 -0000 Subject: [GHC] #12923: MultiParamTypeClasses + ExtendedDefaultRules In-Reply-To: <046.9ae3ec8e366c95f2b64ecec80ccef95a@haskell.org> References: <046.9ae3ec8e366c95f2b64ecec80ccef95a@haskell.org> Message-ID: <061.3c5e35e9bff929306c0c6a39b37679b2@haskell.org> #12923: MultiParamTypeClasses + ExtendedDefaultRules -------------------------------------+------------------------------------- Reporter: amindfv | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): What, precisely, would you like the defaulting rule to be? Ideally, express your proposed rule(s) in the same way as [the user manual does](https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/ghci.html #type-defaulting-in-ghci). Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 5 10:47:21 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Dec 2016 10:47:21 -0000 Subject: [GHC] #12549: Panic on ":t datatypeName" In-Reply-To: <046.93c629409627bd964a188fb34004cca8@haskell.org> References: <046.93c629409627bd964a188fb34004cca8@haskell.org> Message-ID: <061.1ef616d510fadc3d2e537e84e33f1ccd@haskell.org> #12549: Panic on ":t datatypeName" ---------------------------------+-------------------------------------- Reporter: johnleo | Owner: johnleo Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by simonpj): I'm not certain, but I thought that `tc_infer_args` was the only caller of `new_meta_tv_x` which didn't establish the in-scope set. There are lots of `substTyUnchecked` which each need individual attention. I suppose a new ticket that enumerated them would be a good thing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 5 10:56:41 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Dec 2016 10:56:41 -0000 Subject: [GHC] #9291: Don't reconstruct sum types if the type subtly changes In-Reply-To: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> References: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> Message-ID: <061.b7c4477af11fe311bc5000547b62f244@haskell.org> #9291: Don't reconstruct sum types if the type subtly changes -------------------------------------+------------------------------------- Reporter: schyler | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 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: | -------------------------------------+------------------------------------- Comment (by simonpj): The wiki page looks plausible... but rather a lot of work for a modest gain. I wonder if a better approach would be a STG-level CSE pass? (No types there!) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 5 11:18:05 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Dec 2016 11:18:05 -0000 Subject: [GHC] #12727: ghc: panic! (the 'impossible' happened) - piResultTy In-Reply-To: <047.7a02b67b63e3ce77f03bfc70c60ffa06@haskell.org> References: <047.7a02b67b63e3ce77f03bfc70c60ffa06@haskell.org> Message-ID: <062.35091c775c476e15ef3095ac09937c74@haskell.org> #12727: ghc: panic! (the 'impossible' happened) - piResultTy -------------------------------------+------------------------------------- Reporter: ocharles | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ocharles): Sadly we're still seeing this on GHC 8.0.2 RC 1. I'll try and compile with -dcore-lint now and see if that shines any light on the issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 5 11:20:35 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Dec 2016 11:20:35 -0000 Subject: [GHC] #12727: ghc: panic! (the 'impossible' happened) - piResultTy In-Reply-To: <047.7a02b67b63e3ce77f03bfc70c60ffa06@haskell.org> References: <047.7a02b67b63e3ce77f03bfc70c60ffa06@haskell.org> Message-ID: <062.60083b4fe5eaec02c346f8c0e5f78e60@haskell.org> #12727: ghc: panic! (the 'impossible' happened) - piResultTy -------------------------------------+------------------------------------- Reporter: ocharles | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ocharles): * version: 8.0.1 => 8.0.2-rc1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 5 12:17:01 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Dec 2016 12:17:01 -0000 Subject: [GHC] #12919: Equality not used for substitution In-Reply-To: <048.c4e450c7b401a6295cbd8b394ff2a079@haskell.org> References: <048.c4e450c7b401a6295cbd8b394ff2a079@haskell.org> Message-ID: <063.2f362f78dd1647ca1b13a21662789c67@haskell.org> #12919: Equality not used for substitution -------------------------------------+------------------------------------- Reporter: int-index | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: => goldfire @@ -6,0 +6,2 @@ + module T12919 where + @@ -8,1 +10,1 @@ - data N = Z + data Nat = Z @@ -10,2 +12,2 @@ - data V :: N -> Type where - VZ :: V Z + data D :: Nat -> Type where + DZ :: D Z @@ -13,1 +15,1 @@ - type family VC (n :: N) :: Type where + type family VC (n :: Nat) :: Type where @@ -16,2 +18,2 @@ - type family VF (xs :: V n) (f :: VC n) :: Type where - VF VZ f = f + type family VF (xs :: D n) (f :: VC n) :: Type where + VF DZ f = f @@ -22,1 +24,1 @@ - prop :: xs ~ VZ => Dict (VF xs f ~ f) + prop :: xs ~ DZ => Dict (VF xs f ~ f) New description: This code {{{ {-# LANGUAGE TypeInType, TypeFamilies, GADTs, ConstraintKinds #-} module T12919 where import Data.Kind data Nat = Z data D :: Nat -> Type where DZ :: D Z type family VC (n :: Nat) :: Type where VC Z = Type type family VF (xs :: D n) (f :: VC n) :: Type where VF DZ f = f data Dict c where Dict :: c => Dict c prop :: xs ~ DZ => Dict (VF xs f ~ f) prop = Dict }}} fails with this error: {{{ Op.hs:20:8: error: • Couldn't match type ‘f’ with ‘VF 'VZ f’ arising from a use of ‘Dict’ ‘f’ is a rigid type variable bound by the type signature for: prop :: forall (xs :: V 'Z) f. xs ~ 'VZ => Dict VF xs f ~ f at Op.hs:19:9 • In the expression: Dict In an equation for ‘prop’: prop = Dict • Relevant bindings include prop :: Dict VF xs f ~ f (bound at Op.hs:20:1) }}} However, if I substitute `xs` with `VZ` (by hand) in the type of `prop`, it compiles. Can be reproduced with GHC 8.0.1 but not HEAD. -- Comment: Richard, could you look at this? It's an outright bug. I had a look and my brain melted. * We seem to be flattening a type `((f::*) |> Sym D:R:VC[0])`, where I think {{{ axiom D:R:VC[0] :: VC Z ~ Type }}} But the result of this flattening seems to be `((f:*) |> D:R:VC[0])`, which is plainly wrong. * I don't understand the code {{{ flatten_one (CastTy ty g) = do { (xi, co) <- flatten_one ty ; (g', _) <- flatten_co g ; return (mkCastTy xi g', castCoercionKind co g' g) } }}} It seems suspicious that the evidence returned by `flatten_co` is discarded. * `flatten_co` is inadequately commented. Perhaps {{{ If r is a role co :: s ~r t flatten_co co = (fco, kco) then fco :: fs ~r ft fs, ft are flattened types kco :: (fs ~r ft) ~N# (s ~r t) }}} But I'm really not sure. * The `flatten_one (CastTy ty g)` plan seems quite baroque when applied to `((f::*) |> D:R:VC[0])`. Apparently, in `flatten_co` we * Take the coercion `D:R:VC[0]`, and flatten its from-type `*`, and its to-type `VC Z`. * Flattening its to-type uses `Sym D:R:VC[0]` to produce `*` again. * So we end up with `Refl ; D:R:VC[0] : Sym D:R:VC[0]`, which seems a bit of a waste. Generally, could you add a note about flattening `(t |> g)`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 5 12:17:17 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Dec 2016 12:17:17 -0000 Subject: [GHC] #12919: Equality not used for substitution In-Reply-To: <048.c4e450c7b401a6295cbd8b394ff2a079@haskell.org> References: <048.c4e450c7b401a6295cbd8b394ff2a079@haskell.org> Message-ID: <063.2069c740d41cc4f5aabe6e11f44485d3@haskell.org> #12919: Equality not used for substitution -------------------------------------+------------------------------------- Reporter: int-index | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => TypeInType * priority: high => highest -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 5 12:18:56 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Dec 2016 12:18:56 -0000 Subject: [GHC] #12727: ghc: panic! (the 'impossible' happened) - piResultTy In-Reply-To: <047.7a02b67b63e3ce77f03bfc70c60ffa06@haskell.org> References: <047.7a02b67b63e3ce77f03bfc70c60ffa06@haskell.org> Message-ID: <062.75d1761672d3dfdbfffcf3bf4a3d34e0@haskell.org> #12727: ghc: panic! (the 'impossible' happened) - piResultTy -------------------------------------+------------------------------------- Reporter: ocharles | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): It's be great to nail this but we are stuck without a way to reproduce it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 5 12:20:40 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Dec 2016 12:20:40 -0000 Subject: [GHC] #12727: ghc: panic! (the 'impossible' happened) - piResultTy In-Reply-To: <047.7a02b67b63e3ce77f03bfc70c60ffa06@haskell.org> References: <047.7a02b67b63e3ce77f03bfc70c60ffa06@haskell.org> Message-ID: <062.82dcf43fa9cb83017dc7eb6b74291dc0@haskell.org> #12727: ghc: panic! (the 'impossible' happened) - piResultTy -------------------------------------+------------------------------------- Reporter: ocharles | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ocharles): Don't worry, perfectly understandable! I'm going to try and get some more information on this for you. I can't even reliably reproduce it myself, some builds are going through while others fail - always on this module though. I'm hoping -dcore-lint will give us a bit more understanding of what is going wrong though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 5 12:35:27 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Dec 2016 12:35:27 -0000 Subject: [GHC] #12603: INLINE and manually inlining produce different code In-Reply-To: <046.944cd4788eed55470361e7f38358ac43@haskell.org> References: <046.944cd4788eed55470361e7f38358ac43@haskell.org> Message-ID: <061.1e5861bc5bcac68ff428cfd174b8fa7a@haskell.org> #12603: INLINE and manually inlining produce different code -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #12747 #12781 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): It's all to do with ''interactions'' between multiple INLINEs. If we did as you say, and inlined earlier, then we would ''also'' inline functions like `(+)` which also have INLINE pragmas on them. So we might get {{{ attrFromIntINLINE w = case w of I# w' -> case 2# ^# 8# of lvl' -> Attr (w' +# lvl') }}} which, as I say, is currently unfloatable. You may say that the INLINE on `(+)` should be delayed and that would be one solution. But perhaps a better one would be to make floating more robust. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 5 12:39:22 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Dec 2016 12:39:22 -0000 Subject: [GHC] #12925: GHC panic: Can't serialise IfaceTcTyVar In-Reply-To: <050.14e6e8b4799060d85fdbe9ea4c2ffb75@haskell.org> References: <050.14e6e8b4799060d85fdbe9ea4c2ffb75@haskell.org> Message-ID: <065.07ccb8167b0055bb8f08a6b8f7fdf10f@haskell.org> #12925: GHC panic: Can't serialise IfaceTcTyVar -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): So you have this in your tree? {{{ commit f8c8de8ebf73cd77faa0249d92f280e33a8d2624 Author: Simon Peyton Jones Date: Tue Nov 29 14:03:46 2016 +0000 Zonk the free tvs of a RULE lhs to TyVars }}} If not, that should fix it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 5 13:15:12 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Dec 2016 13:15:12 -0000 Subject: [GHC] #12922: Kind classes compile with PolyKinds In-Reply-To: <045.cda8d73aa7f5c75c71cb112094b7aabc@haskell.org> References: <045.cda8d73aa7f5c75c71cb112094b7aabc@haskell.org> Message-ID: <060.bbab4686b4dd1af8a0e1aecbeb9a63ab@haskell.org> #12922: Kind classes compile with PolyKinds -------------------------------------+------------------------------------- Reporter: Tritlo | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * owner: => goldfire Comment: But look at the OP's {{{ class Addable k where type (a :: k) + (b :: k) :: k }}} where the class variable `k` is used as a kind. This indeed should not be allowed unless `TypeInType` is on. I'll put this in my queue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 5 13:16:31 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Dec 2016 13:16:31 -0000 Subject: [GHC] #12919: Equality not used for substitution In-Reply-To: <048.c4e450c7b401a6295cbd8b394ff2a079@haskell.org> References: <048.c4e450c7b401a6295cbd8b394ff2a079@haskell.org> Message-ID: <063.6a914557f0761db1b44891151aca2e33@haskell.org> #12919: Equality not used for substitution -------------------------------------+------------------------------------- Reporter: int-index | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by int-index: @@ -10,1 +10,1 @@ - data Nat = Z + data N = Z @@ -12,2 +12,2 @@ - data D :: Nat -> Type where - DZ :: D Z + data V :: N -> Type where + VZ :: V Z @@ -15,1 +15,1 @@ - type family VC (n :: Nat) :: Type where + type family VC (n :: N) :: Type where @@ -18,2 +18,2 @@ - type family VF (xs :: D n) (f :: VC n) :: Type where - VF DZ f = f + type family VF (xs :: V n) (f :: VC n) :: Type where + VF VZ f = f @@ -24,1 +24,1 @@ - prop :: xs ~ DZ => Dict (VF xs f ~ f) + prop :: xs ~ VZ => Dict (VF xs f ~ f) @@ -31,1 +31,1 @@ - Op.hs:20:8: error: + T12919.hs:22:8: error: @@ -37,1 +37,1 @@ - at Op.hs:19:9 + at T12919.hs:21:9 @@ -41,1 +41,1 @@ - prop :: Dict VF xs f ~ f (bound at Op.hs:20:1) + prop :: Dict VF xs f ~ f (bound at T12919.hs:22:1) New description: This code {{{ {-# LANGUAGE TypeInType, TypeFamilies, GADTs, ConstraintKinds #-} module T12919 where import Data.Kind data N = Z data V :: N -> Type where VZ :: V Z type family VC (n :: N) :: Type where VC Z = Type type family VF (xs :: V n) (f :: VC n) :: Type where VF VZ f = f data Dict c where Dict :: c => Dict c prop :: xs ~ VZ => Dict (VF xs f ~ f) prop = Dict }}} fails with this error: {{{ T12919.hs:22:8: error: • Couldn't match type ‘f’ with ‘VF 'VZ f’ arising from a use of ‘Dict’ ‘f’ is a rigid type variable bound by the type signature for: prop :: forall (xs :: V 'Z) f. xs ~ 'VZ => Dict VF xs f ~ f at T12919.hs:21:9 • In the expression: Dict In an equation for ‘prop’: prop = Dict • Relevant bindings include prop :: Dict VF xs f ~ f (bound at T12919.hs:22:1) }}} However, if I substitute `xs` with `VZ` (by hand) in the type of `prop`, it compiles. Can be reproduced with GHC 8.0.1 but not HEAD. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 5 13:59:53 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Dec 2016 13:59:53 -0000 Subject: [GHC] #12919: Equality not used for substitution In-Reply-To: <048.c4e450c7b401a6295cbd8b394ff2a079@haskell.org> References: <048.c4e450c7b401a6295cbd8b394ff2a079@haskell.org> Message-ID: <063.1eab67a11d3c62df4b5f1a9871e85559@haskell.org> #12919: Equality not used for substitution -------------------------------------+------------------------------------- Reporter: int-index | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): While I don't see what's going wrong here -- and something surely is -- I'm not as concerned about `flatten_co`. The second return value from the function is always ignored and should indeed be removed. It is a coercion relating the output coercion to the input, as constructed by `mkProofIrrelCo`. (Yes, this is a coercion relating two coercions.) These coercions are cheap to make, as any two coercions proving the same proposition are considered equal. Is this holding you up today? Or is it OK to wait a few weeks? I see the "highest" priority and will surely fix for 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 5 14:13:58 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Dec 2016 14:13:58 -0000 Subject: [GHC] #12925: GHC panic: Can't serialise IfaceTcTyVar In-Reply-To: <050.14e6e8b4799060d85fdbe9ea4c2ffb75@haskell.org> References: <050.14e6e8b4799060d85fdbe9ea4c2ffb75@haskell.org> Message-ID: <065.bd523d84e4247199c9e56ceca1e0f9e2@haskell.org> #12925: GHC panic: Can't serialise IfaceTcTyVar -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => invalid Comment: Thanks Simon, that explains it. I was using a slightly older build from https://launchpad.net/~hvr/+archive/ubuntu/ghc which included 5f349fe24066e7b0af85934664e27636d2e84fe5, but not f8c8de8ebf73cd77faa0249d92f280e33a8d2624. I can verify that that commit fixes the above issue. Apologies for the noise. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 5 14:16:59 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Dec 2016 14:16:59 -0000 Subject: [GHC] #9291: Don't reconstruct sum types if the type subtly changes In-Reply-To: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> References: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> Message-ID: <061.626d73c7a66e466d597fe91e0567a132@haskell.org> #9291: Don't reconstruct sum types if the type subtly changes -------------------------------------+------------------------------------- Reporter: schyler | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 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: | -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:28 simonpj]: > The wiki page looks plausible... but rather a lot of work for a modest gain. As Joachim hinted at above, this is also my stance. There might be some interesting theory here and some fun proofs, but I'm unconvinced that all the heavy lifting will be worth it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 5 14:38:54 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Dec 2016 14:38:54 -0000 Subject: [GHC] #12915: cmmImplementSwitchPlans creates duplicate blocks In-Reply-To: <048.450627ba0680e3fafd8b0486acc85c67@haskell.org> References: <048.450627ba0680e3fafd8b0486acc85c67@haskell.org> Message-ID: <063.75e938f6bb2f2939d44d545565959b40@haskell.org> #12915: cmmImplementSwitchPlans creates duplicate blocks -------------------------------------+------------------------------------- Reporter: alexbiehl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): I'm thinking the same as hsyl20. The binary size numbers indicate that whatever parts of the standard libraries end up getting linked into all the nofib programs got 1% smaller, which is nothing to sneeze at. Might also be worth checking out whether this is due to a few small gains and whether there might be a cheaper way of getting those gains. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 5 14:53:52 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Dec 2016 14:53:52 -0000 Subject: [GHC] #12922: Kind classes compile with PolyKinds In-Reply-To: <045.cda8d73aa7f5c75c71cb112094b7aabc@haskell.org> References: <045.cda8d73aa7f5c75c71cb112094b7aabc@haskell.org> Message-ID: <060.d2b3917e3f73c43c6ac6f4b0c6bc02da@haskell.org> #12922: Kind classes compile with PolyKinds -------------------------------------+------------------------------------- Reporter: Tritlo | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Welcome Tritlo! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 5 14:55:46 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Dec 2016 14:55:46 -0000 Subject: [GHC] #9291: Don't reconstruct sum types if the type subtly changes In-Reply-To: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> References: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> Message-ID: <061.41e0c9ea7c3a27b455c97e9d1b30d9f9@haskell.org> #9291: Don't reconstruct sum types if the type subtly changes -------------------------------------+------------------------------------- Reporter: schyler | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 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 Iceland_jack): * cc: Iceland_jack (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 5 15:27:12 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Dec 2016 15:27:12 -0000 Subject: [GHC] #9291: Don't reconstruct sum types if the type subtly changes In-Reply-To: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> References: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> Message-ID: <061.90d30c4385da8d4648e87820bec4a85b@haskell.org> #9291: Don't reconstruct sum types if the type subtly changes -------------------------------------+------------------------------------- Reporter: schyler | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 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: | -------------------------------------+------------------------------------- Comment (by osa1): CSE implementation in STG is one of the things I'm hoping to try when I have some time. I have a branch here that allows STG-to-STG plugins: https://github.com/osa1/ghc/tree/stg_plugins, this may help. We just need a version of `TrieMap` for STG expressions and then the pass should be trivial. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 5 15:29:43 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Dec 2016 15:29:43 -0000 Subject: [GHC] #12809: TYPE 'UnboxedTupleRep is still a lie In-Reply-To: <047.e76db1a74f10a41a50c71596cd333981@haskell.org> References: <047.e76db1a74f10a41a50c71596cd333981@haskell.org> Message-ID: <062.b0ee62abde31db0be40d44e410918331@haskell.org> #12809: TYPE 'UnboxedTupleRep is still a lie -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * cc: Iceland_jack (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 5 15:32:07 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Dec 2016 15:32:07 -0000 Subject: [GHC] #12919: Equality not used for substitution In-Reply-To: <048.c4e450c7b401a6295cbd8b394ff2a079@haskell.org> References: <048.c4e450c7b401a6295cbd8b394ff2a079@haskell.org> Message-ID: <063.d34616949798339cd1d417c402160785@haskell.org> #12919: Equality not used for substitution -------------------------------------+------------------------------------- Reporter: int-index | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): It's not holding ''me'' up, but presumably it's holding int-index up, and outright Lint bugs seem so egregious that I try to fix them fast. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 5 16:08:48 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Dec 2016 16:08:48 -0000 Subject: [GHC] #9291: Don't reconstruct sum types if the type subtly changes In-Reply-To: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> References: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> Message-ID: <061.f42f0ffdc7a9bc782679450f628f0803@haskell.org> #9291: Don't reconstruct sum types if the type subtly changes -------------------------------------+------------------------------------- Reporter: schyler | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 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: | -------------------------------------+------------------------------------- Comment (by nomeata): > I wonder if a better approach would be a STG-level CSE pass? (No types there!) Is general CSE on the STG level safe? We would have to pay attention not to CSE two invocations of `newSTRef`, for example! Consider {{{#!hs foo :: Integer -> Integer foo n = runST (newSTRef 1 >>= \r -> modifySTRef r (+n) >> readSTRef r) + runST (newSTRef 1 >>= \r -> modifySTRef r (+2*n) >> readSTRef r) }}} which generated this STG {{{ STGCSE.foo :: GHC.Integer.Type.Integer -> GHC.Integer.Type.Integer [GblId, Arity=1, Str=, Unf=OtherCon []] = \r [n_sQX] case case newMutVar# [STGCSE.foo2 GHC.Prim.realWorld#] of { Unit# ipv1_sR0 -> … } of { Unit# ipv1_sR8 [Occ=Once] -> case case newMutVar# [STGCSE.foo2 GHC.Prim.realWorld#] of { Unit# ipv3_sRb -> … }}} The two calls to `newMutVar#` look identical! But if we CSE them up, we change the semantics of the program. So it would require some form of „sideeffect-freeness“ analysis on STG. A simple form might be to CSE only constructor applications, and it would be sufficient for this issue. I guess it is good that `newMutVar#` does not get “inlined” to be just a constructor application at the STG stage. I wonder if there are constructor applications that we nevertheless do not want to CSE. The problem does not exist in Core, where `GHC.Magic.runRW#` is not inlined, and the types of `newMutVar#` do not match up. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 5 17:05:57 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Dec 2016 17:05:57 -0000 Subject: [GHC] #9291: Don't reconstruct sum types if the type subtly changes In-Reply-To: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> References: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> Message-ID: <061.11a46cbaffb13c81d149071fde84ca8c@haskell.org> #9291: Don't reconstruct sum types if the type subtly changes -------------------------------------+------------------------------------- Reporter: schyler | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 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: | -------------------------------------+------------------------------------- Comment (by simonpj): Ha ha. Excellent point! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 5 17:11:16 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Dec 2016 17:11:16 -0000 Subject: [GHC] #1791: heap overflow should generate an exception In-Reply-To: <044.abdddbf09447556bb749e2aa1d8c6598@haskell.org> References: <044.abdddbf09447556bb749e2aa1d8c6598@haskell.org> Message-ID: <059.6c4efbd46a70a012f8de70529133d54c@haskell.org> #1791: heap overflow should generate an exception -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: ⊥ Component: Runtime System | Version: 6.8 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: outofmem2 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dobenour): I created a patch for this, but it is just a best-effort implementation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 5 17:13:32 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Dec 2016 17:13:32 -0000 Subject: [GHC] #9291: Don't reconstruct sum types if the type subtly changes In-Reply-To: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> References: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> Message-ID: <061.a72d7526bdbad1a7b05668353e37df87@haskell.org> #9291: Don't reconstruct sum types if the type subtly changes -------------------------------------+------------------------------------- Reporter: schyler | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 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: | -------------------------------------+------------------------------------- Comment (by nomeata): There is value in working with a typed intermediate language, isn’t it ;-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 5 17:40:20 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Dec 2016 17:40:20 -0000 Subject: [GHC] #12425: With -O1 and above causes ghc to use all available memory before being killed by OOM killer In-Reply-To: <044.8db07ee1e56d0d370ac594dbce3dff94@haskell.org> References: <044.8db07ee1e56d0d370ac594dbce3dff94@haskell.org> Message-ID: <059.a97d7d3aa4b3fd71c9d52199d77eeedc@haskell.org> #12425: With -O1 and above causes ghc to use all available memory before being killed by OOM killer -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.3 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"517d03e41b4f5c144d1ad684539340421be2be2a/ghc" 517d03e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="517d03e41b4f5c144d1ad684539340421be2be2a" Fix an asymptotic bug in the occurrence analyser Trac #12425 and #12234 showed up a major and long-standing bug in the occurrence analyser, whereby it could generate explonentially large program! There's a lot of commentary on #12425; and it's all described in Note [Loop breakers, node scoring, and stability] I did quite a lot of refactoring to make the code comprehensibe again (its structure had bit-rotted rather), so the patch looks bigger than it really is. Hurrah! I did a nofib run to check that I hadn't inadertently ruined anything: -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- fluid -0.3% -1.5% 0.01 0.01 +0.0% parser -0.9% +0.6% 0.04 0.04 +0.0% prolog -0.1% +1.2% 0.00 0.00 +0.0% -------------------------------------------------------------------------------- Min -0.9% -1.5% -8.6% -8.7% +0.0% Max +0.1% +1.2% +7.7% +7.8% +2.4% Geometric Mean -0.2% -0.0% -0.2% -0.3% +0.0% I checked what happened in 'prolog'. It seems that we have a recursive data structure something like this f :: [blah] f x = build (\cn. ...g... ) g :: [blah2] g y = ....(foldr k z (f y)).... If we inline 'f' into 'g' we get better fusion than the other way round, but we don't have any way to spot that at the moment. (I wonder if we could do worker/wrapper for functions returning a 'build'?) It was happening before by a fluke. Anyway I decided to accept this; it's relatively rare I think. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 5 17:40:20 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Dec 2016 17:40:20 -0000 Subject: [GHC] #12925: GHC panic: Can't serialise IfaceTcTyVar In-Reply-To: <050.14e6e8b4799060d85fdbe9ea4c2ffb75@haskell.org> References: <050.14e6e8b4799060d85fdbe9ea4c2ffb75@haskell.org> Message-ID: <065.b3d5a8853c93cec8339c85f15fd0793b@haskell.org> #12925: GHC panic: Can't serialise IfaceTcTyVar -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"3e3f7c21a64758c671192c63a741ecc4a5a08831/ghc" 3e3f7c2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="3e3f7c21a64758c671192c63a741ecc4a5a08831" Test Trac #12925 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 5 17:40:20 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Dec 2016 17:40:20 -0000 Subject: [GHC] #12548: Exported pattern synonyms does not mark top-level bindings in RHS as used In-Reply-To: <043.97f0b3892f5aded29e0cb9f0f5c452d4@haskell.org> References: <043.97f0b3892f5aded29e0cb9f0f5c452d4@haskell.org> Message-ID: <058.83c443ce361fcb5ab1a0f538dba3d742@haskell.org> #12548: Exported pattern synonyms does not mark top-level bindings in RHS as used -------------------------------------+------------------------------------- Reporter: pkmx | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | PatternSynonyms, newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"6305674f310633d159a4df4e2e0d033a698599d1/ghc" 6305674/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6305674f310633d159a4df4e2e0d033a698599d1" Fix used-variable calculation (Trac #12548) The used-variable calculation for pattern synonyms is a little tricky, for reasons described in RnBinds Note [Pattern synonym builders don't yield dependencies] It was right semantically, but the "unused-variable warning" was wrong, which led to Trac #12548. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 5 17:40:20 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Dec 2016 17:40:20 -0000 Subject: [GHC] #12234: 'deriving Eq' on recursive datatype makes ghc eat a lot of CPU and RAM In-Reply-To: <045.352c8bb25c33b092176709513059d519@haskell.org> References: <045.352c8bb25c33b092176709513059d519@haskell.org> Message-ID: <060.1a882ab7c77cad49b35ee9385a00f8af@haskell.org> #12234: 'deriving Eq' on recursive datatype makes ghc eat a lot of CPU and RAM -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: deriving-perf Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"517d03e41b4f5c144d1ad684539340421be2be2a/ghc" 517d03e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="517d03e41b4f5c144d1ad684539340421be2be2a" Fix an asymptotic bug in the occurrence analyser Trac #12425 and #12234 showed up a major and long-standing bug in the occurrence analyser, whereby it could generate explonentially large program! There's a lot of commentary on #12425; and it's all described in Note [Loop breakers, node scoring, and stability] I did quite a lot of refactoring to make the code comprehensibe again (its structure had bit-rotted rather), so the patch looks bigger than it really is. Hurrah! I did a nofib run to check that I hadn't inadertently ruined anything: -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- fluid -0.3% -1.5% 0.01 0.01 +0.0% parser -0.9% +0.6% 0.04 0.04 +0.0% prolog -0.1% +1.2% 0.00 0.00 +0.0% -------------------------------------------------------------------------------- Min -0.9% -1.5% -8.6% -8.7% +0.0% Max +0.1% +1.2% +7.7% +7.8% +2.4% Geometric Mean -0.2% -0.0% -0.2% -0.3% +0.0% I checked what happened in 'prolog'. It seems that we have a recursive data structure something like this f :: [blah] f x = build (\cn. ...g... ) g :: [blah2] g y = ....(foldr k z (f y)).... If we inline 'f' into 'g' we get better fusion than the other way round, but we don't have any way to spot that at the moment. (I wonder if we could do worker/wrapper for functions returning a 'build'?) It was happening before by a fluke. Anyway I decided to accept this; it's relatively rare I think. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 5 17:42:34 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Dec 2016 17:42:34 -0000 Subject: [GHC] #12425: With -O1 and above causes ghc to use all available memory before being killed by OOM killer In-Reply-To: <044.8db07ee1e56d0d370ac594dbce3dff94@haskell.org> References: <044.8db07ee1e56d0d370ac594dbce3dff94@haskell.org> Message-ID: <059.bb73782a3f8bb2b6406efd695e2e1a4f@haskell.org> #12425: With -O1 and above causes ghc to use all available memory before being killed by OOM killer -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: merge Priority: high | Milestone: 8.0.3 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: performance bug | perf/compiler/T12425 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge * testcase: => perf/compiler/T12425 Comment: I think I nailed this one, in HEAD at least. Can you see if it fixes your original library? Probably worth merging this to 8.0.3 if we produce such a thing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 5 17:43:10 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Dec 2016 17:43:10 -0000 Subject: [GHC] #12548: Exported pattern synonyms does not mark top-level bindings in RHS as used In-Reply-To: <043.97f0b3892f5aded29e0cb9f0f5c452d4@haskell.org> References: <043.97f0b3892f5aded29e0cb9f0f5c452d4@haskell.org> Message-ID: <058.b3b4ab4732c9b30c38ec9f67a02f3d09@haskell.org> #12548: Exported pattern synonyms does not mark top-level bindings in RHS as used -------------------------------------+------------------------------------- Reporter: pkmx | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: | PatternSynonyms, newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | rename/should_compile/T12548 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => rename/should_compile/T12548 * resolution: => fixed Comment: Thanks for the example! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 5 17:43:33 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Dec 2016 17:43:33 -0000 Subject: [GHC] #12925: GHC panic: Can't serialise IfaceTcTyVar In-Reply-To: <050.14e6e8b4799060d85fdbe9ea4c2ffb75@haskell.org> References: <050.14e6e8b4799060d85fdbe9ea4c2ffb75@haskell.org> Message-ID: <065.86dbfe991a0051ca8516b117f35c20fc@haskell.org> #12925: GHC panic: Can't serialise IfaceTcTyVar -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/T12925 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => typecheck/should_compile/T12925 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 5 17:44:31 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Dec 2016 17:44:31 -0000 Subject: [GHC] #12234: 'deriving Eq' on recursive datatype makes ghc eat a lot of CPU and RAM In-Reply-To: <045.352c8bb25c33b092176709513059d519@haskell.org> References: <045.352c8bb25c33b092176709513059d519@haskell.org> Message-ID: <060.edf40727e98bd57cab0be4a047f38b8b@haskell.org> #12234: 'deriving Eq' on recursive datatype makes ghc eat a lot of CPU and RAM -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.3 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: deriving-perf Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: performance bug | perf/should_compile/T12234 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge * testcase: => perf/should_compile/T12234 * milestone: => 8.0.3 Comment: Fixed! Thanks for a great report. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 5 18:33:16 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Dec 2016 18:33:16 -0000 Subject: [GHC] #2168: ghci should show haddock comments for identifier In-Reply-To: <049.47be5fa91ec9885f4a8847376f7f589a@haskell.org> References: <049.47be5fa91ec9885f4a8847376f7f589a@haskell.org> Message-ID: <064.c1055e7973c0432648430a8f28364d7d@haskell.org> #2168: ghci should show haddock comments for identifier -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by davean): * cc: davean (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 5 19:04:15 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Dec 2016 19:04:15 -0000 Subject: [GHC] #12927: Colorized error messages result in hard-to-read .dump-* files Message-ID: <050.4d52d80d1f24b6c29f775c3be2712dc4@haskell.org> #12927: Colorized error messages result in hard-to-read .dump-* files -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #8809 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- To see this, compile this file: {{{#!hs module Main where x :: String -> String x s = print (reverse s + 1) }}} with `ghc-stage2 -ddump-tc-trace -ddump-to-file`. If you look at the resulting `.dump-tc-trace` file with a text editor like `vim`, you'll see at the bottom: {{{ ... Tc7a checkMain fail Main main Adding error: ^[[;1mBug.hs:1:1: ^[[;1m^[[31merror:^[[;1m The IO action ‘main’ is not defined in module ‘Main’^[[0m }}} The error message is now much harder to discern that before the introduction of colorized error messages. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 5 19:05:04 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Dec 2016 19:05:04 -0000 Subject: [GHC] #8809: Prettier error messages? In-Reply-To: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> References: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> Message-ID: <062.48559f3e3f37e281fdda87305fd2a212@haskell.org> #8809: Prettier error messages? -------------------------------------+------------------------------------- Reporter: joelteon | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): #8809,#10073,#10179,#12906 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: #8809,#10073,#10179 => #8809,#10073,#10179,#12906 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 5 19:17:42 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Dec 2016 19:17:42 -0000 Subject: [GHC] #12927: Colorized error messages result in hard-to-read .dump-* files In-Reply-To: <050.4d52d80d1f24b6c29f775c3be2712dc4@haskell.org> References: <050.4d52d80d1f24b6c29f775c3be2712dc4@haskell.org> Message-ID: <065.ffc14064a3ffb7c77c858e9b3c9a31e6@haskell.org> #12927: Colorized error messages result in hard-to-read .dump-* files -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #8809 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): As a workaround, you can use `less -r` to pass the color codes directly on to your terminal. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 5 19:48:41 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Dec 2016 19:48:41 -0000 Subject: [GHC] #12928: Too easy to trigger CUSK condition using TH Message-ID: <048.b87023a4856ac4da5fccc9b82019d18a@haskell.org> #12928: Too easy to trigger CUSK condition using TH -------------------------------------+------------------------------------- Reporter: int-index | Owner: Type: feature | Status: new request | Priority: high | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While trying to make `singletons` class promotion work with kind- polymorphic type variables, I've encountered a problem regarding CUSKs. Consider this class: {{{ $(promoteOnly [d| class Cls a where fff :: Proxy a -> () |]) }}} The generated TH (slightly simplified by hand) looks like this: {{{ type FffSym1 (t_alvm :: Proxy a1627472612) = Fff t_alvm data FffSym0 (l_alvn :: TyFun (Proxy a1627472612) ()) type instance Apply FffSym0 l_alvn = FffSym1 l_alvn class PCls a_alve where type Fff (arg_alvl :: Proxy a_alve) :: () }}} However, it fails to compile with the following error: {{{ cusk.hs:25:1: error: You have written a *complete user-suppled kind signature*, but the following variable is undetermined: k0 :: * Perhaps add a kind signature. Inferred kinds of user-written variables: a1627472612 :: k0 l_alvn :: TyFun (Proxy a1627472612) () }}} As suggested by the error message, we need to specify the kind in its entirety (write a proper CUSK). So to sidestep the issue, we can write {{{ data FffSym0 (l_alvn :: TyFun (Proxy (a1627472612 :: k)) ()) }}} and it'll work. However, this means that the TH code generator should perform some guesswork to modify kind annotations. It sounds like a minefield — too much can go wrong, so it'd be great to avoid doing so. Looking at the module `TcHsType` in the GHC sources, I see that the error is reported by the `kcHsTyVarBndrs` function: {{{ -- If there are any meta-tvs left, the user has -- lied about having a CUSK. Error. ; let (meta_tvs, good_tvs) = partition isMetaTyVar qkvs ; when (not (null meta_tvs)) $ report_non_cusk_tvs (qkvs ++ tc_tvs) }}} However, I don't see why we can't generalize over `meta_tvs` instead of reporting a failure. I asked on IRC #ghc and ezyang suggested that it should be sound. Below I attach a self-contained example that demonstrates the issue and has no dependencies except `base`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 5 19:49:20 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Dec 2016 19:49:20 -0000 Subject: [GHC] #12928: Too easy to trigger CUSK condition using TH In-Reply-To: <048.b87023a4856ac4da5fccc9b82019d18a@haskell.org> References: <048.b87023a4856ac4da5fccc9b82019d18a@haskell.org> Message-ID: <063.9d485ff8738d61a9c809fccb4c532ea1@haskell.org> #12928: Too easy to trigger CUSK condition using TH -------------------------------------+------------------------------------- Reporter: int-index | Owner: Type: feature request | Status: new Priority: high | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by int-index): * Attachment "cusk.hs" added. CUSK failure example -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 5 20:07:24 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Dec 2016 20:07:24 -0000 Subject: [GHC] #12891: Automate symbols inclusion in RtsSymbols.c from Rts.h In-Reply-To: <044.8e57666e14e9a6962358e38e17489ff4@haskell.org> References: <044.8e57666e14e9a6962358e38e17489ff4@haskell.org> Message-ID: <059.1391dc2080b8761a1d27164d5b9d178e@haskell.org> #12891: Automate symbols inclusion in RtsSymbols.c from Rts.h -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12846 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dobenour): Can we use Language-C? It is a C parser written in Haskell, and we could generate the output from the parse tree. Not sure if it can parse everything in `Rts.h`, though. If there is a problem, it would most probably be in the system headers included by `Rts.h`, not `Rts.h` itself. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 5 20:20:30 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Dec 2016 20:20:30 -0000 Subject: [GHC] #12927: Colorized error messages result in hard-to-read .dump-* files In-Reply-To: <050.4d52d80d1f24b6c29f775c3be2712dc4@haskell.org> References: <050.4d52d80d1f24b6c29f775c3be2712dc4@haskell.org> Message-ID: <065.d2de942aaf664c88925f3f4f4fc1e43a@haskell.org> #12927: Colorized error messages result in hard-to-read .dump-* files -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #8809 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Rufflewind): Another workaround would be to pass `-fdiagnostics-color=never` to ghc. I think the right fix would be to not output ANSI color codes except when the destination is stderr. It's a bit tricky though because I'm not sure how to detect this from within `mkLocMessageAnn`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 5 20:51:40 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Dec 2016 20:51:40 -0000 Subject: [GHC] #8809: Prettier error messages? In-Reply-To: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> References: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> Message-ID: <062.2eb7476f8e0ac4cbf826d54444e8ef7d@haskell.org> #8809: Prettier error messages? -------------------------------------+------------------------------------- Reporter: joelteon | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): #8809,#10073,#10179,#12906 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Tamar Christina ): In [changeset:"847d229346431483b99adcff12e46c7bf6af15da/ghc" 847d2293/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="847d229346431483b99adcff12e46c7bf6af15da" Color output is wreaking havoc on test results Summary: D2716 introduced colors into the output of GHC. These color ourputs are done using escape characters output to the terminal. These however are wreaking havoc on the testsuite output as now no stderr with a warning or error will match anymore. Instead of accepting the new codes as expected values instead I turn them off. So the testsuite is consistent on platforms/terminals we don't support colors on. Test Plan: any test that outputs colors. e.g. make test TEST=T9576 Reviewers: austin, Rufflewind, bgamari Subscribers: thomie, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D2787 GHC Trac Issues: #8809 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 5 21:00:58 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Dec 2016 21:00:58 -0000 Subject: [GHC] #12927: Colorized error messages result in hard-to-read .dump-* files In-Reply-To: <050.4d52d80d1f24b6c29f775c3be2712dc4@haskell.org> References: <050.4d52d80d1f24b6c29f775c3be2712dc4@haskell.org> Message-ID: <065.715ae4662502b4885dd09d3bfe276b47@haskell.org> #12927: Colorized error messages result in hard-to-read .dump-* files -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #8809 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Rufflewind): Hope this fixes it: https://phabricator.haskell.org/D2792 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 5 21:08:02 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Dec 2016 21:08:02 -0000 Subject: [GHC] #12928: Too easy to trigger CUSK condition using TH In-Reply-To: <048.b87023a4856ac4da5fccc9b82019d18a@haskell.org> References: <048.b87023a4856ac4da5fccc9b82019d18a@haskell.org> Message-ID: <063.718e203d19d8e3f8d06feda07a2d1ce5@haskell.org> #12928: Too easy to trigger CUSK condition using TH -------------------------------------+------------------------------------- Reporter: int-index | Owner: Type: feature request | Status: new Priority: high | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): ezyang is right -- it would be sound. But it would defeat the purpose of CUSKs. The idea with CUSKs is that they allow a user to specify when everything about the kind of a type-level definition (datatype, newtype, class, family, type synonym) is known, without any inference. When a CUSK is available, GHC can then use polymorphic recursion and other fancy features while checking the type. Without a CUSK, though, inference with polymorphic recursion is impossible. Here is an example: {{{ type family F (a :: k) where F Int = Bool }}} What's the kind of `F`? There are at least two possibilities: `k -> Type` and `k -> k`. Neither is more general than the other. Instead of guessing between these (and others that use kind families!), GHC rejects the definition as lacking a CUSK. Is this an example of polymorphic recursion? Sort of. You can see it as polymorphic recursion if we consider that we're defining `F` but the occurrence of `F` in the equation is specialized to operate at kind `Type`. So it falls under this whole umbrella. Getting back to the original question: we ''could'' generalize here. But then type inference would become unpredictable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 5 21:17:24 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Dec 2016 21:17:24 -0000 Subject: [GHC] #12928: Too easy to trigger CUSK condition using TH In-Reply-To: <048.b87023a4856ac4da5fccc9b82019d18a@haskell.org> References: <048.b87023a4856ac4da5fccc9b82019d18a@haskell.org> Message-ID: <063.05e1c28a3f0e6c687b3b451514ea2acd@haskell.org> #12928: Too easy to trigger CUSK condition using TH -------------------------------------+------------------------------------- Reporter: int-index | Owner: Type: feature request | Status: new Priority: high | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by int-index): How come we don't have a notion of "complete user-supplied type" to support polymorphic recursion at term level? Also I've noticed that with GHC HEAD the error message is way worse: {{{ Cusk.hs:27:15: error: • Illegal type synonym family application in instance: Proxy a1627472612 • In the type instance declaration for ‘Apply’ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 5 21:20:22 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Dec 2016 21:20:22 -0000 Subject: [GHC] #12928: Too easy to trigger CUSK condition using TH In-Reply-To: <048.b87023a4856ac4da5fccc9b82019d18a@haskell.org> References: <048.b87023a4856ac4da5fccc9b82019d18a@haskell.org> Message-ID: <063.26fca383a91eb8cdbff24e6384fd9115@haskell.org> #12928: Too easy to trigger CUSK condition using TH -------------------------------------+------------------------------------- Reporter: int-index | Owner: Type: feature request | Status: new Priority: high | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > How come we don't have a notion of "complete user-supplied type" to support polymorphic recursion at term level and still retain type inference? We do! It's called a type signature. An alternative to the CUSK thing would be to provide for kind siguatures; e.g. {{{ type D :: (* -> *) -> * type D f = f Int }}} We didn't do that because at the time it seemed more syntactically invasive. But it'd make it all much clearer. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 5 21:25:32 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Dec 2016 21:25:32 -0000 Subject: [GHC] #12928: Too easy to trigger CUSK condition using TH In-Reply-To: <048.b87023a4856ac4da5fccc9b82019d18a@haskell.org> References: <048.b87023a4856ac4da5fccc9b82019d18a@haskell.org> Message-ID: <063.f41aed052699d72f7a63c1818bc745b3@haskell.org> #12928: Too easy to trigger CUSK condition using TH -------------------------------------+------------------------------------- Reporter: int-index | Owner: Type: feature request | Status: new Priority: high | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by int-index): Replying to [comment:3 simonpj]: > > We do! It's called a type signature. > It doesn't sound right. In a type signature, I can omit polymorphic kinds. In a CUSK, I cannot. The example in the ticket defines a method `fff` which has a type signature, but `a` is kind-polymorphic: {{{ class Cls a where fff :: Proxy a -> () }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 5 21:45:25 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Dec 2016 21:45:25 -0000 Subject: [GHC] #12928: Too easy to trigger CUSK condition using TH In-Reply-To: <048.b87023a4856ac4da5fccc9b82019d18a@haskell.org> References: <048.b87023a4856ac4da5fccc9b82019d18a@haskell.org> Message-ID: <063.5ffe9596251d3e1363f664b1ac3e1384@haskell.org> #12928: Too easy to trigger CUSK condition using TH -------------------------------------+------------------------------------- Reporter: int-index | Owner: Type: feature request | Status: new Priority: high | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by int-index): The offending definition has this shape: {{{ data FffSym0 (x :: TyFun (Proxy a) ()) }}} and the term-level equivalent is, I believe, this: {{{ fffSym0 :: TyFun (Proxy a) () -> Type; fffSym0 = undefined }}} However, one is accepted and the other is not. The inferred kind of `a` is a polymorphic `k`: {{{ > :type fffSym0 fffSym0 :: forall k (a :: k). TyFun (Proxy k a) () -> Type }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 5 21:50:22 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Dec 2016 21:50:22 -0000 Subject: [GHC] #12726: GHC 8.0.1: ghc --make broken on Raspberry Pi In-Reply-To: <046.2bab883d5f72d72c6b621360247206d3@haskell.org> References: <046.2bab883d5f72d72c6b621360247206d3@haskell.org> Message-ID: <061.3312eab350f0aad44bced416c644bfcb@haskell.org> #12726: GHC 8.0.1: ghc --make broken on Raspberry Pi -------------------------------------+------------------------------------- Reporter: robjhen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: raspberry pi Operating System: Linux | Architecture: arm Type of failure: GHC doesn't work | Test Case: at all | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by brent80): Passing this flag should get it to build -opta-march=armv7-a -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 5 21:52:10 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Dec 2016 21:52:10 -0000 Subject: [GHC] #12929: GHC 8.0.1 Armv7 Missing -N option Message-ID: <046.572c5fba506d1d5a92d3eab04f8793b4@haskell.org> #12929: GHC 8.0.1 Armv7 Missing -N option -------------------------------------+------------------------------------- Reporter: brent80 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: arm armv7 | Operating System: Linux Architecture: arm | Type of failure: Incorrect Test Case: Run program | error/warning at compile-time with +RTS -N2 | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- System: Raspberry Pi 2 running Raspbian Jessie; LLVM 3.7 installed. GHC: GHC 8.0.1 ARMv7 binary downloaded from GHC webpage (ghc-8.0.1-armv7-deb8-linux.tar.xz). gcc version 4.9.2 (Raspbian 4.9.2-10) Compiled program with -threaded Can't run binary with +RTS -N2 ./single-well-micrologix +RTS -N2 single-well-micrologix: unknown RTS option: -N2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 5 22:16:17 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Dec 2016 22:16:17 -0000 Subject: [GHC] #12928: Too easy to trigger CUSK condition using TH In-Reply-To: <048.b87023a4856ac4da5fccc9b82019d18a@haskell.org> References: <048.b87023a4856ac4da5fccc9b82019d18a@haskell.org> Message-ID: <063.df461ecfc8fb3aeffa517c74407b275d@haskell.org> #12928: Too easy to trigger CUSK condition using TH -------------------------------------+------------------------------------- Reporter: int-index | Owner: Type: feature request | Status: new Priority: high | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Right. In ''type signatures'' we look at the type signature '''all by itself''', quite '''independent of the definition''', and generalise any kind variables. So when you write {{{ fffSym0 :: TyFun (Proxy a) () -> Type }}} we'll behave (as you say) as if you wrote: {{{ fffSym0 :: forall k. forall (a:k). TyFun (Proxy a) () -> Type }}} I agree that this would be reasonable behaviour for a type-level kind sinature. Does everyone agree? BUT we don't have separate type-level kind signatures (yet). If we did, yes. But as-is, do we really want to trigger generalisation when (and only when) the CUSK conditions are satisfied. Maybe so...? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 5 22:21:35 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Dec 2016 22:21:35 -0000 Subject: [GHC] #12928: Too easy to trigger CUSK condition using TH In-Reply-To: <048.b87023a4856ac4da5fccc9b82019d18a@haskell.org> References: <048.b87023a4856ac4da5fccc9b82019d18a@haskell.org> Message-ID: <063.b120f0883d2ad93a21b2a09b365f2491@haskell.org> #12928: Too easy to trigger CUSK condition using TH -------------------------------------+------------------------------------- Reporter: int-index | Owner: Type: feature request | Status: new Priority: high | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by int-index): But isn't necessary to provide a separate type signature for `fffSym0`! I can write it like this using scoped type variables: {{{ fffSym0 (x :: TyFun (Proxy a) ()) = undefined :: Type }}} and its type is inferred as before. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 5 22:26:57 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Dec 2016 22:26:57 -0000 Subject: [GHC] #12928: Too easy to trigger CUSK condition using TH In-Reply-To: <048.b87023a4856ac4da5fccc9b82019d18a@haskell.org> References: <048.b87023a4856ac4da5fccc9b82019d18a@haskell.org> Message-ID: <063.66c48155f6d1e42925375d0f818c62bf@haskell.org> #12928: Too easy to trigger CUSK condition using TH -------------------------------------+------------------------------------- Reporter: int-index | Owner: Type: feature request | Status: new Priority: high | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by int-index): Here's a complete GHCi session to demonstrate the asymmetry: {{{ GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help Prelude> :set -XTypeInType -XScopedTypeVariables Prelude> import Data.Proxy Prelude Data.Proxy> import Data.Kind Prelude Data.Proxy Data.Kind> data TyFun :: * -> * -> * Prelude Data.Proxy Data.Kind> fffSym0 (x :: TyFun (Proxy a) ()) = undefined :: Type Prelude Data.Proxy Data.Kind> :type fffSym0 fffSym0 :: forall k (a :: k). TyFun (Proxy a) () -> Type Prelude Data.Proxy Data.Kind> data FffSym0 (x :: TyFun (Proxy a) ()) :: Type :7:1: error: You have written a *complete user-suppled kind signature*, but the following variable is undetermined: k0 :: * Perhaps add a kind signature. Inferred kinds of user-written variables: a :: k0 x :: TyFun (Proxy a) () }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 5 22:35:34 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Dec 2016 22:35:34 -0000 Subject: [GHC] #12929: GHC 8.0.1 Armv7 Missing -N option In-Reply-To: <046.572c5fba506d1d5a92d3eab04f8793b4@haskell.org> References: <046.572c5fba506d1d5a92d3eab04f8793b4@haskell.org> Message-ID: <061.9c666d5b2dc07a4fa0bcd2bad3babfb3@haskell.org> #12929: GHC 8.0.1 Armv7 Missing -N option -------------------------------------+------------------------------------- Reporter: brent80 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: arm armv7 Operating System: Linux | Architecture: arm Type of failure: Incorrect | Test Case: Run program error/warning at compile-time | with +RTS -N2 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by brent80: @@ -8,1 +8,1 @@ - Compiled program with -threaded + Compiled program with -threaded -rtsopts New description: System: Raspberry Pi 2 running Raspbian Jessie; LLVM 3.7 installed. GHC: GHC 8.0.1 ARMv7 binary downloaded from GHC webpage (ghc-8.0.1-armv7-deb8-linux.tar.xz). gcc version 4.9.2 (Raspbian 4.9.2-10) Compiled program with -threaded -rtsopts Can't run binary with +RTS -N2 ./single-well-micrologix +RTS -N2 single-well-micrologix: unknown RTS option: -N2 -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 5 22:39:24 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Dec 2016 22:39:24 -0000 Subject: [GHC] #12928: Too easy to trigger CUSK condition using TH In-Reply-To: <048.b87023a4856ac4da5fccc9b82019d18a@haskell.org> References: <048.b87023a4856ac4da5fccc9b82019d18a@haskell.org> Message-ID: <063.f7c5f58577647e574d2bf08b8e6ff752@haskell.org> #12928: Too easy to trigger CUSK condition using TH -------------------------------------+------------------------------------- Reporter: int-index | Owner: Type: feature request | Status: new Priority: high | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Another way to see the difference is that GHC uses the definition of a type to inform its kinds. That is, {{{ data T a = MkT (a Int) }}} will infer `a :: Type -> Type`. On the other hand, term-level type signatures stand entirely on their own, as Simon says. So, {{{ x :: forall a. Proxy a x = Proxy :: Proxy (a :: Type) }}} is rejected, even though choosing `a :: Type` in the type signature would work here. I've been favoring having standalone type-level kind signatures for some time, and am waiting for the right time to introduce a ghc-proposal to this end. CUSKs are terribly fiddly and very unexpected to users! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 5 23:24:46 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Dec 2016 23:24:46 -0000 Subject: [GHC] #12930: DDEBUG build broken Message-ID: <049.2d7617702d7922f38eb05deb48d908c0@haskell.org> #12930: DDEBUG build broken -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ Again, Travis is failing to build master since a while. Unfortunately, only the author of commits get mailed by Travis, so I did not notice it so far. But usually, when Travis reports a build failure, this is something actionable! If in doubt, contact me. The breakage at the moment occurs only with -DDEBUG on: Compile failed (exit code 1) errors were: ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20161118 for x86_64-unknown-linux): No match in record selector is_iloc Please report this as a GHC bug: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.haskell.org%2Fghc%2Freportabug&data=02%7C01%7Csimonpj%40microsoft.com%7C688619e3295e4b6e0d5d08d41b0a2104%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636163177711116020&sdata=fh8XEV4Ioaxu0KkwKjDbweFvnQiNJ0V5%2BCj%2FQAdKvsY%3D&reserved=0 *** unexpected failure for rn017(normal) Compile failed (exit code 1) errors were: ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20161118 for x86_64-unknown-linux): No match in record selector is_iloc Please report this as a GHC bug: https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.haskell.org%2Fghc%2Freportabug&data=02%7C01%7Csimonpj%40microsoft.com%7C688619e3295e4b6e0d5d08d41b0a2104%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636163177711116020&sdata=fh8XEV4Ioaxu0KkwKjDbweFvnQiNJ0V5%2BCj%2FQAdKvsY%3D&reserved=0 *** unexpected failure for T7672(normal) And started appearing, unless I am mistaken, with From: Matthew Pickering < matthewtpickering at gmail.com > Date: Fri, 18 Nov 2016 16:28:30 +0000 Subject: [PATCH] Optimise whole module exports We directly build up the correct AvailInfos rather than generating lots of singleton instances and combining them with expensive calls to unionLists. There are two other small changes. * Pushed the nubAvails call into the explicit export list branch as we construct them correctly and uniquely ourselves. * fix_faminst only needs to check the first element of the export list as we maintain the (yucky) invariant that the parent is the first thing in it. Reviewers: simonpj, austin, bgamari Reviewed By: simonpj, bgamari Subscribers: simonpj, thomie, niteria Differential Revision: https://phabricator.haskell.org/D2657 Matthew, can you verify that this is a regression introduce here? Greetings, Joachim }}} The failing tests are `rn017` and `T7672`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 6 01:22:43 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Dec 2016 01:22:43 -0000 Subject: [GHC] #9509: No automatic specialization of inlinable imports in 7.8 In-Reply-To: <044.78a0dc81057ff6a68effbbb3815481da@haskell.org> References: <044.78a0dc81057ff6a68effbbb3815481da@haskell.org> Message-ID: <059.b2e7fd2ebb2216feb07733360fb601f1@haskell.org> #9509: No automatic specialization of inlinable imports in 7.8 -------------------------------------+------------------------------------- Reporter: dolio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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: | -------------------------------------+------------------------------------- Comment (by nfrisby): I now have a theory. Based on some of the notes I've found in the source code, I'm concluding (/recalling!) that "unfoldings should only be simplified gently" and "gently implies no eta-expansion". Notably, {{{SimplUtils.updModeForStableUnfoldings}}} sets {{{sm_eta_expand = False}}}, and the simplifier invokes that before entering a stable unfolding or a rule. However, in this case, we're seeing eta-expansion in the unfolding! I believe that is due to [https://github.com/ghc/ghc/blob/876b00ba25a615423f48b0cf9d443a9fd5dbd6f4/compiler/simplCore/SimplUtils.hs#L1294 this use] of {{{gopt Opt_DoLambdaEtaExpansion dflags}}} in {{{SimplUtils.mkLam}}} --- it's checking the {{{DynFlag}}} instead of checking the {{{sm_eta_expand}}} flag within the {{{SimplEnv}}} (which is not passed to {{{mkLam}}}). Parts of the simplifier, notably {{{simplLam}}}, call {{{mkLam}}}. I've made "the fix" locally, and it indeed fixes this ticket's example case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 6 01:53:17 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Dec 2016 01:53:17 -0000 Subject: [GHC] #12425: With -O1 and above causes ghc to use all available memory before being killed by OOM killer In-Reply-To: <044.8db07ee1e56d0d370ac594dbce3dff94@haskell.org> References: <044.8db07ee1e56d0d370ac594dbce3dff94@haskell.org> Message-ID: <059.4f86d95a43b7bd6baa1de204541b4ae0@haskell.org> #12425: With -O1 and above causes ghc to use all available memory before being killed by OOM killer -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: merge Priority: high | Milestone: 8.0.3 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: performance bug | perf/compiler/T12425 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by erikd): I built a compiler from git HEAD, but that wouldn't build the dependencies for my library (numerous problems with the primitve and vector libraries). I tried checking out the `ghc-8.0` branch and then cherry-picking commit d03e41b4f5 but that failed due to merge conflicts in `compiler/simplCore/OccurAnal.hs` that seem rather tricky to resolve. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 6 03:54:41 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Dec 2016 03:54:41 -0000 Subject: [GHC] #12549: Panic on ":t datatypeName" In-Reply-To: <046.93c629409627bd964a188fb34004cca8@haskell.org> References: <046.93c629409627bd964a188fb34004cca8@haskell.org> Message-ID: <061.3e8af23cbf28fecb8cdd16b7f4d5abda@haskell.org> #12549: Panic on ":t datatypeName" ---------------------------------+-------------------------------------- Reporter: johnleo | Owner: johnleo Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 11371 12785 | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Changes (by johnleo): * related: => 11371 12785 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 6 04:13:57 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Dec 2016 04:13:57 -0000 Subject: [GHC] #12931: tc_infer_args does not set in-scope set correctly Message-ID: <046.c5bac8525d250f0afb084b2b372797bb@haskell.org> #12931: tc_infer_args does not set in-scope set correctly -------------------------------------+------------------------------------- Reporter: johnleo | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #12549 #11371 | #12785 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- As noted in https://ghc.haskell.org/trac/ghc/ticket/12785#comment:6, `TcHsType.tc_infer_args` does not set its in-scope set correctly, which means the call to `TcMType.new_meta_tv_x` will fail if `substTyUnchecked` is replaced by `substTy` in the line {{{ kind = substTyUnchecked subst (tyVarKind tv) }}} This is the only known caller of `new_meta_tv_x` to not set the in-scope set, now that #12549 has been fixed. Once this bug is fixed, change `substTyUnchecked` back to `substTy` in the line noted above. Note that other calls to `substTyUnchecked` that need to be converted to `substTy` are covered in the general ticket #11371. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 6 04:15:40 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Dec 2016 04:15:40 -0000 Subject: [GHC] #12549: Panic on ":t datatypeName" In-Reply-To: <046.93c629409627bd964a188fb34004cca8@haskell.org> References: <046.93c629409627bd964a188fb34004cca8@haskell.org> Message-ID: <061.4c355574afd7ee1f664dec5b660a90fd@haskell.org> #12549: Panic on ":t datatypeName" -------------------------------------+------------------------------------- Reporter: johnleo | Owner: johnleo Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11371 #12785 | Differential Rev(s): #12931 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by johnleo): * status: new => closed * resolution: => fixed * related: 11371 12785 => #11371 #12785 #12931 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 6 04:22:57 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Dec 2016 04:22:57 -0000 Subject: [GHC] #12549: Panic on ":t datatypeName" In-Reply-To: <046.93c629409627bd964a188fb34004cca8@haskell.org> References: <046.93c629409627bd964a188fb34004cca8@haskell.org> Message-ID: <061.09a0357afdbac5b077aefeaf294187d3@haskell.org> #12549: Panic on ":t datatypeName" -------------------------------------+------------------------------------- Reporter: johnleo | Owner: johnleo Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11371 #12785 | Differential Rev(s): #12931 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by johnleo): I created a new bug for `tc_infer_args` (#12931) and set the owner to Richard. Regarding other uses of `substTyUnchecked`, there is already the existing bug #11371, which was left open to address them (see https://ghc.haskell.org/trac/ghc/ticket/11371#comment:51). I count at least 35 calls to `substTyUnchecked` (run `grep substTyUnchecked */*.hs` in the compiler directory); I'm not sure if it's worth listing them all in the bug. I'm closing this bug as fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 6 05:58:29 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Dec 2016 05:58:29 -0000 Subject: [GHC] #9291: Don't reconstruct sum types if the type subtly changes In-Reply-To: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> References: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> Message-ID: <061.9dc946fd69085c53ef7af03428e7159c@haskell.org> #9291: Don't reconstruct sum types if the type subtly changes -------------------------------------+------------------------------------- Reporter: schyler | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 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: | -------------------------------------+------------------------------------- Comment (by osa1): Is this related with typed-ness of the IR? I think if we do some of the transformations we do during `coreToStg` we would have the same problem in Core too. I'm wondering if a solution could be as simple as treating state tokens as different from each other when comparing expressions... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 6 08:27:55 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Dec 2016 08:27:55 -0000 Subject: [GHC] #12425: With -O1 and above causes ghc to use all available memory before being killed by OOM killer In-Reply-To: <044.8db07ee1e56d0d370ac594dbce3dff94@haskell.org> References: <044.8db07ee1e56d0d370ac594dbce3dff94@haskell.org> Message-ID: <059.410fdf0c82db38244243b2052da8245d@haskell.org> #12425: With -O1 and above causes ghc to use all available memory before being killed by OOM killer -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: merge Priority: high | Milestone: 8.0.3 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: performance bug | perf/compiler/T12425 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Thanks for trying. I think this would be retro-fittable to 8.0.3 with a bit of work -- if it really matters. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 6 11:50:57 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Dec 2016 11:50:57 -0000 Subject: [GHC] #12931: tc_infer_args does not set in-scope set correctly In-Reply-To: <046.c5bac8525d250f0afb084b2b372797bb@haskell.org> References: <046.c5bac8525d250f0afb084b2b372797bb@haskell.org> Message-ID: <061.8592d85ef7dfc34a3c87cbcdec039d6d@haskell.org> #12931: tc_infer_args does not set in-scope set correctly -------------------------------------+------------------------------------- Reporter: johnleo | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12549 #11371 | Differential Rev(s): #12785 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => TypeInType Comment: Richard, may be you can look at this in due course? `tc_infer_args` is (uncomfortably) a mystery to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 6 12:13:41 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Dec 2016 12:13:41 -0000 Subject: [GHC] #12932: -fexternal-interpreter` fails to find symbols Message-ID: <046.e268f025fb07ea6927f21c0906b2681d@haskell.org> #12932: -fexternal-interpreter` fails to find symbols ----------------------------------------+---------------------------- Reporter: dominic | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+---------------------------- {{{-fexternal-interpreter}}} fails to find symbols but if I run without it all is well. Is this a bug or am I doing something wrong? {{{ ~/Dropbox/Private/Stochastic/demo $ ghci -fexternal-interpreter -prof fe- handling-example.o -i../../monad-bayes/src -package-db=.cabal- sandbox/x86_64-osx-ghc-8.0.1-packages.conf.d -L/usr/local/opt/openblas/lib -lopenblas ghci -fexternal-interpreter -prof fe-handling-example.o -i../../monad- bayes/src -package-db=.cabal-sandbox/x86_64-osx-ghc-8.0.1-packages.conf.d -L/usr/local/opt/openblas/lib -lopenblas GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help Prelude> :l app/Main.hs :l app/Main.hs [ 1 of 16] Compiling Control.Monad.Bayes.LogDomain ( ../../monad- bayes/src/Control/Monad/Bayes/LogDomain.hs, interpreted ) [ 2 of 16] Compiling Control.Monad.Bayes.Primitive ( ../../monad- bayes/src/Control/Monad/Bayes/Primitive.hs, interpreted ) [ 3 of 16] Compiling Control.Monad.Bayes.Class ( ../../monad- bayes/src/Control/Monad/Bayes/Class.hs, interpreted ) [ 4 of 16] Compiling Control.Monad.Bayes.Sampler ( ../../monad- bayes/src/Control/Monad/Bayes/Sampler.hs, interpreted ) [ 5 of 16] Compiling Control.Monad.Bayes.Sequential ( ../../monad- bayes/src/Control/Monad/Bayes/Sequential.hs, interpreted ) [ 6 of 16] Compiling Control.Monad.Bayes.Prior ( ../../monad- bayes/src/Control/Monad/Bayes/Prior.hs, interpreted ) [ 7 of 16] Compiling Control.Monad.Bayes.Rejection ( ../../monad- bayes/src/Control/Monad/Bayes/Rejection.hs, interpreted ) [ 8 of 16] Compiling Control.Monad.Bayes.Weighted ( ../../monad- bayes/src/Control/Monad/Bayes/Weighted.hs, interpreted ) [ 9 of 16] Compiling Control.Monad.Bayes.Population ( ../../monad- bayes/src/Control/Monad/Bayes/Population.hs, interpreted ) [10 of 16] Compiling Control.Monad.Bayes.Deterministic ( ../../monad- bayes/src/Control/Monad/Bayes/Deterministic.hs, interpreted ) [11 of 16] Compiling Control.Monad.Bayes.Conditional ( ../../monad- bayes/src/Control/Monad/Bayes/Conditional.hs, interpreted ) [12 of 16] Compiling Control.Monad.Bayes.Dist ( ../../monad- bayes/src/Control/Monad/Bayes/Dist.hs, interpreted ) [13 of 16] Compiling Control.Monad.Bayes.Coprimitive ( ../../monad- bayes/src/Control/Monad/Bayes/Coprimitive.hs, interpreted ) [14 of 16] Compiling Control.Monad.Bayes.Trace ( ../../monad- bayes/src/Control/Monad/Bayes/Trace.hs, interpreted ) [15 of 16] Compiling Control.Monad.Bayes.Inference ( ../../monad- bayes/src/Control/Monad/Bayes/Inference.hs, interpreted ) [16 of 16] Compiling Main ( app/Main.hs, interpreted ) Ok, modules loaded: Main, Control.Monad.Bayes.LogDomain, Control.Monad.Bayes.Primitive, Control.Monad.Bayes.Class, Control.Monad.Bayes.Population, Control.Monad.Bayes.Conditional, Control.Monad.Bayes.Inference, Control.Monad.Bayes.Sampler, Control.Monad.Bayes.Rejection, Control.Monad.Bayes.Weighted, Control.Monad.Bayes.Sequential, Control.Monad.Bayes.Trace, Control.Monad.Bayes.Dist, Control.Monad.Bayes.Prior, Control.Monad.Bayes.Deterministic, Control.Monad.Bayes.Coprimitive. *Main> main main ghc-iserv-prof: lookupSymbol failed in relocateSection (relocate external) /Users/dom/Dropbox/Private/Stochastic/demo/.cabal-sandbox/lib/x86_64-osx- ghc-8.0.1/hmatrix-0.18.0.0-ASQ7f3Yo6PP5MiGTxN80a6/libHShmatrix-0.18.0.0-ASQ7f3Yo6PP5MiGTxN80a6_p.a: unknown symbol `___ieee_divdc3' ghc-iserv-prof: Could not on-demand load symbol '_vectorScan' ghc-iserv-prof: lookupSymbol failed in relocateSection (relocate external) /Users/dom/Dropbox/Private/Stochastic/demo/.cabal-sandbox/lib/x86_64-osx- ghc-8.0.1/hmatrix-0.18.0.0-ASQ7f3Yo6PP5MiGTxN80a6/libHShmatrix-0.18.0.0-ASQ7f3Yo6PP5MiGTxN80a6_p.a: unknown symbol `_vectorScan' ghc-iserv-prof: Could not on-demand load symbol '_hmatrixzm0zi18zi0zi0zmASQ7f3Yo6PP5MiGTxN80a6_InternalziVectorizzed_constantAux_closure' ghc-iserv-prof: lookupSymbol failed in relocateSection (relocate external) /Users/dom/Dropbox/Private/Stochastic/demo/.cabal-sandbox/lib/x86_64-osx- ghc-8.0.1/hmatrix-0.18.0.0-ASQ7f3Yo6PP5MiGTxN80a6/libHShmatrix-0.18.0.0-ASQ7f3Yo6PP5MiGTxN80a6_p.a: unknown symbol `_hmatrixzm0zi18zi0zi0zmASQ7f3Yo6PP5MiGTxN80a6_InternalziVectorizzed_constantAux_closure' ghc-iserv-prof: Could not on-demand load symbol '_hmatrixzm0zi18zi0zi0zmASQ7f3Yo6PP5MiGTxN80a6_InternalziMatrix_Matrix_con_info' ghc-iserv-prof: lookupSymbol failed in relocateSection (relocate external) /Users/dom/Dropbox/Private/Stochastic/demo/.cabal-sandbox/lib/x86_64-osx- ghc-8.0.1/hmatrix-0.18.0.0-ASQ7f3Yo6PP5MiGTxN80a6/libHShmatrix-0.18.0.0-ASQ7f3Yo6PP5MiGTxN80a6_p.a: unknown symbol `_hmatrixzm0zi18zi0zi0zmASQ7f3Yo6PP5MiGTxN80a6_InternalziMatrix_Matrix_con_info' ghc-iserv-prof: Could not on-demand load symbol '_hmatrixzm0zi18zi0zi0zmASQ7f3Yo6PP5MiGTxN80a6_InternalziElement_zgzl_info' ghc-iserv-prof: lookupSymbol failed in relocateSection (relocate external) /Users/dom/Dropbox/Private/Stochastic/demo/.cabal-sandbox/lib/x86_64-osx- ghc-8.0.1/hmatrix-0.18.0.0-ASQ7f3Yo6PP5MiGTxN80a6/libHShmatrix-0.18.0.0-ASQ7f3Yo6PP5MiGTxN80a6_p.a: unknown symbol `_hmatrixzm0zi18zi0zi0zmASQ7f3Yo6PP5MiGTxN80a6_InternalziElement_zgzl_info' ghc-iserv-prof: Could not on-demand load symbol '_hmatrixzm0zi18zi0zi0zmASQ7f3Yo6PP5MiGTxN80a6_InternalziUtil_zdfIndexableVectorDouble_closure' ByteCodeLink.lookupCE During interactive linking, GHCi couldn't find the following symbol: hmatrixzm0zi18zi0zi0zmASQ7f3Yo6PP5MiGTxN80a6_InternalziUtil_zdfIndexableVectorDouble_closure This may be due to you not asking GHCi to load extra object files, archives or DLLs needed by your current session. Restart GHCi, specifying the missing library using the -L/path/to/object/dir and -lmissinglibname flags, or simply by naming the relevant files on the GHCi command line. Alternatively, this link failure might indicate a bug in GHCi. If you suspect the latter, please send a bug report to: glasgow-haskell-bugs at haskell.org *Main> }}} But without {{{-fexternal-interpreter}}} all is well. {{{ ~/Dropbox/Private/Stochastic/demo $ ghci -prof fe-handling-example.o -i ../../monad-bayes/src -package-db=.cabal-sandbox/x86_64-osx- ghc-8.0.1-packages.conf.d -L/usr/local/opt/openblas/lib -lopenblas ghci -prof fe-handling-example.o -i../../monad-bayes/src -package-db =.cabal-sandbox/x86_64-osx-ghc-8.0.1-packages.conf.d -L/usr/local/opt/openblas/lib -lopenblas GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help Prelude> :l app/Main.hs :l app/Main.hs [ 1 of 16] Compiling Control.Monad.Bayes.LogDomain ( ../../monad- bayes/src/Control/Monad/Bayes/LogDomain.hs, interpreted ) [ 2 of 16] Compiling Control.Monad.Bayes.Primitive ( ../../monad- bayes/src/Control/Monad/Bayes/Primitive.hs, interpreted ) [ 3 of 16] Compiling Control.Monad.Bayes.Class ( ../../monad- bayes/src/Control/Monad/Bayes/Class.hs, interpreted ) [ 4 of 16] Compiling Control.Monad.Bayes.Sampler ( ../../monad- bayes/src/Control/Monad/Bayes/Sampler.hs, interpreted ) [ 5 of 16] Compiling Control.Monad.Bayes.Sequential ( ../../monad- bayes/src/Control/Monad/Bayes/Sequential.hs, interpreted ) [ 6 of 16] Compiling Control.Monad.Bayes.Prior ( ../../monad- bayes/src/Control/Monad/Bayes/Prior.hs, interpreted ) [ 7 of 16] Compiling Control.Monad.Bayes.Rejection ( ../../monad- bayes/src/Control/Monad/Bayes/Rejection.hs, interpreted ) [ 8 of 16] Compiling Control.Monad.Bayes.Weighted ( ../../monad- bayes/src/Control/Monad/Bayes/Weighted.hs, interpreted ) [ 9 of 16] Compiling Control.Monad.Bayes.Population ( ../../monad- bayes/src/Control/Monad/Bayes/Population.hs, interpreted ) [10 of 16] Compiling Control.Monad.Bayes.Deterministic ( ../../monad- bayes/src/Control/Monad/Bayes/Deterministic.hs, interpreted ) [11 of 16] Compiling Control.Monad.Bayes.Conditional ( ../../monad- bayes/src/Control/Monad/Bayes/Conditional.hs, interpreted ) [12 of 16] Compiling Control.Monad.Bayes.Dist ( ../../monad- bayes/src/Control/Monad/Bayes/Dist.hs, interpreted ) [13 of 16] Compiling Control.Monad.Bayes.Coprimitive ( ../../monad- bayes/src/Control/Monad/Bayes/Coprimitive.hs, interpreted ) [14 of 16] Compiling Control.Monad.Bayes.Trace ( ../../monad- bayes/src/Control/Monad/Bayes/Trace.hs, interpreted ) [15 of 16] Compiling Control.Monad.Bayes.Inference ( ../../monad- bayes/src/Control/Monad/Bayes/Inference.hs, interpreted ) [16 of 16] Compiling Main ( app/Main.hs, interpreted ) Ok, modules loaded: Main, Control.Monad.Bayes.LogDomain, Control.Monad.Bayes.Primitive, Control.Monad.Bayes.Class, Control.Monad.Bayes.Population, Control.Monad.Bayes.Conditional, Control.Monad.Bayes.Inference, Control.Monad.Bayes.Sampler, Control.Monad.Bayes.Rejection, Control.Monad.Bayes.Weighted, Control.Monad.Bayes.Sequential, Control.Monad.Bayes.Trace, Control.Monad.Bayes.Dist, Control.Monad.Bayes.Prior, Control.Monad.Bayes.Deterministic, Control.Monad.Bayes.Coprimitive. *Main> main main Old State: S {p = 96.41248458072532, z = 59.16931688468654, log_alpha = -3.3251317115519465} New state: S {p = 85.18277032500659, z = 47.518663747379414, log_alpha = -0.8056624325046409} Old State: S {p = 110.26606081933504, z = 47.25472896292412, log_alpha = -7.942692650345256} New state: S {p = 99.8466327066433, z = 38.81428385855752, log_alpha = -0.712367347081303} Old State: S {p = 101.53403093173365, z = 54.69189565042656, log_alpha = 0.797288536547407} New state: S {p = 101.52281529166201, z = 44.30057747486097, log_alpha = -2.015330785654092} Old State: S {p = 77.31689464064326, z = 46.619899785065876, log_alpha = 2.2759251158534526} New state: S {p = 116.2875593953072, z = 38.966471329788355, log_alpha = -0.7142394862058071} Old State: S {p = 76.9380013726558, z = 50.125629063113514, log_alpha = -3.2499432321011583} New state: S {p = 69.40844025380522, z = 41.55282023557805, log_alpha = -3.0159942091527503e-2} Old State: S {p = 69.40844025380522, z = 41.55282023557805, log_alpha = -3.0159942091527503e-2} New state: S {p = 68.03763906369906, z = 35.283787110815105, log_alpha = 1.3054304633451674} Old State: S {p = 69.40844025380522, z = 41.55282023557805, log_alpha = -3.0159942091527503e-2} New state: S {p = 68.03763906369906, z = 35.283787110815105, log_alpha = -0.9916988019989725} Old State: S {p = 69.40844025380522, z = 41.55282023557805, log_alpha = -3.0159942091527503e-2} New state: S {p = 68.03763906369906, z = 35.283787110815105, log_alpha = -3.611295894501775} Old State: S {p = 69.40844025380522, z = 41.55282023557805, log_alpha = -3.0159942091527503e-2} New state: S {p = 68.03763906369906, z = 35.283787110815105, log_alpha = -0.7617210597518349} Old State: S {p = 116.2875593953072, z = 38.966471329788355, log_alpha = -0.7142394862058071} New state: S {p = 109.6078122188652, z = 32.55851436113107, log_alpha = -0.4233108619474501} Old State: S {p = 68.03763906369906, z = 35.283787110815105, log_alpha = 1.3054304633451674} New state: S {p = 79.79830336014518, z = 30.422294131721443, log_alpha = 0.6993690927536277} Old State: S {p = 68.03763906369906, z = 35.283787110815105, log_alpha = -0.9916988019989725} New state: S {p = 64.90164005295357, z = 30.422294131721443, log_alpha = -0.3152970276116467} Old State: S {p = 68.03763906369906, z = 35.283787110815105, log_alpha = -0.9916988019989725} New state: S {p = 64.90164005295357, z = 30.422294131721443, log_alpha = -0.8415339406842459} Old State: S {p = 68.03763906369906, z = 35.283787110815105, log_alpha = 1.3054304633451674} New state: S {p = 79.79830336014518, z = 30.422294131721443, log_alpha = -0.755338763976243} Old State: S {p = 68.03763906369906, z = 35.283787110815105, log_alpha = -0.9916988019989725} New state: S {p = 64.90164005295357, z = 30.422294131721443, log_alpha = -0.12244882682932601} Old State: S {p = 103.98419668715715, z = 51.46501997223569, log_alpha = NaN} New state: S {p = NaN, z = 41.96850310814045, log_alpha = -2.6446936218209336} Old State: S {p = 101.59457288618177, z = 50.895296415987694, log_alpha = NaN} New state: S {p = NaN, z = 41.61054780428653, log_alpha = -3.429882621028084} Old State: S {p = 87.94516676609489, z = 49.33016788299561, log_alpha = NaN} New state: S {p = NaN, z = 40.75469030451892, log_alpha = -0.3548643358912281} Old State: S {p = 85.99795164317248, z = 49.168021162595345, log_alpha = NaN} New state: S {p = NaN, z = 40.67497206346814, log_alpha = 2.1104720283005785} Old State: S {p = 78.54647250550833, z = 42.630247908299566, log_alpha = NaN} New state: S {p = NaN, z = 35.95097968042852, log_alpha = -0.6513484233809421} Old State: S {p = NaN, z = 40.75469030451892, log_alpha = -0.3548643358912281} New state: S {p = NaN, z = NaN, log_alpha = -1.5720943792122584} Old State: S {p = NaN, z = 40.75469030451892, log_alpha = -0.3548643358912281} New state: S {p = NaN, z = NaN, log_alpha = -1.6631770526157945} Old State: S {p = NaN, z = 40.67497206346814, log_alpha = 2.1104720283005785} New state: S {p = NaN, z = NaN, log_alpha = -1.2345329390236304} Old State: S {p = NaN, z = 35.95097968042852, log_alpha = -0.6513484233809421} New state: S {p = NaN, z = NaN, log_alpha = -1.820929341136602} Old State: S {p = NaN, z = 40.67497206346814, log_alpha = 2.1104720283005785} New state: S {p = NaN, z = NaN, log_alpha = -2.520535318849168} Old State: S {p = NaN, z = NaN, log_alpha = -1.5720943792122584} New state: S {p = NaN, z = NaN, log_alpha = -0.9471390581854239} Old State: S {p = NaN, z = NaN, log_alpha = -1.6631770526157945} New state: S {p = NaN, z = NaN, log_alpha = -1.0755021237404696} Old State: S {p = NaN, z = NaN, log_alpha = -1.2345329390236304} New state: S {p = NaN, z = NaN, log_alpha = -1.1239335260594507} Old State: S {p = NaN, z = NaN, log_alpha = -1.820929341136602} New state: S {p = NaN, z = NaN, log_alpha = -1.2944498914356701} Old State: S {p = NaN, z = NaN, log_alpha = -2.520535318849168} New state: S {p = NaN, z = NaN, log_alpha = -0.27411572356967484} Accept: False Old State: S {p = 111.8506804060528, z = 49.43995360167743, log_alpha = -9.192660539879242} New state: S {p = 100.79139727821112, z = 40.36178045350178, log_alpha = 1.3407944594098864} Old State: S {p = 112.56620850387993, z = 51.36209895306485, log_alpha = -2.625437037736268} New state: S {p = 101.35925858189091, z = 41.718829881234356, log_alpha = -0.7240542276022712} Old State: S {p = 124.03888190950703, z = 60.73043151177312, log_alpha = -5.946495216000299} New state: S {p = 108.98533165239414, z = 47.91166969904897, log_alpha = -0.8873500091662709} Old State: S {p = 98.02675197633516, z = 52.91365067391672, log_alpha = 2.312571443928833} New state: S {p = 138.1350004691826, z = 43.12261446736768, log_alpha = -0.2792667910662988} Old State: S {p = 94.54575888175407, z = 42.83674832921917, log_alpha = -7.3217354704711175} New state: S {p = 86.44898836218327, z = 35.83329122968358, log_alpha = -0.6931069199421952} Old State: S {p = 86.44898836218327, z = 35.83329122968358, log_alpha = -0.6931069199421952} New state: S {p = 82.70767613536381, z = 30.592809349196145, log_alpha = 0.3349397265296642} Old State: S {p = 86.44898836218327, z = 35.83329122968358, log_alpha = -0.6931069199421952} New state: S {p = 82.70767613536381, z = 30.592809349196145, log_alpha = -1.3495963112508207} Old State: S {p = 138.1350004691826, z = 43.12261446736768, log_alpha = -0.2792667910662988} New state: S {p = 129.45324316753013, z = 35.29589318379763, log_alpha = -0.386669465854595} Old State: S {p = 138.1350004691826, z = 43.12261446736768, log_alpha = -0.2792667910662988} New state: S {p = 129.45324316753013, z = 35.29589318379763, log_alpha = -0.2946746748816039} Old State: S {p = 138.1350004691826, z = 43.12261446736768, log_alpha = -0.2792667910662988} New state: S {p = 129.45324316753013, z = 35.29589318379763, log_alpha = 6.008701708774278e-2} Old State: S {p = 82.70767613536381, z = 30.592809349196145, log_alpha = 0.3349397265296642} New state: S {p = 84.42743985481702, z = 26.485152940386072, log_alpha = -0.8565266788034482} Old State: S {p = 82.70767613536381, z = 30.592809349196145, log_alpha = -1.3495963112508207} New state: S {p = 78.90510523061384, z = 26.485152940386072, log_alpha = -0.23947594100584424} Old State: S {p = 82.70767613536381, z = 30.592809349196145, log_alpha = -1.3495963112508207} New state: S {p = 78.90510523061384, z = 26.485152940386072, log_alpha = -1.6400685168014388} Old State: S {p = 82.70767613536381, z = 30.592809349196145, log_alpha = -1.3495963112508207} New state: S {p = 78.90510523061384, z = 26.485152940386072, log_alpha = -2.309718174473867} Old State: S {p = 82.70767613536381, z = 30.592809349196145, log_alpha = 0.3349397265296642} New state: S {p = 84.42743985481702, z = 26.485152940386072, log_alpha = 0.39960426429090445} Old State: S {p = 103.15456652417501, z = 48.70703230482669, log_alpha = 3.261489684559035} New state: S {p = 223.41791271148057, z = 40.00425989911341, log_alpha = -1.6654810839749887} Old State: S {p = 78.21539356172975, z = 49.34769089107648, log_alpha = 2.9941081783405235} New state: S {p = 165.5956281460007, z = 40.9594944371077, log_alpha = -0.6807278054716505} Old State: S {p = 121.27107377910983, z = 50.9432853913191, log_alpha = -8.126318808529764} New state: S {p = 108.916591323712, z = 41.2439385542472, log_alpha = 0.4369643557823619} Old State: S {p = 98.33533600637841, z = 50.915794054555995, log_alpha = -0.47638340582836275} New state: S {p = 91.42595876935069, z = 41.6915974374073, log_alpha = -1.570488913622821} Old State: S {p = 106.35901771371051, z = 58.39939541846798, log_alpha = 2.4859548939567686} New state: S {p = 153.7564635774571, z = 46.75791989853097, log_alpha = -0.7265425179819862} Old State: S {p = 165.5956281460007, z = 40.9594944371077, log_alpha = -0.6807278054716505} New state: S {p = 153.47230437543251, z = 33.25266900659429, log_alpha = -1.6781162212290632} Old State: S {p = 165.5956281460007, z = 40.9594944371077, log_alpha = -0.6807278054716505} New state: S {p = 153.47230437543251, z = 33.25266900659429, log_alpha = 0.7148953771487301} Old State: S {p = 165.5956281460007, z = 40.9594944371077, log_alpha = -0.6807278054716505} New state: S {p = 153.47230437543251, z = 33.25266900659429, log_alpha = 1.2994581914331431} Old State: S {p = 165.5956281460007, z = 40.9594944371077, log_alpha = -0.6807278054716505} New state: S {p = 153.47230437543251, z = 33.25266900659429, log_alpha = -0.6908099313919266} Old State: S {p = 165.5956281460007, z = 40.9594944371077, log_alpha = -0.6807278054716505} New state: S {p = 153.47230437543251, z = 33.25266900659429, log_alpha = 0.6115450247483429} Old State: S {p = 153.47230437543251, z = 33.25266900659429, log_alpha = 0.6115450247483429} New state: S {p = 149.84673299439467, z = 27.669736758576065, log_alpha = 2.249112097719827} Old State: S {p = 153.47230437543251, z = 33.25266900659429, log_alpha = 0.7148953771487301} New state: S {p = 150.56328821556426, z = 27.669736758576065, log_alpha = -1.6634676360703886} Old State: S {p = 153.47230437543251, z = 33.25266900659429, log_alpha = 0.6115450247483429} New state: S {p = 149.84673299439467, z = 27.669736758576065, log_alpha = -1.1143896901497614} Old State: S {p = 153.47230437543251, z = 33.25266900659429, log_alpha = -1.6781162212290632} New state: S {p = 143.93225309113896, z = 27.669736758576065, log_alpha = 1.2174133795952156} Old State: S {p = 153.47230437543251, z = 33.25266900659429, log_alpha = -1.6781162212290632} New state: S {p = 143.93225309113896, z = 27.669736758576065, log_alpha = 0.2956142597127277} Accept: False 4.962072576592402e-2 7.408640679453008 *Main> }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 6 12:26:32 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Dec 2016 12:26:32 -0000 Subject: [GHC] #12927: Colorized error messages result in hard-to-read .dump-* files In-Reply-To: <050.4d52d80d1f24b6c29f775c3be2712dc4@haskell.org> References: <050.4d52d80d1f24b6c29f775c3be2712dc4@haskell.org> Message-ID: <065.8410e71a9c7f11ebfb08366a372e4361@haskell.org> #12927: Colorized error messages result in hard-to-read .dump-* files -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #8809 | Differential Rev(s): Phab:D2792 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => patch * differential: => Phab:D2792 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 6 14:04:57 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Dec 2016 14:04:57 -0000 Subject: [GHC] #12911: Levity polymorphism check eliminates non-levity-polymorphic data constructor In-Reply-To: <047.553556d51b1a72154ff5eadb4d1146d2@haskell.org> References: <047.553556d51b1a72154ff5eadb4d1146d2@haskell.org> Message-ID: <062.acc3c3a0e12e035698b3a9fb22579701@haskell.org> #12911: Levity polymorphism check eliminates non-levity-polymorphic data constructor -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes, that's over-restrictive; when Richard gets around to implementing the paper (which is very much on his radar I think) it'll be fixed! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 6 14:05:42 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Dec 2016 14:05:42 -0000 Subject: [GHC] #12708: RFC: Representation polymorphic Num In-Reply-To: <051.e9ad721b0c060306ebd4bf7d4de38fdd@haskell.org> References: <051.e9ad721b0c060306ebd4bf7d4de38fdd@haskell.org> Message-ID: <066.b1fe9f02dcfdc3a42ec8c3851a5f0493@haskell.org> #12708: RFC: Representation polymorphic Num -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.1 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: @@ -98,1 +98,1 @@ - fmap :: (b -> b') -> ((# a, b #) -> (# a, b'#)) + fmap :: (b -> b') -> ((# a, b #) -> (# a, b' #)) @@ -105,1 +105,1 @@ - instance Monoid m => Applicative ((# , #) m) where + instance Monoid m => Applicative ((# , #) m) where New description: I can create a GHC proposal for this but I need a sanity check first {{{#!hs import Prelude hiding (Num (..)) import qualified Prelude as P import GHC.Prim import GHC.Types class Num (a :: TYPE k) where (+) :: a -> a -> a (-) :: a -> a -> a (*) :: a -> a -> a negate :: a -> a abs :: a -> a signum :: a -> a fromInteger :: Integer -> a instance Num Int# where (+) :: Int# -> Int# -> Int# (+) = (+#) (-) :: Int# -> Int# -> Int# (-) = (-#) (*) :: Int# -> Int# -> Int# (*) = (*#) negate :: Int# -> Int# negate = negateInt# ... fromInteger :: Integer -> Int# fromInteger (fromInteger @PtrRepLifted @Int -> I# int) = int instance Num Double# where (+) :: Double# -> Double# -> Double# (+) = (+##) (-) :: Double# -> Double# -> Double# (-) = (-##) (*) :: Double# -> Double# -> Double# (*) = (*##) negate :: Double# -> Double# negate = negateDouble# ... fromInteger :: Integer -> Double# fromInteger (fromInteger @PtrRepLifted @Double -> D# dbl) = dbl }}} Note how the `fromInteger` views aren't qualified? That's because we can branch on the kind and all of a sudden, all instances of old `Num` are instances of our `Num` {{{#!hs instance P.Num a => Num (a :: Type) where (+) = (P.+) @a (-) = (P.-) @a (*) = (P.*) @a negate = P.negate @a abs = P.abs @a signum = P.signum @a fromInteger = P.fromInteger @a }}} ---- Same with `Show` etc. etc. {{{#!hs class Show (a :: TYPE k) where show :: (a :: TYPE k) -> String instance P.Show a => Show (a :: Type) where show :: (a :: Type) -> String show = P.show @a instance Show (Int# :: TYPE IntRep) where show :: Int# -> String show int = show @PtrRepLifted @Int (I# int) instance Show (Double# :: TYPE DoubleRep) where show :: Double# -> String show dbl = show @PtrRepLifted @Double (D# dbl) }}} {{{#!hs class Functor (f :: Type -> TYPE rep) where fmap :: (a -> b) -> (f a -> f b) instance Functor ((# , #) a) where fmap :: (b -> b') -> ((# a, b #) -> (# a, b' #)) fmap f (# a, b #) = (# a, f b #) class Applicative (f :: Type -> TYPE rep) where pure :: a -> f a (<*>) :: f (a -> b) -> (f a -> f b) instance Monoid m => Applicative ((# , #) m) where pure :: a -> (# m, a #) pure a = (# mempty, a #) (<*>) :: (# m, a -> b #) -> ((# m, a #) -> (# m, b #)) (# m1, f #) <*> (# m2, x #) = (# m1 <> m2, f x #) class Foldable (f :: Type -> TYPE rep) where fold :: Monoid m => f m -> m instance Foldable ((# , #) xx) where fold :: Monoid m => (# xx, m #) -> m fold (# _, m #) = m }}} halp where does this end ---- What effects would this have? They are even printed the same by default {{{#!hs Prelude.Num :: * -> Constraint Main.Num :: * -> Constraint -- >>> :set -fprint-explicit-runtime-reps Prelude.Num :: * -> Constraint Main.Num :: TYPE k -> Constraint -- >>> :set -fprint-explicit-foralls Prelude.Num :: * -> Constraint Main.Num :: forall (k :: RuntimeRep). TYPE k -> Constraint }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 6 14:07:13 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Dec 2016 14:07:13 -0000 Subject: [GHC] #12784: Typechecker regression in GHC 8.0.2 involving DefaultSignatures In-Reply-To: <050.9a0edf2bdaab8860178dd08e2e10d2b7@haskell.org> References: <050.9a0edf2bdaab8860178dd08e2e10d2b7@haskell.org> Message-ID: <065.fc4bc00f9f06ef7ffd60b395f464d805@haskell.org> #12784: Typechecker regression in GHC 8.0.2 involving DefaultSignatures -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: patch Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #12918 | Differential Rev(s): Phab:D2682, Wiki Page: | Phab:D2786 -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"eec02ab7c8433465cc8d6be0a8889e7c6a222fb0/ghc" eec02ab7/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="eec02ab7c8433465cc8d6be0a8889e7c6a222fb0" Give concrete example for #12784 in 8.0.2 release notes Summary: We mentioned that there were "some programs" that failed to typecheck due to #12784, but given how surprisingly common this issue has been, it'd be prudent to at least give one example of the bug in the release notes. Reviewers: simonpj, bgamari, austin, rwbarton Reviewed By: rwbarton Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2786 GHC Trac Issues: #12784 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 6 14:07:47 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Dec 2016 14:07:47 -0000 Subject: [GHC] #12784: Typechecker regression in GHC 8.0.2 involving DefaultSignatures In-Reply-To: <050.9a0edf2bdaab8860178dd08e2e10d2b7@haskell.org> References: <050.9a0edf2bdaab8860178dd08e2e10d2b7@haskell.org> Message-ID: <065.98ad6f7055de0aea01f9fbe1758312b6@haskell.org> #12784: Typechecker regression in GHC 8.0.2 involving DefaultSignatures -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: merge Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #12918 | Differential Rev(s): Phab:D2682, Wiki Page: | Phab:D2786 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 6 14:21:39 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Dec 2016 14:21:39 -0000 Subject: [GHC] #9291: Don't reconstruct sum types if the type subtly changes In-Reply-To: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> References: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> Message-ID: <061.26632e5388b74cb6e69d641aa99b244e@haskell.org> #9291: Don't reconstruct sum types if the type subtly changes -------------------------------------+------------------------------------- Reporter: schyler | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 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: | -------------------------------------+------------------------------------- Comment (by nomeata): > Is this related with typed-ness of the IR? Yes! The type system of Core ensures that we cannot get the ST stuff wrong (to some extent. It still requires us to also not inline `runRW#`, for example). > I think if we do some of the transformations we do during `coreToStg` we would have the same problem in Core too. You mean inlining `runRW#`? Right, we should not do that. I tried that once, and it broke :-) > I'm wondering if a solution could be as simple as treating state tokens as different from each other when comparing expressions... Sure, such reasoning will be required. Is the only such case? Also, in this case, CSE’ing the state token isn’t the problem per se (the state token is a zero-width value, so operationally, they are all equal). The real problem is CSE’ing `newMutRef#` which has a side-effect. So maybe only CSE’ing constructor applications is a safer start. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 6 15:23:19 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Dec 2016 15:23:19 -0000 Subject: [GHC] #12933: Wrong class instance selection with Data.Kind.Type Message-ID: <043.78f0be4957b31b9b9b4a947ac3a05ddd@haskell.org> #12933: Wrong class instance selection with Data.Kind.Type -------------------------------------+------------------------------------- Reporter: julm | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 8.0.1 Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC accepts Unknown/Multiple | invalid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If you consider the following code: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE FlexibleInstances #-} module Bug where import GHC.Exts (Constraint) import Data.Kind -- | Partial singleton for a kind type. data SKind k where SKiTy :: SKind Type SKiCo :: SKind Constraint instance Show (SKind k) where show SKiTy = "*" show SKiCo = "Constraint" class IKind k where kind :: SKind k instance IKind Constraint where kind = SKiCo }}} Then, the main below will compile even though there is no (IKind Type) instance, and it will print "Constraint" two times, instead of an expected "Constraint" then "*": {{{#!hs main :: IO () main = do print (kind::SKind Constraint) print (kind::SKind Type) }}} And, the main below will print "*" two times, instead of an expected "*" then "Constraint": {{{#!hs instance IKind Type where kind = SKiTy main :: IO () main = do print (kind::SKind Type) print (kind::SKind Constraint) }}} This can be worked around by replacing Type with a new data type Ty to select the right class instances, using two type families Ty_of_Type and Type_of_Ty, as done in the attached Workaround.hs. Sorry if this bug has already been fixed in HEAD: I was unable to find neither a bug report similar, nor a Linux x86_64 build of HEAD for me to test. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 6 15:23:49 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Dec 2016 15:23:49 -0000 Subject: [GHC] #12933: Wrong class instance selection with Data.Kind.Type In-Reply-To: <043.78f0be4957b31b9b9b4a947ac3a05ddd@haskell.org> References: <043.78f0be4957b31b9b9b4a947ac3a05ddd@haskell.org> Message-ID: <058.1af4a6382389ac0d35cf51442fdd5e2f@haskell.org> #12933: Wrong class instance selection with Data.Kind.Type -------------------------------------+------------------------------------- Reporter: julm | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by julm): * Attachment "Workaround.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 6 15:24:39 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Dec 2016 15:24:39 -0000 Subject: [GHC] #12708: RFC: Representation polymorphic Num In-Reply-To: <051.e9ad721b0c060306ebd4bf7d4de38fdd@haskell.org> References: <051.e9ad721b0c060306ebd4bf7d4de38fdd@haskell.org> Message-ID: <066.ac970d20768163c619b6adc271c01d4b@haskell.org> #12708: RFC: Representation polymorphic Num -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.1 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I still believe this is a great idea and would welcome a formal proposal about this. I also still believe that this is something better done in a library for a release or so before we start mucking with something so fundamental. There's nothing about this that cannot be done in a library (modulo `RebindableSyntax`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 6 15:26:07 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Dec 2016 15:26:07 -0000 Subject: [GHC] #12933: Wrong class instance selection with Data.Kind.Type In-Reply-To: <043.78f0be4957b31b9b9b4a947ac3a05ddd@haskell.org> References: <043.78f0be4957b31b9b9b4a947ac3a05ddd@haskell.org> Message-ID: <058.eb3bc50b22a1dd2ae396fda3cce73cca@haskell.org> #12933: Wrong class instance selection with Data.Kind.Type -------------------------------------+------------------------------------- Reporter: julm | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Related to #11715 perhaps? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 6 15:29:08 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Dec 2016 15:29:08 -0000 Subject: [GHC] #12918: Make DefaultSignatures more particular about their types on the RHS of a context In-Reply-To: <050.d16ce32d20f959d1e744b2dfaad73e22@haskell.org> References: <050.d16ce32d20f959d1e744b2dfaad73e22@haskell.org> Message-ID: <065.1c0da4c888369299451bdaa4e91a1b50@haskell.org> #12918: Make DefaultSignatures more particular about their types on the RHS of a context -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.2-rc1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12784 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by kosmikus): * cc: kosmikus (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 6 15:32:23 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Dec 2016 15:32:23 -0000 Subject: [GHC] #12784: Typechecker regression in GHC 8.0.2 involving DefaultSignatures In-Reply-To: <050.9a0edf2bdaab8860178dd08e2e10d2b7@haskell.org> References: <050.9a0edf2bdaab8860178dd08e2e10d2b7@haskell.org> Message-ID: <065.884e0dbfab9f0446b92048517fdd4cf5@haskell.org> #12784: Typechecker regression in GHC 8.0.2 involving DefaultSignatures -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: merge Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #12918 | Differential Rev(s): Phab:D2682, Wiki Page: | Phab:D2786 -------------------------------------+------------------------------------- Changes (by kosmikus): * cc: kosmikus (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 6 15:54:48 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Dec 2016 15:54:48 -0000 Subject: [GHC] #4820: "Invalid object in isRetainer" when doing retainer profiling in GHC 7 branch In-Reply-To: <049.7962690c1cad7c1dc6772c5aaee21bae@haskell.org> References: <049.7962690c1cad7c1dc6772c5aaee21bae@haskell.org> Message-ID: <064.8e26eb84d8fcb1101eb7f82a46dc0b33@haskell.org> #4820: "Invalid object in isRetainer" when doing retainer profiling in GHC 7 branch ----------------------------------+-------------------------------------- Reporter: dleuschner | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Profiling | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #11978 | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Changes (by bgamari): * status: infoneeded => new -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 6 16:20:08 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Dec 2016 16:20:08 -0000 Subject: [GHC] #12790: GHC 8.0.1 uses copious amounts of RAM and time when trying to compile lambdabot-haskell-plugins In-Reply-To: <044.6c4a4edd18cfc656391e8adc9c55d93a@haskell.org> References: <044.6c4a4edd18cfc656391e8adc9c55d93a@haskell.org> Message-ID: <059.0d8b1f109c9b6d744d68a2bbceb94f6f@haskell.org> #12790: GHC 8.0.1 uses copious amounts of RAM and time when trying to compile lambdabot-haskell-plugins -------------------------------------+------------------------------------- Reporter: clint | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I fell at the first fence: {{{ cabal install --with-ghc=/home/simonpj/5builds/HEAD-4/inplace/bin/ghc- stage2 --enable-library-profiling Resolving dependencies... cabal: Could not resolve dependencies: trying: hint-0.6.0 (dependency of mueval-0.9.3) next goal: ghc-boot-th (dependency of template-haskell-2.11.0.0) rejecting: ghc-boot-th-8.1/installed-8.1 (conflict: template-haskell => ghc-boot-th==8.0.*) trying: ghc-boot-th-8.0.1 next goal: ghc (dependency of hint-0.6.0) rejecting: ghc-8.1/installed-8.1 (conflict: ghc-boot-th==8.0.1, ghc => ghc-boot-th==8.1/installed-8.1) Backjump limit reached (currently 2000, change with --max-backjumps or try to run with --reorder-goals). }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 6 16:23:11 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Dec 2016 16:23:11 -0000 Subject: [GHC] #3231: Permission denied error with runProcess/openFile In-Reply-To: <051.9654be8110cd7a09257c98a211221fb3@haskell.org> References: <051.9654be8110cd7a09257c98a211221fb3@haskell.org> Message-ID: <066.5cad6ef886e94aa69ac92931d8601744@haskell.org> #3231: Permission denied error with runProcess/openFile -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 6.10.4 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9775 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * related: => #9775 Comment: I'll operate on the assumption that these two are related. Mainly because the first few examples here had a call out to a cygwin program or something with a call to `_exec`. In which case `WaitForSingleObject` does not do what you expect. I am fixing this is `process`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 6 16:24:48 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Dec 2016 16:24:48 -0000 Subject: [GHC] #9291: Don't reconstruct sum types if the type subtly changes In-Reply-To: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> References: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> Message-ID: <061.0b84c1764b6d172352e53e7a38bc541f@haskell.org> #9291: Don't reconstruct sum types if the type subtly changes -------------------------------------+------------------------------------- Reporter: schyler | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 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: | -------------------------------------+------------------------------------- Comment (by rwbarton): Replying to [comment:36 nomeata]: > > Is this related with typed-ness of the IR? > > Yes! The type system of Core ensures that we cannot get the ST stuff wrong (to some extent. It still requires us to also not inline `runRW#`, for example). Is this really true? Say I write {{{#!hs f :: Bool -> IORef Int -> IO () f b v = v `seq` when b (writeIORef v 3) }}} GHC produces {{{ f1 = \ b_auQ v_auR eta_B1 -> case v_auR `cast` ... of _ { STRef ipv_sPi -> case b_auQ of _ { False -> (# eta_B1, () #); True -> case writeMutVar# ipv_sPi f2 eta_B1 of s2#_aQd { __DEFAULT -> (# s2#_aQd, () #) } } } }}} What stops me from rewriting this via case-of-case to the inequivalent {{{ f1 = \ b_auQ v_auR eta_B1 -> case v_auR `cast` ... of _ { STRef ipv_sPi -> case writeMutVar# ipv_sPi f2 eta_B1 of s2#_aQd { __DEFAULT -> case b_auQ of _ { False -> (# eta_B1, () #); -- Haha, don't actually use s2#_aQd here. True -> (# s2#_aQd, () #) } } } }}} I think it is just the flag `has_side_effects = True` on `writeMutVar#`, and doesn't have to do with types. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 6 16:30:50 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Dec 2016 16:30:50 -0000 Subject: [GHC] #9291: Don't reconstruct sum types if the type subtly changes In-Reply-To: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> References: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> Message-ID: <061.9f55e0750edd942920d5e284c0589db9@haskell.org> #9291: Don't reconstruct sum types if the type subtly changes -------------------------------------+------------------------------------- Reporter: schyler | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 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: | -------------------------------------+------------------------------------- Comment (by nomeata): Uh. Good point. I guess we’d need a linear type system to prevent your illegal double-use of `eta_B1` here :-) (It is not really “case-of-case” that you are doing there, but your point still holds.) Note that this would be an illegal transformation not only for `writeMutVar#` but for anything that is not provabley total, even a pure but non-terminating function. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 6 16:37:27 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Dec 2016 16:37:27 -0000 Subject: [GHC] #9291: Don't reconstruct sum types if the type subtly changes In-Reply-To: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> References: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> Message-ID: <061.fd12f085f755287bf1d9c34c402d41a6@haskell.org> #9291: Don't reconstruct sum types if the type subtly changes -------------------------------------+------------------------------------- Reporter: schyler | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 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: | -------------------------------------+------------------------------------- Comment (by rwbarton): Right, so it's not a very good example. But I think correctness of IO mostly relies on the state threading discipline (which doesn't need types), combined I guess with the need to preserve the semantics of possibly-diverging-but-otherwise-pure programs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 6 16:38:21 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Dec 2016 16:38:21 -0000 Subject: [GHC] #12790: GHC 8.0.1 uses copious amounts of RAM and time when trying to compile lambdabot-haskell-plugins In-Reply-To: <044.6c4a4edd18cfc656391e8adc9c55d93a@haskell.org> References: <044.6c4a4edd18cfc656391e8adc9c55d93a@haskell.org> Message-ID: <059.106b11225147b1017463777b6876ef4a@haskell.org> #12790: GHC 8.0.1 uses copious amounts of RAM and time when trying to compile lambdabot-haskell-plugins -------------------------------------+------------------------------------- Reporter: clint | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Simon, can you run `cabal update` and try again? The `template-haskell` upper version bound for a downstream dependency (`exceptions`) of `lambdabot-haskell-plugins` was too restrictive, and I've since raised it to accommodate GHC HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 6 16:40:30 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Dec 2016 16:40:30 -0000 Subject: [GHC] #11715: Constraint vs * In-Reply-To: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> References: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> Message-ID: <061.d73fd24b0b553e996821a5356a265dfd@haskell.org> #11715: Constraint vs * -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Simon and I recently hit on a possible solution to this long-standing infelicity. 1. Add a new constructor of `RuntimeRep` (of levity-polymorphism fame), `ConstraintRep`. We would then have `type Constraint = TYPE ConstraintRep`. Even though values of types of kind `Constraint` have the same runtime representation as values of types of kind `Type`, it is still OK to have ''more'' distinctions in the type system than are needed at runtime. With this change, we can have things like `Num a -> a` in Core (where there is no distinction between `=>` and `->`), and this would be well- kinded because `->` simply requires that both types have a kind of the form `TYPE blah` for some `blah`. GHC currently desugars one-method (and 0-superclass) classes to be newtypes, not proper datatypes. This is more efficient, of course, than making a new box to store the dictionary. But it means under this new scheme that we have a heterogeneous newtype coercion. For example: {{{#!hs class C a where meth :: a -> a }}} is desugared into {{{#!hs newtype C a = MkCDict { meth :: a -> a } }}} which produces a coercion {{{ axC :: forall (a :: Type). C a ~R# (a -> a) }}} Under our new scheme, this coercion would be heterogeneous, because `C a :: TYPE ConstraintRep` and `(a -> a) :: TYPE LiftedRep`. Of course, GHC (now) handles heterogeneous equalities just fine, but there is a problem: GHC can extract a kind equality from a type equality via its `KindCo` coercion, captured in this typing rule: {{{ co : (t1 :: k1) ~r# (t2 :: k2) ----------------------------------------- KindCo co : (k1 :: Type) ~N# (k2 :: Type) }}} Note that the premise does not require any particular role on the coercion, while the conclusion is always nominal. With `KindCo` (and a few other coercion formers), we could derive a proof of `ConstraintRep ~N# LiftedRep` from `axC`. This is terrible. So: 2. Require the coercion in `KindCo` to be nominal. This makes our equality relation a tiny bit weaker, but I don't think the lost expressiveness will ever bite. GHC does not currently export a heterogeneous version of representational equality (although such a thing exists internally), so users can't every really witness it. And the place where this is key is in decomposing `AppCo`s, but the roles around `AppCo`s mean that the coercion relating the arguments is always nominal. So I think it will work out; building GHC's libraries with this restriction should be an adequate test. One remaining problem is that GHC uses newtype axioms for substitutions in, e.g., newtype unwrapping/normalization. So a heterogeneous axiom is a bad idea. And I'm not yet sure how to fix this. The normal way to avoid heterogeneity is just to cast one side. But we can't do this here, because the coercion we would have to use proves that `Constraint ~N# Type`, which is precisely what we are trying to avoid! So I'm still a bit stuck on this point. Another possible way forward is to do (1), above, and stop encoding one- element classes as newtypes. This has negative performance implications, and so that makes me sad. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 6 17:41:05 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Dec 2016 17:41:05 -0000 Subject: [GHC] #11715: Constraint vs * In-Reply-To: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> References: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> Message-ID: <061.e10955317598eb947222b4402e8711c1@haskell.org> #11715: Constraint vs * -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > One remaining problem is that GHC uses newtype axioms for substitutions in, e.g., newtype unwrapping/normalization. So a heterogeneous axiom is a bad idea Can you give an example? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 6 17:48:14 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Dec 2016 17:48:14 -0000 Subject: [GHC] #11715: Constraint vs * In-Reply-To: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> References: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> Message-ID: <061.65530067bb3f95ae8e30afc13190c968@haskell.org> #11715: Constraint vs * -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Let's imagine a future where `(->) :: forall (r1 :: RuntimeRep) (r2 :: RuntimeRep). TYPE r1 -> TYPE r2 -> Type`. Then, we have the well-typed `(->) ConstraintRep LiftedRep (C a) (a -> a)`. But if we normalize w.r.t. newtypes (e.g., in `normaliseFfiType`), then we'll get `(->) ConstraintRep LiftedRep (a -> a) (a -> a)`, which is ill-kinded. In this case, we can just change `ConstraintRep` to `LiftedRep` as we normalize, but it's not clear that it will always be so easy. (But maybe it really will be, because we tend not to unwrap newtypes under other type constructors.) There's also the niggling problem that the type safety proofs in the presence of newtype axioms explicitly assume that axioms are homogeneous. But maybe this is unnecessary. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 6 18:56:31 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Dec 2016 18:56:31 -0000 Subject: [GHC] #12758: Bring sanity to our performance testsuite In-Reply-To: <046.023630bbf855f7a4ed786cb14a3639ea@haskell.org> References: <046.023630bbf855f7a4ed786cb14a3639ea@haskell.org> Message-ID: <061.7d3e2d6363961ae66f00cb7a98f010a5@haskell.org> #12758: Bring sanity to our performance testsuite -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Test Suite | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by michalt): * cc: michalt (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 6 18:57:10 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Dec 2016 18:57:10 -0000 Subject: [GHC] #11715: Constraint vs * In-Reply-To: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> References: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> Message-ID: <061.530068c602002ce3d809bfa3a5b6c9ca@haskell.org> #11715: Constraint vs * -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by int-index): I see a few problems with this approach: 1. `RuntimeRep` is used to distinguish things with different run-time representations. I understand why it's sound if things represented equally get different `RuntimeRep`s, but it's not what `RuntimeRep` is for, so those fake inequalities are something to avoid (and you suggest to exploit it). Of course I understand that I'm in no position to tell you what `RuntimeRep` means because you invented it, but as a user I have certain expectations and intuition about what it means, and the name suggests that it means a run-time representation, not some arbitrary distinction which turned out to be convenient! A leaky abstraction. 2. I do think that having `Constraint ~ *` is useful in user code, because right now I have to use `Dict` to go from `Constraint` to `*` and `Given` to go in the opposite direction. It is very inconvenient! 3. We don't get the safe implementation of `reflection` (without `unsafeCoerce`) this way, do we? And if we stop encoding one-element classes as newtypes, the current implementation of `reflection` will break. Making `Constraint` a synonym for `*` sounds very simple and elegant. What are the reasons to pursue a more complicated solution? It seems to me that all of the objections were addressed in this thread. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 6 19:45:53 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Dec 2016 19:45:53 -0000 Subject: [GHC] #12425: With -O1 and above causes ghc to use all available memory before being killed by OOM killer In-Reply-To: <044.8db07ee1e56d0d370ac594dbce3dff94@haskell.org> References: <044.8db07ee1e56d0d370ac594dbce3dff94@haskell.org> Message-ID: <059.a690ad13bb5ab3c55fe52521cbcc720b@haskell.org> #12425: With -O1 and above causes ghc to use all available memory before being killed by OOM killer -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: merge Priority: high | Milestone: 8.0.3 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: performance bug | perf/compiler/T12425 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Sorry erikd, several of those dependencies not building on GHC HEAD were probably my fault. After adjusting some `template-haskell` upper version bounds on dependent packages on Hackage, I was able to successfully install `conduit-find` with GHC HEAD, and I did not observe any noticeable slowness. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 6 19:58:17 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Dec 2016 19:58:17 -0000 Subject: [GHC] #12425: With -O1 and above causes ghc to use all available memory before being killed by OOM killer In-Reply-To: <044.8db07ee1e56d0d370ac594dbce3dff94@haskell.org> References: <044.8db07ee1e56d0d370ac594dbce3dff94@haskell.org> Message-ID: <059.095da4eb429d3995ec23507cf704ca5a@haskell.org> #12425: With -O1 and above causes ghc to use all available memory before being killed by OOM killer -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: merge Priority: high | Milestone: 8.0.3 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: performance bug | perf/compiler/T12425 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by erikd): Thanks @RyanGlScott . As long it compiled with `-O1` or above, then its fixed. The original problem was GHC chewing up all memory when *compiling* `conduit-find`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 6 20:06:29 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Dec 2016 20:06:29 -0000 Subject: [GHC] #12930: DDEBUG build broken In-Reply-To: <049.2d7617702d7922f38eb05deb48d908c0@haskell.org> References: <049.2d7617702d7922f38eb05deb48d908c0@haskell.org> Message-ID: <064.26922c85d8833b1551434ecebaeb406f@haskell.org> #12930: DDEBUG build broken -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Marlow ): In [changeset:"19ae142364058e258122f4bb68ef4b9aa6e41890/ghc" 19ae1423/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="19ae142364058e258122f4bb68ef4b9aa6e41890" Mark rn017 and T7672 as expect_broken(#12930) with -DDEBUG }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 6 21:00:40 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Dec 2016 21:00:40 -0000 Subject: [GHC] #11715: Constraint vs * In-Reply-To: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> References: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> Message-ID: <061.d2cb24b4aee30d13b011422394817c84@haskell.org> #11715: Constraint vs * -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Flipping back through this ticket, I see that my new comment:47 seems to appear out of the blue. I also see @int-index advocating for dropping the distinction between `Constraint` and `Type` entirely.... but a quick skim doesn't show others agreeing with this direction of travel. I ''do'' think @int-index's approach (allowing `Int => ...`) is plausible, but I still am not convinced it's a good idea. If it's the ''only'' way to solve the original ticket, then perhaps it would be worth revisiting, but I'm not keen to start down that road. @int-index, you have argued well for your cause, but I, personally, need to see others agree with you and want these features before getting on board. It's not a matter of soundness or implementation, but of the kind of features and properties we wish Haskell to have. Responding more directly to comment:50: 1. That's true I suppose. We could also say, though, that `RuntimeRep` tells us the calling convention, not just the runtime representation. Constraints and regular types ''do'' have different calling conventions in Haskell code. 2. This goes back to my paragraphs above, in this comment. 3. `reflection` is an abuse of GHC, using an undocumented feature of the implementation. I do understand that many people use this undocumented feature, and so we could look at a way of saving `reflection`, but I don't see this as an argument against my proposal. We could always come up with another way to support `reflection` without newtype-classes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 6 21:04:53 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Dec 2016 21:04:53 -0000 Subject: [GHC] #12933: Wrong class instance selection with Data.Kind.Type In-Reply-To: <043.78f0be4957b31b9b9b4a947ac3a05ddd@haskell.org> References: <043.78f0be4957b31b9b9b4a947ac3a05ddd@haskell.org> Message-ID: <058.1104163a65874e10c8870b780b4d8b2e@haskell.org> #12933: Wrong class instance selection with Data.Kind.Type -------------------------------------+------------------------------------- Reporter: julm | Owner: Type: bug | Status: closed Priority: highest | Milestone: Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => duplicate Comment: Yes -- this is an instance of #11715. Thanks for including this example, which I will link to from #11715. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 6 21:24:46 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Dec 2016 21:24:46 -0000 Subject: [GHC] #11715: Constraint vs * In-Reply-To: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> References: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> Message-ID: <061.d6a1e1c57382cc8d6c67e1117fe957dc@haskell.org> #11715: Constraint vs * -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by int-index): Couldn't we theoretically have constraints passed as unboxed data? In https://ghc.haskell.org/trac/ghc/wiki/UnliftedDataTypes I see that Edward Kmett suggests a separate flag to `TYPE`, `Constraintiness`, which would be more disciplined than misusing `RuntimeRep` and would solve the same problems. Except I think that it should be called `Coherency`, not `Constraintiness`, because the main feature of things that go to the left of `=>` is that they should have coherency properties (as was already discussed). {{{ data Coherency = Coherent | Incoherent }}} This way we can even make `->` coherency-polymorphic (and eliminate `Dict`, that would be safe). `=>` could then require something `Coherent`, and `-XIncoherentContexts` (a companion to `-XIncoherentInstances`) could lift this restriction. Then `Int =>` would be disallowed unless the pragma is specified, but none of my objections would apply. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 6 21:49:54 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Dec 2016 21:49:54 -0000 Subject: [GHC] #12790: GHC 8.0.1 uses copious amounts of RAM and time when trying to compile lambdabot-haskell-plugins In-Reply-To: <044.6c4a4edd18cfc656391e8adc9c55d93a@haskell.org> References: <044.6c4a4edd18cfc656391e8adc9c55d93a@haskell.org> Message-ID: <059.786f833d101c88735365e34c6c33a368@haskell.org> #12790: GHC 8.0.1 uses copious amounts of RAM and time when trying to compile lambdabot-haskell-plugins -------------------------------------+------------------------------------- Reporter: clint | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I've managed to reduce it down to something which just requires `parsec`: {{{#!hs module Lambdabot.Plugin.Haskell.Pl.Parser (list) where import Data.Foldable (asum) import Text.ParserCombinators.Parsec (Parser, (), sepBy, try) data Expr = Var Fixity String | App Expr Expr data Fixity = Pref | Inf cons, nil :: Expr cons = Var Inf ":" nil = Var Pref "[]" brackets :: Parser a -> Parser a brackets = undefined symbol :: String -> Parser String symbol = undefined list :: Parser Expr list = asum (map (try . brackets) plist) "list" where plist = [ foldr (\e1 e2 -> cons `App` e1 `App` e2) nil `fmap` (myParser False `sepBy` symbol ","), do e <- myParser False _ <- symbol ".." return $ Var Pref "enumFrom" `App` e, do e <- myParser False _ <- symbol "," e' <- myParser False _ <- symbol ".." return $ Var Pref "enumFromThen" `App` e `App` e', do e <- myParser False _ <- symbol ".." e' <- myParser False return $ Var Pref "enumFromTo" `App` e `App` e', do e <- myParser False _ <- symbol "," e' <- myParser False _ <- symbol ".." e'' <- myParser False return $ Var Pref "enumFromThenTo" `App` e `App` e' `App` e'' ] myParser :: Bool -> Parser Expr myParser = undefined }}} `plist` appears to be the culprit. It seems to have some sort of quadratic slowdown whenever new elements are added to `plist`. For example, commenting out the last element of `plist` makes it compile within a reasonable amount of time (but not instantly). I think the `Alternative` instance for `Parser` might have something to do with it, too. Notably, if I comment out the import of `asum` and redefine it locally as: {{{#!hs asum :: [Parser a] -> Parser a asum = undefined }}} Then it compiles instantly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 6 22:14:50 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Dec 2016 22:14:50 -0000 Subject: [GHC] #12930: DDEBUG build broken In-Reply-To: <049.2d7617702d7922f38eb05deb48d908c0@haskell.org> References: <049.2d7617702d7922f38eb05deb48d908c0@haskell.org> Message-ID: <064.9a773d381276e0b89fd263a6ea9bdecc@haskell.org> #12930: DDEBUG build broken -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Matthew Pickering ): In [changeset:"eafa06dce4aa815159ebba5a34d5137cf401ffbc/ghc" eafa06dc/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="eafa06dce4aa815159ebba5a34d5137cf401ffbc" Revert "Mark rn017 and T7672 as expect_broken(#12930) with -DDEBUG" This reverts commit 19ae142364058e258122f4bb68ef4b9aa6e41890. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 6 22:14:50 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Dec 2016 22:14:50 -0000 Subject: [GHC] #12930: DDEBUG build broken In-Reply-To: <049.2d7617702d7922f38eb05deb48d908c0@haskell.org> References: <049.2d7617702d7922f38eb05deb48d908c0@haskell.org> Message-ID: <064.4718fe4f48e9a12b66a9e7e26bbea21c@haskell.org> #12930: DDEBUG build broken -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Matthew Pickering ): In [changeset:"6e4188abf36d3b489ff7c9586ca49fe922f2beb7/ghc" 6e4188a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6e4188abf36d3b489ff7c9586ca49fe922f2beb7" Fix unsafe usage of `is_iloc` selector in Ord instance for ImportSpec Summary: This fixes tests rn017, T7672 and closed #12930. Both these tests were self referential module imports through hs-boot files. As a result, I am quite suspicious of what the ImpAll constructor is used for. I had a brief hunt around but couldn't immediately see whether it was necessary. Reviewers: austin, bgamari Subscribers: simonpj, thomie, nomeata Differential Revision: https://phabricator.haskell.org/D2793 GHC Trac Issues: #12930 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 6 22:17:31 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Dec 2016 22:17:31 -0000 Subject: [GHC] #12930: DDEBUG build broken In-Reply-To: <049.2d7617702d7922f38eb05deb48d908c0@haskell.org> References: <049.2d7617702d7922f38eb05deb48d908c0@haskell.org> Message-ID: <064.6201e462d25e68f94d55a17f967c1e54@haskell.org> #12930: DDEBUG build broken -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 6 23:15:54 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Dec 2016 23:15:54 -0000 Subject: [GHC] #12926: ghc master (8.1.20161202) panics with assertion failure with devel2 flavor and -O2 In-Reply-To: <044.d632e605d759db42e889e2bb2d7fb6bc@haskell.org> References: <044.d632e605d759db42e889e2bb2d7fb6bc@haskell.org> Message-ID: <059.a413069b3747c7a94e557c32c3b08638@haskell.org> #12926: ghc master (8.1.20161202) panics with assertion failure with devel2 flavor and -O2 -------------------------------------+------------------------------------- Reporter: pacak | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => infoneeded * milestone: => 8.2.1 Comment: What commit is this from? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 6 23:18:33 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Dec 2016 23:18:33 -0000 Subject: [GHC] #12926: ghc master (8.1.20161202) panics with assertion failure with devel2 flavor and -O2 In-Reply-To: <044.d632e605d759db42e889e2bb2d7fb6bc@haskell.org> References: <044.d632e605d759db42e889e2bb2d7fb6bc@haskell.org> Message-ID: <059.cb7916d022f308cf744be4dc32b9f228@haskell.org> #12926: ghc master (8.1.20161202) panics with assertion failure with devel2 flavor and -O2 -------------------------------------+------------------------------------- Reporter: pacak | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by pacak): recent master: 2350906bfb -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 6 23:18:55 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Dec 2016 23:18:55 -0000 Subject: [GHC] #12926: ghc master (8.1.20161202) panics with assertion failure with devel2 flavor and -O2 In-Reply-To: <044.d632e605d759db42e889e2bb2d7fb6bc@haskell.org> References: <044.d632e605d759db42e889e2bb2d7fb6bc@haskell.org> Message-ID: <059.e7db3b4b44d1d13ca9c6660154ae6cad@haskell.org> #12926: ghc master (8.1.20161202) panics with assertion failure with devel2 flavor and -O2 -------------------------------------+------------------------------------- Reporter: pacak | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: infoneeded => new -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 6 23:36:45 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Dec 2016 23:36:45 -0000 Subject: [GHC] #12790: GHC 8.0.1 uses copious amounts of RAM and time when trying to compile lambdabot-haskell-plugins In-Reply-To: <044.6c4a4edd18cfc656391e8adc9c55d93a@haskell.org> References: <044.6c4a4edd18cfc656391e8adc9c55d93a@haskell.org> Message-ID: <059.5b0d1bb5046e85bf85f831e7e7fa60d5@haskell.org> #12790: GHC 8.0.1 uses copious amounts of RAM and time when trying to compile lambdabot-haskell-plugins -------------------------------------+------------------------------------- Reporter: clint | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): That's very helpful. Alas, `parsec-3.1.11` doesn't compile with HEAD. I get {{{ Text\Parsec\Token.hs:524:27: error: Could not deduce (Stream s m t0) arising from a use of option from the context: Stream s m Char bound by the type signature for: makeTokenParser :: Stream s m Char => GenLanguageDef s u m -> GenTokenParser s u m at Text\Parsec\Token.hs:(351,1)-(352,63) The type variable t0 is ambiguous }}} I have not investigated what the problem is. Does anyone know? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 00:22:21 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 00:22:21 -0000 Subject: [GHC] #9577: String literals are wasting space In-Reply-To: <045.ae4d47715fdd8321ed459b0edd946522@haskell.org> References: <045.ae4d47715fdd8321ed459b0edd946522@haskell.org> Message-ID: <060.050fe5c4c98050ecd0de1da46c6305c5@haskell.org> #9577: String literals are wasting space -------------------------------------+------------------------------------- Reporter: xnyhps | Owner: xnyhps Type: bug | Status: patch Priority: low | Milestone: 8.2.1 Component: Compiler (NCG) | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | codeGen/should_run/T9577 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1290 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"b7e88ee0d87f41cf1d8aba62aa44d5bf0a7404ad/ghc" b7e88ee/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b7e88ee0d87f41cf1d8aba62aa44d5bf0a7404ad" Reduce the size of string literals in binaries. Removed the alignment for strings and mark then as cstring sections in the generated asm so the linker can merge duplicate sections. Reviewers: rwbarton, trofi, austin, trommler, simonmar, hvr, bgamari Reviewed By: hvr, bgamari Subscribers: simonpj, hvr, thomie Differential Revision: https://phabricator.haskell.org/D1290 GHC Trac Issues: #9577 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 00:22:21 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 00:22:21 -0000 Subject: [GHC] #12919: Equality not used for substitution In-Reply-To: <048.c4e450c7b401a6295cbd8b394ff2a079@haskell.org> References: <048.c4e450c7b401a6295cbd8b394ff2a079@haskell.org> Message-ID: <063.6d6eee5c46498e3de8a40e3d64edd893@haskell.org> #12919: Equality not used for substitution -------------------------------------+------------------------------------- Reporter: int-index | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"41ec722d71db0eadeddd582a23aab7347349185f/ghc" 41ec722d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="41ec722d71db0eadeddd582a23aab7347349185f" Test Trac #12919 Test Plan: make test TEST=T12919 Reviewers: bgamari, austin Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2788 GHC Trac Issues: #12919 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 00:23:26 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 00:23:26 -0000 Subject: [GHC] #9577: String literals are wasting space In-Reply-To: <045.ae4d47715fdd8321ed459b0edd946522@haskell.org> References: <045.ae4d47715fdd8321ed459b0edd946522@haskell.org> Message-ID: <060.8e748c6cb4df36fbd466424cd1458fa1@haskell.org> #9577: String literals are wasting space -------------------------------------+------------------------------------- Reporter: xnyhps | Owner: xnyhps Type: bug | Status: closed Priority: low | Milestone: 8.2.1 Component: Compiler (NCG) | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | codeGen/should_run/T9577 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1290 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 00:23:58 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 00:23:58 -0000 Subject: [GHC] #12919: Equality not used for substitution In-Reply-To: <048.c4e450c7b401a6295cbd8b394ff2a079@haskell.org> References: <048.c4e450c7b401a6295cbd8b394ff2a079@haskell.org> Message-ID: <063.0490af503d953ad2a6a0e245cca49103@haskell.org> #12919: Equality not used for substitution -------------------------------------+------------------------------------- Reporter: int-index | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/T12919 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * testcase: => typecheck/should_compile/T12919 * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 00:33:20 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 00:33:20 -0000 Subject: [GHC] #4144: Exception: ToDo: hGetBuf - when using custom handle infrastructure In-Reply-To: <052.f68490df51931cf0218e339e7abda5be@haskell.org> References: <052.f68490df51931cf0218e339e7abda5be@haskell.org> Message-ID: <067.9e0c255504a5351d52ea744bcb2cb003@haskell.org> #4144: Exception: ToDo: hGetBuf - when using custom handle infrastructure -------------------------------------+------------------------------------- Reporter: AntoineLatter | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Core Libraries | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => Comment: De-milestoning since the solution isn't clear and no one has stepped up to handle this. If you are affected by this issue please do pick this up! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 00:44:33 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 00:44:33 -0000 Subject: [GHC] #5553: sendWakeup error in simple test program with MVars and killThread In-Reply-To: <042.59ee379d0a78887aa9f6aa413434e659@haskell.org> References: <042.59ee379d0a78887aa9f6aa413434e659@haskell.org> Message-ID: <057.e0b53806ba329af26c25269c83467cd4@haskell.org> #5553: sendWakeup error in simple test program with MVars and killThread -------------------------------------+------------------------------------- Reporter: bit | Owner: Type: bug | Status: new Priority: high | Milestone: 7.4.2 Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Incorrect result | Test Case: at runtime | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by basvandijk): * cc: basvandijk, simonmar (added) * status: closed => new * version: 7.2.1 => 8.0.1 * resolution: worksforme => * owner: tibbe => Comment: In a program at work I get exactly the same error. I'm on '''GHC-8.0.1'''. I'm using Don Stewarts [http://hackage.haskell.org/package/ghc-gc-tune ghc-gc-tune] to find the optimal GC settings for a server program. `ghc- gc-tune` expects the program to terminate. Since it's a server this doesn't happen. To fix this I wrap the program in `timeout --preserve- status 5` to terminate the server after 5 seconds. `ghc-gc-tune` will run the program many times with different `-H` and `-A` settings. Among other things, the program forks a thread which basically does the same thing as the `serverThread` of the OP: {{{ tid <- forkIO $ forever $ threadDelay 5000000 }}} The program ends with installing a signal handler for SIGTERM which will unlock a lock that the program is waiting on. Finally the forked thread is killed: {{{ lock <- newEmptyMVar installHandler sigTERM (Catch $ putMVar lock ()) (Just fullSignalSet) takeMVar lock killThread tid }}} I believe the `sendWakeup` exception is thrown in `threadDelay`. I'm trying to reduce to program so it doesn't contain any proprietary code but so far I'm not succeeding. It appears that [https://github.com/ghc/ghc/blob/ghc-8.0/libraries/base/GHC/Event/TimerManager.hs#L128 closeControl] is called before [https://github.com/ghc/ghc/blob/ghc-8.0/libraries/base/GHC/Event/TimerManager.hs#L204 wakeManager]. Could it be that the `state` IORef is [https://github.com/ghc/ghc/blob/ghc-8.0/libraries/base/GHC/Event/TimerManager.hs#L124 finalized] before we run `wakeManager`? If so, how can we ensure the garbage collector treats the IORef as reachable until after `wakeManager`? Maybe writing to it, as in: {{{ wakeManager :: TimerManager -> IO () wakeManager mgr = do sendWakeup (emControl mgr) atomicWriteIORef (emState mgr) $ \x -> (x, ()) }}} ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 00:46:55 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 00:46:55 -0000 Subject: [GHC] #12934: Testsuite driver buffering behavior has changed with Python 3 Message-ID: <046.b5871f0fc6bb09c51c25296a2f7aad40@haskell.org> #12934: Testsuite driver buffering behavior has changed with Python 3 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Test Suite | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The buffering behavior of the testsuite driver has changed with the move to Python 3 (#9184). Now output seems to arrive at the terminal in blocks. This is strange since the documentation for `sys.stdout` in Python 3.5 claims, > When interactive, standard streams are line-buffered. Otherwise, they are block-buffered like regular text files. You can override this value with the `-u` command-line option. It would be good to understand why this is the case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 00:49:19 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 00:49:19 -0000 Subject: [GHC] #4505: Segmentation fault on long input (list of pairs) In-Reply-To: <046.2dc545b3c32e7b8eef61780dd9491ae5@haskell.org> References: <046.2dc545b3c32e7b8eef61780dd9491ae5@haskell.org> Message-ID: <061.b950443cb67816862532f5cae1d3e8da@haskell.org> #4505: Segmentation fault on long input (list of pairs) -------------------------------------+------------------------------------- Reporter: cathper | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: Segmentation | fault, segfault, long input Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: 4258 | Blocking: Related Tickets: | Differential Rev(s): Phab:D1180 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: niteria => * milestone: 8.2.1 => 8.0.2 Comment: De-milestoning since the solution isn't clear and no one has stepped up to handle this. If you are affected by this issue please do pick it up! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 01:05:58 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 01:05:58 -0000 Subject: [GHC] #7602: Threaded RTS performing badly on recent OS X (10.8?) In-Reply-To: <047.d4c76195d3e5b80e244f99bd757e13e7@haskell.org> References: <047.d4c76195d3e5b80e244f99bd757e13e7@haskell.org> Message-ID: <062.1e13e5f1011d98cef2c14825d176d01a@haskell.org> #7602: Threaded RTS performing badly on recent OS X (10.8?) -------------------------------------+------------------------------------- Reporter: simonmar | Owner: thoughtpolice Type: bug | Status: new Priority: high | Milestone: Component: Runtime System | Version: Resolution: | Keywords: thread-local | state, TLS clang Operating System: MacOS X | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: 7678 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => Comment: De-milestoning since the solution isn't clear and no one has stepped up to handle this. If you are affected by this issue please do pick it up! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 01:13:50 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 01:13:50 -0000 Subject: [GHC] #11485: Very unhelpful message resulting from kind mismatch In-Reply-To: <050.625a7e9c1404b85e4c1b2b4e1408e546@haskell.org> References: <050.625a7e9c1404b85e4c1b2b4e1408e546@haskell.org> Message-ID: <065.784e65083dc09e70687c06d7d3d7c120@haskell.org> #11485: Very unhelpful message resulting from kind mismatch -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 01:14:13 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 01:14:13 -0000 Subject: [GHC] #11548: Absolutely misleading error message on kind error In-Reply-To: <044.e6082235a325c0e8984f6f1f86653383@haskell.org> References: <044.e6082235a325c0e8984f6f1f86653383@haskell.org> Message-ID: <059.69e410d904fed1faa68329751f6e13a1@haskell.org> #11548: Absolutely misleading error message on kind error -------------------------------------+------------------------------------- Reporter: mniip | Owner: goldfire Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * version: 8.1 => 8.0.1-rc1 * resolution: => fixed * milestone: => 8.0.1 Comment: This is fixed in 8.0.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 01:19:17 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 01:19:17 -0000 Subject: [GHC] #9314: Each object file in a static archive file (.a) is loaded into its own mmap()ed page In-Reply-To: <052.69f389ede5e82026cc5c1d8ff164657e@haskell.org> References: <052.69f389ede5e82026cc5c1d8ff164657e@haskell.org> Message-ID: <067.1f1a671b52dea72c88583d7f4cb615ac@haskell.org> #9314: Each object file in a static archive file (.a) is loaded into its own mmap()ed page -------------------------------------+------------------------------------- Reporter: kazu-yamamoto | Owner: Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Runtime System | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.4.1 Comment: Sadly hsyl20's patch stalled and has bitrotted to the point where it will need to be re-written. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 01:25:29 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 01:25:29 -0000 Subject: [GHC] #12935: Object code produced by GHC is non-deterministic Message-ID: <046.8f3dd2cbcacc5f9595e0dfae3817822d@haskell.org> #12935: Object code produced by GHC is non-deterministic -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is a continuation of #4012, which made interface files deterministic. Now someone needs to make object code deterministic. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 01:25:52 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 01:25:52 -0000 Subject: [GHC] #12935: Object code produced by GHC is non-deterministic In-Reply-To: <046.8f3dd2cbcacc5f9595e0dfae3817822d@haskell.org> References: <046.8f3dd2cbcacc5f9595e0dfae3817822d@haskell.org> Message-ID: <061.ced3e9fdae583be57651b39d5d0c9d67@haskell.org> #12935: Object code produced by GHC is non-deterministic -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * version: 8.0.1 => 8.0.2 @@ -1,2 +1,3 @@ - This is a continuation of #4012, which made interface files deterministic. - Now someone needs to make object code deterministic. + This is a continuation of #4012, which was resolved in 8.0.2 by making + interface files deterministic. Now someone needs to make object code + deterministic. New description: This is a continuation of #4012, which was resolved in 8.0.2 by making interface files deterministic. Now someone needs to make object code deterministic. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 01:26:59 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 01:26:59 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.1baa1dbc2b18399881ff3b1cc9946ba1@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: niteria Type: bug | Status: closed Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 6.12.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: 11362 | Blocking: 12262 Related Tickets: #10424 | Differential Rev(s): Phab:D910, | Phab:D1073, Phab:D1133, Phab:D1192, | Phab:D1268, Phab:D1360, Phab:D1373, Wiki Page: | Phab:D1396, Phab:D1457, Phab:D1468, DeterministicBuilds | Phab:D1487, Phab:D1504, Phab:D1508 -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: 8.2.1 => 8.0.2 Comment: As noted above, as of GHC 8.0.2 interface files are deterministic. While this isn't full determinism, it is much of the way there and we will likely leave it at that until someone comes along who wants to finish the project. Closing this in favor of #12935, which tracks the remaining problem of deterministic object code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 01:34:36 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 01:34:36 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.16ab80148fdd5be49d3b400f58cce4d0@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: 11362 | Blocking: 12262 Related Tickets: #10424 | Differential Rev(s): Phab:D910, | Phab:D1073, Phab:D1133, Phab:D1192, | Phab:D1268, Phab:D1360, Phab:D1373, Wiki Page: | Phab:D1396, Phab:D1457, Phab:D1468, DeterministicBuilds | Phab:D1487, Phab:D1504, Phab:D1508 -------------------------------------+------------------------------------- Changes (by niteria): * status: closed => new * owner: niteria => * resolution: fixed => * milestone: 8.0.2 => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 01:38:12 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 01:38:12 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.f738981db42354b77e87596368c1a168@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: 11362 | Blocking: 12262 Related Tickets: #10424 | Differential Rev(s): Phab:D910, | Phab:D1073, Phab:D1133, Phab:D1192, | Phab:D1268, Phab:D1360, Phab:D1373, Wiki Page: | Phab:D1396, Phab:D1457, Phab:D1468, DeterministicBuilds | Phab:D1487, Phab:D1504, Phab:D1508 -------------------------------------+------------------------------------- Changes (by niteria): * owner: => niteria Comment: While GHC 8.0.2 builds interface files deterministically, there's still some work left with making it hard to break in the future. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 01:41:57 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 01:41:57 -0000 Subject: [GHC] #229: Integer overflow in array allocation In-Reply-To: <045.791e3ea8f042e6c7d57ae4cd25dec693@haskell.org> References: <045.791e3ea8f042e6c7d57ae4cd25dec693@haskell.org> Message-ID: <060.6c3a2fee64c2b8f1eee9c5b2da5608bd@haskell.org> #229: Integer overflow in array allocation -------------------------------------+------------------------------------- Reporter: josefs | Owner: rwbarton Type: bug | Status: patch Priority: high | Milestone: 8.2.1 Component: Core Libraries | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch Comment: Here's a patch. https://github.com/bgamari/array/commit/73144bda5cf4f5ba2e73206ea0a53200e30218af -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 01:42:03 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 01:42:03 -0000 Subject: [GHC] #229: Integer overflow in array allocation In-Reply-To: <045.791e3ea8f042e6c7d57ae4cd25dec693@haskell.org> References: <045.791e3ea8f042e6c7d57ae4cd25dec693@haskell.org> Message-ID: <060.50d3c3fceb528518fcfe446be1f1ae84@haskell.org> #229: Integer overflow in array allocation -------------------------------------+------------------------------------- Reporter: josefs | Owner: bgamari Type: bug | Status: patch Priority: high | Milestone: 8.2.1 Component: Core Libraries | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: rwbarton => bgamari -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 01:46:36 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 01:46:36 -0000 Subject: [GHC] #8224: Excessive system time -- new IO manager problem? In-Reply-To: <047.560f2473b19a53c27f0a194339ba0f97@haskell.org> References: <047.560f2473b19a53c27f0a194339ba0f97@haskell.org> Message-ID: <062.c666ff60f0d50e8d102284b365e2d02e@haskell.org> #8224: Excessive system time -- new IO manager problem? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: closed Priority: high | Milestone: Component: Runtime System | Version: 7.7 Resolution: worksforme | Keywords: IO Manager, | System Time Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9221 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => worksforme * milestone: 8.2.1 => Comment: I'm closing this since this issue has turned into a bit of a mess of various unrelated scaling issues, none of which are IO manager-related. @alkar, if you get a chance please do open new ticket describing your particular issue and how to reproduce it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 01:52:59 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 01:52:59 -0000 Subject: [GHC] #1880: Unify flag descriptions to generate both docs and code In-Reply-To: <047.a1f2675dc59d934ab527e6234630f65b@haskell.org> References: <047.a1f2675dc59d934ab527e6234630f65b@haskell.org> Message-ID: <062.21dd250198be1806cd6e6083a8bc09f3@haskell.org> #1880: Unify flag descriptions to generate both docs and code -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: closed Priority: lowest | Milestone: Component: Compiler | Version: 6.8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: Things have changed a great deal since this bug was opened 9 years ago. This still isn't fixed per se (see #11654) but this particular instance of this issue can be closed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 01:53:30 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 01:53:30 -0000 Subject: [GHC] #1880: Unify flag descriptions to generate both docs and code In-Reply-To: <047.a1f2675dc59d934ab527e6234630f65b@haskell.org> References: <047.a1f2675dc59d934ab527e6234630f65b@haskell.org> Message-ID: <062.c657965f2fff657f682b3527a70dbaed@haskell.org> #1880: Unify flag descriptions to generate both docs and code -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: closed => new * resolution: fixed => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 01:53:41 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 01:53:41 -0000 Subject: [GHC] #1880: Unify flag descriptions to generate both docs and code In-Reply-To: <047.a1f2675dc59d934ab527e6234630f65b@haskell.org> References: <047.a1f2675dc59d934ab527e6234630f65b@haskell.org> Message-ID: <062.c673f2cc69471dd9cdf042a8224b6b70@haskell.org> #1880: Unify flag descriptions to generate both docs and code -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: closed Priority: lowest | Milestone: Component: Compiler | Version: 6.8.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11654 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => duplicate * related: => #11654 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 01:59:47 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 01:59:47 -0000 Subject: [GHC] #2496: Invalid Eq/Ord instances in Data.Version In-Reply-To: <044.b515c7a01d17e019028e237b73b96edc@haskell.org> References: <044.b515c7a01d17e019028e237b73b96edc@haskell.org> Message-ID: <059.3c2c844345c684346a84cf17db7fb5fe@haskell.org> #2496: Invalid Eq/Ord instances in Data.Version -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 6.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D395 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => Comment: De-milestoning due to lack of progress. If you want this to happen please feel free to pick it up! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 02:01:56 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 02:01:56 -0000 Subject: [GHC] #12791: Superclass methods could be more aggressively specialised. In-Reply-To: <049.67ba67008b7e7aca654f97100047ee77@haskell.org> References: <049.67ba67008b7e7aca654f97100047ee77@haskell.org> Message-ID: <064.2dfce6b6114f585e26e414eb1a7d087e@haskell.org> #12791: Superclass methods could be more aggressively specialised. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: danharaj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #5835 | Differential Rev(s): Phab:D2714 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: => #5835 Comment: It seems like #5835 is somewhat related here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 02:02:41 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 02:02:41 -0000 Subject: [GHC] #5835: Make better use of known dictionaries In-Reply-To: <041.da4dbbc1a9ab52eefd6923c34aad6eb5@haskell.org> References: <041.da4dbbc1a9ab52eefd6923c34aad6eb5@haskell.org> Message-ID: <056.b20f9d0708bf00ba1e78db87ad715d2e@haskell.org> #5835: Make better use of known dictionaries -------------------------------------+------------------------------------- Reporter: rl | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.5 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.2.1 => Comment: De-milestoning due to lack of progress. If you, the motivated reader, would like to see this happen please do pick it up! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 02:03:33 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 02:03:33 -0000 Subject: [GHC] #12936: Type inference regression in GHC HEAD Message-ID: <050.1f2cf84cf2dccac9b01fc4b4cae905cd@haskell.org> #12936: Type inference regression in GHC HEAD -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- First noticed in https://ghc.haskell.org/trac/ghc/ticket/12790#comment:8. This causes `parsec-3.1.11` to fail to build with GHC HEAD. Here is as small of a test case that I can manage, with no dependencies: {{{#!hs {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE MultiParamTypeClasses #-} module Parsec (makeTokenParser) where import Data.Char (digitToInt) data ParsecT s u (m :: * -> *) a instance Functor (ParsecT s u m) where fmap = undefined instance Applicative (ParsecT s u m) where pure = undefined (<*>) = undefined instance Monad (ParsecT s u m) where return = undefined (>>=) = undefined fail = undefined parserZero :: ParsecT s u m a parserZero = undefined infixr 1 <|> (<|>) :: (ParsecT s u m a) -> (ParsecT s u m a) -> (ParsecT s u m a) (<|>) = undefined class (Monad m) => Stream s m t | s -> t where digit :: (Stream s m Char) => ParsecT s u m Char digit = undefined hexDigit :: (Stream s m Char) => ParsecT s u m Char hexDigit = undefined octDigit :: (Stream s m Char) => ParsecT s u m Char octDigit = undefined option :: (Stream s m t) => a -> ParsecT s u m a -> ParsecT s u m a option = undefined many1 :: (Stream s m t) => ParsecT s u m a -> ParsecT s u m [a] many1 = undefined data GenTokenParser s u m = TokenParser { float :: ParsecT s u m Double, naturalOrFloat :: ParsecT s u m (Either Integer Double) } makeTokenParser :: (Stream s m Char) => GenTokenParser s u m makeTokenParser = TokenParser{ float = float_ , naturalOrFloat = naturalOrFloat_ } where ----------------------------------------------------------- -- Numbers ----------------------------------------------------------- naturalOrFloat_ = lexeme natFloat float_ = lexeme floating -- floats floating = do{ n <- decimal ; fractExponent n } natFloat = zeroNumFloat <|> decimalFloat zeroNumFloat = do{ n <- hexadecimal <|> octal ; return (Left n) } <|> decimalFloat decimalFloat = do{ n <- decimal ; option (Left n) (fractFloat n) } fractFloat n = do{ f <- fractExponent n ; return (Right f) } fractExponent n = do{ fract <- fraction ; expo <- option "" exponent' ; readDouble (show n ++ fract ++ expo) } <|> do{ expo <- exponent' ; readDouble (show n ++ expo) } where readDouble s = case reads s of [(x, "")] -> return x _ -> parserZero fraction = do{ digits <- many1 digit ; return ('.' : digits) } exponent' = do{ e <- decimal ; return (show e) } -- integers and naturals decimal = number 10 digit hexadecimal = number 16 hexDigit octal = number 8 octDigit number base baseDigit = do{ digits <- many1 baseDigit ; let n = foldl (\x d -> base*x + toInteger (digitToInt d)) 0 digits ; seq n (return n) } ----------------------------------------------------------- -- White space & symbols ----------------------------------------------------------- lexeme p = do{ x <- p; whiteSpace; return x } whiteSpace = return () }}} In GHC 8.0.1 and 8.0.2, this compiles without issue. But on GHC HEAD: {{{ $ ~/Software/ghc/inplace/bin/ghc-stage2 Parsec.hs [1 of 1] Compiling Parsec ( Parsec.hs, Parsec.o ) Parsec.hs:83:27: error: • Could not deduce (Stream s m t0) arising from a use of ‘option’ from the context: Stream s m Char bound by the type signature for: makeTokenParser :: Stream s m Char => GenTokenParser s u m at Parsec.hs:53:1-60 The type variable ‘t0’ is ambiguous Relevant bindings include decimalFloat :: ParsecT s u1 m (Either Integer Double) (bound at Parsec.hs:82:5) fractFloat :: forall b a1 u a2. (Read b, Show a2) => a2 -> ParsecT s u m (Either a1 b) (bound at Parsec.hs:87:5) fractExponent :: forall a1 u a2. (Show a2, Read a1) => a2 -> ParsecT s u m a1 (bound at Parsec.hs:91:5) fraction :: forall u. ParsecT s u m [Char] (bound at Parsec.hs:105:5) exponent' :: forall u. ParsecT s u m String (bound at Parsec.hs:109:5) decimal :: forall u. ParsecT s u m Integer (bound at Parsec.hs:114:5) lexeme :: forall b. ParsecT s u m b -> ParsecT s u m b (bound at Parsec.hs:127:5) (Some bindings suppressed; use -fmax-relevant-binds=N or -fno-max- relevant-binds) • In a stmt of a 'do' block: option (Left n) (fractFloat n) In the expression: do { n <- decimal; option (Left n) (fractFloat n) } In an equation for ‘decimalFloat’: decimalFloat = do { n <- decimal; option (Left n) (fractFloat n) } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 02:05:06 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 02:05:06 -0000 Subject: [GHC] #8953: Reification drops necessary kind annotations In-Reply-To: <047.1c676b3de5fd3f2cb8726d1a1f304ef8@haskell.org> References: <047.1c676b3de5fd3f2cb8726d1a1f304ef8@haskell.org> Message-ID: <062.9e30a589509ef5679e8811e5c5206759@haskell.org> #8953: Reification drops necessary kind annotations -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: th/T8953 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D387 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => Comment: This won't be happening for 8.2. If you would like to see this happen please do pick it up! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 02:05:27 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 02:05:27 -0000 Subject: [GHC] #12455: Compact Regions In-Reply-To: <047.80e2661be18b6941b868944e7d5d69fa@haskell.org> References: <047.80e2661be18b6941b868944e7d5d69fa@haskell.org> Message-ID: <062.0e5901872ff47e7ce505d4ca9c5dc575@haskell.org> #12455: Compact Regions -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: task | Status: patch Priority: high | Milestone: 8.2.1 Component: Runtime System | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2751 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 02:15:16 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 02:15:16 -0000 Subject: [GHC] #12790: GHC 8.0.1 uses copious amounts of RAM and time when trying to compile lambdabot-haskell-plugins In-Reply-To: <044.6c4a4edd18cfc656391e8adc9c55d93a@haskell.org> References: <044.6c4a4edd18cfc656391e8adc9c55d93a@haskell.org> Message-ID: <059.f9ae69e48353fb1b07f40c2f3f29e98a@haskell.org> #12790: GHC 8.0.1 uses copious amounts of RAM and time when trying to compile lambdabot-haskell-plugins -------------------------------------+------------------------------------- Reporter: clint | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Simon, I've opened #12936 to figure out that `parsec` issue. Until then, you can work around it by checking out a local copy of `parsec-3.1.11` with `cabal get parsec-3.1.11`, edit `parsec-3.1.11/Text/Parsec/Token.hs`, and change the definition to `makeTokenParser = undefined`. I don't believe its definition is used in this example anyways. Moreover, after making that change, I can confirm that the example in https://ghc.haskell.org/trac/ghc/ticket/12790#comment:7 also exhibits the same slowdown in GHC HEAD (compiling it with `-O -prof`, of course). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 02:18:55 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 02:18:55 -0000 Subject: [GHC] #12646: Type family reification misses a kind signature In-Reply-To: <047.cba91014c4d60775bdcbc80a5671d922@haskell.org> References: <047.cba91014c4d60775bdcbc80a5671d922@haskell.org> Message-ID: <062.21927c2ed5d04671a83bf4f59060f9fe@haskell.org> #12646: Type family reification misses a kind signature -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Actually, might this be a duplicate of #8953? https://ghc.haskell.org/trac/ghc/ticket/8953#comment:14 mentions that closed type families haven't been covered, which seems to be the scope of this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 02:23:03 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 02:23:03 -0000 Subject: [GHC] #12790: GHC 8.0.1 uses copious amounts of RAM and time when trying to compile lambdabot-haskell-plugins In-Reply-To: <044.6c4a4edd18cfc656391e8adc9c55d93a@haskell.org> References: <044.6c4a4edd18cfc656391e8adc9c55d93a@haskell.org> Message-ID: <059.cb19716082a49a0d1d33893d2d86f82e@haskell.org> #12790: GHC 8.0.1 uses copious amounts of RAM and time when trying to compile lambdabot-haskell-plugins -------------------------------------+------------------------------------- Reporter: clint | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Can the example be reduced further by inlining the relevant parts of parsec? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 02:30:46 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 02:30:46 -0000 Subject: [GHC] #12790: GHC 8.0.1 uses copious amounts of RAM and time when trying to compile lambdabot-haskell-plugins In-Reply-To: <044.6c4a4edd18cfc656391e8adc9c55d93a@haskell.org> References: <044.6c4a4edd18cfc656391e8adc9c55d93a@haskell.org> Message-ID: <059.abe42be53c2acc1c6d191f225c7c1710@haskell.org> #12790: GHC 8.0.1 uses copious amounts of RAM and time when trying to compile lambdabot-haskell-plugins -------------------------------------+------------------------------------- Reporter: clint | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Weirdly enough, I tried inlining the relevant `parsec` bits (which isn't an easy task, by the way—there's a surprising amount of things you have to bring in!). But after inlining them, I couldn't reproduce the issue anymore! If you don't believe me, here's a "reduced" example that you can try for yourself: {{{#!hs -- Parsec.hs {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE RankNTypes #-} module Parsec (Parser, sepBy, try) where import Control.Applicative (Alternative(empty, (<|>))) import Control.Monad (MonadPlus(..), ap) import Data.Functor.Identity (Identity) ------------------------ -- Copied from parsec -- ------------------------ type Parser = Parsec String () type Parsec s u = ParsecT s u Identity newtype ParsecT s u m a = ParsecT {unParser :: forall b . State s u -> (a -> State s u -> ParseError -> m b) -- consumed ok -> (ParseError -> m b) -- consumed err -> (a -> State s u -> ParseError -> m b) -- empty ok -> (ParseError -> m b) -- empty err -> m b } data State s u = State { stateInput :: s, statePos :: !SourcePos, stateUser :: !u } data Message = SysUnExpect !String -- @ library generated unexpect | UnExpect !String -- @ unexpected something | Expect !String -- @ expecting something | Message !String -- @ raw message data ParseError = ParseError !SourcePos [Message] data SourcePos = SourcePos SourceName !Line !Column deriving (Eq, Ord) type SourceName = String type Line = Int type Column = Int instance Functor (ParsecT s u m) where fmap f p = parsecMap f p parsecMap :: (a -> b) -> ParsecT s u m a -> ParsecT s u m b parsecMap f p = ParsecT $ \s cok cerr eok eerr -> unParser p s (cok . f) cerr (eok . f) eerr instance Applicative (ParsecT s u m) where pure = return (<*>) = ap -- TODO: Can this be optimized? instance Alternative (ParsecT s u m) where empty = mzero (<|>) = mplus instance Monad (ParsecT s u m) where return x = parserReturn x p >>= f = parserBind p f fail msg = parserFail msg parserReturn :: a -> ParsecT s u m a parserReturn x = ParsecT $ \s _ _ eok _ -> eok x s (unknownError s) parserBind :: ParsecT s u m a -> (a -> ParsecT s u m b) -> ParsecT s u m b {-# INLINE parserBind #-} parserBind m k = ParsecT $ \s cok cerr eok eerr -> let -- consumed-okay case for m mcok x s err = let -- if (k x) consumes, those go straigt up pcok = cok pcerr = cerr -- if (k x) doesn't consume input, but is okay, -- we still return in the consumed continuation peok x s err' = cok x s (mergeError err err') -- if (k x) doesn't consume input, but errors, -- we return the error in the 'consumed-error' -- continuation peerr err' = cerr (mergeError err err') in unParser (k x) s pcok pcerr peok peerr -- empty-ok case for m meok x s err = let -- in these cases, (k x) can return as empty pcok = cok peok x s err' = eok x s (mergeError err err') pcerr = cerr peerr err' = eerr (mergeError err err') in unParser (k x) s pcok pcerr peok peerr -- consumed-error case for m mcerr = cerr -- empty-error case for m meerr = eerr in unParser m s mcok mcerr meok meerr parserFail :: String -> ParsecT s u m a parserFail msg = ParsecT $ \s _ _ _ eerr -> eerr $ newErrorMessage (Message msg) (statePos s) instance MonadPlus (ParsecT s u m) where mzero = parserZero mplus p1 p2 = parserPlus p1 p2 parserZero :: ParsecT s u m a parserZero = ParsecT $ \s _ _ _ eerr -> eerr $ unknownError s parserPlus :: ParsecT s u m a -> ParsecT s u m a -> ParsecT s u m a {-# INLINE parserPlus #-} parserPlus m n = ParsecT $ \s cok cerr eok eerr -> let meerr err = let neok y s' err' = eok y s' (mergeError err err') neerr err' = eerr $ mergeError err err' in unParser n s cok cerr neok neerr in unParser m s cok cerr eok meerr newErrorUnknown :: SourcePos -> ParseError newErrorUnknown pos = ParseError pos [] unknownError :: State s u -> ParseError unknownError state = newErrorUnknown (statePos state) newErrorMessage :: Message -> SourcePos -> ParseError newErrorMessage msg pos = ParseError pos [msg] mergeError :: ParseError -> ParseError -> ParseError mergeError e1@(ParseError pos1 msgs1) e2@(ParseError pos2 msgs2) -- prefer meaningful errors | null msgs2 && not (null msgs1) = e1 | null msgs1 && not (null msgs2) = e2 | otherwise = case pos1 `compare` pos2 of -- select the longest match EQ -> ParseError pos1 (msgs1 ++ msgs2) GT -> e1 LT -> e2 try :: ParsecT s u m a -> ParsecT s u m a try p = ParsecT $ \s cok _ eok eerr -> unParser p s cok eerr eok eerr class (Monad m) => Stream s m t | s -> t where uncons :: s -> m (Maybe (t,s)) instance (Monad m) => Stream [tok] m tok where uncons [] = return $ Nothing uncons (t:ts) = return $ Just (t,ts) {-# INLINE uncons #-} -- | @sepBy p sep@ parses /zero/ or more occurrences of @p@, separated -- by @sep at . Returns a list of values returned by @p at . -- -- > commaSep p = p `sepBy` (symbol ",") sepBy :: (Stream s m t) => ParsecT s u m a -> ParsecT s u m sep -> ParsecT s u m [a] sepBy p sep = sepBy1 p sep <|> return [] -- | @sepBy1 p sep@ parses /one/ or more occurrences of @p@, separated -- by @sep at . Returns a list of values returned by @p at . sepBy1 :: (Stream s m t) => ParsecT s u m a -> ParsecT s u m sep -> ParsecT s u m [a] sepBy1 p sep = do{ x <- p ; xs <- many (sep >> p) ; return (x:xs) } many :: ParsecT s u m a -> ParsecT s u m [a] many p = do xs <- manyAccum (:) p return (reverse xs) manyAccum :: (a -> [a] -> [a]) -> ParsecT s u m a -> ParsecT s u m [a] manyAccum acc p = ParsecT $ \s cok cerr eok eerr -> let walk xs x s' err = unParser p s' (seq xs $ walk $ acc x xs) -- consumed-ok cerr -- consumed-err manyErr -- empty-ok (\e -> cok (acc x xs) s' e) -- empty-err in unParser p s (walk []) cerr manyErr (\e -> eok [] s e) manyErr = error "Text.ParserCombinators.Parsec.Prim.many: combinator 'many' is applied to a parser that accepts an empty string." }}} {{{#!hs module Lambdabot.Plugin.Haskell.Pl.Parser (list) where import Data.Foldable (asum) import Parsec (Parser, sepBy, try) data Expr = Var Fixity String | App Expr Expr data Fixity = Pref | Inf cons, nil :: Expr cons = Var Inf ":" nil = Var Pref "[]" brackets :: Parser a -> Parser a brackets = undefined symbol :: String -> Parser String symbol = undefined list :: Parser Expr list = asum (map (try . brackets) plist) where plist = [ foldr (\e1 e2 -> cons `App` e1 `App` e2) nil `fmap` (myParser False `sepBy` symbol ","), do e <- myParser False _ <- symbol ".." return $ Var Pref "enumFrom" `App` e, do e <- myParser False _ <- symbol "," e' <- myParser False _ <- symbol ".." return $ Var Pref "enumFromThen" `App` e `App` e', do e <- myParser False _ <- symbol ".." e' <- myParser False return $ Var Pref "enumFromTo" `App` e `App` e', do e <- myParser False _ <- symbol "," e' <- myParser False _ <- symbol ".." e'' <- myParser False return $ Var Pref "enumFromThenTo" `App` e `App` e' `App` e'' ] myParser :: Bool -> Parser Expr myParser = undefined }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 03:02:41 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 03:02:41 -0000 Subject: [GHC] #10249: GHCi leaky abstraction: error message mentions `ghciStepIO` In-Reply-To: <051.818ff8bc84030bedfa7f9663d4a7c3ef@haskell.org> References: <051.818ff8bc84030bedfa7f9663d4a7c3ef@haskell.org> Message-ID: <066.746e8e4793514efbe0744e8a3c4cc841@haskell.org> #10249: GHCi leaky abstraction: error message mentions `ghciStepIO` -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: thomie Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: GHCi | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | ghci/scripts/T10249 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1527, Wiki Page: | Phab:D1528 -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: This appears to be fixed however there is no test by the name `T10249` (although `T10248` is quite related). I've gone ahead and added the test. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 03:08:31 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 03:08:31 -0000 Subject: [GHC] #7289: Mingw FPU init not Windows compatible. In-Reply-To: <046.d34d1fd66180608dd1232dbfc9430105@haskell.org> References: <046.d34d1fd66180608dd1232dbfc9430105@haskell.org> Message-ID: <061.ea84aa0d3cb1864daa2bf408134b5652@haskell.org> #7289: Mingw FPU init not Windows compatible. -----------------------------------+-------------------------------- Reporter: Lennart | Owner: Type: bug | Status: upstream Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 7.2.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------------+-------------------------------- Comment (by bgamari): Phyx, do you think we could make this happen? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 03:10:23 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 03:10:23 -0000 Subject: [GHC] #12937: String merging broken on Darwin Message-ID: <046.522d1e640cb7ec5705f6e2f81dabecb6@haskell.org> #12937: String merging broken on Darwin ------------------------------------------+---------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Linking) | Version: 8.0.1 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ------------------------------------------+---------------------------- Phab:D1290 introduced logic to have the linker merge strings to resolve #9577. Unfortunately this logic does not appear to work as expected on OS X. This should be fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 03:11:33 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 03:11:33 -0000 Subject: [GHC] #12937: String merging broken on Darwin In-Reply-To: <046.522d1e640cb7ec5705f6e2f81dabecb6@haskell.org> References: <046.522d1e640cb7ec5705f6e2f81dabecb6@haskell.org> Message-ID: <061.09bbf645221806ca14a054e2265b232a@haskell.org> #12937: String merging broken on Darwin -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 (Linking) | Resolution: | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"39143a474b5a983421eca9651e77f9c6e09b3958/ghc" 39143a47/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="39143a474b5a983421eca9651e77f9c6e09b3958" Mark T9577 as broken on Darwin due to #12937 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 03:12:15 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 03:12:15 -0000 Subject: [GHC] #12790: GHC 8.0.1 uses copious amounts of RAM and time when trying to compile lambdabot-haskell-plugins In-Reply-To: <044.6c4a4edd18cfc656391e8adc9c55d93a@haskell.org> References: <044.6c4a4edd18cfc656391e8adc9c55d93a@haskell.org> Message-ID: <059.a27049beced6414360ef84310686b120@haskell.org> #12790: GHC 8.0.1 uses copious amounts of RAM and time when trying to compile lambdabot-haskell-plugins -------------------------------------+------------------------------------- Reporter: clint | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): If I turn off the worker wrapper transformation then compilation is much faster. The simpl-stats file shows that a lot of time is being spent inlining ww functions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 03:18:48 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 03:18:48 -0000 Subject: [GHC] #12935: Object code produced by GHC is non-deterministic In-Reply-To: <046.8f3dd2cbcacc5f9595e0dfae3817822d@haskell.org> References: <046.8f3dd2cbcacc5f9595e0dfae3817822d@haskell.org> Message-ID: <061.0d25992ba63aff8780ff0237be686a9f@haskell.org> #12935: Object code produced by GHC is non-deterministic -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * cc: nomeata (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 03:20:13 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 03:20:13 -0000 Subject: [GHC] #10962: Improved arithmetic primops In-Reply-To: <050.9a384d25dddf3580aebe73d3e27aa54b@haskell.org> References: <050.9a384d25dddf3580aebe73d3e27aa54b@haskell.org> Message-ID: <065.13943f845702429df7cff1251a02b768@haskell.org> #10962: Improved arithmetic primops -------------------------------------+------------------------------------- Reporter: nkaretnikov | Owner: Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1966 Wiki Page: | wiki:ImprovedArithmeticPrimops | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => new * owner: nkaretnikov => * milestone: 8.2.1 => 8.4.1 Comment: It doesn't seem likely that this will happen for 8.2. Bumping to 8.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 03:20:59 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 03:20:59 -0000 Subject: [GHC] #5063: unix package has untracked dependency on libbsd In-Reply-To: <045.cf55a0b13cf66f80e2fa9d353d2762fd@haskell.org> References: <045.cf55a0b13cf66f80e2fa9d353d2762fd@haskell.org> Message-ID: <060.cf9844a868e425fac6b72c2e2c11ebd4@haskell.org> #5063: unix package has untracked dependency on libbsd -------------------------------------+------------------------------------- Reporter: duncan | Owner: trommler Type: bug | Status: closed Priority: low | Milestone: 8.2.1 Component: Core Libraries | Version: 7.0.3 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: upstream => closed * resolution: => wontfix Comment: Alright, closing on account of comment:16. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 03:23:31 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 03:23:31 -0000 Subject: [GHC] #9775: "Failed to remove" errors during Windows build from hsc2hs In-Reply-To: <045.a3bc7893c1159a7aa08bb934a48297de@haskell.org> References: <045.a3bc7893c1159a7aa08bb934a48297de@haskell.org> Message-ID: <060.37b8d0483ca7f9562bf635df3c7612df@haskell.org> #9775: "Failed to remove" errors during Windows build from hsc2hs ---------------------------------+---------------------------------------- Reporter: gintas | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: hsc2hs | Version: 7.8.3 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by bgamari): Phyx, did this ever get fixed? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 03:24:07 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 03:24:07 -0000 Subject: [GHC] #4879: Deprecate exports In-Reply-To: <049.ea1fa273b308c2a35269907288b50645@haskell.org> References: <049.ea1fa273b308c2a35269907288b50645@haskell.org> Message-ID: <064.b33076155fd6c5094248e7c95131a417@haskell.org> #4879: Deprecate exports -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: deprecate | warning Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10071 #2119 | Differential Rev(s): Phab:D638 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.4.1 Comment: It would be quite nice if this happened for 8.4, but it certainly won't happen for 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 03:26:32 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 03:26:32 -0000 Subject: [GHC] #8953: Reification drops necessary kind annotations In-Reply-To: <047.1c676b3de5fd3f2cb8726d1a1f304ef8@haskell.org> References: <047.1c676b3de5fd3f2cb8726d1a1f304ef8@haskell.org> Message-ID: <062.ed2ce3e57793d053c92c1f2eb8af045a@haskell.org> #8953: Reification drops necessary kind annotations -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: th/T8953 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D387, Wiki Page: | Phab:D2795 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: Phab:D387 => Phab:D387, Phab:D2795 * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 03:26:33 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 03:26:33 -0000 Subject: [GHC] #10431: EqualityConstraints extension? In-Reply-To: <049.f083101907b8bce0e20c55864639c7df@haskell.org> References: <049.f083101907b8bce0e20c55864639c7df@haskell.org> Message-ID: <064.3d9e26fba8db8797c543d77aceb9767b@haskell.org> #10431: EqualityConstraints extension? -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 7.11 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.4.1 Comment: This won't be happening for 8.2. Bumping to 8.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 03:26:55 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 03:26:55 -0000 Subject: [GHC] #12646: Type family reification misses a kind signature In-Reply-To: <047.cba91014c4d60775bdcbc80a5671d922@haskell.org> References: <047.cba91014c4d60775bdcbc80a5671d922@haskell.org> Message-ID: <062.d00f58b5ddf718eb0a30c6f40823e806@haskell.org> #12646: Type family reification misses a kind signature -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8953 | Differential Rev(s): Phab:D2795 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D2795 * related: => #8953 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 03:31:32 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 03:31:32 -0000 Subject: [GHC] #11578: Fix GHC on AArch64/Arm64 In-Reply-To: <044.82eed99cc066ccb994128f1f7245b038@haskell.org> References: <044.82eed99cc066ccb994128f1f7245b038@haskell.org> Message-ID: <059.1b82b5e9e4a9fd2152037949cc5ededa@haskell.org> #11578: Fix GHC on AArch64/Arm64 -------------------------------------+------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------- Changes (by bgamari): * milestone: 8.2.1 => Comment: De-milestoning due to lack of progress. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 03:31:44 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 03:31:44 -0000 Subject: [GHC] #10174: AArch64 : ghc-stage2 segfaults compiling libraries/parallel In-Reply-To: <044.cba7404039a7d54b7c841a5472570df1@haskell.org> References: <044.cba7404039a7d54b7c841a5472570df1@haskell.org> Message-ID: <059.1ea6efd726445917bc97c7e93476329c@haskell.org> #10174: AArch64 : ghc-stage2 segfaults compiling libraries/parallel ----------------------------------------+------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------- Changes (by bgamari): * milestone: 8.2.1 => Comment: De-milestoning due to lack of progress. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 03:31:52 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 03:31:52 -0000 Subject: [GHC] #10332: AArch64 : divbyzero test fails In-Reply-To: <044.44096dba01a163cc10e492eb20ba8e74@haskell.org> References: <044.44096dba01a163cc10e492eb20ba8e74@haskell.org> Message-ID: <059.cb3d47d279a2fe116b8c74f1de509b72@haskell.org> #10332: AArch64 : divbyzero test fails -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: Incorrect result | Test Case: at runtime | testsuite/tests/rts/divbyzero.hs Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => Comment: De-milestoning due to lack of progress. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 03:32:12 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 03:32:12 -0000 Subject: [GHC] #10383: AArch64: get GHC Calling convention working In-Reply-To: <044.f60f745c18534980e39a07b9e77bca2d@haskell.org> References: <044.f60f745c18534980e39a07b9e77bca2d@haskell.org> Message-ID: <059.c1af625c6691b1b4aef78551510ca3ce@haskell.org> #10383: AArch64: get GHC Calling convention working ----------------------------------------+------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------- Changes (by bgamari): * milestone: 8.2.1 => Comment: De-milestoning due to lack of progress. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 03:32:48 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 03:32:48 -0000 Subject: [GHC] #11557: Unbundle Cabal from GHC In-Reply-To: <045.7d711249cd9c8cedc606277ad69f7e88@haskell.org> References: <045.7d711249cd9c8cedc606277ad69f7e88@haskell.org> Message-ID: <060.288acdee3aa7d0d41986480e335aec1f@haskell.org> #11557: Unbundle Cabal from GHC -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: Component: libraries | Version: 8.1 (other) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => Comment: De-milestoning due to lack of progress. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 03:33:16 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 03:33:16 -0000 Subject: [GHC] #4471: Incorrect Unicode output on Windows Console In-Reply-To: <046.0459baeecbdbac5352442349bd351ed0@haskell.org> References: <046.0459baeecbdbac5352442349bd351ed0@haskell.org> Message-ID: <061.841376fcb397536f8a64c079d7f09257@haskell.org> #4471: Incorrect Unicode output on Windows Console -------------------------------------+------------------------------------- Reporter: sankeld | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.12.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Incorrect result | Test Case: at runtime | Blocked By: | Blocking: Related Tickets: #11394 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => Comment: De-milestoning due to lack of progress. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 03:36:41 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 03:36:41 -0000 Subject: [GHC] #11493: Merge compact normal forms In-Reply-To: <046.817f1145363bc4a821bde6cbb76b8fef@haskell.org> References: <046.817f1145363bc4a821bde6cbb76b8fef@haskell.org> Message-ID: <061.075fdc0634881fa42ffafcb72ffe27c6@haskell.org> #11493: Merge compact normal forms -------------------------------------+------------------------------------- Reporter: bgamari | Owner: ezyang Type: task | Status: closed Priority: normal | Milestone: 8.2.1 Component: | Version: 7.10.3 libraries/compact | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: Compact regions have been merged. There are a few cleanups that remain as #12455. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 03:52:05 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 03:52:05 -0000 Subject: [GHC] #12938: Polykinded associated type family rejected on false pretenses Message-ID: <047.78289df80bb670b87243ff849a83bc7e@haskell.org> #12938: Polykinded associated type family rejected on false pretenses -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If I say {{{ class HasRep a where type Rep a :: TYPE r }}} I get {{{ • Kind variable ‘r’ is implicitly bound in datatype ‘Rep’, but does not appear as the kind of any of its type variables. Perhaps you meant to bind it (with TypeInType) explicitly somewhere? Type variables with inferred kinds: a • In the class declaration for ‘HasRep’ }}} This definition should be accepted, though, as `r` is just an invisible parameter to the associated type family. (I don't know how ''useful'' this is, but it's not bogus.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 04:14:28 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 04:14:28 -0000 Subject: [GHC] #10506: SourceNotes are not applied to all identifiers In-Reply-To: <049.4498c09b08bd56b963d5dfbd770a867b@haskell.org> References: <049.4498c09b08bd56b963d5dfbd770a867b@haskell.org> Message-ID: <064.3c8857a332ba88ca8abe82bd9453f4fc@haskell.org> #10506: SourceNotes are not applied to all identifiers -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1565 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch Comment: gridaphobe, it seems I must have overlooked your patch when I left comment:17. Would it still be helpful to merge it? It seems like a fairly unintrusive change. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 04:15:55 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 04:15:55 -0000 Subject: [GHC] #11472: Remove CallStack CPP guards in GHC 8.4 (was: Remove CallStack CPP guards in GHC 8.2) In-Reply-To: <046.fe08b3b66c71764affdf5dd1237373e0@haskell.org> References: <046.fe08b3b66c71764affdf5dd1237373e0@haskell.org> Message-ID: <061.d703e00fcaff4b6769a8d32b91fa4a1c@haskell.org> #11472: Remove CallStack CPP guards in GHC 8.4 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.4.1 Comment: I think we should be conservative here; the cost of keeping the CPP is relatively small compared to the inconvenience of worrying about which 7.10 releases we can/can't build with. Bumping to 8.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 04:18:04 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 04:18:04 -0000 Subject: [GHC] #11757: Turn on (and require) C99/C11 mode by default In-Reply-To: <042.cdde255506f2bc07285d1fee6acec3cf@haskell.org> References: <042.cdde255506f2bc07285d1fee6acec3cf@haskell.org> Message-ID: <057.f653b84c9835d4d879edba75e0263792@haskell.org> #11757: Turn on (and require) C99/C11 mode by default -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: closed Priority: normal | Milestone: 8.2.1 Component: Build System | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: At this point we require C99; it's not not entirely clear what else remains to be done so I'm closing this. Feel free to reopen or open a new ticket if there is more here than meets the eye. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 04:19:12 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 04:19:12 -0000 Subject: [GHC] #11773: linux/powepc : ghc-stage1 segfaults when building unregisterised In-Reply-To: <044.a4a61ba55383f88cbd05cc1baa6706bc@haskell.org> References: <044.a4a61ba55383f88cbd05cc1baa6706bc@haskell.org> Message-ID: <059.0c925c5da8b3ed10f335ba1c53fbbb6e@haskell.org> #11773: linux/powepc : ghc-stage1 segfaults when building unregisterised ----------------------------------------+------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: #11784 | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.4.1 Comment: This will likely not happen for 8.2; bumping to 8.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 04:20:40 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 04:20:40 -0000 Subject: [GHC] #12223: Get rid of extra_files.py In-Reply-To: <045.25e222aea78531eb17d022751cfc2f2d@haskell.org> References: <045.25e222aea78531eb17d022751cfc2f2d@haskell.org> Message-ID: <060.62a51c16828285f59013b0659726ad1c@haskell.org> #12223: Get rid of extra_files.py -------------------------------------+------------------------------------- Reporter: ezyang | Owner: thomie Type: task | Status: new Priority: highest | Milestone: 8.2.1 Component: Test Suite | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: normal => highest Comment: Thomie, I suspect we are close enough to the branch point that it would be reasonable to carry this out now. Bumping priority so we don't lose track of this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 04:21:48 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 04:21:48 -0000 Subject: [GHC] #11382: Optimize Data.Char In-Reply-To: <046.07b85d059cbd81601867717299b83062@haskell.org> References: <046.07b85d059cbd81601867717299b83062@haskell.org> Message-ID: <061.5e77811a077cb3d33948ba2a421948c5@haskell.org> #11382: Optimize Data.Char -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Core Libraries | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9638 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.4.1 Comment: This won't happen for 8.2; bumping to 8.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 04:23:31 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 04:23:31 -0000 Subject: [GHC] #12224: Replace placeHolderPunRhs with a PlaceHolder value In-Reply-To: <044.09c0b892c4df9568629f9746dd1f86c0@haskell.org> References: <044.09c0b892c4df9568629f9746dd1f86c0@haskell.org> Message-ID: <059.8f86d83f7512ea31644def0e4c18473d@haskell.org> #12224: Replace placeHolderPunRhs with a PlaceHolder value -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: task | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 (Parser) | Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2683 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * differential: D2683 => Phab:D2683 * resolution: => wontfix Comment: It seems that we decided this wouldn't be worthwhile. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 04:29:33 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 04:29:33 -0000 Subject: [GHC] #10074: Implement the 'Improved LLVM Backend' proposal In-Reply-To: <052.e0bd123a5931fad09824fa5aaa592583@haskell.org> References: <052.e0bd123a5931fad09824fa5aaa592583@haskell.org> Message-ID: <067.61b7f3707add87f54941e4cddeadd209@haskell.org> #10074: Implement the 'Improved LLVM Backend' proposal -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: thoughtpolice Type: task | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (LLVM) | Version: Resolution: | Keywords: llvm, codegen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D530 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.4.1 Comment: This won't be happening for 8.2 either. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 04:54:55 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 04:54:55 -0000 Subject: [GHC] #10840: Periodic alarm signals can cause a retry loop to get stuck In-Reply-To: <049.c792fb7fbab25e12997f6231b1f3472d@haskell.org> References: <049.c792fb7fbab25e12997f6231b1f3472d@haskell.org> Message-ID: <064.faa511b62f9471d6c895d019edf18224@haskell.org> #10840: Periodic alarm signals can cause a retry loop to get stuck ---------------------------------+---------------------------------------- Reporter: Rufflewind | Owner: bgamari Type: bug | Status: patch Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2796 Wiki Page: | ---------------------------------+---------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D2796 Comment: Here is a patch enabling the pthread-based itimer implementation on Darwin. Let's see how Harbormaster fares. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 05:08:10 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 05:08:10 -0000 Subject: [GHC] #12404: Document version availability for each language extension In-Reply-To: <045.4012266a90a35b27b3ff877b6e2f633e@haskell.org> References: <045.4012266a90a35b27b3ff877b6e2f633e@haskell.org> Message-ID: <060.41788da3e73e45a535f5bafc6a04ca13@haskell.org> #12404: Document version availability for each language extension -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: Documentation | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: As of eb8bc4dadb767729ae267db7ec7d3bee29f48463 the users guide will include `since` annotations on nearly all language extension flags. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 05:09:35 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 05:09:35 -0000 Subject: [GHC] #10506: SourceNotes are not applied to all identifiers In-Reply-To: <049.4498c09b08bd56b963d5dfbd770a867b@haskell.org> References: <049.4498c09b08bd56b963d5dfbd770a867b@haskell.org> Message-ID: <064.49c92d850400838f9b140e8f73d2e872@haskell.org> #10506: SourceNotes are not applied to all identifiers -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1565 Wiki Page: | -------------------------------------+------------------------------------- Comment (by gridaphobe): It turns out the patch I attached doesn't actually work for my purposes (I think I had only tested it with `-ddump-ticked` instead of building LiquidHaskell against it). There's a brief discussion of why on Phab (https://phabricator.haskell.org/D1565#inline-13012). I can work around this by moving `simpleOptPgm` to a first Core2Core pass, thus exposing the fully unoptimized Core to API users and Plugins. But that's a much more invasive change, and could break existing API users and Plugins. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 08:25:45 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 08:25:45 -0000 Subject: [GHC] #9314: Each object file in a static archive file (.a) is loaded into its own mmap()ed page In-Reply-To: <052.69f389ede5e82026cc5c1d8ff164657e@haskell.org> References: <052.69f389ede5e82026cc5c1d8ff164657e@haskell.org> Message-ID: <067.f7313c6ff763b0d84deefd0dafaa6062@haskell.org> #9314: Each object file in a static archive file (.a) is loaded into its own mmap()ed page -------------------------------------+------------------------------------- Reporter: kazu-yamamoto | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.4.1 Component: Runtime System | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: This was done - I merged the changes into https://phabricator.haskell.org/rGHC04e8366608fee4f5e3358acc855bc6f556c3f508 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 09:43:15 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 09:43:15 -0000 Subject: [GHC] #12939: ghc-8.0.1.20161117 did not install ghc.1 manpage Message-ID: <050.1a6f83d836fa085ef75b0067487924cd@haskell.org> #12939: ghc-8.0.1.20161117 did not install ghc.1 manpage ----------------------------------------+--------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Build System | Version: 8.0.2-rc1 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- This seems to be a build regression from ghc-8.0.1. The ghc.1 manpage was not installed for the 8.0.2 RC1 build. I reported this in mail earlier and unfortunately in the meantime lost the buildlogs on Fedora Copr, but since the upstream binary tarballs for Linux also don't seem to contain ghc.1 either it should not be too hard to reproduce. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 09:58:52 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 09:58:52 -0000 Subject: [GHC] #12940: ghc-8.0.2 RC1 libs installed under package dirs vs Cabal installing packages under abi dir Message-ID: <050.075e1d37abb8e63b1885a88d4a4ff225@haskell.org> #12940: ghc-8.0.2 RC1 libs installed under package dirs vs Cabal installing packages under abi dir ----------------------------------------+--------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Build System | Version: 8.0.2-rc1 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- This may be more of an inconsistency than a bug: Under Linux, ghc-8.0.1.20161117 installs its dynlibs in package libdirs whereas Cabal-1.24.1.0 installs them under the abi dir: eg /usr/lib/ghc-8.0.2/pkg-version/libHSpkg-version-*.so vs /usr/lib/-linux-ghc-8.0.2/libHSpkg-version-*.so It would be more consistent for both to install in the same place. Personally I would even suggest just to install ghc dynlibs in /usr/lib itself but that is probably another discuss for Cabal... That would avoid the need for RPATH's entirely. :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 09:59:58 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 09:59:58 -0000 Subject: [GHC] #12940: ghc-8.0.2 RC1 libs installed under package dirs vs Cabal installing packages under abi dir In-Reply-To: <050.075e1d37abb8e63b1885a88d4a4ff225@haskell.org> References: <050.075e1d37abb8e63b1885a88d4a4ff225@haskell.org> Message-ID: <065.74b9f4e30fce41ed9446e476c56f0fb9@haskell.org> #12940: ghc-8.0.2 RC1 libs installed under package dirs vs Cabal installing packages under abi dir ---------------------------------+---------------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Build System | Version: 8.0.2-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Description changed by juhpetersen: @@ -8,0 +8,1 @@ + New description: This may be more of an inconsistency than a bug: Under Linux, ghc-8.0.1.20161117 installs its dynlibs in package libdirs whereas Cabal-1.24.1.0 installs them under the abi dir: eg /usr/lib/ghc-8.0.2/pkg-version/libHSpkg-version-*.so vs /usr/lib/-linux-ghc-8.0.2/libHSpkg-version-*.so It would be more consistent for both to install in the same place. Personally I would even suggest just to install ghc dynlibs in /usr/lib itself but that is probably another discuss for Cabal... That would avoid the need for RPATH's entirely. :-) -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 10:59:44 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 10:59:44 -0000 Subject: [GHC] #12455: Compact Regions In-Reply-To: <047.80e2661be18b6941b868944e7d5d69fa@haskell.org> References: <047.80e2661be18b6941b868944e7d5d69fa@haskell.org> Message-ID: <062.81c5c9fcd7d1ae502ca73190d5887814@haskell.org> #12455: Compact Regions -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: task | Status: patch Priority: high | Milestone: 8.2.1 Component: Runtime System | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2751 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Marlow ): In [changeset:"7036fde9df61b6eae9719c7f6c656778c756bec9/ghc" 7036fde/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7036fde9df61b6eae9719c7f6c656778c756bec9" Overhaul of Compact Regions (#12455) Summary: This commit makes various improvements and addresses some issues with Compact Regions (aka Compact Normal Forms). This was the most important thing I wanted to fix. Compaction previously prevented GC from running until it was complete, which would be a problem in a multicore setting. Now, we compact using a hand-written Cmm routine that can be interrupted at any point. When a GC is triggered during a sharing-enabled compaction, the GC has to traverse and update the hash table, so this hash table is now stored in the StgCompactNFData object. Previously, compaction consisted of a deepseq using the NFData class, followed by a traversal in C code to copy the data. This is now done in a single pass with hand-written Cmm (see rts/Compact.cmm). We no longer use the NFData instances, instead the Cmm routine evaluates components directly as it compacts. The new compaction is about 50% faster than the old one with no sharing, and a little faster on average with sharing (the cost of the hash table dominates when we're doing sharing). Static objects that don't (transitively) refer to any CAFs don't need to be copied into the compact region. In particular this means we often avoid copying Char values and small Int values, because these are static closures in the runtime. Each Compact# object can support a single compactAdd# operation at any given time, so the Data.Compact library now enforces mutual exclusion using an MVar stored in the Compact object. We now get exceptions rather than killing everything with a barf() when we encounter an object that cannot be compacted (a function, or a mutable object). We now also detect pinned objects, which can't be compacted either. The Data.Compact API has been refactored and cleaned up. A new compactSize operation returns the size (in bytes) of the compact object. Most of the documentation is in the Haddock docs for the compact library, which I've expanded and improved here. Various comments in the code have been improved, especially the main Note [Compact Normal Forms] in rts/sm/CNF.c. I've added a few tests, and expanded a few of the tests that were there. We now also run the tests with GHCi, and in a new test way that enables sanity checking (+RTS -DS). There's a benchmark in libraries/compact/tests/compact_bench.hs for measuring compaction speed and comparing sharing vs. no sharing. The field totalDataW in StgCompactNFData was unnecessary. Test Plan: * new unit tests * validate * tested manually that we can compact Data.Aeson data Reviewers: gcampax, bgamari, ezyang, austin, niteria, hvr, erikd Subscribers: thomie, simonpj Differential Revision: https://phabricator.haskell.org/D2751 GHC Trac Issues: #12455 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 13:00:14 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 13:00:14 -0000 Subject: [GHC] #12914: Port SplitSections to Windows In-Reply-To: <045.d916f7daee7750ba3b581d6e4d886418@haskell.org> References: <045.d916f7daee7750ba3b581d6e4d886418@haskell.org> Message-ID: <060.3cfd84750983f80997664c3c1471fdef@haskell.org> #12914: Port SplitSections to Windows -------------------------------------+------------------------------------- Reporter: olsner | Owner: Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Linking) | Resolution: duplicate | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 8405 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => closed * resolution: => duplicate Comment: Duplicate of #12913 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 13:49:39 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 13:49:39 -0000 Subject: [GHC] #12455: Compact Regions In-Reply-To: <047.80e2661be18b6941b868944e7d5d69fa@haskell.org> References: <047.80e2661be18b6941b868944e7d5d69fa@haskell.org> Message-ID: <062.6d421438881b75b3e5ceba5d3d89a447@haskell.org> #12455: Compact Regions -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: task | Status: closed Priority: high | Milestone: 8.2.1 Component: Runtime System | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2751 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: This has been merged. Yay! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 14:59:06 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 14:59:06 -0000 Subject: [GHC] #9813: Error when reifying type constructor In-Reply-To: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> References: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> Message-ID: <058.a98ada2696b1e69b243c02d09546ad4f@haskell.org> #9813: Error when reifying type constructor -------------------------------------+------------------------------------- Reporter: owst | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Template Haskell | Version: 7.8.3 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1899 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => wontfix * milestone: => 8.2.1 Comment: Phab:D1899 was committed as http://git.haskell.org/ghc.git/commit/93e2c8fff902c12fd22d907f7648d847ebfd2146. Phab:D1985 was committed as http://git.haskell.org/ghc.git/commit/d48220eb7b2029ab90ea8185ac82b6bed51009ad. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 15:05:09 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 15:05:09 -0000 Subject: [GHC] #8460: Annotation reification with types in TH In-Reply-To: <044.054b1a18fb230f3acdfda8b8bca50885@haskell.org> References: <044.054b1a18fb230f3acdfda8b8bca50885@haskell.org> Message-ID: <059.3ee73058cef0e7772ebe79a8c3f172f1@haskell.org> #8460: Annotation reification with types in TH -------------------------------------+------------------------------------- Reporter: errge | Owner: Type: feature request | Status: infoneeded Priority: normal | Milestone: Component: Template Haskell | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8397 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 15:06:10 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 15:06:10 -0000 Subject: [GHC] #12164: Type signatures in patterns not (yet) handled by Template Haskell In-Reply-To: <045.340076456ed55a00b4ceab96e80a74e1@haskell.org> References: <045.340076456ed55a00b4ceab96e80a74e1@haskell.org> Message-ID: <060.0c11fa3ada143ac8974c3f6c59a38083@haskell.org> #12164: Type signatures in patterns not (yet) handled by Template Haskell -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: Template Haskell | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2490 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => fixed * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 15:13:46 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 15:13:46 -0000 Subject: [GHC] #9693: Reloading GHCi with Template Haskell names can panic GHC In-Reply-To: <043.739fde51b47ea4696baf564b0f9ae27e@haskell.org> References: <043.739fde51b47ea4696baf564b0f9ae27e@haskell.org> Message-ID: <058.deb0886d001dd2937e1e50a60beead1c@haskell.org> #9693: Reloading GHCi with Template Haskell names can panic GHC -------------------------------------+------------------------------------- Reporter: maxs | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Template Haskell | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Still reproducible on HEAD, but you'll need a different `Fun.hs`: {{{#!hs module Fun where import Language.Haskell.TH stuff = do -- let x = mkName "X" x <- newName "X" sequence $ [dataD (return []) x [] Nothing [ normalC x [] ] []] }}} And you'll get a slightly different error message: {{{ λ> :r [1 of 2] Compiling Fun ( Fun.hs, interpreted ) [2 of 2] Compiling Main ( thbug.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 8.1.20161010 for x86_64-unknown-linux): kcLookupTcTyCon APromotionErr RecDataConPE Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1076:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1080:37 in ghc:Outputable pprPanic, called at compiler/typecheck/TcHsType.hs:1656:27 in ghc:TcHsType Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 15:14:08 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 15:14:08 -0000 Subject: [GHC] #12503: Template Haskell regression: GHC erroneously thinks a type variable is also a kind In-Reply-To: <050.7c43a93904af70f2e967ba340b84127f@haskell.org> References: <050.7c43a93904af70f2e967ba340b84127f@haskell.org> Message-ID: <065.e102eaa4f0274c7ad29b86c84bc68457@haskell.org> #12503: Template Haskell regression: GHC erroneously thinks a type variable is also a kind -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 15:15:27 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 15:15:27 -0000 Subject: [GHC] #9314: Each object file in a static archive file (.a) is loaded into its own mmap()ed page In-Reply-To: <052.69f389ede5e82026cc5c1d8ff164657e@haskell.org> References: <052.69f389ede5e82026cc5c1d8ff164657e@haskell.org> Message-ID: <067.af7840097f3d3548ef67757f9f8faac0@haskell.org> #9314: Each object file in a static archive file (.a) is loaded into its own mmap()ed page -------------------------------------+------------------------------------- Reporter: kazu-yamamoto | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.4.1 Component: Runtime System | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Ahh right; I had forgotten about this. Thanks Simon. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 15:50:20 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 15:50:20 -0000 Subject: [GHC] #10840: Periodic alarm signals can cause a retry loop to get stuck In-Reply-To: <049.c792fb7fbab25e12997f6231b1f3472d@haskell.org> References: <049.c792fb7fbab25e12997f6231b1f3472d@haskell.org> Message-ID: <064.7df5423e6f92902959c93fe5c6fa7973@haskell.org> #10840: Periodic alarm signals can cause a retry loop to get stuck ---------------------------------+---------------------------------------- Reporter: Rufflewind | Owner: bgamari Type: bug | Status: patch Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2796 Wiki Page: | ---------------------------------+---------------------------------------- Comment (by Ben Gamari ): In [changeset:"d70d452a38bed3321bfc3c14074a6b3e1f30a090/ghc" d70d452a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d70d452a38bed3321bfc3c14074a6b3e1f30a090" rts: Use pthread itimer implementation on Darwin We want to avoid using SIGALRM whenever possible since we will interrupt long-running system calls. See #10840. Test Plan: Validate on Darwin Reviewers: austin, erikd, simonmar Reviewed By: simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2796 GHC Trac Issues: #10840 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 15:50:20 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 15:50:20 -0000 Subject: [GHC] #12388: Don't barf on failures in the RTS linker In-Reply-To: <047.b86bfd9a8524336c9591b8a2b9e093dd@haskell.org> References: <047.b86bfd9a8524336c9591b8a2b9e093dd@haskell.org> Message-ID: <062.8ec85f75671ab0ff919f2da898a92f32@haskell.org> #12388: Don't barf on failures in the RTS linker -------------------------------------+------------------------------------- Reporter: dobenour | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2570 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"83d69dca896c7df1f2a36268d5b45c9283985ebf/ghc" 83d69dc/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="83d69dca896c7df1f2a36268d5b45c9283985ebf" Don't barf() on failures in loadArchive() This patch replaces calls to barf() in loadArchive() with proper error handling. Test Plan: GHC CI Reviewers: rwbarton, erikd, hvr, austin, simonmar, bgamari Reviewed By: bgamari Subscribers: thomie Tags: #ghc Differential Revision: https://phabricator.haskell.org/D2652 GHC Trac Issues: #12388 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 15:53:25 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 15:53:25 -0000 Subject: [GHC] #10068: Make the runtime reflection API for names, modules, locations more systematic In-Reply-To: <046.e24e266e9d617fc4224d115c2a203db8@haskell.org> References: <046.e24e266e9d617fc4224d115c2a203db8@haskell.org> Message-ID: <061.a40d4dada0597b6c2f4cd754c61184d5@haskell.org> #10068: Make the runtime reflection API for names, modules, locations more systematic -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: task | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.4.1 Comment: I was hoping to address this after the `Typeable` rework (#11011) but it doesn't look like I'll get to it for 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 15:54:04 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 15:54:04 -0000 Subject: [GHC] #10007: Fix misattribution of Cost Centre profiles to lintAnnots In-Reply-To: <052.018bee922f3a1f3c0286b790702cf38d@haskell.org> References: <052.018bee922f3a1f3c0286b790702cf38d@haskell.org> Message-ID: <067.4aa9a5c73c99f308cbbe30a199f0f134@haskell.org> #10007: Fix misattribution of Cost Centre profiles to lintAnnots -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: scpmw Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Profiling | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #9961,#5654 | Differential Rev(s): Phab:D616 Wiki Page: | Phab:D636 -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.4.1 Comment: This won't be happening for 8.2 either, sadly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 16:08:59 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 16:08:59 -0000 Subject: [GHC] #12936: Type inference regression in GHC HEAD In-Reply-To: <050.1f2cf84cf2dccac9b01fc4b4cae905cd@haskell.org> References: <050.1f2cf84cf2dccac9b01fc4b4cae905cd@haskell.org> Message-ID: <065.61b5f13b66ba7fc2f3ce05cf5e1c4372@haskell.org> #12936: Type inference regression in GHC HEAD -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: simonpj (added) Comment: Simon, this bug was introduced in https://git.haskell.org/ghc.git/commit/f8c966c70bf4e6ca7482658d4eaca2dae367213f. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 16:34:02 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 16:34:02 -0000 Subject: [GHC] #12388: Don't barf on failures in the RTS linker In-Reply-To: <047.b86bfd9a8524336c9591b8a2b9e093dd@haskell.org> References: <047.b86bfd9a8524336c9591b8a2b9e093dd@haskell.org> Message-ID: <062.3af62106f40f3e5e74518233de39a8dd@haskell.org> #12388: Don't barf on failures in the RTS linker -------------------------------------+------------------------------------- Reporter: dobenour | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2570 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 16:36:12 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 16:36:12 -0000 Subject: [GHC] #12388: Don't barf on failures in the RTS linker In-Reply-To: <047.b86bfd9a8524336c9591b8a2b9e093dd@haskell.org> References: <047.b86bfd9a8524336c9591b8a2b9e093dd@haskell.org> Message-ID: <062.8cc20b36ae9adcda14f56dbaec3cde27@haskell.org> #12388: Don't barf on failures in the RTS linker -------------------------------------+------------------------------------- Reporter: dobenour | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2570 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: closed => new * resolution: fixed => Comment: Actually, there are plenty more `barf`s in the linker. This will be a long road... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 16:36:35 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 16:36:35 -0000 Subject: [GHC] #10840: Periodic alarm signals can cause a retry loop to get stuck In-Reply-To: <049.c792fb7fbab25e12997f6231b1f3472d@haskell.org> References: <049.c792fb7fbab25e12997f6231b1f3472d@haskell.org> Message-ID: <064.f44dd2febc42e23a175533cb681b6620@haskell.org> #10840: Periodic alarm signals can cause a retry loop to get stuck ---------------------------------+---------------------------------------- Reporter: Rufflewind | Owner: bgamari Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2796 Wiki Page: | ---------------------------------+---------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 16:40:23 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 16:40:23 -0000 Subject: [GHC] #12591: Profiled build broken In-Reply-To: <046.e6322f7e4e3b94a349405b8198f096f8@haskell.org> References: <046.e6322f7e4e3b94a349405b8198f096f8@haskell.org> Message-ID: <061.b8348aa721a3ee0fefd4f5f30a92fe34@haskell.org> #12591: Profiled build broken -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: I can no longer reproduce this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 16:42:38 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 16:42:38 -0000 Subject: [GHC] #11703: Segmentation fault/internal error: evacuate: strange closure type 15 with GHC.Generics In-Reply-To: <051.d88b9387a728df13c9639e42ea307515@haskell.org> References: <051.d88b9387a728df13c9639e42ea307515@haskell.org> Message-ID: <066.639236aec31f15a45d581e584a580851@haskell.org> #11703: Segmentation fault/internal error: evacuate: strange closure type 15 with GHC.Generics -------------------------------------+------------------------------------- Reporter: NathanWaivio | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 7.10.3 Resolution: fixed | Keywords: Segmentation | Fault, Generics, Runtime error Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: attached Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => fixed Comment: I'm going to close this because (1) I can't reproduce it anymore, and (2) the example requires far too many dependencies to be a reliable test case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 16:48:59 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 16:48:59 -0000 Subject: [GHC] #12652: Type checker no longer accepting code using function composition and rank-n types In-Reply-To: <045.e7a1398648cc72a4fa6aad75be0260b1@haskell.org> References: <045.e7a1398648cc72a4fa6aad75be0260b1@haskell.org> Message-ID: <060.1f945d763480a53bb38ab9b5d073bd32@haskell.org> #12652: Type checker no longer accepting code using function composition and rank-n types -------------------------------------+------------------------------------- Reporter: ezyang | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Agree with Richard. If we can impredicatively use `($)` without `ImpredicativeTypes`, I don't see why we'd need it for `(.)`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 16:50:27 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 16:50:27 -0000 Subject: [GHC] #10007: Fix misattribution of Cost Centre profiles to lintAnnots In-Reply-To: <052.018bee922f3a1f3c0286b790702cf38d@haskell.org> References: <052.018bee922f3a1f3c0286b790702cf38d@haskell.org> Message-ID: <067.a1ac396300e030f715a7d76887710658@haskell.org> #10007: Fix misattribution of Cost Centre profiles to lintAnnots -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: scpmw Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Profiling | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #9961,#5654 | Differential Rev(s): Phab:D616 Wiki Page: | Phab:D636 -------------------------------------+------------------------------------- Changes (by simonmar): * milestone: 8.4.1 => 8.2.1 Comment: As it happens, I was just working on this! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 16:50:39 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 16:50:39 -0000 Subject: [GHC] #10007: Fix misattribution of Cost Centre profiles to lintAnnots In-Reply-To: <052.018bee922f3a1f3c0286b790702cf38d@haskell.org> References: <052.018bee922f3a1f3c0286b790702cf38d@haskell.org> Message-ID: <067.b42b159ab7fdc70454ecb202db7a530b@haskell.org> #10007: Fix misattribution of Cost Centre profiles to lintAnnots -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Profiling | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #9961,#5654 | Differential Rev(s): Phab:D616 Wiki Page: | Phab:D636 -------------------------------------+------------------------------------- Changes (by simonmar): * owner: scpmw => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 17:00:38 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 17:00:38 -0000 Subject: [GHC] #7782: flag to run the demand analysis a second time In-Reply-To: <046.1ec01ebe7149b378f35843d2bc9ef200@haskell.org> References: <046.1ec01ebe7149b378f35843d2bc9ef200@haskell.org> Message-ID: <061.126ade3cd174b526df1e1a682d69ea44@haskell.org> #7782: flag to run the demand analysis a second time -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: Type: task | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #4941, #5302, | Differential Rev(s): #6087, #4962 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: nomeata (added) Comment: nomeata, is this perhaps addressed by f4fd98c717a7f68d76a3054021b3be65d1ebad82? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 17:04:37 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 17:04:37 -0000 Subject: [GHC] #11046: lookupTypeName does not support type operators not starting with : In-Reply-To: <045.eabc8eeec9cc920f3e0838e9774eff4d@haskell.org> References: <045.eabc8eeec9cc920f3e0838e9774eff4d@haskell.org> Message-ID: <060.64896332f4b32d31a25b7489eb75fb15@haskell.org> #11046: lookupTypeName does not support type operators not starting with : -------------------------------------+------------------------------------- Reporter: oerjan | Owner: albertus Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Template Haskell | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | testsuite/tests/th/TH_lookupName.hs, | testsuite/tests/th/T11046.hs Blocked By: | Blocking: Related Tickets: #10583 | Differential Rev(s): Phab:D1451 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.4.1 Comment: It doesn't look like this will be fixed for 8.2 either. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 17:05:09 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 17:05:09 -0000 Subject: [GHC] #11425: The GHC API doesn't provide a good hscTarget option for tooling In-Reply-To: <046.59f16ebaf7d24ed3fda7cb6515755975@haskell.org> References: <046.59f16ebaf7d24ed3fda7cb6515755975@haskell.org> Message-ID: <061.6020859ab67cb1db2089f14065db6ed6@haskell.org> #11425: The GHC API doesn't provide a good hscTarget option for tooling -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature request | Status: new Priority: high | Milestone: Component: GHC API | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => Comment: De-milestoning due to lack of progress but I do hope that someone picks this up. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 17:06:01 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 17:06:01 -0000 Subject: [GHC] #7782: flag to run the demand analysis a second time In-Reply-To: <046.1ec01ebe7149b378f35843d2bc9ef200@haskell.org> References: <046.1ec01ebe7149b378f35843d2bc9ef200@haskell.org> Message-ID: <061.ea036f951ec169086452dcd48226928d@haskell.org> #7782: flag to run the demand analysis a second time -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: Type: task | Status: closed Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #4941, #5302, | Differential Rev(s): #6087, #4962 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: new => closed * resolution: => fixed Comment: Looks like it! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 17:06:07 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 17:06:07 -0000 Subject: [GHC] #314: #line pragmas not respected inside nested comments In-Reply-To: <045.e2d94babc1a72770327e5dfb6388ae06@haskell.org> References: <045.e2d94babc1a72770327e5dfb6388ae06@haskell.org> Message-ID: <060.3d8d845ef7e3937820fec318762f7696@haskell.org> #314: #line pragmas not respected inside nested comments -------------------------------------+------------------------------------- Reporter: nobody | Owner: Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 6.4 (Parser) | Resolution: None | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: read032 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.4.1 Comment: This won't get fixed for 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 17:11:12 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 17:11:12 -0000 Subject: [GHC] #8971: Native Code Generator for 8.0.1 is not as optimized as 7.6.3... In-Reply-To: <050.c7fda5d49ea9b3871e29284bd1fa2f5f@haskell.org> References: <050.c7fda5d49ea9b3871e29284bd1fa2f5f@haskell.org> Message-ID: <065.4e46543ecdedf7e8de2c4f7c26bb49b9@haskell.org> #8971: Native Code Generator for 8.0.1 is not as optimized as 7.6.3... -------------------------------------+------------------------------------- Reporter: GordonBGood | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 8.0.1 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.2.1 => Comment: I'm de-milestoning this due to a lack of developer interest. Currently we have many bugs and few developers; many of these bugs affect platforms far more common than i386 and these are the bugs we will focus on. However, don't let this stop you, the motivated reader, from picking this up. There are several ideas for fixing this issue described in this ticket. Please do pick one and implement it! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 17:11:28 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 17:11:28 -0000 Subject: [GHC] #12866: GHC internal error while building darcsden In-Reply-To: <047.b99e56fbdb3bd24d0c5cb2ff430c4a60@haskell.org> References: <047.b99e56fbdb3bd24d0c5cb2ff430c4a60@haskell.org> Message-ID: <062.3d2a267777d4f73b6663bbddf86c92f4@haskell.org> #12866: GHC internal error while building darcsden -------------------------------------+------------------------------------- Reporter: simonmic | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12867 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => fixed * related: => #12867 Comment: Here's (what I believe to be) a minimal test case: {{{#!hs {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE ConstraintKinds #-} -- {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE ImplicitParams #-} module T12866 where import Control.Monad.IO.Class type BT bt = (BackendTransient bt, ?backendTransient :: bt) type BTIO bt = (BT bt, MonadIO (BackendTransientM bt)) class (Functor (BackendTransientM bt), Monad (BackendTransientM bt)) => BackendTransient bt where type BackendTransientM bt :: * -> * }}} Running this with GHC 8.0.1/8.0.2 yields: {{{ [1 of 1] Compiling T12866 ( Bug.hs, interpreted ) Bug.hs:11:33: error: • GHC internal error: ‘BackendTransientM’ is not in scope during type checking, but it passed the renamer tcl_env of environment: [a142 :-> Type variable ‘bt’ = bt] • In the first argument of ‘MonadIO’, namely ‘BackendTransientM bt’ In the type ‘(BT bt, MonadIO (BackendTransientM bt))’ In the type declaration for ‘BTIO’ Bug.hs:13:1: error: • Non type-variable argument in the constraint: Functor (BackendTransientM bt) (Use FlexibleContexts to permit this) • In the context: (Functor (BackendTransientM bt), Monad (BackendTransientM bt)) While checking the super-classes of class ‘BackendTransient’ In the class declaration for ‘BackendTransient’ }}} But in GHC HEAD, there's no internal error: {{{ [1 of 1] Compiling T12866 ( Bug.hs, interpreted ) Bug.hs:11:1: error: • Non type-variable argument in the constraint: MonadIO (BackendTransientM bt) (Use FlexibleContexts to permit this) • In the type synonym declaration for ‘BTIO’ Bug.hs:13:1: error: • Non type-variable argument in the constraint: Functor (BackendTransientM bt) (Use FlexibleContexts to permit this) • In the context: (Functor (BackendTransientM bt), Monad (BackendTransientM bt)) While checking the super-classes of class ‘BackendTransient’ In the class declaration for ‘BackendTransient’ }}} The workaround is simple: just enable `FlexibleContexts`. That makes it compile without issue on GHC 8.0.1, 8.0.2, and HEAD. For completeness's sake, I was able to reproduce the issue when building `darcsden` with GHC 8.0.1, and I confirmed that enabling `FlexibleContexts` at the top of the file made the internal error go away. I don't have time to build everything again with GHC HEAD, but I think the story would be pretty similar. In conclusion, this is a much more elaborate example of #12867. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 17:46:34 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 17:46:34 -0000 Subject: [GHC] #11715: Constraint vs * In-Reply-To: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> References: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> Message-ID: <061.12c2fe7f20ea94ff447c971cec3548e0@haskell.org> #11715: Constraint vs * -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Yes, it would work to have `TYPE :: Coherency -> RuntimeRep -> Type` instead of the current `TYPE :: RuntimeRep -> Type`. Algebraically, this is just the same as adding more constructors to `RuntimeRep`, as Simon and I have proposed. But I see how this might be preferable. I'm curious for Simon's opinion on this, noting that such a design is independent of the ability to use `Constraint`s to the left of `->` or `Type`s to the left of `=>`. This new design does not solve the problem I outline at the end of comment:47 though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 18:24:41 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 18:24:41 -0000 Subject: [GHC] #9775: "Failed to remove" errors during Windows build from hsc2hs In-Reply-To: <045.a3bc7893c1159a7aa08bb934a48297de@haskell.org> References: <045.a3bc7893c1159a7aa08bb934a48297de@haskell.org> Message-ID: <060.2a8102a0e9ed210ca13fa1d836cba214@haskell.org> #9775: "Failed to remove" errors during Windows build from hsc2hs ---------------------------------+---------------------------------------- Reporter: gintas | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: hsc2hs | Version: 7.8.3 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by Phyx-): I implemented the required changed in `process` but ran into some issues that I'm still working on. https://github.com/haskell/process/issues/77 I should have it done this week. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 18:36:36 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 18:36:36 -0000 Subject: [GHC] #8668: SPECIALIZE silently fails to apply In-Reply-To: <047.7bfae31244c263823ac3d1193001c490@haskell.org> References: <047.7bfae31244c263823ac3d1193001c490@haskell.org> Message-ID: <062.c6bcad640473da8ebce5517fbecac029@haskell.org> #8668: SPECIALIZE silently fails to apply -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nfrisby): Executive summary: It looks like the expected optimization is achieved in GHC 7.10.2. I don't know if something was broken and is now fixed or if some other change side-stepped the original problem, etc. etc. In GHC 7.10.2, `fcTest` seems to be ''faster'' than `vtTest` (5 repetitions, using the same `-O3` setting that crockeea used); that's a reversal of the originally discussed behavior. Compiling `Foo.hs` yields the following rule, which fires when compiling `Main.hs`, in spite of the dfuns on the LHS (see #7080). {{{ ------ Local rules for imported ids -------- "SPEC plusFastCyc" [ALWAYS] forall (@ m_a3Ai) ($dFactored_a3Aj :: Factored m_a3Ai Int) ($dVector_a3Bz :: V.Vector U.Vector Int). plusFastCyc @ (VT U.Vector m_a3Ai) @ Int (Foo.$fNumVT @ U.Vector @ m_a3Ai @ Int (GHC.Real.$p1Real @ Int (GHC.Real.$p1Integral @ Int ($dFactored_a3Aj `cast` (Foo.NTCo:Factored[0] _N _N :: Factored m_a3Ai Int ~R# Integral Int)))) $dVector_a3Bz $dFactored_a3Aj) = Foo.plusFastCyc_$splusFastCyc @ m_a3Ai $dFactored_a3Aj }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 18:54:36 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 18:54:36 -0000 Subject: [GHC] #11444: 8.0 rc1 panics in applyTypeToArgs In-Reply-To: <043.8caf87d45669172d15b0507d2f671ad2@haskell.org> References: <043.8caf87d45669172d15b0507d2f671ad2@haskell.org> Message-ID: <058.50d5bee7a01103ad2f505fd1e1ed0bce@haskell.org> #11444: 8.0 rc1 panics in applyTypeToArgs -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 18:54:51 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 18:54:51 -0000 Subject: [GHC] #9320: Inlining regression/strangeness in 7.8 In-Reply-To: <044.93d9094a260d4e54544e3180a10496bb@haskell.org> References: <044.93d9094a260d4e54544e3180a10496bb@haskell.org> Message-ID: <059.757c41e27cb12db054397d020a7a4bfd@haskell.org> #9320: Inlining regression/strangeness in 7.8 -------------------------------------+------------------------------------- Reporter: dolio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Inlining 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: | -------------------------------------+------------------------------------- Comment (by nfrisby): FYI, with GHC 7.10.2, both `-O1` and `-O2` give code where `test0` takes 80x as much time as does `test1`. {{{ $ uname -a Linux sci-host-a-i-bd1bec66 3.13.0-100-generic #147-Ubuntu SMP Tue Oct 18 16:48:51 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.10.2 $ ghc -fforce-recomp -O2 --make Main.hs $ time ./Main 500000 True; time ./Main 500000 False 1 real 0m4.703s user 0m4.682s sys 0m0.020s 1 real 0m0.055s user 0m0.051s sys 0m0.004s $ echo '4.7 / 0.055' | bc -l 85.45454545454545454545 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 18:57:49 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 18:57:49 -0000 Subject: [GHC] #11560: panic: isInjectiveTyCon sees a TcTyCon In-Reply-To: <047.844547fa9c9539b9ad0e369581a719b2@haskell.org> References: <047.844547fa9c9539b9ad0e369581a719b2@haskell.org> Message-ID: <062.e50f12258ff3aa2ad730c003562cf645@haskell.org> #11560: panic: isInjectiveTyCon sees a TcTyCon -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I can't reproduce this with GHC 8.1.20161125: {{{ $ /opt/ghc/head/bin/ghci GHCi, version 8.1.20161125: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci λ> :set -XTypeFamilies -XTypeInType λ> :m +Data.Kind λ> type family T (l :: *) (k :: l) :: * where { T * Int = * } :3:46: error: • Mismatched type name in type family instance. Expected: T Actual: * • In the type family declaration for ‘T’ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 19:19:19 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 19:19:19 -0000 Subject: [GHC] #9522: SPECIALISE pragmas for derived instances In-Reply-To: <046.6cda231aacfa5256df483e3d63fc0ff8@haskell.org> References: <046.6cda231aacfa5256df483e3d63fc0ff8@haskell.org> Message-ID: <061.b521f10627bb21cab04cbdc213d5d518@haskell.org> #9522: SPECIALISE pragmas for derived instances -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 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 nfrisby): * cc: nfrisby (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 19:24:59 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 19:24:59 -0000 Subject: [GHC] #12941: Extend nofib with benchmarks focused on compiler performance Message-ID: <046.3aa091438d5be9f86a44802bbf848533@haskell.org> #12941: Extend nofib with benchmarks focused on compiler performance -------------------------------------+------------------------------------- Reporter: michalt | Owner: michalt Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: NoFib | Version: benchmark suite | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC seems to be missing a set of benchmarks focused on the compiler performance that would contain some realistic examples and make it easy to test even small changes in the compiler (by having a simple "before and after" comparison). The two main use cases would be: - Anyone hacking on GHC could quickly check even for small performance differences (running the benchmark with and without their change). - Tracking performance of GHC over time (potentially as part of perf.haskell.org) We already have two collections of performance tests/benchmarks: - `tests/perf/compiler` which contains actual tests (part of `validate`) and seems to be focused on larger regressions (if the bounds are too tight, it can generate a fair amount of noise). - `nofib` which is mostly focused on benchmarking the code produced by GHC (the vast majority of the modules compile within 400ms). The current idea is to extend `nofib` with some modules that are only checking the performance of GHC (e.g., might be a library module that doesn't contain `main`). Please see: https://mail.haskell.org/pipermail/ghc- devs/2016-December/013323.html for an initial discussion about this. Also related: - Ticket focused on improvements to `tests/perf/compiler` #12758 - Proposal of having a similar tests but hosted in a separate repo on github: https://github.com/ghc-proposals/ghc-proposals/pull/26 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 19:31:25 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 19:31:25 -0000 Subject: [GHC] #3384: Add HsSyn prettyprinter tests In-Reply-To: <044.d11e412e7968bb1bf100410e6ff17081@haskell.org> References: <044.d11e412e7968bb1bf100410e6ff17081@haskell.org> Message-ID: <059.b7e3b3e780737c1518e0e9634e9f92d3@haskell.org> #3384: Add HsSyn prettyprinter tests -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: task | Status: patch Priority: normal | Milestone: 8.2.1 Component: Test Suite | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2752 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Alan Zimmerman ): In [changeset:"499e43824bda967546ebf95ee33ec1f84a114a7c/ghc" 499e438/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="499e43824bda967546ebf95ee33ec1f84a114a7c" Add HsSyn prettyprinter tests Summary: Add prettyprinter tests, which take a file, parse it, pretty print it, re-parse the pretty printed version and then compare the original and new ASTs (ignoring locations) Updates haddock submodule to match the AST changes. There are three issues outstanding 1. Extra parens around a context are not reproduced. This will require an AST change and will be done in a separate patch. 2. Currently if an `HsTickPragma` is found, this is not pretty-printed, to prevent noise in the output. I am not sure what the desired behaviour in this case is, so have left it as before. Test Ppr047 is marked as expected fail for this. 3. Apart from in a context, the ParsedSource AST keeps all the parens from the original source. Something is happening in the renamer to remove the parens around visible type application, causing T12530 to fail, as the dumped splice decl is after the renamer. This needs to be fixed by keeping the parens, but I do not know where they are being removed. I have amended the test to pass, by removing the parens in the expected output. Test Plan: ./validate Reviewers: goldfire, mpickering, simonpj, bgamari, austin Reviewed By: simonpj, bgamari Subscribers: simonpj, goldfire, thomie, mpickering Differential Revision: https://phabricator.haskell.org/D2752 GHC Trac Issues: #3384 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 19:32:49 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 19:32:49 -0000 Subject: [GHC] #11715: Constraint vs * In-Reply-To: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> References: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> Message-ID: <061.091585b1e11306da293bb342f275dd3b@haskell.org> #11715: Constraint vs * -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by int-index): > Algebraically, this is just the same as adding more constructors to `RuntimeRep` Well, yes, but * you'd have to double the amount of constructors in `RuntimeRep` (coherent and incoherent version of each). * more importantly, you couldn't be parametric in `RuntimeRep` and non- parametric in `Coherency` or vice versa. > This new design does not solve the problem I outline at the end of comment:47 though. Forgive my ignorance, but is it necessary to have the same `TYPE` in Core as is in surface syntax? Couldn't we just "forget" the coherency annotation everywhere and translate surface `TYPE :: Coherency -> RuntimeRep -> Type` to `TYPE :: RuntimeRep -> Type`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 19:32:56 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 19:32:56 -0000 Subject: [GHC] #12941: Extend nofib with benchmarks focused on compiler performance In-Reply-To: <046.3aa091438d5be9f86a44802bbf848533@haskell.org> References: <046.3aa091438d5be9f86a44802bbf848533@haskell.org> Message-ID: <061.71496f426d164db60d4d4c53b6f4230f@haskell.org> #12941: Extend nofib with benchmarks focused on compiler performance -------------------------------------+------------------------------------- Reporter: michalt | Owner: michalt Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: NoFib benchmark | Version: suite | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by michalt): For timings (not allocation), we could use: https://github.com/Gabriel439/bench (basically criterion for command line) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 19:48:29 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 19:48:29 -0000 Subject: [GHC] #5835: Make better use of known dictionaries In-Reply-To: <041.da4dbbc1a9ab52eefd6923c34aad6eb5@haskell.org> References: <041.da4dbbc1a9ab52eefd6923c34aad6eb5@haskell.org> Message-ID: <056.23eade80eb2a14a2d9bd728677fd439f@haskell.org> #5835: Make better use of known dictionaries -------------------------------------+------------------------------------- Reporter: rl | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.5 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 nfrisby): * cc: nfrisby (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 19:48:42 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 19:48:42 -0000 Subject: [GHC] #12791: Superclass methods could be more aggressively specialised. In-Reply-To: <049.67ba67008b7e7aca654f97100047ee77@haskell.org> References: <049.67ba67008b7e7aca654f97100047ee77@haskell.org> Message-ID: <064.ee642c232a45b0818b549534336eacf9@haskell.org> #12791: Superclass methods could be more aggressively specialised. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: danharaj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #5835 | Differential Rev(s): Phab:D2714 Wiki Page: | -------------------------------------+------------------------------------- Changes (by nfrisby): * cc: nfrisby (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 19:49:40 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 19:49:40 -0000 Subject: [GHC] #11715: Constraint vs * In-Reply-To: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> References: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> Message-ID: <061.9546f5d24189e6ed746887916806ce13@haskell.org> #11715: Constraint vs * -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by int-index): Nevermind, it seems that this leads to the problem described in comment:6. Type families with domain `Type` can distinguish between between `Constraint` and `Type` in surface Haskell, so this difference needs to remain in Core. And in comment:7 I see Simon advocating the same change to KindCo as you describe. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 19:58:14 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 19:58:14 -0000 Subject: [GHC] #8581: Pattern synonym used in an expression context could have different constraints to pattern used in a pattern context In-Reply-To: <045.ffb8b433d262c0e3b5b415c2eeca2eee@haskell.org> References: <045.ffb8b433d262c0e3b5b415c2eeca2eee@haskell.org> Message-ID: <060.5e3c5a3db07cf685b1f9eb1cfe1278ae@haskell.org> #8581: Pattern synonym used in an expression context could have different constraints to pattern used in a pattern context -------------------------------------+------------------------------------- Reporter: cactus | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by lelf): * cc: lelf (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 19:59:10 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 19:59:10 -0000 Subject: [GHC] #11080: Open data kinds In-Reply-To: <047.64e06093644ddd3cb76b94e28bef420a@haskell.org> References: <047.64e06093644ddd3cb76b94e28bef420a@haskell.org> Message-ID: <062.db2946b60668473819d3321fa6adccc6@haskell.org> #11080: Open data kinds -------------------------------------+------------------------------------- Reporter: dmcclean | Owner: jstolarek Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #6024 | Differential Rev(s): Phab:D1778 Wiki Page: | GhcKinds/KindsWithoutData | -------------------------------------+------------------------------------- Changes (by lelf): * cc: lelf (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 20:03:43 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 20:03:43 -0000 Subject: [GHC] #12926: ghc master (8.1.20161202) panics with assertion failure with devel2 flavor and -O2 In-Reply-To: <044.d632e605d759db42e889e2bb2d7fb6bc@haskell.org> References: <044.d632e605d759db42e889e2bb2d7fb6bc@haskell.org> Message-ID: <059.173a5c1a0978d263a3d22df8febfc480@haskell.org> #12926: ghc master (8.1.20161202) panics with assertion failure with devel2 flavor and -O2 -------------------------------------+------------------------------------- Reporter: pacak | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I can't reproduce this with GHC 8.1.20161207. Do I need to do something differently? {{{ $ ghc/inplace/bin/ghc-stage2 -O2 Bug.hs -fforce-recomp [1 of 1] Compiling A ( Bug.hs, Bug.o ) Bug.hs:20:10: warning: [-Wmissing-methods] • No explicit implementation for ‘basicOverlaps’, ‘basicInitialize’, and ‘basicUnsafeRead’ • In the instance declaration for ‘MVector Data.Vector.Unboxed.Base.MVector A’ Bug.hs:28:10: warning: [-Wmissing-methods] • No explicit implementation for ‘Data.Vector.Generic.Base.basicUnsafeFreeze’, ‘Data.Vector.Generic.Base.basicUnsafeThaw’, ‘Data.Vector.Generic.Base.basicLength’, ‘Data.Vector.Generic.Base.basicUnsafeSlice’, and ‘Data.Vector.Generic.Base.basicUnsafeIndexM’ • In the instance declaration for ‘Data.Vector.Generic.Base.Vector Data.Vector.Unboxed.Base.Vector A’ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 20:07:02 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 20:07:02 -0000 Subject: [GHC] #11715: Constraint vs * In-Reply-To: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> References: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> Message-ID: <061.52e3a03534370f6bb7ab6ddf63104aa3@haskell.org> #11715: Constraint vs * -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Yes -- you've answered your own question correctly. And, yes, you're right about doubling the constructors, etc. I was just mentioning the algebraic correspondence mostly to convince myself that what you're proposing would clearly work (as well as what I've proposed), from a technical standpoint. But it remains to be seen whether either approach really works out. I need to ponder this more and am curious for Simon's input. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 20:10:47 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 20:10:47 -0000 Subject: [GHC] #5835: Make better use of known dictionaries In-Reply-To: <041.da4dbbc1a9ab52eefd6923c34aad6eb5@haskell.org> References: <041.da4dbbc1a9ab52eefd6923c34aad6eb5@haskell.org> Message-ID: <056.8164e3626891ce2590c702e3821ba0bc@haskell.org> #5835: Make better use of known dictionaries -------------------------------------+------------------------------------- Reporter: rl | Owner: danharaj Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.5 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 danharaj): * owner: => danharaj -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 20:15:42 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 20:15:42 -0000 Subject: [GHC] #8779: Exhaustiveness checks for pattern synonyms In-Reply-To: <046.b910d807e2ecf5838df4d05d7ec88278@haskell.org> References: <046.b910d807e2ecf5838df4d05d7ec88278@haskell.org> Message-ID: <061.e889abe6674c75c93c5ab211dc2e16f9@haskell.org> #8779: Exhaustiveness checks for pattern synonyms -------------------------------------+------------------------------------- Reporter: nomeata | Owner: mpickering Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.1 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2669 Wiki Page: | -------------------------------------+------------------------------------- Changes (by lelf): * cc: lelf (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 20:21:02 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 20:21:02 -0000 Subject: [GHC] #12791: Superclass methods could be more aggressively specialised. In-Reply-To: <049.67ba67008b7e7aca654f97100047ee77@haskell.org> References: <049.67ba67008b7e7aca654f97100047ee77@haskell.org> Message-ID: <064.cbcb73dcd748ea3f808625a34a996014@haskell.org> #12791: Superclass methods could be more aggressively specialised. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: danharaj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #5835 | Differential Rev(s): Phab:D2714 Wiki Page: | -------------------------------------+------------------------------------- Comment (by danharaj): #5835 is indeed related and my patch resolves it too. However, my patch causes a regression in #10359. The core has bad bits that all look similar to this: {{{ main6 main6 = \ ds -> case ds of _ { Box ds1 ds2 -> case ds1 main7 main_number ds2 of dt { D# ipv -> Box (\ @ dum $d(%,%) -> ds1 ($p1(%,%) $d(%,%), $p2(%,%) $d(%,%))) dt } } }}} The issue is caused by the fact that the `Box` constructor has a local tuple constraint: {{{#!hs type Numerical a = (Fractional a, Real a) data Box a = Box { func :: forall dum. (Numerical dum) => dum -> a -> a , obj :: !a } }}} When code that unpacks `Box` and uses its local constraint to do some stuff, the solver needs to produce the tuple constraint. A tuple constraint is implemented as a class with its components as superclasses. The solution with my current patch goes like: {{{ runStage interact with inerts { workitem = [W] $d(%,%) :: (Fractional num[sk], Real num[sk]) (CDictCan(psc)) updSolvedSetTcs: [W] $d(%,%) :: (Fractional num[sk], Real num[sk]) newWantedEvVar/cache hit [G] $dFractional :: Fractional num[sk] newWantedEvVar/cache hit [G] $dReal :: Real num[sk] addTcEvBind a2bg [W] $d(%,%) = C:(%,%) @[Fractional num[sk], Real num[sk]] [$dFractional, $dReal] end stage interact with inerts } }}} The old, unpatched solution goes like: {{{ runStage interact with inerts { workitem = [W] $d(%,%) :: (Fractional dum[sk], Real dum[sk]) (CDictCan(psc)) addTcEvBind a1Tk [W] $d(%,%) = $d(%,%) end stage interact with inerts } }}} The old solution just uses the tuple constraint we are given. The new solution is trying to be too smart: It tries to solve from the top-level instance and it can do so because the solver has decomposed the given tuple constraint into given constraints of its components. So we end up constructing a dictionary that is essentially the same as a given one. Bad! It's not clear to me how to exclude corner cases like this. It is potentially possible that we *do* want to try to solve a tuple constraint from instances because we might be able to find a more concrete solution to one of its components. Is it possible to notice this inefficiency in a core2core pass and resolve it then instead? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 20:23:15 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 20:23:15 -0000 Subject: [GHC] #12926: ghc master (8.1.20161202) panics with assertion failure with devel2 flavor and -O2 In-Reply-To: <044.d632e605d759db42e889e2bb2d7fb6bc@haskell.org> References: <044.d632e605d759db42e889e2bb2d7fb6bc@haskell.org> Message-ID: <059.dd34405e904a8992b805f67cd33469e8@haskell.org> #12926: ghc master (8.1.20161202) panics with assertion failure with devel2 flavor and -O2 -------------------------------------+------------------------------------- Reporter: pacak | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Ryan, are you trying with a `-DDEBUG` build? You will need `GhcStage2HcOpts += -DDEBUG` in your `build.mk`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 20:25:22 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 20:25:22 -0000 Subject: [GHC] #3384: Add HsSyn prettyprinter tests In-Reply-To: <044.d11e412e7968bb1bf100410e6ff17081@haskell.org> References: <044.d11e412e7968bb1bf100410e6ff17081@haskell.org> Message-ID: <059.5ea05080baddf9f346d228f4c84e290f@haskell.org> #3384: Add HsSyn prettyprinter tests -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: task | Status: closed Priority: normal | Milestone: 8.2.1 Component: Test Suite | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2752 Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 20:26:57 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 20:26:57 -0000 Subject: [GHC] #5835: Make better use of known dictionaries In-Reply-To: <041.da4dbbc1a9ab52eefd6923c34aad6eb5@haskell.org> References: <041.da4dbbc1a9ab52eefd6923c34aad6eb5@haskell.org> Message-ID: <056.6cd8f07aefbc014c7c66e9fa6927db82@haskell.org> #5835: Make better use of known dictionaries -------------------------------------+------------------------------------- Reporter: rl | Owner: danharaj Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.5 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): Phab:D2714 Wiki Page: | -------------------------------------+------------------------------------- Changes (by danharaj): * differential: => Phab:D2714 Comment: My patch for #12791 also resolves this issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 20:27:38 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 20:27:38 -0000 Subject: [GHC] #10371: GHC fails to inline and specialize a function In-Reply-To: <050.00603e7cdfd7583d3908a8e6d41ce4f9@haskell.org> References: <050.00603e7cdfd7583d3908a8e6d41ce4f9@haskell.org> Message-ID: <065.fed85b5be856dfb03add92269768c77e@haskell.org> #10371: GHC fails to inline and specialize a function -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8668 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nfrisby): I haven't been able to reproduce this with GHC 7.10.2. I see ~200 ns averages using: * GHC 7.10.2 * subhask-0.1.0.0 or subhask-0.1.0.0 (from Hackage sdist, with relaxed build-depends) * MonadRandom-0.4, QuickCheck-2.8.1, approximate-0.2.2.2, base-4.8.1.0, bloomfilter-2.0.1.0, bytes-0.15.0.1, bytestring-0.10.6.0, cassava-0.4.4.0, containers-0.5.6.2, deepseq-1.4.1.1, erf-2.0.0.0, gamma-0.9.0.2, ghc- prim-0.4.0.0, hmatrix-0.16.1.5, hyperloglog-0.3.4, lens-4.12.3, monad- primitive-0.1, mtl-2.2.1, parallel-3.2.0.6, pipes-4.1.6, primitive-0.6.1.0, semigroups-0.16.2.2, template-haskell-2.10.0.0, vector-0.10.12.3 However, I don't know if either of those are the right `subhask` to use. MikeIzbicki, do you have the source for the `subhask` that you originally observed the regression with? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 20:28:16 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 20:28:16 -0000 Subject: [GHC] #11560: panic: isInjectiveTyCon sees a TcTyCon In-Reply-To: <047.844547fa9c9539b9ad0e369581a719b2@haskell.org> References: <047.844547fa9c9539b9ad0e369581a719b2@haskell.org> Message-ID: <062.83b9e32d104e61e00b4906919c64a28b@haskell.org> #11560: panic: isInjectiveTyCon sees a TcTyCon -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * owner: => goldfire Comment: This panic is gone (even in 8.0.1), but the code should be accepted. It's indeed a `TypeInType` error, and I imagine has nothing at all to do with injective type families. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 20:31:54 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 20:31:54 -0000 Subject: [GHC] #11560: panic: isInjectiveTyCon sees a TcTyCon In-Reply-To: <047.844547fa9c9539b9ad0e369581a719b2@haskell.org> References: <047.844547fa9c9539b9ad0e369581a719b2@haskell.org> Message-ID: <062.fa37cffc1c81bad8bb5c4128eeff5c55@haskell.org> #11560: panic: isInjectiveTyCon sees a TcTyCon -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I take it the fix for this would be the same as the fix needed for #11307 and #11400? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 20:36:00 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 20:36:00 -0000 Subject: [GHC] #12942: Add infix flag for class and data declarations Message-ID: <044.ad2a88252aaa49d53b0869c522534f50@haskell.org> #12942: Add infix flag for class and data declarations -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #3384 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- At the moment, data and type declarations using infix formatting produce the same AST as those using prefix. So {{{#!hs type a ++ b = c }}} and {{{#!hs type (++) a b = c }}} cannot be distinguished in the parsed source, without looking at the `OccName` details of the constructor being defined. Having access to the `OccName` requires an additional constraint which explodes out over the entire AST because of its recursive definitions. In keeping with moving the parsed source to more directly reflect the source code as parsed, add a specific flag to the declaration to indicate the fixity, as used in a `Match` now too. Note: this flag is to capture the fixity used for the lexical definition of the type, primarily for use by `ppr` and `ghc-exactprint`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 20:42:47 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 20:42:47 -0000 Subject: [GHC] #12943: Adjust AST to capture additional parens around a context Message-ID: <044.dc86666ec431fcc5710f72223c59769b@haskell.org> #12943: Adjust AST to capture additional parens around a context -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #3384 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- At the moment the parser strips redundant parens around a context when constructing the AST. So the following two definitions would end up with the same AST. {{{#!hs foo :: (Show a) => a -> String foo' :: ((Show a)) => a -> String }}} This causes roundtripping of an AST via `ppr` to fail, and adds complexity to the API Annotations. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 21:44:04 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 21:44:04 -0000 Subject: [GHC] #7289: Mingw FPU init not Windows compatible. In-Reply-To: <046.d34d1fd66180608dd1232dbfc9430105@haskell.org> References: <046.d34d1fd66180608dd1232dbfc9430105@haskell.org> Message-ID: <061.7c0b4797e53db8f8bacf27d1023d18ea@haskell.org> #7289: Mingw FPU init not Windows compatible. -----------------------------------+-------------------------------- Reporter: Lennart | Owner: Phyx- Type: bug | Status: upstream Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 7.2.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------------+-------------------------------- Changes (by Phyx-): * owner: => Phyx- Comment: Sure, I'll whip up a patch in the weekend. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 7 23:51:23 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Dec 2016 23:51:23 -0000 Subject: [GHC] #12944: ghc master (8.1.20161206) panics with assertion failure with devel2 flavor and -O Message-ID: <044.3fe8817d41680dd8c67e674ebd7c6a0f@haskell.org> #12944: ghc master (8.1.20161206) panics with assertion failure with devel2 flavor and -O -------------------------------------+------------------------------------- Reporter: pacak | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- ghc version: 41ec722d71 with assertion that fails in https://ghc.haskell.org/trac/ghc/ticket/12926 commented out {{{#!hs {-# LANGUAGE TypeFamilies #-} module Numeric.Polynomial.Log () where class AdditiveGroup v where (^+^) :: v -> v -> v negateV :: v -> v (^-^) :: v -> v -> v v ^-^ v' = v ^+^ negateV v' class AdditiveGroup v => VectorSpace v where type Scalar v :: * (*^) :: Scalar v -> v -> v data Poly1 a = Poly1 a a data IntOfLog poly a = IntOfLog !a !(poly a) instance Num a => AdditiveGroup (Poly1 a) where {-# INLINE (^+^) #-} {-# INLINE negateV #-} Poly1 a b ^+^ Poly1 a' b' = Poly1 (a + a') (b + b') negateV (Poly1 a b) = Poly1 (negate a) (negate b) instance (AdditiveGroup (poly a), Num a) => AdditiveGroup (IntOfLog poly a) where {-# INLINE (^+^) #-} {-# INLINE negateV #-} IntOfLog k p ^+^ IntOfLog k' p' = IntOfLog (k + k') (p ^+^ p') negateV (IntOfLog k p) = IntOfLog (negate k) (negateV p) {-# SPECIALISE instance Num a => AdditiveGroup (IntOfLog Poly1 a) #-} instance (VectorSpace (poly a), Scalar (poly a) ~ a, Num a) => VectorSpace (IntOfLog poly a) where type Scalar (IntOfLog poly a) = a s *^ IntOfLog k p = IntOfLog (s * k) (s *^ p) }}} {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.1.20161206 for x86_64-unknown-linux): ASSERT failed! $dAdditiveGroup_aIU Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1114:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1163:22 in ghc:Outputable assertPprPanic, called at compiler/stgSyn/CoreToStg.hs:967:78 in ghc:CoreToStg Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1114:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1118:37 in ghc:Outputable pprPanic, called at compiler/utils/Outputable.hs:1161:5 in ghc:Outputable assertPprPanic, called at compiler/stgSyn/CoreToStg.hs:967:78 in ghc:CoreToStg Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 8 01:42:37 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Dec 2016 01:42:37 -0000 Subject: [GHC] #11272: Overloaded state-monadic function is not specialised In-Reply-To: <052.a8b4d0c324481dd5e9a190050e8955fc@haskell.org> References: <052.a8b4d0c324481dd5e9a190050e8955fc@haskell.org> Message-ID: <067.4b1280c07905150b270eaf40399ef953@haskell.org> #11272: Overloaded state-monadic function is not specialised -------------------------------------+------------------------------------- Reporter: NickSmallbone | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: | -------------------------------------+------------------------------------- Comment (by nfrisby): If I add the `INLINABLE overloaded` pragma in `A` and place a `SPECIALIZE overloaded :: Int -> Int -> State () ()` pragma in `B`, then the desired specialization ultimately happens (with GHC 7.10.2). I mention this as a possible workaround for people stuck on this bug. Forcing the `overloaded` wrapper to be specialized creates a "SPEC" rule whose RHS gets gently simplified enough before the Specialise pass such that GHC then notices the specializable call to the `$woverloaded` worker. Since that worker inherits the original `INLINABLE` pragma (see #6056), GHC automatically specializes the worker. The specialized worker eventually ends up in the RHS of `specialised`. This approach was not obvious to me because I hadn't yet realized that forcibly specializing a w/w wrapper function tends to cause the worker to be automatically specialized. Two shortcomings come immediately to mind. 1. I get the `SPECIALISE pragma on INLINE function probably won't fire: ‘overloaded’` warning, even though the rule does fire. 1. In my experience, `SPECIALIZE` pragmas are often rejected with "LHS too complicated to desugar" (e.g. #10555), so you may need to use `GHC.Exts.inline` instead. * Note that `inline` crucially causes the w/w wrapper to be inlined before the Specialise pass (during `Phase = InitialPhase [Gentle]`), whereas the w/w wrapper's `INLINE[0]` activation delays its natural inlining until after the Specialise pass. * This is awkward: we only want to inline `overloaded` '''if it was replaced by a w/w wrapper'''! A "safer" but more troublesome alternative is to have `inline overloaded` somewhere else in the module, but then you must ensure that it's exported from this module, else GHC will cull it and the SPEC rule before the rule can usefully affect `specialise`. This risks binary bloat, but it also prevents `inline` from ever accidentally inlining `overloaded` into the genuine code. It's remarkable that the w/w transform creates the cast that prevents the wrapper from being automatically specialized (that cast floats to the top of the unfolding, which blocks specialization; see `Note [Specialisation shape]` in `Specialise.hs`). The demand analyzer and w/w transform in this example see through the `State` type synonym, `StateT` newtype, and `Identity` newtype all the way to the `s -> (# a, s #)` worker type -- the `Specialise` pass does not yet have the complementary X-ray vision to see through the corresponding cast to the desired lambdas in the wrapper's unfolding. (#9509 is also specialization-blocked-by-a-cast-atop-the-unfolding, but I think the cast in that case comes from an actual bug.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 8 02:02:42 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Dec 2016 02:02:42 -0000 Subject: [GHC] #1311: newtypes of unboxed types disallowed - documentation bug and/or feature request In-Reply-To: <051.57f61623dcae713596d5a8bb0b9f83bb@haskell.org> References: <051.57f61623dcae713596d5a8bb0b9f83bb@haskell.org> Message-ID: <066.540f41a536934700cdd82b9ed464126b@haskell.org> #1311: newtypes of unboxed types disallowed - documentation bug and/or feature request -------------------------------------+------------------------------------- Reporter: Isaac Dupree | Owner: osa1 Type: feature request | Status: new Priority: low | Milestone: ⊥ Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 8 02:34:12 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Dec 2016 02:34:12 -0000 Subject: [GHC] #12600: Overloaded method causes insufficient specialization In-Reply-To: <043.07cdd679c81a8644725c82782d392414@haskell.org> References: <043.07cdd679c81a8644725c82782d392414@haskell.org> Message-ID: <058.686d3fc691e634a335262115002e1e68@haskell.org> #12600: Overloaded method causes insufficient specialization -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nfrisby): With GHC 7.10.2, adding another method to the class results in `foo` being as specialized as expected. I therefore suspect this ticket is due to the Specialise pass interacting poorly with casts (dictionaries for classes with one method and no superclasses are implemented as a newtype). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 8 03:40:52 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Dec 2016 03:40:52 -0000 Subject: [GHC] #12945: Backpack signature matching doesn't pick up orphan instances Message-ID: <045.e76f05f03835a070e9df77510bd40649@haskell.org> #12945: Backpack signature matching doesn't pick up orphan instances -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.1 (Type checker) | Keywords: backpack | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Repro: {{{ unit impl where module A where data T = T module B(module A, module B) where import A instance Show T where show T = "T" unit sig where signature B where data T = T instance Show T module App where import B app = print T unit main where dependency sig[B=impl:B] module Main where import App main = app }}} I get: {{{ ezyang at sabre:~$ ghc-head --backpack foo.bkp [1 of 3] Processing impl Instantiating impl [1 of 2] Compiling A (.hs -> .o) [2 of 2] Compiling B (.hs -> .o) [2 of 3] Processing sig [3 of 3] Processing main Instantiating main [1 of 1] Including sig[B=impl:B] Instantiating sig[B=impl:B] [1 of 2] Compiling B[sig] (.hsig -> .o) sig/sig-HVnmSw44WZeBfwnUur4wzl/../B.hi:1:1: error: No instance for (GHC.Show.Show impl:A.T) arising when attempting to show that instance [safe] GHC.Show.Show impl:A.T -- Defined in ‘impl:B’ is provided by ‘impl:B’ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 8 11:08:19 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Dec 2016 11:08:19 -0000 Subject: [GHC] #8971: Native Code Generator for 8.0.1 is not as optimized as 7.6.3... In-Reply-To: <050.c7fda5d49ea9b3871e29284bd1fa2f5f@haskell.org> References: <050.c7fda5d49ea9b3871e29284bd1fa2f5f@haskell.org> Message-ID: <065.3a76ad9d3681a7f4bc58512cfc0165c4@haskell.org> #8971: Native Code Generator for 8.0.1 is not as optimized as 7.6.3... -------------------------------------+------------------------------------- Reporter: GordonBGood | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 8.0.1 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: | -------------------------------------+------------------------------------- Comment (by GordonBGood): Replying to [comment:30 bgamari]: > I'm de-milestoning this due to a lack of developer interest. Currently we have many bugs and few developers; many of these bugs affect platforms far more common than i386 and these are the bugs we will focus on. I agree that this issue isn't all that important in the Great Scheme Of Things given that the Native Code Generator (NCG) is gradually being relegated to just a builder for quick-cycle debugging purposes as the (slower compiling, but producing generally faster code) LLVM back end becomes more and more stable (and usable, especially if the required LLVM files, including patches, are distributed with/made available for each GHC version starting with 8.2.1, as promised[https://ghc.haskell.org/trac/ghc/wiki/ImprovedLLVMBackend]). Much more important are performance bugs that affect '''both''' the NCG and LLVM back ends such as the (I'm beginning to think related to each other) #12798 and #12808 pair of issues that although only slowing performance by up to 40% or so (although for all platforms instead of only x86 by 100% as here), affect the perception that GHC code is "slower than Cee" and for which there is no workaround such as choosing an alternate back end. I'll monitor this and will probably either close the issue or at least reduce its priority if version 8.2.1 integrates the LLVM back end as well as it promises. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 8 11:51:54 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Dec 2016 11:51:54 -0000 Subject: [GHC] #12727: ghc: panic! (the 'impossible' happened) - piResultTy In-Reply-To: <047.7a02b67b63e3ce77f03bfc70c60ffa06@haskell.org> References: <047.7a02b67b63e3ce77f03bfc70c60ffa06@haskell.org> Message-ID: <062.1a3e7a9e9b44a85663bdd2cfbc6c2a81@haskell.org> #12727: ghc: panic! (the 'impossible' happened) - piResultTy -------------------------------------+------------------------------------- Reporter: ocharles | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ocharles): We've had a few more panics today, each different: {{{ [248 of 278] Compiling Handler.Auth ( src/Handler/Auth.hs, dist/build/Handler/Auth.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.1.20161117 for x86_64-unknown-linux): Iface Lint failure In interface for Data.ByteString.Internal Unfolding of $fShowByteString_$cshow : warning: In the expression: $trModule2 (unpackChars x_apbxX) (: @ Char shows6 ([] @ Char)) Non-function type in function position Fun type: TrName Arg type: [Char] Arg: unpackChars x_apbxX $fShowByteString_$cshow = \ (x_apbxX :: ByteString) -> : @ Char shows6 ($trModule2 (unpackChars x_apbxX) (: @ Char shows6 ([] @ Char))) Iface expr = \ (x :: ByteString) -> : @ Char shows6 (showLitString (unpackChars x) (: @ Char shows6 ([] @ Char))) }}} and {{{ [215 of 278] Compiling Foundation ( Foundation.hs, dist/build/Foundation.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.1.20161117 for x86_64-unknown-linux): tyThingTyCon Identifier ‘$fEnumIsolationLevel’ }}} I'll continue to see if I can get any sort of repro on this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 8 13:20:06 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Dec 2016 13:20:06 -0000 Subject: [GHC] #12946: Cannot load hmatrix with ghci -fexternal-interpreter: missing symbol ___ieee_divdc3 Message-ID: <047.61f1ff3a967a9dd024164163630b3512@haskell.org> #12946: Cannot load hmatrix with ghci -fexternal-interpreter: missing symbol ___ieee_divdc3 -------------------------------------+------------------------------------- Reporter: simonmar | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Runtime | Version: 8.0.1 System (Linker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- See https://mail.haskell.org/pipermail/glasgow-haskell- users/2016-December/026419.html I tested this on Linux and it seems to work, so I suspect it is an OS X issue. There's an old but related bug on the hmatrix bug tracker: https://github.com/albertoruiz/hmatrix/issues/81 Can someone with OS X look into this please? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 8 13:42:58 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Dec 2016 13:42:58 -0000 Subject: [GHC] #12727: ghc: panic! (the 'impossible' happened) - piResultTy In-Reply-To: <047.7a02b67b63e3ce77f03bfc70c60ffa06@haskell.org> References: <047.7a02b67b63e3ce77f03bfc70c60ffa06@haskell.org> Message-ID: <062.23f7cff3ac7bcd8d568a4738ff60eae0@haskell.org> #12727: ghc: panic! (the 'impossible' happened) - piResultTy -------------------------------------+------------------------------------- Reporter: ocharles | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ocharles): Another rather huge core lint offense this time: https://gist.github.com/ocharles/5237072c9a5620198e31d74baab388b8 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 8 16:20:30 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Dec 2016 16:20:30 -0000 Subject: [GHC] #12947: Core lint error Message-ID: <051.c8f6f90ba6faede01ce48237dc8657bf@haskell.org> #12947: Core lint error -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs import qualified Control.Monad.Fail as Fail newtype P m a = P { unP :: (a -> IO (m ())) -> IO (m ()) } instance Functor (P m) where instance Applicative (P m) where instance Monad (P m) where instance (Fail.MonadFail m) => Fail.MonadFail (P m) where fail msg = ContT $ \ _ -> Fail.fail msg }}} fails when run with `$ ghci -ignore-dot-ghci -fdefer-typed-holes -dcore- lint /tmp/tQZR.hs`, log is attached -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 8 16:20:44 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Dec 2016 16:20:44 -0000 Subject: [GHC] #12947: Core lint error In-Reply-To: <051.c8f6f90ba6faede01ce48237dc8657bf@haskell.org> References: <051.c8f6f90ba6faede01ce48237dc8657bf@haskell.org> Message-ID: <066.c5516527c59b55424fc8d19fe6028ca7@haskell.org> #12947: Core lint error -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * Attachment "log" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 8 17:16:58 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Dec 2016 17:16:58 -0000 Subject: [GHC] #12942: Add infix flag for class and data declarations In-Reply-To: <044.ad2a88252aaa49d53b0869c522534f50@haskell.org> References: <044.ad2a88252aaa49d53b0869c522534f50@haskell.org> Message-ID: <059.125ffa1a665232bb4c7df50307dc685a@haskell.org> #12942: Add infix flag for class and data declarations -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #3384 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm all for capturing the source syntax in the AST, so thumbs-up from me. I don't understand this comment though > Having access to the OccName requires an additional constraint which explodes out over the entire AST because of its recursive definitions. I'm sure you are right, but what additional constraint? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 8 18:25:46 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Dec 2016 18:25:46 -0000 Subject: [GHC] #12941: Extend nofib with benchmarks focused on compiler performance In-Reply-To: <046.3aa091438d5be9f86a44802bbf848533@haskell.org> References: <046.3aa091438d5be9f86a44802bbf848533@haskell.org> Message-ID: <061.a0d580afb37d12e1db280ded43eeddaf@haskell.org> #12941: Extend nofib with benchmarks focused on compiler performance -------------------------------------+------------------------------------- Reporter: michalt | Owner: michalt Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: NoFib benchmark | Version: suite | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: bgamari (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 8 18:32:39 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Dec 2016 18:32:39 -0000 Subject: [GHC] #12942: Add infix flag for class and data declarations In-Reply-To: <044.ad2a88252aaa49d53b0869c522534f50@haskell.org> References: <044.ad2a88252aaa49d53b0869c522534f50@haskell.org> Message-ID: <059.220bc6850c124336d9bbfe3bf0b51562@haskell.org> #12942: Add infix flag for class and data declarations -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #3384 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alanz): The additional `HasOccNameId`constraints were introduced in Phab:D2752, this patch should remove them again. E.g. {{{#!hs pp_vanilla_decl_head :: (OutputableBndrId name, HasOccNameId name) => Located name -> LHsQTyVars name -> HsContext name -> SDoc pp_vanilla_decl_head thing (HsQTvs { hsq_explicit = tyvars }) context = hsep [pprHsContext context, pp_tyvars tyvars] where pp_tyvars (varl:varsr) | isSymOcc $ occName (unLoc thing) = hsep [ppr (unLoc varl), pprInfixOcc (unLoc thing) , hsep (map (ppr.unLoc) varsr)] | otherwise = hsep [ pprPrefixOcc (unLoc thing) , hsep (map (ppr.unLoc) (varl:varsr))] pp_tyvars [] = ppr thing }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 8 18:34:31 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Dec 2016 18:34:31 -0000 Subject: [GHC] #12871: Upgrade Mingw-w64 bindist for GHC to GCC 6.2.0 and Binutils 2.27.2 In-Reply-To: <044.3b0884ef0bcd4a4b9bcf5d4f10c21a66@haskell.org> References: <044.3b0884ef0bcd4a4b9bcf5d4f10c21a66@haskell.org> Message-ID: <059.1fbb549a63f980408225b41aee360f7a@haskell.org> #12871: Upgrade Mingw-w64 bindist for GHC to GCC 6.2.0 and Binutils 2.27.2 -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: task | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2749 Wiki Page: | Phab:D2810 -------------------------------------+------------------------------------- Changes (by Phyx-): * differential: Phab:D2749 => Phab:D2749 Phab:D2810 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 8 19:05:15 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Dec 2016 19:05:15 -0000 Subject: [GHC] #12948: Implement unwind rules for non-Intel architectures Message-ID: <046.8f503227fa066851e13a6dcbab195691@haskell.org> #12948: Implement unwind rules for non-Intel architectures -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- To support DWARF-based stack unwinding, a platform needs a few things, * Valid unwind records in `stg_stop_thread` (defined in `rts/StgStartup.cmm`) * Support in the native code generator (by implementing the `generateUnwindTable` field of `NcgImpl`) * A mapping of register numbers to DWARF register numbers (see `dwarfRegNo` in `nativeGhc/Dwarf/Constants.hs`) * For unwinding support in the runtime system: * Unwinding support in `libdw` * a `set_initial_registers` implementation (see `rts/Libdw.c`) Currently the only platforms that has all of these implemented is x86_64 and i386. Someone should pick up the other platforms. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 8 19:12:41 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Dec 2016 19:12:41 -0000 Subject: [GHC] #12944: ghc master (8.1.20161206) panics with assertion failure with devel2 flavor and -O In-Reply-To: <044.3fe8817d41680dd8c67e674ebd7c6a0f@haskell.org> References: <044.3fe8817d41680dd8c67e674ebd7c6a0f@haskell.org> Message-ID: <059.890f640f5c181d215f699e65bc9adeb1@haskell.org> #12944: ghc master (8.1.20161206) panics with assertion failure with devel2 flavor and -O -------------------------------------+------------------------------------- Reporter: pacak | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: normal => highest * component: Compiler => Compiler (CodeGen) * milestone: => 8.2.1 Comment: I can also reproduce this with 9bcc4e335b34c00191e8897aa7393c3856e8996f, {{{ $ ghc -O ~/hi.hs [1 of 1] Compiling Numeric.Polynomial.Log ( /home/ben/hi.hs, /home/ben/hi.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.1.20161207 for x86_64-unknown-linux): StgCmmEnv: variable not found $dAdditiveGroup_aIP local binds for: *^ ^+^ negateV ^-^ $p1VectorSpace $fAdditiveGroupPoly1 $WIntOfLog $fAdditiveGroupIntOfLog_$cnegateV $fAdditiveGroupIntOfLog_$c^+^ $fAdditiveGroupPoly1_$c^-^ $fAdditiveGroupPoly1_$cnegateV $fAdditiveGroupPoly1_$c^+^ w_s12P ww_s12Q ww1_s12R ww2_s12S ww3_s12T dt_s12U Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1116:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1120:37 in ghc:Outputable pprPanic, called at compiler/codeGen/StgCmmEnv.hs:137:9 in ghc:StgCmmEnv Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 8 19:14:00 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Dec 2016 19:14:00 -0000 Subject: [GHC] #12944: ghc master (8.1.20161206) panics with assertion failure with devel2 flavor and -O In-Reply-To: <044.3fe8817d41680dd8c67e674ebd7c6a0f@haskell.org> References: <044.3fe8817d41680dd8c67e674ebd7c6a0f@haskell.org> Message-ID: <059.0888f2f79b65edeacc16537e6ec6db5f@haskell.org> #12944: ghc master (8.1.20161206) panics with assertion failure with devel2 flavor and -O -------------------------------------+------------------------------------- Reporter: pacak | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): It looks like the failing assertion is this, {{{#!hs lookupBinding :: IdEnv HowBound -> Id -> HowBound lookupBinding env v = case lookupVarEnv env v of Just xx -> xx Nothing -> ASSERT2( isGlobalId v, ppr v ) ImportBound }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 8 19:28:08 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Dec 2016 19:28:08 -0000 Subject: [GHC] #4505: Segmentation fault on long input (list of pairs) In-Reply-To: <046.2dc545b3c32e7b8eef61780dd9491ae5@haskell.org> References: <046.2dc545b3c32e7b8eef61780dd9491ae5@haskell.org> Message-ID: <061.ff7444d49acd4cd8ddfb87330a3ab32e@haskell.org> #4505: Segmentation fault on long input (list of pairs) -------------------------------------+------------------------------------- Reporter: cathper | Owner: Type: bug | Status: patch Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: Segmentation | fault, segfault, long input Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: 4258 | Blocking: Related Tickets: | Differential Rev(s): Phab:D1180 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch Comment: Here is a quick attempt at a patch: https://github.com/bgamari/array/commit/73144bda5cf4f5ba2e73206ea0a53200e30218af. The only trouble here is that we now are doing overflow in unsafe indexing operations, which will cost a bit of performance. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 8 20:14:12 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Dec 2016 20:14:12 -0000 Subject: [GHC] #4505: Segmentation fault on long input (list of pairs) In-Reply-To: <046.2dc545b3c32e7b8eef61780dd9491ae5@haskell.org> References: <046.2dc545b3c32e7b8eef61780dd9491ae5@haskell.org> Message-ID: <061.f329a5da85600da4f6d2ed741df4dbd7@haskell.org> #4505: Segmentation fault on long input (list of pairs) -------------------------------------+------------------------------------- Reporter: cathper | Owner: Type: bug | Status: patch Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: Segmentation | fault, segfault, long input Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: 4258 | Blocking: Related Tickets: | Differential Rev(s): Phab:D1180 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Please ignore comment:45 which was intended for #229. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 8 20:14:17 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Dec 2016 20:14:17 -0000 Subject: [GHC] #4505: Segmentation fault on long input (list of pairs) In-Reply-To: <046.2dc545b3c32e7b8eef61780dd9491ae5@haskell.org> References: <046.2dc545b3c32e7b8eef61780dd9491ae5@haskell.org> Message-ID: <061.fb532f72fbeccdf378b71a4d33b531f9@haskell.org> #4505: Segmentation fault on long input (list of pairs) -------------------------------------+------------------------------------- Reporter: cathper | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: Segmentation | fault, segfault, long input Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: 4258 | Blocking: Related Tickets: | Differential Rev(s): Phab:D1180 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => new -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 8 21:04:48 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Dec 2016 21:04:48 -0000 Subject: [GHC] #1791: heap overflow should generate an exception In-Reply-To: <044.abdddbf09447556bb749e2aa1d8c6598@haskell.org> References: <044.abdddbf09447556bb749e2aa1d8c6598@haskell.org> Message-ID: <059.0ba9bed9293e2435cf50e698f355e2ec@haskell.org> #1791: heap overflow should generate an exception -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: feature request | Status: patch Priority: normal | Milestone: ⊥ Component: Runtime System | Version: 6.8 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: outofmem2 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2790 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D2790 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 8 21:24:33 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Dec 2016 21:24:33 -0000 Subject: [GHC] #10074: Implement the 'Improved LLVM Backend' proposal In-Reply-To: <052.e0bd123a5931fad09824fa5aaa592583@haskell.org> References: <052.e0bd123a5931fad09824fa5aaa592583@haskell.org> Message-ID: <067.516b4a0f8bc8d80c0313aa9e07c95593@haskell.org> #10074: Implement the 'Improved LLVM Backend' proposal -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: thoughtpolice Type: task | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (LLVM) | Version: Resolution: | Keywords: llvm, codegen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11295, #12470 | Differential Rev(s): Phab:D530 Wiki Page: | wiki:ImprovedLLVMBackend | -------------------------------------+------------------------------------- Changes (by bgamari): * wikipage: => wiki:ImprovedLLVMBackend * related: => #11295, #12470 Comment: Currently this plan is in need of an implementor. At this point I'm not convinced that we want or need to ship our own LLVM builds. Rather, I this it would be sufficient to simply try to understand what LLVM passes are fruitful for GHC's code (#11295) and be specific about which LLVM version a particular GHC release targets (which we already do). There are related opportunities here that are a bit farther off, * Track aliasing information more precisely (see wiki:Commentary/Compiler/Backends/LLVM/Alias) * Move to the LLVM bitcode format (#12470) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 8 21:26:41 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Dec 2016 21:26:41 -0000 Subject: [GHC] #8971: Native Code Generator for 8.0.1 is not as optimized as 7.6.3... In-Reply-To: <050.c7fda5d49ea9b3871e29284bd1fa2f5f@haskell.org> References: <050.c7fda5d49ea9b3871e29284bd1fa2f5f@haskell.org> Message-ID: <065.c6d06c7f830bdaea8d78cd68637e70b4@haskell.org> #8971: Native Code Generator for 8.0.1 is not as optimized as 7.6.3... -------------------------------------+------------------------------------- Reporter: GordonBGood | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 8.0.1 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: | -------------------------------------+------------------------------------- Comment (by bgamari): To be clear, currently the improved LLVM backend plan is in need of someone to implement it. See #10074 for details. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 8 22:40:02 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Dec 2016 22:40:02 -0000 Subject: [GHC] #9696: readRawBufferPtr and writeRawBufferPtr allocate memory In-Reply-To: <052.b427ad2427779cbbeba69c4df93a91d2@haskell.org> References: <052.b427ad2427779cbbeba69c4df93a91d2@haskell.org> Message-ID: <067.fba5c22f50252df7ea0c4d1785196045@haskell.org> #9696: readRawBufferPtr and writeRawBufferPtr allocate memory -------------------------------------+------------------------------------- Reporter: mergeconflict | Owner: Type: bug | Status: patch Priority: low | Milestone: 8.2.1 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2813 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D2813 * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 8 22:45:26 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Dec 2016 22:45:26 -0000 Subject: [GHC] #12949: Pattern coverage mistake Message-ID: <045.3db1ccae2330725ee6ce9cf1d67c2922@haskell.org> #12949: Pattern coverage mistake -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I disabled syntax highlighting below; the bugs highlighting single quotes made the code unreadable. {{{ {-# LANGUAGE DataKinds, TypeFamilies, GADTs, TypeOperators, ScopedTypeVariables, ConstraintKinds, StandaloneDeriving #-} {-# OPTIONS_GHC -Wall #-} import Data.Constraint import Data.Type.Bool -- Bool singletons data Boolly b where Falsey :: Boolly 'False Truey :: Boolly 'True deriving instance Show (Boolly b) class KnownBool b where knownBool :: Boolly b instance KnownBool 'False where knownBool = Falsey instance KnownBool 'True where knownBool = Truey -- OrRel a b r expresses all the usual implications inherent -- in the statement that r ~ (a || b). type OrRel (a :: Bool) (b :: Bool) (r :: Bool) :: Constraint = (r ~ (a || b), If r (If (Not a) (b ~ 'True) (() :: Constraint), If (Not b) (a ~ 'True) (() :: Constraint)) (a ~ 'False, b ~ 'False)) -- Given known Bools, their disjunction is also known abr :: forall a b r p1 p2 . (OrRel a b r, KnownBool a, KnownBool b) => p1 a -> p2 b -> Dict (KnownBool r) abr _ _ = case knownBool :: Boolly a of Truey -> Dict Falsey -> case knownBool :: Boolly b of Truey -> Dict -- Problematic match Falsey -> Dict }}} The trouble is that GHC warns that the problematic match is redundant, which it is not. If I remove it, GHC ''fails'' to warn that the patterns are incomplete, which they are. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 8 22:49:10 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Dec 2016 22:49:10 -0000 Subject: [GHC] #12949: Pattern coverage mistake In-Reply-To: <045.3db1ccae2330725ee6ce9cf1d67c2922@haskell.org> References: <045.3db1ccae2330725ee6ce9cf1d67c2922@haskell.org> Message-ID: <060.6b30f9c8ad62eeba47ce7fa5a61e98d8@haskell.org> #12949: Pattern coverage mistake -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Note that everything works as expected if I pass in the `Boolly` values explicitly. Perhaps the pattern coverage checker is confusing `knownBool` called at different types? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 8 23:03:26 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Dec 2016 23:03:26 -0000 Subject: [GHC] #12945: Backpack signature matching doesn't pick up orphan instances In-Reply-To: <045.e76f05f03835a070e9df77510bd40649@haskell.org> References: <045.e76f05f03835a070e9df77510bd40649@haskell.org> Message-ID: <060.c51ac6ae57bf6c214231f6a52060719d@haskell.org> #12945: Backpack signature matching doesn't pick up orphan instances -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"62332f36b62431ddb9ab3c97365288c7d3fc2d39/ghc" 62332f3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="62332f36b62431ddb9ab3c97365288c7d3fc2d39" Setup tcg_imports earlier during signature matching, so orphans are visible. Summary: Previously, we updated tcg_imports after doing all of the actual matching, which was fine for outputting the interface, but not good enough for checking if all type classes were implemented; we weren't treating orphans as visible (when they needed to be.) Fixes #12945. Signed-off-by: Edward Z. Yang Test Plan: validate Reviewers: simonpj, austin, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2802 GHC Trac Issues: #12945 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 8 23:12:10 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Dec 2016 23:12:10 -0000 Subject: [GHC] #12945: Backpack signature matching doesn't pick up orphan instances In-Reply-To: <045.e76f05f03835a070e9df77510bd40649@haskell.org> References: <045.e76f05f03835a070e9df77510bd40649@haskell.org> Message-ID: <060.1d115a2f7b2c9d264a70787f074aab4a@haskell.org> #12945: Backpack signature matching doesn't pick up orphan instances -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: fixed | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 8 23:45:03 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Dec 2016 23:45:03 -0000 Subject: [GHC] #12388: Don't barf on failures in the RTS linker In-Reply-To: <047.b86bfd9a8524336c9591b8a2b9e093dd@haskell.org> References: <047.b86bfd9a8524336c9591b8a2b9e093dd@haskell.org> Message-ID: <062.a1652ae70ef6525f8270b58fa3e7143a@haskell.org> #12388: Don't barf on failures in the RTS linker -------------------------------------+------------------------------------- Reporter: dobenour | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2570 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"c766d53f3d8b58567b3bacf36fd7b6509656b1fc/ghc" c766d53/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c766d53f3d8b58567b3bacf36fd7b6509656b1fc" rts/linker: Fix LoadArchive build on Windows Test Plan: Validate on Windows. Reviewers: austin, erikd, simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2798 GHC Trac Issues: #12388 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 8 23:45:03 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Dec 2016 23:45:03 -0000 Subject: [GHC] #12871: Upgrade Mingw-w64 bindist for GHC to GCC 6.2.0 and Binutils 2.27.2 In-Reply-To: <044.3b0884ef0bcd4a4b9bcf5d4f10c21a66@haskell.org> References: <044.3b0884ef0bcd4a4b9bcf5d4f10c21a66@haskell.org> Message-ID: <059.1ae479646aa35e877b42471cf3d5c90a@haskell.org> #12871: Upgrade Mingw-w64 bindist for GHC to GCC 6.2.0 and Binutils 2.27.2 -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: task | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2749 Wiki Page: | Phab:D2810 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"1e5b7d701149dc20c9f92e722c32912c86d53081/ghc" 1e5b7d7/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1e5b7d701149dc20c9f92e722c32912c86d53081" Update Windows GCC driver. Test Plan: None really, as none of our tests cover this usage. Probably should add one.. Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D2810 GHC Trac Issues: #12871 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 8 23:45:03 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Dec 2016 23:45:03 -0000 Subject: [GHC] #10249: GHCi leaky abstraction: error message mentions `ghciStepIO` In-Reply-To: <051.818ff8bc84030bedfa7f9663d4a7c3ef@haskell.org> References: <051.818ff8bc84030bedfa7f9663d4a7c3ef@haskell.org> Message-ID: <066.9c2a19a7bd5fa04268a9be933a5dcbd6@haskell.org> #10249: GHCi leaky abstraction: error message mentions `ghciStepIO` -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: thomie Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: GHCi | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | ghci/scripts/T10249 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1527, Wiki Page: | Phab:D1528 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"6889400bd5ce6b481844fe5cfa7c9256ff5cd52f/ghc" 6889400/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6889400bd5ce6b481844fe5cfa7c9256ff5cd52f" testsuite: Add test for #10249 Test Plan: Validate Reviewers: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2794 GHC Trac Issues: #10249 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 8 23:45:03 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Dec 2016 23:45:03 -0000 Subject: [GHC] #9577: String literals are wasting space In-Reply-To: <045.ae4d47715fdd8321ed459b0edd946522@haskell.org> References: <045.ae4d47715fdd8321ed459b0edd946522@haskell.org> Message-ID: <060.6531479298645e6be3c57724fe7a4b2e@haskell.org> #9577: String literals are wasting space -------------------------------------+------------------------------------- Reporter: xnyhps | Owner: xnyhps Type: bug | Status: closed Priority: low | Milestone: 8.2.1 Component: Compiler (NCG) | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | codeGen/should_run/T9577 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1290 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"55361b381d14d8752f00d90868fcbe82f86c6b2d/ghc" 55361b38/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="55361b381d14d8752f00d90868fcbe82f86c6b2d" nativeGen: Fix string merging on Windows D1290 places string constants in the `.rodata.str` section with `aMS` section flags so that the linker can merge them. However, it seems that ld doesn't understand these flags. It appears that `gcc -fmerge-constants` uses the `dr` flags on Windows. Make GHC do the same. Test Plan: Validate on Windows Reviewers: xnyhps, austin, Phyx Reviewed By: Phyx Subscribers: thomie, trommler Differential Revision: https://phabricator.haskell.org/D2797 GHC Trac Issues: #9577 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 9 00:21:45 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Dec 2016 00:21:45 -0000 Subject: [GHC] #12950: unnecessarily complicated left-hand side causing RULE left-hand side too complicated to desugar Message-ID: <046.22b3b53414e7ce2af2682aabd50cd43c@haskell.org> #12950: unnecessarily complicated left-hand side causing RULE left-hand side too complicated to desugar -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: #10555,#12074 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC 7.10.2 rejects the `SPECIALIZE` pragma in the following snippet with "RULE left-hand side too complicated to desugar". {{{#!hs class C a where type TF a; m :: a -> TF a instance C Int where type TF Int = String; m = show overloaded :: C a => a -> (a,TF a) {-# INLINABLE overloaded #-} overloaded a = (a,m a) {-# SPECIALIZE overloaded :: Int -> (Int,TF Int) #-} }}} This use case is so simple/basic/prevalent that it seems inappropriate to reject it. The actual message is {{{ RULE left-hand side too complicated to desugar Optimised lhs: case cobox_awc of _ [Occ=Dead] { GHC.Types.Eq# cobox -> overloaded @ Int $dC_awb } Orig lhs: case cobox_awc of cobox_awc { GHC.Types.Eq# cobox -> overloaded @ Int $dC_awb } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 9 00:22:45 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Dec 2016 00:22:45 -0000 Subject: [GHC] #12951: Remove __USE_MINGW_ANSI_STDIO define from PosixSource.h Message-ID: <046.6a7aeb23ea1b9a4487131aaecfa8bac9@haskell.org> #12951: Remove __USE_MINGW_ANSI_STDIO define from PosixSource.h -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This was a stop-gap measure to allow users to build GHC 8.2 with 7.10.1 and 7.10.2. It can be removed for 8.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 9 00:23:41 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Dec 2016 00:23:41 -0000 Subject: [GHC] #12951: Remove __USE_MINGW_ANSI_STDIO define from PosixSource.h In-Reply-To: <046.6a7aeb23ea1b9a4487131aaecfa8bac9@haskell.org> References: <046.6a7aeb23ea1b9a4487131aaecfa8bac9@haskell.org> Message-ID: <061.d89166dcb1b41a60f9dbf23ff4c71530@haskell.org> #12951: Remove __USE_MINGW_ANSI_STDIO define from PosixSource.h -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2812 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * differential: => Phab:D2812 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 9 00:29:42 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Dec 2016 00:29:42 -0000 Subject: [GHC] #12950: unnecessarily complicated left-hand side causing RULE left-hand side too complicated to desugar In-Reply-To: <046.22b3b53414e7ce2af2682aabd50cd43c@haskell.org> References: <046.22b3b53414e7ce2af2682aabd50cd43c@haskell.org> Message-ID: <061.12413f1f15c4e2450752e3dcb931cd36@haskell.org> #12950: unnecessarily complicated left-hand side causing RULE left-hand side too complicated to desugar -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | 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: #10555,#12074 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nfrisby): I'm unfamiliar with the implementation of the type-checker. Even so, I flipped on `-ddump-tc-trace` to investigate where that troublesome coercion was coming from. I noticed the following subsequence of trace messages. {{{ tcSubTypeDS_NC the type signature for ‘overloaded’ a_awb[tau:1] -> (a_awb[tau:1], TF a_awb[tau:1]) Int -> (Int, TF Int) *snip* writeMetaTyVar a_awb[tau:1] := Int *snip* utype_defer cobox_awd TF a_awb[tau:1] TF Int arising from a type equality a_awb[tau:1] -> (a_awb[tau:1], TF a_awb[tau:1]) ~ Int -> (Int, TF Int) *snip* u_tys yields coercion: cobox_awd }}} This indicates that `cobox_awd` is the result of the unifier deferring the question of whether `TF a_awb ~ TF Int`, even though `a_awd` was already set to `Int`. Digging a bit deeper, I see that `TcUnify.uType` contains [https://github.com/ghc/ghc/blob/086b4836c4b279d5ae0e330719e1a679dd16392e/compiler/typecheck/TcUnify.hs#L1286-L1291 the following matches], which ultimately incur the coercion that sinks the SPECIALISE pragma since they do not check if the types' already solved tyvars admit reflexivity as a proof here. {{{#!hs -- Always defer if a type synonym family (type function) -- is involved. (Data families behave rigidly.) go ty1@(TyConApp tc1 _) ty2 | isTypeFamilyTyCon tc1 = uType_defer origin ty1 ty2 go ty1 ty2@(TyConApp tc2 _) | isTypeFamilyTyCon tc2 = uType_defer origin ty1 ty2 }}} I anticipate that a possible "fix" for this ticket would be for the `go` function to check if the solved type variables render `ty1` and `ty2` equivalent such that `TcRefl` would suffice here. Or perhaps there's somewhere more appropriate (`dsSpec`?) to perform that "optimization" for the sake of accepting SPECIALIZE pragmas like this one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 9 00:33:48 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Dec 2016 00:33:48 -0000 Subject: [GHC] #12950: unnecessarily complicated left-hand side causing RULE left-hand side too complicated to desugar In-Reply-To: <046.22b3b53414e7ce2af2682aabd50cd43c@haskell.org> References: <046.22b3b53414e7ce2af2682aabd50cd43c@haskell.org> Message-ID: <061.d4ca0b5e0255f8d705a68c3a4dc64d39@haskell.org> #12950: unnecessarily complicated left-hand side causing RULE left-hand side too complicated to desugar -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | 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: | Differential Rev(s): #10555,#12074,#12649 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by nfrisby): * related: #10555,#12074 => #10555,#12074,#12649 Comment: The proposal in #12649 might involve an "alternate" code path in the type- checker that side-steps this issue: if a SPECIALIZE pragma could be declared more directly ("set `a` to `Int`"), then `decomposeRuleLhs` (the function that emits "RULE left-hand side too complicated to desugar") might not even be necessary. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 9 00:35:02 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Dec 2016 00:35:02 -0000 Subject: [GHC] #12950: Unnecessarily complicated left-hand side for SPECIALIZE pragma causing RULE left-hand side too complicated to desugar (was: unnecessarily complicated left-hand side causing RULE left-hand side too complicated to desugar) In-Reply-To: <046.22b3b53414e7ce2af2682aabd50cd43c@haskell.org> References: <046.22b3b53414e7ce2af2682aabd50cd43c@haskell.org> Message-ID: <061.2bf70c96c5290ba9d317c4d59b2fb03b@haskell.org> #12950: Unnecessarily complicated left-hand side for SPECIALIZE pragma causing RULE left-hand side too complicated to desugar -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | 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: | Differential Rev(s): #10555,#12074,#12649 | Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 9 01:01:24 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Dec 2016 01:01:24 -0000 Subject: [GHC] #12952: Broken tests: ghci014 maessen_hashtab qq006 Message-ID: <049.947a2dec0a1cc0063fc980a213642347@haskell.org> #12952: Broken tests: ghci014 maessen_hashtab qq006 -------------------------------------+------------------------------------- Reporter: Rufflewind | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: ghci014 | Blocked By: maessen_hashtab qq006 | Blocking: | Related Tickets: Differential Rev(s): D2807 | Wiki Page: -------------------------------------+------------------------------------- {{{ ghci/scripts/ghci014.run ghci014 [bad stderr] (ghci) programs/maessen-hashtab/maessen_hashtab.run maessen_hashtab [exit code non-0] (hpc) quasiquotation/qq006/qq006.run qq006 [exit code 0] (normal) }}} The first two were fairly straightforward: `ghci014` and `maessen_hashtab` are broken because they rely on a very ancient version of QuickCheck. I don't know what is up with `qq006`. It doesn't compile on GHC 8.0.1 but now apparently it does on GHC HEAD. Is this a bug or a change in semantics? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 9 01:56:17 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Dec 2016 01:56:17 -0000 Subject: [GHC] #12950: Unnecessarily complicated left-hand side for SPECIALIZE pragma causing RULE left-hand side too complicated to desugar In-Reply-To: <046.22b3b53414e7ce2af2682aabd50cd43c@haskell.org> References: <046.22b3b53414e7ce2af2682aabd50cd43c@haskell.org> Message-ID: <061.8e695eb58f42a498a45187911d7ca3b1@haskell.org> #12950: Unnecessarily complicated left-hand side for SPECIALIZE pragma causing RULE left-hand side too complicated to desugar -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: worksforme | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): #10555,#12074,#12649 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by nfrisby): * status: new => closed * resolution: => worksforme Comment: Closing this ticket -- the SPECIALIZE pragma is accepted and works as expected in in GHC 8.0.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 9 02:12:08 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Dec 2016 02:12:08 -0000 Subject: [GHC] #12953: Use computed gotos in the interpreter when the compiler supports it Message-ID: <047.553281fe81ba5e2200adafd7df4ff001@haskell.org> #12953: Use computed gotos in the interpreter when the compiler supports it -------------------------------------+------------------------------------- Reporter: dobenour | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.0.1 System | Keywords: interpreter | 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: -------------------------------------+------------------------------------- We can use computed gotos to speed up the interpreter on systems that support them. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 9 02:12:45 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Dec 2016 02:12:45 -0000 Subject: [GHC] #12953: Use computed gotos in the interpreter when the compiler supports it In-Reply-To: <047.553281fe81ba5e2200adafd7df4ff001@haskell.org> References: <047.553281fe81ba5e2200adafd7df4ff001@haskell.org> Message-ID: <062.9ec5c440743a75070bb5afaa5019b6c2@haskell.org> #12953: Use computed gotos in the interpreter when the compiler supports it -------------------------------------+------------------------------------- Reporter: dobenour | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: interpreter 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 dobenour): * type: bug => feature request -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 9 02:27:06 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Dec 2016 02:27:06 -0000 Subject: [GHC] #12954: unexpected uncaught segmentation error in arbitrary precision Integer calculations with modestly large numbers Message-ID: <046.4a50f65ae4b117a9a39023c6be40e710@haskell.org> #12954: unexpected uncaught segmentation error in arbitrary precision Integer calculations with modestly large numbers --------------------------------------+---------------------------------- Reporter: geraint | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+---------------------------------- In ghci 8.0.1 on my mac, expressions no bigger than {{{2^(10^7) :: Integer}}} usually cause a bus error; {{{2^(10^6)}}} is apparently OK. The force of "usually" is that every now and then they and larger expressions are fine, so it is not quite reproducible. I believe it's the Integer arithmetic library, rather than the exponentiation, and I think it might be a stack overflow in libHSinteger- gmp-1.0.0.1-ghc8.0.1.dylib The problem was first encountered with compiled code doing additions and multiplications on similarly sized Integer values. Substantially larger numbers can be handled by 7.8.4 on other platforms, which is all I have to compare it with. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 9 03:01:16 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Dec 2016 03:01:16 -0000 Subject: [GHC] #12955: Confusing error (module is not loaded) when more hsigs provided than -instantiated-with Message-ID: <045.af0dbd7cccb0e75a1e56a8bbe94489fa@haskell.org> #12955: Confusing error (module is not loaded) when more hsigs provided than -instantiated-with -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Keywords: backpack | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Steps to reproduce: 1. Create an `A.hsig` file with `signature A where` 2. Try to build it with `ghc --make A.hsig` Expected: Some error indicating an unexpected signature (you need to specify `-instantiated-with` Actual: This error: {{{ [1 of 1] Compiling A[sig] (.hsig -> .o) attempting to use module ‘main:A’ (A.hsig) which is not loaded }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 9 04:06:13 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Dec 2016 04:06:13 -0000 Subject: [GHC] #12951: Remove __USE_MINGW_ANSI_STDIO define from PosixSource.h In-Reply-To: <046.6a7aeb23ea1b9a4487131aaecfa8bac9@haskell.org> References: <046.6a7aeb23ea1b9a4487131aaecfa8bac9@haskell.org> Message-ID: <061.ede82600ab2c51493d72bfe950c83586@haskell.org> #12951: Remove __USE_MINGW_ANSI_STDIO define from PosixSource.h -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2812 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"6da62535469149d69ec98674db1c51dbde0efab1/ghc" 6da62535/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6da62535469149d69ec98674db1c51dbde0efab1" rts/PosixSource.h: Define __USE_MINGW_ANSI_STDIO on Windows This was removed in 8dc72f3c33b0e724ddb690c9d494969980c10afd which cleaned up PosixSource.h. Strangely, this only started breaking for me now. Test Plan: Validate on Windows Reviewers: simonmar, erikd, austin, Phyx Reviewed By: Phyx Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2812 GHC Trac Issues: #12951 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 9 04:15:44 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Dec 2016 04:15:44 -0000 Subject: [GHC] #12726: GHC 8.0.1: ghc --make broken on Raspberry Pi In-Reply-To: <046.2bab883d5f72d72c6b621360247206d3@haskell.org> References: <046.2bab883d5f72d72c6b621360247206d3@haskell.org> Message-ID: <061.bc036bd7199b41bbd6ed6e580253ded3@haskell.org> #12726: GHC 8.0.1: ghc --make broken on Raspberry Pi -------------------------------------+------------------------------------- Reporter: robjhen | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: worksforme | Keywords: raspberry pi Operating System: Linux | Architecture: arm Type of failure: GHC doesn't work | Test Case: at all | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by siddhanathan): * status: new => closed * resolution: => worksforme Comment: Closing as per brent80's comment. Tested on Raspberry Pi 2. Please reopen if this was in error. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 9 04:43:53 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Dec 2016 04:43:53 -0000 Subject: [GHC] #8971: Native Code Generator for 8.0.1 is not as optimized as 7.6.3... In-Reply-To: <050.c7fda5d49ea9b3871e29284bd1fa2f5f@haskell.org> References: <050.c7fda5d49ea9b3871e29284bd1fa2f5f@haskell.org> Message-ID: <065.481cd0c52b845748d77babfd125fd137@haskell.org> #8971: Native Code Generator for 8.0.1 is not as optimized as 7.6.3... -------------------------------------+------------------------------------- Reporter: GordonBGood | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 8.0.1 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: | -------------------------------------+------------------------------------- Comment (by GordonBGood): Replying to [comment:32 bgamari]: > To be clear, currently the improved LLVM backend plan is in need of someone to implement it. See #10074 for details. That's a pity, but not a problem as long as the version of LLVM that the version of GHC requires (opt and llc from LLVM) are readily available and the patches for the underlying system support (Mingw binutils in the case of Windows, especially patched for Windows 64 to make them work with LLVM on Windows) are also readily available. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 9 05:31:17 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Dec 2016 05:31:17 -0000 Subject: [GHC] #9504: LLVM backend TBAA is too aggressive In-Reply-To: <047.895b450af37d81fdca37d7d76677e0ee@haskell.org> References: <047.895b450af37d81fdca37d7d76677e0ee@haskell.org> Message-ID: <062.c1e9c39505911eeb39f3e8dd01d7248d@haskell.org> #9504: LLVM backend TBAA is too aggressive -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: 9308 Related Tickets: | Differential Rev(s): D2758 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dobenour): * differential: => D2758 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 9 05:31:40 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Dec 2016 05:31:40 -0000 Subject: [GHC] #9504: LLVM backend TBAA is too aggressive In-Reply-To: <047.895b450af37d81fdca37d7d76677e0ee@haskell.org> References: <047.895b450af37d81fdca37d7d76677e0ee@haskell.org> Message-ID: <062.4d3637aecb9605bc32f7b8aeeed2211e@haskell.org> #9504: LLVM backend TBAA is too aggressive -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: 9308 Related Tickets: | Differential Rev(s): Diff: 2758 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dobenour): * differential: D2758 => Diff: 2758 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 9 05:33:46 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Dec 2016 05:33:46 -0000 Subject: [GHC] #9504: LLVM backend TBAA is too aggressive In-Reply-To: <047.895b450af37d81fdca37d7d76677e0ee@haskell.org> References: <047.895b450af37d81fdca37d7d76677e0ee@haskell.org> Message-ID: <062.aa3d10e7696e0a484c3cd1f37caf8f02@haskell.org> #9504: LLVM backend TBAA is too aggressive -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: 9308 Related Tickets: | Differential Rev(s): Phab:2758 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dobenour): * differential: Diff: 2758 => Phab:2758 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 9 05:33:59 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Dec 2016 05:33:59 -0000 Subject: [GHC] #9504: LLVM backend TBAA is too aggressive In-Reply-To: <047.895b450af37d81fdca37d7d76677e0ee@haskell.org> References: <047.895b450af37d81fdca37d7d76677e0ee@haskell.org> Message-ID: <062.4c396717fbe00c11df63789d3edfa6d2@haskell.org> #9504: LLVM backend TBAA is too aggressive -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: 9308 Related Tickets: | Differential Rev(s): Phab:2758 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dobenour): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 9 05:34:21 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Dec 2016 05:34:21 -0000 Subject: [GHC] #9504: LLVM backend TBAA is too aggressive In-Reply-To: <047.895b450af37d81fdca37d7d76677e0ee@haskell.org> References: <047.895b450af37d81fdca37d7d76677e0ee@haskell.org> Message-ID: <062.091bcddd9dabb6cf6d2a0415e7624484@haskell.org> #9504: LLVM backend TBAA is too aggressive -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: 9308 Related Tickets: | Differential Rev(s): Phab:D2758 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dobenour): * differential: Phab:2758 => Phab:D2758 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 9 05:35:05 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Dec 2016 05:35:05 -0000 Subject: [GHC] #9308: nofib fannkuch-redux runs perpetually with -fllvm In-Reply-To: <042.547b78253c22f834191c24f2af1b28cf@haskell.org> References: <042.547b78253c22f834191c24f2af1b28cf@haskell.org> Message-ID: <057.9e51920a3352be5705516fae0e3394fb@haskell.org> #9308: nofib fannkuch-redux runs perpetually with -fllvm -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 7.8.3 Resolution: | Keywords: fannkuch- | redux Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: fannkuch- at runtime | redux Blocked By: 9504 | Blocking: Related Tickets: #5567 | Differential Rev(s): Phab:D2758 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dobenour): * status: new => patch * differential: => Phab:D2758 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 9 06:37:26 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Dec 2016 06:37:26 -0000 Subject: [GHC] #12942: Add infix flag for class and data declarations In-Reply-To: <044.ad2a88252aaa49d53b0869c522534f50@haskell.org> References: <044.ad2a88252aaa49d53b0869c522534f50@haskell.org> Message-ID: <059.c7218574be32771d6a11e28939c8d186@haskell.org> #12942: Add infix flag for class and data declarations -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #3384 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alanz): And I just realised the issue statement is wrong, the constraints are on the `Outputable` instances for the AST, not the AST itself. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 9 09:38:16 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Dec 2016 09:38:16 -0000 Subject: [GHC] #12808: For non-strict code including primitive (Addr#) code, Loop Invariant Code Flow not lifted outside the loop... (was: For primitive (Addr#) operations, Loop Invariant Code Flow not lifted outside the loop...) In-Reply-To: <050.4b8817bb90d50f291df9e28cde0cf9f5@haskell.org> References: <050.4b8817bb90d50f291df9e28cde0cf9f5@haskell.org> Message-ID: <065.6bb53f506caf15bf6235d7bcefd3946d@haskell.org> #12808: For non-strict code including primitive (Addr#) code, Loop Invariant Code Flow not lifted outside the loop... -------------------------------------+------------------------------------- Reporter: GordonBGood | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 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: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 9 10:44:25 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Dec 2016 10:44:25 -0000 Subject: [GHC] #11511: Type family producing infinite type accepted as injective In-Reply-To: <048.97d84dbb372812585cd3199cfa06814f@haskell.org> References: <048.97d84dbb372812585cd3199cfa06814f@haskell.org> Message-ID: <063.2bc09c6c0bdfdb84161c41d48fa5b158@haskell.org> #11511: Type family producing infinite type accepted as injective -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Keywords: TypeFamilies, Resolution: | Injective Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jstolarek): I had a talk about injective type families yesterday and it provoked me to rethink this issue. What we do in the pre-unification algorithm is: 1. assume that type family applications unify with anything 2. but we look under injective type family applications and unify the arguments Now, my question is: when we are checking whether `F` is injective why do we assume that `F`'s injectivity annotation is true? This is what we're trying to prove and I think we should not assume that as part of our proof. This is exactly what's happening here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 9 11:23:57 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Dec 2016 11:23:57 -0000 Subject: [GHC] #12808: For non-strict code including primitive (Addr#) code, Loop Invariant Code Flow not lifted outside the loop... In-Reply-To: <050.4b8817bb90d50f291df9e28cde0cf9f5@haskell.org> References: <050.4b8817bb90d50f291df9e28cde0cf9f5@haskell.org> Message-ID: <065.8a8f1e28a6b9e43123a6da2939c14cf2@haskell.org> #12808: For non-strict code including primitive (Addr#) code, Loop Invariant Code Flow not lifted outside the loop... -------------------------------------+------------------------------------- Reporter: GordonBGood | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 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: | -------------------------------------+------------------------------------- Comment (by GordonBGood): It seems that the loop invariant code flow not being lifted out of the loops in not limited to primitive operations (also including Addr#), but is a general case for any code that is not purely strict, thus anything involving boxed thunks does not seem to be optimized properly. The following code of a simple naive Sieve of Eratosthenes implementation with the composite number culling operations run a number of times in a loop for better timing purposes demonstrates the problem: {{{ {-# LANGUAGE FlexibleContexts, BangPatterns, MagicHash, UnboxedTuples #-} {-# OPTIONS_GHC -O3 -rtsopts -keep-s-files -ddump-stg -ddump-cmm -ddump- opt-cmm -ddump-to-file -dumpdir . #-} -- or -O2 -fllvm -v -dcore-lint -ddump-asm import Data.Word import Data.Bits import Data.Array.ST (runSTUArray) import Data.Array.Base import GHC.ST ( ST(..) ) twos = listArray (0, 31) [ 1 `shiftL` i | i <- [0 .. 31]] :: UArray Int Word32 eos :: Int -> [Int] eos top = [fromIntegral i | (i, False) <- assocs cmpsts] where cmpsts = runSTUArray $ do cmpstsb <- newArray (0, top) False :: ST s (STUArray s Int Bool) cmpstsw <- (castSTUArray :: STUArray s Int Bool -> ST s (STUArray s Int Word32)) cmpstsb unsafeWrite cmpstsw 0 3 -- precull 0 and 1 let loop i = if i <= 0 then return cmpstsb else let nxtp p = let s = p * p in if s > top then loop (i - 1) else do v <- unsafeRead cmpstsw (p `shiftR` 5) if v .&. unsafeAt twos (p .&. 31) /= 0 then nxtp (p + 1) else let nxtc c = if c > top then return () else do let w = c `shiftR` 5 v <- unsafeRead cmpstsw w unsafeWrite cmpstsw w (v .|. unsafeAt twos (c .&. 31)) nxtc (c + p) in do { nxtc s; nxtp (p + 1) } in twos `seq` nxtp 2 loop (10000 :: Int) main = print $ length $ eos(131071) }}} When run with the -fllvm (LLVM back end) compiler flag, it produces the following STG code for the inner loop (located by searching for "nxtc", massively indented for display): {{{ let { $wnxtc_s7Ru [InlPrag=[0], Occ=LoopBreaker] :: GHC.Prim.Int# -> GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, () #) [LclId, Arity=2, Str=DmdType , Unf=OtherCon []] = sat-only \r srt:SRT:[] [ww1_s7Rv w1_s7Rw] case ># [ww1_s7Rv 131071#] of sat_s7Rx { __DEFAULT -> case tagToEnum# [sat_s7Rx] of _ [Occ=Dead] { GHC.Types.False -> case uncheckedIShiftRA# [ww1_s7Rv 5#] of i#_s7Rz [Dmd=] { __DEFAULT -> case readWord32Array# [ipv1_s7R1 i#_s7Rz w1_s7Rw] of _ [Occ=Dead] { (#,#) ipv8_s7RB [Occ=Once] ipv9_s7RC [Occ=Once] -> case andI# [ww1_s7Rv 31#] of sat_s7RD { __DEFAULT -> case indexWord32Array# [ipv5_s7Rf sat_s7RD] of wild5_s7RE { __DEFAULT -> case or# [ipv9_s7RC wild5_s7RE] of sat_s7RF { __DEFAULT -> case writeWord32Array# [ipv1_s7R1 i#_s7Rz sat_s7RF ipv8_s7RB] of s2#1_s7RG [OS=OneShot] { __DEFAULT -> case +# [ww1_s7Rv ww_s7Rh] of sat_s7RH { __DEFAULT -> $wnxtc_s7Ru sat_s7RH s2#1_s7RG; }; }; }; }; }; }; }; GHC.Types.True -> (#,#) [w1_s7Rw GHC.Tuple.()]; }; }; } in }}} This, in turn produces the following CMM code: {{{ c8oB: _s7R1::P64 = P64[_s7Ru::P64 + 6]; _s7Rf::P64 = P64[_s7Ru::P64 + 14]; _s7Rh::I64 = I64[_s7Ru::P64 + 22]; _c8oE::I64 = %MO_S_Gt_W64(_s7Rv::I64, 131071); _s7Rx::I64 = _c8oE::I64; switch [0 .. 1] _s7Rx::I64 { case 0 : goto c8oM; case 1 : goto c8oN; } c8oN: R1 = GHC.Tuple.()_closure+1; call (P64[(old + 8)])(R1) args: 8, res: 0, upd: 8; c8oM: _c8oP::I64 = %MO_S_Shr_W64(_s7Rv::I64, 5); _s7Rz::I64 = _c8oP::I64; _s7RC::I64 = %MO_UU_Conv_W32_W64(I32[(_s7R1::P64 + 16) + (_s7Rz::I64 << 2)]); _s7RC::I64 = _s7RC::I64; _c8oS::I64 = _s7Rv::I64 & 31; _s7RD::I64 = _c8oS::I64; _c8oV::I64 = %MO_UU_Conv_W32_W64(I32[(_s7Rf::P64 + 16) + (_s7RD::I64 << 2)]); _s7RE::I64 = _c8oV::I64; _c8oY::I64 = _s7RC::I64 | _s7RE::I64; _s7RF::I64 = _c8oY::I64; I32[(_s7R1::P64 + 16) + (_s7Rz::I64 << 2)] = %MO_UU_Conv_W64_W32(_s7RF::I64); _c8p3::I64 = _s7Rv::I64 + _s7Rh::I64; _s7RH::I64 = _c8p3::I64; _s7Rv::I64 = _s7RH::I64; goto c8oB; }}} which is reduced to the following CMM code after many optimization passes: {{{ c8oB: switch [0 .. 1] (%MO_S_Gt_W64(_s7Rv::I64, 131071)) { case 0 : goto c8oM; case 1 : goto c8oN; } c8oN: R1 = GHC.Tuple.()_closure+1; call (P64[Sp])(R1) args: 8, res: 0, upd: 8; c8oM: _s7R1::P64 = P64[_s7Ru::P64 + 6]; _s7Rh::I64 = I64[_s7Ru::P64 + 22]; _s7Rz::I64 = %MO_S_Shr_W64(_s7Rv::I64, 5); I32[(_s7R1::P64 + 16) + (_s7Rz::I64 << 2)] = %MO_UU_Conv_W64_W32(%MO_UU_Conv_W32_W64(I32[(_s7R1::P64 + 16) + (_s7Rz::I64 << 2)]) | %MO_UU_Conv_W32_W64(I32[P64[_s7Ru::P64 + 14] + ((_s7Rv::I64 & 31 << 2) + 16)])); _s7Rv::I64 = _s7Rv::I64 + _s7Rh::I64; goto c8oB; }}} and finally the following assembly code: {{{ .align 16, 0x90 .LBB29_1: # %c8oM # =>This Inner Loop Header: Depth=1 movq %r14, %rax sarq $5, %rax movq 6(%rbx), %rcx movq 14(%rbx), %rdx movl %r14d, %esi andl $31, %esi movl 16(%rdx,%rsi,4), %edx addq 22(%rbx), %r14 orl %edx, 16(%rcx,%rax,4) cmpq $131072, %r14 # imm = 0x20000 jl .LBB29_1 }}} where one can clearly see the multiple register loads inside the inner loop. This code runs at almost four CPU clock cycles per loop on Intel Skylake. It is easy to see that this code is partially non-strict by running the `+RTS -s` command line option on the run to observed that heap use is much higher than it should be, although not so high that it causes a significant amount of GC or cost in execution time. The extra execution time is almost entirely due to the register reloads seen above inside the inner loop. '''The Work Around''' By merely changing the inner loop as follows, the non-strictness goes away (as seen in the amount of heap used, which drops to a few 10's of Kilobytes from 10's of Megabytes: {{{ let nxtc c = if c > top then nxtp (p + 1) else do let w = c `shiftR` 5 v <- unsafeRead cmpstsw w unsafeWrite cmpstsw w (v .|. unsafeAt twos (c .&. 31)) nxtc (c + p) in nxtc s in twos `seq` nxtp 2 }}} With the modified code producing the following STG (massively indented for display here): {{{ lvl21_s7Rl [Dmd=] { __DEFAULT -> let-no-escape { $wnxtc_s7Rm [InlPrag=[0], Occ=LoopBreaker] :: GHC.Prim.Int# -> GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, Data.Array.Base.STUArray GHC.Prim.RealWorld GHC.Types.Int GHC.Types.Bool #) [LclId, Arity=2, Str=DmdType , Unf=OtherCon []] = sat-only \r srt:SRT:[] [ww3_s7Rn w3_s7Ro] case ># [ww3_s7Rn 131071#] of sat_s7Rp { __DEFAULT -> case tagToEnum# [sat_s7Rp] of _ [Occ=Dead] { GHC.Types.False -> case uncheckedIShiftRA# [ww3_s7Rn 5#] of i#_s7Rr [Dmd=] { __DEFAULT -> case readWord32Array# [ipv1_s7Qj i#_s7Rr w3_s7Ro] of _ [Occ=Dead] { (#,#) ipv8_s7Rt [Occ=Once] ipv9_s7Ru [Occ=Once] -> case andI# [ww3_s7Rn 31#] of sat_s7Rv { __DEFAULT -> case indexWord32Array# [ipv5_s7Qx sat_s7Rv] of wild7_s7Rw { __DEFAULT -> case or# [ipv9_s7Ru wild7_s7Rw] of sat_s7Rx { __DEFAULT -> case writeWord32Array# [ipv1_s7Qj i#_s7Rr sat_s7Rx ipv8_s7Rt] of s2#1_s7Ry [OS=OneShot] { __DEFAULT -> case +# [ww3_s7Rn ww2_s7R8] of sat_s7Rz { __DEFAULT -> $wnxtc_s7Rm sat_s7Rz s2#1_s7Ry; }; }; }; }; }; }; }; GHC.Types.True -> $wnxtp1_s7R7 lvl21_s7Rl w3_s7Ro; }; }; } in $wnxtc_s7Rm x1_s7Ra ipv6_s7Rf; }; }; }}} converted to the following initial CMM code: {{{ c8o0: switch [0 .. 1] (%MO_S_Gt_W64(_s7QO::I64, 131071)) { case 0 : goto c8o8; case 1 : goto c8o9; } c8o9: _s7Qz::I64 = _s7QM::I64; goto c8ni; c8o8: _s7QS::I64 = %MO_S_Shr_W64(_s7QO::I64, 5); I32[(_s7Qj::P64 + 16) + (_s7QS::I64 << 2)] = %MO_UU_Conv_W64_W32(%MO_UU_Conv_W32_W64(I32[(_s7Qj::P64 + 16) + (_s7QS::I64 << 2)]) | %MO_UU_Conv_W32_W64(I32[(_s7Qx::P64 + 16) + (_s7QO::I64 & 31 << 2)])); _s7QO::I64 = _s7QO::I64 + _s7Qz::I64; goto c8o0; }}} and the following optimized CMM code: {{{ c8p9: switch [0 .. 1] (%MO_S_Gt_W64(_s7Rn::I64, 131071)) { case 0 : goto c8ph; case 1 : goto c8pi; } c8pi: _s7R8::I64 = _s7Rl::I64; goto c8ou; c8ph: _s7Rr::I64 = %MO_S_Shr_W64(_s7Rn::I64, 5); I32[(_s7Qj::P64 + 16) + (_s7Rr::I64 << 2)] = %MO_UU_Conv_W64_W32(%MO_UU_Conv_W32_W64(I32[(_s7Qj::P64 + 16) + (_s7Rr::I64 << 2)]) | %MO_UU_Conv_W32_W64(I32[(_s7Qx::P64 + 16) + (_s7Rn::I64 & 31 << 2)])); _s7Rn::I64 = _s7Rn::I64 + _s7R8::I64; goto c8p9; }}} to produce the following almost ideal assembly code (this particular code doesn't seem to manifest the symptoms of ticket #12798): {{{ .LBB29_10: # %c8ph # Parent Loop BB29_7 Depth=1 # Parent Loop BB29_8 Depth=2 # => This Inner Loop Header: Depth=3 movq %rsi, %rdx sarq $5, %rdx movl %esi, %edi andl $31, %edi movl 16(%rcx,%rdi,4), %edi orl %edi, 16(%r10,%rdx,4) addq %rax, %rsi cmpq $131071, %rsi # imm = 0x1FFFF jle .LBB29_10 }}} which one can see has no register loads and is almost ideal as to speed for the purpose - it runs at about 3.09 CPU clock cycles per loop whereas I have seen some code slightly re-ordered as produced by Clang/Rust/LLVM that runs at about 3.00 clock cycles. In order to fix the previous code using primitive Addr# operations for which the ticket was opened, one just has to convince the compiler that it is to be evaluated strictly; although this is not so easy or one runs into the mixed lifted and un-lifted types error message. However, there is likely a whole wide range of programs where executing entirely strictly is either not possible or not desired. I don't see why non-strict boxed code (for Haskell, likely the majority of code) can not be just as effectively optimized. '''In conclusion:''' this is a very serious performance bug that can cause up to about a half again cost in execution time (50% increase), occurs in many use cases with a typical performance cost of about 30% (for instance for highly recursive code using list basted tail calls), and I believe has a great deal to do with the general perception that (GHC) Haskell is very much slower than Cee languages (C/C++/Rust, etc.). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 9 11:30:42 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Dec 2016 11:30:42 -0000 Subject: [GHC] #12808: For non-strict code including primitive (Addr#) code, Loop Invariant Code Flow not lifted outside the loop... In-Reply-To: <050.4b8817bb90d50f291df9e28cde0cf9f5@haskell.org> References: <050.4b8817bb90d50f291df9e28cde0cf9f5@haskell.org> Message-ID: <065.432690cc7bff270750e411fd5655cef4@haskell.org> #12808: For non-strict code including primitive (Addr#) code, Loop Invariant Code Flow not lifted outside the loop... -------------------------------------+------------------------------------- Reporter: GordonBGood | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 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: | -------------------------------------+------------------------------------- Description changed by GordonBGood: @@ -12,11 +12,15 @@ - '''Description of test code:''' Essentially, this method involves - extreme loop unrolling with very imperative code although coded - functionally; in the case of the following code it means that, recognizing - that for all odd primes (which they all are other than two), and that all - word sizes are of an even number of bits, there will be a repeating - pattern of composite number culls that repeats every word size number of - bits. Thus for a word size of one eight-bit byte, we can unroll to eight - composite culls in the body of one loop, with loops cases for the primes - modulo 8 of 1, 3, 5, and 7, and for the eight bit start positions (b0..b7) - meaning there are four times eight is 32 loop cases. When there are no - longer a full eight culls left, the culling reverts to conventional + '''Shortest possible test code that clearly shows non-strict code not + being optimized, but optimized when made strict:''' Please refer directly + to comment 12https://ghc.haskell.org/trac/ghc/ticket/12808#comment:12, + + '''A version of test code that triggered this ticket:''' Essentially, + this method involves extreme loop unrolling with very imperative code + although coded functionally; in the case of the following code it means + that, recognizing that for all odd primes (which they all are other than + two), and that all word sizes are of an even number of bits, there will be + a repeating pattern of composite number culls that repeats every word size + number of bits. Thus for a word size of one eight-bit byte, we can unroll + to eight composite culls in the body of one loop, with loops cases for the + primes modulo 8 of 1, 3, 5, and 7, and for the eight bit start positions + (b0..b7) meaning there are four times eight is 32 loop cases. When there + are no longer a full eight culls left, the culling reverts to conventional New description: '''Background:''' I've been intrigued investigating whether GHC can produce code "as fast as Cee (C/C++/Rust/etc.)" by-any-means-possible, and have been using the very tight inner composite culling loops (purely integer operations) of a basic Sieve of Eratosthenes implementation as a test vehicle. '''Synopsis:''' This is a follow-on of the work leading to finding the efficiency problem described in ticket #12798, but involves pushing the speed even further as per the method described for "primesieve" as per [http://primesieve.org/] in the "Highly optimized inner loop" section. '''Shortest possible test code that clearly shows non-strict code not being optimized, but optimized when made strict:''' Please refer directly to comment 12https://ghc.haskell.org/trac/ghc/ticket/12808#comment:12, '''A version of test code that triggered this ticket:''' Essentially, this method involves extreme loop unrolling with very imperative code although coded functionally; in the case of the following code it means that, recognizing that for all odd primes (which they all are other than two), and that all word sizes are of an even number of bits, there will be a repeating pattern of composite number culls that repeats every word size number of bits. Thus for a word size of one eight-bit byte, we can unroll to eight composite culls in the body of one loop, with loops cases for the primes modulo 8 of 1, 3, 5, and 7, and for the eight bit start positions (b0..b7) meaning there are four times eight is 32 loop cases. When there are no longer a full eight culls left, the culling reverts to conventional single-cull-per-loop as per the test program of ticket #12798. To do this using GHC we need pointer arithmetic, and the only way to implement pointer arithmetic in GHC is to use the Addr# primitive. GHC/Haskell has one other slight overhead over Cee languages in that we need to move the culling array to a pinned array to avoid having it moved while the culling is going on and then move it back when finished but this takes a negligible amount of time (one percent or so) as compared to the culling. As usual for test programs, the culling operations are repeated in a loop for a number of times to give more accurate timing not influenced by execution not related to the culling. All of this is included in the following code (truncated as to loop coses for inclusion here): {{{#!hs -- EfficiencyBug.hs -- showing that there is a register loop invariant bug in generation of assembler code... -- LLVM shows the bug clearer since the code is generally a little faster... {-# LANGUAGE FlexibleContexts, BangPatterns, MagicHash, UnboxedTuples #-} {-# OPTIONS_GHC -O2 -rtsopts -keep-s-files #-} -- or -O2 -fllvm import Data.Word import Data.Bits import Data.Array.ST (runSTUArray) import Data.Array.Base import GHC.ST ( ST(..) ) import GHC.Exts numLOOPS = 10000 :: Int -- Uses a very simple Sieve of Eratosthenes for fixed 2 ^ 18 range (so one L1 cache size) to prove it. twos :: UArray Int Word32 twos = listArray (0, 31) [1 `shiftL` i | i <- [0 .. 31]] soep1 :: () -> [Word32] soep1() = 2 : [fromIntegral i * 2 + 3 | (i, False) <- assocs bufb] where bufb = runSTUArray $ do let bfBts = (256 * 1024) `div` 2 -- to 2^18 + 2 is 128 KBits = 16 KBytes bf <- newArray (0, bfBts - 1) False :: ST s (STUArray s Int Bool) cullb bf cullb bf@(STUArray l u n marr#) = ST $ \s0# -> case getSizeofMutableByteArray# marr# s0# of { (# s1#, n# #) -> let loop t mr# s0# = -- cull a number of times to test timing if t <= 0 then (# s0#, STUArray l u n mr# #) else case getSizeofMutableByteArray# mr# s0# of { (# s1#, n# #) -> case newPinnedByteArray# n# s1# of { (# s2#, marr'# #) -> case copyMutableByteArray# mr# 0# marr'# 0# n# s2# of { s3# -> case unsafeFreezeByteArray# marr'# s3# of { (# s4#, arr# #) -> -- must do this case byteArrayContents# arr# of { adr# -> -- to obtain the addr# here let cullp i@(I# i#) sp# = let !p@(I# p#) = i + i + 3 in let !s@(I# s#) = (p * p - 3) `div` 2 in if s >= n then case copyMutableByteArray# marr'# 0# mr# 0# n# sp# of so# -> (# so#, mr# #) else let !(UArray _ _ _ tarr#) = twos in case readWord64Array# marr# (i# `uncheckedIShiftRL#` 6#) sp# of { (# sp0#, v0# #) -> case (v0# `and#` ((int2Word# 1#) `uncheckedShiftL#` (i# `andI#` 63#))) `eqWord#` (int2Word# 0#) of 0# -> cullp (i + 1) sp0# -- not prime _ -> -- is prime -- most program execution time spent in the following tight loops. -- the following code implments extream loop unrolling... let !pi@(I# pi#) = fromIntegral p in let !sw@(I# sw#) = s `shiftR` 3 in let !sb@(I# sb#) = s .&. 7 in let p1 = sb + pi in let !(I# r1#) = p1 `shiftR` 3 in let p2 = p1 + pi in let !(I# r2#) = p2 `shiftR` 3 in let p3 = p2 + pi in let !(I# r3#) = p3 `shiftR` 3 in let p4 = p3 + pi in let !(I# r4#) = p4 `shiftR` 3 in let p5 = p4 + pi in let !(I# r5#) = p5 `shiftR` 3 in let p6 = p5 + pi in let !(I# r6#) = p6 `shiftR` 3 in let p7 = p6 + pi in let !(I# r7#) = p7 `shiftR` 3 in let !lmt@(I# lmt#) = (fromIntegral n `shiftR` 3) - p7 in let !lmt1# = plusAddr# adr# lmt# in let !strt# = plusAddr# adr# sw# in let !(I# n#) = n in let (# !so#, !sco# #) = case ((((p - 1) `div` 2) .&. 3) `shiftL` 3) + sb of { 0 -> let cull c# sp# = case c# `ltAddr#` lmt1# of 0# -> (# c#, sp# #) _ -> case readWord8OffAddr# c# 0# sp# of { (# sp0#, v0# #) -> case writeWord8OffAddr# c# 0# (v0# `or#` (int2Word# 1#)) sp0# of { sp1# -> case readWord8OffAddr# c# r1# sp1# of { (# sp2#, v1# #) -> case writeWord8OffAddr# c# r1# (v1# `or#` (int2Word# 2#)) sp2# of { sp3# -> case readWord8OffAddr# c# r2# sp3# of { (# sp4#, v2# #) -> case writeWord8OffAddr# c# r2# (v2# `or#` (int2Word# 4#)) sp4# of { sp5# -> case readWord8OffAddr# c# r3# sp5# of { (# sp6#, v3# #) -> case writeWord8OffAddr# c# r3# (v3# `or#` (int2Word# 8#)) sp6# of { sp7# -> case readWord8OffAddr# c# r4# sp7# of { (# sp8#, v4# #) -> case writeWord8OffAddr# c# r4# (v4# `or#` (int2Word# 16#)) sp8# of { sp9# -> case readWord8OffAddr# c# r5# sp9# of { (# sp10#, v5# #) -> case writeWord8OffAddr# c# r5# (v5# `or#` (int2Word# 32#)) sp10# of { sp11# -> case readWord8OffAddr# c# r6# sp11# of { (# sp12#, v6# #) -> case writeWord8OffAddr# c# r6# (v6# `or#` (int2Word# 64#)) sp12# of { sp13# -> case readWord8OffAddr# c# r7# sp13# of { (# sp14#, v7# #) -> case writeWord8OffAddr# c# r7# (v7# `or#` (int2Word# 128#)) sp14# of { sp15# -> cull (plusAddr# c# pi#) sp15# }}}}}}}}}}}}}}}} in cull strt# sp0#; 1 -> let cull c# sp# = case c# `ltAddr#` lmt1# of 0# -> (# c#, sp# #) _ -> case readWord8OffAddr# c# 0# sp# of { (# sp0#, v0# #) -> case writeWord8OffAddr# c# 0# (v0# `or#` (int2Word# 2#)) sp0# of { sp1# -> case readWord8OffAddr# c# r1# sp1# of { (# sp2#, v1# #) -> case writeWord8OffAddr# c# r1# (v1# `or#` (int2Word# 4#)) sp2# of { sp3# -> case readWord8OffAddr# c# r2# sp3# of { (# sp4#, v2# #) -> case writeWord8OffAddr# c# r2# (v2# `or#` (int2Word# 8#)) sp4# of { sp5# -> case readWord8OffAddr# c# r3# sp5# of { (# sp6#, v3# #) -> case writeWord8OffAddr# c# r3# (v3# `or#` (int2Word# 16#)) sp6# of { sp7# -> case readWord8OffAddr# c# r4# sp7# of { (# sp8#, v4# #) -> case writeWord8OffAddr# c# r4# (v4# `or#` (int2Word# 32#)) sp8# of { sp9# -> case readWord8OffAddr# c# r5# sp9# of { (# sp10#, v5# #) -> case writeWord8OffAddr# c# r5# (v5# `or#` (int2Word# 64#)) sp10# of { sp11# -> case readWord8OffAddr# c# r6# sp11# of { (# sp12#, v6# #) -> case writeWord8OffAddr# c# r6# (v6# `or#` (int2Word# 128#)) sp12# of { sp13# -> case readWord8OffAddr# c# r7# sp13# of { (# sp14#, v7# #) -> case writeWord8OffAddr# c# r7# (v7# `or#` (int2Word# 1#)) sp14# of { sp15# -> cull (plusAddr# c# pi#) sp15# }}}}}}}}}}}}}}}} in cull strt# sp0#; -- and so on for 30 more cases... _ -> (# strt#, sp0# #) {- normally never taken case, all cases covered -} } in let !ns# = ((minusAddr# so# adr#) `uncheckedIShiftL#` 3#) +# sb# in -- extreme loop unrolling ends here; remaining primes culled conventionally... let cull j# sc# = -- very tight inner loop case j# <# n# of 0# -> cullp (i + 1) sc# _ -> let i# = j# `andI#` 31# in let !sh# = indexWord32Array# tarr# i# in -- (1 `shiftL` (j .&. 31))) let w# = j# `uncheckedIShiftRL#` 5# in case readWord32Array# marr'# w# sc# of { (# sc0#, ov# #) -> case writeWord32Array# marr'# w# (ov# `or#` sh#) sc0# of { sc1# -> cull (j# +# pi#) sc1# }} in cull ns# sp0# } in case cullp 0 s4# of (# sp#, mrp# #) -> loop (t - 1) mrp# sp# }}}}} in loop numLOOPS marr# s1# } main = print $ length $ soep1() }}} '''The problem:''' The problem is in the innermost loop of the cases, for which case "0" the following assembly code (using -fllvm) is produced: {{{ seGU_info$def: # BB#0: # %cgRL cmpq %r14, 70(%rbx) jbe .LBB35_1 .align 16, 0x90 .LBB35_2: # %cgRJ # =>This Inner Loop Header: Depth=1 movq 14(%rbx), %rcx movq 22(%rbx), %rdx movq 30(%rbx), %rsi movq 38(%rbx), %rdi movq 46(%rbx), %r8 movq 54(%rbx), %r9 movq 62(%rbx), %r10 movq 6(%rbx), %rax addq %r14, %rax orb $1, (%r14) orb $2, (%rcx,%r14) orb $4, (%rdx,%r14) orb $8, (%rsi,%r14) orb $16, (%rdi,%r14) orb $32, (%r8,%r14) orb $64, (%r9,%r14) orb $-128, (%r10,%r14) cmpq 70(%rbx), %rax movq %rax, %r14 jb .LBB35_2 jmp .LBB35_3 .LBB35_1: movq %r14, %rax .LBB35_3: # %cgRK movq (%rbp), %rcx movq %rax, %rbx rex64 jmpq *%rcx # TAILCALL }}} One can readily see that the compiler is not lifting the Loop Invariant Code Flow as in initializing the registers to outside the inner loop, meaning there are many register loads from memory which are not necessary. '''Desired results:''' The desired assembly code is something like the following, which is similar to what is produced by Cee (C/C++/Rust/etc.): {{{ seGU_info$def: # BB#0: # %cgRL movq 14(%rbx), %rcx movq 22(%rbx), %rdx movq 30(%rbx), %rsi movq 38(%rbx), %rdi movq 46(%rbx), %r8 movq 54(%rbx), %r9 movq 62(%rbx), %r10 movq 6(%rbx), %rax movq 70(%rbx), %rbx cmpq %r14, %rbx # rbx clobbered here, but old value jbe .LBB35_1 # never used again until replaced after loop .align 16, 0x90 .LBB35_2: # %cgRJ # =>This Inner Loop Header: Depth=1 orb $1, (%r14) orb $2, (%rcx,%r14) orb $4, (%rdx,%r14) orb $8, (%rsi,%r14) orb $16, (%rdi,%r14) orb $32, (%r8,%r14) orb $64, (%r9,%r14) orb $-128, (%r10,%r14) addq %rax, %r14 cmpq %rbx, %r14 jb .LBB35_2 jmp .LBB35_3 .LBB35_1: movq %r14, %rax .LBB35_3: # %cgRK movq (%rbp), %rcx movq %rax, %rbx # rbx clobbered here anyway rex64 jmpq *%rcx # TAILCALL }}} '''Full testing:''' The actual unrolled loop code including all the case loops is too long to post here, but to verify the result is correct (23000) and the performance, the full actual file is attached here. Due to the magic of modern CPU instruction fusion and Out Of Order (OOE) execution, the code is not as slow as it would indicate by the number of increased instructions, but while it is about twice as fast as when culled conventionally (Intel Skylake), it is about half again as slow as Cee. On an Intel Sky Lake i5-6500 (running at 3.5 GHz for single threading), this takes about one second, about two seconds culled conventionally, but only about 0.6 seconds for Rust/LLVM (with the assembly code output essentially identical to the "desired" code). '''Other back ends and targets:''' Although the code generated by the native NCG has other problems (not moving the loop test to the end of the loop to avoid one jump, and not combining the read and modify and store instructions into the single available instruction), it exhibits the same problem as to not lifting the Loop Invariant Code Flow register initialization. Although this code is x86_64, the problem also applies to x86 code even though the x86 architecture doesn't have enough registers to do this in one loop and needs to be split into two loops culling only four composites per loop, but there still is a significant gain in speed. Although not tested, it probably also applies to other targets such as ARM (which has many general purpose registers). '''Conclusion:''' The use of Addr# primitives is probably not a frequent use case, but as shown here that when one needs their use, they should be efficient. I considered that GHC may intentionally limit the performance of these unsafe primitives to limit their use unless absolutely necessary as in marshalling, something as C# does for the use of unsafe pointers, but surely GHC would not do that as the target programmers are different. '''If this and ticket #12798 were fixed, for this use case the GHC code would be within a percent or two of the performance of Cee.''' -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 9 11:35:33 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Dec 2016 11:35:33 -0000 Subject: [GHC] #8925: :print and :sprint sometimes fully evaluates strings In-Reply-To: <045.158e5823a1b625f26a808590111b756b@haskell.org> References: <045.158e5823a1b625f26a808590111b756b@haskell.org> Message-ID: <060.af7ddeb2f34b9535cf91276cb244a754@haskell.org> #8925: :print and :sprint sometimes fully evaluates strings -------------------------------------+------------------------------------- Reporter: soapie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dramforever): This still affects 8.0.1. Is there any update on this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 9 13:08:26 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Dec 2016 13:08:26 -0000 Subject: [GHC] #11011: Add type-indexed type representations (`TypeRep a`) In-Reply-To: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> References: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> Message-ID: <062.2836c6da2acf73afac145649e18089cb@haskell.org> #11011: Add type-indexed type representations (`TypeRep a`) -------------------------------------+------------------------------------- Reporter: bjmprice | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2010 Wiki Page: | -------------------------------------+------------------------------------- Changes (by baramoglo): * cc: baramoglo (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 9 13:11:27 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Dec 2016 13:11:27 -0000 Subject: [GHC] #12936: Type inference regression in GHC HEAD In-Reply-To: <050.1f2cf84cf2dccac9b01fc4b4cae905cd@haskell.org> References: <050.1f2cf84cf2dccac9b01fc4b4cae905cd@haskell.org> Message-ID: <065.2392b96252ab5fb6bdee6dfa27d94cf6@haskell.org> #12936: Type inference regression in GHC HEAD -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Rufflewind): Ran into this same bug too. I think something is broken with the constraint solving and/or functional dependencies. I managed to simplify the bug to the following: {{{#!hs {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE ScopedTypeVariables #-} module Token where class S s t | s -> t m :: forall s t . S s t => s m = undefined o :: forall s t . S s t => s -> s o = undefined c :: forall s . s -> s -> s c = undefined p :: forall s . S s () => s -> s p d = f where -- declaring either of these type signatures will cause the bug to go away -- f :: s f = c d (o e) -- e :: s e = c m m }}} Inlining it any further will cause the bug to vanish. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 9 13:56:37 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Dec 2016 13:56:37 -0000 Subject: [GHC] #12646: Type family reification misses a kind signature In-Reply-To: <047.cba91014c4d60775bdcbc80a5671d922@haskell.org> References: <047.cba91014c4d60775bdcbc80a5671d922@haskell.org> Message-ID: <062.45805e0426b9b2cc4d632952394e46d1@haskell.org> #12646: Type family reification misses a kind signature -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8953 | Differential Rev(s): Phab:D2795 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"f65ff2c4c9b60e370a722ac7572186816e23e573/ghc" f65ff2c4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f65ff2c4c9b60e370a722ac7572186816e23e573" Disambiguate reified closed type family kinds in TH Summary: A continuation of #8953. This fixes an oversight in which the left-hand sides of closed type families, when reified in Template Haskell, would not be given kind annotations, even when they are necessary for disambiguation purposes in the presence of `PolyKinds`. Fixes #8953 and #12646. Test Plan: ./validate Reviewers: hvr, bgamari, austin, goldfire Reviewed By: goldfire Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2795 GHC Trac Issues: #8953, #12646 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 9 13:56:37 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Dec 2016 13:56:37 -0000 Subject: [GHC] #8953: Reification drops necessary kind annotations In-Reply-To: <047.1c676b3de5fd3f2cb8726d1a1f304ef8@haskell.org> References: <047.1c676b3de5fd3f2cb8726d1a1f304ef8@haskell.org> Message-ID: <062.fa60dae2b77094588f0afeb6c9b26024@haskell.org> #8953: Reification drops necessary kind annotations -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: th/T8953 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D387, Wiki Page: | Phab:D2795 -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"f65ff2c4c9b60e370a722ac7572186816e23e573/ghc" f65ff2c4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f65ff2c4c9b60e370a722ac7572186816e23e573" Disambiguate reified closed type family kinds in TH Summary: A continuation of #8953. This fixes an oversight in which the left-hand sides of closed type families, when reified in Template Haskell, would not be given kind annotations, even when they are necessary for disambiguation purposes in the presence of `PolyKinds`. Fixes #8953 and #12646. Test Plan: ./validate Reviewers: hvr, bgamari, austin, goldfire Reviewed By: goldfire Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2795 GHC Trac Issues: #8953, #12646 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 9 13:57:29 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Dec 2016 13:57:29 -0000 Subject: [GHC] #8953: Reification drops necessary kind annotations In-Reply-To: <047.1c676b3de5fd3f2cb8726d1a1f304ef8@haskell.org> References: <047.1c676b3de5fd3f2cb8726d1a1f304ef8@haskell.org> Message-ID: <062.de10b88058620819a875e401dafb3fa6@haskell.org> #8953: Reification drops necessary kind annotations -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Template Haskell | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: th/T8953 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D387, Wiki Page: | Phab:D2795 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 9 13:57:42 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Dec 2016 13:57:42 -0000 Subject: [GHC] #12646: Type family reification misses a kind signature In-Reply-To: <047.cba91014c4d60775bdcbc80a5671d922@haskell.org> References: <047.cba91014c4d60775bdcbc80a5671d922@haskell.org> Message-ID: <062.0620c7fe098dffe7795515a183789b75@haskell.org> #12646: Type family reification misses a kind signature -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Template Haskell | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8953 | Differential Rev(s): Phab:D2795 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 9 16:17:49 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Dec 2016 16:17:49 -0000 Subject: [GHC] #12877: Constant propagation with basic unboxed arithmetic instructions In-Reply-To: <045.bd713e9e019034e67a37dfef8669f427@haskell.org> References: <045.bd713e9e019034e67a37dfef8669f427@haskell.org> Message-ID: <060.4ed0145551a539e132e0f30bacefaca1@haskell.org> #12877: Constant propagation with basic unboxed arithmetic instructions -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: hsyl20 Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2762 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"d3b546b1a6058f26d5659c7f2000a7b25b7ea2ba/ghc" d3b546b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d3b546b1a6058f26d5659c7f2000a7b25b7ea2ba" Scrutinee Constant Folding This patch introduces new rules to perform constant folding through case-expressions. E.g., ``` case t -# 10# of _ { ===> case t of _ { 5# -> e1 15# -> e1 8# -> e2 18# -> e2 DEFAULT -> e DEFAULT -> e ``` The initial motivation is that it allows "Merge Nested Cases" optimization to kick in and to further simplify the code (see Trac #12877). Currently we recognize the following operations for Word# and Int#: Add, Sub, Xor, Not and Negate (for Int# only). Test Plan: validate Reviewers: simonpj, austin, bgamari Reviewed By: simonpj, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2762 GHC Trac Issues: #12877 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 9 16:17:49 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Dec 2016 16:17:49 -0000 Subject: [GHC] #12927: Colorized error messages result in hard-to-read .dump-* files In-Reply-To: <050.4d52d80d1f24b6c29f775c3be2712dc4@haskell.org> References: <050.4d52d80d1f24b6c29f775c3be2712dc4@haskell.org> Message-ID: <065.f5204470e5435dca64d7eb0564c6ad67@haskell.org> #12927: Colorized error messages result in hard-to-read .dump-* files -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #8809 | Differential Rev(s): Phab:D2792 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"cee72d5c3c53863bd4fc9f324a93c322448e038e/ghc" cee72d5/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="cee72d5c3c53863bd4fc9f324a93c322448e038e" Disable colors unless printing to stderr Only print colors when mkLocMessageAnn is called directly from defaultLogAction. This prevents ANSI error codes from cluttering up the dump files. Test Plan: validate Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2792 GHC Trac Issues: #12927 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 9 16:24:31 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Dec 2016 16:24:31 -0000 Subject: [GHC] #12927: Colorized error messages result in hard-to-read .dump-* files In-Reply-To: <050.4d52d80d1f24b6c29f775c3be2712dc4@haskell.org> References: <050.4d52d80d1f24b6c29f775c3be2712dc4@haskell.org> Message-ID: <065.85e8d64495b6bcd6e9d70c25d706e94d@haskell.org> #12927: Colorized error messages result in hard-to-read .dump-* files -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #8809 | Differential Rev(s): Phab:D2792 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 9 16:59:21 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Dec 2016 16:59:21 -0000 Subject: [GHC] #12727: ghc: panic! (the 'impossible' happened) - piResultTy In-Reply-To: <047.7a02b67b63e3ce77f03bfc70c60ffa06@haskell.org> References: <047.7a02b67b63e3ce77f03bfc70c60ffa06@haskell.org> Message-ID: <062.b2955593f058a8cd398edf9831299e69@haskell.org> #12727: ghc: panic! (the 'impossible' happened) - piResultTy -------------------------------------+------------------------------------- Reporter: ocharles | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ocharles): Another panic that is different from all the above: {{{ [231 of 278] Compiling Handler.Pallets ( src/Handler/Pallets.hs, dist/build/Handler/Pallets.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.1.20161117 for x86_64-unknown-linux): getClassPredTys [Sql] }}} It's very strange that we seem to get different panics every time -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 9 17:43:43 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Dec 2016 17:43:43 -0000 Subject: [GHC] #12727: ghc: panic! (the 'impossible' happened) - piResultTy In-Reply-To: <047.7a02b67b63e3ce77f03bfc70c60ffa06@haskell.org> References: <047.7a02b67b63e3ce77f03bfc70c60ffa06@haskell.org> Message-ID: <062.c6c1e7121cb74564730f8b1ce103064a@haskell.org> #12727: ghc: panic! (the 'impossible' happened) - piResultTy -------------------------------------+------------------------------------- Reporter: ocharles | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): All very mysterious. But I can't do anything without a way to reproduce, unfortunately. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 9 17:44:13 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Dec 2016 17:44:13 -0000 Subject: [GHC] #12936: Type inference regression in GHC HEAD In-Reply-To: <050.1f2cf84cf2dccac9b01fc4b4cae905cd@haskell.org> References: <050.1f2cf84cf2dccac9b01fc4b4cae905cd@haskell.org> Message-ID: <065.ee8d8b93da789a78afa41aa0f3cd1d45@haskell.org> #12936: Type inference regression in GHC HEAD -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I've solved this; validating now; will commit on Monday. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 9 18:38:25 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Dec 2016 18:38:25 -0000 Subject: [GHC] #12745: Compile cmm file for register allocator stats In-Reply-To: <046.aedaab3ee1da5a91e8f8ed1888c354b2@haskell.org> References: <046.aedaab3ee1da5a91e8f8ed1888c354b2@haskell.org> Message-ID: <061.80ee1b56af5000f74619b33087aa5625@haskell.org> #12745: Compile cmm file for register allocator stats -------------------------------------+------------------------------------- Reporter: tjakway | Owner: tjakway Type: task | Status: closed Priority: lowest | Milestone: Component: Compiler (NCG) | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12744 | Differential Rev(s): Phab:D2638 Wiki Page: | -------------------------------------+------------------------------------- Changes (by tjakway): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 9 19:30:08 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Dec 2016 19:30:08 -0000 Subject: [GHC] #12923: MultiParamTypeClasses + ExtendedDefaultRules In-Reply-To: <046.9ae3ec8e366c95f2b64ecec80ccef95a@haskell.org> References: <046.9ae3ec8e366c95f2b64ecec80ccef95a@haskell.org> Message-ID: <061.41044ef8173f05d1abd9ffb3d70cb4d7@haskell.org> #12923: MultiParamTypeClasses + ExtendedDefaultRules -------------------------------------+------------------------------------- Reporter: amindfv | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by amindfv): For my needs, given the rule linked above: "All of the classes Ci are single-parameter type classes." I would relax it to say: "Only one parameter in each class Ci has kind `:: *` " so this would be a valid program... {{{#!hs class Works a (b :: Bool) where works :: a -> A b instance Works Double 'True main = print (works 5 :: A 'True) }}} ...but this would remain ambiguous: {{{#!hs class Doesnt a b where doesnt :: a -> b instance Doesnt Double Bool main = print $ doesnt 5 True }}} The defaulting rule could be relaxed more, but this seems like the smallest possible change. Additionally, this change is critical for my EDSL's coherence; a more-relaxed rule would just be nice-to-have. Thank you! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 9 20:10:14 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Dec 2016 20:10:14 -0000 Subject: [GHC] #8809: Prettier error messages? In-Reply-To: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> References: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> Message-ID: <062.84cc5076cc41deb038a138e47179cdd4@haskell.org> #8809: Prettier error messages? -------------------------------------+------------------------------------- Reporter: joelteon | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): #8809,#10073,#10179,#12906 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Rufflewind): Here's a sketch of [https://phabricator.haskell.org/D2718 what the caret diagnostics look like now]: {{{ #!html 
testsuite/tests/warnings/should_fail/CaretDiagnostics1.hs:8:31:
 error:
     • Couldn't match expected type ‘[Char]’ with actual type ‘()’
     • In the second argument of ‘(+)’, namely ‘()’
       In the first argument of ‘pure’, namely
         ‘("this is not an IO" + ())’
       In a stmt of a 'do' block: pure ("this is not an IO" + ())

   pure ("this is not an IO" + (            ))
                               ^^^^^^^^^^^^^^

 testsuite/tests/warnings/should_fail/CaretDiagnostics1.hs:13:7:
 error:
     • Couldn't match expected type ...
 }}} There are some minor tweaks to the style I mentioned previously: the underlining is now the same color as the error type (red = error, magenta = warning) and the underlined part of the code is also colored and bolded. It also uses exclusively carets (no more tildes). There is also an empty line separating the error message itself from the caret diagnostic. I could go even further to add a margin, kind of like Rust: {{{ #!html 
testsuite/tests/warnings/should_fail/CaretDiagnostics1.hs:8:31:
 error:
     • Couldn't match expected type ‘[Char]’ with actual type ‘()’
     • In the second argument of ‘(+)’, namely ‘()’
       In the first argument of ‘pure’, namely
         ‘("this is not an IO" + ())’
       In a stmt of a 'do' block: pure ("this is not an IO" + ())
   |
 8 |   pure ("this is not an IO" + (            ))
   |                               ^^^^^^^^^^^^^^

 testsuite/tests/warnings/should_fail/CaretDiagnostics1.hs:13:7:
 error:
     • Couldn't match expected type ...
 }}} but I'm concerned that (a) it might add more noise to the diagnostics; (b) it loses the nice property that if your source code is ≤ 80 characters, the error message is guaranteed to be also ≤ 80 characters (otherwise, if the user's terminal is too small, the messages will wrap and become misaligned). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 9 20:51:30 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Dec 2016 20:51:30 -0000 Subject: [GHC] #8809: Prettier error messages? In-Reply-To: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> References: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> Message-ID: <062.3faed0e3ee5c109079067960db72e8e8@haskell.org> #8809: Prettier error messages? -------------------------------------+------------------------------------- Reporter: joelteon | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): #8809,#10073,#10179,#12906 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by joehillen): +1 for margin. I don't see the need for concern about line length; no other compiler seems to care about that. I really hope the "In the first/second argument of" can someday be dropped. It's useless noise once you have carets, and it's always been difficult to grok. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 9 21:04:01 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Dec 2016 21:04:01 -0000 Subject: [GHC] #12923: MultiParamTypeClasses + ExtendedDefaultRules In-Reply-To: <046.9ae3ec8e366c95f2b64ecec80ccef95a@haskell.org> References: <046.9ae3ec8e366c95f2b64ecec80ccef95a@haskell.org> Message-ID: <061.0ec871141226183e4f7fd5e64ad6838b@haskell.org> #12923: MultiParamTypeClasses + ExtendedDefaultRules -------------------------------------+------------------------------------- Reporter: amindfv | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): It's hard to imagine the small generalization in comment:3 doing any harm. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 9 21:12:08 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Dec 2016 21:12:08 -0000 Subject: [GHC] #12923: MultiParamTypeClasses + ExtendedDefaultRules In-Reply-To: <046.9ae3ec8e366c95f2b64ecec80ccef95a@haskell.org> References: <046.9ae3ec8e366c95f2b64ecec80ccef95a@haskell.org> Message-ID: <061.39f94754f0c1e82c0ba62a629bda1b74@haskell.org> #12923: MultiParamTypeClasses + ExtendedDefaultRules -------------------------------------+------------------------------------- Reporter: amindfv | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2816 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D2816 * milestone: => 8.2.1 Comment: Here's a quick patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 9 21:19:31 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Dec 2016 21:19:31 -0000 Subject: [GHC] #12877: Constant propagation with basic unboxed arithmetic instructions In-Reply-To: <045.bd713e9e019034e67a37dfef8669f427@haskell.org> References: <045.bd713e9e019034e67a37dfef8669f427@haskell.org> Message-ID: <060.29314f65c3277f005bc0da975692db69@haskell.org> #12877: Constant propagation with basic unboxed arithmetic instructions -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: hsyl20 Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2762 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 9 21:26:57 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Dec 2016 21:26:57 -0000 Subject: [GHC] #12956: Something has broken T12903 Message-ID: <046.00d2d5d11cfef207ccca3cd778c78a40@haskell.org> #12956: Something has broken T12903 --------------------------------------+--------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.1 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- 895a131f6e56847d9ebca2e9bfe19a3189e49d72, which fixes #12903, seems to be broken on OS X. The tree was known to compile at 499e43824bda967546ebf95ee33ec1f84a114a7c and is known to be broken at 61932cd3eb0d5d22cb35d118fb9f87298881cd77. I'll need to figure out which of the intervening commits broken it -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 9 21:29:01 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Dec 2016 21:29:01 -0000 Subject: [GHC] #12357: Increasing maximum constraint tuple size significantly blows up compiler allocations In-Reply-To: <046.dd0f12e974ac3c5c9febd70397bf4138@haskell.org> References: <046.dd0f12e974ac3c5c9febd70397bf4138@haskell.org> Message-ID: <061.cba547ccb98356154c6af0ec08b432c2@haskell.org> #12357: Increasing maximum constraint tuple size significantly blows up compiler allocations -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2400, Wiki Page: | Phab:D2414 -------------------------------------+------------------------------------- Comment (by bgamari): This has been merged, resulting in the fixes * f53d761df9762232b54ec57a950d301011cd21f8 * eb3d6595735671605c5d6294a796dc0f16f784a4 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 9 21:29:19 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Dec 2016 21:29:19 -0000 Subject: [GHC] #12357: Increasing maximum constraint tuple size significantly blows up compiler allocations In-Reply-To: <046.dd0f12e974ac3c5c9febd70397bf4138@haskell.org> References: <046.dd0f12e974ac3c5c9febd70397bf4138@haskell.org> Message-ID: <061.38c80631e9c174fd8eb2ca2e4a29c3f3@haskell.org> #12357: Increasing maximum constraint tuple size significantly blows up compiler allocations -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2400, Wiki Page: | Phab:D2414 -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.2.1 Comment: I think it is safe to call this resolved. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 9 21:30:49 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Dec 2016 21:30:49 -0000 Subject: [GHC] #12946: Cannot load hmatrix with ghci -fexternal-interpreter: missing symbol ___ieee_divdc3 In-Reply-To: <047.61f1ff3a967a9dd024164163630b3512@haskell.org> References: <047.61f1ff3a967a9dd024164163630b3512@haskell.org> Message-ID: <062.b276f1ad396451f9b9879ce337592750@haskell.org> #12946: Cannot load hmatrix with ghci -fexternal-interpreter: missing symbol ___ieee_divdc3 -------------------------------------+------------------------------------- Reporter: simonmar | Owner: bgamari Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12932 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => duplicate * related: => #12932 Comment: It looks like this is a duplicate of #12932. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 9 21:46:55 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Dec 2016 21:46:55 -0000 Subject: [GHC] #12932: -fexternal-interpreter` fails to find symbols In-Reply-To: <046.e268f025fb07ea6927f21c0906b2681d@haskell.org> References: <046.e268f025fb07ea6927f21c0906b2681d@haskell.org> Message-ID: <061.35591b917e19afff8e001706764f7db5@haskell.org> #12932: -fexternal-interpreter` fails to find symbols -----------------------------+---------------------------------------- Reporter: dominic | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #12946 | Differential Rev(s): Wiki Page: | -----------------------------+---------------------------------------- Changes (by bgamari): * related: => #12946 * milestone: => 8.2.1 Comment: This was also reported as #12946. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 9 21:55:35 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Dec 2016 21:55:35 -0000 Subject: [GHC] #11317: Test prog003 fails with segfault on Windows (GHCi) In-Reply-To: <046.e04825e713c12f85562a518dea8fe3f3@haskell.org> References: <046.e04825e713c12f85562a518dea8fe3f3@haskell.org> Message-ID: <061.5791a2c714fa5f9f105e43e777e7f652@haskell.org> #11317: Test prog003 fails with segfault on Windows (GHCi) ---------------------------------+---------------------------------------- Reporter: rdragon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.11 Resolution: | Keywords: GC Operating System: Windows | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: prog003 Blocked By: | Blocking: Related Tickets: #11234 #3408 | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by bgamari): * status: closed => new * resolution: fixed => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 9 22:01:48 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Dec 2016 22:01:48 -0000 Subject: [GHC] #12932: -fexternal-interpreter` fails to find symbols In-Reply-To: <046.e268f025fb07ea6927f21c0906b2681d@haskell.org> References: <046.e268f025fb07ea6927f21c0906b2681d@haskell.org> Message-ID: <061.3cc9101d2a97ef4e6121c8773303d56a@haskell.org> #12932: -fexternal-interpreter` fails to find symbols -----------------------------+---------------------------------------- Reporter: dominic | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #12946 | Differential Rev(s): Wiki Page: | -----------------------------+---------------------------------------- Comment (by bgamari): The problem is that the linker cannot find `___ieee_divdc3`, a `libgcc` symbol. I'll need to look into why. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 9 22:03:10 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Dec 2016 22:03:10 -0000 Subject: [GHC] #12932: -fexternal-interpreter` fails to find symbols In-Reply-To: <046.e268f025fb07ea6927f21c0906b2681d@haskell.org> References: <046.e268f025fb07ea6927f21c0906b2681d@haskell.org> Message-ID: <061.af638460016d80188a5ef28b217668f0@haskell.org> #12932: -fexternal-interpreter` fails to find symbols -----------------------------+---------------------------------------- Reporter: dominic | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #12946 | Differential Rev(s): Wiki Page: | -----------------------------+---------------------------------------- Changes (by bgamari): * status: new => infoneeded Comment: Where did you get your GHC build from, dominic? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 9 22:03:58 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Dec 2016 22:03:58 -0000 Subject: [GHC] #12956: Something has broken T12903 In-Reply-To: <046.00d2d5d11cfef207ccca3cd778c78a40@haskell.org> References: <046.00d2d5d11cfef207ccca3cd778c78a40@haskell.org> Message-ID: <061.e945acc04148a136edabea50815615c7@haskell.org> #12956: Something has broken T12903 -----------------------------------+-------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------------+-------------------------------------- Comment (by Ben Gamari ): In [changeset:"62418b878a1e57b6d187c4f98bf90f6cd64a58b6/ghc" 62418b8/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="62418b878a1e57b6d187c4f98bf90f6cd64a58b6" Mark T12903 as broken on OS X Something has recently broken it. See #12956. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 9 22:03:58 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Dec 2016 22:03:58 -0000 Subject: [GHC] #9308: nofib fannkuch-redux runs perpetually with -fllvm In-Reply-To: <042.547b78253c22f834191c24f2af1b28cf@haskell.org> References: <042.547b78253c22f834191c24f2af1b28cf@haskell.org> Message-ID: <057.8e2beed689979847005d386a69e848a6@haskell.org> #9308: nofib fannkuch-redux runs perpetually with -fllvm -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 7.8.3 Resolution: | Keywords: fannkuch- | redux Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: fannkuch- at runtime | redux Blocked By: 9504 | Blocking: Related Tickets: #5567 | Differential Rev(s): Phab:D2758 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"90fae01c326bf8b0802b4e8968f84886be4e1380/ghc" 90fae01c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="90fae01c326bf8b0802b4e8968f84886be4e1380" Fix LLVM TBAA metadata Accesses through a Cmm local are currently reported as having the "other" type, which can only alias other "other" accesses. However, this assumption is incorrect, which can result in silent bad LLVM codegen. Fixes #9308. Fixes #9504. Test Plan: GHC CI Reviewers: rwbarton, austin, bgamari Reviewed By: bgamari Subscribers: michalt, thomie Differential Revision: https://phabricator.haskell.org/D2758 GHC Trac Issues: #9125, #9308, #9504 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 9 22:03:58 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Dec 2016 22:03:58 -0000 Subject: [GHC] #9504: LLVM backend TBAA is too aggressive In-Reply-To: <047.895b450af37d81fdca37d7d76677e0ee@haskell.org> References: <047.895b450af37d81fdca37d7d76677e0ee@haskell.org> Message-ID: <062.871ef6272aeb736f529329587d333852@haskell.org> #9504: LLVM backend TBAA is too aggressive -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: 9308 Related Tickets: | Differential Rev(s): Phab:D2758 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"90fae01c326bf8b0802b4e8968f84886be4e1380/ghc" 90fae01c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="90fae01c326bf8b0802b4e8968f84886be4e1380" Fix LLVM TBAA metadata Accesses through a Cmm local are currently reported as having the "other" type, which can only alias other "other" accesses. However, this assumption is incorrect, which can result in silent bad LLVM codegen. Fixes #9308. Fixes #9504. Test Plan: GHC CI Reviewers: rwbarton, austin, bgamari Reviewed By: bgamari Subscribers: michalt, thomie Differential Revision: https://phabricator.haskell.org/D2758 GHC Trac Issues: #9125, #9308, #9504 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 9 22:03:58 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Dec 2016 22:03:58 -0000 Subject: [GHC] #9125: int-to-float conversion broken on ARM In-Reply-To: <046.674440465a685280d146765ea38d0bfb@haskell.org> References: <046.674440465a685280d146765ea38d0bfb@haskell.org> Message-ID: <061.80e180f0081077bae03ca5874e7dcb6a@haskell.org> #9125: int-to-float conversion broken on ARM -------------------------------------+------------------------------------- Reporter: Ansible | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.8.3 (CodeGen) | Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Incorrect result | Test Case: at runtime | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"90fae01c326bf8b0802b4e8968f84886be4e1380/ghc" 90fae01c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="90fae01c326bf8b0802b4e8968f84886be4e1380" Fix LLVM TBAA metadata Accesses through a Cmm local are currently reported as having the "other" type, which can only alias other "other" accesses. However, this assumption is incorrect, which can result in silent bad LLVM codegen. Fixes #9308. Fixes #9504. Test Plan: GHC CI Reviewers: rwbarton, austin, bgamari Reviewed By: bgamari Subscribers: michalt, thomie Differential Revision: https://phabricator.haskell.org/D2758 GHC Trac Issues: #9125, #9308, #9504 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 9 22:03:58 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Dec 2016 22:03:58 -0000 Subject: [GHC] #10598: DeriveAnyClass and GND don't work well together In-Reply-To: <043.eb0a3cc9875acc25d45d33a9b9c86b64@haskell.org> References: <043.eb0a3cc9875acc25d45d33a9b9c86b64@haskell.org> Message-ID: <058.bee0636a499f8800e0a4226eb75d3c4d@haskell.org> #10598: DeriveAnyClass and GND don't work well together -------------------------------------+------------------------------------- Reporter: osa1 | Owner: RyanGlScott Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | deriving/should_run/T10598_bug Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2280 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"5349d648fd7af3f50953e8594b3d148ab073017f/ghc" 5349d648/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5349d648fd7af3f50953e8594b3d148ab073017f" Rename TH constructors for deriving strategies After talking to Richard, he and I concluded that choosing the rather common name `Newtype` to represent the corresponding deriving strategy in Template Haskell was a poor choice of name. I've opted to rename it to something less common (`NewtypeStrategy`) while we still have time. I also renamed the corrsponding datatype in the GHC internals so as to match it. Reviewers: austin, goldfire, hvr, bgamari Reviewed By: bgamari Subscribers: thomie, mpickering Differential Revision: https://phabricator.haskell.org/D2814 GHC Trac Issues: #10598 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 9 22:03:58 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Dec 2016 22:03:58 -0000 Subject: [GHC] #11317: Test prog003 fails with segfault on Windows (GHCi) In-Reply-To: <046.e04825e713c12f85562a518dea8fe3f3@haskell.org> References: <046.e04825e713c12f85562a518dea8fe3f3@haskell.org> Message-ID: <061.7520f01fa951b5fdc9f265111e934253@haskell.org> #11317: Test prog003 fails with segfault on Windows (GHCi) ---------------------------------+---------------------------------------- Reporter: rdragon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.11 Resolution: | Keywords: GC Operating System: Windows | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: prog003 Blocked By: | Blocking: Related Tickets: #11234 #3408 | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by Ben Gamari ): In [changeset:"24a4fe2925d66e50b4f5e66e7a5c1ca4a320bf88/ghc" 24a4fe2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="24a4fe2925d66e50b4f5e66e7a5c1ca4a320bf88" testsuite: Mark prog003 as broken on Windows Due to #11317. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 9 22:05:05 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Dec 2016 22:05:05 -0000 Subject: [GHC] #12937: String merging broken on Darwin In-Reply-To: <046.522d1e640cb7ec5705f6e2f81dabecb6@haskell.org> References: <046.522d1e640cb7ec5705f6e2f81dabecb6@haskell.org> Message-ID: <061.cc9e96b7f77ed84d6801daec71e50a3e@haskell.org> #12937: String merging broken on Darwin -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 (Linking) | Resolution: | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: => bgamari -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 9 22:22:38 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Dec 2016 22:22:38 -0000 Subject: [GHC] #9504: LLVM backend TBAA is too aggressive In-Reply-To: <047.895b450af37d81fdca37d7d76677e0ee@haskell.org> References: <047.895b450af37d81fdca37d7d76677e0ee@haskell.org> Message-ID: <062.c7bcae51c58fd33afae67ce74b26f52e@haskell.org> #9504: LLVM backend TBAA is too aggressive -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler (LLVM) | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: 9308 Related Tickets: | Differential Rev(s): Phab:D2758 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 9 23:09:06 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Dec 2016 23:09:06 -0000 Subject: [GHC] #12957: In a record-update construct:ghc-stage2: panic! (the 'impossible' happened) Message-ID: <046.4ffe2bf9b6314906faa3602a2a60600d@haskell.org> #12957: In a record-update construct:ghc-stage2: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While compiling `Repro.hs` with `HEAD` I get this: {{{ $ ~/local/ghc-inaccessible-right-side/inplace/bin/ghc-stage2 Repro.hs [1 of 1] Compiling Repro ( Repro.hs, Repro.o ) Repro.hs:22:35: warning: [-Woverlapping-patterns] Pattern match has inaccessible right hand side In a record-update construct:ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20161209 for x86_64-unknown-linux): unused Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} It doesn't reproduce on 7.10.2. I'm 90% sure it reproduces on 8.0.2 (I have a branch with some unrelated patches). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 9 23:10:04 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Dec 2016 23:10:04 -0000 Subject: [GHC] #12957: In a record-update construct:ghc-stage2: panic! (the 'impossible' happened) In-Reply-To: <046.4ffe2bf9b6314906faa3602a2a60600d@haskell.org> References: <046.4ffe2bf9b6314906faa3602a2a60600d@haskell.org> Message-ID: <061.0294810541e91a05545193483552bc09@haskell.org> #12957: In a record-update construct:ghc-stage2: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by niteria): * Attachment "Repro.hs" added. Repro.hs -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 9 23:34:57 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Dec 2016 23:34:57 -0000 Subject: [GHC] #12957: In a record-update construct:ghc-stage2: panic! (the 'impossible' happened) In-Reply-To: <046.4ffe2bf9b6314906faa3602a2a60600d@haskell.org> References: <046.4ffe2bf9b6314906faa3602a2a60600d@haskell.org> Message-ID: <061.9a3e48b09fd72f0974bc968a7381cb8f@haskell.org> #12957: In a record-update construct:ghc-stage2: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by niteria): {{{ diff --git a/compiler/hsSyn/HsExpr.hs b/compiler/hsSyn/HsExpr.hs index 78ee4e0..4422ec7 100644 --- a/compiler/hsSyn/HsExpr.hs +++ b/compiler/hsSyn/HsExpr.hs @@ -2389,7 +2389,7 @@ matchSeparator LambdaExpr = text "->" matchSeparator ProcExpr = text "->" matchSeparator PatBindRhs = text "=" matchSeparator (StmtCtxt _) = text "<-" -matchSeparator RecUpd = panic "unused" +matchSeparator RecUpd = text "{" matchSeparator ThPatSplice = panic "unused" matchSeparator ThPatQuote = panic "unused" matchSeparator PatSyn = panic "unused" }}} makes the panic go away, but the error isn't very nice: {{{ [1 of 1] Compiling Repro ( Repro.hs, Repro.o ) Repro.hs:22:35: warning: [-Woverlapping-patterns] Pattern match has inaccessible right hand side In a record-update construct: BFields ds_dFp { ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 9 23:43:51 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Dec 2016 23:43:51 -0000 Subject: [GHC] #12808: For non-strict code including primitive (Addr#) code, Loop Invariant Code Flow not lifted outside the loop... In-Reply-To: <050.4b8817bb90d50f291df9e28cde0cf9f5@haskell.org> References: <050.4b8817bb90d50f291df9e28cde0cf9f5@haskell.org> Message-ID: <065.8c2da890c74ccbb53491d6ea34616380@haskell.org> #12808: For non-strict code including primitive (Addr#) code, Loop Invariant Code Flow not lifted outside the loop... -------------------------------------+------------------------------------- Reporter: GordonBGood | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: JoinPoints 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 simonpj): * keywords: => JoinPoints * cc: maurerl@… (added) Comment: Interesting. Looking at comment:12, note the difference between the SLOW version: {{{ let nxtc c = if c > top then return () else do { ...; nxtc (c+p) } in do { nxtc ss; nxtp (p + 1) } }}} and the FAST version {{{ let nxtc c = if c > top then nxtp (p + 1) else do else do { ...; nxtc (c+p) } in nxtc ss }}} In SLOW, `nxtc` is represented by a heap-allocated closure, whereas in FAST `nxtc` is a join point, and hence not allocated at all (you can see that from the `let-no-escape` in the STG). See our paper [https://www.microsoft.com/en-us/research/publication/compiling-without- continuations/ Compiling without continuations], and [wiki:SequentCore]. Notice that in SLOW, the call to `nxtc s` is ''followed by'' a call to `nxtp (p+1)`. But in FAST we move that call right into `nxtc` itself, in the return branch of the `if`. That's what makes `nxtc` into a join point. (None of this has anything to do with non-strictness, incidentally.) This is a rather non-trivial transformation. You clearly think it's a pretty obvious optimisation, but it doesn't look obvious to me. Happily, though, our new Core-with-join-point (described in the paper) should catch this nicely. If we start with SLOW, after a bit we'll get this {{{ let nxtc c s = if c > top then (# s,c #) else case ... of (# s',p #) -> nxtc (c+p) s' } in case nxtc ss s of (# s', r #) -> nxtp (p + 1) s' } }}} Now if we do float-in, to move the `let nxtc` in to the scruintee of the case, it becomes a join point, and join-point analysis should find it. After that, the transformations in the paper will turn it into FAST. The example in comment:10 looks similar: {{{ case doit adr# sp# of sd# -> cullp (p + 2) sd# in cullp 1 s4# }}}}} }}} Here again, `doit` will become a join point if we float it in. The example in the Descrption is too big for me to analyse. I've cc'd Luke Maurer who is implementing Core with join points; this looks like another good example. (cf #12781) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 10 00:07:45 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Dec 2016 00:07:45 -0000 Subject: [GHC] #12923: MultiParamTypeClasses + ExtendedDefaultRules In-Reply-To: <046.9ae3ec8e366c95f2b64ecec80ccef95a@haskell.org> References: <046.9ae3ec8e366c95f2b64ecec80ccef95a@haskell.org> Message-ID: <061.f565534e885867d09f5f51dd32e98384@haskell.org> #12923: MultiParamTypeClasses + ExtendedDefaultRules -------------------------------------+------------------------------------- Reporter: amindfv | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2816 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I don't think that rule will work. As the user manual page says, the list type `[] :: * -> *` is in the list of type defaults, so that higher-kinded variables can be defaulted too. See #10971. So we can't restrict to *. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 10 00:30:54 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Dec 2016 00:30:54 -0000 Subject: [GHC] #12923: MultiParamTypeClasses + ExtendedDefaultRules In-Reply-To: <046.9ae3ec8e366c95f2b64ecec80ccef95a@haskell.org> References: <046.9ae3ec8e366c95f2b64ecec80ccef95a@haskell.org> Message-ID: <061.f9478aa92d753992635b0487262c469a@haskell.org> #12923: MultiParamTypeClasses + ExtendedDefaultRules -------------------------------------+------------------------------------- Reporter: amindfv | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2816 Wiki Page: | -------------------------------------+------------------------------------- Comment (by amindfv): Ahhh. Maybe we can say something like this?: "Only one parameter in each class Ci has kind `:: *` or `:: (->) * _` " -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 10 00:51:04 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Dec 2016 00:51:04 -0000 Subject: [GHC] #12923: MultiParamTypeClasses + ExtendedDefaultRules In-Reply-To: <046.9ae3ec8e366c95f2b64ecec80ccef95a@haskell.org> References: <046.9ae3ec8e366c95f2b64ecec80ccef95a@haskell.org> Message-ID: <061.7c61a076a3fe88ed04361ab58ea6e984@haskell.org> #12923: MultiParamTypeClasses + ExtendedDefaultRules -------------------------------------+------------------------------------- Reporter: amindfv | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2816 Wiki Page: | -------------------------------------+------------------------------------- Comment (by amindfv): By the way, to get the current code to work we need to add: ` {-# LANGUAGE KindSignatures #-} ` and ` data A (b :: Bool) = A deriving Show ` to testsuite/tests/typecheck/should_compile/T12923.hs and ` import Kind ` to compiler/typecheck/TcSimplify.hs It does regress for Foldable at the moment, as Simon predicted, but in the test case I provided it does in fact work, beautifully! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 10 04:10:41 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Dec 2016 04:10:41 -0000 Subject: [GHC] #9308: nofib fannkuch-redux runs perpetually with -fllvm In-Reply-To: <042.547b78253c22f834191c24f2af1b28cf@haskell.org> References: <042.547b78253c22f834191c24f2af1b28cf@haskell.org> Message-ID: <057.84e22aac34e1577935260871384d86ce@haskell.org> #9308: nofib fannkuch-redux runs perpetually with -fllvm -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler (LLVM) | Version: 7.8.3 Resolution: fixed | Keywords: fannkuch- | redux Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: fannkuch- at runtime | redux Blocked By: 9504 | Blocking: Related Tickets: #5567 | Differential Rev(s): Phab:D2758 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 10 04:55:11 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Dec 2016 04:55:11 -0000 Subject: [GHC] #7206: Implement cheap build In-Reply-To: <046.231132dc13e5eec24b09b65a3836eff3@haskell.org> References: <046.231132dc13e5eec24b09b65a3836eff3@haskell.org> Message-ID: <061.ec9cdbcc01a3beec7f6d81609624e4de@haskell.org> #7206: Implement cheap build -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 7.4.2 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: | -------------------------------------+------------------------------------- Comment (by bgamari): I took another look at this while waiting for a build and I believe I have identified the source of the additional allocations. In particular I looked at the `real/parser` nofib case, which regresses in allocations by about 3% when using `cheapBuild` for `unpack`, {{{ "unpack" [~1] forall a . unpackCString# a = cheapBuild (unpackFoldrCString# a) }}} The issue is replicated with an example as simple as, {{{#!hs module Hi where data Pat = PatVar Id | PatCon Id [Pat] | PatWild | PatTuple [Pat] deriving (Show{-was:Text-}) type Id = String }}} A pattern which occurs quite often in `parser`. Let's consider the code generated for the `PatTuple` branch of `$cshowsPrec` (taken from the output of the phase 1 simplifier pass), {{{#!hs -- Before cheapBuild PatTuple b1 -> case a of { GHC.Types.I# x -> case GHC.Prim.tagToEnum# @ Bool (GHC.Prim.>=# x 11#) of { False -> ++ @ Char lvl (GHC.Show.showList__ @ Pat $cshowList b1 eta); True -> GHC.Types.: @ Char GHC.Show.shows6 (++ @ Char lvl (GHC.Show.showList__ @ Pat $cshowList b1 (GHC.Types.: @ Char GHC.Show.shows4 eta))) } } -- After cheapBuild PatTuple b1 -> let { p :: ShowS p = \ (x :: String) -> GHC.CString.unpackAppendCString# "PatTuple "# (GHC.Show.showList__ @ Pat $cshowList b1 x) } in case a of { GHC.Types.I# x -> case GHC.Prim.tagToEnum# @ Bool (GHC.Prim.>=# x 11#) of { False -> p eta; True -> GHC.Types.: @ Char GHC.Show.shows6 (p (GHC.Types.: @ Char GHC.Show.shows4 eta)) } } }}} We see that after the introduction of `cheapBuild` the `p` binding is no longer inlined. Comparing the output of `dump-inlinings` reveals why, **Before `cheapBuild`** {{{ Considering inlining: p arg infos [ValueArg] interesting continuation BoringCtxt some_benefit True is exp: True is work-free: True guidance IF_ARGS [0] 80 0 discounted size = 60 ANSWER = YES Inlining done: p Inlined fn: \ (x :: GHC.Base.String) -> GHC.Base.++ @ GHC.Types.Char lvl (GHC.Types.: @ GHC.Types.Char GHC.Show.shows5 (GHC.Show.showLitString b1 (GHC.Types.: @ GHC.Types.Char GHC.Show.shows5 x))) Cont: ApplyToVal nodup (GHC.Types.: @ GHC.Types.Char GHC.Show.shows4 x) Stop[BoringCtxt] [GHC.Types.Char] }}} **After `cheapBuild`** {{{ Considering inlining: p arg infos [ValueArg] interesting continuation BoringCtxt some_benefit True is exp: True is work-free: True guidance IF_ARGS [0] 110 0 discounted size = 90 ANSWER = NO }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 10 05:01:56 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Dec 2016 05:01:56 -0000 Subject: [GHC] #11511: Type family producing infinite type accepted as injective In-Reply-To: <048.97d84dbb372812585cd3199cfa06814f@haskell.org> References: <048.97d84dbb372812585cd3199cfa06814f@haskell.org> Message-ID: <063.bffaf70da0379e55b6e7d2a4d17c73c8@haskell.org> #11511: Type family producing infinite type accepted as injective -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Keywords: TypeFamilies, Resolution: | Injective Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): I imagine you have some examples where you need the recursive assumption. For a boring example, imagine converting one (promoted) unary natural number type `data N1 = Z1 | S1 N1` to another `data N2 = Z2 | S2 N2`: {{{ type family F (a :: N1) :: N2 where F Z1 = Z2 F (S1 n) = S2 (F n) }}} That is injective but you need to use the injectivity inductively to prove it. The original example seems fine to me, since you can't prove `F Bool ~ F Char` (you would need both the "infinite type" `[[[...]]]` and an infinitely long proof in order to do so). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 10 09:44:43 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Dec 2016 09:44:43 -0000 Subject: [GHC] #12957: In a record-update construct:ghc-stage2: panic! (the 'impossible' happened) In-Reply-To: <046.4ffe2bf9b6314906faa3602a2a60600d@haskell.org> References: <046.4ffe2bf9b6314906faa3602a2a60600d@haskell.org> Message-ID: <061.20a44a961a9f371a50cfd644cec34be7@haskell.org> #12957: In a record-update construct:ghc-stage2: panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): It is unfortunate the compiler doesn't throw a type error earlier. The warning comes from the desugaring of the record update so it would still be difficult for users to act upon. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 10 13:31:21 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Dec 2016 13:31:21 -0000 Subject: [GHC] #7289: Mingw FPU init not Windows compatible. In-Reply-To: <046.d34d1fd66180608dd1232dbfc9430105@haskell.org> References: <046.d34d1fd66180608dd1232dbfc9430105@haskell.org> Message-ID: <061.36e61b397f4a09dbaec4ffe55f1253b2@haskell.org> #7289: Mingw FPU init not Windows compatible. -------------------------------------+------------------------------------- Reporter: Lennart | Owner: Phyx- Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 7.2.2 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2819 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: upstream => patch * differential: => Phab:D2819 * architecture: x86 => Unknown/Multiple -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 10 14:15:02 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Dec 2016 14:15:02 -0000 Subject: [GHC] #12808: For non-strict code including primitive (Addr#) code, Loop Invariant Code Flow not lifted outside the loop... In-Reply-To: <050.4b8817bb90d50f291df9e28cde0cf9f5@haskell.org> References: <050.4b8817bb90d50f291df9e28cde0cf9f5@haskell.org> Message-ID: <065.1a995bce66de88f6460708f10398305e@haskell.org> #12808: For non-strict code including primitive (Addr#) code, Loop Invariant Code Flow not lifted outside the loop... -------------------------------------+------------------------------------- Reporter: GordonBGood | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: JoinPoints 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: | -------------------------------------+------------------------------------- Comment (by GordonBGood): Replying to [comment:14 simonpj]: > ... > In SLOW, `nxtc` is represented by a heap-allocated closure, whereas in FAST `nxtc` is a join point, and hence not allocated at all (you can see that from the `let-no-escape` in the STG). See our paper [https://www.microsoft.com/en-us/research/publication/compiling-without- continuations/ Compiling without continuations], and [wiki:SequentCore]. Yes, I saw that. > Notice that in SLOW, the call to `nxtc s` is ''followed by'' a call to `nxtp (p+1)`. But in FAST we move that call right into `nxtc` itself, in the return branch of the `if`. That's what makes `nxtc` into a join point. I had wondered if the work on join points might help here... > (None of this has anything to do with non-strictness, incidentally.) I just wondered if strictness might be a clue, as the FAST version consumes very low heap, whereas the SLOW version takes an amount of heap which is about the calculated amount for numLOOPS times the number of primes culled... > This is a rather non-trivial transformation. You clearly think it's a pretty obvious optimisation, but it doesn't look obvious to me. No, I didn't think it was trivial, just that the optimisation gets triggered in the one case; I couldn't see why it couldn't be extended to the other... > Happily, though, our new Core-with-join-point (described in the paper) should catch this nicely. If we start with SLOW, after a bit we'll get this > {{{ > let nxtc c s = if c > top > then (# s,c #) > else case ... of (# s',p #) -> nxtc (c+p) s' } > in case nxtc ss s of > (# s', r #) -> nxtp (p + 1) s' } > }}} > Now if we do float-in, to move the `let nxtc` in to the scruintee of the case, it becomes a join point, and join-point analysis should find it. After that, the transformations in the paper will turn it into FAST. > > The example in comment:10 looks similar: > {{{ > case doit adr# sp# of sd# -> cullp (p + 2) sd# in cullp 1 s4# }}}}} > }}} > Here again, `doit` will become a join point if we float it in. The example in the Descrption is too big for me to analyse. Don't worry about the big example in the description as if the small example in comment 10 and this latest example in comment 12 get fixed, I'm pretty sure it will take core of that larger case too. > I've cc'd Luke Maurer who is implementing Core with join points; this looks like another good example. (cf #12781) That is encouraging news the the Join Point Analysis should catch this. Thanks for looking at this, as I think it important in many cases beyond this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 10 14:38:53 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Dec 2016 14:38:53 -0000 Subject: [GHC] #12942: Add infix flag for class and data declarations In-Reply-To: <044.ad2a88252aaa49d53b0869c522534f50@haskell.org> References: <044.ad2a88252aaa49d53b0869c522534f50@haskell.org> Message-ID: <059.42bd7cb3456c751c873ba3c35f2f830d@haskell.org> #12942: Add infix flag for class and data declarations -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #3384 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alanz): And it seems the `HasOccName` constraint is also required for `pprMinimalSig`, via {{{#!hs pprBooleanFormulaNormal :: (Outputable a, HasOccName a) => BooleanFormula a -> SDoc pprBooleanFormulaNormal = go where go (Var x) = pprPrefixVar (isSymOcc (occName x)) (ppr x) ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 10 18:04:58 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Dec 2016 18:04:58 -0000 Subject: [GHC] #12958: Properly detect if GHCi is running in MinTTY Message-ID: <050.37d9b9b784581d8321a5359fbb9fb60c@haskell.org> #12958: Properly detect if GHCi is running in MinTTY -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: GHCi | Version: 8.0.1 Keywords: | Operating System: Windows Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Since the user experience of GHCi is known to be rather poor when run in MinTTY (e.g., see #12720), GHCi emits a warning when it thinks it's being run in a terminal that uses MinTTY (such as Cygwin or MSYS2). [http://git.haskell.org/ghc.git/blob/17ac9b19438d5e8f6de33f99828e8c0e7c8c1129:/driver/ghci/ghci.c#l18 Here] is the code that checks for this in `ghci.c`: {{{#!c if (getenv("_")) { printf("WARNING: GHCi invoked via 'ghci.exe' in *nix-like shells (cygwin-bash, in particular)\n"); printf(" doesn't handle Ctrl-C well; use the 'ghcii.sh' shell wrapper instead\n"); fflush(stdout); } }}} This is a rather shoddy way to detect MinTTY's presence, however. It's quite easy to define an environmental variable named `_` in terminals that don't use MinTTY (e.g., ConEmu). After seeing Phab:D2809, I learned of a much more reliable way to detect for MinTTY's presence: {{{#!hs queryCygwinTerminal :: Win32.HANDLE -> IO Bool queryCygwinTerminal h = do fileType <- Win32.getFileType h if fileType /= Win32.fILE_TYPE_PIPE then pure False else do fn <- getFileNameByHandle h pure (("\\cygwin-" `isPrefixOf` fn || "\\msys-" `isPrefixOf` fn) && "-pty" `isInfixOf` fn && "-master" `isSuffixOf` fn) `catch` \ (_ :: IOError) -> pure False getFileNameByHandle :: Win32.HANDLE -> IO String getFileNameByHandle h = do let sizeOfDWORD = sizeOf (undefined :: Win32.DWORD) let sizeOfWchar = sizeOf (undefined :: CWchar) -- note: implicitly assuming that DWORD has stronger alignment than wchar_t let bufSize = sizeOfDWORD + mAX_PATH * sizeOfWchar allocaBytes bufSize $ \ buf -> do getFileInformationByHandleEx h fileNameInfo buf (fromIntegral bufSize) len :: Win32.DWORD <- peek buf let len' = fromIntegral len `div` sizeOfWchar peekCWStringLen (buf `plusPtr` sizeOfDWORD, min len' mAX_PATH) getFileInformationByHandleEx :: Win32.HANDLE -> CInt -> Ptr a -> Win32.DWORD -> IO () getFileInformationByHandleEx h cls buf bufSize = do lib <- Win32.getModuleHandle (Just "kernel32.dll") ptr <- Win32.getProcAddress lib "GetFileInformationByHandleEx" let c_GetFileInformationByHandleEx = mk_GetFileInformationByHandleEx (castPtrToFunPtr ptr) Win32.failIfFalse_ "getFileInformationByHandleEx" (c_GetFileInformationByHandleEx h cls buf bufSize) type F_GetFileInformationByHandleEx a = Win32.HANDLE -> CInt -> Ptr a -> Win32.DWORD -> IO Win32.BOOL foreign import WINAPI "dynamic" mk_GetFileInformationByHandleEx :: FunPtr (F_GetFileInformationByHandleEx a) -> F_GetFileInformationByHandleEx a }}} We should port this to C and use this in `ghci.c` instead of what we have now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 10 20:41:24 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Dec 2016 20:41:24 -0000 Subject: [GHC] #12808: For closures, Loop Invariant Code Flow not lifted outside the loop... (was: For non-strict code including primitive (Addr#) code, Loop Invariant Code Flow not lifted outside the loop...) In-Reply-To: <050.4b8817bb90d50f291df9e28cde0cf9f5@haskell.org> References: <050.4b8817bb90d50f291df9e28cde0cf9f5@haskell.org> Message-ID: <065.a080140d61b097bd05987415dec2abbf@haskell.org> #12808: For closures, Loop Invariant Code Flow not lifted outside the loop... -------------------------------------+------------------------------------- Reporter: GordonBGood | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: JoinPoints 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: | -------------------------------------+------------------------------------- Description changed by GordonBGood: @@ -12,3 +12,5 @@ - '''Shortest possible test code that clearly shows non-strict code not - being optimized, but optimized when made strict:''' Please refer directly - to comment 12https://ghc.haskell.org/trac/ghc/ticket/12808#comment:12, + '''Shortest possible test code that clearly shows closures not being + optimized, but optimized when unified by a "join point":''' Please refer + directly to comment + 12https://ghc.haskell.org/trac/ghc/ticket/12808#comment:12 and follow-on + comments. New description: '''Background:''' I've been intrigued investigating whether GHC can produce code "as fast as Cee (C/C++/Rust/etc.)" by-any-means-possible, and have been using the very tight inner composite culling loops (purely integer operations) of a basic Sieve of Eratosthenes implementation as a test vehicle. '''Synopsis:''' This is a follow-on of the work leading to finding the efficiency problem described in ticket #12798, but involves pushing the speed even further as per the method described for "primesieve" as per [http://primesieve.org/] in the "Highly optimized inner loop" section. '''Shortest possible test code that clearly shows closures not being optimized, but optimized when unified by a "join point":''' Please refer directly to comment 12https://ghc.haskell.org/trac/ghc/ticket/12808#comment:12 and follow-on comments. '''A version of test code that triggered this ticket:''' Essentially, this method involves extreme loop unrolling with very imperative code although coded functionally; in the case of the following code it means that, recognizing that for all odd primes (which they all are other than two), and that all word sizes are of an even number of bits, there will be a repeating pattern of composite number culls that repeats every word size number of bits. Thus for a word size of one eight-bit byte, we can unroll to eight composite culls in the body of one loop, with loops cases for the primes modulo 8 of 1, 3, 5, and 7, and for the eight bit start positions (b0..b7) meaning there are four times eight is 32 loop cases. When there are no longer a full eight culls left, the culling reverts to conventional single-cull-per-loop as per the test program of ticket #12798. To do this using GHC we need pointer arithmetic, and the only way to implement pointer arithmetic in GHC is to use the Addr# primitive. GHC/Haskell has one other slight overhead over Cee languages in that we need to move the culling array to a pinned array to avoid having it moved while the culling is going on and then move it back when finished but this takes a negligible amount of time (one percent or so) as compared to the culling. As usual for test programs, the culling operations are repeated in a loop for a number of times to give more accurate timing not influenced by execution not related to the culling. All of this is included in the following code (truncated as to loop coses for inclusion here): {{{#!hs -- EfficiencyBug.hs -- showing that there is a register loop invariant bug in generation of assembler code... -- LLVM shows the bug clearer since the code is generally a little faster... {-# LANGUAGE FlexibleContexts, BangPatterns, MagicHash, UnboxedTuples #-} {-# OPTIONS_GHC -O2 -rtsopts -keep-s-files #-} -- or -O2 -fllvm import Data.Word import Data.Bits import Data.Array.ST (runSTUArray) import Data.Array.Base import GHC.ST ( ST(..) ) import GHC.Exts numLOOPS = 10000 :: Int -- Uses a very simple Sieve of Eratosthenes for fixed 2 ^ 18 range (so one L1 cache size) to prove it. twos :: UArray Int Word32 twos = listArray (0, 31) [1 `shiftL` i | i <- [0 .. 31]] soep1 :: () -> [Word32] soep1() = 2 : [fromIntegral i * 2 + 3 | (i, False) <- assocs bufb] where bufb = runSTUArray $ do let bfBts = (256 * 1024) `div` 2 -- to 2^18 + 2 is 128 KBits = 16 KBytes bf <- newArray (0, bfBts - 1) False :: ST s (STUArray s Int Bool) cullb bf cullb bf@(STUArray l u n marr#) = ST $ \s0# -> case getSizeofMutableByteArray# marr# s0# of { (# s1#, n# #) -> let loop t mr# s0# = -- cull a number of times to test timing if t <= 0 then (# s0#, STUArray l u n mr# #) else case getSizeofMutableByteArray# mr# s0# of { (# s1#, n# #) -> case newPinnedByteArray# n# s1# of { (# s2#, marr'# #) -> case copyMutableByteArray# mr# 0# marr'# 0# n# s2# of { s3# -> case unsafeFreezeByteArray# marr'# s3# of { (# s4#, arr# #) -> -- must do this case byteArrayContents# arr# of { adr# -> -- to obtain the addr# here let cullp i@(I# i#) sp# = let !p@(I# p#) = i + i + 3 in let !s@(I# s#) = (p * p - 3) `div` 2 in if s >= n then case copyMutableByteArray# marr'# 0# mr# 0# n# sp# of so# -> (# so#, mr# #) else let !(UArray _ _ _ tarr#) = twos in case readWord64Array# marr# (i# `uncheckedIShiftRL#` 6#) sp# of { (# sp0#, v0# #) -> case (v0# `and#` ((int2Word# 1#) `uncheckedShiftL#` (i# `andI#` 63#))) `eqWord#` (int2Word# 0#) of 0# -> cullp (i + 1) sp0# -- not prime _ -> -- is prime -- most program execution time spent in the following tight loops. -- the following code implments extream loop unrolling... let !pi@(I# pi#) = fromIntegral p in let !sw@(I# sw#) = s `shiftR` 3 in let !sb@(I# sb#) = s .&. 7 in let p1 = sb + pi in let !(I# r1#) = p1 `shiftR` 3 in let p2 = p1 + pi in let !(I# r2#) = p2 `shiftR` 3 in let p3 = p2 + pi in let !(I# r3#) = p3 `shiftR` 3 in let p4 = p3 + pi in let !(I# r4#) = p4 `shiftR` 3 in let p5 = p4 + pi in let !(I# r5#) = p5 `shiftR` 3 in let p6 = p5 + pi in let !(I# r6#) = p6 `shiftR` 3 in let p7 = p6 + pi in let !(I# r7#) = p7 `shiftR` 3 in let !lmt@(I# lmt#) = (fromIntegral n `shiftR` 3) - p7 in let !lmt1# = plusAddr# adr# lmt# in let !strt# = plusAddr# adr# sw# in let !(I# n#) = n in let (# !so#, !sco# #) = case ((((p - 1) `div` 2) .&. 3) `shiftL` 3) + sb of { 0 -> let cull c# sp# = case c# `ltAddr#` lmt1# of 0# -> (# c#, sp# #) _ -> case readWord8OffAddr# c# 0# sp# of { (# sp0#, v0# #) -> case writeWord8OffAddr# c# 0# (v0# `or#` (int2Word# 1#)) sp0# of { sp1# -> case readWord8OffAddr# c# r1# sp1# of { (# sp2#, v1# #) -> case writeWord8OffAddr# c# r1# (v1# `or#` (int2Word# 2#)) sp2# of { sp3# -> case readWord8OffAddr# c# r2# sp3# of { (# sp4#, v2# #) -> case writeWord8OffAddr# c# r2# (v2# `or#` (int2Word# 4#)) sp4# of { sp5# -> case readWord8OffAddr# c# r3# sp5# of { (# sp6#, v3# #) -> case writeWord8OffAddr# c# r3# (v3# `or#` (int2Word# 8#)) sp6# of { sp7# -> case readWord8OffAddr# c# r4# sp7# of { (# sp8#, v4# #) -> case writeWord8OffAddr# c# r4# (v4# `or#` (int2Word# 16#)) sp8# of { sp9# -> case readWord8OffAddr# c# r5# sp9# of { (# sp10#, v5# #) -> case writeWord8OffAddr# c# r5# (v5# `or#` (int2Word# 32#)) sp10# of { sp11# -> case readWord8OffAddr# c# r6# sp11# of { (# sp12#, v6# #) -> case writeWord8OffAddr# c# r6# (v6# `or#` (int2Word# 64#)) sp12# of { sp13# -> case readWord8OffAddr# c# r7# sp13# of { (# sp14#, v7# #) -> case writeWord8OffAddr# c# r7# (v7# `or#` (int2Word# 128#)) sp14# of { sp15# -> cull (plusAddr# c# pi#) sp15# }}}}}}}}}}}}}}}} in cull strt# sp0#; 1 -> let cull c# sp# = case c# `ltAddr#` lmt1# of 0# -> (# c#, sp# #) _ -> case readWord8OffAddr# c# 0# sp# of { (# sp0#, v0# #) -> case writeWord8OffAddr# c# 0# (v0# `or#` (int2Word# 2#)) sp0# of { sp1# -> case readWord8OffAddr# c# r1# sp1# of { (# sp2#, v1# #) -> case writeWord8OffAddr# c# r1# (v1# `or#` (int2Word# 4#)) sp2# of { sp3# -> case readWord8OffAddr# c# r2# sp3# of { (# sp4#, v2# #) -> case writeWord8OffAddr# c# r2# (v2# `or#` (int2Word# 8#)) sp4# of { sp5# -> case readWord8OffAddr# c# r3# sp5# of { (# sp6#, v3# #) -> case writeWord8OffAddr# c# r3# (v3# `or#` (int2Word# 16#)) sp6# of { sp7# -> case readWord8OffAddr# c# r4# sp7# of { (# sp8#, v4# #) -> case writeWord8OffAddr# c# r4# (v4# `or#` (int2Word# 32#)) sp8# of { sp9# -> case readWord8OffAddr# c# r5# sp9# of { (# sp10#, v5# #) -> case writeWord8OffAddr# c# r5# (v5# `or#` (int2Word# 64#)) sp10# of { sp11# -> case readWord8OffAddr# c# r6# sp11# of { (# sp12#, v6# #) -> case writeWord8OffAddr# c# r6# (v6# `or#` (int2Word# 128#)) sp12# of { sp13# -> case readWord8OffAddr# c# r7# sp13# of { (# sp14#, v7# #) -> case writeWord8OffAddr# c# r7# (v7# `or#` (int2Word# 1#)) sp14# of { sp15# -> cull (plusAddr# c# pi#) sp15# }}}}}}}}}}}}}}}} in cull strt# sp0#; -- and so on for 30 more cases... _ -> (# strt#, sp0# #) {- normally never taken case, all cases covered -} } in let !ns# = ((minusAddr# so# adr#) `uncheckedIShiftL#` 3#) +# sb# in -- extreme loop unrolling ends here; remaining primes culled conventionally... let cull j# sc# = -- very tight inner loop case j# <# n# of 0# -> cullp (i + 1) sc# _ -> let i# = j# `andI#` 31# in let !sh# = indexWord32Array# tarr# i# in -- (1 `shiftL` (j .&. 31))) let w# = j# `uncheckedIShiftRL#` 5# in case readWord32Array# marr'# w# sc# of { (# sc0#, ov# #) -> case writeWord32Array# marr'# w# (ov# `or#` sh#) sc0# of { sc1# -> cull (j# +# pi#) sc1# }} in cull ns# sp0# } in case cullp 0 s4# of (# sp#, mrp# #) -> loop (t - 1) mrp# sp# }}}}} in loop numLOOPS marr# s1# } main = print $ length $ soep1() }}} '''The problem:''' The problem is in the innermost loop of the cases, for which case "0" the following assembly code (using -fllvm) is produced: {{{ seGU_info$def: # BB#0: # %cgRL cmpq %r14, 70(%rbx) jbe .LBB35_1 .align 16, 0x90 .LBB35_2: # %cgRJ # =>This Inner Loop Header: Depth=1 movq 14(%rbx), %rcx movq 22(%rbx), %rdx movq 30(%rbx), %rsi movq 38(%rbx), %rdi movq 46(%rbx), %r8 movq 54(%rbx), %r9 movq 62(%rbx), %r10 movq 6(%rbx), %rax addq %r14, %rax orb $1, (%r14) orb $2, (%rcx,%r14) orb $4, (%rdx,%r14) orb $8, (%rsi,%r14) orb $16, (%rdi,%r14) orb $32, (%r8,%r14) orb $64, (%r9,%r14) orb $-128, (%r10,%r14) cmpq 70(%rbx), %rax movq %rax, %r14 jb .LBB35_2 jmp .LBB35_3 .LBB35_1: movq %r14, %rax .LBB35_3: # %cgRK movq (%rbp), %rcx movq %rax, %rbx rex64 jmpq *%rcx # TAILCALL }}} One can readily see that the compiler is not lifting the Loop Invariant Code Flow as in initializing the registers to outside the inner loop, meaning there are many register loads from memory which are not necessary. '''Desired results:''' The desired assembly code is something like the following, which is similar to what is produced by Cee (C/C++/Rust/etc.): {{{ seGU_info$def: # BB#0: # %cgRL movq 14(%rbx), %rcx movq 22(%rbx), %rdx movq 30(%rbx), %rsi movq 38(%rbx), %rdi movq 46(%rbx), %r8 movq 54(%rbx), %r9 movq 62(%rbx), %r10 movq 6(%rbx), %rax movq 70(%rbx), %rbx cmpq %r14, %rbx # rbx clobbered here, but old value jbe .LBB35_1 # never used again until replaced after loop .align 16, 0x90 .LBB35_2: # %cgRJ # =>This Inner Loop Header: Depth=1 orb $1, (%r14) orb $2, (%rcx,%r14) orb $4, (%rdx,%r14) orb $8, (%rsi,%r14) orb $16, (%rdi,%r14) orb $32, (%r8,%r14) orb $64, (%r9,%r14) orb $-128, (%r10,%r14) addq %rax, %r14 cmpq %rbx, %r14 jb .LBB35_2 jmp .LBB35_3 .LBB35_1: movq %r14, %rax .LBB35_3: # %cgRK movq (%rbp), %rcx movq %rax, %rbx # rbx clobbered here anyway rex64 jmpq *%rcx # TAILCALL }}} '''Full testing:''' The actual unrolled loop code including all the case loops is too long to post here, but to verify the result is correct (23000) and the performance, the full actual file is attached here. Due to the magic of modern CPU instruction fusion and Out Of Order (OOE) execution, the code is not as slow as it would indicate by the number of increased instructions, but while it is about twice as fast as when culled conventionally (Intel Skylake), it is about half again as slow as Cee. On an Intel Sky Lake i5-6500 (running at 3.5 GHz for single threading), this takes about one second, about two seconds culled conventionally, but only about 0.6 seconds for Rust/LLVM (with the assembly code output essentially identical to the "desired" code). '''Other back ends and targets:''' Although the code generated by the native NCG has other problems (not moving the loop test to the end of the loop to avoid one jump, and not combining the read and modify and store instructions into the single available instruction), it exhibits the same problem as to not lifting the Loop Invariant Code Flow register initialization. Although this code is x86_64, the problem also applies to x86 code even though the x86 architecture doesn't have enough registers to do this in one loop and needs to be split into two loops culling only four composites per loop, but there still is a significant gain in speed. Although not tested, it probably also applies to other targets such as ARM (which has many general purpose registers). '''Conclusion:''' The use of Addr# primitives is probably not a frequent use case, but as shown here that when one needs their use, they should be efficient. I considered that GHC may intentionally limit the performance of these unsafe primitives to limit their use unless absolutely necessary as in marshalling, something as C# does for the use of unsafe pointers, but surely GHC would not do that as the target programmers are different. '''If this and ticket #12798 were fixed, for this use case the GHC code would be within a percent or two of the performance of Cee.''' -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 10 21:14:26 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Dec 2016 21:14:26 -0000 Subject: [GHC] #12871: Upgrade Mingw-w64 bindist for GHC to GCC 6.2.0 and Binutils 2.27.2 In-Reply-To: <044.3b0884ef0bcd4a4b9bcf5d4f10c21a66@haskell.org> References: <044.3b0884ef0bcd4a4b9bcf5d4f10c21a66@haskell.org> Message-ID: <059.6a77ecd85d33e7f95211bcf77026af37@haskell.org> #12871: Upgrade Mingw-w64 bindist for GHC to GCC 6.2.0 and Binutils 2.27.2 -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: task | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2749 Wiki Page: | Phab:D2810 -------------------------------------+------------------------------------- Comment (by Tamar Christina ): In [changeset:"490b9429a8ed3c55d17bf0964fb14582eb206a3d/ghc" 490b942/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="490b9429a8ed3c55d17bf0964fb14582eb206a3d" Automate GCC driver wrapper Summary: Everytime we upgrade the GCC version this wrapper needed updating. This is a big fragile and we kept forgetting it. Instead automate it so we don't have to worry about it. Test Plan: ./validate Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D2820 GHC Trac Issues: #12871 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 10 21:49:34 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Dec 2016 21:49:34 -0000 Subject: [GHC] #12708: RFC: Representation polymorphic Num In-Reply-To: <051.e9ad721b0c060306ebd4bf7d4de38fdd@haskell.org> References: <051.e9ad721b0c060306ebd4bf7d4de38fdd@haskell.org> Message-ID: <066.b9cb801b07967834a42fc2b5f95eb151@haskell.org> #12708: RFC: Representation polymorphic Num -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.1 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Replying to [comment:22 goldfire]: > I still believe this is a great idea and would welcome a formal proposal about this. [https://github.com/ghc-proposals/ghc-proposals/pull/30 Done]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 10 23:22:20 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Dec 2016 23:22:20 -0000 Subject: [GHC] #12942: Add infix flag for class and data declarations In-Reply-To: <044.ad2a88252aaa49d53b0869c522534f50@haskell.org> References: <044.ad2a88252aaa49d53b0869c522534f50@haskell.org> Message-ID: <059.4ec42ea6224156e5d274c95f79fbb843@haskell.org> #12942: Add infix flag for class and data declarations -------------------------------------+------------------------------------- Reporter: alanz | Owner: mpickering Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #3384 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * owner: alanz => mpickering Comment: I didn't notice this before but there is something wrong with this constraint and we should clean it up before someone forgets. The first thing which is wrong is that it already nearly exists in GHC and is called `NamedThing`, so we should just try to use that rather than this new class. The second thing, in both cases it is used to check whether a variable is an infix operator or not and then either calls `pprInfixOcc` or `pprPrefixOcc`. It would seem better to add a new method to `OutputableBndr` which also does this check rather than do it every time we need to know. Something like `pprInPos :: (SDoc -> SDoc) -> (SDoc -> SDoc) -> SDoc` where the two continuations describe how to deal with the two cases that the indentified is infix or prefix might be better. Another very good question is why `pprBooleanFormulaNormal` isn't parametrised by `OutputableBndr` as well when it very clearly outputs `Bndr`s. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 10 23:32:43 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Dec 2016 23:32:43 -0000 Subject: [GHC] #12708: RFC: Representation polymorphic Num In-Reply-To: <051.e9ad721b0c060306ebd4bf7d4de38fdd@haskell.org> References: <051.e9ad721b0c060306ebd4bf7d4de38fdd@haskell.org> Message-ID: <066.19d1a1cf808036fc4a24e320a245fe26@haskell.org> #12708: RFC: Representation polymorphic Num -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.1 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by carter): Replying to [comment:22 goldfire]: > I still believe this is a great idea and would welcome a formal proposal about this. I also still believe that this is something better done in a library for a release or so before we start mucking with something so fundamental. There's nothing about this that cannot be done in a library (modulo `RebindableSyntax`). I agree with richard, experimental changes to the core num prelude, especially those using still new constructs should happen in userland first. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 10 23:33:43 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Dec 2016 23:33:43 -0000 Subject: [GHC] #12942: Add infix flag for class and data declarations In-Reply-To: <044.ad2a88252aaa49d53b0869c522534f50@haskell.org> References: <044.ad2a88252aaa49d53b0869c522534f50@haskell.org> Message-ID: <059.5005d125ba4af7067935524891e941e4@haskell.org> #12942: Add infix flag for class and data declarations -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #3384 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * owner: mpickering => alanz -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 11 00:44:19 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Dec 2016 00:44:19 -0000 Subject: [GHC] #12959: GHC doesn't warn about missing implementations for class methods beginning with an underscore Message-ID: <050.f1c049718f4b94fba939144b405d48bc@haskell.org> #12959: GHC doesn't warn about missing implementations for class methods beginning with an underscore -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This code compiles without any warnings! {{{#!hs {-# OPTIONS_GHC -Wmissing-methods #-} module Bug where class Foo a where _Bar :: a -> Int instance Foo Int }}} This code, however, //does// emit a warning: {{{#!hs {-# OPTIONS_GHC -Wmissing-methods #-} module Warns where class Foo a where bBar :: a -> Int instance Foo Int }}} {{{ Bug.hs:7:10: warning: [-Wmissing-methods] • No explicit implementation for ‘bBar’ • In the instance declaration for ‘Foo Int’ }}} The only difference is in the name of the class method of `Foo`. Namely, when a class method is prefixed with an underscore, GHC seems to look the other way when checking if any instances are missing an implementation of it. I'd argue that this behavior is incorrect, since I can't envision any scenario in which you'd want the compiler //not// to warn you about missing method implementations (as opposed to, say, not warning about an unused record selector). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 11 00:49:52 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Dec 2016 00:49:52 -0000 Subject: [GHC] #12923: MultiParamTypeClasses + ExtendedDefaultRules In-Reply-To: <046.9ae3ec8e366c95f2b64ecec80ccef95a@haskell.org> References: <046.9ae3ec8e366c95f2b64ecec80ccef95a@haskell.org> Message-ID: <061.0fff5614ec6b75f72af15c10c7cd037f@haskell.org> #12923: MultiParamTypeClasses + ExtendedDefaultRules -------------------------------------+------------------------------------- Reporter: amindfv | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2816 Wiki Page: | -------------------------------------+------------------------------------- Comment (by amindfv): I've got both `*` and `* -> *` (test T10971a) defaulting working with: https://phabricator.haskell.org/D2822 Let me know how it looks. Thanks -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 11 01:10:20 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Dec 2016 01:10:20 -0000 Subject: [GHC] #12959: GHC doesn't warn about missing implementations for class methods beginning with an underscore In-Reply-To: <050.f1c049718f4b94fba939144b405d48bc@haskell.org> References: <050.f1c049718f4b94fba939144b405d48bc@haskell.org> Message-ID: <065.606aa1158e67e6abc2d906fdebc72acb@haskell.org> #12959: GHC doesn't warn about missing implementations for class methods beginning with an underscore -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by RyanGlScott: @@ -26,1 +26,1 @@ - Bug.hs:7:10: warning: [-Wmissing-methods] + Warn.hs:7:10: warning: [-Wmissing-methods] New description: This code compiles without any warnings! {{{#!hs {-# OPTIONS_GHC -Wmissing-methods #-} module Bug where class Foo a where _Bar :: a -> Int instance Foo Int }}} This code, however, //does// emit a warning: {{{#!hs {-# OPTIONS_GHC -Wmissing-methods #-} module Warns where class Foo a where bBar :: a -> Int instance Foo Int }}} {{{ Warn.hs:7:10: warning: [-Wmissing-methods] • No explicit implementation for ‘bBar’ • In the instance declaration for ‘Foo Int’ }}} The only difference is in the name of the class method of `Foo`. Namely, when a class method is prefixed with an underscore, GHC seems to look the other way when checking if any instances are missing an implementation of it. I'd argue that this behavior is incorrect, since I can't envision any scenario in which you'd want the compiler //not// to warn you about missing method implementations (as opposed to, say, not warning about an unused record selector). -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 11 01:17:20 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Dec 2016 01:17:20 -0000 Subject: [GHC] #12959: GHC doesn't warn about missing implementations for class methods beginning with an underscore In-Reply-To: <050.f1c049718f4b94fba939144b405d48bc@haskell.org> References: <050.f1c049718f4b94fba939144b405d48bc@haskell.org> Message-ID: <065.7388f3f489257000110cd331677251e3@haskell.org> #12959: GHC doesn't warn about missing implementations for class methods beginning with an underscore -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I believe I've found [http://git.haskell.org/ghc.git/blob/490b9429a8ed3c55d17bf0964fb14582eb206a3d:/compiler/typecheck/TcClassDcl.hs#l283 the function] that's responsible for this behavior: {{{#!hs tcClassMinimalDef :: Name -> [LSig Name] -> [TcMethInfo] -> TcM ClassMinimalDef tcClassMinimalDef _clas sigs op_info = case findMinimalDef sigs of Nothing -> return defMindef Just mindef -> do -- Warn if the given mindef does not imply the default one -- That is, the given mindef should at least ensure that the -- class ops without default methods are required, since we -- have no way to fill them in otherwise whenIsJust (isUnsatisfied (mindef `impliesAtom`) defMindef) $ (\bf -> addWarnTc NoReason (warningMinimalDefIncomplete bf)) return mindef where -- By default require all methods without a default -- implementation whose names don't start with '_' defMindef :: ClassMinimalDef defMindef = mkAnd [ noLoc (mkVar name) | (name, _, Nothing) <- op_info , not (startsWithUnderscore (getOccName name)) ] }}} Notice that `defMindef` deliberately discards method names that begin with an underscore. So fixing this ticket would be a simple matter of removing that line. That being said, I'm worried that there's a comment in this code explicitly calling out the case in which a method's name begins with `_`. Is there a story behind this comment? (e.g., did someone ask for this to be the case?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 11 01:25:22 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Dec 2016 01:25:22 -0000 Subject: [GHC] #12959: GHC doesn't warn about missing implementations for class methods beginning with an underscore In-Reply-To: <050.f1c049718f4b94fba939144b405d48bc@haskell.org> References: <050.f1c049718f4b94fba939144b405d48bc@haskell.org> Message-ID: <065.314e4eec977005b497fa50765bc5b372@haskell.org> #12959: GHC doesn't warn about missing implementations for class methods beginning with an underscore -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: simonpj (added) Comment: At the very least, I've found the commit ( http://git.haskell.org/ghc.git/commit/96f33e63fe913298becbef33bf95daee98fbe44d ) all the way back from 2001 which introduced this quirk: {{{ From 96f33e63fe913298becbef33bf95daee98fbe44d Mon Sep 17 00:00:00 2001 From: unknown Date: Tue, 24 Sep 2013 20:01:31 +0100 Subject: [PATCH] Move defaultClassMinimalDef from BuildTyCl to TcClassDcl Simple refactoring. Also in Vectorise.Types/TyConDecl, simply propagate the classMinimalDef from the class we are vectorising. Simpler and more direct. --- compiler/iface/BuildTyCl.lhs | 12 +----------- compiler/typecheck/TcClassDcl.lhs | 18 +++++++++++++----- compiler/vectorise/Vectorise/Type/TyConDecl.hs | 4 ++-- 3 files changed, 16 insertions(+), 18 deletions(-) }}} Simon, do you remember why you made this change? The commit description doesn't really allude to it (other than "Simple refactoring"). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 11 02:04:15 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Dec 2016 02:04:15 -0000 Subject: [GHC] #12809: TYPE 'UnboxedTupleRep is still a lie In-Reply-To: <047.e76db1a74f10a41a50c71596cd333981@haskell.org> References: <047.e76db1a74f10a41a50c71596cd333981@haskell.org> Message-ID: <062.9b6c1ae2ae7d6c4aa61f8597f4aa0f12@haskell.org> #12809: TYPE 'UnboxedTupleRep is still a lie -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): See also: https://github.com/ghc-proposals/ghc-proposals/pull/29 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 11 02:24:51 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Dec 2016 02:24:51 -0000 Subject: [GHC] #12784: Typechecker regression in GHC 8.0.2 involving DefaultSignatures In-Reply-To: <050.9a0edf2bdaab8860178dd08e2e10d2b7@haskell.org> References: <050.9a0edf2bdaab8860178dd08e2e10d2b7@haskell.org> Message-ID: <065.eb3215b11c0e48b6c7a80d501f504fc8@haskell.org> #12784: Typechecker regression in GHC 8.0.2 involving DefaultSignatures -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: merge Priority: highest | Milestone: 8.0.2 Component: Compiler | Version: 8.0.2-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #12918 | Differential Rev(s): Phab:D2682, Wiki Page: | Phab:D2786 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * version: 8.1 => 8.0.2-rc1 * milestone: 8.2.1 => 8.0.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 11 02:31:07 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Dec 2016 02:31:07 -0000 Subject: [GHC] #12808: For closures, Loop Invariant Code Flow related to captured free values not lifted outside the loop... (was: For closures, Loop Invariant Code Flow not lifted outside the loop...) In-Reply-To: <050.4b8817bb90d50f291df9e28cde0cf9f5@haskell.org> References: <050.4b8817bb90d50f291df9e28cde0cf9f5@haskell.org> Message-ID: <065.19461203bf205e07b3df63a3b6b00980@haskell.org> #12808: For closures, Loop Invariant Code Flow related to captured free values not lifted outside the loop... -------------------------------------+------------------------------------- Reporter: GordonBGood | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: JoinPoints 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: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 11 14:43:44 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Dec 2016 14:43:44 -0000 Subject: [GHC] #876: Length is not a good consumer In-Reply-To: <054.b373028d5cb568a8380002fb5d2d74f4@haskell.org> References: <054.b373028d5cb568a8380002fb5d2d74f4@haskell.org> Message-ID: <069.d0009242bb7bc0348055185015e66390@haskell.org> #876: Length is not a good consumer -------------------------------------+------------------------------------- Reporter: ariep@… | Owner: Type: bug | Status: new Priority: lowest | Milestone: 7.6.2 Component: libraries/base | Version: 6.5 Resolution: | Keywords: length Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | perf/should_run/T876 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by George): * status: closed => new * resolution: fixed => Comment: I believe this has regressed. {{{ length [0..10] 11 it :: Int (0.11 secs, 85,536 bytes) Prelude> length [0..(10^7)] 10000001 it :: Int (0.25 secs, 720,084,176 bytes) Prelude> }}} My guess, fwiw, is that this is connected with AMP, making list an instance of Foldable and the issue that rewrite rules cannot be applied to class methods as discussed in recent emails between Conal and SimonPJ. I think the current priority of lowest is correct but thought it worth noting that the problem still exists. Also I think that the user's guide does not accurately reflect the state of list fusion, i.e. https://ghc.haskell.org/trac/ghc/ticket/915. The User's Guide, section 9.32.6 states "This list could readily be extended; if there are Prelude functions that you use a lot which are not included, please tell us." As this bug and ticket 915 indicates extending the list is not always easy. I can file a doc bug if people would like. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 11 14:47:46 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Dec 2016 14:47:46 -0000 Subject: [GHC] #915: Implement list fusion using streams instead of foldr/build In-Reply-To: <046.37416aee19ee095c9a6e98285b215b72@haskell.org> References: <046.37416aee19ee095c9a6e98285b215b72@haskell.org> Message-ID: <061.44d19b654afc9d9819325daae6af78bc@haskell.org> #915: Implement list fusion using streams instead of foldr/build -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: task | Status: closed Priority: normal | Milestone: 7.6.1 Component: libraries/base | Version: 6.8 Resolution: invalid | Keywords: fusion Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: N/A Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by George): Given the preceding comment by Duncan does it make sense to reopen this as a potential task? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 11 15:05:09 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Dec 2016 15:05:09 -0000 Subject: [GHC] #876: Length is not a good consumer In-Reply-To: <054.b373028d5cb568a8380002fb5d2d74f4@haskell.org> References: <054.b373028d5cb568a8380002fb5d2d74f4@haskell.org> Message-ID: <069.fcb57596958d6b091ac3cea89ccb9fce@haskell.org> #876: Length is not a good consumer -------------------------------------+------------------------------------- Reporter: ariep@… | Owner: Type: bug | Status: new Priority: lowest | Milestone: 7.6.2 Component: libraries/base | Version: 6.5 Resolution: | Keywords: length Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | perf/should_run/T876 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): This code, compiled with `-O, does fuse, and allocates nothing (or constant amounts) {{{#!hs module Foo where x :: Int -> Int x n = length [0..(10^n)::Int] }}} {{{ $ ghci -fobject-code -O Foo GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Foo ( Foo.hs, Foo.o ) Ok, modules loaded: Foo. Prelude Foo> :set +s Prelude Foo> x 1 11 (0.03 secs, 14,976,744 bytes) Prelude Foo> x 7 10000001 (0.02 secs, 0 bytes) Prelude Foo> x 8 100000001 (0.04 secs, 0 bytes) }}} (almost) HEAD: {{{ GHCi, version 8.1.20161117: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Foo (.hs -> .o) WARNING: file compiler/simplCore/SimplCore.hs, line 663 Simplifier bailing out after 4 iterations [58, 14, 2, 2] Size = {terms: 96, types: 32, coercions: 0} Ok, modules loaded: Foo (Foo.o). Prelude Foo> :set +s Prelude Foo> x 1 11 (0.19 secs, 94,792 bytes) Prelude Foo> x 2 101 (0.01 secs, 94,648 bytes) Prelude Foo> x 7 10000001 (0.01 secs, 98,568 bytes) Prelude Foo> x 8 100000001 (0.05 secs, 98,448 bytes) }}} Testing this in with interpreted code is not sufficient, as the optimizer does less in that case. So so far, everything seems as expected to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 11 15:07:07 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Dec 2016 15:07:07 -0000 Subject: [GHC] #12960: New haddock seems to be segfaulting Message-ID: <044.d96764a38896f35490454b7982053572@haskell.org> #12960: New haddock seems to be segfaulting -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Documentation | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Commit 61932cd3eb0d5d22cb35d118fb9f87298881cd77 bumped up haddock. This seems to be segfaulting randomly on Windows and OSX or just dies. compiler/ghc.mk:581: recipe for target 'compiler/stage2/doc/html/ghc/ghc.haddock' failed make[1]: *** [compiler/stage2/doc/html/ghc/ghc.haddock] Error 1 Makefile:122: recipe for target 'all' failed make: *** [all] Error 2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 11 15:07:33 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Dec 2016 15:07:33 -0000 Subject: [GHC] #12960: New haddock seems to be segfaulting In-Reply-To: <044.d96764a38896f35490454b7982053572@haskell.org> References: <044.d96764a38896f35490454b7982053572@haskell.org> Message-ID: <059.bdf278ba2070bc8eba934b5bcf09464c@haskell.org> #12960: New haddock seems to be segfaulting -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Documentation | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Phyx-: @@ -5,0 +5,1 @@ + {{{ @@ -10,0 +11,1 @@ + }}} New description: Commit 61932cd3eb0d5d22cb35d118fb9f87298881cd77 bumped up haddock. This seems to be segfaulting randomly on Windows and OSX or just dies. {{{ compiler/ghc.mk:581: recipe for target 'compiler/stage2/doc/html/ghc/ghc.haddock' failed make[1]: *** [compiler/stage2/doc/html/ghc/ghc.haddock] Error 1 Makefile:122: recipe for target 'all' failed make: *** [all] Error 2 }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 11 16:05:47 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Dec 2016 16:05:47 -0000 Subject: [GHC] #9775: "Failed to remove" errors during Windows build from hsc2hs In-Reply-To: <045.a3bc7893c1159a7aa08bb934a48297de@haskell.org> References: <045.a3bc7893c1159a7aa08bb934a48297de@haskell.org> Message-ID: <060.2802c5958dd674155c46a2229fb74dad@haskell.org> #9775: "Failed to remove" errors during Windows build from hsc2hs ---------------------------------+---------------------------------------- Reporter: gintas | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: hsc2hs | Version: 7.8.3 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by Phyx-): Pull request submitted to `Process`[1] Now to update hsc2hs. [1] https://github.com/haskell/process/pull/80 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 11 16:31:55 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Dec 2016 16:31:55 -0000 Subject: [GHC] #12894: Bump directory In-Reply-To: <046.4beed447095342b2603c24699e3a82bd@haskell.org> References: <046.4beed447095342b2603c24699e3a82bd@haskell.org> Message-ID: <061.d16ddd842a849ea6b2e08768541c81e3@haskell.org> #12894: Bump directory -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: upstream Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): This was done in 68abbbd75b69eace345bb47f7f713462f370bf3b -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 11 17:15:26 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Dec 2016 17:15:26 -0000 Subject: [GHC] #12961: Duplicate exported functions? Message-ID: <046.df52197804743b94c3be74861e4050c8@haskell.org> #12961: Duplicate exported functions? -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In my paper on Call Arity, I wrote > Unfortunately it also means that adding a top-level function to the export list of the module can prevent Call Arity from eta-expanding it and other functions in the module. and a reviewer asked > Why don’t you duplicate and specialize the function? And that is an interesting question, which I don’t want to pursue at the moment in detail, but note down. Obviously, if the the function can be inlined in all uses in the current module, we essentially do that already. But if not (for example, because it is recursive), then this could indeed improve the performance of the in-module uses. The question is: Is it worth it? Questions on the way: Do we have more analyses like Call Arity that gather information form the use sites, and that need to make pessimistic assumptions for exported functions, or is it the only one? In terms of final code size: Will CSE reliably undo the duplication of possible large swathes of code if both copies of the function were compiled identically? Maybe instead of duplicating all exported functions opportunistically, Call Arity could analyze them twice and only if it gets useful data from the use-sites cause them to be duplicated. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 11 17:21:16 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Dec 2016 17:21:16 -0000 Subject: [GHC] #12961: Duplicate exported functions? In-Reply-To: <046.df52197804743b94c3be74861e4050c8@haskell.org> References: <046.df52197804743b94c3be74861e4050c8@haskell.org> Message-ID: <061.dcb095b5f7fa48f94b6a5b6cb9775b83@haskell.org> #12961: Duplicate exported functions? -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * priority: normal => low -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 11 19:59:27 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Dec 2016 19:59:27 -0000 Subject: [GHC] #12942: Add infix flag for class and data declarations In-Reply-To: <044.ad2a88252aaa49d53b0869c522534f50@haskell.org> References: <044.ad2a88252aaa49d53b0869c522534f50@haskell.org> Message-ID: <059.f4f5ce01e429fab72c3fbf38b9ab594c@haskell.org> #12942: Add infix flag for class and data declarations -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #3384 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alanz): `NamedThing` has a method `getName :: a -> Name` which is meaningless in the `RdrName` case for the `ParsedSource`. I see that `OutputableBndr` has class methods `pprPrefixOcc, pprInfixOcc :: a -> SDoc` which will work for the `BooleanFormula` case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 11 22:13:29 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Dec 2016 22:13:29 -0000 Subject: [GHC] #12942: Add infix flag for class and data declarations In-Reply-To: <044.ad2a88252aaa49d53b0869c522534f50@haskell.org> References: <044.ad2a88252aaa49d53b0869c522534f50@haskell.org> Message-ID: <059.f8748635c9b3c55ab4e31b552b665948@haskell.org> #12942: Add infix flag for class and data declarations -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #3384 | Differential Rev(s): Phab:D2828 Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * differential: => Phab:D2828 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 11 22:15:48 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Dec 2016 22:15:48 -0000 Subject: [GHC] #12960: New haddock seems to be segfaulting In-Reply-To: <044.d96764a38896f35490454b7982053572@haskell.org> References: <044.d96764a38896f35490454b7982053572@haskell.org> Message-ID: <059.56f90b750512c8186f780a0e780863ff@haskell.org> #12960: New haddock seems to be segfaulting -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Documentation | Version: 8.0.1 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => closed * resolution: => invalid Comment: Think the origin may lie with some other patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 11 22:44:28 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Dec 2016 22:44:28 -0000 Subject: [GHC] #12959: GHC doesn't warn about missing implementations for class methods beginning with an underscore In-Reply-To: <050.f1c049718f4b94fba939144b405d48bc@haskell.org> References: <050.f1c049718f4b94fba939144b405d48bc@haskell.org> Message-ID: <065.6dd0f34fe270199ea20831759dec473e@haskell.org> #12959: GHC doesn't warn about missing implementations for class methods beginning with an underscore -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AlexET): You can actually trace it back further to 9aba9a7f16e3f4acd79c75aacdbaad5af92f8752 where it was introduced. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 11 23:04:12 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Dec 2016 23:04:12 -0000 Subject: [GHC] #12550: Inconsistent unicode display for kinds In-Reply-To: <046.4e00c711f62582701b795cf12b5d8ff3@haskell.org> References: <046.4e00c711f62582701b795cf12b5d8ff3@haskell.org> Message-ID: <061.9a3fc2bc4573f5c44fbe3f3812958209@haskell.org> #12550: Inconsistent unicode display for kinds ---------------------------------+-------------------------------------- Reporter: johnleo | Owner: johnleo Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by johnleo): Ben's fix for #11660 handled almost all of the problems. The sole remaining problem was the result of conflation between the input format of kind * (`*`, `★` or `Type`), the internal representation, and the output format. If * was inferred it was output correctly, but if it was explicitly specified in the type signature it would be output in that form, which means the output format could be a confusing mixture of `*`, `★` and `Type`. I have unified the output format to be `*` when non- unicode output is expected and `★` when `-fprint-unicode-syntax` is enabled. Note that in the future we may output `Type` in all cases instead (see #12030) but this will not happen for some time; I plan to create a proposal for this. I wanted to go further and unify the internal representations of `*`, `★` and `Type` by setting the key of all three to be `liftedTypeKindTyConKey` since internally they are all fundamentally the same thing. However this caused a panic in `PrelInfo.knownKeyNamesOkay` since apparently all keys have to be unique. I wonder if that condition could be relaxed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 11 23:05:20 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Dec 2016 23:05:20 -0000 Subject: [GHC] #12550: Inconsistent unicode display for kinds In-Reply-To: <046.4e00c711f62582701b795cf12b5d8ff3@haskell.org> References: <046.4e00c711f62582701b795cf12b5d8ff3@haskell.org> Message-ID: <061.812bac429440b98ff5dcebc9118a59d5@haskell.org> #12550: Inconsistent unicode display for kinds ----------------------------------+-------------------------------------- Reporter: johnleo | Owner: johnleo Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11660 #12030 | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Changes (by johnleo): * related: => #11660 #12030 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 11 23:44:13 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Dec 2016 23:44:13 -0000 Subject: [GHC] #12550: Inconsistent unicode display for kinds In-Reply-To: <046.4e00c711f62582701b795cf12b5d8ff3@haskell.org> References: <046.4e00c711f62582701b795cf12b5d8ff3@haskell.org> Message-ID: <061.f66743f1b7a9a591efc52f34af846e91@haskell.org> #12550: Inconsistent unicode display for kinds ----------------------------------+-------------------------------------- Reporter: johnleo | Owner: johnleo Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11660 #12030 | Differential Rev(s): Phab:D2829 Wiki Page: | ----------------------------------+-------------------------------------- Changes (by johnleo): * differential: => Phab:D2829 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 12 09:41:19 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Dec 2016 09:41:19 -0000 Subject: [GHC] #11511: Type family producing infinite type accepted as injective In-Reply-To: <048.97d84dbb372812585cd3199cfa06814f@haskell.org> References: <048.97d84dbb372812585cd3199cfa06814f@haskell.org> Message-ID: <063.721c546182627aea7e543a9d5a84a958@haskell.org> #11511: Type family producing infinite type accepted as injective -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Keywords: TypeFamilies, Resolution: | Injective Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jstolarek): Yes, certainly what I said is conservative - some injective functions would be rejected. What I'm wondering is whether our current approach is sound from a logical point of view. Perhaps assuming `F` injective when checking injectivity of `F` is the reason why Richard couldn't complete the proof we presented in the paper? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 12 11:57:00 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Dec 2016 11:57:00 -0000 Subject: [GHC] #12936: Type inference regression in GHC HEAD In-Reply-To: <050.1f2cf84cf2dccac9b01fc4b4cae905cd@haskell.org> References: <050.1f2cf84cf2dccac9b01fc4b4cae905cd@haskell.org> Message-ID: <065.e87ea942f88e1fc434c8a118a063800c@haskell.org> #12936: Type inference regression in GHC HEAD -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"f1036ad80efb9cf80977fa234f8b9c7b23cc6835/ghc" f1036ad/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f1036ad80efb9cf80977fa234f8b9c7b23cc6835" Make dropDerivedSimples restore [WD] constraints I'd forgotten to turn [W] + [D] constraints back into [WD] in dropDerivedSimples; and that led to Trac #12936. Fortunately the fix is simple. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 12 12:02:21 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Dec 2016 12:02:21 -0000 Subject: [GHC] #12962: No automatic SCC annotations for functions marked INLINABLE Message-ID: <054.f2234820ab9cebe1f15e9179cc25a0ab@haskell.org> #12962: No automatic SCC annotations for functions marked INLINABLE -------------------------------------+------------------------------------- Reporter: | Owner: MikolajKonarski | Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Judging from .prof files and the -xc and -prof callstacks, GHC adds no automatic SCC annotations for functions marked `INLINABLE`. The user's guide only mentions `INLINE`: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/profiling.html, not `INLINABLE`. Is it a bug in documentation or implementation? In my case I managed to work around by using `-fexpose-all-unfoldings` instead of the tons of `INLINABLE` I was using before, but in general case, adding all the SCC annotations by hand seems prohibitive. e.g., in code that needs a lot of `INLINABLE` to enable specialization. Since `-fexpose-all-unfoldings` does not inhibit profiling and compiling with no optimization doesn't help recover it, the culprit is probably not the actual inlining or specialization, but rather handling of the `INLINABLE` pragma itself. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 12 12:17:33 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Dec 2016 12:17:33 -0000 Subject: [GHC] #876: Length is not a good consumer In-Reply-To: <054.b373028d5cb568a8380002fb5d2d74f4@haskell.org> References: <054.b373028d5cb568a8380002fb5d2d74f4@haskell.org> Message-ID: <069.f8f0de8bf8b4533ba63c9640bde9b6ce@haskell.org> #876: Length is not a good consumer -------------------------------------+------------------------------------- Reporter: ariep@… | Owner: Type: bug | Status: closed Priority: lowest | Milestone: 7.6.2 Component: libraries/base | Version: 6.5 Resolution: fixed | Keywords: length Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | perf/should_run/T876 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 12 12:36:12 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Dec 2016 12:36:12 -0000 Subject: [GHC] #12962: No automatic SCC annotations for functions marked INLINABLE In-Reply-To: <054.f2234820ab9cebe1f15e9179cc25a0ab@haskell.org> References: <054.f2234820ab9cebe1f15e9179cc25a0ab@haskell.org> Message-ID: <069.92f5378c2847548f65c3fb7dd3de10a1@haskell.org> #12962: No automatic SCC annotations for functions marked INLINABLE -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): So to be clear here, the problem is that you expect GHC to add cost centres to functions marked `INLINABLE` when using `-fprof-auto`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 12 12:40:00 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Dec 2016 12:40:00 -0000 Subject: [GHC] #12962: No automatic SCC annotations for functions marked INLINABLE In-Reply-To: <054.f2234820ab9cebe1f15e9179cc25a0ab@haskell.org> References: <054.f2234820ab9cebe1f15e9179cc25a0ab@haskell.org> Message-ID: <069.8ee56883819b6c89335b0f29d3cc2dd8@haskell.org> #12962: No automatic SCC annotations for functions marked INLINABLE -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by MikolajKonarski): Yes, that's it. I use mostly `-fprof-auto-exported`, but users' guide mentions only `INLINE` as disabling automatic annotations in either case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 12 13:11:53 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Dec 2016 13:11:53 -0000 Subject: [GHC] #12962: No automatic SCC annotations for functions marked INLINABLE In-Reply-To: <054.f2234820ab9cebe1f15e9179cc25a0ab@haskell.org> References: <054.f2234820ab9cebe1f15e9179cc25a0ab@haskell.org> Message-ID: <069.dc0073ca2c4415f1b1e86af2f6c7f020@haskell.org> #12962: No automatic SCC annotations for functions marked INLINABLE -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * cc: osa1 (added) Comment: I'm not sure if this is intentional. `compiler/deSugar/Coverage.hs` is responsible for adding ticks. It's using `BasicTypes.isAnyInlinePragma` for deciding whether to add a tick or not, and that function returns true for both `INLINE` and `INLINABLE`. But if you look at the note `inline sccs`: {{{#!haskell -- Note [inline sccs] -- -- It should be reasonable to add ticks to INLINE functions; however -- currently this tickles a bug later on because the SCCfinal pass -- does not look inside unfoldings to find CostCentres. It would be -- difficult to fix that, because SCCfinal currently works on STG and -- not Core (and since it also generates CostCentres for CAFs, -- changing this would be difficult too). -- -- Another reason not to add ticks to INLINE functions is that this -- sometimes handy for avoiding adding a tick to a particular function -- (see #6131) -- -- So for now we do not add any ticks to INLINE functions at all. }}} it doesn't mention `INLINABLE`. #6131 also doesn't mention `INLINABLE`, maybe it didn't exist at the time. I think it might make sense to add cost centres to `INLINABLE` functions as they may not be inlined. Somewhat related ticket: #10766 (semantics of `INLINE` and `INLINABLE` are not clear). I also looked at the git history. The commit that added the note also added `isAnyInlinePragma` calls, and that functions had same semantics as today. So maybe it's intentional and we should update the documentation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 12 13:17:02 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Dec 2016 13:17:02 -0000 Subject: [GHC] #11739: Simplify axioms; should be applied to types In-Reply-To: <047.1dec82d6884084079fbacd762d819ea8@haskell.org> References: <047.1dec82d6884084079fbacd762d819ea8@haskell.org> Message-ID: <062.44fb745bad26ca6338445671f5e6dc75@haskell.org> #11739: Simplify axioms; should be applied to types -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * owner: => goldfire -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 12 13:21:52 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Dec 2016 13:21:52 -0000 Subject: [GHC] #12903: SIGINT is not handled in forked process In-Reply-To: <045.73f1eb35eda69f56b71c66e83162bd9f@haskell.org> References: <045.73f1eb35eda69f56b71c66e83162bd9f@haskell.org> Message-ID: <060.08ca2a05f338785da8afd06477173376@haskell.org> #12903: SIGINT is not handled in forked process -------------------------------------+------------------------------------- Reporter: qnikst | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Runtime System | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2770 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Matthew Pickering ): In [changeset:"6720376500c33947fe196b68fe54f5e448376c5d/ghc" 67203765/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6720376500c33947fe196b68fe54f5e448376c5d" Disable T12903 due to flakiness Test seems to randomly fail on harbormaster. Disabling it until it can be fixed. Test Plan: make test TEST=T12903 Reviewers: austin, bgamari, simonmar, mpickering Reviewed By: mpickering Subscribers: mpickering, thomie, qnikst Differential Revision: https://phabricator.haskell.org/D2821 GHC Trac Issues: #12903 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 12 13:23:19 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Dec 2016 13:23:19 -0000 Subject: [GHC] #12963: Give -fexpose-all-unfoldings the same semantics as INLINABLE on each function Message-ID: <054.22fe7863b28eeadeb595cd63b5824204@haskell.org> #12963: Give -fexpose-all-unfoldings the same semantics as INLINABLE on each function -------------------------------------+------------------------------------- Reporter: | Owner: MikolajKonarski | Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #12962 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Feature request: give `-fexpose-all-unfoldings` the same semantics as `INLINABLE` on each function. For simplicity, for the principle of least surprise and for usability of `-fexpose-all-unfoldings`, so that it can actually replace tons of `INLINABLE` that are needed, e.g., for code with lots of abstract class constraints to force it to specialize to the single class that is actually used. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 12 13:25:37 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Dec 2016 13:25:37 -0000 Subject: [GHC] #12963: Give -fexpose-all-unfoldings the same semantics as INLINABLE on each function In-Reply-To: <054.22fe7863b28eeadeb595cd63b5824204@haskell.org> References: <054.22fe7863b28eeadeb595cd63b5824204@haskell.org> Message-ID: <069.0db610e2e341eb77cb02ce2b61306140@haskell.org> #12963: Give -fexpose-all-unfoldings the same semantics as INLINABLE on each function -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12962 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by MikolajKonarski): I should mention that the semantics of `-fexpose-all-unfoldings` is currently different from `INLINABLE` on each function. In particular, it produces much slower programs for my codebase, probably because it doesn't force specialization (though it makes it possible by exposing the unfoldings), as opposed to `INLINABLE`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 12 13:27:39 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Dec 2016 13:27:39 -0000 Subject: [GHC] #12962: No automatic SCC annotations for functions marked INLINABLE In-Reply-To: <054.f2234820ab9cebe1f15e9179cc25a0ab@haskell.org> References: <054.f2234820ab9cebe1f15e9179cc25a0ab@haskell.org> Message-ID: <069.a30e4997820e8d32f63ba3913e5d005e@haskell.org> #12962: No automatic SCC annotations for functions marked INLINABLE -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12963 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by MikolajKonarski): * related: => #12963 @@ -15,0 +15,4 @@ + + Edit: Ufortunately, the workaround by using `-fexpose-all-unfoldings` + turns out to be not acceptable for me, see #12963. I'm also no longer sure + about the last paragraph. New description: Judging from .prof files and the -xc and -prof callstacks, GHC adds no automatic SCC annotations for functions marked `INLINABLE`. The user's guide only mentions `INLINE`: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/profiling.html, not `INLINABLE`. Is it a bug in documentation or implementation? In my case I managed to work around by using `-fexpose-all-unfoldings` instead of the tons of `INLINABLE` I was using before, but in general case, adding all the SCC annotations by hand seems prohibitive. e.g., in code that needs a lot of `INLINABLE` to enable specialization. Since `-fexpose-all-unfoldings` does not inhibit profiling and compiling with no optimization doesn't help recover it, the culprit is probably not the actual inlining or specialization, but rather handling of the `INLINABLE` pragma itself. Edit: Ufortunately, the workaround by using `-fexpose-all-unfoldings` turns out to be not acceptable for me, see #12963. I'm also no longer sure about the last paragraph. -- Comment: Ufortunately, the workaround by using `-fexpose-all-unfoldings` turns out to be not acceptable for me, see #12963. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 12 13:36:31 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Dec 2016 13:36:31 -0000 Subject: [GHC] #12963: Give -fexpose-all-unfoldings the same semantics as INLINABLE on each function In-Reply-To: <054.22fe7863b28eeadeb595cd63b5824204@haskell.org> References: <054.22fe7863b28eeadeb595cd63b5824204@haskell.org> Message-ID: <069.3043ad741962c4229173cb336a76af44@haskell.org> #12963: Give -fexpose-all-unfoldings the same semantics as INLINABLE on each function -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12962 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): This is very vague. You say that the semantics are different but how have you observed this? `INLINABLE` doesn't do anything about "forcing specialisation" so I'm unclear what you mean. If I was to guess I would say that `-fexpose-all-unfoldings` exposes optimised unfoldings rather than unoptimised unfoldings like `INLINABLE`. Now to make progress, do you have a small code sample which behaves differently with `INLINABLE` vs `-fexpose-all-unfoldings`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 12 13:36:42 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Dec 2016 13:36:42 -0000 Subject: [GHC] #12963: Give -fexpose-all-unfoldings the same semantics as INLINABLE on each function In-Reply-To: <054.22fe7863b28eeadeb595cd63b5824204@haskell.org> References: <054.22fe7863b28eeadeb595cd63b5824204@haskell.org> Message-ID: <069.81cc66aec26fa0579675c4a34bd9d96b@haskell.org> #12963: Give -fexpose-all-unfoldings the same semantics as INLINABLE on each function -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12962 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => Inlining -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 12 13:37:04 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Dec 2016 13:37:04 -0000 Subject: [GHC] #12962: No automatic SCC annotations for functions marked INLINABLE In-Reply-To: <054.f2234820ab9cebe1f15e9179cc25a0ab@haskell.org> References: <054.f2234820ab9cebe1f15e9179cc25a0ab@haskell.org> Message-ID: <069.41329e0ad0499f50cf55b4a92484b56c@haskell.org> #12962: No automatic SCC annotations for functions marked INLINABLE -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 8.0.1 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12963 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => Inlining -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 12 13:54:25 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Dec 2016 13:54:25 -0000 Subject: [GHC] #12963: Give -fexpose-all-unfoldings the same semantics as INLINABLE on each function In-Reply-To: <054.22fe7863b28eeadeb595cd63b5824204@haskell.org> References: <054.22fe7863b28eeadeb595cd63b5824204@haskell.org> Message-ID: <069.65a279f98ff1d8e9fe3ea8838633eb15@haskell.org> #12963: Give -fexpose-all-unfoldings the same semantics as INLINABLE on each function -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12962 #12463 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by MikolajKonarski): * related: #12962 => #12962 #12463 Comment: Yes, I'm being lazy. I've only benchmarked my big codebase (https://github.com/LambdaHack/LambdaHack). It may not be easy to find a small example in which GHC nevertheless fails to specialize a function for which it has an available unfolding. I got the bit about `INLINABLE` forcing specialization from here: https://ghc.haskell.org/trac/ghc/ticket/12463#comment:8 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 12 13:57:55 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Dec 2016 13:57:55 -0000 Subject: [GHC] #12963: Give -fexpose-all-unfoldings the same semantics as INLINABLE on each function In-Reply-To: <054.22fe7863b28eeadeb595cd63b5824204@haskell.org> References: <054.22fe7863b28eeadeb595cd63b5824204@haskell.org> Message-ID: <069.d04f00893daedf501f73ebb4509520e0@haskell.org> #12963: Give -fexpose-all-unfoldings the same semantics as INLINABLE on each function -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: Type: feature request | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12962 #12463 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => infoneeded -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 12 14:08:45 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Dec 2016 14:08:45 -0000 Subject: [GHC] #12873: hWaitForInput with socket as handle excepts on windows In-Reply-To: <044.1ddaa628578738df0ad8573626efc264@haskell.org> References: <044.1ddaa628578738df0ad8573626efc264@haskell.org> Message-ID: <059.17dde0f91913742d5d5545e65a212b35@haskell.org> #12873: hWaitForInput with socket as handle excepts on windows ----------------------------------+-------------------------------------- Reporter: bwurk | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #7353 | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Comment (by pjljvdlaar): I had a similar problem with hWaitForInput. The work around I found was to move to Haskell platform 2013, with The Glorious Glasgow Haskell Compilation System, version 7.6.3 Also your example works perfectly with ghc 7.6.3! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 12 14:08:51 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Dec 2016 14:08:51 -0000 Subject: [GHC] #12949: Pattern coverage mistake In-Reply-To: <045.3db1ccae2330725ee6ce9cf1d67c2922@haskell.org> References: <045.3db1ccae2330725ee6ce9cf1d67c2922@haskell.org> Message-ID: <060.266a0ecb32f7b4746d4270e5d4d09c88@haskell.org> #12949: Pattern coverage mistake -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): This does indeed look like a bug to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 12 14:25:50 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Dec 2016 14:25:50 -0000 Subject: [GHC] #12949: Pattern coverage mistake In-Reply-To: <045.3db1ccae2330725ee6ce9cf1d67c2922@haskell.org> References: <045.3db1ccae2330725ee6ce9cf1d67c2922@haskell.org> Message-ID: <060.3d7fed911c400ef16b4b374f04e97ae7@haskell.org> #12949: Pattern coverage mistake -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * cc: gkaracha (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 12 14:37:21 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Dec 2016 14:37:21 -0000 Subject: [GHC] #12949: Pattern coverage mistake In-Reply-To: <045.3db1ccae2330725ee6ce9cf1d67c2922@haskell.org> References: <045.3db1ccae2330725ee6ce9cf1d67c2922@haskell.org> Message-ID: <060.950fcf214c17a1347a9345ef7b22a209@haskell.org> #12949: Pattern coverage mistake -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by gkaracha): * keywords: => PatternMatchWarnings Comment: Ah, yes, I think so too. First #11984 freshened variables too much (I still haven't managed to fix it), now this freshens them too little. I will take a look at this one too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 12 15:14:39 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Dec 2016 15:14:39 -0000 Subject: [GHC] #12942: Add infix flag for class and data declarations In-Reply-To: <044.ad2a88252aaa49d53b0869c522534f50@haskell.org> References: <044.ad2a88252aaa49d53b0869c522534f50@haskell.org> Message-ID: <059.0b4819f6051f1f2732761c40c06c9ec1@haskell.org> #12942: Add infix flag for class and data declarations -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: task | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #3384 | Differential Rev(s): Phab:D2828 Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 12 15:49:56 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Dec 2016 15:49:56 -0000 Subject: [GHC] #11715: Constraint vs * In-Reply-To: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> References: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> Message-ID: <061.e9a631521170dfd3d99e77542b171ba7@haskell.org> #11715: Constraint vs * -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Typeable, Resolution: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: Typeable => Typeable, LevityPolymorphism -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 12 16:25:31 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Dec 2016 16:25:31 -0000 Subject: [GHC] #8095: TypeFamilies painfully slow In-Reply-To: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> References: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> Message-ID: <065.941b3ff58837c5504e09a3c19c9e4e55@haskell.org> #8095: TypeFamilies painfully slow -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5321, #11598, | Differential Rev(s): #12506 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: bgamari => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 12 16:27:49 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Dec 2016 16:27:49 -0000 Subject: [GHC] #11715: Constraint vs * In-Reply-To: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> References: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> Message-ID: <061.a265f17bc6719e4f84da85aea9f37a70@haskell.org> #11715: Constraint vs * -------------------------------------+------------------------------------- Reporter: bgamari | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Typeable, Resolution: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: => goldfire -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 12 16:32:32 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Dec 2016 16:32:32 -0000 Subject: [GHC] #11523: Infinite Loop when mixing UndecidableSuperClasses and the class/instance constraint synonym trick. In-Reply-To: <045.d4380bf1adf1df9e0c96b4a3ede582ad@haskell.org> References: <045.d4380bf1adf1df9e0c96b4a3ede582ad@haskell.org> Message-ID: <060.db732d81e22f1c1bdf67e9306d6b1c32@haskell.org> #11523: Infinite Loop when mixing UndecidableSuperClasses and the class/instance constraint synonym trick. -------------------------------------+------------------------------------- Reporter: ekmett | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Resolution: | UndecidableSuperClasses Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | polykinds/T11523 Blocked By: | Blocking: Related Tickets: #11480 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: => simonpj -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 12 16:33:38 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Dec 2016 16:33:38 -0000 Subject: [GHC] #11784: panic "hscCmmFile: no_mod" with `-v2 and above In-Reply-To: <044.29a67b6904270a19ef7b34462d19062e@haskell.org> References: <044.29a67b6904270a19ef7b34462d19062e@haskell.org> Message-ID: <059.1f5329ee1a3ac695b56cbc8d571ef08c@haskell.org> #11784: panic "hscCmmFile: no_mod" with `-v2 and above -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): This is really quite a bad bug sine it hinders one's the ability to debug the compiler. We should really make sure this is fixed for 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 12 16:38:52 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Dec 2016 16:38:52 -0000 Subject: [GHC] #12603: INLINE and manually inlining produce different code In-Reply-To: <046.944cd4788eed55470361e7f38358ac43@haskell.org> References: <046.944cd4788eed55470361e7f38358ac43@haskell.org> Message-ID: <061.7beb4bcb4b9a644a2368809fd1faa2c5@haskell.org> #12603: INLINE and manually inlining produce different code -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #12747 #12781 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"bc3d37dada357b04fc5a35f740b4fe7e05292b06/ghc" bc3d37d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="bc3d37dada357b04fc5a35f740b4fe7e05292b06" Float unboxed expressions by boxing This patch makes GHC's floating more robust, by allowing it to float unboxed expressions of at least some common types. See Note [Floating MFEs of unlifted type] in SetLevels. This was all provoked by Trac #12603 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 12 16:43:18 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Dec 2016 16:43:18 -0000 Subject: [GHC] #12603: INLINE and manually inlining produce different code In-Reply-To: <046.944cd4788eed55470361e7f38358ac43@haskell.org> References: <046.944cd4788eed55470361e7f38358ac43@haskell.org> Message-ID: <061.bc37fd3d1db081ff0db38f73877a90ab@haskell.org> #12603: INLINE and manually inlining produce different code -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #12747 #12781 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Mikolaj, I think the above patch will make it robust for you. Can you check? Meanwhile, I'm going to leave this open because I ''also'' want to investigate making INLINE pragmas fire in the "gentle" phase, on the grounds that that's what the programmer said. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 12 16:49:51 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Dec 2016 16:49:51 -0000 Subject: [GHC] #12936: Type inference regression in GHC HEAD In-Reply-To: <050.1f2cf84cf2dccac9b01fc4b4cae905cd@haskell.org> References: <050.1f2cf84cf2dccac9b01fc4b4cae905cd@haskell.org> Message-ID: <065.6e64644eba7c33a2e2b12f4dae3cedc2@haskell.org> #12936: Type inference regression in GHC HEAD -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => fixed Comment: I can now build `parsec` again on HEAD. Thanks, Simon! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 12 16:53:40 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Dec 2016 16:53:40 -0000 Subject: [GHC] #12936: Type inference regression in GHC HEAD In-Reply-To: <050.1f2cf84cf2dccac9b01fc4b4cae905cd@haskell.org> References: <050.1f2cf84cf2dccac9b01fc4b4cae905cd@haskell.org> Message-ID: <065.2e9c42250d419ff35253d644016572ba@haskell.org> #12936: Type inference regression in GHC HEAD -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/T12936.hs Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => typecheck/should_compile/T12936.hs -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 12 17:00:08 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Dec 2016 17:00:08 -0000 Subject: [GHC] #12964: Runtime regression to RTS change Message-ID: <046.bcf824695cea07d48dc888c9a5c7fa61@haskell.org> #12964: Runtime regression to RTS change -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Runtime | Version: 8.1 System | 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: -------------------------------------+------------------------------------- The commit to fix #12799, namely changeset:1732d7ac43ca, seems to have introduced a runtime regression. The hidden and integer nofib benchmarks regress by 5.5% resp. 2.5%: https://perf.haskell.org/ghc/#revision/1732d7ac43ca578deca39ea5a63cbf34f3cd9dd5 I re-measured this commit and its parent once, and the numbers aid not change much. The `hidden` regression seems to be offset almost completely by the later changeset:6f7ed1e51bf360621a3c2a447045ab3012f68575 while the `integer` regression got “fixed” by the later changeset:1732d7ac43ca578deca39ea5a63cbf34f3cd9dd5. The perf builder is still new, so this might be bogus. But we should still check. Also, maybe random changes to the RTS cause random changes to the code layout which surface here. Or there is a real cause. Simon Marlow [https://phabricator.haskell.org/rGHC1732d7ac43ca#56419 suggested] to open a high priority ticket for this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 12 17:03:23 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Dec 2016 17:03:23 -0000 Subject: [GHC] #12962: No automatic SCC annotations for functions marked INLINABLE In-Reply-To: <054.f2234820ab9cebe1f15e9179cc25a0ab@haskell.org> References: <054.f2234820ab9cebe1f15e9179cc25a0ab@haskell.org> Message-ID: <069.74f01fd5e2612a419047cf13e043462c@haskell.org> #12962: No automatic SCC annotations for functions marked INLINABLE -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 8.0.1 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12963 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I think the proposal is that `-fprof-auto` adds cost-centres to INLINABLE (but not INLINE) things. I'm ok with that; I doubt it was intentional to make it so for INLINABLE. Would someone care to make a patch etc? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 12 17:09:41 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Dec 2016 17:09:41 -0000 Subject: [GHC] #12963: Give -fexpose-all-unfoldings the same semantics as INLINABLE on each function In-Reply-To: <054.22fe7863b28eeadeb595cd63b5824204@haskell.org> References: <054.22fe7863b28eeadeb595cd63b5824204@haskell.org> Message-ID: <069.0031d0d5d495740c82873ce0859efdff@haskell.org> #12963: Give -fexpose-all-unfoldings the same semantics as INLINABLE on each function -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: Type: feature request | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12962 #12463 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Feature request: give `-fexpose-all-unfoldings` the same semantics as INLINABLE on each function. I don't think we should do this. * `-fexpose-all-unfoldings` has no effect on the optimisation pipeline; it just arranges that, at the end of the pipeline all the unfoldings for all functions are put into the interface file. * `INLINABLE` is quite different. It says to snapshot (essentially the source code of) the RHS of the function, and make it available for inlining and/or specialisation at call sites. So it could have a major effect on the optimisation pipeline. (I'd prefer that it was called `SPECIALISABLE`.) Anyway I don't think it'd be a good idea to make them the same. If you want ''all'' the user-written top-level functions to be `INLINABLE`, we'll need a way to say just that; a reasonable feature request. Perhaps `{-# SPECIALISABLE_ALL #-}`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 12 17:12:46 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Dec 2016 17:12:46 -0000 Subject: [GHC] #12790: GHC 8.0.1 uses copious amounts of RAM and time when trying to compile lambdabot-haskell-plugins In-Reply-To: <044.6c4a4edd18cfc656391e8adc9c55d93a@haskell.org> References: <044.6c4a4edd18cfc656391e8adc9c55d93a@haskell.org> Message-ID: <059.23edaec06204248043e96eb03bdf3a1c@haskell.org> #12790: GHC 8.0.1 uses copious amounts of RAM and time when trying to compile lambdabot-haskell-plugins -------------------------------------+------------------------------------- Reporter: clint | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Thankfully, Simon has fixed #12936, so now we can compile `parsec` on GHC HEAD without issue. Another interesting tidbit: when compiling with `-O -prof`, it exhibits slowdown, but with `-O -prof -fprof-auto`, it doesn't! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 12 17:21:12 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Dec 2016 17:21:12 -0000 Subject: [GHC] #12965: String merging broken on Windows Message-ID: <046.4ab9842a6728ed7002fe72135f75869e@haskell.org> #12965: String merging broken on Windows ----------------------------------------+--------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- #9577 introduced string literal merging via the linker. Unfortunately I haven't been able to get this to function on Windows, resulting in testsuite failures of #9577. Even `gcc` appears to do the wrong thing here, {{{ $ cat hi.c #include const char *hi = "hello world"; extern const char *hi2; void main() { printf("%p %p", hi, hi2); } $ cat hi2.c const char *hi2 = "hello world"; $ gcc -c hi.c; gcc -c hi2.c; gcc -fmerge-all-constants hi2.o hi.o $ ./a.exe 0x100403040 0x100403030 $ gcc -s hi2.c $ cat hi2.s .file "hi2.c" .globl hi .section .rdata,"dr" .LC0: .ascii "hello world\0" .data .align 8 hi: .quad .LC0 .ident "GCC: (GNU) 5.3.0" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 12 17:22:00 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Dec 2016 17:22:00 -0000 Subject: [GHC] #9577: String literals are wasting space In-Reply-To: <045.ae4d47715fdd8321ed459b0edd946522@haskell.org> References: <045.ae4d47715fdd8321ed459b0edd946522@haskell.org> Message-ID: <060.84c017f6551ae66e817f9342f5d27266@haskell.org> #9577: String literals are wasting space -------------------------------------+------------------------------------- Reporter: xnyhps | Owner: xnyhps Type: bug | Status: closed Priority: low | Milestone: 8.2.1 Component: Compiler (NCG) | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | codeGen/should_run/T9577 Blocked By: | Blocking: Related Tickets: #12937, #12965 | Differential Rev(s): Phab:D1290 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: => #12937, #12965 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 12 17:27:32 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Dec 2016 17:27:32 -0000 Subject: [GHC] #12962: No automatic SCC annotations for functions marked INLINABLE In-Reply-To: <054.f2234820ab9cebe1f15e9179cc25a0ab@haskell.org> References: <054.f2234820ab9cebe1f15e9179cc25a0ab@haskell.org> Message-ID: <069.34f85fbfcfd248242111c070de7bf48c@haskell.org> #12962: No automatic SCC annotations for functions marked INLINABLE -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 8.0.1 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12963 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): I'm a bit busy for next two days, I'll make a patch after that unless someone else does in the meantime. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 12 17:33:39 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Dec 2016 17:33:39 -0000 Subject: [GHC] #12790: GHC 8.0.1 uses copious amounts of RAM and time when trying to compile lambdabot-haskell-plugins In-Reply-To: <044.6c4a4edd18cfc656391e8adc9c55d93a@haskell.org> References: <044.6c4a4edd18cfc656391e8adc9c55d93a@haskell.org> Message-ID: <059.a7fd11af1af4ef7ac67bf9c10fb74035@haskell.org> #12790: GHC 8.0.1 uses copious amounts of RAM and time when trying to compile lambdabot-haskell-plugins -------------------------------------+------------------------------------- Reporter: clint | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): There's quite a difference between the generated Core for `list` depending on whether `-fprof-auto` is on or not. With `-fprof-auto`, we have: {{{#!hs -- RHS size: {terms: 2, types: 0, coercions: 0} list :: Parser Expr list = Lambdabot.Plugin.Haskell.Pl.Parser.list_go1 Lambdabot.Plugin.Haskell.Pl.Parser.list1 -- RHS size: {terms: 3, types: 11, coercions: 10} Lambdabot.Plugin.Haskell.Pl.Parser.list1 :: [Text.Parsec.Prim.ParsecT [Char] () Data.Functor.Identity.Identity Expr] }}} But without `-fprof-auto`, we have: {{{#!hs -- RHS size: {terms: 1, types: 0, coercions: 7} list :: Parser Expr list = Lambdabot.Plugin.Haskell.Pl.Parser.list1 `cast` (Sym (Text.Parsec.Prim.N:ParsecT[0] <[Char]>_R <()>_R _R _R) :: ((forall b. Text.Parsec.Prim.State [Char] () -> (Expr -> Text.Parsec.Prim.State [Char] () -> Text.Parsec.Error.ParseError -> Data.Functor.Identity.Identity b) -> (Text.Parsec.Error.ParseError -> Data.Functor.Identity.Identity b) -> (Expr -> Text.Parsec.Prim.State [Char] () -> Text.Parsec.Error.ParseError -> Data.Functor.Identity.Identity b) -> (Text.Parsec.Error.ParseError -> Data.Functor.Identity.Identity b) -> Data.Functor.Identity.Identity b) :: *) ~R# (Text.Parsec.Prim.ParsecT [Char] () Data.Functor.Identity.Identity Expr :: *)) -- RHS size: {terms: 910,139, types: 246,618, coercions: 0} Lambdabot.Plugin.Haskell.Pl.Parser.list1 :: forall b. Text.Parsec.Prim.State [Char] () -> (Expr -> Text.Parsec.Prim.State [Char] () -> Text.Parsec.Error.ParseError -> Data.Functor.Identity.Identity b) -> (Text.Parsec.Error.ParseError -> Data.Functor.Identity.Identity b) -> (Expr -> Text.Parsec.Prim.State [Char] () -> Text.Parsec.Error.ParseError -> Data.Functor.Identity.Identity b) -> (Text.Parsec.Error.ParseError -> Data.Functor.Identity.Identity b) -> Data.Functor.Identity.Identity b }}} That's quite the code explosion! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 12 18:38:14 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Dec 2016 18:38:14 -0000 Subject: [GHC] #12837: KnownNat and KnownSymbol should be abstract In-Reply-To: <049.214432e5cb536d2a77e4b4992c98f5b4@haskell.org> References: <049.214432e5cb536d2a77e4b4992c98f5b4@haskell.org> Message-ID: <064.6cbbd8079e1cdde004f3188375257470@haskell.org> #12837: KnownNat and KnownSymbol should be abstract -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by pbg): I'm a total newbie so can't comment on whether this is a desired change. However in case it is - would extending the code that was added for `Typeable` (#8132) to account for additional class names be the way to go here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 12 18:51:06 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Dec 2016 18:51:06 -0000 Subject: [GHC] #12942: Add infix flag for class and data declarations In-Reply-To: <044.ad2a88252aaa49d53b0869c522534f50@haskell.org> References: <044.ad2a88252aaa49d53b0869c522534f50@haskell.org> Message-ID: <059.b423ea0f1eed8037bd1a17f13b4957a1@haskell.org> #12942: Add infix flag for class and data declarations -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: task | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #3384 | Differential Rev(s): Phab:D2828 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Alan Zimmerman ): In [changeset:"8f6d241a74efa6f6280689a9b14c36c6a9f4c231/ghc" 8f6d241a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8f6d241a74efa6f6280689a9b14c36c6a9f4c231" Add infix flag for class and data declarations Summary: At the moment, data and type declarations using infix formatting produce the same AST as those using prefix. So type a ++ b = c and type (++) a b = c cannot be distinguished in the parsed source, without looking at the OccName details of the constructor being defined. Having access to the OccName requires an additional constraint which explodes out over the entire AST because of its recursive definitions. In keeping with moving the parsed source to more directly reflect the source code as parsed, add a specific flag to the declaration to indicate the fixity, as used in a Match now too. Note: this flag is to capture the fixity used for the lexical definition of the type, primarily for use by ppr and ghc-exactprint. Updates haddock submodule. Test Plan: ./validate Reviewers: mpickering, goldfire, bgamari, austin Reviewed By: mpickering Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2828 GHC Trac Issues: #12942 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 12 18:53:46 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Dec 2016 18:53:46 -0000 Subject: [GHC] #12942: Add infix flag for class and data declarations In-Reply-To: <044.ad2a88252aaa49d53b0869c522534f50@haskell.org> References: <044.ad2a88252aaa49d53b0869c522534f50@haskell.org> Message-ID: <059.6cb0cbf4b731f48beebb0eb25fbff251@haskell.org> #12942: Add infix flag for class and data declarations -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: task | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #3384 | Differential Rev(s): Phab:D2828 Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 12 19:32:26 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Dec 2016 19:32:26 -0000 Subject: [GHC] #9832: Get rid of PERL dependency of `ghc-split` In-Reply-To: <042.a80d180822707ef08b1350d4a542cee3@haskell.org> References: <042.a80d180822707ef08b1350d4a542cee3@haskell.org> Message-ID: <057.bd28e413cfd921fe7a64b346c5487b89@haskell.org> #9832: Get rid of PERL dependency of `ghc-split` ---------------------------------+---------------------------------------- Reporter: hvr | Owner: dobenour Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Driver | Version: Resolution: | Keywords: perl Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8405 | Differential Rev(s): D2768 Wiki Page: | ---------------------------------+---------------------------------------- Changes (by michalt): * cc: michalt (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 12 19:50:40 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Dec 2016 19:50:40 -0000 Subject: [GHC] #12915: cmmImplementSwitchPlans creates duplicate blocks In-Reply-To: <048.450627ba0680e3fafd8b0486acc85c67@haskell.org> References: <048.450627ba0680e3fafd8b0486acc85c67@haskell.org> Message-ID: <063.e25bfca9fafc1d268909cf2b941f4ca5@haskell.org> #12915: cmmImplementSwitchPlans creates duplicate blocks -------------------------------------+------------------------------------- Reporter: alexbiehl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by michalt): Another ticket about this: #9157 (also with a good example where sinking pass could expose some additional optimization opportunities for common block elimination). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 12 20:54:04 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Dec 2016 20:54:04 -0000 Subject: [GHC] #11715: Constraint vs * In-Reply-To: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> References: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> Message-ID: <061.78f8164a17230973f7e54ed563b0b806@haskell.org> #11715: Constraint vs * -------------------------------------+------------------------------------- Reporter: bgamari | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Typeable, Resolution: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): While speaking to danharaj about #10359 it occurred to me that the semantic issues with the tuple transform that simonpj proposes in ticket:10359#comment:2 would disappear if dictionaries were instead of kind `UnliftedPtrRep`. We could then introduce a core-to-core pass which would look for reconstructions of unlifted data constructors (e.g. `(case d of (a,b) -> a, case d of (a,b) -> b)`) and reduce them safely (e.g. to `d`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 12 21:57:28 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Dec 2016 21:57:28 -0000 Subject: [GHC] #12966: GHC panics with forall and constraint Message-ID: <043.89f40a41f374846eb7676b05fcc51b80@haskell.org> #12966: GHC panics with forall and constraint -------------------------------------+------------------------------------- Reporter: xcmw | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ λ> type Maybeify c = forall d. (c d) => ((~) (Maybe d)) :2:39: error:ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-apple-darwin): print_equality ~ Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 12 22:00:41 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Dec 2016 22:00:41 -0000 Subject: [GHC] #12962: No automatic SCC annotations for functions marked INLINABLE In-Reply-To: <054.f2234820ab9cebe1f15e9179cc25a0ab@haskell.org> References: <054.f2234820ab9cebe1f15e9179cc25a0ab@haskell.org> Message-ID: <069.966d4ec6ecd33a4afacf9b0414f417a4@haskell.org> #12962: No automatic SCC annotations for functions marked INLINABLE -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 8.0.1 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12963 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by MikolajKonarski): Splendid! (We really need a 'Like' button here.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 12 22:07:49 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Dec 2016 22:07:49 -0000 Subject: [GHC] #12899: ghc panics at random places with -jX In-Reply-To: <044.e06c34ff950f64285fd655be98faab7e@haskell.org> References: <044.e06c34ff950f64285fd655be98faab7e@haskell.org> Message-ID: <059.5f28cecc4e5f33275462c10479fd21fb@haskell.org> #12899: ghc panics at random places with -jX -------------------------------------+------------------------------------- Reporter: pacak | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by pacak): After recompilation in devel2 mode, one of the panics: {{{ : error: ghc: panic! (the 'impossible' happened) (GHC version 8.1.20161206 for x86_64-unknown-linux): applyTypeToArgs Expression: $fDataFixity_$cgmapQ @ (Exchange ByteString ByteString) @ Identity ($fProfunctorExchange @ ByteString @ ByteString) $fFunctorIdentity Type: forall u. (forall d. Data d => d -> u) -> Fixity -> [u] Args: [TYPE: Exchange ByteString ByteString, TYPE: Identity, $fProfunctorExchange @ ByteString @ ByteString, $fFunctorIdentity] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1114:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1118:37 in ghc:Outputable pprPanic, called at compiler/coreSyn/CoreUtils.hs:181:14 in ghc:CoreUtils Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 12 22:17:04 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Dec 2016 22:17:04 -0000 Subject: [GHC] #12963: Give -fexpose-all-unfoldings the same semantics as INLINABLE on each function In-Reply-To: <054.22fe7863b28eeadeb595cd63b5824204@haskell.org> References: <054.22fe7863b28eeadeb595cd63b5824204@haskell.org> Message-ID: <069.4f1a77f7e319ba9e0f703e457c74c082@haskell.org> #12963: Give -fexpose-all-unfoldings the same semantics as INLINABLE on each function -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12962 #12463 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by MikolajKonarski): * status: infoneeded => closed * resolution: => duplicate Comment: Oh, I didn't know the difference between `-fexpose-all-unfoldings` and giving all functions `INLINABLE` is so big and so well defined. Given that, I drop this feature request in favour of #12463. `RECURSIVE_SPECIALISABLE` fits my use case even better and in the worst case the proposal may reduce to something similar to `SPECIALISABLE_ALL`, so I will focus there. Thank you, Simon! Thank you, mpickering! Closing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 12 22:18:32 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Dec 2016 22:18:32 -0000 Subject: [GHC] #12463: SPECIALIZABLE pragma? In-Reply-To: <046.92ae6c231572298cabf5e2202d74c32b@haskell.org> References: <046.92ae6c231572298cabf5e2202d74c32b@haskell.org> Message-ID: <061.d6daa8d1a007fcfedf653e48eb940f44@haskell.org> #12463: SPECIALIZABLE pragma? -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by MikolajKonarski): I just wanted to confirm this feature is very much needed and point to a snippet of authoritative explanation of related things: https://ghc.haskell.org/trac/ghc/ticket/12963#comment:6 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 12 23:04:33 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Dec 2016 23:04:33 -0000 Subject: [GHC] #12550: Inconsistent unicode display for kinds In-Reply-To: <046.4e00c711f62582701b795cf12b5d8ff3@haskell.org> References: <046.4e00c711f62582701b795cf12b5d8ff3@haskell.org> Message-ID: <061.3b2e9673614acfecf576d08acd09c743@haskell.org> #12550: Inconsistent unicode display for kinds ----------------------------------+-------------------------------------- Reporter: johnleo | Owner: johnleo Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11660 #12030 | Differential Rev(s): Phab:D2829 Wiki Page: | ----------------------------------+-------------------------------------- Comment (by goldfire): Replying to [comment:9 johnleo]: > ... since internally they are all fundamentally the same thing. However this caused a panic in `PrelInfo.knownKeyNamesOkay` since apparently all keys have to be unique. I wonder if that condition could be relaxed. An entity in the compiler is identified by its Unique. So if two things have the same unique, then it's just one thing. In this case, if we have both stars have the same unique, it means, essentially, that GHC will arbitrarily pick one to print whenever it is printing, as it can't tell the difference. On the other hand, it might make more sense to have a special `OccName` that prints differently depending on whether unicode syntax is enabled. But I'm not sure it's worth the bother. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 13 02:03:07 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Dec 2016 02:03:07 -0000 Subject: [GHC] #12967: GHC 8.0.1 Panic for current Aeson 1.0.2.1 Message-ID: <048.15995c38bd0c9449abab339f2616c179@haskell.org> #12967: GHC 8.0.1 Panic for current Aeson 1.0.2.1 -------------------------------------+------------------------------------- Reporter: bitemyapp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ [1 of 1] Compiling Main ( Dates.hs, .stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build/aeson-benchmark-dates/aeson- benchmark-dates-tmp/Main.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): Simplifier ticks exhausted When trying UnfoldingDone $s>$< 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 To see detailed counts use -ddump-simpl-stats Total ticks: 153200 }}} I am not certain if this is a duplicate of: - https://ghc.haskell.org/trac/ghc/ticket/10083 - https://ghc.haskell.org/trac/ghc/ticket/12789 - https://ghc.haskell.org/trac/ghc/ticket/11263 - https://ghc.haskell.org/trac/ghc/ticket/5539 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 13 02:18:01 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Dec 2016 02:18:01 -0000 Subject: [GHC] #12747: INLINE vs NOINLINE vs give three different results; two would be better In-Reply-To: <054.339f6462cfb9fb131ebe3aa0fa842cb7@haskell.org> References: <054.339f6462cfb9fb131ebe3aa0fa842cb7@haskell.org> Message-ID: <069.4a46b06f0da54ae8abb779c4969113b1@haskell.org> #12747: INLINE vs NOINLINE vs give three different results; two would be better -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12603 #12781 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by MikolajKonarski): Actually, I now see INLINABLE is named similarly to INLINE only by coincidence and also by coincidence it's used (though it's much more powerful for that) together with inline as a per-call-side analogue of INLINE. I think what we need is more generally giving a precise and symmetric and orthogonal semantics to the optimization-related pragmas (including adding many more). If somebody writes a proper GHC proposal for that, please close this ticket and let's have the discussion there. I also hereby drop the feature request that the behaviour X of GHC in the absence of the pragma controlling X for a particular piece of code should be equivalent to the source code with pragma X or it's negation. I see GHC may control X in a much more fine-grained way than source code manipulation permits (e.g., at the level of Core), so it's OK (even if not ideal) if GHC produces something smarter than the programmer can possibly express. However, I still think major GHC optimizations should possess informal semantics in terms of source code manipulation and should be controllable via a complete set of pragmas that on the level of granularity available to the programmer produce exactly the same results as said source code manipulations. I think we need per-call-site, per-expression (where applicable), per-definition, recursive-per-definition (where applicable), per-module and per-project versions of local (only within the module) and global (everywhere) versions of positive and negative versions of INLINE, KEEP_UNFOLDING_IN_HI_FILE, SPECIALIZABLE (a part of what is currently INLINABLE), FLOAT_OUT and a few more pragmas for GHC optimizations that have or can be made to have the key property that they have a clear, simple semantics in terms of original source code transformation. Granted, a few of these combinations don't make sense, e.g., per-module and especially per-project INLINE. If GHC can do much smarter things for a chunk of program than what the simple source-manipulation semantics implies (e.g., by looking at other, distant bits of code or measuring sizes and complexity of Core resulting from subexpressions), let's keep the smart version to be used when neither pragma X nor it's negation is specified, or when some special pragma X_HIPER is given and let's nevertheless have pragma X do the simple, naive thing. I see this goes in the direction of meta-programming, but to the extent that GHC in fact does it, we should embrace meta-programming instead of hiding it. The fact that the meta-programming preserves semantics (and only changes performance), doesn't make it any less in need of proper, civilized support. Also note that while we want GHC to be as smart behind the scenes as possible in the final program, we want it to behave in explicit and simple way when we juggle pragmas while optimizing by experimentation or while debugging GHC itself. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 13 03:54:31 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Dec 2016 03:54:31 -0000 Subject: [GHC] #12968: GHC crash with TypeInType and pattern synonym Message-ID: <045.e5902e755bebc0a0dcc9bf7badbe59f9@haskell.org> #12968: GHC crash with TypeInType and pattern synonym -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I decided to try playing with the proposed new `Typeable` interface, faking up types and functions in GHC 8.0.1. Unfortunately, it seems I did something impossible: {{{#!hs {-# LANGUAGE TypeInType, GADTs, ScopedTypeVariables, PatternSynonyms, ViewPatterns #-} module TypeReflection where data TypeRep (a :: k) data TRAppG (fun :: k2) where TRAppG :: forall k1 (a :: k1 -> k2) (b :: k1) . TypeRep a -> TypeRep b -> TRAppG (a b) pattern TRApp :: forall k2 (fun :: k2). () => forall k1 (a :: k1 -> k2) (b :: k1). (fun ~ a b) => TypeRep a -> TypeRep b -> TypeRep fun pattern TRApp a b <- ((undefined :: TypeRep fun -> TRAppG fun) -> TRAppG a b) }}} The error: {{{ [1 of 1] Compiling TypeReflection ( TypeReflectionTemplate.hs, TypeReflectionTemplate.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): StgCmmEnv: variable not found $dIP_a1Aj local binds for: typeRep $tcTypeable $tc'C:Typeable $tcTypeRep $tc'TRAppG $WTRAppG $tcTRAppG $trModule $tcTRAppG1_r1KE $tc'TRAppG1_r1KS $tcTypeRep1_r1KT $tcTypeable1_r1KU $tc'C:Typeable1_r1KV $trModule1_r1KW $trModule2_r1KX scrut_s1Lg cont_s1Lh fail_s1Li sat_s1Lj sat_s1Lk sat_s1Ll sat_s1Lm sat_s1Ln sat_s1Lo sat_s1Lp sat_s1Lq sat_s1Lr sat_s1Ls sat_s1Lt }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 13 04:00:50 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Dec 2016 04:00:50 -0000 Subject: [GHC] #12969: Rebindable enumFrom etc. syntax Message-ID: <045.5772062aa85023583167120cc509b98f@haskell.org> #12969: Rebindable enumFrom etc. syntax -------------------------------------+------------------------------------- Reporter: cactus | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple RebindableSyntax | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Constructs like `[x..]` or `[x..y]` etc. seem to use wired-in `enumFrom`, `enumFromTo`, etc. names even when `RebindableSyntax` is turned on. I think we should allow these to be shadowed by the user the same way they can shadow other syntax desugarings. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 13 07:11:52 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Dec 2016 07:11:52 -0000 Subject: [GHC] #12955: Confusing error (module is not loaded) when more hsigs provided than -instantiated-with In-Reply-To: <045.af0dbd7cccb0e75a1e56a8bbe94489fa@haskell.org> References: <045.af0dbd7cccb0e75a1e56a8bbe94489fa@haskell.org> Message-ID: <060.e2caae002707f4e9be5193981af0d8fb@haskell.org> #12955: Confusing error (module is not loaded) when more hsigs provided than -instantiated-with -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"24f6bec94411aa6c39a2c94ce5154ffe96ae330f/ghc" 24f6bec9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="24f6bec94411aa6c39a2c94ce5154ffe96ae330f" Sanity check if we pick up an hsig file without -instantiated-with. Summary: Previously we would just let compilation proceed along until we tried to pull up the Module for the hsig file, and get main:A instead of , and get a mysterious error. Check for this earlier! Fixes #12955. Signed-off-by: Edward Z. Yang Test Plan: validate Reviewers: simonpj, austin, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2815 GHC Trac Issues: #12955 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 13 07:32:03 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Dec 2016 07:32:03 -0000 Subject: [GHC] #12955: Confusing error (module is not loaded) when more hsigs provided than -instantiated-with In-Reply-To: <045.af0dbd7cccb0e75a1e56a8bbe94489fa@haskell.org> References: <045.af0dbd7cccb0e75a1e56a8bbe94489fa@haskell.org> Message-ID: <060.b47e884733560186ac1a1aca9bbefabb@haskell.org> #12955: Confusing error (module is not loaded) when more hsigs provided than -instantiated-with -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 13 08:37:07 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Dec 2016 08:37:07 -0000 Subject: [GHC] #12708: RFC: Representation polymorphic Num In-Reply-To: <051.e9ad721b0c060306ebd4bf7d4de38fdd@haskell.org> References: <051.e9ad721b0c060306ebd4bf7d4de38fdd@haskell.org> Message-ID: <066.8fc9f4c59b731d5ca08cf85b680cc5b7@haskell.org> #12708: RFC: Representation polymorphic Num -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.1 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by oerjan): * cc: oerjan (added) Comment: Replying to [comment:11 goldfire]: > Replying to [comment:3 Iceland_jack]: > > Should this not be allowed when `minBound :: () -> a` is allowed? > > Because `blah :: Int#` is not allowed? This would actually be OK, because methods -- even nullary ones, like `minBound` are actually functions that take dictionaries. So we're OK here. The question is, how would you store the necessary `Int#` in the dictionary? It seems to me you'd have to use some kind of indirection because otherwise you have a dictionary field than can have arbitrary size. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 13 08:42:20 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Dec 2016 08:42:20 -0000 Subject: [GHC] #12873: hWaitForInput with socket as handle excepts on windows In-Reply-To: <044.1ddaa628578738df0ad8573626efc264@haskell.org> References: <044.1ddaa628578738df0ad8573626efc264@haskell.org> Message-ID: <059.53cbbbd85197e6256769a9a18b5480f9@haskell.org> #12873: hWaitForInput with socket as handle excepts on windows ----------------------------------+-------------------------------------- Reporter: bwurk | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #7353 | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Comment (by bwurk): Unfortunately, that would mean downgrading infrastructure and packages, so I'm curious to the changes which introduce this bug. As far as I can tell, there are no relevant changes in cbits/inputReady.c from 7.6.3 to recent versions of GHC which could have caused this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 13 09:30:19 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Dec 2016 09:30:19 -0000 Subject: [GHC] #12964: Runtime regression to RTS change In-Reply-To: <046.bcf824695cea07d48dc888c9a5c7fa61@haskell.org> References: <046.bcf824695cea07d48dc888c9a5c7fa61@haskell.org> Message-ID: <061.90b5b3b16bbc70dcdc92c207b930c857@haskell.org> #12964: Runtime regression to RTS change -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Runtime System | Version: 8.1 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: | -------------------------------------+------------------------------------- Comment (by simonmar): The fact that some of these tests seem to wobble around in response to unrelated changes suggests that it's something like an alignment or locality issue. These can be a pain to track down, especially when the difference is only 5%. The best plan of attack is to use perf to identify where the extra cycles are going (hopefully the extra 5% is localised in one place) and then go from there. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 13 10:09:05 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Dec 2016 10:09:05 -0000 Subject: [GHC] #12968: GHC crash with TypeInType and pattern synonym In-Reply-To: <045.e5902e755bebc0a0dcc9bf7badbe59f9@haskell.org> References: <045.e5902e755bebc0a0dcc9bf7badbe59f9@haskell.org> Message-ID: <060.62e022935099c9764afdd2d4100e2bc7@haskell.org> #12968: GHC crash with TypeInType and pattern synonym -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => closed * resolution: => fixed Comment: This is fixed in HEAD. I'm unsure which commit or ticket this is a duplicate of. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 13 11:50:30 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Dec 2016 11:50:30 -0000 Subject: [GHC] #12970: Add default implementation for Bits.bitSize Message-ID: <045.18bc248265b05555e123c1ad78e88bb9@haskell.org> #12970: Add default implementation for Bits.bitSize -------------------------------------+------------------------------------- Reporter: txnull | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: | Version: libraries/base | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I think it would be a good idea to provide a default implementation for bitSize, example: {{{#!hs bitSize b = fromMaybe (error "bitSize is undefined") (bitSizeMaybe b) }}} The advantage is that from now on new instances of Bits no longer need to define bitSize. And once bitSize has been removed there will be no errors about it not being a method of class Bits. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 13 14:55:33 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Dec 2016 14:55:33 -0000 Subject: [GHC] #12708: RFC: Representation polymorphic Num In-Reply-To: <051.e9ad721b0c060306ebd4bf7d4de38fdd@haskell.org> References: <051.e9ad721b0c060306ebd4bf7d4de38fdd@haskell.org> Message-ID: <066.0ac0eaafcca355a4367da04b409a6dcb@haskell.org> #12708: RFC: Representation polymorphic Num -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.1 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:25 oerjan]: > The question is, how would you store the necessary `Int#` in the dictionary? It seems to me you'd have to use some kind of indirection because otherwise you have a dictionary field than can have arbitrary size. Spot on. You're right -- we would have a problem with `Bounded`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 13 15:01:32 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Dec 2016 15:01:32 -0000 Subject: [GHC] #12968: GHC crash with TypeInType and pattern synonym In-Reply-To: <045.e5902e755bebc0a0dcc9bf7badbe59f9@haskell.org> References: <045.e5902e755bebc0a0dcc9bf7badbe59f9@haskell.org> Message-ID: <060.d90814929ed92fc3387030e69f24dc6a@haskell.org> #12968: GHC crash with TypeInType and pattern synonym -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): #12489, perhaps? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 13 15:07:48 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Dec 2016 15:07:48 -0000 Subject: [GHC] #12790: GHC 8.0.1 uses copious amounts of RAM and time when trying to compile lambdabot-haskell-plugins In-Reply-To: <044.6c4a4edd18cfc656391e8adc9c55d93a@haskell.org> References: <044.6c4a4edd18cfc656391e8adc9c55d93a@haskell.org> Message-ID: <059.75470a84365ea8043f633a2cea04919f@haskell.org> #12790: GHC 8.0.1 uses copious amounts of RAM and time when trying to compile lambdabot-haskell-plugins -------------------------------------+------------------------------------- Reporter: clint | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): To elaborate on the observation that enabling `-fprof-auto` fixes the slowdown, it's because if you add an `SCC` pragma for `list`: {{{#!hs {-# SCC list #-} list :: Parser Expr list = ... }}} Then it also fixes the slowdown. (`-fprof-auto` was just doing this under the hood). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 13 15:55:45 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Dec 2016 15:55:45 -0000 Subject: [GHC] #8248: GHCi should not fail to honour ghci.conf or .ghci if group writable In-Reply-To: <046.667caeee812579621ec3ac8601656752@haskell.org> References: <046.667caeee812579621ec3ac8601656752@haskell.org> Message-ID: <061.611d03d6db41bf0a9238f048891ee77f@haskell.org> #8248: GHCi should not fail to honour ghci.conf or .ghci if group writable -------------------------------------+------------------------------------- Reporter: afcowie | Owner: whisky Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: GHCi | Version: 7.6.3 Resolution: wontfix | Keywords: Operating System: Linux | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #9324 | Differential Rev(s): Phab:D805 Wiki Page: | -------------------------------------+------------------------------------- Comment (by anohigisavay): I just got hit by this issue. I have been using ACL for more granular permission control. I created two users to access different desktop environments to avoid certain conflict issues, while essentially they are the same user and should be able to access each other's home directory without any problem. When ACL is enabled the group permission bits in the traditional UGO mechanism act as the mask for ACL (i.e. the maximum available permission for ACL_USER, ACL_GROUP_OBJ and ACL_GROUP). Thus it must be set to `rw-` instead of `r--`. This limitation renders ACL ineffective for the home directory. While it is obviously overkilling for GHCi to consider all these security enhancement mechanisms (SELinux and others also exist), I suggest we can leave the choice between security and flexibility to the users. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 13 18:04:10 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Dec 2016 18:04:10 -0000 Subject: [GHC] #12968: GHC crash with TypeInType and pattern synonym In-Reply-To: <045.e5902e755bebc0a0dcc9bf7badbe59f9@haskell.org> References: <045.e5902e755bebc0a0dcc9bf7badbe59f9@haskell.org> Message-ID: <060.b34fe63e29cf2b358a04287c262546e0@haskell.org> #12968: GHC crash with TypeInType and pattern synonym -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #12489 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * related: => #12489 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 13 19:38:01 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Dec 2016 19:38:01 -0000 Subject: [GHC] #4505: Segmentation fault on long input (list of pairs) In-Reply-To: <046.2dc545b3c32e7b8eef61780dd9491ae5@haskell.org> References: <046.2dc545b3c32e7b8eef61780dd9491ae5@haskell.org> Message-ID: <061.bd08dad00f46200f3da1c06ed23a76d5@haskell.org> #4505: Segmentation fault on long input (list of pairs) -------------------------------------+------------------------------------- Reporter: cathper | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.0.1 Resolution: | Keywords: Segmentation | fault, segfault, long input Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: 4258 | Blocking: Related Tickets: | Differential Rev(s): Phab:D1180 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.0.2 => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 13 20:56:36 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Dec 2016 20:56:36 -0000 Subject: [GHC] #12903: SIGINT is not handled in forked process In-Reply-To: <045.73f1eb35eda69f56b71c66e83162bd9f@haskell.org> References: <045.73f1eb35eda69f56b71c66e83162bd9f@haskell.org> Message-ID: <060.23fb8491bbe2e34dfbf2f9cf785d9877@haskell.org> #12903: SIGINT is not handled in forked process -------------------------------------+------------------------------------- Reporter: qnikst | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2770 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.0.2 => 8.2.1 Comment: Given all of the trouble that this test has given us I'm afraid I'm going to need to revert in `ghc-8.0`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 13 20:58:42 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Dec 2016 20:58:42 -0000 Subject: [GHC] #12894: Bump directory In-Reply-To: <046.4beed447095342b2603c24699e3a82bd@haskell.org> References: <046.4beed447095342b2603c24699e3a82bd@haskell.org> Message-ID: <061.30e44093cba0618535e17e95a745960f@haskell.org> #12894: Bump directory -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: upstream => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 13 20:58:57 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Dec 2016 20:58:57 -0000 Subject: [GHC] #12880: Update to Cabal-1.24.1.1 In-Reply-To: <042.fed2f725f41f6702d6c9570271c8e9a1@haskell.org> References: <042.fed2f725f41f6702d6c9570271c8e9a1@haskell.org> Message-ID: <057.2502856078aa3cac083d17be8f46a79a@haskell.org> #12880: Update to Cabal-1.24.1.1 -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: closed Priority: high | Milestone: 8.0.2 Component: libraries | Version: 8.0.2-rc1 (other) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: upstream => closed * resolution: => fixed Comment: This was carried out in 6c6f9c1de4a548afccb3f5c557600987e87cb11e. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 13 21:23:49 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Dec 2016 21:23:49 -0000 Subject: [GHC] #12956: Something has broken T12903 In-Reply-To: <046.00d2d5d11cfef207ccca3cd778c78a40@haskell.org> References: <046.00d2d5d11cfef207ccca3cd778c78a40@haskell.org> Message-ID: <061.04bba8d8757d58fcb775b76347d9b587@haskell.org> #12956: Something has broken T12903 -----------------------------------+-------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------------+-------------------------------------- Comment (by Ben Gamari ): In [changeset:"aa123f445338c2980fcee87a09c01d14a83bf409/ghc" aa123f4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="aa123f445338c2980fcee87a09c01d14a83bf409" Fix testcase T12903 on OS X Old test used timeouts that leads to the various sporadic errors. Tet was rewritten to not use timeouts. Reviewers: austin, erikd, simonmar, bgamari Reviewed By: simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2827 GHC Trac Issues: #12956 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 13 21:23:49 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Dec 2016 21:23:49 -0000 Subject: [GHC] #9696: readRawBufferPtr and writeRawBufferPtr allocate memory In-Reply-To: <052.b427ad2427779cbbeba69c4df93a91d2@haskell.org> References: <052.b427ad2427779cbbeba69c4df93a91d2@haskell.org> Message-ID: <067.6d9ca3f6a061c44be1e222c23eb92f8e@haskell.org> #9696: readRawBufferPtr and writeRawBufferPtr allocate memory -------------------------------------+------------------------------------- Reporter: mergeconflict | Owner: Type: bug | Status: patch Priority: low | Milestone: 8.2.1 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2813 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"cc2e3ec06ce5ac979ff2ecf453ad85b0e5ff326d/ghc" cc2e3ec0/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="cc2e3ec06ce5ac979ff2ecf453ad85b0e5ff326d" base: Make raw buffer IO operations more strict Ticket #9696 reported that `readRawBufferPtr` and `writeRawBufferPtr` allocated unnecessarily. The binding is question was, ``` let { buf_s4VD [Dmd=] :: GHC.Ptr.Ptr GHC.Word.Word8 [LclId, Unf=OtherCon []] = NO_CCS GHC.Ptr.Ptr! [ds1_s4Vy]; } in case GHC.IO.FD.$wreadRawBufferPtr Main.main5 0# 0# buf_s4VD Main.main4 Main.main3 GHC.Prim.void# of ... ``` The problem was that GHC apparently couldn't tell that `readRawBufferPtr` would always demand the buffer. Here we simple add bang patterns on all of the small arguments of these functions to ensure that worker/wrappers can eliminate these allocations. Test Plan: Look at STG produced by testcase in #9696, verify no allocations Reviewers: austin, hvr, simonmar Reviewed By: simonmar Subscribers: RyanGlScott, simonmar, thomie Differential Revision: https://phabricator.haskell.org/D2813 GHC Trac Issues: #9696 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 13 21:23:49 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Dec 2016 21:23:49 -0000 Subject: [GHC] #12550: Inconsistent unicode display for kinds In-Reply-To: <046.4e00c711f62582701b795cf12b5d8ff3@haskell.org> References: <046.4e00c711f62582701b795cf12b5d8ff3@haskell.org> Message-ID: <061.8467d314e81682b5411de5c6f47e3015@haskell.org> #12550: Inconsistent unicode display for kinds ----------------------------------+-------------------------------------- Reporter: johnleo | Owner: johnleo Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11660 #12030 | Differential Rev(s): Phab:D2829 Wiki Page: | ----------------------------------+-------------------------------------- Comment (by Ben Gamari ): In [changeset:"7031704332db55de1fc3c46a8f450bad933997e0/ghc" 7031704/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7031704332db55de1fc3c46a8f450bad933997e0" print * in unicode correctly (fixes #12550) Test Plan: validate Reviewers: simonpj, austin, bgamari, goldfire Reviewed By: bgamari, goldfire Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2829 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 13 21:25:49 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Dec 2016 21:25:49 -0000 Subject: [GHC] #12550: Inconsistent unicode display for kinds In-Reply-To: <046.4e00c711f62582701b795cf12b5d8ff3@haskell.org> References: <046.4e00c711f62582701b795cf12b5d8ff3@haskell.org> Message-ID: <061.1ee83ce002f1e10454f8619a4e92519a@haskell.org> #12550: Inconsistent unicode display for kinds ----------------------------------+-------------------------------------- Reporter: johnleo | Owner: johnleo Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11660 #12030 | Differential Rev(s): Phab:D2829 Wiki Page: | ----------------------------------+-------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 13 21:26:01 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Dec 2016 21:26:01 -0000 Subject: [GHC] #12956: Something has broken T12903 In-Reply-To: <046.00d2d5d11cfef207ccca3cd778c78a40@haskell.org> References: <046.00d2d5d11cfef207ccca3cd778c78a40@haskell.org> Message-ID: <061.ca2800d0aec0d82050d7a3dacdd7e3bc@haskell.org> #12956: Something has broken T12903 -----------------------------------+-------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Runtime System | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------------+-------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 13 21:26:49 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Dec 2016 21:26:49 -0000 Subject: [GHC] #9696: readRawBufferPtr and writeRawBufferPtr allocate memory In-Reply-To: <052.b427ad2427779cbbeba69c4df93a91d2@haskell.org> References: <052.b427ad2427779cbbeba69c4df93a91d2@haskell.org> Message-ID: <067.efc813eb51a553dac15a97dd73bcf6a0@haskell.org> #9696: readRawBufferPtr and writeRawBufferPtr allocate memory -------------------------------------+------------------------------------- Reporter: mergeconflict | Owner: Type: bug | Status: closed Priority: low | Milestone: 8.2.1 Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2813 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 13 21:57:46 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Dec 2016 21:57:46 -0000 Subject: [GHC] #9832: Get rid of PERL dependency of `ghc-split` In-Reply-To: <042.a80d180822707ef08b1350d4a542cee3@haskell.org> References: <042.a80d180822707ef08b1350d4a542cee3@haskell.org> Message-ID: <057.54c4d91a74ad139ef96b1781f30faabd@haskell.org> #9832: Get rid of PERL dependency of `ghc-split` ---------------------------------+---------------------------------------- Reporter: hvr | Owner: dobenour Type: task | Status: patch Priority: normal | Milestone: 8.2.1 Component: Driver | Version: Resolution: | Keywords: perl Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8405 | Differential Rev(s): Phab:D2768 Wiki Page: | ---------------------------------+---------------------------------------- Changes (by bgamari): * status: new => patch * differential: D2768 => Phab:D2768 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 13 21:59:37 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Dec 2016 21:59:37 -0000 Subject: [GHC] #7860: Add more bit fiddling functions to 'integer-gmp' In-Reply-To: <046.cf50459cade182946253e5602ab21f1f@haskell.org> References: <046.cf50459cade182946253e5602ab21f1f@haskell.org> Message-ID: <061.614821fdbdd86b444114a6bc213d2138@haskell.org> #7860: Add more bit fiddling functions to 'integer-gmp' -------------------------------------+------------------------------------- Reporter: lebedev | Owner: hvr Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Core Libraries | Version: 7.6.3 Resolution: | Keywords: integer-gmp Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #3489, #9835 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.4.1 Comment: It doesn't look like this will happen for 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 13 22:00:02 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Dec 2016 22:00:02 -0000 Subject: [GHC] #8440: Get rid of the remaining static flags In-Reply-To: <052.744af3e10192bedb98c0b515d9a6cc6d@haskell.org> References: <052.744af3e10192bedb98c0b515d9a6cc6d@haskell.org> Message-ID: <067.a8853fa8fb5e19a18c42e9df9786108e@haskell.org> #8440: Get rid of the remaining static flags -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.4.1 Comment: It is unlikely this will happen for 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 13 22:02:19 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Dec 2016 22:02:19 -0000 Subject: [GHC] #9244: Compiler could warn about type variable shadowing, and hint about ScopedTypeVariables In-Reply-To: <047.4ca6fb75e0604e66c9de7145ac89f916@haskell.org> References: <047.4ca6fb75e0604e66c9de7145ac89f916@haskell.org> Message-ID: <062.8533e5363e427e7bc17058cf426f4a71@haskell.org> #9244: Compiler could warn about type variable shadowing, and hint about ScopedTypeVariables -------------------------------------+------------------------------------- Reporter: stusmith | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #1316, #3691, | Differential Rev(s): #11438, #10581, #11539, #12716 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.4.1 Comment: It doesn't look like this will happen for 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 13 22:04:01 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Dec 2016 22:04:01 -0000 Subject: [GHC] #7860: Add more bit fiddling functions to 'integer-gmp' In-Reply-To: <046.cf50459cade182946253e5602ab21f1f@haskell.org> References: <046.cf50459cade182946253e5602ab21f1f@haskell.org> Message-ID: <061.aedfe82466083461b804663310f49306@haskell.org> #7860: Add more bit fiddling functions to 'integer-gmp' -------------------------------------+------------------------------------- Reporter: lebedev | Owner: hvr Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Core Libraries | Version: 7.6.3 Resolution: | Keywords: integer-gmp Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #3489, #9835 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): Just for the record, I did start a couple months ago (http://git.haskell.org/ghc.git/shortlog/refs/heads/wip/T7860) before I shifted attention to more urgent tasks -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 13 22:04:52 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Dec 2016 22:04:52 -0000 Subject: [GHC] #9601: Make the rewrite rule system more powerful In-Reply-To: <050.d0198153d3c3c67b578255419aefe8e8@haskell.org> References: <050.d0198153d3c3c67b578255419aefe8e8@haskell.org> Message-ID: <065.e1ccd3b95c7b01c00deba63b88b647de@haskell.org> #9601: Make the rewrite rule system more powerful -------------------------------------+------------------------------------- Reporter: spacekitteh | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9137, #10804 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => Comment: Removing milestone as this is more of a long-term goal. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 13 22:05:43 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Dec 2016 22:05:43 -0000 Subject: [GHC] #3427: control what sort of entity a deprecated pragma applies to In-Reply-To: <044.6e5c26a8435c2fcde3f9de3ab4769428@haskell.org> References: <044.6e5c26a8435c2fcde3f9de3ab4769428@haskell.org> Message-ID: <059.2cac8ca06f779176e44fe8891cd057fd@haskell.org> #3427: control what sort of entity a deprecated pragma applies to -------------------------------------+------------------------------------- Reporter: igloo | Owner: thoughtpolice Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 6.10.4 Resolution: | Keywords: deprecate | warning Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.4.1 Comment: This won't happen for 8.2 although it would be great if someone could pick this up for 8.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 13 22:14:42 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Dec 2016 22:14:42 -0000 Subject: [GHC] #12964: Runtime regression to RTS change In-Reply-To: <046.bcf824695cea07d48dc888c9a5c7fa61@haskell.org> References: <046.bcf824695cea07d48dc888c9a5c7fa61@haskell.org> Message-ID: <061.68648907531c2bb9e54a1cd1d888ce6d@haskell.org> #12964: Runtime regression to RTS change -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 8.1 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 nomeata): * priority: highest => normal Comment: Further measurements show that the wobbling of `hidden` correlates with changes to the RTS, but it also changed due to changeset:514c01eec5f2b23f278c29b61345dce6c37900f1. There seems to be a performance cliff of sorts, which is very annoying when trying to keep tabs on performance, but probably not a high priority blocker for the release, especially as it is likely not a simple bug introduced by any single commit. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 13 22:26:29 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Dec 2016 22:26:29 -0000 Subject: [GHC] #12971: gcc not finding default temporary directory Message-ID: <051.d90144b3c0ebb71e2cb75f2b09f4ef06@haskell.org> #12971: gcc not finding default temporary directory -------------------------------------+------------------------------------- Reporter: erikprantare | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hello, I've been trying to get the ghc to compile a .hs file to binary. I get an error that seems to be caused during the C compilation phase from the special character ä in my user directory. When compiling I get this: {{{ C:\Users\Erik Präntare>ghc C:\code\Haskell\test.hs Linking C:\code\Haskell\test.exe ... realgcc.exe: error: C:\Users\Erik Pr├ñntare\AppData\Local\Temp\ghc28912_0\ghc_1. c: No such file or directory realgcc.exe: fatal error: no input files compilation terminated. `gcc.exe' failed in phase `C Compiler'. (Exit code: 1) }}} Notice how it says Pr├ñntare instead of Präntare. The UTF-8 encoding for ä is 0xC3 0xA4 which, surprise surprise, corresponds to ├ñ in ASCII. Now, I managed to get around this by changing the tmpdir to my actual temporary directory, but as a new user of ghc it was very troublesome to find a solution. Maybe consider changing the default tmpdir, at least if special characters are encountered? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 13 22:30:42 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Dec 2016 22:30:42 -0000 Subject: [GHC] #12971: Change default tmpdir (was: gcc not finding default temporary directory) In-Reply-To: <051.d90144b3c0ebb71e2cb75f2b09f4ef06@haskell.org> References: <051.d90144b3c0ebb71e2cb75f2b09f4ef06@haskell.org> Message-ID: <066.c368b85559282b58fd484ffc636eb15c@haskell.org> #12971: Change default tmpdir -------------------------------------+------------------------------------- Reporter: erikprantare | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 13 23:17:42 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Dec 2016 23:17:42 -0000 Subject: [GHC] #12972: Missed specialisation opportunity with phantom type class parameter? Message-ID: <049.64f963aad64381fca27b6f57df680357@haskell.org> #12972: Missed specialisation opportunity with phantom type class parameter? -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I am unsure of my analysis of this code fragment. It seems like we could do a better job optimising `test3`. First the code, then the analysis at the bottom. {{{#!hs {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE RoleAnnotations #-} {-# LANGUAGE IncoherentInstances #-} module Foo where data Proxy a = Proxy --type role Phantom phantom nominal class Phantom x a | a -> x where method :: a method1 :: a instance Phantom x (Proxy x) where method = Proxy method1 = Proxy -- This doesn't optimise test3 :: Phantom x (Proxy x) => Proxy x test3 = method -- This does optimise instance Phantom Char Int where method = 5 method1 = 5 test4 :: Phantom x Int => Int test4 = method }}} Here is the relevant part of the core {{{#!hs -- RHS size: {terms: 4, types: 9, coercions: 0} test3 test3 = \ @ x_ayL $dPhantom_ayS -> method $dPhantom_ayS -- RHS size: {terms: 3, types: 5, coercions: 0} test4 test4 = \ @ x_ayz _ -> $cmethod1_az4 }}} In `test4` the dictionary selector `method` is eliminated but in the analogous case `test3` where `x` is used in both arguments then `method` is not specialised. It seems that we could do a similar specialisation and ultimately replace the dictionary with `Proxy` as `x` is phantom. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 14 00:37:27 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Dec 2016 00:37:27 -0000 Subject: [GHC] #7206: Implement cheap build In-Reply-To: <046.231132dc13e5eec24b09b65a3836eff3@haskell.org> References: <046.231132dc13e5eec24b09b65a3836eff3@haskell.org> Message-ID: <061.ec129ef7437d950cee2f127f2c778fd7@haskell.org> #7206: Implement cheap build -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 7.4.2 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 MikolajKonarski): * cc: MikolajKonarski (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 14 03:24:31 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Dec 2016 03:24:31 -0000 Subject: [GHC] #12973: No levity-polymorphic arguments Message-ID: <047.f204ee30fb0e348fef5e84b6439839c8@haskell.org> #12973: No levity-polymorphic arguments -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple LevityPolymorphism | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- As discussed in our [http://cs.brynmawr.edu/~rae/papers/2017/levity/levity.pdf draft paper] on levity polymorphism, you cannot have a levity-polymorphic argument. Here is an example: {{{#!hs {-# LANGUAGE RebindableSyntax, TypeInType, ExplicitForAll #-} module Bug where import qualified Prelude as P import GHC.Exts class Num (a :: TYPE r) where (+) :: a -> a -> a fromInteger :: P.Integer -> a foo :: forall (a :: TYPE r). Num a => a foo = 3 + 4 }}} HEAD panics in `kindPrimRep`, but the code should be rejected. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 14 03:57:38 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Dec 2016 03:57:38 -0000 Subject: [GHC] #12832: GHC infers too simplified contexts In-Reply-To: <046.c1f3ff2a9ca4d830d3e52f2f57c4f3ec@haskell.org> References: <046.c1f3ff2a9ca4d830d3e52f2f57c4f3ec@haskell.org> Message-ID: <061.be6236de094324ee2389cf60989b2052@haskell.org> #12832: GHC infers too simplified contexts -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: high | Milestone: 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by danilo2): @simon, I understand this note (to some degree) and its motivation. In its example it makes perfect sense not to throw an overlap error and compile just fine. But in my example it is just wrong nad I dont see any reason for it (maybe I dont understand something here). Anyway – when I create: {{{ instance Run m Int where run = test }}} It could be possible that I wanted to choose the `Test IM a` as constraint. It could be possible and it would make sense here. Exactly the same sense as the second option available. Why is GHC just blindly choosing one option and throwing a very misguiding error to the user? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 14 04:14:51 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Dec 2016 04:14:51 -0000 Subject: [GHC] #12944: ghc master (8.1.20161206) panics with assertion failure with devel2 flavor and -O In-Reply-To: <044.3fe8817d41680dd8c67e674ebd7c6a0f@haskell.org> References: <044.3fe8817d41680dd8c67e674ebd7c6a0f@haskell.org> Message-ID: <059.e773e85b8785ac1fdb438bbc481f9f77@haskell.org> #12944: ghc master (8.1.20161206) panics with assertion failure with devel2 flavor and -O -------------------------------------+------------------------------------- Reporter: pacak | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by pacak): If I comment out this assertion there are other failures on the same code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 14 04:15:16 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Dec 2016 04:15:16 -0000 Subject: [GHC] #12973: No levity-polymorphic arguments In-Reply-To: <047.f204ee30fb0e348fef5e84b6439839c8@haskell.org> References: <047.f204ee30fb0e348fef5e84b6439839c8@haskell.org> Message-ID: <062.7c6918bf67d57c3bad7ee06d5d3dadee@haskell.org> #12973: No levity-polymorphic arguments -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): This is subtler than we realized in the paper. Consider {{{#!hs data (a :: k1) :~~: (b :: k2) where HRefl :: a :~~: a bar :: forall (r :: RuntimeRep) (a :: TYPE r). a :~~: Int -> a bar HRefl = 3 + 4 }}} Well? What do we think? Is that good or bad? It depends on how GHC inserts the coercions. :( In HEAD, this panics as written. But if I make the RHS to be `3 + 4 :: Int`, then it compiles. The question is whether GHC chooses to desugar the RHS to {{{ (+) @a (fromInteger @a 3) (fromInteger @a 4) }}} or to {{{ (+) @Int (fromInteger @Int 3) (fromInteger @Int 4) |> co }}} where `co` can cast from `Int` to `a`. The former is much more obvious in this case, but there's nothing actually wrong about the latter. And I'm sure some scenarios won't be as easy to guess what might happen under the hood. I think this question is more fundamental than just predictable type inference. For example, is this Core well typed: {{{f (x |> co)}}} What if the left-hand type of `co` is levity polymorphic? What if the right-hand type is? And what happens in the code generator when it sees such a construct? Presumably, it just ignores casts. This tells us that we care about `co`'s left-hand type. But now what if we substitute `x :-> y |> co'`. If `y` looks levity-polymorphic while `x` does not, this substitution has brought us from a well typed program to an ill typed one. Disaster! I thus go to sleep troubled. Hopefully wisdom strikes in the night, either in my sleep or on this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 14 05:32:23 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Dec 2016 05:32:23 -0000 Subject: [GHC] #12944: ghc master (8.1.20161206) panics with assertion failure with devel2 flavor and -O In-Reply-To: <044.3fe8817d41680dd8c67e674ebd7c6a0f@haskell.org> References: <044.3fe8817d41680dd8c67e674ebd7c6a0f@haskell.org> Message-ID: <059.8fd91b97b0fee09819b67f729f0b1388@haskell.org> #12944: ghc master (8.1.20161206) panics with assertion failure with devel2 flavor and -O -------------------------------------+------------------------------------- Reporter: pacak | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): It sounds very much like uniques are overflowing. We are working on confirming this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 14 05:32:47 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Dec 2016 05:32:47 -0000 Subject: [GHC] #12944: ghc master (8.1.20161206) panics with assertion failure with devel2 flavor and -O In-Reply-To: <044.3fe8817d41680dd8c67e674ebd7c6a0f@haskell.org> References: <044.3fe8817d41680dd8c67e674ebd7c6a0f@haskell.org> Message-ID: <059.12c2a432253d96d85327641d84463fe2@haskell.org> #12944: ghc master (8.1.20161206) panics with assertion failure with devel2 flavor and -O -------------------------------------+------------------------------------- Reporter: pacak | Owner: Type: bug | Status: patch Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2844 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D2844 Comment: Here is a patch fixing some of the fragility of the current unique setup. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 14 10:12:14 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Dec 2016 10:12:14 -0000 Subject: [GHC] #12603: INLINE and manually inlining produce different code In-Reply-To: <046.944cd4788eed55470361e7f38358ac43@haskell.org> References: <046.944cd4788eed55470361e7f38358ac43@haskell.org> Message-ID: <061.6cc7204ccc5e28152ab0c9af3c5fd677@haskell.org> #12603: INLINE and manually inlining produce different code -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #12747 #12781 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by MikolajKonarski): > Mikolaj, I think the above patch will make it robust for you. Can you check? Thank you. I will check and report back, when your patch is back in HEAD and when I manage to make my package compile with HEAD (the parsec problem is gone; thank you; I'm currently prodding maintainers of other packages that I depends on, mostly broken due to changes in cabal). This way I can avoid compiling GHC and instead use some nightly HEAD build (e.g. the one here https://launchpad.net/~hvr/+archive/ubuntu/ghc). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 14 12:09:38 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Dec 2016 12:09:38 -0000 Subject: [GHC] #12967: GHC 8.0.1 Panic for current Aeson 1.0.2.1 In-Reply-To: <048.15995c38bd0c9449abab339f2616c179@haskell.org> References: <048.15995c38bd0c9449abab339f2616c179@haskell.org> Message-ID: <063.2e97f98ea1af756a6c5c06dbae1eeb13@haskell.org> #12967: GHC 8.0.1 Panic for current Aeson 1.0.2.1 -------------------------------------+------------------------------------- Reporter: bitemyapp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Did you try increasing the tick limit as the message suggests? How high did you have to turn it up? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 14 12:11:37 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Dec 2016 12:11:37 -0000 Subject: [GHC] #12747: INLINE vs NOINLINE vs give three different results; two would be better In-Reply-To: <054.339f6462cfb9fb131ebe3aa0fa842cb7@haskell.org> References: <054.339f6462cfb9fb131ebe3aa0fa842cb7@haskell.org> Message-ID: <069.76f4397c12a653820d04b69c42b4efa0@haskell.org> #12747: INLINE vs NOINLINE vs give three different results; two would be better -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12603 #12781 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > However, I still think major GHC optimizations should possess informal semantics in terms of source code manipulation and should be controllable via a complete set of pragmas that on the level of granularity available to the programmer produce exactly the same results as said source code manipulations I'm all for that in principle. It just needs someone to devise a design, and then implement it. A complicating factor with any per-definition control is that GHC's inlining means that that functions get inlined into each other like crazy, so it's never clear where one function begins and another ends. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 14 13:23:41 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Dec 2016 13:23:41 -0000 Subject: [GHC] #12973: No levity-polymorphic arguments In-Reply-To: <047.f204ee30fb0e348fef5e84b6439839c8@haskell.org> References: <047.f204ee30fb0e348fef5e84b6439839c8@haskell.org> Message-ID: <062.89e7ba5440f2f659d791a916bfa2b32f@haskell.org> #12973: No levity-polymorphic arguments -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Something struck in the night. Time will tell if it was wisdom. The idea is this: the representation choice of an argument is properly a property of the ''function'', not the ''argument''. So, in Core at least, when examining `f (x |> co)`, we care about the argument type of `f`, not that of `x` or `co`. (Of course, if it's well typed, the right-hand type of `co` matches the argument type of `f`.) So the Core levity polymorphism check does ''not'' look under coercions. However, this means that the code generator must also not look under coercions when compiling arguments (that is, when converting to ANF). Does this already happen? Perhaps, as I look at !CorePrep. But then is this respected further on down the compilation chain? (That is, how are coerced arguments handled in STG and beyond?) I do see that we simply drop casts in !CoreToStg; no surprise there. And I suppose that, at this point, we're already in ANF form, so any arguments are bound to ids that have the right type.... so maybe it's all OK. I'd love confirmation. Even if this all works out at the Core level, we still have a type inference challenge. Maybe the solution is simply to punt, arguing that the user is playing with fire and so sometimes will get burnt. By "punt" here, I mean that GHC just has a little unpredictability in this area. (Indeed, this is already the case, as discussed in the paper around trouble generalizing levity variables.) Maybe this is the real wisdom here: keep calm, carry on, and hope it all works. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 14 13:33:53 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Dec 2016 13:33:53 -0000 Subject: [GHC] #12974: Solution to regular expression is no longer valid Message-ID: <049.7341c9cdb661fd57e27a365180236c9a@haskell.org> #12974: Solution to regular expression is no longer valid -------------------------------------+------------------------------------- Reporter: pjljvdlaar | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following HUnit test code {{{#!hs module Main where import Test.HUnit import Text.Regex.Posix testRegexSimple :: Test testRegexSimple = TestCase $ do assertBool "pattern matches regex ^(a)|(p)$" ( "p" =~ "^(a)|(p)$" ) testRegex :: Test testRegex = TestCase $ do assertBool "pattern matches regex ^(ab+c*d?)|(ef{2}g{3,6}h{3,})|(p)$" ( "p" =~ "^(ab+c*d?)|(ef{2}g{3,6}h{3,})|(p)$" ) tests = TestList [ TestLabel "Regex Simple" testRegexSimple, TestLabel "Regex" testRegex ] main :: IO Counts main = do runTestTT tests }}} runs perfectly using Haskell platform 2013.2.0.0 with ghc 7.6.3. However, on stack LTS 7.13 with ghc 8.0.1 the second test fails! I assume this behaviour is the result of a bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 14 13:37:33 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Dec 2016 13:37:33 -0000 Subject: [GHC] #12974: Solution to regular expression is no longer valid In-Reply-To: <049.7341c9cdb661fd57e27a365180236c9a@haskell.org> References: <049.7341c9cdb661fd57e27a365180236c9a@haskell.org> Message-ID: <064.e0bfc39870f95adca9fd0d03dc9cb512@haskell.org> #12974: Solution to regular expression is no longer valid ---------------------------------+---------------------------------------- Reporter: pjljvdlaar | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: regex Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by pjljvdlaar): * keywords: => regex * os: Unknown/Multiple => Windows -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 14 13:38:54 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Dec 2016 13:38:54 -0000 Subject: [GHC] #12974: Solution to regular expression is no longer valid In-Reply-To: <049.7341c9cdb661fd57e27a365180236c9a@haskell.org> References: <049.7341c9cdb661fd57e27a365180236c9a@haskell.org> Message-ID: <064.44c4231c8987d697caf063d0f9782be6@haskell.org> #12974: Solution to regular expression is no longer valid ---------------------------------+-------------------------------------- Reporter: pjljvdlaar | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: regex Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Changes (by pjljvdlaar): * architecture: Unknown/Multiple => x86_64 (amd64) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 14 13:53:45 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Dec 2016 13:53:45 -0000 Subject: [GHC] #12974: Solution to regular expression is no longer valid In-Reply-To: <049.7341c9cdb661fd57e27a365180236c9a@haskell.org> References: <049.7341c9cdb661fd57e27a365180236c9a@haskell.org> Message-ID: <064.fbf0d7744f2df68b84b6e222c2f63b1c@haskell.org> #12974: Solution to regular expression is no longer valid ---------------------------------+-------------------------------------- Reporter: pjljvdlaar | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: regex Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by mpickering): Is this a bug in GHC or a bug in the regular expression library? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 14 15:02:36 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Dec 2016 15:02:36 -0000 Subject: [GHC] #12975: Suggested type signature for a pattern synonym causes program to fail to type check Message-ID: <047.5d9fc0ffb90d93bc2d5a96bef52c66e8@haskell.org> #12975: Suggested type signature for a pattern synonym causes program to fail to type check -------------------------------------+------------------------------------- Reporter: ocharles | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple patternsynonyms | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Take the following program: {{{#!hs {-# LANGUAGE ViewPatterns, PatternSynonyms, RankNTypes, GADTs #-} import Data.Typeable data T where MkT :: Typeable a => a -> T pattern Cast a <- MkT (cast -> Just a) }}} When compiled with `-Wall`, GHC rightly prompts about a missing signature on `Cast`: {{{ Top-level binding with no type signature: Cast :: forall b. Typeable b => forall a. Typeable a => b -> T }}} However, using this suggested type signature causes the program to fail to type check: {{{#!hs • Could not deduce (Typeable a0) arising from the "provided" constraints claimed by the signature of ‘Cast’ from the context: Typeable a bound by a pattern with constructor: MkT :: forall a. Typeable a => a -> T, in a pattern synonym declaration at ../foo.hs:9:19-38 In other words, a successful match on the pattern MkT (cast -> Just a) does not provide the constraint (Typeable a0) The type variable ‘a0’ is ambiguous • In the declaration for pattern synonym ‘Cast’ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 14 15:07:33 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Dec 2016 15:07:33 -0000 Subject: [GHC] #12975: Suggested type signature for a pattern synonym causes program to fail to type check In-Reply-To: <047.5d9fc0ffb90d93bc2d5a96bef52c66e8@haskell.org> References: <047.5d9fc0ffb90d93bc2d5a96bef52c66e8@haskell.org> Message-ID: <062.1acf4bc4cc6bba00da078eb4740dfc19@haskell.org> #12975: Suggested type signature for a pattern synonym causes program to fail to type check -------------------------------------+------------------------------------- Reporter: ocharles | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: | patternsynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ocharles): I actually believe the correct type of this pattern is {{{#!hs pattern Cast :: () => Typeable a => a -> T pattern Cast a <- MkT (cast -> Just a) }}} But this is also rejected: {{{ • Could not deduce (Typeable a0) arising from a use of ‘cast’ from the context: Typeable a bound by a pattern with constructor: MkT :: forall a. Typeable a => a -> T, in a pattern synonym declaration at ../foo.hs:9:19-38 The type variable ‘a0’ is ambiguous • In the pattern: cast -> Just a In the pattern: MkT (cast -> Just a) In the declaration for pattern synonym ‘Cast’ }}} I may be wrong with that type though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 14 15:14:20 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Dec 2016 15:14:20 -0000 Subject: [GHC] #12975: Suggested type signature for a pattern synonym causes program to fail to type check In-Reply-To: <047.5d9fc0ffb90d93bc2d5a96bef52c66e8@haskell.org> References: <047.5d9fc0ffb90d93bc2d5a96bef52c66e8@haskell.org> Message-ID: <062.47d40ce224d95c555d043a48c868884e@haskell.org> #12975: Suggested type signature for a pattern synonym causes program to fail to type check -------------------------------------+------------------------------------- Reporter: ocharles | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: patternsynonyms => PatternSynonyms Comment: The type signature you are looking for is... {{{#!hs pattern Cast :: Typeable b => b -> T pattern Cast a <- MkT (cast -> Just a) }}} `cast` has type `(Typeable a, Typeable b) => a -> Maybe b`, as `MkT` provides `Typeable a` for us, we require `Typeable b` in order to use the function. The inferred type is still wrong in HEAD. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 14 15:15:59 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Dec 2016 15:15:59 -0000 Subject: [GHC] #12975: Suggested type signature for a pattern synonym causes program to fail to type check In-Reply-To: <047.5d9fc0ffb90d93bc2d5a96bef52c66e8@haskell.org> References: <047.5d9fc0ffb90d93bc2d5a96bef52c66e8@haskell.org> Message-ID: <062.ea77b1d96d42e83eb1d1dba995114099@haskell.org> #12975: Suggested type signature for a pattern synonym causes program to fail to type check -------------------------------------+------------------------------------- Reporter: ocharles | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ocharles): If I only supply one context, which context am I supplying? The provided one, or the required one? That is, are you suggesting `pattern Cast :: () => Typeable b => ...` or `pattern Cast :: Typeable b => () => ...`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 14 15:19:50 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Dec 2016 15:19:50 -0000 Subject: [GHC] #12975: Suggested type signature for a pattern synonym causes program to fail to type check In-Reply-To: <047.5d9fc0ffb90d93bc2d5a96bef52c66e8@haskell.org> References: <047.5d9fc0ffb90d93bc2d5a96bef52c66e8@haskell.org> Message-ID: <062.bcca4b84ea4c8d1d13c08ce6e1b6eef3@haskell.org> #12975: Suggested type signature for a pattern synonym causes program to fail to type check -------------------------------------+------------------------------------- Reporter: ocharles | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): The required one. `req => t` is the same as `req => () => t`. This is different from the first implementation, we changed it last release. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 14 16:22:06 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Dec 2016 16:22:06 -0000 Subject: [GHC] #12976: GHCi displays the kinds of unboxed tuples incorrectly Message-ID: <050.bfe267d1fb78d199eecf7450a8a79f6e@haskell.org> #12976: GHCi displays the kinds of unboxed tuples incorrectly -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This can be reproduced in GHCi 8.0.2 or HEAD. First, a preamble: {{{ $ inplace/bin/ghc-stage2 --interactive GHCi, version 8.1.20161208: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci λ> :set -fprint-explicit-runtime-reps -fprint-explicit-kinds -fprint- explicit-foralls -XUnboxedTuples -XTemplateHaskell -XMagicHash λ> :m + GHC.Exts Language.Haskell.TH Language.Haskell.TH.Lib Language.Haskell.TH.Syntax }}} The kind of `(#,#)` is reported correctly: {{{ (#,#) :: forall (k0 :: RuntimeRep) (k1 :: RuntimeRep). TYPE k0 -> TYPE k1 -> TYPE 'UnboxedTupleRep }}} But when you give it an argument, it seems to default `TYPE k1` to `*` for some reason! {{{ λ> :k (#,#) Int# (#,#) Int# :: * -> TYPE 'UnboxedTupleRep }}} This is a blatant lie, as this kind-checks: {{{ λ> :k (#,#) Int# Int# (#,#) Int# Int# :: TYPE 'UnboxedTupleRep }}} The effect is even more noticeable when you throw `TemplateHaskell` into the mix: {{{ λ> :k $(unboxedTupleT 2) $(unboxedTupleT 2) :: * -> * -> TYPE 'UnboxedTupleRep λ> :k $(unboxedTupleT 2) Int# $(unboxedTupleT 2) Int# :: * -> TYPE 'UnboxedTupleRep λ> :k $(conT (unboxedTupleTypeName 2)) $(conT (unboxedTupleTypeName 2)) :: * -> * -> TYPE 'UnboxedTupleRep λ> :k $(conT (unboxedTupleTypeName 2)) Int# $(conT (unboxedTupleTypeName 2)) Int# :: * -> TYPE 'UnboxedTupleRep }}} All of these kinds should be reporting the `RuntimeRep`s that GHC is //actually// using under the hood. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 14 16:24:23 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Dec 2016 16:24:23 -0000 Subject: [GHC] #12976: GHCi displays the kinds of unboxed tuples incorrectly In-Reply-To: <050.bfe267d1fb78d199eecf7450a8a79f6e@haskell.org> References: <050.bfe267d1fb78d199eecf7450a8a79f6e@haskell.org> Message-ID: <065.58ef0f0379d811cbe26dfc036db6aad2@haskell.org> #12976: GHCi displays the kinds of unboxed tuples incorrectly -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): This also affects unboxed sums, unsurprisingly: {{{ λ> :set -fprint-explicit-runtime-reps -fprint-explicit-kinds -fprint- explicit-foralls -XUnboxedSums -XTemplateHaskell -XMagicHash λ> :m + GHC.Exts Language.Haskell.TH Language.Haskell.TH.Lib Language.Haskell.TH.Syntax λ> :k $(unboxedSumT 2) $(unboxedSumT 2) :: * -> * -> TYPE 'UnboxedSumRep λ> :k $(unboxedSumT 2) Int# $(unboxedSumT 2) Int# :: * -> TYPE 'UnboxedSumRep }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 14 16:30:01 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Dec 2016 16:30:01 -0000 Subject: [GHC] #12974: Solution to regular expression is no longer valid In-Reply-To: <049.7341c9cdb661fd57e27a365180236c9a@haskell.org> References: <049.7341c9cdb661fd57e27a365180236c9a@haskell.org> Message-ID: <064.b30c224fe7f1a69c99638693f5c61770@haskell.org> #12974: Solution to regular expression is no longer valid ---------------------------------+-------------------------------------- Reporter: pjljvdlaar | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: regex Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by rwbarton): Hard to imagine it could be a GHC bug. However Haskell platform 2013.2.0.0 and LTS 7.13 both have the same version regex-posix 0.95.2 and on Windows the regex engine even appears to be bundled as C source within the Cabal package... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 14 16:40:13 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Dec 2016 16:40:13 -0000 Subject: [GHC] #12977: Template Haskell: unboxedTupleTypeName doesn't handle unboxed 0- and 1-tuples Message-ID: <050.5008aa7e061a856376f030d970571fea@haskell.org> #12977: Template Haskell: unboxedTupleTypeName doesn't handle unboxed 0- and 1-tuples -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.0.1 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC has a notion of unboxed 0-tuples and 1-tuples: {{{ λ> :set -XUnboxedTuples λ> :k (##) (##) :: TYPE 'GHC.Types.VoidRep λ> :k (# Int #) (# Int #) :: TYPE 'GHC.Types.UnboxedTupleRep }}} But it is impossible to acquire the `Name`s of these type constructors using `unboxedTupleTypeName` from `template-haskell`: {{{ λ> :set -XTemplateHaskell λ> :m + Language.Haskell.TH Language.Haskell.TH.Syntax λ> :k $(conT (unboxedTupleTypeName 0)) :1:1: error: • Exception when trying to run compile-time code: unboxedTupleTypeName 0 CallStack (from HasCallStack): error, called at libraries/template- haskell/Language/Haskell/TH/Syntax.hs:1179:26 in template- haskell:Language.Haskell.TH.Syntax Code: conT (unboxedTupleTypeName 0) • In the untyped splice: $(conT (unboxedTupleTypeName 0)) λ> :k $(conT (unboxedTupleTypeName 1)) :1:1: error: • Exception when trying to run compile-time code: unboxedTupleTypeName 1 CallStack (from HasCallStack): error, called at libraries/template- haskell/Language/Haskell/TH/Syntax.hs:1180:26 in template- haskell:Language.Haskell.TH.Syntax Code: conT (unboxedTupleTypeName 1) • In the untyped splice: $(conT (unboxedTupleTypeName 1)) }}} And similarly for `unboxedTupleDataName`. This is because of [http://git.haskell.org/ghc.git/blob/9c9a2229fe741c55a8fb8d0c6380ec066a77722b:/libraries /template-haskell/Language/Haskell/TH/Syntax.hs#l1184 silly restrictions] put in place on the definitions of `unboxedTupleTypeName` and `unboxedTupleDataName` within `template-haskell`: {{{#!hs -- Unboxed tuple data and type constructors -- | Unboxed tuple data constructor unboxedTupleDataName :: Int -> Name -- | Unboxed tuple type constructor unboxedTupleTypeName :: Int -> Name unboxedTupleDataName 0 = error "unboxedTupleDataName 0" unboxedTupleDataName 1 = error "unboxedTupleDataName 1" unboxedTupleDataName n = mk_unboxed_tup_name (n-1) DataName unboxedTupleTypeName 0 = error "unboxedTupleTypeName 0" unboxedTupleTypeName 1 = error "unboxedTupleTypeName 1" unboxedTupleTypeName n = mk_unboxed_tup_name (n-1) TcClsName }}} It should be possible to lift this restriction. I'll work on this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 14 16:54:01 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Dec 2016 16:54:01 -0000 Subject: [GHC] #12977: Template Haskell: unboxedTupleTypeName doesn't handle unboxed 0- and 1-tuples In-Reply-To: <050.5008aa7e061a856376f030d970571fea@haskell.org> References: <050.5008aa7e061a856376f030d970571fea@haskell.org> Message-ID: <065.1612c8fae3613bebc1b14d16f3a4eb44@haskell.org> #12977: Template Haskell: unboxedTupleTypeName doesn't handle unboxed 0- and 1-tuples -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: bug | Status: patch Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2847 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D2847 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 14 18:12:54 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Dec 2016 18:12:54 -0000 Subject: [GHC] #12959: GHC doesn't warn about missing implementations for class methods beginning with an underscore In-Reply-To: <050.f1c049718f4b94fba939144b405d48bc@haskell.org> References: <050.f1c049718f4b94fba939144b405d48bc@haskell.org> Message-ID: <065.f6a06e0283cb89d137dc473ed430930c@haskell.org> #12959: GHC doesn't warn about missing implementations for class methods beginning with an underscore -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2849 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D2849 Comment: Since I consider the current behavior absolutely batty, I've opened Phab:D2849 to correct it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 14 18:23:39 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Dec 2016 18:23:39 -0000 Subject: [GHC] #12978: User guide section on AllowAmbiguousTypes should mention TypeApplications Message-ID: <049.971cd017bc2e9b4b982c4731f7c4e434@haskell.org> #12978: User guide section on AllowAmbiguousTypes should mention TypeApplications -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html?highlight=allowambiguoustypes #ghc-flag--XAllowAmbiguousTypes With type applications it is tempting to write {{{ class C x a where meth :: a }}} which will fail the ambiguity check as `x` is not used in any methods. One way to get around this is to use `TypeApplications` in order to specify what `x` should be at each usage of `meth`. A small section in the user guide explaining this and linking to the section on `TypeApplications` would be useful. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 14 18:32:54 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Dec 2016 18:32:54 -0000 Subject: [GHC] #12959: GHC doesn't warn about missing implementations for class methods beginning with an underscore In-Reply-To: <050.f1c049718f4b94fba939144b405d48bc@haskell.org> References: <050.f1c049718f4b94fba939144b405d48bc@haskell.org> Message-ID: <065.ad7b8df8401e1b7b9c996e299a836ec4@haskell.org> #12959: GHC doesn't warn about missing implementations for class methods beginning with an underscore -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2849 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): It's not clear how this behavior was arrived at but I agree that at first glance it doesn't seem desirable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 14 21:35:19 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Dec 2016 21:35:19 -0000 Subject: [GHC] #12972: Missed specialisation opportunity with phantom type class parameter? In-Reply-To: <049.64f963aad64381fca27b6f57df680357@haskell.org> References: <049.64f963aad64381fca27b6f57df680357@haskell.org> Message-ID: <064.02fbc31aca5eba61e3ebff51aaf2ea6f@haskell.org> #12972: Missed specialisation opportunity with phantom type class parameter? -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by danharaj): We discovered this while analyzing a moderately large production system based on `reflex` and `reflex-dom` compiled with ghcjs. Web applications that use this framework rely heavily on specialization in order to be performant when run in a browser. One feature of `reflex-dom` is a javascript FFI facility built to allow uniform interaction with either ghcjs's low-level JS FFI or a native JS engine (such as WebKit) when built with ghc. This type class is the user interface for this feature: {{{#!hs class (Monad m, MonadIO (JSM m), MonadFix (JSM m), MonadJS x (JSM m)) => HasJS x m | m -> x where type JSM m :: * -> * liftJS :: JSM m a -> m a }}} The `x` parameter is important. There are situations where a program will manage multiple Javascript execution contexts. In general, references cannot be shared between execution contexts. So this is a slightly more elaborate version of the phantom type parameter used by the `ST` monad. The `x` parameter is used by the implementation of the FFI to tag various JS datastructures so that they cannot be intermixed: It guarantees this aspect of semantic correctness. Unfortunately, using this FFI via `HasJS` prevents automatic specialization because even though the dictionary for `HasJS` need not depend on `x` in an essential way, GHC seems unable to automatically create a specialized version of a polymorphic declaration that is constrained by `HasJS` and marked `INLINABLE`. I believe this is because, according to the documentation in the `Specialise` module, the invariant of the specialiser for generated specialisations is that "no specialised version is overloaded" and GHC cannot deduce that the overloading caused by `x` is benign. The workaround was to create an escape hatch that allowed the user to specify a concrete dummy type for `x` at the top-level, namely `()`. This allowed GHC to specialize all of their code which led to significant performance gains. This isn't the best situation: a user had to abandon type discipline ensuring semantic correctness in order to avoid unacceptable performance overhead. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 14 21:36:42 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Dec 2016 21:36:42 -0000 Subject: [GHC] #9890: RTS -qa option is helpful but under-documented In-Reply-To: <049.126a2e59b04d15cfa71935d2118594d3@haskell.org> References: <049.126a2e59b04d15cfa71935d2118594d3@haskell.org> Message-ID: <064.2aabffbb6dc8bf59b5dbd50f2ec30f1d@haskell.org> #9890: RTS -qa option is helpful but under-documented -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: Type: task | Status: new Priority: normal | Milestone: 8.0.2 Component: Runtime System | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2850 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: simonmar => * status: closed => new * differential: => Phab:D2850 * resolution: fixed => * milestone: 7.10.1 => 8.0.2 Comment: It turns out that there is actually **still** no mention of this flag in the users guide. Here's a patch to fix this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 14 21:36:50 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Dec 2016 21:36:50 -0000 Subject: [GHC] #9890: RTS -qa option is helpful but under-documented In-Reply-To: <049.126a2e59b04d15cfa71935d2118594d3@haskell.org> References: <049.126a2e59b04d15cfa71935d2118594d3@haskell.org> Message-ID: <064.6d85ac0d738c8b8a563a4a350af75219@haskell.org> #9890: RTS -qa option is helpful but under-documented -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: Type: task | Status: patch Priority: normal | Milestone: 8.0.2 Component: Runtime System | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2850 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 14 22:13:43 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Dec 2016 22:13:43 -0000 Subject: [GHC] #12976: GHCi displays the kinds of unboxed tuples incorrectly In-Reply-To: <050.bfe267d1fb78d199eecf7450a8a79f6e@haskell.org> References: <050.bfe267d1fb78d199eecf7450a8a79f6e@haskell.org> Message-ID: <065.13aed7e6f64b87d49b9bbdadda77fecd@haskell.org> #12976: GHCi displays the kinds of unboxed tuples incorrectly -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I say that this behavior is correct. As you report, the kind of `(#,#)` is `forall (r1 :: RuntimeRep) (r2 :: RuntimeRep). TYPE r1 -> TYPE r2 -> TYPE 'UnboxedTupleRep`. So once you provide a type argument (`(#,#) Int#`), then GHC must supply both `RuntimeRep` arguments. The second one defaults to `PtrRepLifted`. At the term level, we can then regeneralize, but you can't do that in types because there is no type-level lambda. An alternative to the current design would be to have {{{ (#,#) :: forall (r1 :: RuntimeRep). TYPE r1 -> forall (r2 :: RuntimeRep). TYPE r2 -> TYPE 'UnboxedTupleRep` }}} This is an improvement from a technical standpoint, but I wager humans would be even more confused here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 14 23:06:08 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Dec 2016 23:06:08 -0000 Subject: [GHC] #12979: -fspecialise-aggressively is not documented Message-ID: <049.e943358d5b891507f5e56a8c57be0460@haskell.org> #12979: -fspecialise-aggressively is not documented -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I couldn't find any documentation for `-fspecialise-aggressively`. The flag is explained in `compiler/specialise/Specialise` in the note `[Specialise imported INLINABLE things]` but doesn't appear in the user manual! The flag was introduced in b9e49d3e9580e13d89efd1f779cb76f610e0d6e0. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 00:37:24 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 00:37:24 -0000 Subject: [GHC] #12944: ghc master (8.1.20161206) panics with assertion failure with devel2 flavor and -O In-Reply-To: <044.3fe8817d41680dd8c67e674ebd7c6a0f@haskell.org> References: <044.3fe8817d41680dd8c67e674ebd7c6a0f@haskell.org> Message-ID: <059.7f04821f5e9fcc39230538aab511d482@haskell.org> #12944: ghc master (8.1.20161206) panics with assertion failure with devel2 flavor and -O -------------------------------------+------------------------------------- Reporter: pacak | Owner: Type: bug | Status: patch Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2844 Wiki Page: | -------------------------------------+------------------------------------- Comment (by pacak): https://ghc.haskell.org/trac/ghc/ticket/12899 - related -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 01:08:23 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 01:08:23 -0000 Subject: [GHC] #12976: GHCi displays the kinds of unboxed tuples incorrectly In-Reply-To: <050.bfe267d1fb78d199eecf7450a8a79f6e@haskell.org> References: <050.bfe267d1fb78d199eecf7450a8a79f6e@haskell.org> Message-ID: <065.0991f2fa45a32af6f4401e4220ff5003@haskell.org> #12976: GHCi displays the kinds of unboxed tuples incorrectly -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:2 goldfire]: > I say that this behavior is correct. As you report, the kind of `(#,#)` is `forall (r1 :: RuntimeRep) (r2 :: RuntimeRep). TYPE r1 -> TYPE r2 -> TYPE 'UnboxedTupleRep`. So once you provide a type argument (`(#,#) Int#`), then GHC must supply both `RuntimeRep` arguments. The second one defaults to `PtrRepLifted`. Do you mind explaining your reasoning for in a little more detail? Because it's not cleat at all to me why making `r1 ~ 'IntRep` would cause `r2` to default to `PtrRepLifted`. In particular, I would have expected: {{{#!hs (#,#) Int# :: forall (r2 :: RuntimeRep). TYPE r2 -> TYPE 'UnboxedTupleRep }}} Why would it default with an argument, but not without arguments? Also, do you know what's going on with: {{{ λ> :k $(unboxedTupleT 2) $(unboxedTupleT 2) :: * -> * -> TYPE 'UnboxedTupleRep }}} Is Template Haskell causing some defaulting behavior that I'm not aware of? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 01:57:48 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 01:57:48 -0000 Subject: [GHC] #12980: Unlifted class method rejected Message-ID: <047.30d5cc1ce932625fb79015dfcdcefc56@haskell.org> #12980: Unlifted class method rejected -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If I say {{{#!hs class C a where meth :: Array# a }}} I get {{{ • Expecting a lifted type, but ‘Array# a’ is unlifted • In the type signature: meth :: Array# a In the class declaration for ‘C’ }}} This definition looks OK to me. I don't see why we can't have an unlifted member of a class. (As @oerjan points out in comment:25:ticket:12708, we can't have a ''levity-polymorphic'' class member, but this is solidly levity- monomorphic.) I'm happy to lift this restriction in ongoing work in this area, but I wanted to double-check before doing so. For the record, the same error occurs even when the class has more than one member, so it's not the no-unlifted-newtypes restriction. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 03:51:40 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 03:51:40 -0000 Subject: [GHC] #12981: SMP never enabled on ARMv7 Message-ID: <044.559338d739806b65d1855740c8ce12dd@haskell.org> #12981: SMP never enabled on ARMv7 -------------------------------------+------------------------------------- Reporter: orion | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: arm | Type of failure: Building GHC | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- SMP support should be enabled on ARMv7, however I have been unable to force it so. The problem lies in `mk/config.mk.in`, where double quotes have been erroneously added around the `ArchSupportsSMP` variable. This causes the `GhcWithSMP` variable to always be `NO` when building for ARM. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 03:53:03 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 03:53:03 -0000 Subject: [GHC] #12981: SMP never enabled on ARMv7 In-Reply-To: <044.559338d739806b65d1855740c8ce12dd@haskell.org> References: <044.559338d739806b65d1855740c8ce12dd@haskell.org> Message-ID: <059.99501ce762f086ada91d05e346c345fa@haskell.org> #12981: SMP never enabled on ARMv7 ----------------------------------------+----------------------------- Reporter: orion | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+----------------------------- Changes (by orion): * Attachment "smp-arm-fix.patch" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 07:45:30 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 07:45:30 -0000 Subject: [GHC] #12982: Missed constant folding oportunities Message-ID: <044.d9771cbd0fd576f4750f411f0acf4ba6@haskell.org> #12982: Missed constant folding oportunities -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: feature | Status: new request | Priority: normal | Milestone: 8.4.1 Component: | Version: 8.0.1 libraries/hoopl | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- A work colleague of mine found that some expressions were not being constant folded as expected. For example: {{#!hs module Test where import Data.Int number :: Int64 number = 2 ^ 10 - 3 }}} compiled using: {{{ ghc -O2 -keep-s-file -c test.hs }}} should result in an assembler file containing the constant `1021` but doesn't. However, if I change the above expression to: {{{ number = 1024 -3 }}} then the output assembler files does contain the value `1021`. I did a bit of a search and found some constant folding code in the `hoopl` library, but that doesn't seem to be what GHC actually uses. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 08:29:30 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 08:29:30 -0000 Subject: [GHC] #12979: -fspecialise-aggressively is not documented In-Reply-To: <049.e943358d5b891507f5e56a8c57be0460@haskell.org> References: <049.e943358d5b891507f5e56a8c57be0460@haskell.org> Message-ID: <064.5aa207061d85c9ffbaccbaadb877b223@haskell.org> #12979: -fspecialise-aggressively is not documented -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): It's entirely experimental; I was just trying something out, and didn't mean to advertise it. But by all means add a user-manual entry -- thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 09:08:25 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 09:08:25 -0000 Subject: [GHC] #12981: SMP never enabled on ARMv7 In-Reply-To: <044.559338d739806b65d1855740c8ce12dd@haskell.org> References: <044.559338d739806b65d1855740c8ce12dd@haskell.org> Message-ID: <059.45871fc9fbe86718aa871008f7537458@haskell.org> #12981: SMP never enabled on ARMv7 ----------------------------------------+----------------------------- Reporter: orion | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+----------------------------- Comment (by Sergei Trofimovich ): In [changeset:"52c5e55348170f27f5ef1cb010c4c96ab4aa47cc/ghc" 52c5e55/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="52c5e55348170f27f5ef1cb010c4c96ab4aa47cc" mk/config.mk.in: enable SMP on ARMv7+ (Trac #12981) Before the change result of expression ArchSupportsSMP="$(if $(filter $(ARM_ISA),ARMv5 ARMv6),NO,YES)" to evaluate to ArchSupportsSMP="YES" After the change it's ArchSupportsSMP=YES Thanks to orion for the fix! Fixes Trac #12981 Signed-off-by: Sergei Trofimovich }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 09:11:32 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 09:11:32 -0000 Subject: [GHC] #12981: SMP never enabled on ARMv7 In-Reply-To: <044.559338d739806b65d1855740c8ce12dd@haskell.org> References: <044.559338d739806b65d1855740c8ce12dd@haskell.org> Message-ID: <059.cbaffbdb035ddcfdea4b753c6791a11d@haskell.org> #12981: SMP never enabled on ARMv7 ----------------------------------------+----------------------------- Reporter: orion | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.2 Component: Build System | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+----------------------------- Changes (by slyfox): * status: new => merge * milestone: => 8.0.2 Comment: Nice catch! The fix is worth backporting to 8.0. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 09:13:05 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 09:13:05 -0000 Subject: [GHC] #12983: Loading temp shared object failed: TemplateHaskell and recompilation Message-ID: <049.2c68231d33bee80b5ff9e32f112656cd@haskell.org> #12983: Loading temp shared object failed: TemplateHaskell and recompilation -------------------------------------+------------------------------------- Reporter: StefanWehr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: template | Operating System: Unknown/Multiple haskell, recompilation | Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In our project, we get from time to time an error like this: {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/8r/25v12lxd02zdm7lpky3xcnh80000gn/T/ghc40483_0/libghc_1.dylib, 5): Symbol not found: _ShortText_ShortText_con_info Referenced from: /var/folders/8r/25v12lxd02zdm7lpky3xcnh80000gn/T/ghc40483_0/libghc_1.dylib Expected in: flat namespace in /var/folders/8r/25v12lxd02zdm7lpky3xcnh80000gn/T/ghc40483_0/libghc_1.dylib }}} I was able to create a somewhat minimal setup for reproducing the problem. I've reproduced the problem on Mac and Linux with GHC 8.0.1, didn't try on Windows. The root of the problem seems to be an interaction with template haskell and the recompilation manager. I'll now explain the setup. I've attached an archive which contains all code and a simple build script. Just unpack the archive and execute ./build.sh to reproduce the problem. The setup consists of four files. (Don't be confused by the module names. They are derived from our project). The problem arises after a change to one of these files and a recompilation. Here are the initial versions of the four files. {{{#!hs -- src/ShortText.hs module ShortText where data ShortText = ShortText String toString :: ShortText -> String toString (ShortText s) = s }}} {{{#!hs -- src/Hospital.hs module Hospital where foo :: Int -> String foo i = show i }}} {{{#!hs -- src/Types.hs {-# LANGUAGE TemplateHaskell #-} module Types where import qualified Hospital import Language.Haskell.TH genCode :: Q [Dec] genCode = let s = Hospital.foo 5 in [d|string = s|] }}} {{{#!hs -- src/MetaHandler.hs {-# LANGUAGE TemplateHaskell #-} module Main where import qualified Types -- splices in "string :: String" $(Types.genCode) main :: IO () main = putStrLn string }}} Compiling the project for the first time works without problems: {{{ $ /Users/swehr/.stack/programs/x86_64-osx/ghc-8.0.1/bin/ghc -O0 -isrc -ibuild -dynamic -outputdir build -package template-haskell --make src/MetaHandler.hs [1 of 3] Compiling Hospital ( src/Hospital.hs, build/Hospital.o ) [2 of 3] Compiling Types ( src/Types.hs, build/Types.o ) [3 of 3] Compiling Main ( src/MetaHandler.hs, build/Main.o ) Linking src/MetaHandler ... }}} I then changed the content of src/Hospital.hs to use the ShortText module. Here is the new content: {{{#!hs -- src/Hospital.hs module Hospital where import ShortText foo :: Int -> String foo i = toString (ShortText (show i)) }}} Then recompilation fails: {{{ [1 of 4] Compiling ShortText ( src/ShortText.hs, build/ShortText.o ) [2 of 4] Compiling Hospital ( src/Hospital.hs, build/Hospital.o ) [4 of 4] Compiling Main ( src/MetaHandler.hs, build/Main.o ) [TH] ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/8r/25v12lxd02zdm7lpky3xcnh80000gn/T/ghc40827_0/libghc_7.dylib, 5): Symbol not found: _ShortText_ShortText_con_info Referenced from: /var/folders/8r/25v12lxd02zdm7lpky3xcnh80000gn/T/ghc40827_0/libghc_7.dylib Expected in: flat namespace in /var/folders/8r/25v12lxd02zdm7lpky3xcnh80000gn/T/ghc40827_0/libghc_7.dylib Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Looking at the output when compiling with -v3 gives a clue why: {{{ ... *** Linker: /usr/bin/gcc -m64 -fno-stack-protector -DTABLES_NEXT_TO_CODE -m64 -dynamiclib -o /var/folders/8r/25v12lxd02zdm7lpky3xcnh80000gn/T/ghc40913_0/libghc_7.dylib build/Hospital.o build/Types.o -undefined dynamic_lookup -single_module -install_name '@rpath/libghc_7.dylib' -L/Users/swehr/.stack/programs/x86_64-osx/ghc-8.0.1/lib/ghc-8.0.1 /template-haskell-2.11.0.0 -Wl,-rpath -Wl,/Users/swehr/.stack/programs/x86_64-osx/ghc-8.0.1/lib/ghc-8.0.1 /template-haskell-2.11.0.0 -L/Users/swehr/.stack/programs/x86_64-osx/ghc-8.0.1/lib/ghc-8.0.1/pretty-1.1.3.3 -Wl,-rpath -Wl,/Users/swehr/.stack/programs/x86_64-osx/ghc-8.0.1/lib/ghc-8.0.1/pretty-1.1.3.3 -L/Users/swehr/.stack/programs/x86_64-osx/ghc-8.0.1/lib/ghc-8.0.1/deepseq-1.4.2.0 -Wl,-rpath -Wl,/Users/swehr/.stack/programs/x86_64-osx/ghc-8.0.1/lib/ghc-8.0.1/deepseq-1.4.2.0 -L/Users/swehr/.stack/programs/x86_64-osx/ghc-8.0.1/lib/ghc-8.0.1/array-0.5.1.1 -Wl,-rpath -Wl,/Users/swehr/.stack/programs/x86_64-osx/ghc-8.0.1/lib/ghc-8.0.1/array-0.5.1.1 -L/Users/swehr/.stack/programs/x86_64-osx/ghc-8.0.1/lib/ghc-8.0.1/ghc- boot-th-8.0.1 -Wl,-rpath -Wl,/Users/swehr/.stack/programs/x86_64-osx/ghc-8.0.1/lib/ghc-8.0.1/ghc- boot-th-8.0.1 -L/Users/swehr/.stack/programs/x86_64-osx/ghc-8.0.1/lib/ghc-8.0.1/base-4.9.0.0 -Wl,-rpath -Wl,/Users/swehr/.stack/programs/x86_64-osx/ghc-8.0.1/lib/ghc-8.0.1/base-4.9.0.0 -L/Users/swehr/.stack/programs/x86_64-osx/ghc-8.0.1/lib/ghc-8.0.1/integer- gmp-1.0.0.1 -Wl,-rpath -Wl,/Users/swehr/.stack/programs/x86_64-osx/ghc-8.0.1/lib/ghc-8.0.1 /integer-gmp-1.0.0.1 -L/Users/swehr/.stack/programs/x86_64-osx/ghc-8.0.1/lib/ghc-8.0.1/ghc- prim-0.5.0.0 -Wl,-rpath -Wl,/Users/swehr/.stack/programs/x86_64-osx/ghc-8.0.1/lib/ghc-8.0.1/ghc- prim-0.5.0.0 -L/Users/swehr/.stack/programs/x86_64-osx/ghc-8.0.1/lib/ghc-8.0.1/rts -Wl,-rpath -Wl,/Users/swehr/.stack/programs/x86_64-osx/ghc-8.0.1/lib/ghc-8.0.1/rts -lHStemplate-haskell-2.11.0.0-ghc8.0.1 -lHSpretty-1.1.3.3-ghc8.0.1 -lHSdeepseq-1.4.2.0-ghc8.0.1 -lHSarray-0.5.1.1-ghc8.0.1 -lHSghc-boot- th-8.0.1-ghc8.0.1 -lHSbase-4.9.0.0-ghc8.0.1 -lHSinteger- gmp-1.0.0.1-ghc8.0.1 -lHSghc-prim-0.5.0.0-ghc8.0.1 -liconv *** Deleting temp files: Deleting: /var/folders/8r/25v12lxd02zdm7lpky3xcnh80000gn/T/ghc40913_0/ghc_8.rsp /var/folders/8r/25v12lxd02zdm7lpky3xcnh80000gn/T/ghc40913_0/libghc_7.dylib *** Deleting temp dirs: Deleting: /var/folders/8r/25v12lxd02zdm7lpky3xcnh80000gn/T/ghc40913_0 ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/8r/25v12lxd02zdm7lpky3xcnh80000gn/T/ghc40913_0/libghc_7.dylib, 5): Symbol not found: _ShortText_ShortText_con_info Referenced from: /var/folders/8r/25v12lxd02zdm7lpky3xcnh80000gn/T/ghc40913_0/libghc_7.dylib Expected in: flat namespace in /var/folders/8r/25v12lxd02zdm7lpky3xcnh80000gn/T/ghc40913_0/libghc_7.dylib }}} We can see here that the .o file for ShortText is not passed to gcc when building libghc_7.dylib. I suspect that libghc_7.dylib is used to run template haskell code, but this is only a guess. Looking at the .hi file for MetaHandler, we can see why gcc does not get the .o file for ShortText: ShortText is not included in the module dependencies: {{{ $ /Users/swehr/.stack/programs/x86_64-osx/ghc-8.0.1/bin/ghc --show-iface build/Main.hi Magic: Wanted 33214052, got 33214052 Version: Wanted [8, 0, 0, 1], got [8, 0, 0, 1] Way: Wanted [], got [d, y, n] interface Main 8001 interface hash: def8085a5dcb4980922089d5d21cf0f9 ABI hash: 1a46783c6a6c6b308503cf705db45d4d export-list hash: d2d75d71ebb6963f6e9c9a5b4050ef71 orphan hash: 693e9af84d3dfcc71e640e005bdc5e2e flag hash: 3468616c2ba87fe39e866ff30d651f01 sig of: Nothing used TH splices: True where exports: main string module dependencies: Hospital Types package dependencies: array-0.5.1.1 base-4.9.0.0 deepseq-1.4.2.0 ghc-boot-th-8.0.1 ghc-prim-0.5.0.0 integer- gmp-1.0.0.1 pretty-1.1.3.3 template-haskell-2.11.0.0 orphans: GHC.Base GHC.Float }}} I think the main problem is that src/Types.hs is not recompiled in the second run. I also experimented with compiling each file separately, using the -c flag. When I then compile src/Types.hs, ghc outputs "compilation NOT required" in the second run. If a compile src/Types.hs with -fforce- recomp in the 2nd run, everything works fine. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 09:14:12 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 09:14:12 -0000 Subject: [GHC] #12983: Loading temp shared object failed: TemplateHaskell and recompilation In-Reply-To: <049.2c68231d33bee80b5ff9e32f112656cd@haskell.org> References: <049.2c68231d33bee80b5ff9e32f112656cd@haskell.org> Message-ID: <064.430e65501a877f2fede40f2140022c36@haskell.org> #12983: Loading temp shared object failed: TemplateHaskell and recompilation -------------------------------------+------------------------------------- Reporter: StefanWehr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: template | haskell, recompilation Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by StefanWehr): * Attachment "ghc-bug-12983.tar.gz" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 09:27:58 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 09:27:58 -0000 Subject: [GHC] #12940: ghc-8.0.2 RC1 libs installed under package dirs vs Cabal installing packages under abi dir In-Reply-To: <050.075e1d37abb8e63b1885a88d4a4ff225@haskell.org> References: <050.075e1d37abb8e63b1885a88d4a4ff225@haskell.org> Message-ID: <065.8829dc29d625a5ebfeb133e706cd68a1@haskell.org> #12940: ghc-8.0.2 RC1 libs installed under package dirs vs Cabal installing packages under abi dir ---------------------------------+---------------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Build System | Version: 8.0.2-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by slyfox): Sounds like a dupe of #12770 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 09:37:32 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 09:37:32 -0000 Subject: [GHC] #12042: Infinite loop with type synonyms and hs-boot In-Reply-To: <045.2af2d998455883876e6ff4ff050c9c9d@haskell.org> References: <045.2af2d998455883876e6ff4ff050c9c9d@haskell.org> Message-ID: <060.4f41223a28abdf2c1ac3b9c5b3cc6276@haskell.org> #12042: Infinite loop with type synonyms and hs-boot -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: closed Priority: low | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Keywords: hs-boot Resolution: fixed | backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2656 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 09:39:23 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 09:39:23 -0000 Subject: [GHC] #11062: Type families + hs-boot files = panic (type family consistency check too early) (was: Type families + hs-boot files = panic) In-Reply-To: <047.7c49c2177d004f32c0696dfdb91a7434@haskell.org> References: <047.7c49c2177d004f32c0696dfdb91a7434@haskell.org> Message-ID: <062.a9ce95d684c5edbb0df0a12a88f93eae@haskell.org> #11062: Type families + hs-boot files = panic (type family consistency check too early) -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: patch Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: TypeFamilies | hs-boot Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2215 Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 09:52:11 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 09:52:11 -0000 Subject: [GHC] #12899: ghc panics at random places with -jX In-Reply-To: <044.e06c34ff950f64285fd655be98faab7e@haskell.org> References: <044.e06c34ff950f64285fd655be98faab7e@haskell.org> Message-ID: <059.0058813f8e3860dbc08fb356a9f848a3@haskell.org> #12899: ghc panics at random places with -jX -------------------------------------+------------------------------------- Reporter: pacak | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): For anyone not following along at home, the problem is that the `Unique`s were overflowing. The `UniqSupply` counter was reaching over 25 million but only 24 bits (around 17 million) were being used to store the uniques. This led to uniques being allocated multiple times. The failures were different each time because the overflow was only bad if it overflowed into the same label and then we relied on this unique at some point in compilation (to do an equality check for example). It was a coincidence that compiling with `-j1` didn't trigger these problems, it must have been the ordering these uniques were applied didn't cause terrible things like this to happen. Ben has produced a diff (D2844) which bumps the number of bits we use so hopefully this is never a problem again! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 09:55:50 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 09:55:50 -0000 Subject: [GHC] #12980: Unlifted class method rejected In-Reply-To: <047.30d5cc1ce932625fb79015dfcdcefc56@haskell.org> References: <047.30d5cc1ce932625fb79015dfcdcefc56@haskell.org> Message-ID: <062.85cb48277accb378268225ab540cea1f@haskell.org> #12980: Unlifted class method rejected -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Certainly should be ok for multi-method classes. I'm not quite sure about the single-method case, because of the interaction with newtypes -- but I think there's a case for using data types in the single-method case too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 09:56:08 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 09:56:08 -0000 Subject: [GHC] #12980: Unlifted class method rejected In-Reply-To: <047.30d5cc1ce932625fb79015dfcdcefc56@haskell.org> References: <047.30d5cc1ce932625fb79015dfcdcefc56@haskell.org> Message-ID: <062.e3a4da948049406bd15226252680c920@haskell.org> #12980: Unlifted class method rejected -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => LevityPolymorphism -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 11:05:45 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 11:05:45 -0000 Subject: [GHC] #12982: Missed constant folding oportunities In-Reply-To: <044.d9771cbd0fd576f4750f411f0acf4ba6@haskell.org> References: <044.d9771cbd0fd576f4750f411f0acf4ba6@haskell.org> Message-ID: <059.268c9d8240866852ba0969191bbbcce3@haskell.org> #12982: Missed constant folding oportunities -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: libraries/hoopl | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- @@ -5,1 +5,1 @@ - {{#!hs + {{{#!hs New description: A work colleague of mine found that some expressions were not being constant folded as expected. For example: {{{#!hs module Test where import Data.Int number :: Int64 number = 2 ^ 10 - 3 }}} compiled using: {{{ ghc -O2 -keep-s-file -c test.hs }}} should result in an assembler file containing the constant `1021` but doesn't. However, if I change the above expression to: {{{ number = 1024 -3 }}} then the output assembler files does contain the value `1021`. I did a bit of a search and found some constant folding code in the `hoopl` library, but that doesn't seem to be what GHC actually uses. -- Comment (by simonpj): I suspect it's just that the constant folding RULES, in `prelude/Build -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 12:01:27 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 12:01:27 -0000 Subject: [GHC] #12979: -fspecialise-aggressively is not documented In-Reply-To: <049.e943358d5b891507f5e56a8c57be0460@haskell.org> References: <049.e943358d5b891507f5e56a8c57be0460@haskell.org> Message-ID: <064.cfbf7957b33708f4a7d8d19abea024af@haskell.org> #12979: -fspecialise-aggressively is not documented -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): I'm unsure what kind of code it is meant to specialise better. The ticket linked in the comment (#8874) is irrelevant. Is it meant to specialise functions which are polymorphic but but not overloaded? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 12:02:26 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 12:02:26 -0000 Subject: [GHC] #12984: Missed constant folding oportunities (associativity) Message-ID: <045.0a42c32dd482b39428ca2268278e9f14@haskell.org> #12984: Missed constant folding oportunities (associativity) -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider this simple example: {{{#!hs import System.Environment main :: IO () main = do args <- getArgs print ((length args + 10) - 10) }}} Compiled with -O2, we get the following Core: {{{#!hs case GHC.Show.$wshowSignedInt 0# (GHC.Prim.-# (GHC.Prim.+# ww2_a6Pd 10#) 10#) (GHC.Types.[] @ Char) of }}} I would expect GHC to perform constant folding there to remove the unnecessary operation. Basically, for any expression composed of Int#/Word# +/-/* primops, I think we should use associativity and distributivity laws to push the constants in the outer operation. It would allow the "scrutinee constant folding" optimization to be applied more often too. I have a patch that does this for case scrutinees, but where should I put it in GHC so that the optimization gets applied more generally? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 12:07:07 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 12:07:07 -0000 Subject: [GHC] #12984: Missed constant folding oportunities (associativity) In-Reply-To: <045.0a42c32dd482b39428ca2268278e9f14@haskell.org> References: <045.0a42c32dd482b39428ca2268278e9f14@haskell.org> Message-ID: <060.43bd1fced7ef78ae7abc9457f657b2a0@haskell.org> #12984: Missed constant folding oportunities (associativity) -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Ideally, express it as a bunch of rewrite rules (`prelude/PrelRules.hs`). I don't know if that is conveniently possible for assoc/distrib laws. Don't forget to take care about overflow etc. You will know this better than I but computer arithmetic doesn't obey all the same laws as mathematics! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 12:14:09 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 12:14:09 -0000 Subject: [GHC] #12978: User guide section on AllowAmbiguousTypes should mention TypeApplications In-Reply-To: <049.971cd017bc2e9b4b982c4731f7c4e434@haskell.org> References: <049.971cd017bc2e9b4b982c4731f7c4e434@haskell.org> Message-ID: <064.9229fdd708905938a1533b4cf15d564e@haskell.org> #12978: User guide section on AllowAmbiguousTypes should mention TypeApplications -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Good idea! I think that would be great. Would you like to draft it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 12:16:45 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 12:16:45 -0000 Subject: [GHC] #12959: GHC doesn't warn about missing implementations for class methods beginning with an underscore In-Reply-To: <050.f1c049718f4b94fba939144b405d48bc@haskell.org> References: <050.f1c049718f4b94fba939144b405d48bc@haskell.org> Message-ID: <065.e0dbc141e80cdff85e47ea3de5e7240f@haskell.org> #12959: GHC doesn't warn about missing implementations for class methods beginning with an underscore -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2849 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I don't think there was a deep reason. Currently `-Wunusused-binds` doesn't warn about variables starting with an underscore, so the leading underscore is a per-variable hint that you intend this to be unused and should not warn. So maybe I just naively extended it to the class-method case, which is admittedly a bit different. I have no objection to killing off this special case. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 12:56:05 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 12:56:05 -0000 Subject: [GHC] #12975: Suggested type signature for a pattern synonym causes program to fail to type check In-Reply-To: <047.5d9fc0ffb90d93bc2d5a96bef52c66e8@haskell.org> References: <047.5d9fc0ffb90d93bc2d5a96bef52c66e8@haskell.org> Message-ID: <062.8065fc855f813e06e70bccbd7b7c71b7@haskell.org> #12975: Suggested type signature for a pattern synonym causes program to fail to type check -------------------------------------+------------------------------------- Reporter: ocharles | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): The reported type is sort of right: {{{ Cast :: forall b. Typeable b => forall a. Typeable a => b -> T }}} That is, you can match a value of any type `b` provided it is typeable. So {{{ f (Cast x) = rhs }}} means pretty much {{{ f (MkT y) = case cast y of Just x -> rhs }}} Inside `rhs` we have access to the `Typeable a` constraint bound by `MkT`; that's what the `Typeable a` constraint in the inferred type is saying. But this `Typeable a` provided constraint is no use to `rhs` because we have no values of type `a`. So Matthew's type is less confusing {{{ pattern Cast :: Typeable b => b -> T }}} Offering useless constraints is bad enough; but worse, as you report, it's rejected as ambiguous (for the same reason) if you specify it in a user signature. That is indeed confusing. What I can't see is a robust and convenient way to eliminate the unnecessary constraints and existential variables. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 14:11:04 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 14:11:04 -0000 Subject: [GHC] #12976: GHCi displays the kinds of unboxed tuples incorrectly In-Reply-To: <050.bfe267d1fb78d199eecf7450a8a79f6e@haskell.org> References: <050.bfe267d1fb78d199eecf7450a8a79f6e@haskell.org> Message-ID: <065.9766ba2127842f4b59271b468e50d367@haskell.org> #12976: GHCi displays the kinds of unboxed tuples incorrectly -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): The `(#,#)` type constructor takes 4 arguments, `(r1 :: RuntimeRep)`, `(r2 :: RuntimeRep)`, `(a :: TYPE r1)`, and `(b :: TYPE r2)`. Because there is no type-level lambda, it ''must'' take these arguments in order. So we cannot supply the third argument (the `Int#` in the `(#,#) Int#` case) without supplying the second. Initially, this second argument is a unification variable, but this gets defaulted to `PtrRepLifted` before printing. Does that explain it? And I have no idea what's going on with TH. That looks like a separate ticket to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 15:08:28 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 15:08:28 -0000 Subject: [GHC] #12832: GHC infers too simplified contexts In-Reply-To: <046.c1f3ff2a9ca4d830d3e52f2f57c4f3ec@haskell.org> References: <046.c1f3ff2a9ca4d830d3e52f2f57c4f3ec@haskell.org> Message-ID: <061.a791ed0f1eaf28f71757da2aef8cc593@haskell.org> #12832: GHC infers too simplified contexts -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: high | Milestone: 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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): In the Note above there could be two classes that use each other, not just one. I don't have a good solution here, I'm afraid. Maybe someone else does. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 15:09:38 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 15:09:38 -0000 Subject: [GHC] #12985: GHCi incorrectly reports the kind of unboxed tuples spliced in from Template Haskell Message-ID: <050.ad0392c4ae751e995d3259a41b13bc35@haskell.org> #12985: GHCi incorrectly reports the kind of unboxed tuples spliced in from Template Haskell -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.0.2 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #12976 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- First noticed in #12976. First, fire up GHCi 8.0.2 (or HEAD) and enable some options: {{{ $ inplace/bin/ghc-stage2 --interactive GHCi, version 8.1.20161208: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci λ> :set -fprint-explicit-runtime-reps -fprint-explicit-kinds -fprint- explicit-foralls -XUnboxedTuples -XTemplateHaskell -XMagicHash λ> :m + GHC.Exts Language.Haskell.TH Language.Haskell.TH.Lib Language.Haskell.TH.Syntax }}} Next, try looking at the kind of a regular unboxed tuple: {{{ λ> :k (#,#) (#,#) :: forall (a :: RuntimeRep) (b :: RuntimeRep). TYPE a -> TYPE b -> TYPE 'UnboxedTupleRep }}} But when you splice in the unboxed tuple type constructor via Template Haskell, `:k` misbehaves: {{{ λ> :k $(unboxedTupleT 2) $(unboxedTupleT 2) :: * -> * -> TYPE 'UnboxedTupleRep }}} This kind is totally wrong, since you //can// in fact apply this type constructor to types with kinds other than `*`: {{{ λ> :k $(unboxedTupleT 2) Int# Int# $(unboxedTupleT 2) Int# Int# :: TYPE 'UnboxedTupleRep }}} Moreover, this appears to be a regression since GHC 8.0.1, since if you try this in GHCi 8.0.1: {{{ $ /opt/ghc/8.0.1/bin/ghci GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci λ> :set -fprint-explicit-runtime-reps -fprint-explicit-kinds -fprint- explicit-foralls -XUnboxedTuples -XTemplateHaskell -XMagicHash λ> :m + GHC.Exts Language.Haskell.TH Language.Haskell.TH.Lib Language.Haskell.TH.Syntax λ> :k $(unboxedTupleT 2) $(unboxedTupleT 2) :: forall (a :: RuntimeRep) (b :: RuntimeRep). TYPE a -> TYPE b -> TYPE 'UnboxedTupleRep }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 15:10:11 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 15:10:11 -0000 Subject: [GHC] #12976: GHCi displays the kinds of unboxed tuples incorrectly In-Reply-To: <050.bfe267d1fb78d199eecf7450a8a79f6e@haskell.org> References: <050.bfe267d1fb78d199eecf7450a8a79f6e@haskell.org> Message-ID: <065.b87077e01c8c838744107450d3f75ec8@haskell.org> #12976: GHCi displays the kinds of unboxed tuples incorrectly -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #12985 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => invalid * related: => #12985 Comment: Replying to [comment:4 goldfire]: > The `(#,#)` type constructor takes 4 arguments, `(r1 :: RuntimeRep)`, `(r2 :: RuntimeRep)`, `(a :: TYPE r1)`, and `(b :: TYPE r2)`. Because there is no type-level lambda, it ''must'' take these arguments in order. So we cannot supply the third argument (the `Int#` in the `(#,#) Int#` case) without supplying the second. Initially, this second argument is a unification variable, but this gets defaulted to `PtrRepLifted` before printing. > > Does that explain it? Now it makes sense! Thanks. I'm a bit saddened that we apparently don't have a way to make `(#,#) Int# :: forall (r2 :: RuntimeRep). TYPE r2 -> TYPE 'UnboxedTupleRep`, but maybe that problem will be fixed once we have visible kind applications (#12045). > And I have no idea what's going on with TH. That looks like a separate ticket to me. OK. I've opened #12985 specifically to address that issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 15:21:24 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 15:21:24 -0000 Subject: [GHC] #12976: GHCi displays the kinds of unboxed tuples incorrectly In-Reply-To: <050.bfe267d1fb78d199eecf7450a8a79f6e@haskell.org> References: <050.bfe267d1fb78d199eecf7450a8a79f6e@haskell.org> Message-ID: <065.671fb2327e56ae17ba3e18d30f9a3604@haskell.org> #12976: GHCi displays the kinds of unboxed tuples incorrectly -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #12985 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): No. Visible kind applications won't help. We need to either have: 1. Type-level lambdas, or 2. Declare `(#,#) :: forall r1. TYPE r1 -> forall r2. TYPE r2 -> TYPE 'UnboxedTupleRep`. (2) is obviously much much easier. But I'm worried about folks getting confused at the non-prenex type. On the other hand, if someone is wading in these waters, they had better know how to swim already... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 15:43:12 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 15:43:12 -0000 Subject: [GHC] #12969: Rebindable enumFrom etc. syntax In-Reply-To: <045.5772062aa85023583167120cc509b98f@haskell.org> References: <045.5772062aa85023583167120cc509b98f@haskell.org> Message-ID: <060.3b54d96f8df9df2d9802c525d6bbc123@haskell.org> #12969: Rebindable enumFrom etc. syntax -------------------------------------+------------------------------------- Reporter: cactus | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: | RebindableSyntax Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Currently they are defined to desugar to `fromList ` and `fromList` ''is'' rebindable. You need `-XOverloadedLists` on to get this; see the [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html #overloaded-lists manual section]. I'll add a note to the user manual. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 15:43:17 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 15:43:17 -0000 Subject: [GHC] #10614: Show constraints in ``Found hole...'' In-Reply-To: <047.e629c8600a92660c55de2127511a14cd@haskell.org> References: <047.e629c8600a92660c55de2127511a14cd@haskell.org> Message-ID: <062.566d913d38d3dd9d31161bc2633521b5@haskell.org> #10614: Show constraints in ``Found hole...'' -------------------------------------+------------------------------------- Reporter: bjmprice | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://phabricator.haskell.org/D2767 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"0c3341b23e0672fb9c05d9f6ab0be76f411d526e/ghc" 0c3341b2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0c3341b23e0672fb9c05d9f6ab0be76f411d526e" Show constraints when reporting typed holes This patch implements the display of constraints in the error message for typed holes. Test Plan: validate, read docs Reviewers: simonpj, austin, bgamari Reviewed By: simonpj, bgamari Subscribers: simonpj, thomie Differential Revision: https://phabricator.haskell.org/D2767 GHC Trac Issues: #10614 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 15:43:17 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 15:43:17 -0000 Subject: [GHC] #12758: Bring sanity to our performance testsuite In-Reply-To: <046.023630bbf855f7a4ed786cb14a3639ea@haskell.org> References: <046.023630bbf855f7a4ed786cb14a3639ea@haskell.org> Message-ID: <061.8e98451b507dae7d068381a0cdd11527@haskell.org> #12758: Bring sanity to our performance testsuite -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Test Suite | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"2940a61722b5e5b35421b385dedf07f82c63557d/ghc" 2940a617/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2940a61722b5e5b35421b385dedf07f82c63557d" testsuite: Specify expected allocations of T12877 for Windows This deviated by 12% from the expected allocations on Windows. Yet another case of #12758. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 15:43:17 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 15:43:17 -0000 Subject: [GHC] #7289: Mingw FPU init not Windows compatible. In-Reply-To: <046.d34d1fd66180608dd1232dbfc9430105@haskell.org> References: <046.d34d1fd66180608dd1232dbfc9430105@haskell.org> Message-ID: <061.7c94f9aa33c3c784a2343b04ac9e9547@haskell.org> #7289: Mingw FPU init not Windows compatible. -------------------------------------+------------------------------------- Reporter: Lennart | Owner: Phyx- Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 7.2.2 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2819 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"6f7d8279cea4aa1082fb07adf5da507297e21ee8/ghc" 6f7d827/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6f7d8279cea4aa1082fb07adf5da507297e21ee8" Reset FPU precision back to MSVCRT defaults Mingw-w64 does a stupid thing. They set the FPU precision to extended mode by default. The reasoning is that it's for compatibility with GNU Linux ported libraries. However the problem is this is incompatible with the standard Windows double precision mode. In fact, if we create a new OS thread then Windows will reset the FPU to double precision mode. So we end up with a weird state where the main thread by default has a different precision than any child threads. Test Plan: ./validate new test T7289 Reviewers: simonmar, austin, bgamari, erikd Reviewed By: simonmar Subscribers: thomie, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D2819 GHC Trac Issues: #7289 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 15:43:17 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 15:43:17 -0000 Subject: [GHC] #12977: Template Haskell: unboxedTupleTypeName doesn't handle unboxed 0- and 1-tuples In-Reply-To: <050.5008aa7e061a856376f030d970571fea@haskell.org> References: <050.5008aa7e061a856376f030d970571fea@haskell.org> Message-ID: <065.ec489f244d4a38ff463282ee0563a956@haskell.org> #12977: Template Haskell: unboxedTupleTypeName doesn't handle unboxed 0- and 1-tuples -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: bug | Status: patch Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2847 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"9550b8d810c3ce9fcf3419da367041124e2673de/ghc" 9550b8d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9550b8d810c3ce9fcf3419da367041124e2673de" Make unboxedTuple{Type,Data}Name support 0- and 1-tuples Previously, these functions were hardcoded so as to always `error` whenever given an argument of 0 or 1. This restriction can be lifted pretty easily, however. This requires a slight tweak to `isBuiltInOcc_maybe` in `TysWiredIn` to allow it to recognize `Unit#` (which is the hard-wired `OccName` for unboxed 1-tuples). Fixes #12977. Test Plan: make test TEST=12977 Reviewers: austin, goldfire, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2847 GHC Trac Issues: #12977 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 15:43:17 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 15:43:17 -0000 Subject: [GHC] #12965: String merging broken on Windows In-Reply-To: <046.4ab9842a6728ed7002fe72135f75869e@haskell.org> References: <046.4ab9842a6728ed7002fe72135f75869e@haskell.org> Message-ID: <061.b0049e3d8938f105cb9e1488b3a0c2df@haskell.org> #12965: String merging broken on Windows ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by Ben Gamari ): In [changeset:"be5384cea2b89791a9334c4eaa313edcc4055042/ghc" be5384ce/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="be5384cea2b89791a9334c4eaa313edcc4055042" testsuite: Mark T9577 as broken due to #12965 Test Plan: validate Reviewers: austin, Phyx Reviewed By: Phyx Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2835 GHC Trac Issues: #12965 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 15:43:37 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 15:43:37 -0000 Subject: [GHC] #10614: Show constraints in ``Found hole...'' In-Reply-To: <047.e629c8600a92660c55de2127511a14cd@haskell.org> References: <047.e629c8600a92660c55de2127511a14cd@haskell.org> Message-ID: <062.b484c0f2597b3150a015a629557d7a6e@haskell.org> #10614: Show constraints in ``Found hole...'' -------------------------------------+------------------------------------- Reporter: bjmprice | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://phabricator.haskell.org/D2767 -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 15:43:54 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 15:43:54 -0000 Subject: [GHC] #7289: Mingw FPU init not Windows compatible. In-Reply-To: <046.d34d1fd66180608dd1232dbfc9430105@haskell.org> References: <046.d34d1fd66180608dd1232dbfc9430105@haskell.org> Message-ID: <061.f8fcde5ff151d4ce53a13826c6bd69dd@haskell.org> #7289: Mingw FPU init not Windows compatible. -------------------------------------+------------------------------------- Reporter: Lennart | Owner: Phyx- Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Runtime System | Version: 7.2.2 Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2819 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 15:44:34 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 15:44:34 -0000 Subject: [GHC] #12977: Template Haskell: unboxedTupleTypeName doesn't handle unboxed 0- and 1-tuples In-Reply-To: <050.5008aa7e061a856376f030d970571fea@haskell.org> References: <050.5008aa7e061a856376f030d970571fea@haskell.org> Message-ID: <065.0048feae1fb77b00315dce857d7de540@haskell.org> #12977: Template Haskell: unboxedTupleTypeName doesn't handle unboxed 0- and 1-tuples -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Template Haskell | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2847 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 16:13:51 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 16:13:51 -0000 Subject: [GHC] #8440: Get rid of the remaining static flags In-Reply-To: <052.744af3e10192bedb98c0b515d9a6cc6d@haskell.org> References: <052.744af3e10192bedb98c0b515d9a6cc6d@haskell.org> Message-ID: <067.d4e0a6dc0846a606c9cc712144ad2bf0@haskell.org> #8440: Get rid of the remaining static flags -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: Type: task | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2839 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D2839 Comment: Yay, hsyl20 picked this up! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 16:28:00 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 16:28:00 -0000 Subject: [GHC] #9890: RTS -qa option is helpful but under-documented In-Reply-To: <049.126a2e59b04d15cfa71935d2118594d3@haskell.org> References: <049.126a2e59b04d15cfa71935d2118594d3@haskell.org> Message-ID: <064.3436adcfc543cf22e40db58a18885baf@haskell.org> #9890: RTS -qa option is helpful but under-documented -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: Type: task | Status: closed Priority: normal | Milestone: 8.0.2 Component: Runtime System | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2850 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: It turns out that there is in fact [[https://phabricator.haskell.org/diffusion/GHC/browse/master/docs/users_guide /using- concurrent.rst;52c5e55348170f27f5ef1cb010c4c96ab4aa47cc$153-165|documentation]] for this flag -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 16:43:08 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 16:43:08 -0000 Subject: [GHC] #12974: Solution to regular expression is no longer valid In-Reply-To: <049.7341c9cdb661fd57e27a365180236c9a@haskell.org> References: <049.7341c9cdb661fd57e27a365180236c9a@haskell.org> Message-ID: <064.08c9abdaa994f51c04ae5836400b069b@haskell.org> #12974: Solution to regular expression is no longer valid ---------------------------------+-------------------------------------- Reporter: pjljvdlaar | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: regex Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by bgamari): To install the dependencies required for this test, {{{ $ cabal install hunit regex-posix }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 16:45:35 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 16:45:35 -0000 Subject: [GHC] #12970: Add default implementation for Bits.bitSize In-Reply-To: <045.18bc248265b05555e123c1ad78e88bb9@haskell.org> References: <045.18bc248265b05555e123c1ad78e88bb9@haskell.org> Message-ID: <060.e8b77a26646baa75a8f6660139ca9b38@haskell.org> #12970: Add default implementation for Bits.bitSize -------------------------------------+------------------------------------- Reporter: txnull | Owner: Type: feature request | Status: upstream Priority: normal | Milestone: Component: libraries/base | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: core-libraries-committee@… (added) * status: new => upstream Comment: This would need to be cleared with the [[https://wiki.haskell.org/Core_Libraries_Committee|Core Libraries Committee]]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 16:47:11 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 16:47:11 -0000 Subject: [GHC] #12974: Solution to regular expression is no longer valid In-Reply-To: <049.7341c9cdb661fd57e27a365180236c9a@haskell.org> References: <049.7341c9cdb661fd57e27a365180236c9a@haskell.org> Message-ID: <064.7e99cd3c0ce98a95ca7a219d3a03f03a@haskell.org> #12974: Solution to regular expression is no longer valid ---------------------------------+-------------------------------------- Reporter: pjljvdlaar | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: regex Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by bgamari): Hmm, I am unable to reproduce this on x86_64 Linux with GHC 8.0.1, `HUnit-1.5.0.0`, and `regex-posix-0.95.2`. Trying Windows next. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 16:49:23 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 16:49:23 -0000 Subject: [GHC] #12967: GHC 8.0.1 Panic for current Aeson 1.0.2.1 In-Reply-To: <048.15995c38bd0c9449abab339f2616c179@haskell.org> References: <048.15995c38bd0c9449abab339f2616c179@haskell.org> Message-ID: <063.0e4ac6a18abbb4d49760a653e560cf35@haskell.org> #12967: GHC 8.0.1 Panic for current Aeson 1.0.2.1 -------------------------------------+------------------------------------- Reporter: bitemyapp | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => infoneeded -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 16:49:53 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 16:49:53 -0000 Subject: [GHC] #12478: Template Haskell support for unboxed sums In-Reply-To: <050.ac92f1e30012cfcda45bbbcb5dda55fd@haskell.org> References: <050.ac92f1e30012cfcda45bbbcb5dda55fd@haskell.org> Message-ID: <065.698a4cc95d8c0988de87e7d9397b16fc@haskell.org> #12478: Template Haskell support for unboxed sums -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: Template Haskell | Version: 8.1 Resolution: fixed | Keywords: | TemplateHaskell Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | th/T12478_{1,2,3,4} Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2448, Wiki Page: | Phab:D2854 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * differential: Phab:D2448 => Phab:D2448, Phab:D2854 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 16:50:45 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 16:50:45 -0000 Subject: [GHC] #12514: Can't write unboxed sum type constructors in prefix form In-Reply-To: <050.841e8669fe47472e53beeefaf89bc022@haskell.org> References: <050.841e8669fe47472e53beeefaf89bc022@haskell.org> Message-ID: <065.d2f8275dc238a4cc80eb7cea3bdbba97@haskell.org> #12514: Can't write unboxed sum type constructors in prefix form -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): While we await a design for prefix unboxed sum type/data constructors in Haskell, a convenient workaround for this issue is to just use Template Haskell. (I've opened Phab:D2854 for this.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 16:51:07 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 16:51:07 -0000 Subject: [GHC] #12974: Solution to regular expression is no longer valid In-Reply-To: <049.7341c9cdb661fd57e27a365180236c9a@haskell.org> References: <049.7341c9cdb661fd57e27a365180236c9a@haskell.org> Message-ID: <064.ea09b719135a3615d0704157ddad2097@haskell.org> #12974: Solution to regular expression is no longer valid ---------------------------------+-------------------------------------- Reporter: pjljvdlaar | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: regex Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by bgamari): Hmm, interesting. Indeed this is reproducible with the same versions on Windows. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 16:59:20 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 16:59:20 -0000 Subject: [GHC] #12954: unexpected uncaught segmentation error in arbitrary precision Integer calculations with modestly large numbers In-Reply-To: <046.4a50f65ae4b117a9a39023c6be40e710@haskell.org> References: <046.4a50f65ae4b117a9a39023c6be40e710@haskell.org> Message-ID: <061.caac1c455dccc61f856457d6465304d2@haskell.org> #12954: unexpected uncaught segmentation error in arbitrary precision Integer calculations with modestly large numbers ----------------------------------+-------------------------------------- Reporter: geraint | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Comment (by bgamari): Indeed I can reproduce this on our Mac Mini but sadly can't convince `lldb` to attach to the compiler. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 17:01:12 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 17:01:12 -0000 Subject: [GHC] #12953: Use computed gotos in the interpreter when the compiler supports it In-Reply-To: <047.553281fe81ba5e2200adafd7df4ff001@haskell.org> References: <047.553281fe81ba5e2200adafd7df4ff001@haskell.org> Message-ID: <062.77c26c9a59e83f4889df2d00243ba377@haskell.org> #12953: Use computed gotos in the interpreter when the compiler supports it -------------------------------------+------------------------------------- Reporter: dobenour | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: interpreter 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: | -------------------------------------+------------------------------------- Comment (by bgamari): The [[https://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html|gcc documentation]] has a nice description of this feature. It seems that the only major compiler that does not support this is Visual C++. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 17:03:30 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 17:03:30 -0000 Subject: [GHC] #12949: Pattern coverage mistake In-Reply-To: <045.3db1ccae2330725ee6ce9cf1d67c2922@haskell.org> References: <045.3db1ccae2330725ee6ce9cf1d67c2922@haskell.org> Message-ID: <060.93aa2e6f6a566a552e2b81edcd78ff9e@haskell.org> #12949: Pattern coverage mistake -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: gkaracha Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: => gkaracha * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 17:13:35 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 17:13:35 -0000 Subject: [GHC] #12954: unexpected uncaught segmentation error in arbitrary precision Integer calculations with modestly large numbers In-Reply-To: <046.4a50f65ae4b117a9a39023c6be40e710@haskell.org> References: <046.4a50f65ae4b117a9a39023c6be40e710@haskell.org> Message-ID: <061.357da405a4d58532a30c15484aed6fbf@haskell.org> #12954: unexpected uncaught segmentation error in arbitrary precision Integer calculations with modestly large numbers ----------------------------------+-------------------------------------- Reporter: geraint | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: GHCi | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Changes (by bgamari): * cc: hvr (added) * priority: normal => high * milestone: => 8.2.1 Comment: Alright, here's a backtrace, {{{ ghc-mini:~ bgamari$ sudo lldb -- /Users/bgamari/ghc-8.0.1/lib/ghc-8.0.1/bin/ghc -B/Users/bgamari/ghc-8.0.1/lib/ghc-8.0.1 --interactive Password: (lldb) target create "/Users/bgamari/ghc-8.0.1/lib/ghc-8.0.1/bin/ghc" run Current executable set to '/Users/bgamari/ghc-8.0.1/lib/ghc-8.0.1/bin/ghc' (x86_64). (lldb) settings set -- target.run-args "-B/Users/bgamari/ghc-8.0.1/lib/ghc-8.0.1" "--interactive" (lldb) run Process 99769 launched: '/Users/bgamari/ghc-8.0.1/lib/ghc-8.0.1/bin/ghc' (x86_64) GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help Prelude> 2^(10^7) :: Integer Process 99769 stopped * thread #2: tid = 0x6cc7f82, 0x0000000108169cfd libHSinteger- gmp-1.0.0.1-ghc8.0.1.dylib`__gmpn_mul + 3437, stop reason = EXC_BAD_ACCESS (code=1, address=0x70000d43ad38) frame #0: 0x0000000108169cfd libHSinteger- gmp-1.0.0.1-ghc8.0.1.dylib`__gmpn_mul + 3437 libHSinteger-gmp-1.0.0.1-ghc8.0.1.dylib`__gmpn_mul: -> 0x108169cfd <+3437>: callq 0x10818d6a0 ; __gmpn_toom63_mul 0x108169d02 <+3442>: jmp 0x10816975f ; <+1999> 0x108169d07 <+3447>: movq -0x118(%rbp), %rcx 0x108169d0e <+3454>: movq -0x158(%rbp), %rdx (lldb) bt * thread #2: tid = 0x6cc7f82, 0x0000000108169cfd libHSinteger- gmp-1.0.0.1-ghc8.0.1.dylib`__gmpn_mul + 3437, stop reason = EXC_BAD_ACCESS (code=1, address=0x70000d43ad38) * frame #0: 0x0000000108169cfd libHSinteger- gmp-1.0.0.1-ghc8.0.1.dylib`__gmpn_mul + 3437 frame #1: 0x0000000108169df5 libHSinteger- gmp-1.0.0.1-ghc8.0.1.dylib`__gmpn_mul + 3685 frame #2: 0x00000001081701aa libHSinteger- gmp-1.0.0.1-ghc8.0.1.dylib`__gmpn_tdiv_qr + 2986 frame #3: 0x0000000108145742 libHSinteger- gmp-1.0.0.1-ghc8.0.1.dylib`crUO_info + 50 }}} hvr, do you have any idea what is going on here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 17:20:20 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 17:20:20 -0000 Subject: [GHC] #12971: Paths are encoded incorrectly when invoking GCC (was: Change default tmpdir) In-Reply-To: <051.d90144b3c0ebb71e2cb75f2b09f4ef06@haskell.org> References: <051.d90144b3c0ebb71e2cb75f2b09f4ef06@haskell.org> Message-ID: <066.b681f288e158e30b9c814504fa8fc4ee@haskell.org> #12971: Paths are encoded incorrectly when invoking GCC ---------------------------------+---------------------------------------- Reporter: erikprantare | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by bgamari): * priority: normal => highest * os: Unknown/Multiple => Windows * type: feature request => bug * milestone: => 8.2.1 Comment: Oh dear, it looks like we are failing to encode a filename with UTF-16 as expected by Windows. This is quite -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 17:20:38 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 17:20:38 -0000 Subject: [GHC] #12954: unexpected uncaught segmentation error in arbitrary precision Integer calculations with modestly large numbers In-Reply-To: <046.4a50f65ae4b117a9a39023c6be40e710@haskell.org> References: <046.4a50f65ae4b117a9a39023c6be40e710@haskell.org> Message-ID: <061.9744bb80f164f09cf0f8d68fed484f98@haskell.org> #12954: unexpected uncaught segmentation error in arbitrary precision Integer calculations with modestly large numbers ----------------------------------+-------------------------------------- Reporter: geraint | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: GHCi | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Comment (by rwbarton): It's probably the same issue as #7655. See ticket:7655#comment:33 specifically. What version of libgmp are you using? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 17:26:43 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 17:26:43 -0000 Subject: [GHC] #12971: Paths are encoded incorrectly when invoking GCC In-Reply-To: <051.d90144b3c0ebb71e2cb75f2b09f4ef06@haskell.org> References: <051.d90144b3c0ebb71e2cb75f2b09f4ef06@haskell.org> Message-ID: <066.6128ab8652321494014c83291f5628d6@haskell.org> #12971: Paths are encoded incorrectly when invoking GCC ---------------------------------+---------------------------------------- Reporter: erikprantare | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by bgamari): Indeed I can reproduce this with, {{{ $ mkdir Präntare $ export TMP=`pwd`/Präntare $ echo 'main = putStrLn "hello world!"' > Hello.hs $ ghc Hello.hs 1 of 1] Compiling Main ( Hello.hs, Hello.o ) Linking Hello.exe ... realgcc.exe: error: C:\msys64\home\ben\Präntare\ghc2596_0\ghc_4.c: No such file or directory realgcc.exe: fatal error: no input files compilation terminated. `gcc.exe' failed in phase `C Compiler'. (Exit code: 1) $ export TMP=/tmp $ ghc Hello.hs Linking Hello.exe ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 17:28:19 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 17:28:19 -0000 Subject: [GHC] #12971: Paths are encoded incorrectly when invoking GCC In-Reply-To: <051.d90144b3c0ebb71e2cb75f2b09f4ef06@haskell.org> References: <051.d90144b3c0ebb71e2cb75f2b09f4ef06@haskell.org> Message-ID: <066.343f5513d00ae940bf586f394ca9d8e0@haskell.org> #12971: Paths are encoded incorrectly when invoking GCC ---------------------------------+---------------------------------------- Reporter: erikprantare | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by bgamari): `ghc -v` reveals that the failing command is, {{{ Linking Hello.exe ... *** C Compiler: "C:\msys64\home\ben\ghc-8.0.1-i386\lib/../mingw/bin/gcc.exe" "-U__i686" "-march=i686" "-fno-stack-protector" "-DTABLES_NEXT_TO_CODE" "-c" "C:\msys64\home\ben\Prntare\ghc4688_0\ghc_4.c" "-o" "C:\msys64\home\ben\Prntare\ghc4688_0\ghc_5.o" "-IC:\msys64\home\ben\ghc-8.0.1-i386\lib/include" realgcc.exe: error: C:\msys64\home\ben\Präntare\ghc4688_0\ghc_4.c: No such file or directory realgcc.exe: fatal error: no input files compilation terminated. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 17:36:30 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 17:36:30 -0000 Subject: [GHC] #12974: Solution to regular expression is no longer valid In-Reply-To: <049.7341c9cdb661fd57e27a365180236c9a@haskell.org> References: <049.7341c9cdb661fd57e27a365180236c9a@haskell.org> Message-ID: <064.c019a0ff5dce6654fc09dd09bf3d2f49@haskell.org> #12974: Solution to regular expression is no longer valid ---------------------------------+-------------------------------------- Reporter: pjljvdlaar | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: regex Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by rwbarton): Not too surprising that it is Windows-specific if you look at the regex- posix.cabal file (it uses bundled sources on Windows only). But the GHC version dependence is a mystery. Perhaps it could be the string literal inlining issue, #12757? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 17:37:28 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 17:37:28 -0000 Subject: [GHC] #12971: Paths are encoded incorrectly when invoking GCC In-Reply-To: <051.d90144b3c0ebb71e2cb75f2b09f4ef06@haskell.org> References: <051.d90144b3c0ebb71e2cb75f2b09f4ef06@haskell.org> Message-ID: <066.6829a20460edf9a8e7b2f101de13aba5@haskell.org> #12971: Paths are encoded incorrectly when invoking GCC ---------------------------------+---------------------------------------- Reporter: erikprantare | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by bgamari): It seems quite likely that `DriverPipeline.mkExtraObj` is responsible for this call but it doesn't have any immediately evident issues. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 17:46:31 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 17:46:31 -0000 Subject: [GHC] #12971: Paths are encoded incorrectly when invoking GCC In-Reply-To: <051.d90144b3c0ebb71e2cb75f2b09f4ef06@haskell.org> References: <051.d90144b3c0ebb71e2cb75f2b09f4ef06@haskell.org> Message-ID: <066.7de745d62e7508e76e5b774968bd9303@haskell.org> #12971: Paths are encoded incorrectly when invoking GCC ---------------------------------+---------------------------------------- Reporter: erikprantare | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by bgamari): Hmm, the missing `ä` above may have just been due to the terminal. Redirecting `ghc`'s output to a file and viewing the file with vim shows the following, {{{ Linking Hello.exe ... *** C Compiler: "C:\msys64\home\ben\ghc-8.0.1-i386\lib/../mingw/bin/gcc.exe" "-U__i686" \ "-march=i686" "-fno-stack-protector" "-DTABLES_NEXT_TO_CODE" "-c" \ "C:\msys64\home\ben\Pr<84>ntare\ghc4344_0\ghc_4.c" \ "-o" "C:\msys64\home\ben\Pr<84>ntare\ghc4344_0\ghc_5.o" \ "-IC:\msys64\home\ben\ghc-8.0.1-i386\lib/include" realgcc.exe: error: C:\msys64\home\ben\Präntare\ghc4344_0\ghc_4.c: No such file or directory }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 18:07:39 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 18:07:39 -0000 Subject: [GHC] #12959: GHC doesn't warn about missing implementations for class methods beginning with an underscore In-Reply-To: <050.f1c049718f4b94fba939144b405d48bc@haskell.org> References: <050.f1c049718f4b94fba939144b405d48bc@haskell.org> Message-ID: <065.3e1edea2db7dfe6efcb8a7db041d36f9@haskell.org> #12959: GHC doesn't warn about missing implementations for class methods beginning with an underscore -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2849 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"503219e3e1667ac39607021b2d9586260fbab32b/ghc" 503219e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="503219e3e1667ac39607021b2d9586260fbab32b" Warn about missing instance methods that start with an underscore Previously, GHC would not warn whenever there was a class instance that didn't implement a class method whose name begins with an underscore. Fixes #12959. Test Plan: make test TEST=WarnMinimal Reviewers: austin, bgamari, simonpj Reviewed By: bgamari, simonpj Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2849 GHC Trac Issues: #12959 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 18:07:39 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 18:07:39 -0000 Subject: [GHC] #5205: Control.Monad.forever leaks space In-Reply-To: <043.8fcf8c307e1ec9852b70a8a6ac25e38b@haskell.org> References: <043.8fcf8c307e1ec9852b70a8a6ac25e38b@haskell.org> Message-ID: <058.fd1aedbe0b49cc6f7f0e7ac1111d2be5@haskell.org> #5205: Control.Monad.forever leaks space --------------------------------------------+------------------------------ Reporter: akio | Owner: pcapriotti Type: bug | Status: closed Priority: high | Milestone: 7.6.1 Component: libraries/base | Version: 7.0.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime performance bug | Test Case: T5205 Blocked By: | Blocking: Related Tickets: | --------------------------------------------+------------------------------ Comment (by Ben Gamari ): In [changeset:"d39816285341cf639b51ae14f65c63a3e89bba95/ghc" d398162/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d39816285341cf639b51ae14f65c63a3e89bba95" testsuite: Separate out Windows results for T5205 This test seems to have much different allocation behavior on Windows and Linux. Previously we had widened the acceptance window to 7% to accomodate this, but even this isn't enough any more. Instead of further widening the window let's just give an expected number for each platform. Really, this is precisely the issue with our performance testing model which I've been complaining about in #12758. Fixes test for #5205 on 64-bit Windows. Test Plan: Validate on Windows Reviewers: austin Subscribers: thomie, Phyx Differential Revision: https://phabricator.haskell.org/D2848 GHC Trac Issues: #5205 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 18:07:39 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 18:07:39 -0000 Subject: [GHC] #10007: Fix misattribution of Cost Centre profiles to lintAnnots In-Reply-To: <052.018bee922f3a1f3c0286b790702cf38d@haskell.org> References: <052.018bee922f3a1f3c0286b790702cf38d@haskell.org> Message-ID: <067.eae7e495f0cf8f23d43946c554b650d0@haskell.org> #10007: Fix misattribution of Cost Centre profiles to lintAnnots -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Profiling | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #9961,#5654 | Differential Rev(s): Phab:D616 Wiki Page: | Phab:D636 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"394231b301efb6b56654b0a480ab794fe3b7e4db/ghc" 394231b3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="394231b301efb6b56654b0a480ab794fe3b7e4db" Fix cost-centre-stacks bug (#5654) This fixes some cases of wrong stacks being generated by the profiler. For background and details on the fix see `Note [Evaluating functions with profiling]` in `rts/Apply.cmm`. This does have an impact on allocations for some programs when profiling. nofib results: ``` k-nucleotide +0.0% +8.8% +11.0% +11.0% 0.0% puzzle +0.0% +12.5% 0.244 0.246 0.0% typecheck 0.0% +8.7% +16.1% +16.2% 0.0% ------------------------------------------------------------------------ -------- Min -0.0% -0.0% -34.4% -35.5% -25.0% Max +0.0% +12.5% +48.9% +49.4% +10.6% Geometric Mean +0.0% +0.6% +2.0% +1.8% -0.3% ``` But runtimes don't seem to be affected much, and the examples I looked at were completely legitimate. For example, in puzzle we have this: ``` position :: ItemType -> StateType -> BankType position Bono = bonoPos position Edge = edgePos position Larry = larryPos position Adam = adamPos ``` where the identifiers on the rhs are all record selectors. Previously the profiler gave a stack that looked like ``` position bonoPos ... ``` i.e. `bonoPos` was at the same level of the call stack as `position`, but now it looks like ``` position bonoPos ... ``` I used the normaliser from the testsuite to diff the profiling output from other nofib programs and they all looked better. Test Plan: * the broken test passes * validate * compiled and ran all of nofib, measured perf, diff'd several .prof files Reviewers: niteria, erikd, austin, scpmw, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2804 GHC Trac Issues: #5654, #10007 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 18:07:39 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 18:07:39 -0000 Subject: [GHC] #12758: Bring sanity to our performance testsuite In-Reply-To: <046.023630bbf855f7a4ed786cb14a3639ea@haskell.org> References: <046.023630bbf855f7a4ed786cb14a3639ea@haskell.org> Message-ID: <061.d44d72b1757f02ec215d33c78a850493@haskell.org> #12758: Bring sanity to our performance testsuite -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Test Suite | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"d39816285341cf639b51ae14f65c63a3e89bba95/ghc" d398162/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d39816285341cf639b51ae14f65c63a3e89bba95" testsuite: Separate out Windows results for T5205 This test seems to have much different allocation behavior on Windows and Linux. Previously we had widened the acceptance window to 7% to accomodate this, but even this isn't enough any more. Instead of further widening the window let's just give an expected number for each platform. Really, this is precisely the issue with our performance testing model which I've been complaining about in #12758. Fixes test for #5205 on 64-bit Windows. Test Plan: Validate on Windows Reviewers: austin Subscribers: thomie, Phyx Differential Revision: https://phabricator.haskell.org/D2848 GHC Trac Issues: #5205 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 18:07:39 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 18:07:39 -0000 Subject: [GHC] #5654: Profiling semantics bug In-Reply-To: <047.ac296d247951e42a341a674c3c07d355@haskell.org> References: <047.ac296d247951e42a341a674c3c07d355@haskell.org> Message-ID: <062.a0a8de8bc2643823b28ca35e9be4befa@haskell.org> #5654: Profiling semantics bug -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: low | Milestone: Component: Profiling | Version: 7.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | profiling/should_run/scc004 Blocked By: | Blocking: Related Tickets: #10007 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"394231b301efb6b56654b0a480ab794fe3b7e4db/ghc" 394231b3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="394231b301efb6b56654b0a480ab794fe3b7e4db" Fix cost-centre-stacks bug (#5654) This fixes some cases of wrong stacks being generated by the profiler. For background and details on the fix see `Note [Evaluating functions with profiling]` in `rts/Apply.cmm`. This does have an impact on allocations for some programs when profiling. nofib results: ``` k-nucleotide +0.0% +8.8% +11.0% +11.0% 0.0% puzzle +0.0% +12.5% 0.244 0.246 0.0% typecheck 0.0% +8.7% +16.1% +16.2% 0.0% ------------------------------------------------------------------------ -------- Min -0.0% -0.0% -34.4% -35.5% -25.0% Max +0.0% +12.5% +48.9% +49.4% +10.6% Geometric Mean +0.0% +0.6% +2.0% +1.8% -0.3% ``` But runtimes don't seem to be affected much, and the examples I looked at were completely legitimate. For example, in puzzle we have this: ``` position :: ItemType -> StateType -> BankType position Bono = bonoPos position Edge = edgePos position Larry = larryPos position Adam = adamPos ``` where the identifiers on the rhs are all record selectors. Previously the profiler gave a stack that looked like ``` position bonoPos ... ``` i.e. `bonoPos` was at the same level of the call stack as `position`, but now it looks like ``` position bonoPos ... ``` I used the normaliser from the testsuite to diff the profiling output from other nofib programs and they all looked better. Test Plan: * the broken test passes * validate * compiled and ran all of nofib, measured perf, diff'd several .prof files Reviewers: niteria, erikd, austin, scpmw, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2804 GHC Trac Issues: #5654, #10007 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 18:09:13 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 18:09:13 -0000 Subject: [GHC] #12959: GHC doesn't warn about missing implementations for class methods beginning with an underscore In-Reply-To: <050.f1c049718f4b94fba939144b405d48bc@haskell.org> References: <050.f1c049718f4b94fba939144b405d48bc@haskell.org> Message-ID: <065.a8e48d8b653c9e19d5fde49cdb955b73@haskell.org> #12959: GHC doesn't warn about missing implementations for class methods beginning with an underscore -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2849 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 18:11:08 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 18:11:08 -0000 Subject: [GHC] #5654: Profiling semantics bug In-Reply-To: <047.ac296d247951e42a341a674c3c07d355@haskell.org> References: <047.ac296d247951e42a341a674c3c07d355@haskell.org> Message-ID: <062.f86c611b18a6ed681621f58422d7f59f@haskell.org> #5654: Profiling semantics bug -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: closed Priority: low | Milestone: 8.2.1 Component: Profiling | Version: 7.2.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | profiling/should_run/scc004 Blocked By: | Blocking: Related Tickets: #10007 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 18:57:03 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 18:57:03 -0000 Subject: [GHC] #12962: No automatic SCC annotations for functions marked INLINABLE In-Reply-To: <054.f2234820ab9cebe1f15e9179cc25a0ab@haskell.org> References: <054.f2234820ab9cebe1f15e9179cc25a0ab@haskell.org> Message-ID: <069.1961c34282373cb0c24920f5a25c75d6@haskell.org> #12962: No automatic SCC annotations for functions marked INLINABLE -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 8.0.1 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12963 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): There's a test (`profinline001`) that assumes `INLINABLE` functions don't get cost centers. So it seems like this was intentional. Should I still make this change? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 19:15:56 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 19:15:56 -0000 Subject: [GHC] #12986: Ignore case when parsing language pragmas Message-ID: <045.f0f51830416b41e6e2c00f8c5ae945a4@haskell.org> #12986: Ignore case when parsing language pragmas -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Parser) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It's annoying to have to remember exactly how a language extension is supposed to be capitalized. It seems highly unlikely that we will ever have two different language extensions that differ only by case. Therefore, I think GHC should ignore case when matching `{-# LANGUAGE #-}` pragmas. Thus, we should accept not only `UndecidableSuperClasses` but also `UndecidableSuperclasses`, etc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 19:22:43 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 19:22:43 -0000 Subject: [GHC] #10301: Plugins/dynamic loading subtly broken (it seems) In-Reply-To: <052.1efd9612b96733295747c4ea13bc0951@haskell.org> References: <052.1efd9612b96733295747c4ea13bc0951@haskell.org> Message-ID: <067.54b8ca68f6fc3906c5fc20e03fecb786@haskell.org> #10301: Plugins/dynamic loading subtly broken (it seems) -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | plugins/T10294 plugins/frontend01 Blocked By: | Blocking: Related Tickets: #8276 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: angerman (added) Comment: `T10294` seems to pass on Travis pretty reliably since c3c702441137dc8f7ee0dd5ac313be96d625459a. Strangely enough I've not seen it pass locally nor on Phabricator. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 19:30:07 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 19:30:07 -0000 Subject: [GHC] #10301: Plugins/dynamic loading subtly broken (it seems) In-Reply-To: <052.1efd9612b96733295747c4ea13bc0951@haskell.org> References: <052.1efd9612b96733295747c4ea13bc0951@haskell.org> Message-ID: <067.247a974d3958a873de253461d7263da4@haskell.org> #10301: Plugins/dynamic loading subtly broken (it seems) -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | plugins/T10294 plugins/frontend01 Blocked By: | Blocking: Related Tickets: #8276 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.2.1 Comment: Ahh, I see. `.travis.yml` configures the build with `DYNAMIC_GHC_PROGRAMS = NO`, which is the only case where we expected `T10294` to fail. Consequently it seems that we can mark this as fixed. Hooray! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 19:33:35 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 19:33:35 -0000 Subject: [GHC] #12971: Paths are encoded incorrectly when invoking GCC In-Reply-To: <051.d90144b3c0ebb71e2cb75f2b09f4ef06@haskell.org> References: <051.d90144b3c0ebb71e2cb75f2b09f4ef06@haskell.org> Message-ID: <066.c0f80adcadb4687f1cd87c1b8019d41e@haskell.org> #12971: Paths are encoded incorrectly when invoking GCC ---------------------------------+---------------------------------------- Reporter: erikprantare | Owner: Phyx Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by bgamari): * owner: => Phyx Comment: Phyx kindly said he would take this from here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 20:03:57 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 20:03:57 -0000 Subject: [GHC] #12966: GHC panics with forall and constraint In-Reply-To: <043.89f40a41f374846eb7676b05fcc51b80@haskell.org> References: <043.89f40a41f374846eb7676b05fcc51b80@haskell.org> Message-ID: <058.a1c24c7b1725fa2f7a71e17b3175acbc@haskell.org> #12966: GHC panics with forall and constraint -------------------------------------+------------------------------------- Reporter: xcmw | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => wontfix * milestone: => 8.2.1 Comment: Thanks for the report, xcmw! On `master` this expectedly fails with, {{{ λ> :set -XRankNTypes λ> type Maybeify c = forall d. (c d) => ((~) (Maybe d)) :3:39: error: • Expecting one more argument to ‘(~) (Maybe d)’ Expected a type, but ‘(~) (Maybe d)’ has kind ‘* -> Constraint’ • In the type ‘forall d. (c d) => ((~) (Maybe d))’ In the type declaration for ‘Maybeify’ }}} This was likely fixed by #11660, which won't be backported to 8.0. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 20:04:27 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 20:04:27 -0000 Subject: [GHC] #12966: GHC panics with forall and constraint In-Reply-To: <043.89f40a41f374846eb7676b05fcc51b80@haskell.org> References: <043.89f40a41f374846eb7676b05fcc51b80@haskell.org> Message-ID: <058.b1c477ade7b834a636da758b576a9321@haskell.org> #12966: GHC panics with forall and constraint -------------------------------------+------------------------------------- Reporter: xcmw | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/T12966 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * testcase: => typecheck/T12966 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 20:36:56 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 20:36:56 -0000 Subject: [GHC] #12979: -fspecialise-aggressively is not documented In-Reply-To: <049.e943358d5b891507f5e56a8c57be0460@haskell.org> References: <049.e943358d5b891507f5e56a8c57be0460@haskell.org> Message-ID: <064.4d92eface5f4fc552b9dd9bbab7f5fb1@haskell.org> #12979: -fspecialise-aggressively is not documented -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by danharaj): The relevant documentation seems to be: {{{ Note [Specialise imported INLINABLE things] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ What imported functions do we specialise? The basic set is * DFuns and things with INLINABLE pragmas. but with -fspecialise-aggressively we add * Anything with an unfolding template Trac #8874 has a good example of why we want to auto-specialise DFuns. We have the -fspecialise-aggressively flag (usually off), because we risk lots of orphan modules from over-vigorous specialisation. However it's not a big deal: anything non-recursive with an unfolding-template will probably have been inlined already. }}} I have experimented with using this flag too, but it didn't do much for my use case beyond `-fexpose-all-unfoldings` and generous use of `INLINABLE`. As I understand it, instead I could use `-fexpose-all-unfoldings` and `-fspecialise-aggressively` and need not worry about putting `INLINABLE` annotations on my declarations. Is that correct? By the way, it is really brutal on compilation times! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 21:00:49 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 21:00:49 -0000 Subject: [GHC] #12966: GHC panics with forall and constraint In-Reply-To: <043.89f40a41f374846eb7676b05fcc51b80@haskell.org> References: <043.89f40a41f374846eb7676b05fcc51b80@haskell.org> Message-ID: <058.dc3a203d0703f9348c02d4adf2e93d49@haskell.org> #12966: GHC panics with forall and constraint -------------------------------------+------------------------------------- Reporter: xcmw | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/T12966 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Adding a test is good. For comment:2 do I gather that you have done so? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 21:08:57 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 21:08:57 -0000 Subject: [GHC] #12987: Core lint error with levity polymorphism Message-ID: <051.73a5e5a2c40d220576fa03522f240f43@haskell.org> #12987: Core lint error with levity polymorphism -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple LevityPolymorphism | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ $ ghci -ignore-dot-ghci GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help Prelude> import GHC.Types Prelude GHC.Types> :set -XTypeInType Prelude GHC.Types> class NUM (a :: TYPE rep) where add :: a -> a -> a Prelude GHC.Types> }}} works, but with `-dcore-lint` I get a core lint error {{{ $ ghci -ignore-dot-ghci GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help Prelude> import GHC.Types Prelude GHC.Types> :set -XTypeInType Prelude GHC.Types> :set -dcore-lint Prelude GHC.Types> class NUM (a :: TYPE rep) where add :: a -> a -> a *** Core Lint errors : in result of Tidy Core *** : warning: In the type ‘forall a_a17Q. NUM a_a17Q => a_a17Q -> a_a17Q -> a_a17Q’ Ill-kinded argument in type or kind ‘a_a17Q -> a_a17Q’ type or kind ‘a_a17Q -> a_a17Q’ kind: TYPE rep_a17P : warning: In the type ‘forall a_a17Q. NUM a_a17Q => a_a17Q -> a_a17Q -> a_a17Q’ Ill-kinded argument in type or kind ‘a_a17Q -> a_a17Q -> a_a17Q’ type or kind ‘a_a17Q -> a_a17Q -> a_a17Q’ kind: TYPE rep_a17P *** Offending Program *** add [InlPrag=INLINE] :: forall a_a17Q. NUM a_a17Q => a_a17Q -> a_a17Q -> a_a17Q [GblId[ClassOp], Arity=1, Caf=NoCafRefs, Str=DmdType , Unf=Unf{Src=InlineStable, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=1,unsat_ok=False,boring_ok=True) Tmpl= \ (@ (rep_a17P :: RuntimeRep)) (@ (a_a17Q :: TYPE rep_a17P)) (tpl_B1 [Occ=Once] :: NUM a_a17Q) -> tpl_B1 `cast` (N:NUM[0] _N _N :: (NUM a_a17Q :: Constraint) ~R# ((a_a17Q -> a_a17Q -> a_a17Q) :: *))}] add = \ (@ (rep_a17P :: RuntimeRep)) (@ (a_a17Q :: TYPE rep_a17P)) (tpl_B1 :: NUM a_a17Q) -> tpl_B1 `cast` (N:NUM[0] _N _N :: (NUM a_a17Q :: Constraint) ~R# ((a_a17Q -> a_a17Q -> a_a17Q) :: *)) $trModule1_r18t :: TrName [GblId, Caf=NoCafRefs, Str=DmdType] $trModule1_r18t = TrNameS "interactive"# $trModule2_r18D :: TrName [GblId, Caf=NoCafRefs, Str=DmdType] $trModule2_r18D = TrNameS "Ghci1"# $trModule :: Module [GblId, Caf=NoCafRefs, Str=DmdType] $trModule = Module $trModule1_r18t $trModule2_r18D $tc'C:NUM1_r18E :: TrName [GblId, Caf=NoCafRefs, Str=DmdType] $tc'C:NUM1_r18E = TrNameS "'C:NUM"# $tc'C:NUM :: TyCon [GblId, Caf=NoCafRefs, Str=DmdType] $tc'C:NUM = TyCon 13508714812303496948## 14031386194776682412## $trModule $tc'C:NUM1_r18E $tcNUM1_r18F :: TrName [GblId, Caf=NoCafRefs, Str=DmdType] $tcNUM1_r18F = TrNameS "NUM"# $tcNUM :: TyCon [GblId, Caf=NoCafRefs, Str=DmdType] $tcNUM = TyCon 18330307158587089132## 17437587248867430906## $trModule $tcNUM1_r18F *** End of Offense *** : error: Compilation had errors *** Exception: ExitFailure 1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 21:41:53 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 21:41:53 -0000 Subject: [GHC] #12045: Visible kind application In-Reply-To: <051.f572b464c11770181720f8a1a7ec05a5@haskell.org> References: <051.f572b464c11770181720f8a1a7ec05a5@haskell.org> Message-ID: <066.bc3ed1a1a64945b314b661ebcc38e8de@haskell.org> #12045: Visible kind application -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Iceland_jack Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | TypeApplications TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 12976 | Differential Rev(s): ​Phab:D2216 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * related: => 12976 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 21:52:08 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 21:52:08 -0000 Subject: [GHC] #12045: Visible kind application In-Reply-To: <051.f572b464c11770181720f8a1a7ec05a5@haskell.org> References: <051.f572b464c11770181720f8a1a7ec05a5@haskell.org> Message-ID: <066.f6bca5634615718f5b8ad82526e579ce@haskell.org> #12045: Visible kind application -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Iceland_jack Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | TypeApplications TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): ​Phab:D2216 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * related: 12976 => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 21:54:15 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 21:54:15 -0000 Subject: [GHC] #12708: RFC: Representation polymorphic Num In-Reply-To: <051.e9ad721b0c060306ebd4bf7d4de38fdd@haskell.org> References: <051.e9ad721b0c060306ebd4bf7d4de38fdd@haskell.org> Message-ID: <066.20601e2d3d7b5f2ed04753dfe0d8a344@haskell.org> #12708: RFC: Representation polymorphic Num -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.1 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 12980 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * related: => 12980 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 21:56:28 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 21:56:28 -0000 Subject: [GHC] #12987: Core lint error with levity polymorphism In-Reply-To: <051.73a5e5a2c40d220576fa03522f240f43@haskell.org> References: <051.73a5e5a2c40d220576fa03522f240f43@haskell.org> Message-ID: <066.dd854feeb0bef609b5374673c8251dce@haskell.org> #12987: Core lint error with levity polymorphism -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I can reproduce this in GHC 8.0.2, but not in GHC HEAD: {{{ $ inplace/bin/ghc-stage2 --interactive GHCi, version 8.1.20161215: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci λ> import GHC.Types λ> :set -XTypeInType -dcore-lint λ> class NUM (a :: TYPE rep) where add :: a -> a -> a λ> :t add add :: NUM a => a -> a -> a }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 22:21:39 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 22:21:39 -0000 Subject: [GHC] #12879: (xs -> xs) wrongly suggests TypeApplications In-Reply-To: <051.16598209ccbf8290d8f46e992fbe8e53@haskell.org> References: <051.16598209ccbf8290d8f46e992fbe8e53@haskell.org> Message-ID: <066.1d5f7141ae24460abd0ac0c011156c52@haskell.org> #12879: (xs -> xs) wrongly suggests TypeApplications -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by zyla): I believe this is fixed in HEAD: {{{ GHCi, version 8.1.20161209: http://www.haskell.org/ghc/ :? for help Prelude> map (xs -> xs) :1:6: error: Pattern syntax in expression context: xs -> xs Prelude> }}} But there's another issue - the message still appears when using as- patterns when TypeApplications is already enabled: {{{ Prelude> :set -XTypeApplications Prelude> map (xs at xs) :19:6: error: Pattern syntax in expression context: xs at xs Did you mean to enable TypeApplications? }}} Perhaps replacing it with `Type application syntax requires a space before '@'` is a good idea in this case? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 22:26:58 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 22:26:58 -0000 Subject: [GHC] #12879: (xs -> xs) wrongly suggests TypeApplications In-Reply-To: <051.16598209ccbf8290d8f46e992fbe8e53@haskell.org> References: <051.16598209ccbf8290d8f46e992fbe8e53@haskell.org> Message-ID: <066.4af38f806e0c801ac63b242cb4664af3@haskell.org> #12879: (xs -> xs) wrongly suggests TypeApplications -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): That would be a good error message -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 22:31:51 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 22:31:51 -0000 Subject: [GHC] #12973: No levity-polymorphic arguments In-Reply-To: <047.f204ee30fb0e348fef5e84b6439839c8@haskell.org> References: <047.f204ee30fb0e348fef5e84b6439839c8@haskell.org> Message-ID: <062.3ea417034bed0fd3d8804d89528f5785@haskell.org> #12973: No levity-polymorphic arguments -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * cc: Iceland_jack (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 22:54:37 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 22:54:37 -0000 Subject: [GHC] #12966: GHC panics with forall and constraint In-Reply-To: <043.89f40a41f374846eb7676b05fcc51b80@haskell.org> References: <043.89f40a41f374846eb7676b05fcc51b80@haskell.org> Message-ID: <058.7dac3efebbfd3d2b8750c2a8274b3744@haskell.org> #12966: GHC panics with forall and constraint -------------------------------------+------------------------------------- Reporter: xcmw | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/T12966 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Yes, it's in my next merge batch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 23:17:23 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 23:17:23 -0000 Subject: [GHC] #12971: Paths are encoded incorrectly when invoking GCC In-Reply-To: <051.d90144b3c0ebb71e2cb75f2b09f4ef06@haskell.org> References: <051.d90144b3c0ebb71e2cb75f2b09f4ef06@haskell.org> Message-ID: <066.e26a4ada741b2555511baed7fe386125@haskell.org> #12971: Paths are encoded incorrectly when invoking GCC ---------------------------------+---------------------------------------- Reporter: erikprantare | Owner: Phyx Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by Ben Gamari ): In [changeset:"8f0546bfaf47ec865bb0c6dc2cb0ac451367f65a/ghc" 8f0546bf/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8f0546bfaf47ec865bb0c6dc2cb0ac451367f65a" testsuite: Add test for #12971 Test Plan: Validate Reviewers: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2855 GHC Trac Issues: #12971 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 23:17:23 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 23:17:23 -0000 Subject: [GHC] #12966: GHC panics with forall and constraint In-Reply-To: <043.89f40a41f374846eb7676b05fcc51b80@haskell.org> References: <043.89f40a41f374846eb7676b05fcc51b80@haskell.org> Message-ID: <058.2cf6d86fb3383fec154f73ff6909de00@haskell.org> #12966: GHC panics with forall and constraint -------------------------------------+------------------------------------- Reporter: xcmw | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/T12966 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"81c49562570a403e8470f73f4decd3e0cb891983/ghc" 81c4956/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="81c49562570a403e8470f73f4decd3e0cb891983" testsuite: Add test for #12966 This isn't exactly a typechecker test, but it was the most appropriate directory I could think of. The issue being tested is fixed. Test Plan: Validate Reviewers: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2857 GHC Trac Issues: #12966 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 23:17:23 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 23:17:23 -0000 Subject: [GHC] #10301: Plugins/dynamic loading subtly broken (it seems) In-Reply-To: <052.1efd9612b96733295747c4ea13bc0951@haskell.org> References: <052.1efd9612b96733295747c4ea13bc0951@haskell.org> Message-ID: <067.6f48c52aa1b2b22c1f0e2479bae5446a@haskell.org> #10301: Plugins/dynamic loading subtly broken (it seems) -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | plugins/T10294 plugins/frontend01 Blocked By: | Blocking: Related Tickets: #8276 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"0cad52d6395487b617edef2b131909d3b4085be4/ghc" 0cad52d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0cad52d6395487b617edef2b131909d3b4085be4" testsuite: Mark T10294 as fixed It seems that c3c702441137dc8f7ee0dd5ac313be96d625459a resolved #10301. It took a while to notice this since it only broke when tested against a statically linked GHC, a configuration which Harbormaster doesn't test. Test Plan: Validate Reviewers: angerman, austin Subscribers: thomie, nomeata Differential Revision: https://phabricator.haskell.org/D2856 GHC Trac Issues: #10294, #10301 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 23:17:23 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 23:17:23 -0000 Subject: [GHC] #10294: Missing instances if compiling with -fplugin In-Reply-To: <046.47fd486c7f73b488b5247db11cbe3c48@haskell.org> References: <046.47fd486c7f73b488b5247db11cbe3c48@haskell.org> Message-ID: <061.4689d54f8c3383e2187fd1c167a69dc1@haskell.org> #10294: Missing instances if compiling with -fplugin -------------------------------------+------------------------------------- Reporter: jscholl | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.1 checker) | Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: GHC rejects | Test Case: valid program | plugins/T10294, plugins/T10294a Blocked By: 10420 | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"0cad52d6395487b617edef2b131909d3b4085be4/ghc" 0cad52d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0cad52d6395487b617edef2b131909d3b4085be4" testsuite: Mark T10294 as fixed It seems that c3c702441137dc8f7ee0dd5ac313be96d625459a resolved #10301. It took a while to notice this since it only broke when tested against a statically linked GHC, a configuration which Harbormaster doesn't test. Test Plan: Validate Reviewers: angerman, austin Subscribers: thomie, nomeata Differential Revision: https://phabricator.haskell.org/D2856 GHC Trac Issues: #10294, #10301 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 23:20:55 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 23:20:55 -0000 Subject: [GHC] #10301: Plugins/dynamic loading subtly broken (it seems) In-Reply-To: <052.1efd9612b96733295747c4ea13bc0951@haskell.org> References: <052.1efd9612b96733295747c4ea13bc0951@haskell.org> Message-ID: <067.225e7af245901155776fe2552f2c4977@haskell.org> #10301: Plugins/dynamic loading subtly broken (it seems) -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | plugins/T10294 plugins/frontend01 Blocked By: | Blocking: Related Tickets: #8276 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 23:27:52 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 23:27:52 -0000 Subject: [GHC] #12982: Missed constant folding oportunities In-Reply-To: <044.d9771cbd0fd576f4750f411f0acf4ba6@haskell.org> References: <044.d9771cbd0fd576f4750f411f0acf4ba6@haskell.org> Message-ID: <059.3dd99b99b3cc784f99937d749d2f2817@haskell.org> #12982: Missed constant folding oportunities -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: libraries/hoopl | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sio): > Would anyone like to fix that? (Need to be careful to preserve overflow behaviour.) I'd like to take a crack at this. It'll be my first change, so will take me a while to get familiar with the codebase; will update when I've made some progress. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 23:38:44 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 23:38:44 -0000 Subject: [GHC] #12988: Join points Message-ID: <049.06fbe13653f56f55b1f6ffcfbfa59936@haskell.org> #12988: Join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: lukemaurer Type: feature | Status: new request | Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): D2853 | Wiki Page: SequentCore -------------------------------------+------------------------------------- Master ticket for the `wip/join-points` branch. For details, see SequentCore. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 23:40:20 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 23:40:20 -0000 Subject: [GHC] #12988: Join points In-Reply-To: <049.06fbe13653f56f55b1f6ffcfbfa59936@haskell.org> References: <049.06fbe13653f56f55b1f6ffcfbfa59936@haskell.org> Message-ID: <064.96dcf9524472bfb12d4ad8049ddfffc2@haskell.org> #12988: Join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: lukemaurer Type: feature request | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D2853 Wiki Page: SequentCore | -------------------------------------+------------------------------------- Changes (by lukemaurer): * status: new => patch * keywords: => JoinPoints -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 23:46:18 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 23:46:18 -0000 Subject: [GHC] #9601: Make the rewrite rule system more powerful In-Reply-To: <050.d0198153d3c3c67b578255419aefe8e8@haskell.org> References: <050.d0198153d3c3c67b578255419aefe8e8@haskell.org> Message-ID: <065.c9b9dc5d22a816b9a00a2c8c1324ff93@haskell.org> #9601: Make the rewrite rule system more powerful -------------------------------------+------------------------------------- Reporter: spacekitteh | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9137, #10804 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): I don't know much about `RULES`, let me highlight this idea from ticket:9136#comment:1 (that lead to #9137): {{{ forall x y z. (IsLiteral y, IsLiteral z) => (x +# y) -# z = x +# (y -# z) forall x y z. (IsLiteral y, IsLiteral z) => (x -# y) -# z = x -# (y +# z) ... }}} This strikes my fancy! It's like a type class (predicate) for syntax * Could `IsLiteral` be given a kind? * Which constraint can be made available? (`IsEven`, `IsOdd`, ...) * Which properties can the compiler make use of? * Which properties can the optimizer make use of? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 23:50:18 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 23:50:18 -0000 Subject: [GHC] #9137: A way to match RULES only for literals In-Reply-To: <046.beaebd120563c793d8d6d0e627d6471a@haskell.org> References: <046.beaebd120563c793d8d6d0e627d6471a@haskell.org> Message-ID: <061.77fcb17052f0bd6057c11f716b41ac79@haskell.org> #9137: A way to match RULES only for literals -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 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 Iceland_jack): * cc: Iceland_jack (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 23:52:10 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 23:52:10 -0000 Subject: [GHC] #229: Integer overflow in array allocation In-Reply-To: <045.791e3ea8f042e6c7d57ae4cd25dec693@haskell.org> References: <045.791e3ea8f042e6c7d57ae4cd25dec693@haskell.org> Message-ID: <060.8d8c1319c001dd104dab7cc5d66485c5@haskell.org> #229: Integer overflow in array allocation -------------------------------------+------------------------------------- Reporter: josefs | Owner: bgamari Type: bug | Status: patch Priority: high | Milestone: 8.2.1 Component: Core Libraries | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"cd4b202f24da928adf66c05443b457002ab6a3e1/ghc" cd4b202/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="cd4b202f24da928adf66c05443b457002ab6a3e1" array: Check for integer overflow during allocation This fixes #229, where creating a new array can cause array to allocate a smaller array than it thinks it allocates due to integer overflow, resulting in memory unsafety. This breaks the rts/overflow1 test, which relied on this unchecked overflow. I fix it by reimplementing the test in terms of newByteArray# directly. Updates the array submodule. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 15 23:56:38 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Dec 2016 23:56:38 -0000 Subject: [GHC] #229: Integer overflow in array allocation In-Reply-To: <045.791e3ea8f042e6c7d57ae4cd25dec693@haskell.org> References: <045.791e3ea8f042e6c7d57ae4cd25dec693@haskell.org> Message-ID: <060.1b9d65c62334d9cfcfc9b5534b7ceb83@haskell.org> #229: Integer overflow in array allocation -------------------------------------+------------------------------------- Reporter: josefs | Owner: bgamari Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Core Libraries | Version: 7.9 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: After 13 years we can at long last close this chapter. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 16 00:10:06 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Dec 2016 00:10:06 -0000 Subject: [GHC] #12985: GHCi incorrectly reports the kind of unboxed tuples spliced in from Template Haskell In-Reply-To: <050.ad0392c4ae751e995d3259a41b13bc35@haskell.org> References: <050.ad0392c4ae751e995d3259a41b13bc35@haskell.org> Message-ID: <065.22fef3c416ada82c927b9ee1d75edb97@haskell.org> #12985: GHCi incorrectly reports the kind of unboxed tuples spliced in from Template Haskell -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #12976 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: facundo.dominguez (added) Comment: This regression was introduced by http://git.haskell.org/ghc.git/commit/8d63419478074728eb03082787ea51d498b3e62e (#11832). Facundo, do you know what might be going on here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 16 00:17:13 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Dec 2016 00:17:13 -0000 Subject: [GHC] #11195: New pattern-match check can be non-performant In-Reply-To: <047.3d302be30292bcd5d6fb3a65b1c2a01c@haskell.org> References: <047.3d302be30292bcd5d6fb3a65b1c2a01c@haskell.org> Message-ID: <062.5bf1f985ea1478fe6a6766018e01f1d0@haskell.org> #11195: New pattern-match check can be non-performant -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1676, Wiki Page: | Phab:D1795 -------------------------------------+------------------------------------- Comment (by bgamari): simonpj, are you referring to the compilation of `OptCoercion` again? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 16 00:20:31 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Dec 2016 00:20:31 -0000 Subject: [GHC] #5775: Inconsistency in demand analysis In-Reply-To: <041.59a17f321cd8e5e5a5552bb1b43821e2@haskell.org> References: <041.59a17f321cd8e5e5a5552bb1b43821e2@haskell.org> Message-ID: <056.0646b6bcb7816b75b149206a07454bbd@haskell.org> #5775: Inconsistency in demand analysis -------------------------------------+------------------------------------- Reporter: rl | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.5 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): * owner: bgamari => Comment: I will not have time to look further into this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 16 00:21:28 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Dec 2016 00:21:28 -0000 Subject: [GHC] #8095: TypeFamilies painfully slow In-Reply-To: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> References: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> Message-ID: <065.d9b47b08e27cd1c58e84ef53fa7360b1@haskell.org> #8095: TypeFamilies painfully slow -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5321, #11598, | Differential Rev(s): #12506 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: => goldfire Comment: Assigning to Richard. Feel free to unassign if you don't think you will get to this, Richard. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 16 00:22:58 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Dec 2016 00:22:58 -0000 Subject: [GHC] #9198: large performance regression in type checker speed in 7.8 In-Reply-To: <045.f5a457d59b89d5fb7ca7aaa1ff3c4984@haskell.org> References: <045.f5a457d59b89d5fb7ca7aaa1ff3c4984@haskell.org> Message-ID: <060.9e705961bfa3787d81143d6045323aa6@haskell.org> #9198: large performance regression in type checker speed in 7.8 -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (Type | Version: 7.8.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.4.1 Comment: There is no solution on the horizon for this. Bumping to 8.4 at the earliest. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 16 00:23:56 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Dec 2016 00:23:56 -0000 Subject: [GHC] #10892: ApplicativeDo should use *> and <* In-Reply-To: <047.75544cc852e1b71af89f5571354ace9a@haskell.org> References: <047.75544cc852e1b71af89f5571354ace9a@haskell.org> Message-ID: <062.c12a223af6c849fa2464e7a8cf332173@haskell.org> #10892: ApplicativeDo should use *> and <* -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: task | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 12143 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.4.1 Comment: It doesn't sound like this will happen for 8.2. However, feel free to step up if you, the motivated reader, would like to see this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 16 00:24:55 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Dec 2016 00:24:55 -0000 Subject: [GHC] #12662: Investigate ListSetOps module In-Reply-To: <049.ac2eeedbba5d3645ca691cea26396eab@haskell.org> References: <049.ac2eeedbba5d3645ca691cea26396eab@haskell.org> Message-ID: <064.9c6a1d1d37b3bd3ff3fc1c0007e1cffc@haskell.org> #12662: Investigate ListSetOps module -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Pacak reports that he has 352760 "Over-long notElem in unionLists" messages for 500 modules -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 16 00:27:36 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Dec 2016 00:27:36 -0000 Subject: [GHC] #8228: GHC built under Windows does not generate dyn_hi files In-Reply-To: <045.75cbd05b617b871cecfcf573b0b5b3b2@haskell.org> References: <045.75cbd05b617b871cecfcf573b0b5b3b2@haskell.org> Message-ID: <060.bf32e18a167dbdd36f04252b465e4947@haskell.org> #8228: GHC built under Windows does not generate dyn_hi files -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: GHC doesn't work | Unknown/Multiple at all | Test Case: cabal01 Blocked By: | Blocking: 6107 Related Tickets: #7134 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: Phyx- (added) * owner: thoughtpolice => Comment: Unassigning. Phyx, have you seen this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 16 00:30:35 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Dec 2016 00:30:35 -0000 Subject: [GHC] #12662: Investigate ListSetOps module In-Reply-To: <049.ac2eeedbba5d3645ca691cea26396eab@haskell.org> References: <049.ac2eeedbba5d3645ca691cea26396eab@haskell.org> Message-ID: <064.1f395b61423211feeb2ababfc7a29c32@haskell.org> #12662: Investigate ListSetOps module -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Here are the examples from his log: {{{ Feedback NewAboutYoursAPIHelp 4.1 KB, Plain text Soft wrap Raw text Duplicate 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 [directory-1.2.6.2, filepath-1.4.1.0, resourcet-1.1.7.5, foreign-var-0.1, iteratee-compress-0.3.4, lzma-0.0.0, mmorph-1.0.6, pipes-4.2.0, pipes-safe-2.2.4, relstuff-iteratee-0.2.4, Chart-1.8, ListLike-4.5, MemoTrie-0.6.4, StateVar-1.1.0.4, adjunctions-4.3, aeson-0.11.2.0, attoparsec-0.13.0.2, base-orphans-0.5.4, base64-bytestring-1.0.0.1, bifunctors-5.4.1, blaze-builder-0.4.0.2, bytes-0.15.2, case-insensitive-1.2.0.7, cereal-0.5.3.0, colour-2.3.3, comonad-5, contravariant-1.4, cookie-0.4.2.1, data-default-class-0.1.2.0, distributive-0.5.0.2, dlist-0.8, enummapset-th-0.6.1.0, exceptions-0.8.3, fmlist-0.9, free-4.12.4, hashable-1.2.4.0, hmatrix-0.18.0.0, hsc-extras-0.1.0.0, http-client-0.5.1, http-types-0.9.1, influxdb-0.10.0, iteratee-0.8.4.6, kan-extensions-5.0.1, kickchan-0.1.0.4, lens-4.14, lifted-base-0.2.3.8, linear-1.20.5, monad-control-1.0.1.0, mtl-2.2.1, network-2.6.2.1, network-uri-2.6.1.0, old-locale-1.0.0.7, operational-0.2.3.2, parallel-3.2.1.0, parsec-3.1.11, piecewise-polynomial-0.0.0.2, prelude-extras-0.4.0.3, profunctors-5.2, reflection-2.1.2, retry-0.7.4.1, scientific-0.3.4.9, semigroupoids-5.1, simconf-0.23.1.1, snappy-0.2.0.2, split-0.2.3.1, sqroll-0.0.0.6, stm-2.4.4.1, streaming-commons-0.1.15.5, tagged-0.8.5, thyme-0.3.5.5, transformers-base-0.4.4, transformers-compat-0.5.1.4, unix-2.7.2.0, unordered-containers-0.2.7.1, utf8-string-1.0.1.1, vector-space-0.10.3, vector-th-unbox-0.2.1.6, zlib-0.6.1.1, HUnit-1.3.1.1, QuickCheck-2.9.1, ansi-terminal-0.6.2.3, ansi-wl-pprint-0.6.7.3, beamable-0.2.0.0, binary-0.8.3.0, containers-0.5.7.1, ghc-boot-th-8.1, hostname-1.0, murmur-hash-0.1.0.9, pretty-1.1.3.3, primitive-0.6.1.0, random-1.1, regex-base-0.93.2, regex-posix-0.95.2, template-haskell-2.12.0.0, test-framework-0.8.1.1, test-framework-hunit-0.3.0.2, test-framework-quickcheck2-0.3.0.3, text-1.2.2.1, tf-random-0.5, time-1.6.0.1, transformers-0.5.2.0, vector-0.11.0.0, xml-1.3.14, hsyslog-4, array-0.5.1.1, base-4.9.0.0, bytestring-0.10.8.1, deepseq-1.4.2.0, ghc-prim-0.5.0.0, integer-gmp-1.0.0.1] [Journal.Types, Network.BeamServer.Internal, Data.MemoTrie, Data.Functor.Rep, Data.Attoparsec.Internal.Types, Data.Functor.Compose, Data.Functor.Product, Data.Functor.Sum, Data.Bifunctor.Biff, Data.Bifunctor.Clown, Data.Bifunctor.Flip, Data.Bifunctor.Join, Data.Bifunctor.Joker, Data.Bifunctor.Product, Data.Bifunctor.Sum, Data.Bifunctor.Tannen, Data.Bifunctor.Wrapped, Data.Bytes.Get, Data.Bytes.Signed, Data.Bytes.VarInt, Data.IntMap.Base, Data.IntSet.Base, Data.Map.Base, Data.Sequence, Data.Set.Base, Data.DList, GHC.LanguageExtensions.Type, Internal.Devel, Internal.Matrix, Internal.Modular, Internal.Numeric, Network.HTTP.Client, Database.InfluxDB.Types, Data.Functor.Day, Data.Functor.Yoneda, Control.Lens.At, Control.Lens.Internal.Indexed, Control.Lens.Reified, Control.Lens.Tuple, Control.Lens.Wrapped, Control.Lens.Zoom, Linear.V1, Linear.V2, Data.BeamableOrphans, Data.EnumMap.Lazy, Data.EnumMap.Strict, Prelude.Orphans, Control.Monad.Trans.Control, Network.URI, Numeric.Polynomial, Numeric.Polynomial.Log, Numeric.Polynomial.Piecewise, Text.PrettyPrint.Annotated.HughesPJ, Text.PrettyPrint.HughesPJ, Control.Monad.Primitive, Data.Profunctor.Rep, Control.Retry, Data.Tagged, Language.Haskell.TH.Syntax, Data.Text, Data.Text.Lazy, Data.Thyme.Calendar.Internal, Data.Thyme.Clock.Internal, Data.Thyme.Clock.TAI, Data.Thyme.Internal.Micro, Data.Thyme.LocalTime, Data.HashMap.Base, Data.HashSet, Data.Vector, Data.Vector.Primitive, Data.Vector.Storable, Data.Vector.Unboxed, Data.Vector.Unboxed.Base, Data.AffineSpace, Data.Basis, Data.VectorSpace, Codec.Compression.Zlib.Stream, System.Posix.Syslog, Control.Applicative, Data.Complex, Data.Either, Data.Functor.Const, Data.Functor.Identity, Data.List.NonEmpty, Data.Monoid, Data.Semigroup, Data.Type.Equality, Data.Version, Data.Void, GHC.Exts, GHC.Generics, GHC.IO.Exception, GHC.TypeLits] Pasted 36 minutes ago — Expires in 7 days }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 16 00:44:49 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Dec 2016 00:44:49 -0000 Subject: [GHC] #12989: ($) can have a more general type Message-ID: <045.48fb17a262faf4da952ae03116f5bd7c@haskell.org> #12989: ($) can have a more general type -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The documentation (in section 9.12.1 for GHC 8; I don't know what section it is in 8.2) suggests a hypothetical type for `($)`: {{{#!hs bad :: forall (r1 :: RuntimeRep) (r2 :: RuntimeRep) (a :: TYPE r1) (b :: TYPE r2). (a -> b) -> a -> b bad f x = f x }}} It explains, correctly, that this definition will not work because `x` has a representation-polymorphic type. However, this doesn't actually explain why `($)` doesn't have that type! Indeed, both GHC 8 and 8.2 accept the following: {{{#!hs good :: forall (r1 :: RuntimeRep) (r2 :: RuntimeRep) (a :: TYPE r1) (b :: TYPE r2). (a -> b) -> a -> b good f = f }}} This has very slightly different semantics, but anyone relying on the difference is already doing something they shouldn't. It may or may not be possible to retain the current semantics with some care and magic, if we so desire. I didn't really know how to characterize this ticket properly. It could be considered a documentation bug or a compiler feature request. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 16 00:53:03 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Dec 2016 00:53:03 -0000 Subject: [GHC] #11062: Type families + hs-boot files = panic (type family consistency check too early) In-Reply-To: <047.7c49c2177d004f32c0696dfdb91a7434@haskell.org> References: <047.7c49c2177d004f32c0696dfdb91a7434@haskell.org> Message-ID: <062.e8be3d27a34724eef4a0e4e7f679a174@haskell.org> #11062: Type families + hs-boot files = panic (type family consistency check too early) -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: patch Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: TypeFamilies | hs-boot Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2215 Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): There is a technical difficulty with (1): we need to be able to distinguish between imported families and families which we are going to define. Unfortunately, these families are all bundled together in a `FamInstEnv`, and the only indication if it's local or external is in the `Name` of the `CoAxiom`, but we're not allowed to actually poke the `CoAxiom` to get this `Name` (since that will force the thunk.) So we need to carry along the `Name` of the `FamInstEnv`, or separate out local/external while we're typechecking the interface. The latter sounds less intrusive; we'll just end up with two FamInstEnvs in this case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 16 00:54:50 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Dec 2016 00:54:50 -0000 Subject: [GHC] #11243: Flag to not expand type families In-Reply-To: <047.01f55ca519ccdb3f0aca6a921b90d83a@haskell.org> References: <047.01f55ca519ccdb3f0aca6a921b90d83a@haskell.org> Message-ID: <062.e9387ea99457d86af805b4d4b6c3b422@haskell.org> #11243: Flag to not expand type families -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.4.1 Comment: It doesn't look like this will happen for 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 16 00:56:14 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Dec 2016 00:56:14 -0000 Subject: [GHC] #12944: ghc master (8.1.20161206) panics with assertion failure with devel2 flavor and -O In-Reply-To: <044.3fe8817d41680dd8c67e674ebd7c6a0f@haskell.org> References: <044.3fe8817d41680dd8c67e674ebd7c6a0f@haskell.org> Message-ID: <059.a057741a1126f86ee23e9ecb9764eb42@haskell.org> #12944: ghc master (8.1.20161206) panics with assertion failure with devel2 flavor and -O -------------------------------------+------------------------------------- Reporter: pacak | Owner: Type: bug | Status: patch Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2844 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"0d213c18b6962bb65e2b3035a258dd3f5bf454dd/ghc" 0d213c1/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0d213c18b6962bb65e2b3035a258dd3f5bf454dd" UniqSupply: Use full range of machine word Currently uniques are 32-bits wide. 8 of these bits are for the unique class, leaving only 24 for the unique number itself. This seems dangerously small for a large project. Let's use the full range of the native machine word. We also add (now largely unnecessary) overflow check to ensure that the unique number doesn't overflow. Test Plan: Validate Reviewers: simonmar, austin, niteria Reviewed By: niteria Subscribers: mpickering, thomie Differential Revision: https://phabricator.haskell.org/D2844 GHC Trac Issues: #12944 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 16 00:56:14 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Dec 2016 00:56:14 -0000 Subject: [GHC] #12795: Add more types to System.Posix.Types In-Reply-To: <046.4fbe8aafe0a055922e787b103a5411d6@haskell.org> References: <046.4fbe8aafe0a055922e787b103a5411d6@haskell.org> Message-ID: <061.8360ae5804b80d7451e22c1003b745ab@haskell.org> #12795: Add more types to System.Posix.Types -------------------------------------+------------------------------------- Reporter: DanielG | Owner: DanielG Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2664 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"ffc2327070dbb664bdb407a804121eacb2a7c734/ghc" ffc23270/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ffc2327070dbb664bdb407a804121eacb2a7c734" base: Add more POSIX types (fixes #12795) Test Plan: validate Reviewers: hvr, austin, RyanGlScott, bgamari Reviewed By: RyanGlScott, bgamari Subscribers: RyanGlScott, thomie, erikd Differential Revision: https://phabricator.haskell.org/D2664 GHC Trac Issues: #12795 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 16 00:57:32 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Dec 2016 00:57:32 -0000 Subject: [GHC] #12795: Add more types to System.Posix.Types In-Reply-To: <046.4fbe8aafe0a055922e787b103a5411d6@haskell.org> References: <046.4fbe8aafe0a055922e787b103a5411d6@haskell.org> Message-ID: <061.a3779920ef9d8343658ee429ec9e63c7@haskell.org> #12795: Add more types to System.Posix.Types -------------------------------------+------------------------------------- Reporter: DanielG | Owner: DanielG Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: libraries/base | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2664 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.2.1 Comment: Thanks DanielG! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 16 00:57:47 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Dec 2016 00:57:47 -0000 Subject: [GHC] #12989: ($) can have a more general type In-Reply-To: <045.48fb17a262faf4da952ae03116f5bd7c@haskell.org> References: <045.48fb17a262faf4da952ae03116f5bd7c@haskell.org> Message-ID: <060.7993b0ec6f4b8ac7025057ad6fd87af5@haskell.org> #12989: ($) can have a more general type -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): I think most likely there ''isn't'' any way to change the arity magically, so if we want to change the type, we probably have to accept the (small) semantic change. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 16 00:58:02 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Dec 2016 00:58:02 -0000 Subject: [GHC] #12944: ghc master (8.1.20161206) panics with assertion failure with devel2 flavor and -O In-Reply-To: <044.3fe8817d41680dd8c67e674ebd7c6a0f@haskell.org> References: <044.3fe8817d41680dd8c67e674ebd7c6a0f@haskell.org> Message-ID: <059.bd911b5c1967a9da6d6fb7bdb046e0e1@haskell.org> #12944: ghc master (8.1.20161206) panics with assertion failure with devel2 flavor and -O -------------------------------------+------------------------------------- Reporter: pacak | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 (CodeGen) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2844 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: According to pacak the fix in comment:7 has fixed the issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 16 00:58:46 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Dec 2016 00:58:46 -0000 Subject: [GHC] #11149: Unify fixity/associativity of <>-ish pretty-printing operators In-Reply-To: <042.a660c98bcc278791754b9d72890aec37@haskell.org> References: <042.a660c98bcc278791754b9d72890aec37@haskell.org> Message-ID: <057.2d0bbee5dd922f1e5f2ef93567cd574c@haskell.org> #11149: Unify fixity/associativity of <>-ish pretty-printing operators -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.4.1 Comment: This won't happen for 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 16 00:59:24 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Dec 2016 00:59:24 -0000 Subject: [GHC] #12989: ($) can have a more general type In-Reply-To: <045.48fb17a262faf4da952ae03116f5bd7c@haskell.org> References: <045.48fb17a262faf4da952ae03116f5bd7c@haskell.org> Message-ID: <060.f14369ea1ffc1f20d64f02b092c83bef@haskell.org> #12989: ($) can have a more general type -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): I don't know whether this would be kosher, but one possibility would be to skip the kind check on `arg1_ty` in the type checker special case for `arg1 $ arg2` and then rewrite the expression into {{{arg1 `good` arg2}}}. (Or for that matter, into a direct application `arg1 arg2`.) That would never change semantics because it only applies to a saturated application of `($)` in the first place. You still wouldn't be able to use `($)` with unboxed argument type in a higher-order context, but at least you would be able to write things like `I# $ x# +# y +# z#`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 16 00:59:37 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Dec 2016 00:59:37 -0000 Subject: [GHC] #11238: Redesign the dynamic linking on ELF systems In-Reply-To: <047.b64204058d590ba33e44f36f6140b2e6@haskell.org> References: <047.b64204058d590ba33e44f36f6140b2e6@haskell.org> Message-ID: <062.c256dcf1816b0bd8d20443024720e917@haskell.org> #11238: Redesign the dynamic linking on ELF systems -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Runtime System | Version: 7.10.3 (Linker) | Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: 9237, 9498, | 11042, 11499, 12684 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.4.1 Comment: I suspect this won't happen for 8.2 but feel free to re-milestone if I'm mistake. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 16 01:00:10 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Dec 2016 01:00:10 -0000 Subject: [GHC] #11262: Test print022: wrong stdout on powerpc64 In-Reply-To: <047.0409b41ca7e7566752abaefb0ae702eb@haskell.org> References: <047.0409b41ca7e7566752abaefb0ae702eb@haskell.org> Message-ID: <062.ccc9cee8ab80be6c04cd25a9e2fe13bc@haskell.org> #11262: Test print022: wrong stdout on powerpc64 -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: GHCi | Version: 7.11 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc64 Type of failure: Incorrect result | Test Case: print022 at runtime | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.4.1 Comment: This likely won't get fixed for GHC 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 16 01:03:36 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Dec 2016 01:03:36 -0000 Subject: [GHC] #11457: Run type-checker plugins before GHC's solver In-Reply-To: <049.a8fb4e5f5bcb03aebd9c2ea03a73390b@haskell.org> References: <049.a8fb4e5f5bcb03aebd9c2ea03a73390b@haskell.org> Message-ID: <064.251d2ee8f41202034d75cfc1f2deab3b@haskell.org> #11457: Run type-checker plugins before GHC's solver -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: plugin Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: angerman (added) * milestone: 8.2.1 => 8.4.1 Comment: This won't happen for 8.2. Angerman, you might be interested in this considering your recent reflections on plugins. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 16 01:05:48 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Dec 2016 01:05:48 -0000 Subject: [GHC] #11714: Kind of (->) type constructor is overly constrained In-Reply-To: <046.1c872034bd46f91c4f4aa91d607a8219@haskell.org> References: <046.1c872034bd46f91c4f4aa91d607a8219@haskell.org> Message-ID: <061.cbd6206f8e46d8c2ffa8d116a90db010@haskell.org> #11714: Kind of (->) type constructor is overly constrained -------------------------------------+------------------------------------- Reporter: bgamari | Owner: goldfire Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Typeable, | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: => goldfire Comment: Simon has said that Richard will be picking this up. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 16 01:08:58 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Dec 2016 01:08:58 -0000 Subject: [GHC] #8299: Add richer data model address arithmetic: AddrDiff and AddrInt (ie d Int_ptr_diff and Int_ptr_size) In-Reply-To: <045.f91b5080e44be46bd4f6c2cd9b6ce680@haskell.org> References: <045.f91b5080e44be46bd4f6c2cd9b6ce680@haskell.org> Message-ID: <060.26d1c5c797e903ceeb680a546c8efe1f@haskell.org> #8299: Add richer data model address arithmetic: AddrDiff and AddrInt (ie d Int_ptr_diff and Int_ptr_size) -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 8287 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => Comment: Un-milestoning due to lack of progress. Feel free to pick it up though! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 16 01:09:56 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Dec 2016 01:09:56 -0000 Subject: [GHC] #10972: Add a :binfo (beginner info) GHCi command In-Reply-To: <045.69c25027f6e9192e0896957840c11b0e@haskell.org> References: <045.69c25027f6e9192e0896957840c11b0e@haskell.org> Message-ID: <060.01f676a8de5f35af9e38c1bcb8c93bfc@haskell.org> #10972: Add a :binfo (beginner info) GHCi command -------------------------------------+------------------------------------- Reporter: kanetw | Owner: kanetw Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10963 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.4.1 Comment: This won't be happening for 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 16 01:31:28 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Dec 2016 01:31:28 -0000 Subject: [GHC] #12990: Partially applied constructors with unpacked fields simplified badly Message-ID: <045.525d0610bc9f5daed2ba04304bf44d04@haskell.org> #12990: Partially applied constructors with unpacked fields simplified badly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: -------------------------------------+------------------------------------- When a constructor is partially applied to at least one unpacked field, the simplifier produces pretty lousy results. {{{#!hs data Foo a = Foo !Int a silly :: ((a -> Foo a) -> r) -> r silly f = f (Foo 3) }}} compiles to {{{ -- RHS size: {terms: 9, types: 7, coercions: 0} $WFoo :: forall a. Int -> a -> Foo a $WFoo = \ (@ a_aqI) (dt_ayl :: Int) (dt_aym :: a_aqI[sk:1]) -> case dt_ayl of { I# dt_ayn -> Foo dt_ayn dt_aym } -- RHS size: {terms: 2, types: 0, coercions: 0} silly2 :: Int silly2 = I# 3# -- RHS size: {terms: 3, types: 3, coercions: 0} silly1 :: forall a. a -> Foo a silly1 = \ (@ a_ayG) -> $WFoo silly2 -- RHS size: {terms: 5, types: 9, coercions: 0} silly :: forall a r. ((a -> Foo a) -> r) -> r silly = \ (@ a_ayG) (@ r_ayH) (f_axY :: (a -> Foo a) -> r) -> f_axY silly1 }}} That is, GHC represents `Foo 3` as a closure containing a ''boxed'' `Int`. Manually eta-expanding would fix it. {{{#!hs silly :: ((a -> Foo a) -> r) -> r silly f = f (\x -> Foo 3 x) }}} compiles to {{{#!hs -- RHS size: {terms: 5, types: 4, coercions: 0} silly1 :: forall a. a -> Foo a silly1 = \ (@ a_ayO) (x_ay9 :: a) -> Foo 3# x_ay9 -- RHS size: {terms: 5, types: 9, coercions: 0} silly :: forall a r. ((a -> Foo a) -> r) -> r silly = \ (@ a_ayO) (@ r_ayP) (f_ay8 :: (a -> Foo a) -> r) -> f_ay8 silly1 }}} in which the `Int` is unpacked into the closure. This transformation is valid whenever the value to be stored unpacked is known not to be bottom, and is certainly a good idea if it's known to have been forced. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 16 01:34:48 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Dec 2016 01:34:48 -0000 Subject: [GHC] #12990: Partially applied constructors with unpacked fields simplified badly In-Reply-To: <045.525d0610bc9f5daed2ba04304bf44d04@haskell.org> References: <045.525d0610bc9f5daed2ba04304bf44d04@haskell.org> Message-ID: <060.7aa44e35c7f68178e325f1ac1fb5a784@haskell.org> #12990: Partially applied constructors with unpacked fields simplified badly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: | -------------------------------------+------------------------------------- Comment (by rwbarton): Inlining `$WFoo` into `silly1` and then beta-reducing would also fix it (case of known constructor). I think that GHC thinks the inlining will be fruitless here for some reason. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 16 01:39:51 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Dec 2016 01:39:51 -0000 Subject: [GHC] #12984: Missed constant folding oportunities (associativity) In-Reply-To: <045.0a42c32dd482b39428ca2268278e9f14@haskell.org> References: <045.0a42c32dd482b39428ca2268278e9f14@haskell.org> Message-ID: <060.33b0c9ecf6e3a1add2b45370ea0ae370@haskell.org> #12984: Missed constant folding oportunities (associativity) -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2858 Wiki Page: | -------------------------------------+------------------------------------- Changes (by hsyl20): * status: new => patch * differential: => Phab:D2858 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 16 01:40:10 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Dec 2016 01:40:10 -0000 Subject: [GHC] #12944: ghc master (8.1.20161206) panics with assertion failure with devel2 flavor and -O In-Reply-To: <044.3fe8817d41680dd8c67e674ebd7c6a0f@haskell.org> References: <044.3fe8817d41680dd8c67e674ebd7c6a0f@haskell.org> Message-ID: <059.8ef610327d2eef3498f1c31de295bfc8@haskell.org> #12944: ghc master (8.1.20161206) panics with assertion failure with devel2 flavor and -O -------------------------------------+------------------------------------- Reporter: pacak | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 (CodeGen) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2844 Wiki Page: | -------------------------------------+------------------------------------- Comment (by pacak): This ticket is _NOT_ related to unique identifier and it still fails with fix in place. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 16 01:42:17 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Dec 2016 01:42:17 -0000 Subject: [GHC] #12944: ghc master (8.1.20161206) panics with assertion failure with devel2 flavor and -O In-Reply-To: <044.3fe8817d41680dd8c67e674ebd7c6a0f@haskell.org> References: <044.3fe8817d41680dd8c67e674ebd7c6a0f@haskell.org> Message-ID: <059.dd283378827dd6d551b2accbd54b591d@haskell.org> #12944: ghc master (8.1.20161206) panics with assertion failure with devel2 flavor and -O -------------------------------------+------------------------------------- Reporter: pacak | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 (CodeGen) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2844 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Oh dear, yes, you are quite right. My apologies! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 16 01:43:58 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Dec 2016 01:43:58 -0000 Subject: [GHC] #12899: ghc panics at random places with -jX In-Reply-To: <044.e06c34ff950f64285fd655be98faab7e@haskell.org> References: <044.e06c34ff950f64285fd655be98faab7e@haskell.org> Message-ID: <059.401c8265aed0c11ad0261b430759a2ef@haskell.org> #12899: ghc panics at random places with -jX -------------------------------------+------------------------------------- Reporter: pacak | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2844 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * differential: => Phab:D2844 * resolution: => fixed * milestone: => 8.2.1 Comment: This was addressed by Phab:D2844, as mentioned by mpickering above. Unfortunately, I cited the wrong ticket in the commit description, so the commit message didn't make it here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 16 01:54:42 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Dec 2016 01:54:42 -0000 Subject: [GHC] #12990: Partially applied constructors with unpacked fields simplified badly In-Reply-To: <045.525d0610bc9f5daed2ba04304bf44d04@haskell.org> References: <045.525d0610bc9f5daed2ba04304bf44d04@haskell.org> Message-ID: <060.9afd1b52ff23781b1231f42b68711987@haskell.org> #12990: Partially applied constructors with unpacked fields simplified badly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: | -------------------------------------+------------------------------------- Comment (by dfeuer): Actually, I guess the eta-expansion per se is always safe (because a strict constructor can never have a weird arity), and will lead to case- of-known-constructor when relevant. I don't have any opinion whatsoever about exactly ''how'' this should be fixed; I just want it fixed. I've had to write some unpleasantly long-winded code in `containers` to work around this. It shows up all over `Traversable` things, for instance. {{{#!hs data Node = Node2 !Int a a | Node3 !Int a a a instance Traversable Node where traverse f (Node2 sz x y) = Node2 sz <$> traverse f x <*> traverse f y ... }}} is no good; GHC would box up the node size (which starts out unboxed!) just to put it in the closure passed to `fmap`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 16 02:12:47 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Dec 2016 02:12:47 -0000 Subject: [GHC] #11062: Type families + hs-boot files = panic (type family consistency check too early) In-Reply-To: <047.7c49c2177d004f32c0696dfdb91a7434@haskell.org> References: <047.7c49c2177d004f32c0696dfdb91a7434@haskell.org> Message-ID: <062.827010f58bdab2b92203f847f5b8ba7a@haskell.org> #11062: Type families + hs-boot files = panic (type family consistency check too early) -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: patch Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: TypeFamilies | hs-boot Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2859 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * differential: Phab:D2215 => Phab:D2859 Comment: OK, we've got a new patch! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 16 03:19:10 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Dec 2016 03:19:10 -0000 Subject: [GHC] #7325: threadDelay mistreats minBound and maxBound in some configurations In-Reply-To: <048.f6376e5e233d59dcc7fd251637dbe84b@haskell.org> References: <048.f6376e5e233d59dcc7fd251637dbe84b@haskell.org> Message-ID: <063.524c328ce692a08082728bbec45ece48@haskell.org> #7325: threadDelay mistreats minBound and maxBound in some configurations -------------------------------------+------------------------------------- Reporter: joeyadams | Owner: Type: bug | Status: patch Priority: high | Milestone: 8.2.1 Component: Runtime System | Version: 7.6.1 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Incorrect result | Test Case: at runtime | base/tests/T8089 Blocked By: | Blocking: Related Tickets: #9722 | Differential Rev(s): Phab:D2861 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D2861 Comment: `threadDelay minBound` no longer appears to block on Windows. However, `threadDelay maxBound` returns immediately. See Phab:D2861 for a fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 16 04:19:40 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Dec 2016 04:19:40 -0000 Subject: [GHC] #11784: panic "hscCmmFile: no_mod" with `-v2 and above In-Reply-To: <044.29a67b6904270a19ef7b34462d19062e@haskell.org> References: <044.29a67b6904270a19ef7b34462d19062e@haskell.org> Message-ID: <059.e477fac21b7b504737e2d509c6a20982@haskell.org> #11784: panic "hscCmmFile: no_mod" with `-v2 and above -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): The problem here is that `hscCompileCmmFile` needs a `Module` to give to `CodeOutput.codeOutput`. The downstream uses of this `Module` are, * `outputForeignStubs`: needs a string to form the stem of the stub filename * `PIC.howToAccessLabel`: calls `CLabel.labelDynamic`, which, * then wants to compare it against another `Module` taken from a `HpcTicksLabel` * and uses it to call `Packages.isDllName` Given that `PIC.howToAccessLabel` hasn't blowing up due to the bottoming `Module`s we give it for C-- files, I suppose it should be safe for `hscCompileCmmFile` to simply make up a module name to give to the backend. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 16 04:20:22 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Dec 2016 04:20:22 -0000 Subject: [GHC] #11784: panic "hscCmmFile: no_mod" with `-v2 and above In-Reply-To: <044.29a67b6904270a19ef7b34462d19062e@haskell.org> References: <044.29a67b6904270a19ef7b34462d19062e@haskell.org> Message-ID: <059.652c69c8a8115cb2f655876fe4bfb764@haskell.org> #11784: panic "hscCmmFile: no_mod" with `-v2 and above -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: patch Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2864 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D2864 Comment: Here's a patch that carries out the proposal in comment:3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 16 04:30:15 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Dec 2016 04:30:15 -0000 Subject: [GHC] #11736: Allow unsaturated uses of unlifted types in Core In-Reply-To: <046.58eb4ccf2c61eb23569b6021fe490e4a@haskell.org> References: <046.58eb4ccf2c61eb23569b6021fe490e4a@haskell.org> Message-ID: <061.85b54d36ad0195ac92fd1a81e2406087@haskell.org> #11736: Allow unsaturated uses of unlifted types in Core -------------------------------------+------------------------------------- Reporter: bgamari | Owner: goldfire Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Typeable, | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: => goldfire Comment: Richard, what is the current status of this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 16 04:30:41 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Dec 2016 04:30:41 -0000 Subject: [GHC] #11953: Export Word32#, Word64# on all architectures In-Reply-To: <046.593317f13858c2d1c5dc11a464cab3d1@haskell.org> References: <046.593317f13858c2d1c5dc11a464cab3d1@haskell.org> Message-ID: <061.f490110a9135cc97199bf63a8b8d47f5@haskell.org> #11953: Export Word32#, Word64# on all architectures -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.4.1 Comment: This won't happen for 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 16 04:34:11 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Dec 2016 04:34:11 -0000 Subject: [GHC] #11221: Remove -fwarn-context-quantification In-Reply-To: <046.3e0415fa600798191d12b77f31b5c35a@haskell.org> References: <046.3e0415fa600798191d12b77f31b5c35a@haskell.org> Message-ID: <061.946f1c7e1972f4eac6457e52524d43fd@haskell.org> #11221: Remove -fwarn-context-quantification -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2862 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D2862 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 16 07:16:22 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Dec 2016 07:16:22 -0000 Subject: [GHC] #12708: RFC: Representation polymorphic Num In-Reply-To: <051.e9ad721b0c060306ebd4bf7d4de38fdd@haskell.org> References: <051.e9ad721b0c060306ebd4bf7d4de38fdd@haskell.org> Message-ID: <066.086e4406ed16adee21ac1ef0d6fa8c0c@haskell.org> #12708: RFC: Representation polymorphic Num -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.1 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12980 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by oerjan): * related: 12980 => #12980 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 16 07:28:29 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Dec 2016 07:28:29 -0000 Subject: [GHC] #12980: Unlifted class method rejected In-Reply-To: <047.30d5cc1ce932625fb79015dfcdcefc56@haskell.org> References: <047.30d5cc1ce932625fb79015dfcdcefc56@haskell.org> Message-ID: <062.758891c6a6a822f4c5dee28a83077b5b@haskell.org> #12980: Unlifted class method rejected -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by oerjan): * cc: oerjan (added) Comment: Replying to [comment:1 simonpj]: > Certainly should be ok for multi-method classes. I'm not quite sure about the single-method case, because of the interaction with newtypes -- but I think there's a case for using data types in the single-method case too. Alternatively, since fields cannot be levity-polymorphic (at least without extra indirection), you could restrict the newtype optimization to methods of kind `Type`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 16 07:53:28 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Dec 2016 07:53:28 -0000 Subject: [GHC] #12970: Add default implementation for Bits.bitSize In-Reply-To: <045.18bc248265b05555e123c1ad78e88bb9@haskell.org> References: <045.18bc248265b05555e123c1ad78e88bb9@haskell.org> Message-ID: <060.f7d68bf44f81c77785d719b8207cc9e6@haskell.org> #12970: Add default implementation for Bits.bitSize -------------------------------------+------------------------------------- Reporter: txnull | Owner: Type: feature request | Status: upstream Priority: normal | Milestone: Component: libraries/base | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): it may make sense to also consider a DefaultSignature-based default impl for `bitSizeMaybe` inheriting from `FiniteBits(finiteBitSize)` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 16 08:30:15 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Dec 2016 08:30:15 -0000 Subject: [GHC] #11195: New pattern-match check can be non-performant In-Reply-To: <047.3d302be30292bcd5d6fb3a65b1c2a01c@haskell.org> References: <047.3d302be30292bcd5d6fb3a65b1c2a01c@haskell.org> Message-ID: <062.e15d7bf33762db13aab5e20d461be146@haskell.org> #11195: New pattern-match check can be non-performant -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1676, Wiki Page: | Phab:D1795 -------------------------------------+------------------------------------- Comment (by simonpj): Replying to [comment:13 bgamari]: > simonpj, are you referring to the compilation of `OptCoercion` again? I think so. It was careless of me not to be more specific. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 16 08:43:50 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Dec 2016 08:43:50 -0000 Subject: [GHC] #5654: Profiling semantics bug In-Reply-To: <047.ac296d247951e42a341a674c3c07d355@haskell.org> References: <047.ac296d247951e42a341a674c3c07d355@haskell.org> Message-ID: <062.b57fc9c760dd1e645fbe8ac38d0f728d@haskell.org> #5654: Profiling semantics bug -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: low | Milestone: 8.2.1 Component: Profiling | Version: 7.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | profiling/should_run/scc004 Blocked By: | Blocking: Related Tickets: #10007 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * owner: simonmar => * status: closed => new * resolution: fixed => Comment: I uncovered a bug in the patch, triggered by using GHCi with profiling. Fix incoming. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 16 08:45:22 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Dec 2016 08:45:22 -0000 Subject: [GHC] #12899: ghc panics at random places with -jX In-Reply-To: <044.e06c34ff950f64285fd655be98faab7e@haskell.org> References: <044.e06c34ff950f64285fd655be98faab7e@haskell.org> Message-ID: <059.09d93bbec1efca11cc2d762810104f32@haskell.org> #12899: ghc panics at random places with -jX -------------------------------------+------------------------------------- Reporter: pacak | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2844 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Here's the commit message I believe: In [changeset:"0d213c18b6962bb65e2b3035a258dd3f5bf454dd/ghc" 0d213c1/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0d213c18b6962bb65e2b3035a258dd3f5bf454dd" UniqSupply: Use full range of machine word Currently uniques are 32-bits wide. 8 of these bits are for the unique class, leaving only 24 for the unique number itself. This seems dangerously small for a large project. Let's use the full range of the native machine word. We also add (now largely unnecessary) overflow check to ensure that the unique number doesn't overflow. Test Plan: Validate Reviewers: simonmar, austin, niteria Reviewed By: niteria Subscribers: mpickering, thomie Differential Revision: https://phabricator.haskell.org/D2844 GHC Trac Issues: #12944 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 16 11:14:15 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Dec 2016 11:14:15 -0000 Subject: [GHC] #12988: Join points In-Reply-To: <049.06fbe13653f56f55b1f6ffcfbfa59936@haskell.org> References: <049.06fbe13653f56f55b1f6ffcfbfa59936@haskell.org> Message-ID: <064.ccf92bd46b7c3c1db89f381c8237e9d7@haskell.org> #12988: Join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: lukemaurer Type: feature request | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2853 Wiki Page: SequentCore | -------------------------------------+------------------------------------- Changes (by trommler): * differential: D2853 => Phab:D2853 Comment: Fix Phabricator link. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 16 13:31:02 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Dec 2016 13:31:02 -0000 Subject: [GHC] #12986: Ignore case when parsing language pragmas In-Reply-To: <045.f0f51830416b41e6e2c00f8c5ae945a4@haskell.org> References: <045.f0f51830416b41e6e2c00f8c5ae945a4@haskell.org> Message-ID: <060.2d5038f8e8f53ba06081e784116757e2@haskell.org> #12986: Ignore case when parsing language pragmas -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): This user-facing feature looks like it should go through [https://github.com/ghc-proposals/ghc-proposals/ ghc-proposals] first. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 16 13:41:02 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Dec 2016 13:41:02 -0000 Subject: [GHC] #12939: ghc-8.0.1.20161117 did not install ghc.1 manpage In-Reply-To: <050.1a6f83d836fa085ef75b0067487924cd@haskell.org> References: <050.1a6f83d836fa085ef75b0067487924cd@haskell.org> Message-ID: <065.3404c99af80cf59e634fd0be9c932f21@haskell.org> #12939: ghc-8.0.1.20161117 did not install ghc.1 manpage ---------------------------------+---------------------------------------- Reporter: juhpetersen | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Build System | Version: 8.0.2-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by bgamari): * owner: => bgamari -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 16 13:56:26 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Dec 2016 13:56:26 -0000 Subject: [GHC] #12985: GHCi incorrectly reports the kind of unboxed tuples spliced in from Template Haskell In-Reply-To: <050.ad0392c4ae751e995d3259a41b13bc35@haskell.org> References: <050.ad0392c4ae751e995d3259a41b13bc35@haskell.org> Message-ID: <065.535f0aa5ea61c06f30ff0241fed5b459@haskell.org> #12985: GHCi incorrectly reports the kind of unboxed tuples spliced in from Template Haskell -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #12976 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Thanks for finding that commit. I looked through quickly and didn't see anything obvious, I'm afraid. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 16 14:02:11 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Dec 2016 14:02:11 -0000 Subject: [GHC] #11736: Allow unsaturated uses of unlifted types in Core In-Reply-To: <046.58eb4ccf2c61eb23569b6021fe490e4a@haskell.org> References: <046.58eb4ccf2c61eb23569b6021fe490e4a@haskell.org> Message-ID: <061.dd70c9ca1e3e3909bc0e79f0e17a8e27@haskell.org> #11736: Allow unsaturated uses of unlifted types in Core -------------------------------------+------------------------------------- Reporter: bgamari | Owner: goldfire Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Typeable, | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Phab:D2842 will make this possible. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 16 14:12:16 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Dec 2016 14:12:16 -0000 Subject: [GHC] #12503: Template Haskell regression: GHC erroneously thinks a type variable is also a kind In-Reply-To: <050.7c43a93904af70f2e967ba340b84127f@haskell.org> References: <050.7c43a93904af70f2e967ba340b84127f@haskell.org> Message-ID: <065.496bfe725f6acf6a5a2ff7c14fd01c97@haskell.org> #12503: Template Haskell regression: GHC erroneously thinks a type variable is also a kind -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Richard or Ryan, could one of you pick this up? I'm trying to find owners for all of the 8.2 tickets in high or highest state. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 16 14:56:15 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Dec 2016 14:56:15 -0000 Subject: [GHC] #12991: panic when using IrredPreds in a type checker plugin. Message-ID: <043.3217b821d2aaafeace19f4825d72c2ca@haskell.org> #12991: panic when using IrredPreds in a type checker plugin. -------------------------------------+------------------------------------- Reporter: owen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'm working on a type checker plugin that solves constraints expressed with an empty, closed type family of kind Constraint. These show up in the plugin as wanted IrredPred constraints. Unfortunately, something seems to go sideways sometimes when I give solved or unsolvable IrredPreds back to GHC. I've managed to reproduce the error in a minimal-ish plugin. It doesn't try to solve anything, it just returns all the IrredPred constraints back to GHC in a TcPluginContradiction. When compiling a test case that uses the type family in a constraint, it gives the following output: {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-apple-darwin): StgCmmEnv: variable not found $dMonad_a5fm local binds for: $trModule $trModule1_r5qI $trModule2_r5rc }}} If I omit the IrredPreds and return an empty TcPluginContradiction, I get 'Could not deduce...' errors as I would expect. Strangley, the panic also goes away if I give an explicit type signature to main in the test case. I'm attaching an archive with 3 files. Plugin.hs has the plugin itself. Compare.hs has the closed type family. The test case that exercises the panic is in Fails.hs. Running {{{ ghc -shared -dynamic --make Test/*.hs -package ghc-8.0.1 }}} in the unpacked directory should reproduce the panic. Adding -dcore-lint does give some potentially useful information: {{{ [3 of 3] Compiling Test.Fails ( Test/Fails.hs, Test/Fails.o ) irred compare [W] irred_a5qq :: l_a5fo[tau:3] ≽ l'_a5fp[tau:3] (CNonCanonical) irred compare [W] irred_a5qr :: l'_a5fp[tau:3] ≽ l_a5fo[tau:3] (CNonCanonical) : warning: In the expression: return @ m_a5fl $dMonad_a5fm @ () $dMonad_a5fm :: Monad m_a5fl[tau:3] [LclId, Str=DmdType] is out of scope : warning: In the expression: (irred_a5qq, irred_a5qr) irred_a5qq :: s_a5ql[fuv:2] [LclId, Str=DmdType] is out of scope : warning: In the expression: (irred_a5qq, irred_a5qr) Argument value doesn't match argument type: Fun type: (Integer ≽ Integer, Integer ≽ Integer) => (Integer ≽ Integer, Integer ≽ Integer) Arg type: s_a5ql[fuv:2] Arg: irred_a5qq *** Offending Program *** $trModule :: Module [LclIdX, Str=DmdType] $trModule = Module (TrNameS "main"#) (TrNameS "Test.Fails"#) oops :: forall l_a572 l'_a573. (l_a572 === l'_a573) => l_a572 -> l'_a573 -> () [LclIdX, Str=DmdType] oops = \ (@ l_a5eW) (@ l'_a5eX) _ [Occ=Dead] _ [Occ=Dead] _ [Occ=Dead] -> () main :: forall (m_a5fl :: * -> *). m_a5fl () [LclIdX, Str=DmdType] main = \ (@ (m_a5fl :: * -> *)) -> $ @ 'PtrRepLifted @ () @ (m_a5fl ()) (return @ m_a5fl $dMonad_a5fm @ ()) (oops @ Integer @ Integer (irred_a5qq, irred_a5qr) 1 0) *** End of Offense *** : error: Compilation had errors }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 16 14:58:12 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Dec 2016 14:58:12 -0000 Subject: [GHC] #12991: panic when using IrredPreds in a type checker plugin. In-Reply-To: <043.3217b821d2aaafeace19f4825d72c2ca@haskell.org> References: <043.3217b821d2aaafeace19f4825d72c2ca@haskell.org> Message-ID: <058.3d6c0da2651cafd4239ff6137bb83471@haskell.org> #12991: panic when using IrredPreds in a type checker plugin. -------------------------------------+------------------------------------- Reporter: owen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by owen): * Attachment "ghc-plugin-test.tgz" added. tcplugin and test case -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 16 16:19:38 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Dec 2016 16:19:38 -0000 Subject: [GHC] #12992: Language.Haskell.TH doesn't reexport everything from Language.Haskell.TH.Lib Message-ID: <050.b358fe16eb179e6d620e897e9ac1be92@haskell.org> #12992: Language.Haskell.TH doesn't reexport everything from Language.Haskell.TH.Lib -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Template | Version: 8.0.1 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The documentation for `Language.Haskell.TH.Lib` [http://git.haskell.org/ghc.git/blob/9e862765ffe161da8a4fd9cd67b0a600874feaa9:/libraries /template-haskell/Language/Haskell/TH/Lib.hs#l8 claims]: {{{#!hs -- All of the exports from this module should -- be "public" functions. The main module TH -- re-exports them all. }}} Sadly, this isn't true. There are a number of functions that `Language.Haskell.TH` accidentally forgets to export. Notably, this includes all of the unboxed tuple library functions, as noticed [https://phabricator.haskell.org/D2448#inline-20282 here], but there are many others as well. To avoid this sort of thing in the future, I think the cleanest solution would be to just reexport the entirely of the `Language.Haskell.TH.Lib` module from `Language.Haskell.TH`. This would have the downside that you'll have to click an extra link in order to see the Haddocks for `Language.Haskell.TH.Lib`, but I believe the simplification will be worth it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 16 16:22:51 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Dec 2016 16:22:51 -0000 Subject: [GHC] #12992: Language.Haskell.TH doesn't reexport everything from Language.Haskell.TH.Lib In-Reply-To: <050.b358fe16eb179e6d620e897e9ac1be92@haskell.org> References: <050.b358fe16eb179e6d620e897e9ac1be92@haskell.org> Message-ID: <065.9f90b0ec399f22e5a259277e78d41991@haskell.org> #12992: Language.Haskell.TH doesn't reexport everything from Language.Haskell.TH.Lib -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2867 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D2867 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 16 16:29:41 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Dec 2016 16:29:41 -0000 Subject: [GHC] #12564: Type family in type pattern kind In-Reply-To: <048.93ccdd84c715d6e667e14d904b8a963f@haskell.org> References: <048.93ccdd84c715d6e667e14d904b8a963f@haskell.org> Message-ID: <063.77f08ddeb4da5a0710edfbffd894ade6@haskell.org> #12564: Type family in type pattern kind -------------------------------------+------------------------------------- Reporter: int-index | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: TypeInType, Resolution: | TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Richard, do you think this will happen for 8.2? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 16 17:11:27 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Dec 2016 17:11:27 -0000 Subject: [GHC] #11221: Remove -fwarn-context-quantification In-Reply-To: <046.3e0415fa600798191d12b77f31b5c35a@haskell.org> References: <046.3e0415fa600798191d12b77f31b5c35a@haskell.org> Message-ID: <061.8d5d79a03302c3866d5290472431b1ae@haskell.org> #11221: Remove -fwarn-context-quantification -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2862 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"13c1fc4dfc925afa328a6be9db191b11bf96d4a0/ghc" 13c1fc4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="13c1fc4dfc925afa328a6be9db191b11bf96d4a0" DynFlags: Rip out remnants of WarnContextQuantification Test Plan: Validate Reviewers: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2862 GHC Trac Issues: #11221 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 16 17:11:27 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Dec 2016 17:11:27 -0000 Subject: [GHC] #11784: panic "hscCmmFile: no_mod" with `-v2 and above In-Reply-To: <044.29a67b6904270a19ef7b34462d19062e@haskell.org> References: <044.29a67b6904270a19ef7b34462d19062e@haskell.org> Message-ID: <059.c6245f0c2371f25879d77e31c6d73caa@haskell.org> #11784: panic "hscCmmFile: no_mod" with `-v2 and above -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: patch Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2864 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"222e99d9e6b24c17a67c07d24d05999701b83e96/ghc" 222e99d9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="222e99d9e6b24c17a67c07d24d05999701b83e96" Make up a module name for c-- files Summary: We used to pass a bottoming Module to the NCG, which resulted in panics when `-v` was used due to debug output (see #11784). Instead we make up a module name. This is a bit scary since `PIC.howToAccessLabel` might actually use the Module, but if it wasn't crashing before I suppose it's fine. Test Plan: `touch hi.cmm; ghc -v2 -c -dcmm-lint hi.cmm` Reviewers: austin, simonmar Reviewed By: simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2864 GHC Trac Issues: #11784 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 16 17:13:16 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Dec 2016 17:13:16 -0000 Subject: [GHC] #11221: Remove -fwarn-context-quantification In-Reply-To: <046.3e0415fa600798191d12b77f31b5c35a@haskell.org> References: <046.3e0415fa600798191d12b77f31b5c35a@haskell.org> Message-ID: <061.a89135dcf6bdbaf7a0ae0e0cbf5a3940@haskell.org> #11221: Remove -fwarn-context-quantification -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2862 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: This has been done. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 16 17:13:52 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Dec 2016 17:13:52 -0000 Subject: [GHC] #11784: panic "hscCmmFile: no_mod" with `-v2 and above In-Reply-To: <044.29a67b6904270a19ef7b34462d19062e@haskell.org> References: <044.29a67b6904270a19ef7b34462d19062e@haskell.org> Message-ID: <059.7634527e76cabae0be7b3dfd83e28a31@haskell.org> #11784: panic "hscCmmFile: no_mod" with `-v2 and above -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2864 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: Done! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 16 17:23:28 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Dec 2016 17:23:28 -0000 Subject: [GHC] #12503: Template Haskell regression: GHC erroneously thinks a type variable is also a kind In-Reply-To: <050.7c43a93904af70f2e967ba340b84127f@haskell.org> References: <050.7c43a93904af70f2e967ba340b84127f@haskell.org> Message-ID: <065.ca751cf6f951bd9fd39e1d35f9a0798d@haskell.org> #12503: Template Haskell regression: GHC erroneously thinks a type variable is also a kind -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * owner: => goldfire -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 16 17:27:22 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Dec 2016 17:27:22 -0000 Subject: [GHC] #12944: ghc master (8.1.20161206) panics with assertion failure with devel2 flavor and -O In-Reply-To: <044.3fe8817d41680dd8c67e674ebd7c6a0f@haskell.org> References: <044.3fe8817d41680dd8c67e674ebd7c6a0f@haskell.org> Message-ID: <059.13db4f78954e27502935193774505c42@haskell.org> #12944: ghc master (8.1.20161206) panics with assertion failure with devel2 flavor and -O -------------------------------------+------------------------------------- Reporter: pacak | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 (CodeGen) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2844 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I know exactly what is going on here, thanks to the nice example in the Description. It's a long-standing bug in the implementation of `{-# SPECIALISE instance ... #-}`. Core Lint nails it instantly. I'll look at this early next week. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 16 17:29:31 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Dec 2016 17:29:31 -0000 Subject: [GHC] #12564: Type family in type pattern kind In-Reply-To: <048.93ccdd84c715d6e667e14d904b8a963f@haskell.org> References: <048.93ccdd84c715d6e667e14d904b8a963f@haskell.org> Message-ID: <063.80ce575e873b8c94179c5900622eabc2@haskell.org> #12564: Type family in type pattern kind -------------------------------------+------------------------------------- Reporter: int-index | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: TypeInType, Resolution: | TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): ummm... Maybe :) In reality, probably not. It depends on how my levity polymorphism stuff evolves. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 16 18:29:05 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Dec 2016 18:29:05 -0000 Subject: [GHC] #12564: Type family in type pattern kind In-Reply-To: <048.93ccdd84c715d6e667e14d904b8a963f@haskell.org> References: <048.93ccdd84c715d6e667e14d904b8a963f@haskell.org> Message-ID: <063.c2581cccf93bb9e04ee52ea2930d8491@haskell.org> #12564: Type family in type pattern kind -------------------------------------+------------------------------------- Reporter: int-index | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: TypeInType, Resolution: | TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by int-index): > In reality, probably not :( I'd love to see a fix for this in 8.2 - tell me if I can assist. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 16 19:26:09 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Dec 2016 19:26:09 -0000 Subject: [GHC] #12993: GHC 8.0.2-rc2 template Haskell interface file issue Message-ID: <044.56e369c809d82d157ebbcd06d9da2b3e@haskell.org> #12993: GHC 8.0.2-rc2 template Haskell interface file issue -------------------------------------+------------------------------------- Reporter: glguy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2-rc1 Keywords: | Operating System: MacOS X Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When I try to build language-lua as found on Hackage with GHC 8.0.2-rc2 I get the following error. This package works with 8.0.1. I'm using the latest release of cabal-install/Cabal and alex-3.2.1 {{{#!hs src/Language/Lua/Annotated/Lexer.x:149:14: error: • Can't find interface-file declaration for variable AlexTools.runA Probable cause: bug in .hi-boot file, or inconsistent .hi file Use -ddump-if-trace to get an idea of which file caused the error • In the expression: AlexTools.runA x_a28iM inp_a28iQ x_a28iK x_a28iL mode_a28iP In the expression: case AlexTools.runA x_a28iM inp_a28iQ x_a28iK x_a28iL mode_a28iP of { (mode'_a28iR, ts_a28iS) -> (ts_a28iS ++ (go_a28iO mode'_a28iR x_a28iK)) } In a case alternative: AlexToken x_a28iK x_a28iL x_a28iM -> case AlexTools.runA x_a28iM inp_a28iQ x_a28iK x_a28iL mode_a28iP of { (mode'_a28iR, ts_a28iS) -> (ts_a28iS ++ (go_a28iO mode'_a28iR x_a28iK)) } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 16 19:26:36 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Dec 2016 19:26:36 -0000 Subject: [GHC] #12993: GHC 8.0.2-rc2 template Haskell interface file issue In-Reply-To: <044.56e369c809d82d157ebbcd06d9da2b3e@haskell.org> References: <044.56e369c809d82d157ebbcd06d9da2b3e@haskell.org> Message-ID: <059.509442de0256a9c405a0d49630666eca@haskell.org> #12993: GHC 8.0.2-rc2 template Haskell interface file issue -------------------------------------+------------------------------------- Reporter: glguy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by glguy: @@ -5,1 +5,1 @@ - {{{#!hs + {{{ New description: When I try to build language-lua as found on Hackage with GHC 8.0.2-rc2 I get the following error. This package works with 8.0.1. I'm using the latest release of cabal-install/Cabal and alex-3.2.1 {{{ src/Language/Lua/Annotated/Lexer.x:149:14: error: • Can't find interface-file declaration for variable AlexTools.runA Probable cause: bug in .hi-boot file, or inconsistent .hi file Use -ddump-if-trace to get an idea of which file caused the error • In the expression: AlexTools.runA x_a28iM inp_a28iQ x_a28iK x_a28iL mode_a28iP In the expression: case AlexTools.runA x_a28iM inp_a28iQ x_a28iK x_a28iL mode_a28iP of { (mode'_a28iR, ts_a28iS) -> (ts_a28iS ++ (go_a28iO mode'_a28iR x_a28iK)) } In a case alternative: AlexToken x_a28iK x_a28iL x_a28iM -> case AlexTools.runA x_a28iM inp_a28iQ x_a28iK x_a28iL mode_a28iP of { (mode'_a28iR, ts_a28iS) -> (ts_a28iS ++ (go_a28iO mode'_a28iR x_a28iK)) } }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 16 19:34:35 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Dec 2016 19:34:35 -0000 Subject: [GHC] #8228: GHC built under Windows does not generate dyn_hi files In-Reply-To: <045.75cbd05b617b871cecfcf573b0b5b3b2@haskell.org> References: <045.75cbd05b617b871cecfcf573b0b5b3b2@haskell.org> Message-ID: <060.f33e6f1075cc987eb6cdcdf29dbde41c@haskell.org> #8228: GHC built under Windows does not generate dyn_hi files -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: GHC doesn't work | Unknown/Multiple at all | Test Case: cabal01 Blocked By: | Blocking: 6107 Related Tickets: #7134 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): I don't seem to have this issue with Phab:D2592 but I haven't looked very deeply. But I am able to build with DYNAMIC_TOO set and build dynamic programs fine. I will rebase that patch and update it most likely next week, should have more free time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 16 19:35:57 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Dec 2016 19:35:57 -0000 Subject: [GHC] #12993: GHC 8.0.2-rc2 template Haskell interface file issue In-Reply-To: <044.56e369c809d82d157ebbcd06d9da2b3e@haskell.org> References: <044.56e369c809d82d157ebbcd06d9da2b3e@haskell.org> Message-ID: <059.a1d6b3e764f0d9c6fd322ac2bd956de1@haskell.org> #12993: GHC 8.0.2-rc2 template Haskell interface file issue -------------------------------------+------------------------------------- Reporter: glguy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by glguy): The issue seemed to be that the the AlexTools module is using the `runA` record selector from Template Haskell but that that record selector is not exported to preserve an abstraction boundary https://github.com/GaloisInc/alex-tools/blob/master/src/AlexTools.hs#L268 If I export runA, or define runA as a top-level definition (even without exporting it) the bug does away. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 16 19:41:05 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Dec 2016 19:41:05 -0000 Subject: [GHC] #12993: GHC 8.0.2-rc2 template Haskell interface file issue In-Reply-To: <044.56e369c809d82d157ebbcd06d9da2b3e@haskell.org> References: <044.56e369c809d82d157ebbcd06d9da2b3e@haskell.org> Message-ID: <059.e4394005ed9ab33f0afb97c83ccf7d30@haskell.org> #12993: GHC 8.0.2-rc2 template Haskell interface file issue -------------------------------------+------------------------------------- Reporter: glguy | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 8.0.2-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * priority: normal => highest -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 16 19:49:31 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Dec 2016 19:49:31 -0000 Subject: [GHC] #12993: GHC 8.0.2-rc2 template Haskell interface file issue In-Reply-To: <044.56e369c809d82d157ebbcd06d9da2b3e@haskell.org> References: <044.56e369c809d82d157ebbcd06d9da2b3e@haskell.org> Message-ID: <059.06cd5f3d0c5766a0e91319e8534db993@haskell.org> #12993: GHC 8.0.2-rc2 template Haskell interface file issue -------------------------------------+------------------------------------- Reporter: glguy | Owner: Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 8.0.2-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): The name `runA` is being "exported" through a quote. Minimal reproducer: {{{ -- TA.hs {-# LANGUAGE TemplateHaskell #-} module TA (q) where data X = X { x :: Int } q = [|x|] -- TB.hs {-# LANGUAGE TemplateHaskell #-} module TB where import TA f = $(q) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 16 20:08:15 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Dec 2016 20:08:15 -0000 Subject: [GHC] #9601: Make the rewrite rule system more powerful In-Reply-To: <050.d0198153d3c3c67b578255419aefe8e8@haskell.org> References: <050.d0198153d3c3c67b578255419aefe8e8@haskell.org> Message-ID: <065.1aa3c09cc7c9a25577f55a92b8e6abd7@haskell.org> #9601: Make the rewrite rule system more powerful -------------------------------------+------------------------------------- Reporter: spacekitteh | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9137, #10804 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): The syntax might look like these are types, but morally, they are would simply be boolean predicates: {{{ IsLiteral :: a -> Bool }}} These predicates could be normal, user defined functions (which the compiler would then try to symbolically evaluate), built-in “magic” predicates like this one, or functions without “normal” implementation, but with further rewrite rules that determine the predicate. Isabelle’s simplifier supports all that, and even more, if you are looking for inspiration. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 16 21:21:16 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Dec 2016 21:21:16 -0000 Subject: [GHC] #12993: GHC 8.0.2-rc2 template Haskell interface file issue In-Reply-To: <044.56e369c809d82d157ebbcd06d9da2b3e@haskell.org> References: <044.56e369c809d82d157ebbcd06d9da2b3e@haskell.org> Message-ID: <059.4af7f167882583e2de12236731475cc6@haskell.org> #12993: GHC 8.0.2-rc2 template Haskell interface file issue -------------------------------------+------------------------------------- Reporter: glguy | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Template Haskell | Version: 8.0.2-rc2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * version: 8.0.2-rc1 => 8.0.2-rc2 * component: Compiler => Template Haskell * milestone: => 8.0.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 16 21:41:24 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Dec 2016 21:41:24 -0000 Subject: [GHC] #12993: GHC 8.0.2-rc2 template Haskell interface file issue In-Reply-To: <044.56e369c809d82d157ebbcd06d9da2b3e@haskell.org> References: <044.56e369c809d82d157ebbcd06d9da2b3e@haskell.org> Message-ID: <059.7bcc8d7a3b148fdcf536bfa2ca351bda@haskell.org> #12993: GHC 8.0.2-rc2 template Haskell interface file issue -------------------------------------+------------------------------------- Reporter: glguy | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Template Haskell | Version: 8.0.2-rc2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): It appears that the following declaration is present in the interface file produced by 8.0.1 and that produced by 8.0.2-rc2 with an explicit export of `x`, but missing from 8.0.2-rc2 otherwise, {{{ fb6798a720ab50725d554237e3ba2ff7 x :: X -> Int RecSel Left X }}} `master` is also afflicted with this issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 16 22:13:49 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Dec 2016 22:13:49 -0000 Subject: [GHC] #11317: Test prog003 fails with segfault on Windows (GHCi) In-Reply-To: <046.e04825e713c12f85562a518dea8fe3f3@haskell.org> References: <046.e04825e713c12f85562a518dea8fe3f3@haskell.org> Message-ID: <061.01a8942bca07dd845a3e474f3636306f@haskell.org> #11317: Test prog003 fails with segfault on Windows (GHCi) ---------------------------------+---------------------------------------- Reporter: rdragon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.11 Resolution: | Keywords: GC Operating System: Windows | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: prog003 Blocked By: | Blocking: Related Tickets: #11234 #3408 | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by bgamari): This failure is actually quite flaky. It seems to fail most of the time, but occasionally doesn't. Unfortunately gdb isn't of much help here, {{{ GHCi, version 8.1.20161216: http://www.haskell.org/ghc/ :? for help [New Thread 7512.0xb0c] Warning: ignoring unrecognised input `prog003.script' Prelude> :script prog003.script [1 of 1] Compiling Main ( shell.hs, interpreted ) Ok, modules loaded: Main. Run 1 [1 of 4] Compiling D ( D.hs, interpreted ) [2 of 4] Compiling C ( C.hs, interpreted ) [3 of 4] Compiling B ( B.hs, interpreted ) [4 of 4] Compiling A ( A.hs, interpreted ) Ok, modules loaded: A, B, C, D. a :: Int -> Int 168 Run 2 [1 of 4] Compiling D ( D.hs, interpreted ) [2 of 4] Compiling C ( C.hs, interpreted ) [D changed] [3 of 4] Compiling B ( B.hs, interpreted ) [D changed] [4 of 4] Compiling A ( A.hs, interpreted ) [B changed] Ok, modules loaded: A, B, C, D. (A.a,B.b,C.c,D.d) :: (Float -> Float, Float -> Float, Float -> Float, Float -> Float) 28.0 Run 3 Ok, modules loaded: A, B, C, D. (A.a,B.b,C.c,D.d) :: (Float -> Float, Float -> Float, Float -> Float, Float -> Float) 28.0 Run 4 [2 of 4] Compiling C ( C.hs, interpreted ) [3 of 4] Compiling B ( B.hs, interpreted ) [4 of 4] Compiling A ( A.hs, interpreted ) Ok, modules loaded: A, B, C, D (D.o). (A.a,B.b,C.c,D.d) :: (Float -> Float, Float -> Float, Float -> Float, Float -> Float) 28.0 Run 5 [3 of 4] Compiling B ( B.hs, interpreted ) [4 of 4] Compiling A ( A.hs, interpreted ) Ok, modules loaded: A, B, C (C.o), D (D.o). (A.a,B.b,C.c,D.d) :: (Float -> Float, Float -> Float, Float -> Float, Float -> Float) 28.0 Run 6 [4 of 4] Compiling A ( A.hs, interpreted ) Ok, modules loaded: A, B (B.o), C (C.o), D (D.o). (A.a,B.b,C.c,D.d) :: (Float -> Float, Float -> Float, Float -> Float, Float -> Float) 28.0 Run 7 Program received signal SIGSEGV, Segmentation fault. 0x000000000af36d2f in ?? () (gdb) bt #0 0x000000000af36d2f in ?? () Backtrace stopped: previous frame identical to this frame (corrupt stack?) (gdb) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 17 00:12:18 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Dec 2016 00:12:18 -0000 Subject: [GHC] #12985: GHCi incorrectly reports the kind of unboxed tuples spliced in from Template Haskell In-Reply-To: <050.ad0392c4ae751e995d3259a41b13bc35@haskell.org> References: <050.ad0392c4ae751e995d3259a41b13bc35@haskell.org> Message-ID: <065.17bbbc97357fe71ceb245a235dc59edb@haskell.org> #12985: GHCi incorrectly reports the kind of unboxed tuples spliced in from Template Haskell -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #12976 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by facundo.dominguez): Thanks for the heads up. I don't have an immediate insight though. Will take a look as soon as I can. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 17 00:30:22 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Dec 2016 00:30:22 -0000 Subject: [GHC] #12954: unexpected uncaught segmentation error in arbitrary precision Integer calculations with modestly large numbers In-Reply-To: <046.4a50f65ae4b117a9a39023c6be40e710@haskell.org> References: <046.4a50f65ae4b117a9a39023c6be40e710@haskell.org> Message-ID: <061.bbe3381fcd3f35953b1886930eb571ae@haskell.org> #12954: unexpected uncaught segmentation error in arbitrary precision Integer calculations with modestly large numbers ----------------------------------+-------------------------------------- Reporter: geraint | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: GHCi | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Comment (by George): FWIW, on my Mac it resulted in "your system has run out of Application Memory" and I had to reboot my machine. this is with ghc 8.0.1 and Mac OS 10.12.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 17 00:41:03 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Dec 2016 00:41:03 -0000 Subject: [GHC] #9291: Don't reconstruct sum types if the type subtly changes In-Reply-To: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> References: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> Message-ID: <061.4663a232cc35e1b2f9bf74c1bbca43c1@haskell.org> #9291: Don't reconstruct sum types if the type subtly changes -------------------------------------+------------------------------------- Reporter: schyler | Owner: nomeata Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 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): Phab:D2871 Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * owner: => nomeata * differential: => Phab:D2871 Comment: I started working on this (at the STG stage, CSE’ing only constructors, and not across lambdas) at Phab:D2871. Not merge-worthy yet, but preliminary review is welcome. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 17 01:58:05 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Dec 2016 01:58:05 -0000 Subject: [GHC] #9577: String literals are wasting space In-Reply-To: <045.ae4d47715fdd8321ed459b0edd946522@haskell.org> References: <045.ae4d47715fdd8321ed459b0edd946522@haskell.org> Message-ID: <060.bd07e53f8b695ac7ede31a3ce226f383@haskell.org> #9577: String literals are wasting space -------------------------------------+------------------------------------- Reporter: xnyhps | Owner: xnyhps Type: bug | Status: closed Priority: low | Milestone: 8.2.1 Component: Compiler (NCG) | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | codeGen/should_run/T9577 Blocked By: | Blocking: Related Tickets: #12937, #12965 | Differential Rev(s): Phab:D1290 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"4026b452817e9d4241691c58d131904bd0eb1fec/ghc" 4026b452/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4026b452817e9d4241691c58d131904bd0eb1fec" Fix string merging with -split-sections The added flags for string literal merging ended up printed in the middle of the section name when -split-sections was enabled. Break it up to put the flags after the name. Test Plan: validate with SplitSections=YES Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2865 GHC Trac Issues: #9577 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 17 01:58:06 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Dec 2016 01:58:06 -0000 Subject: [GHC] #12993: GHC 8.0.2-rc2 template Haskell interface file issue In-Reply-To: <044.56e369c809d82d157ebbcd06d9da2b3e@haskell.org> References: <044.56e369c809d82d157ebbcd06d9da2b3e@haskell.org> Message-ID: <059.3b6a9961890d5185daa1d29829448682@haskell.org> #12993: GHC 8.0.2-rc2 template Haskell interface file issue -------------------------------------+------------------------------------- Reporter: glguy | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Template Haskell | Version: 8.0.2-rc2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"c8ed1bdc02e68f8cab32a6a44520b896d37310a5/ghc" c8ed1bd/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c8ed1bdc02e68f8cab32a6a44520b896d37310a5" testsuite: Add test for #12993 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 17 01:58:06 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Dec 2016 01:58:06 -0000 Subject: [GHC] #11445: Turn on SplitSections by default In-Reply-To: <045.848c295688fc284737f19db2f979eda9@haskell.org> References: <045.848c295688fc284737f19db2f979eda9@haskell.org> Message-ID: <060.eab284d8704dc9a2f04b6a6659a4ef66@haskell.org> #11445: Turn on SplitSections by default -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Build System | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 11285 Related Tickets: | Differential Rev(s): Phab:D1800 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"8f71d9581ee0a1826c0105e51a7048f0c7669492/ghc" 8f71d958/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8f71d9581ee0a1826c0105e51a7048f0c7669492" Enable split sections by default where possible On non-windows platforms with GNU ld, enable SplitSections in the GHC build by default. Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: DemiMarie, thomie Differential Revision: https://phabricator.haskell.org/D1800 GHC Trac Issues: #11445 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 17 11:00:09 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Dec 2016 11:00:09 -0000 Subject: [GHC] #10723: Make declarations in signatures "weakly bound" until they are used In-Reply-To: <045.468e4f2d1d9f6be5dd513d2c8bb6c010@haskell.org> References: <045.468e4f2d1d9f6be5dd513d2c8bb6c010@haskell.org> Message-ID: <060.557be6abd0cae955fa781b37696e463e@haskell.org> #10723: Make declarations in signatures "weakly bound" until they are used -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: closed Priority: lowest | Milestone: Component: Package system | Version: 7.11 Resolution: wontfix | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => closed * resolution: => wontfix Comment: I've got a new proposal for something in this space. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 17 11:22:55 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Dec 2016 11:22:55 -0000 Subject: [GHC] #12994: Module and export level signature thinning in Backpack Message-ID: <045.f43d28ea2478374c1ae4ae4760dece5e@haskell.org> #12994: Module and export level signature thinning in Backpack -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: backpack | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- **The problem.** We want to write signature packages to allow us to reuse signatures, but Backpack in its current incarnation forces us to depend on ALL of the signatures from the signature package. This is troublesome if we only really needed a subset of the signatures from the package. What we'd like is a way to "thin" out the signatures, keeping only the ones we need. In the original design of Backpack, this was not allowed, because if a signature was requiring a function so that a module from that package could use it, you're not permitted to just drop that requirement (someone really needs it!) But signature packages: packages that consist of only signatures (no modules) do not have any such requirement. So let's allow module and export level signature thinning here. **Design.** First, during the course of mix-in linking we infer if a package is a signature package or not. A package is a signature package if it does not have any modules, and itself depends only on fully instantiated packages or signature packages. A signature package is eligible for requirement thinning. A signature package can be thinned at the module level using the `signature-mixins` field, by saying `include-signatures: sig-pkg (A)` (we don't reuse `mixins` field to distinguish signature packages from regular indefinite packages); this means that we only are bringing the signature `A` into scope. If `A` imports another signature `B`, the user is obligated to also bring that signature into scope (if they do not, we will error, although this can only be done by GHC.) By default, all signatures in scope at a name get merged to a name. We add a pragma for controlling what declarations from packages get merged in: {{{ signature A where {-# MERGE "sig-pkg" (T, S, foo, bar, baz) #-} data T qux :: T -> T }}} This line means, "merge in the declarations T, foo, bar, baz from the signature in sig-pkg." Two things to note: 1. If `foo :: S`, you're obligated to also declare `S` in the import list, even if you are not otherwise using it. The reason for this is to make it always explicit what is going to be required in the end. 2. Even if `T` is in the merge list, you still have to declare it locally if you want to make use of it. These are not imports! (:TODO: There is no provision for disambiguating between two signatures from the same package, but mix-linked differently. This seems like a pretty rare case.) The semantics is that we proceed as we do now, but when merging, we apply the explicit import list to reduce the set of entities we actually typecheck and merge in (checking, however, to ensure that these are all well-formed.) That's it, I think. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 17 12:55:39 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Dec 2016 12:55:39 -0000 Subject: [GHC] #12995: interpetBCO doesn't get stripped from executables Message-ID: <045.482eb25a92f705bed000e62a3990b26a@haskell.org> #12995: interpetBCO doesn't get stripped from executables -------------------------------------+------------------------------------- Reporter: olsner | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.0.1 System | Keywords: footprint | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Looking at the symbols linked into a simple Hello world program (e.g. with `nm -S --size-sort hello_world`), interpretBCO from the RTS is one of the larger functions. Unless I'm missing something, a compiled program shouldn't need the bytecode interpreter. The reason it gets linked and not dead-code stripped is that the scheduler has a hardcoded reference to it in `case ThreadInterpret:`, and figuring out if that particular what_next value is possible is out of reach of the linker. I'm thinking the ThreadInterpret state could be removed, and replaced with a more generic "resume by calling C function" state, with a function pointer on the stack. Paths that enter this state would push a function pointer to interpretBCO, and so the linker will link against interpretBCO iff it's actually used. Or perhaps it would be possible to have the interpreter entry point follow STG calling conventions and use ThreadRunGHC? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 17 14:10:07 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Dec 2016 14:10:07 -0000 Subject: [GHC] #12996: Memory leak in recursion when switching from -O1 to -O2 Message-ID: <047.d6ab448efd91a6aa33b2e8a0065bc482@haskell.org> #12996: Memory leak in recursion when switching from -O1 to -O2 -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: Memory leak, | Operating System: Unknown/Multiple optimization | Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- For example code see attachment. When compiling with -O1 the code behaves as expected with each loop taking about the same amount of time. At -O2 each iteration takes (nonlinear) more time than the last and leaks memory. It gets slow enough that I never bothered to let it run past 40 iterations since the slowdown seems to be exponential. I initially hit the bug in code using a Set instead of list but turns out the issue can be reduced to an example with lists. Removing either filter, pattern matching or changing the loop fixes the issue. I tested it under the following conditions: * Compiler flags: -fno-full-laziness/No flags * Compiler versions: GHC 8.0.1 and 7.10.3e * Operating Systems: Windows 10, Linux Mint In every case -O1 works as expected with -O2 showing exponential slowdown with each iteration. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 17 14:15:24 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Dec 2016 14:15:24 -0000 Subject: [GHC] #12996: Memory leak in recursion when switching from -O1 to -O2 In-Reply-To: <047.d6ab448efd91a6aa33b2e8a0065bc482@haskell.org> References: <047.d6ab448efd91a6aa33b2e8a0065bc482@haskell.org> Message-ID: <062.fb968d5e7c3b46a18964d398cc812f79@haskell.org> #12996: Memory leak in recursion when switching from -O1 to -O2 -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Memory leak, | optimization 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 AndreasK): * Attachment "Main.hs" added. Example Code -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 17 14:15:49 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Dec 2016 14:15:49 -0000 Subject: [GHC] #12996: Memory leak in recursion when switching from -O1 to -O2 In-Reply-To: <047.d6ab448efd91a6aa33b2e8a0065bc482@haskell.org> References: <047.d6ab448efd91a6aa33b2e8a0065bc482@haskell.org> Message-ID: <062.8804c20462f4bde829a50881f068551e@haskell.org> #12996: Memory leak in recursion when switching from -O1 to -O2 -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Memory leak, | optimization 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 AndreasK): * Attachment "Main.verbose-stg2stg.O2" added. STG output at -O2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 17 14:16:04 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Dec 2016 14:16:04 -0000 Subject: [GHC] #12996: Memory leak in recursion when switching from -O1 to -O2 In-Reply-To: <047.d6ab448efd91a6aa33b2e8a0065bc482@haskell.org> References: <047.d6ab448efd91a6aa33b2e8a0065bc482@haskell.org> Message-ID: <062.278c81dfc7773b85c70afbd605c7dc52@haskell.org> #12996: Memory leak in recursion when switching from -O1 to -O2 -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Memory leak, | optimization 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 AndreasK): * Attachment "Main.verbose-stg2stg.O1" added. STG output at -O1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 17 14:17:29 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Dec 2016 14:17:29 -0000 Subject: [GHC] #12996: Memory leak in recursion when switching from -O1 to -O2 In-Reply-To: <047.d6ab448efd91a6aa33b2e8a0065bc482@haskell.org> References: <047.d6ab448efd91a6aa33b2e8a0065bc482@haskell.org> Message-ID: <062.c9852ddaebba755b66e0222b73e540c1@haskell.org> #12996: Memory leak in recursion when switching from -O1 to -O2 -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Memory leak, | optimization 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: | -------------------------------------+------------------------------------- Description changed by AndreasK: @@ -24,0 +24,4 @@ + + The stg output seems to be the same for both cases as well. I attached STG + dumps created with " -fforce-recomp -ddump-to-file -dverbose-core2core + -dsuppress-uniques -dsuppress-all Main.hs -ddump-simpl -dverbose-stg2stg" New description: For example code see attachment. When compiling with -O1 the code behaves as expected with each loop taking about the same amount of time. At -O2 each iteration takes (nonlinear) more time than the last and leaks memory. It gets slow enough that I never bothered to let it run past 40 iterations since the slowdown seems to be exponential. I initially hit the bug in code using a Set instead of list but turns out the issue can be reduced to an example with lists. Removing either filter, pattern matching or changing the loop fixes the issue. I tested it under the following conditions: * Compiler flags: -fno-full-laziness/No flags * Compiler versions: GHC 8.0.1 and 7.10.3e * Operating Systems: Windows 10, Linux Mint In every case -O1 works as expected with -O2 showing exponential slowdown with each iteration. The stg output seems to be the same for both cases as well. I attached STG dumps created with " -fforce-recomp -ddump-to-file -dverbose-core2core -dsuppress-uniques -dsuppress-all Main.hs -ddump-simpl -dverbose-stg2stg" -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 17 14:29:13 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Dec 2016 14:29:13 -0000 Subject: [GHC] #12996: Memory leak in recursion when switching from -O1 to -O2 In-Reply-To: <047.d6ab448efd91a6aa33b2e8a0065bc482@haskell.org> References: <047.d6ab448efd91a6aa33b2e8a0065bc482@haskell.org> Message-ID: <062.6294b9939cad2616b1a0ef3aaeda6832@haskell.org> #12996: Memory leak in recursion when switching from -O1 to -O2 -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Memory leak, | optimization 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 AndreasK): * Attachment "O1.log" added. Peformance reference for -O1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 17 14:29:28 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Dec 2016 14:29:28 -0000 Subject: [GHC] #12996: Memory leak in recursion when switching from -O1 to -O2 In-Reply-To: <047.d6ab448efd91a6aa33b2e8a0065bc482@haskell.org> References: <047.d6ab448efd91a6aa33b2e8a0065bc482@haskell.org> Message-ID: <062.1201846736a270f340ec0c4d9db5d8f6@haskell.org> #12996: Memory leak in recursion when switching from -O1 to -O2 -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Memory leak, | optimization 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 AndreasK): * Attachment "O2.log" added. Performance reference for -O2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 17 14:46:27 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Dec 2016 14:46:27 -0000 Subject: [GHC] #12996: Memory leak in recursion when switching from -O1 to -O2 In-Reply-To: <047.d6ab448efd91a6aa33b2e8a0065bc482@haskell.org> References: <047.d6ab448efd91a6aa33b2e8a0065bc482@haskell.org> Message-ID: <062.7979f0df7aea1715b32a36760eba8fbb@haskell.org> #12996: Memory leak in recursion when switching from -O1 to -O2 -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Memory leak, | optimization 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: | -------------------------------------+------------------------------------- Description changed by AndreasK: @@ -24,4 +24,0 @@ - - The stg output seems to be the same for both cases as well. I attached STG - dumps created with " -fforce-recomp -ddump-to-file -dverbose-core2core - -dsuppress-uniques -dsuppress-all Main.hs -ddump-simpl -dverbose-stg2stg" New description: For example code see attachment. When compiling with -O1 the code behaves as expected with each loop taking about the same amount of time. At -O2 each iteration takes (nonlinear) more time than the last and leaks memory. It gets slow enough that I never bothered to let it run past 40 iterations since the slowdown seems to be exponential. I initially hit the bug in code using a Set instead of list but turns out the issue can be reduced to an example with lists. Removing either filter, pattern matching or changing the loop fixes the issue. I tested it under the following conditions: * Compiler flags: -fno-full-laziness/No flags * Compiler versions: GHC 8.0.1 and 7.10.3e * Operating Systems: Windows 10, Linux Mint In every case -O1 works as expected with -O2 showing exponential slowdown with each iteration. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 17 14:47:36 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Dec 2016 14:47:36 -0000 Subject: [GHC] #12996: Memory leak in recursion when switching from -O1 to -O2 In-Reply-To: <047.d6ab448efd91a6aa33b2e8a0065bc482@haskell.org> References: <047.d6ab448efd91a6aa33b2e8a0065bc482@haskell.org> Message-ID: <062.1e4e9b528122b546946116c3285a8b9c@haskell.org> #12996: Memory leak in recursion when switching from -O1 to -O2 -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Memory leak, | optimization 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 AndreasK): * Attachment "Main.verbose-stg2stg.O1" added. STG output at -O1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 17 14:47:36 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Dec 2016 14:47:36 -0000 Subject: [GHC] #12996: Memory leak in recursion when switching from -O1 to -O2 In-Reply-To: <047.d6ab448efd91a6aa33b2e8a0065bc482@haskell.org> References: <047.d6ab448efd91a6aa33b2e8a0065bc482@haskell.org> Message-ID: <062.278c81dfc7773b85c70afbd605c7dc52@haskell.org> #12996: Memory leak in recursion when switching from -O1 to -O2 -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Memory leak, | optimization 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 AndreasK): * Attachment "Main.verbose-stg2stg.O1" removed. STG output at -O1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 17 14:47:53 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Dec 2016 14:47:53 -0000 Subject: [GHC] #12996: Memory leak in recursion when switching from -O1 to -O2 In-Reply-To: <047.d6ab448efd91a6aa33b2e8a0065bc482@haskell.org> References: <047.d6ab448efd91a6aa33b2e8a0065bc482@haskell.org> Message-ID: <062.8804c20462f4bde829a50881f068551e@haskell.org> #12996: Memory leak in recursion when switching from -O1 to -O2 -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Memory leak, | optimization 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 AndreasK): * Attachment "Main.verbose-stg2stg.O2" removed. STG output at -O2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 17 14:47:53 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Dec 2016 14:47:53 -0000 Subject: [GHC] #12996: Memory leak in recursion when switching from -O1 to -O2 In-Reply-To: <047.d6ab448efd91a6aa33b2e8a0065bc482@haskell.org> References: <047.d6ab448efd91a6aa33b2e8a0065bc482@haskell.org> Message-ID: <062.3c7ad8632e047443f52e1f4d6977d1fe@haskell.org> #12996: Memory leak in recursion when switching from -O1 to -O2 -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Memory leak, | optimization 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 AndreasK): * Attachment "Main.verbose-stg2stg.O2" added. STG output at -O2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 17 15:03:04 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Dec 2016 15:03:04 -0000 Subject: [GHC] #12995: interpetBCO doesn't get stripped from executables In-Reply-To: <045.482eb25a92f705bed000e62a3990b26a@haskell.org> References: <045.482eb25a92f705bed000e62a3990b26a@haskell.org> Message-ID: <060.4a933cd8e27752fab12f7c23ce7147d3@haskell.org> #12995: interpetBCO doesn't get stripped from executables -------------------------------------+------------------------------------- Reporter: olsner | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: footprint Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): I have another idea. I think we can't start a GHCi process just by using `base` from a Haskell program, right? So that part of the scheduler can only be run in `ghc-stage2`. Why not just `ifdef` those parts so that that block in the scheduler and `interpretBCO` would be defined only when compiling RTS for `ghc-stage2`? Would that be too much extra compilation? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 17 15:13:35 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Dec 2016 15:13:35 -0000 Subject: [GHC] #12997: Build broken on OpenBSD Message-ID: <046.c0878bd6997bef3bde75ecc5cab79db4@haskell.org> #12997: Build broken on OpenBSD ----------------------------------------+--------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.2-rc2 Keywords: | Operating System: OpenBSD Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- Karel says, {{{ "/usr/local/bin/ghc" -o utils/hsc2hs/dist/build/tmp/hsc2hs -hisuf hi -osuf o -hcsuf hc -static -H32m -O -Wall -package-db libraries/bootstrapping.conf -hide-all-packages -i -iutils/hsc2hs/. -iutils/hsc2hs/dist/build -iutils/hsc2hs/dist/build/autogen -Iutils/hsc2hs/dist/build -Iutils/hsc2hs/dist/build/autogen -optP-include -optPutils/hsc2hs/dist/build/autogen/cabal_macros.h -package-id base-4.8.2.0-8dd7859ce039df9f3d3f4ff9dbf4bb93 -package-id containers-0.5.6.2-59326c33e30ec8f6afd574cbac625bbb -package-id directory-1.2.2.0-de5c44596f448d2b2988d8588c5afdef -package-id filepath-1.4.0.0-f97d1e4aebfd7a03be6980454fe31d6e -package-id process-1.2.3.0-ca3fff48cdf67a08d7e3f92817538395 -XHaskell2010 -no-user-package-db -rtsopts -odir utils/hsc2hs/dist/build -hidir utils/hsc2hs/dist/build -stubdir utils/hsc2hs/dist/build -optl-z -optlwxneeded -static -H32m -O -Wall -package-db libraries/bootstrapping.conf -hide-all-packages -i -iutils/hsc2hs/. -iutils/hsc2hs/dist/build -iutils/hsc2hs/dist/build/autogen -Iutils/hsc2hs/dist/build -Iutils/hsc2hs/dist/build/autogen -optP-include -optPutils/hsc2hs/dist/build/autogen/cabal_macros.h -package-id base-4.8.2.0-8dd7859ce039df9f3d3f4ff9dbf4bb93 -package-id containers-0.5.6.2-59326c33e30ec8f6afd574cbac625bbb -package-id directory-1.2.2.0-de5c44596f448d2b2988d8588c5afdef -package-id filepath-1.4.0.0-f97d1e4aebfd7a03be6980454fe31d6e -package-id process-1.2.3.0-ca3fff48cdf67a08d7e3f92817538395 -XHaskell2010 -no-user-package-db -rtsopts utils/hsc2hs/dist/build/Main.o utils/hsc2hs/dist/build/C.o utils/hsc2hs/dist/build/Common.o utils/hsc2hs/dist/build/CrossCodegen.o utils/hsc2hs/dist/build/DirectCodegen.o utils/hsc2hs/dist/build/Flags.o utils/hsc2hs/dist/build/HSCParser.o utils/hsc2hs/dist/build/UtilsCodegen.o utils/hsc2hs/dist/build/Paths_hsc2hs.o : Warning: Couldn't figure out linker information! Make sure you're using GNU ld, GNU gold or the built in OS X linker, etc. gcc: wxneeded: No such file or directory compiler/ghc.mk:584: compiler/stage1/build/.depend-v.haskell: No such file or directory gmake[1]: *** [utils/hsc2hs/ghc.mk:15: utils/hsc2hs/dist/build/tmp/hsc2hs] Error 1 gmake: *** [Makefile:132: all] Error 2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 17 15:13:49 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Dec 2016 15:13:49 -0000 Subject: [GHC] #12997: Build broken on OpenBSD In-Reply-To: <046.c0878bd6997bef3bde75ecc5cab79db4@haskell.org> References: <046.c0878bd6997bef3bde75ecc5cab79db4@haskell.org> Message-ID: <061.2ff9d9d57ec624393ba3936ee375da98@haskell.org> #12997: Build broken on OpenBSD -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.2-rc2 Resolution: | Keywords: Operating System: OpenBSD | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * failure: None/Unknown => Building GHC failed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 17 15:15:43 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Dec 2016 15:15:43 -0000 Subject: [GHC] #12997: Build broken on OpenBSD In-Reply-To: <046.c0878bd6997bef3bde75ecc5cab79db4@haskell.org> References: <046.c0878bd6997bef3bde75ecc5cab79db4@haskell.org> Message-ID: <061.7ae08deee41aefb7319e5624eacd7965@haskell.org> #12997: Build broken on OpenBSD -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.2-rc2 Resolution: | Keywords: Operating System: OpenBSD | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => merge Comment: This was fixed by f48f5a9ebf384e1e157b7b413e1d779f4289ddd2 but unfortunately I forgot to create a ticket to ensure this was merged back to `ghc-8.0`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 17 15:24:59 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Dec 2016 15:24:59 -0000 Subject: [GHC] #12993: GHC 8.0.2-rc2 template Haskell interface file issue In-Reply-To: <044.56e369c809d82d157ebbcd06d9da2b3e@haskell.org> References: <044.56e369c809d82d157ebbcd06d9da2b3e@haskell.org> Message-ID: <059.754feccb7758d6562220b1b7db80aa00@haskell.org> #12993: GHC 8.0.2-rc2 template Haskell interface file issue -------------------------------------+------------------------------------- Reporter: glguy | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Template Haskell | Version: 8.0.2-rc2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: osa1 (added) Comment: The culprit here appears to be 3a00ff92a3ee66c096b85b180d247d1a471a6b6e, {{{ commit 3a00ff92a3ee66c096b85b180d247d1a471a6b6e Author: Ömer Sinan Ağacan Date: Fri May 27 11:02:47 2016 -0400 Do not init record accessors as exported This was causing redundant code generation when accessors are not actually exported, as they were being marked as "exported" at initialization. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 17 16:24:31 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Dec 2016 16:24:31 -0000 Subject: [GHC] #12996: Memory leak in recursion when switching from -O1 to -O2 In-Reply-To: <047.d6ab448efd91a6aa33b2e8a0065bc482@haskell.org> References: <047.d6ab448efd91a6aa33b2e8a0065bc482@haskell.org> Message-ID: <062.5a38e2dff4359a84c40dd97b141e6470@haskell.org> #12996: Memory leak in recursion when switching from -O1 to -O2 -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Memory leak, | optimization 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: | -------------------------------------+------------------------------------- Comment (by osa1): I analyzed this a little bit, here's my findings: - The function that causes this slowness is generated by `SpecConstr`. If you compile with `-O2 -fno-spec-constr` it works fine. - When `appLoop` function is defined like this: {{{#!haskell appLoop :: AppState -> IO () appLoop s = do let AppState state = s print state appLoop $ AppState (cycleState state) }}} Demand analyzer thinks `appLoop` is not strict on `s`. If we define it like this: {{{#!haskell appLoop :: AppState -> IO () appLoop (AppState state) = do print state appLoop $ AppState (cycleState state) }}} Worker/wrapper runs instead of SpecConstr and this version compiles to fast code. I don't understand why `-O2` version is getting slower in each iteration, but I suspect it has do to with Cmm rather than STG. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 17 16:44:31 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Dec 2016 16:44:31 -0000 Subject: [GHC] #12995: interpetBCO doesn't get stripped from executables In-Reply-To: <045.482eb25a92f705bed000e62a3990b26a@haskell.org> References: <045.482eb25a92f705bed000e62a3990b26a@haskell.org> Message-ID: <060.d2b6a1a05ca9b5c78bcbea7b5c9ec4f3@haskell.org> #12995: interpetBCO doesn't get stripped from executables -------------------------------------+------------------------------------- Reporter: olsner | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: footprint Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by olsner): That does sound simpler, but I believe `ghc-stage2` currently links against the same RTS libraries that are being installed? Then we'd need to introduce separate copies of the RTS for ghc itself and user programs. WRT compilation time, the RTS build at least parallelizes perfectly so that shouldn't be too bad, but it could be a bit of a build-system mess. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 17 16:49:20 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Dec 2016 16:49:20 -0000 Subject: [GHC] #12993: GHC 8.0.2-rc2 template Haskell interface file issue In-Reply-To: <044.56e369c809d82d157ebbcd06d9da2b3e@haskell.org> References: <044.56e369c809d82d157ebbcd06d9da2b3e@haskell.org> Message-ID: <059.c0bf2b9a75d689b2cdae4a2857048a2a@haskell.org> #12993: GHC 8.0.2-rc2 template Haskell interface file issue -------------------------------------+------------------------------------- Reporter: glguy | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Template Haskell | Version: 8.0.2-rc2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): The motivation behind that commit is that if a record selector is not exported and not used within the module, code for it was still generated. With that commit they're removed. I agree that this bug is caused by that change. I think a proper fix would be to detect that in these cases the selector is actually used. This is already done for toplevel definitions. For example: {{{#!haskell module Lib (x) where x, y :: Int x = 1 y = 2 }}} Compile and run `nm` on the object file, and you'll see that there isn't a symbol `Lib_y_closure`. If you export `y` you'll see that symbol. If I export `y` in a TH code it still works fine: {{{#!haskell module Lib (x, z) where x, y :: Int x = 1 y = 2 z = [|y|] }}} If you run `nm` you'll see that there's a `Lib_y_closure`. Apparently this last part is not done for record selectors and we should fix that. @bgamari, if this is urgent feel free to revert that commit, I can put it back once I figure out how to fix this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 17 16:59:21 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Dec 2016 16:59:21 -0000 Subject: [GHC] #12995: interpetBCO doesn't get stripped from executables In-Reply-To: <045.482eb25a92f705bed000e62a3990b26a@haskell.org> References: <045.482eb25a92f705bed000e62a3990b26a@haskell.org> Message-ID: <060.42ec8de65532cbf9e69c0689c33a3ae1@haskell.org> #12995: interpetBCO doesn't get stripped from executables -------------------------------------+------------------------------------- Reporter: olsner | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: footprint Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): We could add a new "dimension of RTS way" (like threaded, profiling and debug) for whether or not to include the interpreter. Note that this doesn't affect just ghc itself but also programs that use the ghc library. The burden on the end user to select the correct RTS flavor doesn't seem worthwhile if the only purpose is to generate a smaller executable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 17 19:21:51 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Dec 2016 19:21:51 -0000 Subject: [GHC] #3384: Add HsSyn prettyprinter tests In-Reply-To: <044.d11e412e7968bb1bf100410e6ff17081@haskell.org> References: <044.d11e412e7968bb1bf100410e6ff17081@haskell.org> Message-ID: <059.6822518c973795e37af44bcbbe333e89@haskell.org> #3384: Add HsSyn prettyprinter tests -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: task | Status: closed Priority: normal | Milestone: 8.2.1 Component: Test Suite | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2752 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Tamar Christina ): In [changeset:"d88efb7048160c3031eadb4f3b729e9fe406414d/ghc" d88efb7/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d88efb7048160c3031eadb4f3b729e9fe406414d" Fix Pretty printer tests on Windows Summary: D2752 added some tests which escapes string literals. This means newlines are converted before they get normalized by the IO functions. So on Windows \r\n would be in the output while \n was expected. Test Plan: make test -C testsuite/tests/printer Reviewers: austin, bgamari, alanz Reviewed By: alanz Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2873 GHC Trac Issues: #3384 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 17 21:35:19 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Dec 2016 21:35:19 -0000 Subject: [GHC] #9291: Don't reconstruct sum types if the type subtly changes In-Reply-To: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> References: <046.746d0dfe65f722505ddbecfcd76b7b95@haskell.org> Message-ID: <061.e7ca670d83c9197510a359a228e86809@haskell.org> #9291: Don't reconstruct sum types if the type subtly changes -------------------------------------+------------------------------------- Reporter: schyler | Owner: nomeata Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 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): Phab:D2871 Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: new => patch Comment: Ok, should be ready for review. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 17 22:35:34 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Dec 2016 22:35:34 -0000 Subject: [GHC] #12993: GHC 8.0.2-rc2 template Haskell interface file issue In-Reply-To: <044.56e369c809d82d157ebbcd06d9da2b3e@haskell.org> References: <044.56e369c809d82d157ebbcd06d9da2b3e@haskell.org> Message-ID: <059.e373976ae386a5c6384ae057f9a0ea0e@haskell.org> #12993: GHC 8.0.2-rc2 template Haskell interface file issue -------------------------------------+------------------------------------- Reporter: glguy | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.2 Component: Template Haskell | Version: 8.0.2-rc2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"0af959b1999b48f3b8e6c47184b6f8c80b4c452d/ghc" 0af959b1/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0af959b1999b48f3b8e6c47184b6f8c80b4c452d" Revert "Do not init record accessors as exported" This reverts commit 3a00ff92a3ee66c096b85b180d247d1a471a6b6e due to #12993 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 17 23:04:59 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Dec 2016 23:04:59 -0000 Subject: [GHC] #12998: libraries/base/System/Posix/Types.hs: tries to define Floating instance for opaque type Message-ID: <045.4c5bd2571549a8006f623b42fcc0a3c6@haskell.org> #12998: libraries/base/System/Posix/Types.hs: tries to define Floating instance for opaque type -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I've noticed it as a build failure on openbsd-6 but on linux behaviour is strange as well. Build failure: {{{ libraries/base/System/Posix/Types.hs:217:100: error: * No instance for (Fractional Int32) arising from the 'deriving' clause of a data type declaration Possible fix: use a standalone 'deriving instance' declaration, so you can specify the instance context yourself * When deriving the instance for (Fractional CTimer) }}} On openbsd-6.0 timer_t is an int32: {{{ # gcc -E /usr/include/time.h | grep timer_t typedef __int32_t __timer_t; typedef __timer_t timer_t; }}} On amd64-linux-glibc it's void*: {{{ $ gcc -E /usr/include/time.h | grep timer_t typedef void * __timer_t; typedef __timer_t timer_t; }}} But base's configure detects it as Double (by chance) on amd64-linux- glibc. {{{ System.Posix.Types> :t CTimer CTimer :: Double -> CTimer }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 17 23:06:48 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Dec 2016 23:06:48 -0000 Subject: [GHC] #12998: libraries/base/System/Posix/Types.hs: tries to define Floating instance for opaque type In-Reply-To: <045.4c5bd2571549a8006f623b42fcc0a3c6@haskell.org> References: <045.4c5bd2571549a8006f623b42fcc0a3c6@haskell.org> Message-ID: <060.1bd7f1d7c55b848a6c5941e16a497422@haskell.org> #12998: libraries/base/System/Posix/Types.hs: tries to define Floating instance for opaque type -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by slyfox): changeset:ffc2327070dbb664bdb407a804121eacb2a7c734 added instance as: {{{#!hs #if defined(HTYPE_TIMER_T) -- | @since 4.10.0.0 FLOATING_TYPE_WITH_CTYPE(CTimer,timer_t,HTYPE_TIMER_T) #endif }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 17 23:15:44 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Dec 2016 23:15:44 -0000 Subject: [GHC] #12998: libraries/base/System/Posix/Types.hs: tries to define Floating instance for opaque type In-Reply-To: <045.4c5bd2571549a8006f623b42fcc0a3c6@haskell.org> References: <045.4c5bd2571549a8006f623b42fcc0a3c6@haskell.org> Message-ID: <060.060cac61f11fd9c1dadf9dd543b2692d@haskell.org> #12998: libraries/base/System/Posix/Types.hs: tries to define Floating instance for opaque type -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: DanielG (added) Comment: As I note [https://phabricator.haskell.org/rGHCffc2327070dbb664bdb407a804121eacb2a7c734 here], a quick-and-dirty fix would be to introduce a macro `OPAQUE_TYPE_WITH_CTYPE` in `CTypes.h`: {{{#!hs #define OPAQUE_CLASSES Eq,Ord,Storable #define OPAQUE_TYPE_WITH_CTYPE(T,THE_CTYPE,B) \ newtype {-# CTYPE "THE_CTYPE" #-} T = T B \ deriving (OPAQUE_CLASSES) \ deriving newtype (Read, Show); }}} And then use that on `CTimer` instead of `FLOATING_TYPE_WITH_CTYPE`. Of course, this doesn't fix the infelicity that the underlying representation of `CTimer` is still not a `Ptr ()`, which would require fixing the `FPTOOLS_CHECK_HTYPE_ELSE` [http://git.haskell.org/ghc.git/blob/ffc2327070dbb664bdb407a804121eacb2a7c734:/libraries/base/aclocal.m4#l115 M4 macro] in `libraries/base/aclocal.m4` to remedy. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 17 23:18:06 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Dec 2016 23:18:06 -0000 Subject: [GHC] #12998: libraries/base/System/Posix/Types.hs: tries to define Floating instance for opaque type In-Reply-To: <045.4c5bd2571549a8006f623b42fcc0a3c6@haskell.org> References: <045.4c5bd2571549a8006f623b42fcc0a3c6@haskell.org> Message-ID: <060.5b770bf1a26645b08e72cea9e35578c1@haskell.org> #12998: libraries/base/System/Posix/Types.hs: tries to define Floating instance for opaque type -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12795 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #12795 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 17 23:45:00 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Dec 2016 23:45:00 -0000 Subject: [GHC] #12998: libraries/base/System/Posix/Types.hs: tries to define Floating instance for opaque type In-Reply-To: <045.4c5bd2571549a8006f623b42fcc0a3c6@haskell.org> References: <045.4c5bd2571549a8006f623b42fcc0a3c6@haskell.org> Message-ID: <060.8fbfc2e0d10ce5795014083866e35e93@haskell.org> #12998: libraries/base/System/Posix/Types.hs: tries to define Floating instance for opaque type -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12795 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by DanielG): Ah looks like I trusted the assessments of `FPTOOLS_CHECK_HTYPE` a bit too much. Personally I'm not all that attached to `timer_t` specifically I just added it for completeness' sake. So I wouldn't mind just removing it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 18 00:00:19 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Dec 2016 00:00:19 -0000 Subject: [GHC] #12998: libraries/base/System/Posix/Types.hs: tries to define Floating instance for opaque type In-Reply-To: <045.4c5bd2571549a8006f623b42fcc0a3c6@haskell.org> References: <045.4c5bd2571549a8006f623b42fcc0a3c6@haskell.org> Message-ID: <060.cb3bcd24371db41187798eaff39049de@haskell.org> #12998: libraries/base/System/Posix/Types.hs: tries to define Floating instance for opaque type -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12795 | Differential Rev(s): Phab:D2876 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D2876 * milestone: => 8.2.1 Comment: Very well, I've opted to go down the "remove `CTimer`" route in Phab:D2876. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 18 01:01:51 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Dec 2016 01:01:51 -0000 Subject: [GHC] #12819: Pattern synonym signatures are not validity-checked In-Reply-To: <047.ea2438d0a734e559e510fecf46b09b65@haskell.org> References: <047.ea2438d0a734e559e510fecf46b09b65@haskell.org> Message-ID: <062.e52a2776791895897845912ca484d38b@haskell.org> #12819: Pattern synonym signatures are not validity-checked -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"8906e7b79a585039712034d9e88ca49f3cea6554/ghc" 8906e7b7/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8906e7b79a585039712034d9e88ca49f3cea6554" Reshuffle levity polymorphism checks. Previously, GHC checked for bad levity polymorphism to the left of all arrows in data constructors. This was wrong, as reported in #12911 (where an example is also shown). The solution is to check each individual argument for bad levity polymorphism. Thus the check has been moved from TcValidity to TcTyClsDecls. A similar situation exists with pattern synonyms, also fixed here. This patch also nabs #12819 while I was in town. Test cases: typecheck/should_compile/T12911, patsyn/should_fail/T12819 Test Plan: ./validate Reviewers: simonpj, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2783 GHC Trac Issues: #12819, #12911 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 18 01:01:51 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Dec 2016 01:01:51 -0000 Subject: [GHC] #12911: Levity polymorphism check eliminates non-levity-polymorphic data constructor In-Reply-To: <047.553556d51b1a72154ff5eadb4d1146d2@haskell.org> References: <047.553556d51b1a72154ff5eadb4d1146d2@haskell.org> Message-ID: <062.707679a560ac3f30a59278a85c693a3f@haskell.org> #12911: Levity polymorphism check eliminates non-levity-polymorphic data constructor -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"8906e7b79a585039712034d9e88ca49f3cea6554/ghc" 8906e7b7/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8906e7b79a585039712034d9e88ca49f3cea6554" Reshuffle levity polymorphism checks. Previously, GHC checked for bad levity polymorphism to the left of all arrows in data constructors. This was wrong, as reported in #12911 (where an example is also shown). The solution is to check each individual argument for bad levity polymorphism. Thus the check has been moved from TcValidity to TcTyClsDecls. A similar situation exists with pattern synonyms, also fixed here. This patch also nabs #12819 while I was in town. Test cases: typecheck/should_compile/T12911, patsyn/should_fail/T12819 Test Plan: ./validate Reviewers: simonpj, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2783 GHC Trac Issues: #12819, #12911 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 18 01:01:51 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Dec 2016 01:01:51 -0000 Subject: [GHC] #7325: threadDelay mistreats minBound and maxBound in some configurations In-Reply-To: <048.f6376e5e233d59dcc7fd251637dbe84b@haskell.org> References: <048.f6376e5e233d59dcc7fd251637dbe84b@haskell.org> Message-ID: <063.ad6c93e6375857836afdb4c39211b293@haskell.org> #7325: threadDelay mistreats minBound and maxBound in some configurations -------------------------------------+------------------------------------- Reporter: joeyadams | Owner: Type: bug | Status: patch Priority: high | Milestone: 8.2.1 Component: Runtime System | Version: 7.6.1 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Incorrect result | Test Case: at runtime | base/tests/T8089 Blocked By: | Blocking: Related Tickets: #9722 | Differential Rev(s): Phab:D2861 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"2d1beb1ec84c2d22c6be83944ef4ea8626abd76a/ghc" 2d1beb1e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2d1beb1ec84c2d22c6be83944ef4ea8626abd76a" rts/win32/IOManager: Fix integer types This code has been broken on 64-bit systems for some time: the length and timeout arguments of `addIORequest` and `addDelayRequest`, respectively, were declared as `int`. However, they were passed Haskell integers from their respective primops. Integer overflow and madness ensued. This resulted in #7325 and who knows what else. Also, there were a few left-over `BOOL`s in here which were not passed to Windows system calls; these were changed to C99 `bool`s. However, there is still a bit of signedness inconsistency within the `delay#` call-chain, * `GHC.Conc.IO.threadDelay` and the `delay#` primop accept `Int` arguments * The `delay#` implementation in `PrimOps.cmm` expects the timeout as a `W_` * `AsyncIO.c:addDelayRequest` expects an `HsInt` (was `int` prior to this patch) * `IOManager.c:AddDelayRequest` expects an `HsInt`` (was `int`) * The Windows `Sleep` function expects a `DWORD` (which is unsigned) Test Plan: Validate on Windows Reviewers: erikd, austin, simonmar, Phyx Reviewed By: Phyx Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2861 GHC Trac Issues: #7325 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 18 01:01:51 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Dec 2016 01:01:51 -0000 Subject: [GHC] #12992: Language.Haskell.TH doesn't reexport everything from Language.Haskell.TH.Lib In-Reply-To: <050.b358fe16eb179e6d620e897e9ac1be92@haskell.org> References: <050.b358fe16eb179e6d620e897e9ac1be92@haskell.org> Message-ID: <065.3383b7a31345a21d61b8756cb9c6264a@haskell.org> #12992: Language.Haskell.TH doesn't reexport everything from Language.Haskell.TH.Lib -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Template Haskell | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2867 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"343b1473fa3ad1f90e4f9708dbc4d8127382dc36/ghc" 343b1473/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="343b1473fa3ad1f90e4f9708dbc4d8127382dc36" Reexport Language.Haskell.TH.Lib from Language.Haskell.TH Reexporting `Language.Haskell.TH.Lib` from `Language.Haskell.TH` ensures that `Language.Haskell.TH` will continue to expose all of the functions that `Language.Haskell.TH.Lib` does in the future. Fixes #12992. Test Plan: ./validate Reviewers: austin, bgamari, goldfire Reviewed By: bgamari, goldfire Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2867 GHC Trac Issues: #12992 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 18 01:01:51 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Dec 2016 01:01:51 -0000 Subject: [GHC] #5654: Profiling semantics bug In-Reply-To: <047.ac296d247951e42a341a674c3c07d355@haskell.org> References: <047.ac296d247951e42a341a674c3c07d355@haskell.org> Message-ID: <062.453ba8b623691380511babecaa775e9b@haskell.org> #5654: Profiling semantics bug -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: low | Milestone: 8.2.1 Component: Profiling | Version: 7.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | profiling/should_run/scc004 Blocked By: | Blocking: Related Tickets: #10007 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"2a02040b2e23daa4f791afc290c33c9bbe3c620c/ghc" 2a02040b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2a02040b2e23daa4f791afc290c33c9bbe3c620c" Fix bug in previous fix for #5654 I forgot to account for BCOs, which have a different layout from functions. This caused crashes when using profiling with GHCi (via -fexternal-interpreter -prof), which unfortunately is not tested at all by validate, even when profiling is enabled. I'm going to add some testing that would have caught this in a separate patch. Test Plan: ``` cd nofib/spectral/puzzle && make NoFibWithGHCi=YES EXTRA_RUNTEST_OPTS='-fexternal-interpreter -prof' ``` New testsuite tests coming in a separate diff. Reviewers: niteria, austin, erikd, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2868 GHC Trac Issues: #5654 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 18 01:01:51 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Dec 2016 01:01:51 -0000 Subject: [GHC] #5654: Profiling semantics bug In-Reply-To: <047.ac296d247951e42a341a674c3c07d355@haskell.org> References: <047.ac296d247951e42a341a674c3c07d355@haskell.org> Message-ID: <062.0b7ac583ba12c6fcb49c4c1d15da9517@haskell.org> #5654: Profiling semantics bug -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: low | Milestone: 8.2.1 Component: Profiling | Version: 7.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | profiling/should_run/scc004 Blocked By: | Blocking: Related Tickets: #10007 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"90cfa84981ee1f9fb756a3af1bd707674c18c034/ghc" 90cfa849/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="90cfa84981ee1f9fb756a3af1bd707674c18c034" Run some tests with -fexternal-interpreter -prof We don't have any other tests for this, except one Template Haskell test. This would have caught the bug I just fixed in D2868, at least when validating with profiling on. Test Plan: Ran tests Reviewers: niteria, austin, erikd, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2869 GHC Trac Issues: #5654 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 18 01:02:25 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Dec 2016 01:02:25 -0000 Subject: [GHC] #12819: Pattern synonym signatures are not validity-checked In-Reply-To: <047.ea2438d0a734e559e510fecf46b09b65@haskell.org> References: <047.ea2438d0a734e559e510fecf46b09b65@haskell.org> Message-ID: <062.a754de0caebc71b4a118a2259c50610f@haskell.org> #12819: Pattern synonym signatures are not validity-checked -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 18 01:02:49 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Dec 2016 01:02:49 -0000 Subject: [GHC] #7325: threadDelay mistreats minBound and maxBound in some configurations In-Reply-To: <048.f6376e5e233d59dcc7fd251637dbe84b@haskell.org> References: <048.f6376e5e233d59dcc7fd251637dbe84b@haskell.org> Message-ID: <063.4d23825b2063785142aabf0ff13b7f06@haskell.org> #7325: threadDelay mistreats minBound and maxBound in some configurations -------------------------------------+------------------------------------- Reporter: joeyadams | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Runtime System | Version: 7.6.1 Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Incorrect result | Test Case: at runtime | base/tests/T8089 Blocked By: | Blocking: Related Tickets: #9722 | Differential Rev(s): Phab:D2861 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 18 01:03:01 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Dec 2016 01:03:01 -0000 Subject: [GHC] #12992: Language.Haskell.TH doesn't reexport everything from Language.Haskell.TH.Lib In-Reply-To: <050.b358fe16eb179e6d620e897e9ac1be92@haskell.org> References: <050.b358fe16eb179e6d620e897e9ac1be92@haskell.org> Message-ID: <065.02260989ae66198ac431ba279727c7bc@haskell.org> #12992: Language.Haskell.TH doesn't reexport everything from Language.Haskell.TH.Lib -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Template Haskell | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2867 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 18 01:03:21 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Dec 2016 01:03:21 -0000 Subject: [GHC] #5654: Profiling semantics bug In-Reply-To: <047.ac296d247951e42a341a674c3c07d355@haskell.org> References: <047.ac296d247951e42a341a674c3c07d355@haskell.org> Message-ID: <062.c9ec77ba518112c9792e5e42066e574a@haskell.org> #5654: Profiling semantics bug -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: closed Priority: low | Milestone: 8.2.1 Component: Profiling | Version: 7.2.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | profiling/should_run/scc004 Blocked By: | Blocking: Related Tickets: #10007 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 18 01:13:24 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Dec 2016 01:13:24 -0000 Subject: [GHC] #10010: LLVM/optimized code for sqrt incorrect for negative values In-Reply-To: <044.d19bdbb75724dc36db07410233c6837c@haskell.org> References: <044.d19bdbb75724dc36db07410233c6837c@haskell.org> Message-ID: <059.2e3fbe424dcbb4dcb7d78dff70847516@haskell.org> #10010: LLVM/optimized code for sqrt incorrect for negative values -------------------------------------+------------------------------------- Reporter: glguy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): @tjakway, does that mean this is fixed now? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 18 02:06:41 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Dec 2016 02:06:41 -0000 Subject: [GHC] #12993: GHC 8.0.2-rc2 template Haskell interface file issue In-Reply-To: <044.56e369c809d82d157ebbcd06d9da2b3e@haskell.org> References: <044.56e369c809d82d157ebbcd06d9da2b3e@haskell.org> Message-ID: <059.b0103ace811c9b53861bf5b00e1962c4@haskell.org> #12993: GHC 8.0.2-rc2 template Haskell interface file issue -------------------------------------+------------------------------------- Reporter: glguy | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.0.2 Component: Template Haskell | Version: 8.0.2-rc2 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: I've reverted the commit in question on `master` and `ghc-8.0`. osa1, perhaps you want to open a Task ticket to ensure that the original goal of your commit isn't lost? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 18 03:40:58 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Dec 2016 03:40:58 -0000 Subject: [GHC] #11062: Type families + hs-boot files = panic (type family consistency check too early) In-Reply-To: <047.7c49c2177d004f32c0696dfdb91a7434@haskell.org> References: <047.7c49c2177d004f32c0696dfdb91a7434@haskell.org> Message-ID: <062.662afc6f4969bcc034f2fd9b2b42fb38@haskell.org> #11062: Type families + hs-boot files = panic (type family consistency check too early) -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: patch Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: TypeFamilies | hs-boot Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2859 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"25b70a29f6236b591252bf5a361a1547f0ffee51/ghc" 25b70a29/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="25b70a29f6236b591252bf5a361a1547f0ffee51" Check family instance consistency of hs-boot families later, fixes #11062. Summary: With hs-boot files, some type families may be defined in the module we are typechecking. In this case, we are not allowed to poke these families until after we typecheck our local declarations. So we first check everything involving non-recursive families, and then check the recursive families as we finish kind-checking them. Signed-off-by: Edward Z. Yang Test Plan: validate Reviewers: goldfire, austin, simonpj, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2859 GHC Trac Issues: #11062 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 18 03:46:10 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Dec 2016 03:46:10 -0000 Subject: [GHC] #11062: Type families + hs-boot files = panic (type family consistency check too early) In-Reply-To: <047.7c49c2177d004f32c0696dfdb91a7434@haskell.org> References: <047.7c49c2177d004f32c0696dfdb91a7434@haskell.org> Message-ID: <062.725443b0e9ac9876e3ad11a0d81ba9db@haskell.org> #11062: Type families + hs-boot files = panic (type family consistency check too early) -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: TypeFamilies | hs-boot Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2859 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 18 04:56:04 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Dec 2016 04:56:04 -0000 Subject: [GHC] #10010: LLVM/optimized code for sqrt incorrect for negative values In-Reply-To: <044.d19bdbb75724dc36db07410233c6837c@haskell.org> References: <044.d19bdbb75724dc36db07410233c6837c@haskell.org> Message-ID: <059.88471cf856f48de2131709b8c71e900e@haskell.org> #10010: LLVM/optimized code for sqrt incorrect for negative values -------------------------------------+------------------------------------- Reporter: glguy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tjakway): Replying to [comment:3 mpickering]: > @tjakway, does that mean this is fixed now? I don't remember why I didn't test it with LLVM 3.6 (probably just forgot) but we should probably do that before closing the ticket. I don't have any reason to think 3.6 would be different but just to be sure. Unless we don't support 3.6 with the latest version of GHC, then we can just close it now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 18 05:22:18 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Dec 2016 05:22:18 -0000 Subject: [GHC] #12603: INLINE and manually inlining produce different code In-Reply-To: <046.944cd4788eed55470361e7f38358ac43@haskell.org> References: <046.944cd4788eed55470361e7f38358ac43@haskell.org> Message-ID: <061.3637f0d18a2fc93591e1f25ccf114be3@haskell.org> #12603: INLINE and manually inlining produce different code -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #12747 #12781 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: bgamari => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 18 08:01:04 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Dec 2016 08:01:04 -0000 Subject: [GHC] #12999: Investigate use of floating-point arithmetic in I/O Event-handler Message-ID: <042.d9e72583afa2ded1431f4a089ec3a9ba@haskell.org> #12999: Investigate use of floating-point arithmetic in I/O Event-handler -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: | Version: 8.0.1 libraries/base | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I was asked/made aware of some questionable use of floating-point arithmetic in `GHC.Event.TimerManager`; Specifically, I can't explain why `getMonotonicTime` first gets a timestamp as `Word64`, only to perform a not-necessarily cheap floating- point division, and returns a `Double`... {{{#!hs -- | Return monotonic time in seconds, since some unspecified starting point getMonotonicTime :: IO Double getMonotonicTime = do w <- getMonotonicNSec return (fromIntegral w / 1000000000) foreign import ccall unsafe "getMonotonicNSec" getMonotonicNSec :: IO Word64 }}} which then gets used e.g. by {{{#!hs updateTimeout :: TimerManager -> TimeoutKey -> Int -> IO () updateTimeout mgr (TK key) us = do now <- getMonotonicTime let expTime = fromIntegral us / 1000000.0 + now editTimeouts mgr (Q.adjust (const expTime) key) wakeManager mgr }}} Whereas, the priority queue (`GHC.Event.PSQ`) then uses `Double`s for its priorities... For correctness and performance reasons, I'd expect the use of fixed-width integers (i.e. `Word64` or `Int64`) for such codepaths... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 18 11:22:48 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Dec 2016 11:22:48 -0000 Subject: [GHC] #12879: (xs -> xs) wrongly suggests TypeApplications In-Reply-To: <051.16598209ccbf8290d8f46e992fbe8e53@haskell.org> References: <051.16598209ccbf8290d8f46e992fbe8e53@haskell.org> Message-ID: <066.7c39d88d5a18a0ed4c12b89fa29fefae@haskell.org> #12879: (xs -> xs) wrongly suggests TypeApplications -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2877 Wiki Page: | -------------------------------------+------------------------------------- Changes (by zyla): * differential: => Phab:D2877 Comment: I submitted a patch: https://phabricator.haskell.org/D2877 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 18 15:52:10 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Dec 2016 15:52:10 -0000 Subject: [GHC] #12478: Template Haskell support for unboxed sums In-Reply-To: <050.ac92f1e30012cfcda45bbbcb5dda55fd@haskell.org> References: <050.ac92f1e30012cfcda45bbbcb5dda55fd@haskell.org> Message-ID: <065.a1a76365aa7903a23445bb3618c6b234@haskell.org> #12478: Template Haskell support for unboxed sums -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: Template Haskell | Version: 8.1 Resolution: fixed | Keywords: | TemplateHaskell Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | th/T12478_{1,2,3,4} Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2448, Wiki Page: | Phab:D2854 -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"b5d788aa0e73fdf22cca3f88962e7652b07073cc/ghc" b5d788aa/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b5d788aa0e73fdf22cca3f88962e7652b07073cc" Introduce unboxedSum{Data,Type}Name to template-haskell Summary: In D2448 (which introduced Template Haskell support for unboxed sums), I neglected to add `unboxedSumDataName` and `unboxedSumTypeName` functions, since there wasn't any way you could write unboxed sum data or type constructors in prefix form to begin with (see #12514). But even if you can't write these `Name`s directly in source code, it would still be nice to be able to use these `Name`s in Template Haskell (for instance, to be able to treat unboxed sum type constructors like any other type constructors). Along the way, this uncovered a minor bug in `isBuiltInOcc_maybe` in `TysWiredIn`, which was calculating the arity of unboxed sum data constructors incorrectly. Test Plan: make test TEST=T12478_5 Reviewers: osa1, goldfire, austin, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2854 GHC Trac Issues: #12478, #12514 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 18 15:52:10 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Dec 2016 15:52:10 -0000 Subject: [GHC] #12795: Add more types to System.Posix.Types In-Reply-To: <046.4fbe8aafe0a055922e787b103a5411d6@haskell.org> References: <046.4fbe8aafe0a055922e787b103a5411d6@haskell.org> Message-ID: <061.213c9b50791a3bd64b34ed0df1197d1b@haskell.org> #12795: Add more types to System.Posix.Types -------------------------------------+------------------------------------- Reporter: DanielG | Owner: DanielG Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: libraries/base | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2664 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"513eb6a0638a1c64b9d76bcab39ed80cdd9dbb27/ghc" 513eb6a0/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="513eb6a0638a1c64b9d76bcab39ed80cdd9dbb27" Fix #12998 by removing CTimer Summary: CTimer is a wrapper around `timer_t`, which is a typedef for `void*` on most platforms. The issue is that GHC's `FPTOOLS_CHECK_HTYPE` is not robust enough to discern pointer types from non-pointer types, so it mistakenly labels `timer_t` as a `Double` or `Int32` (depending on how many bits a pointer takes up on your platform). This wreaks havoc when trying to give it certain type class instances, as noted in https://phabricator.haskell.org/rGHCffc2327070dbb664bdb407a804121eacb2a7c734. For now, the simplest thing to do would be removing `CTimer`, since: 1. The original author (@DanielG) didn't have a particular use in mind for `timer_t` when he fixed #12795. 2. `CTimer` hasn't appeared in a release of `base` yet. Fixes #12998. Reviewers: austin, hvr, bgamari, DanielG, trofi Reviewed By: bgamari, trofi Subscribers: thomie, DanielG, erikd Differential Revision: https://phabricator.haskell.org/D2876 GHC Trac Issues: #12795, #12998 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 18 15:52:09 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Dec 2016 15:52:09 -0000 Subject: [GHC] #12514: Can't write unboxed sum type constructors in prefix form In-Reply-To: <050.841e8669fe47472e53beeefaf89bc022@haskell.org> References: <050.841e8669fe47472e53beeefaf89bc022@haskell.org> Message-ID: <065.d88a0dd4c743d42ea466938bfe7c92c9@haskell.org> #12514: Can't write unboxed sum type constructors in prefix form -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"b5d788aa0e73fdf22cca3f88962e7652b07073cc/ghc" b5d788aa/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b5d788aa0e73fdf22cca3f88962e7652b07073cc" Introduce unboxedSum{Data,Type}Name to template-haskell Summary: In D2448 (which introduced Template Haskell support for unboxed sums), I neglected to add `unboxedSumDataName` and `unboxedSumTypeName` functions, since there wasn't any way you could write unboxed sum data or type constructors in prefix form to begin with (see #12514). But even if you can't write these `Name`s directly in source code, it would still be nice to be able to use these `Name`s in Template Haskell (for instance, to be able to treat unboxed sum type constructors like any other type constructors). Along the way, this uncovered a minor bug in `isBuiltInOcc_maybe` in `TysWiredIn`, which was calculating the arity of unboxed sum data constructors incorrectly. Test Plan: make test TEST=T12478_5 Reviewers: osa1, goldfire, austin, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2854 GHC Trac Issues: #12478, #12514 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 18 15:52:10 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Dec 2016 15:52:10 -0000 Subject: [GHC] #12998: libraries/base/System/Posix/Types.hs: tries to define Floating instance for opaque type In-Reply-To: <045.4c5bd2571549a8006f623b42fcc0a3c6@haskell.org> References: <045.4c5bd2571549a8006f623b42fcc0a3c6@haskell.org> Message-ID: <060.429e14b23e0975196105525c15c4c100@haskell.org> #12998: libraries/base/System/Posix/Types.hs: tries to define Floating instance for opaque type -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12795 | Differential Rev(s): Phab:D2876 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"513eb6a0638a1c64b9d76bcab39ed80cdd9dbb27/ghc" 513eb6a0/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="513eb6a0638a1c64b9d76bcab39ed80cdd9dbb27" Fix #12998 by removing CTimer Summary: CTimer is a wrapper around `timer_t`, which is a typedef for `void*` on most platforms. The issue is that GHC's `FPTOOLS_CHECK_HTYPE` is not robust enough to discern pointer types from non-pointer types, so it mistakenly labels `timer_t` as a `Double` or `Int32` (depending on how many bits a pointer takes up on your platform). This wreaks havoc when trying to give it certain type class instances, as noted in https://phabricator.haskell.org/rGHCffc2327070dbb664bdb407a804121eacb2a7c734. For now, the simplest thing to do would be removing `CTimer`, since: 1. The original author (@DanielG) didn't have a particular use in mind for `timer_t` when he fixed #12795. 2. `CTimer` hasn't appeared in a release of `base` yet. Fixes #12998. Reviewers: austin, hvr, bgamari, DanielG, trofi Reviewed By: bgamari, trofi Subscribers: thomie, DanielG, erikd Differential Revision: https://phabricator.haskell.org/D2876 GHC Trac Issues: #12795, #12998 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 18 15:53:25 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Dec 2016 15:53:25 -0000 Subject: [GHC] #12998: libraries/base/System/Posix/Types.hs: tries to define Floating instance for opaque type In-Reply-To: <045.4c5bd2571549a8006f623b42fcc0a3c6@haskell.org> References: <045.4c5bd2571549a8006f623b42fcc0a3c6@haskell.org> Message-ID: <060.92db7db42c042b226ce720f10802649a@haskell.org> #12998: libraries/base/System/Posix/Types.hs: tries to define Floating instance for opaque type -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12795 | Differential Rev(s): Phab:D2876 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 18 16:04:31 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Dec 2016 16:04:31 -0000 Subject: [GHC] #10053: Regression on MacOS platform, error in ghci calling main after loading compiled code: "Too late for parseStaticFlags..." In-Reply-To: <045.7defde488a4af19895968f8c8b9b5f95@haskell.org> References: <045.7defde488a4af19895968f8c8b9b5f95@haskell.org> Message-ID: <060.57aba58e6ada9a005e062ad2e22b5851@haskell.org> #10053: Regression on MacOS platform, error in ghci calling main after loading compiled code: "Too late for parseStaticFlags..." -------------------------------------+------------------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: low | Milestone: Component: GHCi | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by George): * priority: normal => low Comment: given that it only fails with module Main or no module statement I'm changing the priority to low. It is still a regression and a confusing error so it would be nice to have it fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 18 17:00:30 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Dec 2016 17:00:30 -0000 Subject: [GHC] #13000: minor doc bug about list fusion in GHC user's guide Message-ID: <045.b6f36678f58a796f7f2fbf38ed7ca155@haskell.org> #13000: minor doc bug about list fusion in GHC user's guide -------------------------------------+------------------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Documentation | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- First, the Users Guide (8.0.1.20161117) in section 10.32.6,List fusion, should mention length as a good consumer. Secondly, it says: "If you want to write your own good consumers or producers, look at the Prelude definitions of the above functions to see how to do so." However if you go to https://hackage.haskell.org/package/base-4.9.0.0/docs/Prelude.html and look at the source code for length you end up at https://hackage.haskell.org/package/base-4.9.0.0/docs/src/Data.Foldable.html#length which is not a good consumer. I think the User's Guide should be changed to replace "Prelude" with "https://hackage.haskell.org/package/base-4.9.0.0/docs/src/GHC.List.html". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 18 17:00:33 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Dec 2016 17:00:33 -0000 Subject: [GHC] #12958: Properly detect if GHCi is running in MinTTY In-Reply-To: <050.37d9b9b784581d8321a5359fbb9fb60c@haskell.org> References: <050.37d9b9b784581d8321a5359fbb9fb60c@haskell.org> Message-ID: <065.23b8c976052b4791b5a625b543cca2e7@haskell.org> #12958: Properly detect if GHCi is running in MinTTY -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: GHCi | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2878 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D2878 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 18 17:18:51 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Dec 2016 17:18:51 -0000 Subject: [GHC] #13001: EnumFromThenTo is is not a good producer Message-ID: <045.652a4f5a016a7134707107ddee18203b@haskell.org> #13001: EnumFromThenTo is is not a good producer -------------------------------------+------------------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: MacOS X Architecture: x86_64 | Type of failure: Runtime (amd64) | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# OPTIONS_GHC -Wall #-} module Foo where testFromTo :: Int -> Int testFromTo n = length ([0..(10^n)] :: [Int]) testFromThenTo :: Int -> Int testFromThenTo n = length ([0,2..(10^n)] :: [Int]) }}} {{{ $ ghci -fobject-code -O GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help Prelude> :load Foo :load Foo [1 of 1] Compiling Foo ( Foo.hs, Foo.o ) Ok, modules loaded: Foo (Foo.o). Prelude Foo> :set +s :set +s Prelude Foo> testFromTo 5 testFromTo 5 100001 (0.02 secs, 97,992 bytes) Prelude Foo> testFromThenTo 5 testFromThenTo 5 50001 (0.00 secs, 5,694,424 bytes) Prelude Foo> testFromThenTo 6 testFromThenTo 6 500001 (0.02 secs, 56,095,288 bytes) Prelude Foo> }}} I set the Type to bug rather than feature request as the source code in http://hackage.haskell.org/package/base-4.9.0.0/docs/src/GHC.Enum.html#enumFromTo seems to be trying to do list fusion: {{{#!hs -- efdInt and efdtInt deal with [a,b..] and [a,b..c]. -- The code is more complicated because of worries about Int overflow. -- See Note [How the Enum rules work] {-# RULES "efdtInt" [~1] forall x1 x2 y. efdtInt x1 x2 y = build (\ c n -> efdtIntFB c n x1 x2 y) "efdtIntUpList" [1] efdtIntFB (:) [] = efdtInt #-} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 18 17:49:42 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Dec 2016 17:49:42 -0000 Subject: [GHC] #13002: :set -O does not work in .ghci file Message-ID: <045.1c938219ffdaa14f896f37fe62db4c60@haskell.org> #13002: :set -O does not work in .ghci file --------------------------------------+---------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+---------------------------- {{{#!hs {-# OPTIONS_GHC -Wall #-} module Foo where testFromTo :: Int -> Int testFromTo n = length ([0..(10^n)] :: [Int]) }}} {{{ cat ~/.ghci :set +s :set -fobject-code :set -O bash-3.2$ touch Foo.hs bash-3.2$ ghci GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /Users/gcolpitts/.ghci Prelude> :load Foo :load Foo [1 of 1] Compiling Foo ( Foo.hs, Foo.o ) Ok, modules loaded: Foo (Foo.o). (0.15 secs,) Prelude Foo> testFromTo 5 testFromTo 5 100001 (0.02 secs, 8,885,888 bytes) Prelude Foo> :quit :quit Leaving GHCi. bash-3.2$ touch Foo.hs bash-3.2$ ghci -fobject-code -O GHCi, version 8.0.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /Users/gcolpitts/.ghci Prelude> :load Foo :load Foo [1 of 1] Compiling Foo ( Foo.hs, Foo.o ) Ok, modules loaded: Foo (Foo.o). (0.15 secs,) Prelude Foo> testFromTo 5 testFromTo 5 100001 (0.02 secs, 98,400 bytes) }}} While supplying -fobject-code -O as an argument to ghci seems like an easy workaround that isn't feasible as far as I know when using emacs thus setting priority to normal rather than low. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 18 18:20:17 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Dec 2016 18:20:17 -0000 Subject: [GHC] #12997: Build broken on OpenBSD In-Reply-To: <046.c0878bd6997bef3bde75ecc5cab79db4@haskell.org> References: <046.c0878bd6997bef3bde75ecc5cab79db4@haskell.org> Message-ID: <061.91f79b2c625d0c16b083847acc26eef1@haskell.org> #12997: Build broken on OpenBSD -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.2-rc2 Resolution: | Keywords: Operating System: OpenBSD | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by slyfox): * cc: slyfox (added) Comment: In HEAD I had to revert changeset:f48f5a9ebf384e1e157b7b413e1d779f4289ddd2 as changeset:a6657bd0d6b9949098021d89ed3cd8a943bdd3b6 (it's a full clean revert) to restore SRC_LD_OPTS handling. This fix should be enough for ghc-8.0 branch for OpenBSD: changeset:87c3b1d4395c3d4fc7a5272717c48f3f525da959 I only tested ghc-HEAD on OpenBSD-6.0. Hope it's not too confusing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 18 23:56:53 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Dec 2016 23:56:53 -0000 Subject: [GHC] #13003: improve documentation for typed TH and make it more discoverable Message-ID: <045.be56361ab1e3677f8b5beb473b90b5fb@haskell.org> #13003: improve documentation for typed TH and make it more discoverable -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Documentation | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- theres quite a sparsity of documentation and dearth of discoverability for typed TH in the Template Haskell Library haddocks and the GHC manual, this probably wouldn't be much work to make it vastly better. one specific two course of action might be a) adding to the template haskell library a module `Language.Haskell.TH.Typed` that only exports the stuff in `Language.Haskell.TH` that is needed for typed TH (namely the newtype `TExp` but not its constructor), plus perhaps the function `unTypeQ :: Q (TExp a) -> Q Exp` and additionally documents how to use typed TH splices and quotations. b) add a clear section to the manual that perhaps touches on some of this too? (its not clear if theres any real docs in the ghc manual on this :( ) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 19 00:16:42 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Dec 2016 00:16:42 -0000 Subject: [GHC] #13004: Timeout no longer kills processes on timeout Message-ID: <044.a6877c959d19da5e9ab8a3dcab34e50f@haskell.org> #13004: Timeout no longer kills processes on timeout -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Test Suite | Version: 8.1 Keywords: | Operating System: Windows Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- There's a bug in timeout where processes aren't being killed on a timeout. e.g. `~/ghc/testsuite/timeout/install-inplace/bin/timeout.exe 10 "sleep 10000s"` never ends -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 19 00:18:00 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Dec 2016 00:18:00 -0000 Subject: [GHC] #13004: Timeout no longer kills processes on timeout In-Reply-To: <044.a6877c959d19da5e9ab8a3dcab34e50f@haskell.org> References: <044.a6877c959d19da5e9ab8a3dcab34e50f@haskell.org> Message-ID: <059.9a215c41c47de87fed8d99199e102097@haskell.org> #13004: Timeout no longer kills processes on timeout -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Test Suite | Version: 8.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2880 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => patch * differential: => Phab:D2880 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 19 03:14:29 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Dec 2016 03:14:29 -0000 Subject: [GHC] #12911: Levity polymorphism check eliminates non-levity-polymorphic data constructor In-Reply-To: <047.553556d51b1a72154ff5eadb4d1146d2@haskell.org> References: <047.553556d51b1a72154ff5eadb4d1146d2@haskell.org> Message-ID: <062.a91d11823404b4c3dabec43cd8fbfc49@haskell.org> #12911: Levity polymorphism check eliminates non-levity-polymorphic data constructor -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T12911 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * testcase: => typecheck/should_compile/T12911 * status: new => closed * resolution: => fixed Comment: Thanks for merging, Ben! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 19 03:15:27 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Dec 2016 03:15:27 -0000 Subject: [GHC] #12819: Pattern synonym signatures are not validity-checked In-Reply-To: <047.ea2438d0a734e559e510fecf46b09b65@haskell.org> References: <047.ea2438d0a734e559e510fecf46b09b65@haskell.org> Message-ID: <062.a12fe13b9d61c5cf46a68fb7c2a22d97@haskell.org> #12819: Pattern synonym signatures are not validity-checked -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC accepts | Test Case: invalid program | patsyn/should_fail/T12819 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * testcase: => patsyn/should_fail/T12819 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 19 03:49:35 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Dec 2016 03:49:35 -0000 Subject: [GHC] #13003: improve documentation for typed TH and make it more discoverable In-Reply-To: <045.be56361ab1e3677f8b5beb473b90b5fb@haskell.org> References: <045.be56361ab1e3677f8b5beb473b90b5fb@haskell.org> Message-ID: <060.e05d7eaadc2d5cc8eec9a7da3260522c@haskell.org> #13003: improve documentation for typed TH and make it more discoverable -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Documentation | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): The [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html #template-haskell section] on Template Haskell in the manual does describe the typed TH facility. Admittedly, this description is buried within the description for regular TH. A concrete suggestion for improvement (in other words, a patch) is very welcome. As for your suggestion (a), that might indeed be an improvement. Is this something that should go to the libraries@ mailing list? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 19 10:26:58 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Dec 2016 10:26:58 -0000 Subject: [GHC] #10007: Fix misattribution of Cost Centre profiles to lintAnnots In-Reply-To: <052.018bee922f3a1f3c0286b790702cf38d@haskell.org> References: <052.018bee922f3a1f3c0286b790702cf38d@haskell.org> Message-ID: <067.626d4574e7b45349921306c8b061d92a@haskell.org> #10007: Fix misattribution of Cost Centre profiles to lintAnnots -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: simonmar Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Profiling | Version: 7.10.1-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #9961,#5654 | Differential Rev(s): Phab:D616 Wiki Page: | Phab:D636 -------------------------------------+------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Optimistically closing as fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 19 10:36:07 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Dec 2016 10:36:07 -0000 Subject: [GHC] #12995: interpetBCO doesn't get stripped from executables In-Reply-To: <045.482eb25a92f705bed000e62a3990b26a@haskell.org> References: <045.482eb25a92f705bed000e62a3990b26a@haskell.org> Message-ID: <060.83ef75fdb44529c9adaeb7b07d6b18e7@haskell.org> #12995: interpetBCO doesn't get stripped from executables -------------------------------------+------------------------------------- Reporter: olsner | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: footprint Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): The proposed solution in the ticket doesn't work out easily, I think, because the reference to `interpretBCO` would move from the scheduler to the entry code for BCO. So the BCO code needs to move into a separate file. Maybe things can be unravelled sufficiently, or maybe they get too tangled, I'm not sure. Adding another RTS way dimension seems too heavyweight a solution for this problem. Speaking of which, how much do we really care about this? How many Kb would be saved in a static executable? My guess is that there might be lower-hanging fruit. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 19 11:29:27 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Dec 2016 11:29:27 -0000 Subject: [GHC] #13005: Mac OSX uses MAP_ANON in place of MAP_ANONYMOUS Message-ID: <046.d43a09b5f43348df6b22d776514a766b@haskell.org> #13005: Mac OSX uses MAP_ANON in place of MAP_ANONYMOUS -------------------------------------+------------------------------------- Reporter: gracjan | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 (Linking) | Keywords: | Operating System: MacOS X Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Looks like Mac OS X has MAP_ANON instead of MAP_ANONYMOUS in /usr/include/sys/mman.h rts/linker/MachO.c needs fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 19 11:38:16 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Dec 2016 11:38:16 -0000 Subject: [GHC] #13006: Possible program should type check but does not using Implicit Parameters and Vectors Message-ID: <046.d11a545658da6a3ca94932f012a2e6ea@haskell.org> #13006: Possible program should type check but does not using Implicit Parameters and Vectors -------------------------------------+------------------------------------- Reporter: clinton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I think (but I'm not sure) that the following code should type check. This will require using the 'vector' package to illustrate this issue, sorry I couldn't create an example without it. Either uncommenting the explicit `m ()` signature or changing the type to the simpler `D m` data type will allow the code to compile. {{{ {-# LANGUAGE ImplicitParams #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE KindSignatures #-} import Data.Vector.Unboxed.Mutable (MVector) import Control.Monad.Primitive (PrimMonad, PrimState) data D (x :: * -> *) type T m = MVector (PrimState m) Int --type T m = D m h :: forall m. PrimMonad m => T m -> m () h x = let f _ = (let ?v = x in g) {- :: m () -} in f undefined g :: (PrimMonad m , ?v :: T m) => m () g = undefined main = pure () }}} Alternatively, including `g` into the let binding as opposed to the top level will also compile: {{{ {-# LANGUAGE ImplicitParams #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE KindSignatures #-} import Data.Vector.Unboxed.Mutable (MVector) import Control.Monad.Primitive (PrimMonad, PrimState) data D (x :: * -> *) type T m = MVector (PrimState m) Int --type T m = D m h :: forall m. PrimMonad m => T m -> m () h x = let f _ = (let ?v = x in g) {- :: m () -} g :: (PrimMonad m , ?v :: T m) => m () g = undefined in f undefined main = pure () }}} Perhaps this isn't a bug and has to do with the rank-2 type inside of Vector, but I'm just putting in this bug report to confirm. This is an issue as of 8.0.2-rc2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 19 11:39:53 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Dec 2016 11:39:53 -0000 Subject: [GHC] #12780: Calling "do nothing" type checker plugin affects type checking when it shouldn't In-Reply-To: <046.701ac1658f414a768fc3ee00bdc8b2b5@haskell.org> References: <046.701ac1658f414a768fc3ee00bdc8b2b5@haskell.org> Message-ID: <061.c8383418093751c40fe5c9dc5f6f5dfc@haskell.org> #12780: Calling "do nothing" type checker plugin affects type checking when it shouldn't -------------------------------------+------------------------------------- Reporter: clinton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by clinton): * version: 8.1 => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 19 12:45:14 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Dec 2016 12:45:14 -0000 Subject: [GHC] #13006: Possible program should type check but does not using Implicit Parameters and Vectors In-Reply-To: <046.d11a545658da6a3ca94932f012a2e6ea@haskell.org> References: <046.d11a545658da6a3ca94932f012a2e6ea@haskell.org> Message-ID: <061.3447447b1ccc72387da55d609127a578@haskell.org> #13006: Possible program should type check but does not using Implicit Parameters and Vectors -------------------------------------+------------------------------------- Reporter: clinton | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2-rc2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => invalid Comment: In {{{ f _ = let ?v = x in g }}} what type did you expect `f` to have? GHC infers {{{ f :: forall a n. (...) => a -> n () }}} because `g :: forall m. (PrimMonad m, ?v :: T m) => m ()`. (I've used `n` instead of `m` in `f`'s type to emphasise that it is different to `m`. What is the `(...)`? The body of `f` has a call `g`, which gives rise to the constraints `(PrimMonad n, ?v :: T n)`. Alas the `?v` binding in f's RHS binds `?v :: T m` (since `x :: T m`), and that is no help in discharging `?v :: T n`. So we end up with {{{ f :: forall a n. (PrimMonad n, ?v :: T n) => n () }}} and hence the error. By adding the signature you make `f` monomorphic (`-XMonoLocalBinds` has the same effect) which solves the problem. Perhaps we should be more aggressive in reporting an error when functional dependencies can't be satisfied, but I think the program should indeed be rejected. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 19 13:01:05 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Dec 2016 13:01:05 -0000 Subject: [GHC] #13005: Mac OSX uses MAP_ANON in place of MAP_ANONYMOUS In-Reply-To: <046.d43a09b5f43348df6b22d776514a766b@haskell.org> References: <046.d43a09b5f43348df6b22d776514a766b@haskell.org> Message-ID: <061.bf52f2c2bb16169ea5fab348ad943b3f@haskell.org> #13005: Mac OSX uses MAP_ANON in place of MAP_ANONYMOUS -------------------------------------+------------------------------------- Reporter: gracjan | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 (Linking) | Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by gracjan): https://phabricator.haskell.org/D2881 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 19 13:08:30 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Dec 2016 13:08:30 -0000 Subject: [GHC] #13007: ghc-options -threaded present but -N option unrecognised on ARM Message-ID: <043.e2df0643f8c5c18fcdd44872fd2d8ea9@haskell.org> #13007: ghc-options -threaded present but -N option unrecognised on ARM -------------------------------------+------------------------------------- Reporter: tmpz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.0.1 System | Keywords: arm, | Operating System: Linux raspberrypi, raspbian, rts, | threaded | Type of failure: Incorrect result Architecture: arm | at runtime Test Case: | Blocked By: http://allocinit.io/haskell | /haskell-on-raspberry-pi-3/ | Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When compiling a program on ARM (Raspberry PI 3, OS: Raspbian Jessi) with ghc it is possible to specify as runtime options {{{ -threaded -rtsopts -with-rtsopts=-N }}} However when running the program with -N, -N is not a recognised option. See output here http://pastebin.com/sKjfkRtq Running with --info gives the following http://pastebin.com/q36Ef7y4 showing that ("RTS way", "rts_thr") is available. Investigation already done here: https://www.reddit.com/r/haskell/comments/5j0u36/getting_haskell_and_stack_on_a_rapsberry_pi_3/dbcgbht/ Steps used to get ghc on the system: http://allocinit.io/haskell/haskell- on-raspberry-pi-3/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 19 13:11:20 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Dec 2016 13:11:20 -0000 Subject: [GHC] #13005: Mac OSX uses MAP_ANON in place of MAP_ANONYMOUS In-Reply-To: <046.d43a09b5f43348df6b22d776514a766b@haskell.org> References: <046.d43a09b5f43348df6b22d776514a766b@haskell.org> Message-ID: <061.e9b6a4b26474ecea285eb21bdc148797@haskell.org> #13005: Mac OSX uses MAP_ANON in place of MAP_ANONYMOUS -------------------------------------+------------------------------------- Reporter: gracjan | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 (Linking) | Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2881 Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * differential: => Phab:D2881 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 19 14:17:34 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Dec 2016 14:17:34 -0000 Subject: [GHC] #13006: Possible program should type check but does not using Implicit Parameters and Vectors In-Reply-To: <046.d11a545658da6a3ca94932f012a2e6ea@haskell.org> References: <046.d11a545658da6a3ca94932f012a2e6ea@haskell.org> Message-ID: <061.e27a8096c2ff9b894d9d843782e619f0@haskell.org> #13006: Possible program should type check but does not using Implicit Parameters and Vectors -------------------------------------+------------------------------------- Reporter: clinton | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2-rc2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by clinton): Thank you for the explanation, but why does the code happily compile when `type T m = D m`? Your explanation above seems independent of the exact definition of `T`, so is there an alternate bug for the `type T m = D m` case where the code compiles when it shouldn't? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 19 14:47:14 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Dec 2016 14:47:14 -0000 Subject: [GHC] #13006: Possible program should type check but does not using Implicit Parameters and Vectors In-Reply-To: <046.d11a545658da6a3ca94932f012a2e6ea@haskell.org> References: <046.d11a545658da6a3ca94932f012a2e6ea@haskell.org> Message-ID: <061.6a93d634fe29c4bd1350a2419aad390e@haskell.org> #13006: Possible program should type check but does not using Implicit Parameters and Vectors -------------------------------------+------------------------------------- Reporter: clinton | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2-rc2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): From the given `[G] ?v :: MVector (PrimState m) Int` and wanted `[G] ?v MVector (PrimState n) Int` we get the derived equality `[D] MVector (PrimState m) Int ~ MVector (PrimState n) Int`. Alas `PrimState` is a (non-injective) type family, so this does not tell us that `M ~ n`. In the simpler version, it does. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 19 15:20:40 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Dec 2016 15:20:40 -0000 Subject: [GHC] #12928: Too easy to trigger CUSK condition using TH In-Reply-To: <048.b87023a4856ac4da5fccc9b82019d18a@haskell.org> References: <048.b87023a4856ac4da5fccc9b82019d18a@haskell.org> Message-ID: <063.259c4900fb4f7a288add12f3274bef94@haskell.org> #12928: Too easy to trigger CUSK condition using TH -------------------------------------+------------------------------------- Reporter: int-index | Owner: Type: feature request | Status: new Priority: high | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => TypeInType -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 19 15:22:31 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Dec 2016 15:22:31 -0000 Subject: [GHC] #13006: Possible program should type check but does not using Implicit Parameters and Vectors In-Reply-To: <046.d11a545658da6a3ca94932f012a2e6ea@haskell.org> References: <046.d11a545658da6a3ca94932f012a2e6ea@haskell.org> Message-ID: <061.57a7d85bba3ab279678f3fb867cbd3ef@haskell.org> #13006: Possible program should type check but does not using Implicit Parameters and Vectors -------------------------------------+------------------------------------- Reporter: clinton | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2-rc2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by clinton): Ah that makes sense presumably even injectivity won't help here as we can't derive `a ~ b` from `F a ~ F b`, even if F is injective yes? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 19 15:36:26 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Dec 2016 15:36:26 -0000 Subject: [GHC] #13007: ghc-options -threaded present but -N option unrecognised on ARM In-Reply-To: <043.e2df0643f8c5c18fcdd44872fd2d8ea9@haskell.org> References: <043.e2df0643f8c5c18fcdd44872fd2d8ea9@haskell.org> Message-ID: <058.80e2c5afe5f12b265f3e0a17ee7d7472@haskell.org> #13007: ghc-options -threaded present but -N option unrecognised on ARM -------------------------------------+------------------------------------- Reporter: tmpz | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Resolution: duplicate | Keywords: arm, | raspberrypi, raspbian, rts, | threaded Operating System: Linux | Architecture: arm Type of failure: Incorrect result | Test Case: at runtime | http://allocinit.io/haskell | /haskell-on-raspberry-pi-3/ Blocked By: | Blocking: Related Tickets: 12981 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => closed * resolution: => duplicate * related: => 12981 Comment: The threaded runtime is a different matter from supporting executing Haskell on multiple OS threads (SMP, or the -N option). Confusing I know! The build system was accidentally disabling SMP for all ARM builds, even when targeting a version of ARM that supports the atomic operations needed to support multiprocessing. Recently reported and fixed in #12981. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 19 15:49:34 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Dec 2016 15:49:34 -0000 Subject: [GHC] #13005: Mac OSX uses MAP_ANON in place of MAP_ANONYMOUS In-Reply-To: <046.d43a09b5f43348df6b22d776514a766b@haskell.org> References: <046.d43a09b5f43348df6b22d776514a766b@haskell.org> Message-ID: <061.a25bd555bcefefa8b3923cce1014de2e@haskell.org> #13005: Mac OSX uses MAP_ANON in place of MAP_ANONYMOUS -------------------------------------+------------------------------------- Reporter: gracjan | Owner: Type: bug | Status: patch Priority: high | Milestone: Component: Compiler | Version: 8.0.1 (Linking) | Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2881 Wiki Page: | -------------------------------------+------------------------------------- Changes (by gracjan): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 19 15:51:50 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Dec 2016 15:51:50 -0000 Subject: [GHC] #9509: No automatic specialization of inlinable imports in 7.8 In-Reply-To: <044.78a0dc81057ff6a68effbbb3815481da@haskell.org> References: <044.78a0dc81057ff6a68effbbb3815481da@haskell.org> Message-ID: <059.fff7bcf5eea4e33aa99c15e110dde28d@haskell.org> #9509: No automatic specialization of inlinable imports in 7.8 -------------------------------------+------------------------------------- Reporter: dolio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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: | -------------------------------------+------------------------------------- Comment (by simonpj): Nicolas I think you are spot on. I'll fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 19 15:54:05 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Dec 2016 15:54:05 -0000 Subject: [GHC] #11715: Constraint vs * In-Reply-To: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> References: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> Message-ID: <061.ef7c32316186b860cc3054c2cd93b41c@haskell.org> #11715: Constraint vs * -------------------------------------+------------------------------------- Reporter: bgamari | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Typeable, Resolution: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by simonpj: @@ -22,1 +22,3 @@ - See also #11621 + See also + * #11621 + * #12933 New description: I first noticed something was a bit odd with `Constraint` when chasing #11334. Consider this testcase (`-O0` is sufficient), {{{#!hs import Data.Typeable main = do print $ typeRep (Proxy :: Proxy Eq) print $ typeOf (Proxy :: Proxy Eq) }}} With `ghc-8.0` this will produce, {{{ Eq Proxy (* -> *) Eq }}} Notice the second line; GHC seems to be claiming that `Eq :: * -> *`, which is clearly nonsense. I believe this issue may be the cause of some of the testsuite failures that I'm seeing on #11011. Unfortunately I haven't the foggiest where this issue might originate. See also * #11621 * #12933 -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 19 15:56:53 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Dec 2016 15:56:53 -0000 Subject: [GHC] #12791: Superclass methods could be more aggressively specialised. In-Reply-To: <049.67ba67008b7e7aca654f97100047ee77@haskell.org> References: <049.67ba67008b7e7aca654f97100047ee77@haskell.org> Message-ID: <064.b9ec2121eb06a30c9ac6d4d85ef87b33@haskell.org> #12791: Superclass methods could be more aggressively specialised. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: danharaj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #5835 | Differential Rev(s): Phab:D2714 Wiki Page: | -------------------------------------+------------------------------------- Description changed by simonpj: @@ -48,0 +48,3 @@ + + See also + * #5835, which will be fixed when this one is fixed. New description: Say `R` is a superclass of `MR` but only uses one of the type variables. If this type variable is fixed then we know that we are going to use a specific instance for `R`. Thus, the optimiser *could* specialise all methods from the superclass at this point leading to better code. {{{#!hs {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE FlexibleContexts #-} module Foo where class R t => MR t m where push :: t -> m -> Int class R t where pull :: t -> Int --type MR2 t m = (R t, MR t m) instance MR Int Int where push = max instance R Int where pull = negate myf :: (MR Int a) => a -> Int -> Int myf _ = pull }}} To give a concrete example, `R` is a super class of `MR` but only mentions the first type variable. Thus when we fix it in `myf`, we could optimise the definition to `myf _ = negate` by inlining the class method. Reid points out that if you have a definition like {{{ data X = X f :: R X => Int -> Int f = pull }}} then the instance for `R X` could be provided by another module. However it is common to structure large applications with super class constraints so it would be desirable to do better. See also * #5835, which will be fixed when this one is fixed. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 19 16:23:38 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Dec 2016 16:23:38 -0000 Subject: [GHC] #12947: Core lint error In-Reply-To: <051.c8f6f90ba6faede01ce48237dc8657bf@haskell.org> References: <051.c8f6f90ba6faede01ce48237dc8657bf@haskell.org> Message-ID: <066.52a81c2272963c1537df7bacd1162f87@haskell.org> #12947: Core lint error -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Are you sure? I get {{{ simonpj at cam-05-unx:~/tmp$ ~/5builds/ghc-8.0-branch/inplace/bin/ghc-stage1 -c -dcore-lint T12947.hs -fdefer-typed-holes T12947.hs:16:14: error: • Couldn't match expected type ‘P m a’ with actual type ‘ContT r0 m0 a0’ • In the expression: ContT $ \ _ -> Fail.fail msg In an equation for ‘fail’: fail msg = ContT $ \ _ -> Fail.fail msg In the instance declaration for ‘Fail.MonadFail (P m)’ • Relevant bindings include fail :: String -> P m a (bound at T12947.hs:16:3) }}} Perhaps you meant `-fdefer-type-errors`? But then I get {{{ simonpj at cam-05-unx:~/tmp$ ~/5builds/ghc-8.0-branch/inplace/bin/ghc-stage1 -c -dcore-lint T12947.hs -fdefer-type-errors T12947.hs:9:10: warning: [-Wmissing-methods] • No explicit implementation for ‘fmap’ • In the instance declaration for ‘Functor (P m)’ T12947.hs:11:10: warning: [-Wmissing-methods] • No explicit implementation for ‘pure’ and ‘<*>’ • In the instance declaration for ‘Applicative (P m)’ T12947.hs:13:10: warning: [-Wmissing-methods] • No explicit implementation for ‘>>=’ • In the instance declaration for ‘Monad (P m)’ T12947.hs:16:14: warning: [-Wdeferred-type-errors] • Couldn't match expected type ‘P m a’ with actual type ‘ContT r0 m0 a0’ • In the expression: ContT $ \ _ -> Fail.fail msg In an equation for ‘fail’: fail msg = ContT $ \ _ -> Fail.fail msg In the instance declaration for ‘Fail.MonadFail (P m)’ • Relevant bindings include fail :: String -> P m a (bound at T12947.hs:16:3) }}} All of which looks fine to me. Maybe it's been fixed? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 19 16:23:46 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Dec 2016 16:23:46 -0000 Subject: [GHC] #13007: ghc-options -threaded present but -N option unrecognised on ARM In-Reply-To: <043.e2df0643f8c5c18fcdd44872fd2d8ea9@haskell.org> References: <043.e2df0643f8c5c18fcdd44872fd2d8ea9@haskell.org> Message-ID: <058.02bb187d940b2d75406f88ed929afda0@haskell.org> #13007: ghc-options -threaded present but -N option unrecognised on ARM -------------------------------------+------------------------------------- Reporter: tmpz | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Resolution: duplicate | Keywords: arm, | raspberrypi, raspbian, rts, | threaded Operating System: Linux | Architecture: arm Type of failure: Incorrect result | Test Case: at runtime | http://allocinit.io/haskell | /haskell-on-raspberry-pi-3/ Blocked By: | Blocking: Related Tickets: 12981 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tmpz): Thank you very much, I could not find the other ticket. Sorry for the duplicate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 19 16:33:26 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Dec 2016 16:33:26 -0000 Subject: [GHC] #12959: GHC doesn't warn about missing implementations for class methods beginning with an underscore In-Reply-To: <050.f1c049718f4b94fba939144b405d48bc@haskell.org> References: <050.f1c049718f4b94fba939144b405d48bc@haskell.org> Message-ID: <065.ad1178743b0a73ee5ff150eb06964e83@haskell.org> #12959: GHC doesn't warn about missing implementations for class methods beginning with an underscore -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: | warnings/minimal/WarnMinimal.hs Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2849 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => warnings/minimal/WarnMinimal.hs -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 19 16:34:16 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Dec 2016 16:34:16 -0000 Subject: [GHC] #12809: TYPE 'UnboxedTupleRep is still a lie In-Reply-To: <047.e76db1a74f10a41a50c71596cd333981@haskell.org> References: <047.e76db1a74f10a41a50c71596cd333981@haskell.org> Message-ID: <062.62706ce3e6ca7adb6cf210d37ce59c4e@haskell.org> #12809: TYPE 'UnboxedTupleRep is still a lie -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => LevityPolymorphism -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 19 17:42:57 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Dec 2016 17:42:57 -0000 Subject: [GHC] #13006: Possible program should type check but does not using Implicit Parameters and Vectors In-Reply-To: <046.d11a545658da6a3ca94932f012a2e6ea@haskell.org> References: <046.d11a545658da6a3ca94932f012a2e6ea@haskell.org> Message-ID: <061.8b8b26cd95e553c9ccac7fd6099dff36@haskell.org> #13006: Possible program should type check but does not using Implicit Parameters and Vectors -------------------------------------+------------------------------------- Reporter: clinton | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2-rc2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): On the contrary, if `F` is injective then we can indeed deduce `a ~ b` from `F a ~ F b`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 19 20:37:50 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Dec 2016 20:37:50 -0000 Subject: [GHC] #12045: Visible kind application In-Reply-To: <051.f572b464c11770181720f8a1a7ec05a5@haskell.org> References: <051.f572b464c11770181720f8a1a7ec05a5@haskell.org> Message-ID: <066.ab557d013acf14ef8de2a0937c728aa6@haskell.org> #12045: Visible kind application -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Iceland_jack Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | TypeApplications TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): ​Phab:D2216 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): https://ghc.haskell.org/trac/ghc/wiki/DependentHaskell/Phase1#Designquestions -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 19 20:43:43 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Dec 2016 20:43:43 -0000 Subject: [GHC] #12995: interpetBCO doesn't get stripped from executables In-Reply-To: <045.482eb25a92f705bed000e62a3990b26a@haskell.org> References: <045.482eb25a92f705bed000e62a3990b26a@haskell.org> Message-ID: <060.20dd32d27b5ce371cbe171a3494fa695@haskell.org> #12995: interpetBCO doesn't get stripped from executables -------------------------------------+------------------------------------- Reporter: olsner | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: footprint Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by olsner): Since the RTS is built with `-ffunction-sections` now, the code doesn't need to be moved to separate files. It should be enough to remove the function(s) from the call graph. But that in itself might be hard enough :) BCO-related code pops up in quite a few places - e.g. `stg_AP_*` checks the function type and invokes `stg_yield_to_interpreter` for the `ARG_BCO` case, so that would still keep the interpreter alive. The generated apply code from genapply also has calls directly to `stg_BCO` which just yields to the interpreter. `interpretBCO` is quite little code itself though, commenting out the call in `schedule` saved about 15kB. Not enough to motivate much effort at all really... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 19 22:40:28 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Dec 2016 22:40:28 -0000 Subject: [GHC] #11502: Scrutinize use of 'long' in rts/ In-Reply-To: <045.a2d5adf2c113bf5cbc484973798f0d81@haskell.org> References: <045.a2d5adf2c113bf5cbc484973798f0d81@haskell.org> Message-ID: <060.1dcc768254cb7f00467a4a323725e5d5@haskell.org> #11502: Scrutinize use of 'long' in rts/ -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by MarcelineVQ): * owner: MarcelineVQ => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 19 22:41:43 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Dec 2016 22:41:43 -0000 Subject: [GHC] #11522: maxStkSize can overflow In-Reply-To: <047.c682131ad79ad28d6b34355aabbd4286@haskell.org> References: <047.c682131ad79ad28d6b34355aabbd4286@haskell.org> Message-ID: <062.6bcbbc161d2073c520b307acd1dce361@haskell.org> #11522: maxStkSize can overflow -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1895 Wiki Page: | -------------------------------------+------------------------------------- Changes (by MarcelineVQ): * owner: MarcelineVQ => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 19 22:52:48 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Dec 2016 22:52:48 -0000 Subject: [GHC] #11822: Pattern match checker exceeded (2000000) iterations In-Reply-To: <049.f2a29571b162949a036aa4b2a361c7f6@haskell.org> References: <049.f2a29571b162949a036aa4b2a361c7f6@haskell.org> Message-ID: <064.e790fb266b7e18cc2f7f71f43e5b606f@haskell.org> #11822: Pattern match checker exceeded (2000000) iterations -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: gkaracha Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc3 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Starting next week I will start spending time on it to see what can be done. George, how's it going? I've just noticed that in the compiler itself `PrelRules.hs` doesn't currently blow the limit, but the changes in [Phab:D2858] require `-fmax- pmcheck-iterations=6000000`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 19 23:19:07 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Dec 2016 23:19:07 -0000 Subject: [GHC] #13004: Timeout no longer kills processes on timeout In-Reply-To: <044.a6877c959d19da5e9ab8a3dcab34e50f@haskell.org> References: <044.a6877c959d19da5e9ab8a3dcab34e50f@haskell.org> Message-ID: <059.f5737d8c388826342dbf0c9e4e32b7ad@haskell.org> #13004: Timeout no longer kills processes on timeout -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Test Suite | Version: 8.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2880 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Tamar Christina ): In [changeset:"6263e1079a2d203fbd2e668ca99c0e901fcd1548/ghc" 6263e107/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6263e1079a2d203fbd2e668ca99c0e901fcd1548" Fix timeout's timeout on Windows Summary: Timeout has been broken by my previous patch. The timeout event was not being processed correctly, as such hanging processes would not be killed as they should have been. This corrects it. Test Plan: ./validate ~/ghc/testsuite/timeout/install-inplace/bin/timeout.exe 10 "sleep 10000s" Reviewers: austin, RyanGlScott, bgamari Reviewed By: bgamari Subscribers: thomie, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D2880 GHC Trac Issues: #13004 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 19 23:22:49 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Dec 2016 23:22:49 -0000 Subject: [GHC] #13004: Timeout no longer kills processes on timeout In-Reply-To: <044.a6877c959d19da5e9ab8a3dcab34e50f@haskell.org> References: <044.a6877c959d19da5e9ab8a3dcab34e50f@haskell.org> Message-ID: <059.eba5297f8ed69cefb7055f6ffad718af@haskell.org> #13004: Timeout no longer kills processes on timeout -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Test Suite | Version: 8.1 Resolution: fixed | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2880 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 19 23:30:39 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Dec 2016 23:30:39 -0000 Subject: [GHC] #12965: String merging broken on Windows In-Reply-To: <046.4ab9842a6728ed7002fe72135f75869e@haskell.org> References: <046.4ab9842a6728ed7002fe72135f75869e@haskell.org> Message-ID: <061.4f31295b81e59aa5e571c113fd811e00@haskell.org> #12965: String merging broken on Windows ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by Phyx-): Constant merging was disabled on Windows by a stupid check that was introduced late in GCC6. https://github.com/gcc- mirror/gcc/blob/gcc-6-branch/gcc/configure.ac#L2928 The check essentially ensures that only ELF platform support that flag. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 19 23:39:38 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Dec 2016 23:39:38 -0000 Subject: [GHC] #12983: Loading temp shared object failed: TemplateHaskell and recompilation In-Reply-To: <049.2c68231d33bee80b5ff9e32f112656cd@haskell.org> References: <049.2c68231d33bee80b5ff9e32f112656cd@haskell.org> Message-ID: <064.914ded23c44da12091bdaf83f2a3be23@haskell.org> #12983: Loading temp shared object failed: TemplateHaskell and recompilation -------------------------------------+------------------------------------- Reporter: StefanWehr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: template | haskell, recompilation Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dleuschner): * cc: dleuschner (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 19 23:46:29 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Dec 2016 23:46:29 -0000 Subject: [GHC] #7325: threadDelay mistreats minBound and maxBound in some configurations In-Reply-To: <048.f6376e5e233d59dcc7fd251637dbe84b@haskell.org> References: <048.f6376e5e233d59dcc7fd251637dbe84b@haskell.org> Message-ID: <063.7ecd1eb984de5e162d6db0aaa7825989@haskell.org> #7325: threadDelay mistreats minBound and maxBound in some configurations -------------------------------------+------------------------------------- Reporter: joeyadams | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Runtime System | Version: 7.6.1 Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Incorrect result | Test Case: at runtime | base/tests/T8089 Blocked By: | Blocking: Related Tickets: #9722 | Differential Rev(s): Phab:D2861 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"c0c1f801f4ca26f1db68ac527341a1cf051cb7d6/ghc" c0c1f801/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c0c1f801f4ca26f1db68ac527341a1cf051cb7d6" Mark T8089 as unbroken since #7325 is now resolved }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 20 00:19:30 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Dec 2016 00:19:30 -0000 Subject: [GHC] #12996: Memory leak in recursion when switching from -O1 to -O2 In-Reply-To: <047.d6ab448efd91a6aa33b2e8a0065bc482@haskell.org> References: <047.d6ab448efd91a6aa33b2e8a0065bc482@haskell.org> Message-ID: <062.252b97f7882356e2670cbcea802c4113@haskell.org> #12996: Memory leak in recursion when switching from -O1 to -O2 -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Memory leak, | optimization 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: | -------------------------------------+------------------------------------- Comment (by simonpj): This turns out to be an example of #11731. It turns out that the thunk for `cycleState state` is wrongly marked "used-once", and that's why there's a massive slow-down. (Each iteration evaluates it twice, so it goes exponential.) The patch for #11731 fixes it, but it never made it into GHC 8.0. I'll mark it thus in case we ship 8.0.3. It really is quite a serious bug. I'll make this bug into a test case. Meanwhile: > Demand analyzer thinks appLoop is not strict on s. It looks strict, but the demand analyser has a hack for I/O: earlier operations migth throw an exception, and so we treat them as lazy in their continuation. See `Note [IO hack in the demand analyser]` in `DmdAnal`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 20 00:20:11 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Dec 2016 00:20:11 -0000 Subject: [GHC] #11731: Simplifier: Inlining trivial let can lose sharing In-Reply-To: <046.a5918d80f4707137661067c33245f819@haskell.org> References: <046.a5918d80f4707137661067c33245f819@haskell.org> Message-ID: <061.f235fd68a3bbf6785075a468d93a00e6@haskell.org> #11731: Simplifier: Inlining trivial let can lose sharing -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.3 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2073 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: closed => merge * milestone: => 8.0.3 Comment: This patch should go into 8.0.3. See #12996. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 20 00:23:23 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Dec 2016 00:23:23 -0000 Subject: [GHC] #10946: Typed hole inside typed Template Haskell bracket causes panic In-Reply-To: <048.bb931422119631f05ab09abe14bd4c46@haskell.org> References: <048.bb931422119631f05ab09abe14bd4c46@haskell.org> Message-ID: <063.f7f264f3826d33d5503ebbeceb2c7e49@haskell.org> #10946: Typed hole inside typed Template Haskell bracket causes panic -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: th/T10946 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.4.1 Comment: It looks like this won't happen for 8.2 either. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 20 00:23:46 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Dec 2016 00:23:46 -0000 Subject: [GHC] #5775: Inconsistency in demand analysis In-Reply-To: <041.59a17f321cd8e5e5a5552bb1b43821e2@haskell.org> References: <041.59a17f321cd8e5e5a5552bb1b43821e2@haskell.org> Message-ID: <056.10e8937416facbca6af2744093bcb31a@haskell.org> #5775: Inconsistency in demand analysis -------------------------------------+------------------------------------- Reporter: rl | Owner: Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 7.5 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.2.1 => 8.4.1 Comment: Bumping off to 8.4 due to lack of owner. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 20 00:35:49 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Dec 2016 00:35:49 -0000 Subject: [GHC] #13008: Cleanup backwards compatibility ifdefs due to stage1 external interpreter work Message-ID: <045.2ac2011cab453571e7594dd8ee92efe0@haskell.org> #13008: Cleanup backwards compatibility ifdefs due to stage1 external interpreter work -------------------------------------+------------------------------------- Reporter: shlevy | Owner: Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- https://phabricator.haskell.org/D2826 and https://phabricator.haskell.org/D2884 make some code paths that were incompatible with GHC 7.10.x newly built by the stage0 compiler, requiring some CPP hackery to keep our compatibility guarantees. When we can drop that dependency, we should be sure to remove the old code paths. Specifically, the checks for MIN_VERSION_base(4,9,0) and MIN_VERSION_process(1,4,2) can be removed once we're able to assume ghc 8.0.x as stage0. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 20 00:35:57 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Dec 2016 00:35:57 -0000 Subject: [GHC] #13009: Hierarchical Module Structure for GHC Message-ID: <045.859215149771e4346ac45f933feca22e@haskell.org> #13009: Hierarchical Module Structure for GHC -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: | ModuleDependencies/Hierarchical -------------------------------------+------------------------------------- Currently GHC's modules are not hierarchical and have very short cryptic names. I would like to revive this 8-year old proposal: https://ghc.haskell.org/trac/ghc/wiki/ModuleDependencies/Hierarchical Pros: * cleaner code base and overall code structure easier to grasp * better integration with other packages when using GHC API * better documentation (cf https://www.stackage.org/lts-7.14/package/ghc-8.0.1) Cons: * break the GHC (plugin) API * may make "rebase" harder during the transition period -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 20 00:40:19 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Dec 2016 00:40:19 -0000 Subject: [GHC] #10053: Regression on MacOS platform, error in ghci calling main after loading compiled code: "Too late for parseStaticFlags..." In-Reply-To: <045.7defde488a4af19895968f8c8b9b5f95@haskell.org> References: <045.7defde488a4af19895968f8c8b9b5f95@haskell.org> Message-ID: <060.97369632b15ef93d75a8215f2bcc0040@haskell.org> #10053: Regression on MacOS platform, error in ghci calling main after loading compiled code: "Too late for parseStaticFlags..." -------------------------------------+------------------------------------- Reporter: George | Owner: Type: bug | Status: patch Priority: low | Milestone: 8.2.1 Component: GHCi | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2839 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D2839 * milestone: => 8.2.1 Comment: I suspect this will actually be fixed by Phab:D2839. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 20 00:43:57 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Dec 2016 00:43:57 -0000 Subject: [GHC] #12564: Type family in type pattern kind In-Reply-To: <048.93ccdd84c715d6e667e14d904b8a963f@haskell.org> References: <048.93ccdd84c715d6e667e14d904b8a963f@haskell.org> Message-ID: <063.2d0320b3c6b05f65a5850080cab9a823@haskell.org> #12564: Type family in type pattern kind -------------------------------------+------------------------------------- Reporter: int-index | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: TypeInType, Resolution: | TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.4.1 Comment: In that case I'll bump this off to 8.4. Do feel free to bump it back if things change, however. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 20 00:45:08 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Dec 2016 00:45:08 -0000 Subject: [GHC] #12437: 20% regression in max_bytes_used for T1969 In-Reply-To: <047.090b2624111211cac9a272929b897b02@haskell.org> References: <047.090b2624111211cac9a272929b897b02@haskell.org> Message-ID: <062.dffb10597917b35e33567715ac8945f4@haskell.org> #12437: 20% regression in max_bytes_used for T1969 -------------------------------------+------------------------------------- Reporter: simonmar | Owner: osa1 Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): osa1, what do you think should happen to this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 20 00:46:31 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Dec 2016 00:46:31 -0000 Subject: [GHC] #8281: The impossible happened: primRepToFFIType In-Reply-To: <044.47e20917996e473150de04c1ce1afc0b@haskell.org> References: <044.47e20917996e473150de04c1ce1afc0b@haskell.org> Message-ID: <059.e61d58cc522296dd3527f135e20167bd@haskell.org> #8281: The impossible happened: primRepToFFIType -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.4.1 Comment: Nor will this happen for 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 20 00:46:43 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Dec 2016 00:46:43 -0000 Subject: [GHC] #7298: GHCi is setting stdin/stdout to NoBuffering in runghc when DYNAMIC_GHC_PROGRAMS=YES In-Reply-To: <044.34213a5738911dce009c62eab496ee22@haskell.org> References: <044.34213a5738911dce009c62eab496ee22@haskell.org> Message-ID: <059.ec0b9f26765df2514c5dd8bfe6c4f33c@haskell.org> #7298: GHCi is setting stdin/stdout to NoBuffering in runghc when DYNAMIC_GHC_PROGRAMS=YES -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: high | Milestone: Component: GHCi | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | ghc-e/should_run/T2228 Blocked By: | Blocking: Related Tickets: #2228 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => Comment: This is still not fixed, it seems like no one is terribly eager to see it fixed, and the fix won't be terrible simple. Consequently I'm going to un- milestone this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 20 00:49:53 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Dec 2016 00:49:53 -0000 Subject: [GHC] #11261: Implement DWARF debugging on powerpc64 In-Reply-To: <047.fcb308b656617448e39264eeafa29658@haskell.org> References: <047.fcb308b656617448e39264eeafa29658@haskell.org> Message-ID: <062.5dacd37dc49afcdfa0e0fcdcdd92fcb2@haskell.org> #11261: Implement DWARF debugging on powerpc64 -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 7.11 (CodeGen) | Resolution: | Keywords: Operating System: Linux | Architecture: powerpc64 Type of failure: Incorrect result | Test Case: debug, T10667 at runtime | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.4.1 Comment: It seems unlikely that this will happen for 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 20 00:57:26 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Dec 2016 00:57:26 -0000 Subject: [GHC] #12965: String merging broken on Windows In-Reply-To: <046.4ab9842a6728ed7002fe72135f75869e@haskell.org> References: <046.4ab9842a6728ed7002fe72135f75869e@haskell.org> Message-ID: <061.c72f37ef41357c87972e15a090349797@haskell.org> #12965: String merging broken on Windows ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: upstream Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by bgamari): * status: new => upstream Comment: Do you know when can we expect a fixed GCC release, Phyx? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 20 01:11:57 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Dec 2016 01:11:57 -0000 Subject: [GHC] #12965: String merging broken on Windows In-Reply-To: <046.4ab9842a6728ed7002fe72135f75869e@haskell.org> References: <046.4ab9842a6728ed7002fe72135f75869e@haskell.org> Message-ID: <061.53d1f00c9cba0c92f96465b0284f6a87@haskell.org> #12965: String merging broken on Windows ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: upstream Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.4.1 Comment: Bumping off to 8.4 since we really can't do anything about this ourselves anyways. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 20 01:13:14 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Dec 2016 01:13:14 -0000 Subject: [GHC] #10506: SourceNotes are not applied to all identifiers In-Reply-To: <049.4498c09b08bd56b963d5dfbd770a867b@haskell.org> References: <049.4498c09b08bd56b963d5dfbd770a867b@haskell.org> Message-ID: <064.a286fa61ecf74301944240c2af03e71a@haskell.org> #10506: SourceNotes are not applied to all identifiers -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1565 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => new * milestone: 8.2.1 => 8.4.1 Comment: Alright, then I'm going to bump this off to 8.4 since the hour is late and there is no obvious solution in sight. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 20 01:13:20 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Dec 2016 01:13:20 -0000 Subject: [GHC] #12965: String merging broken on Windows In-Reply-To: <046.4ab9842a6728ed7002fe72135f75869e@haskell.org> References: <046.4ab9842a6728ed7002fe72135f75869e@haskell.org> Message-ID: <061.4fdaeb77d30883f5eb0f243a2e627015@haskell.org> #12965: String merging broken on Windows ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: upstream Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by Phyx-): * milestone: 8.4.1 => 8.2.1 Comment: I've worked out the changes required for this on `GCC`, but `binutils` may need a patch as well. The one for `GCC` I might be able to get away with as a bugfix, but the `binutils` one... If I'm able to fix them then I can ask the mingw-w64 guys for another patch release. So we don't have to wait for a release. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 20 01:13:36 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Dec 2016 01:13:36 -0000 Subject: [GHC] #12356: StaticPointers support in GHCi In-Reply-To: <046.4add1b1a872a2608a03a4c2efa3faa77@haskell.org> References: <046.4add1b1a872a2608a03a4c2efa3faa77@haskell.org> Message-ID: <061.3dc95d51c386f7ae29312b1b707f462a@haskell.org> #12356: StaticPointers support in GHCi -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: feature request | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12000, #9878 | Differential Rev(s): Phab:D2504 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: => bgamari -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 20 01:14:06 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Dec 2016 01:14:06 -0000 Subject: [GHC] #12965: String merging broken on Windows In-Reply-To: <046.4ab9842a6728ed7002fe72135f75869e@haskell.org> References: <046.4ab9842a6728ed7002fe72135f75869e@haskell.org> Message-ID: <061.a5ab55dc2915d8dc14f86117a5a8203a@haskell.org> #12965: String merging broken on Windows ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: upstream Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by Phyx-): * milestone: 8.2.1 => 8.4.1 Comment: hmm trac had a mind of it's own. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 20 01:14:24 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Dec 2016 01:14:24 -0000 Subject: [GHC] #11011: Add type-indexed type representations (`TypeRep a`) In-Reply-To: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> References: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> Message-ID: <062.94a28341450e759f4ab525e2793a62d9@haskell.org> #11011: Add type-indexed type representations (`TypeRep a`) -------------------------------------+------------------------------------- Reporter: bjmprice | Owner: bgamari Type: feature request | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2010 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: => bgamari Comment: I'm still working on this here and there but suffering from a severe lack of time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 20 01:15:02 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Dec 2016 01:15:02 -0000 Subject: [GHC] #9370: unfolding info as seen when building a module depends on flags in a previously-compiled module In-Reply-To: <045.e2e9bbeb8a2151371c0306e4a7b88a0a@haskell.org> References: <045.e2e9bbeb8a2151371c0306e4a7b88a0a@haskell.org> Message-ID: <060.9e86f5897e1114244e7a481d9352bb89@haskell.org> #9370: unfolding info as seen when building a module depends on flags in a previously-compiled module -------------------------------------+------------------------------------- Reporter: carter | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: newcomer, | Inlining Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8635 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: => bgamari Comment: I have an in-flight patch for this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 20 01:15:39 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Dec 2016 01:15:39 -0000 Subject: [GHC] #9630: compile-time performance regression (probably due to Generics) In-Reply-To: <042.a529e5f70870528e7f8796a28ce82a84@haskell.org> References: <042.a529e5f70870528e7f8796a28ce82a84@haskell.org> Message-ID: <057.a62080c9df71484b96dc88e5b81f9941@haskell.org> #9630: compile-time performance regression (probably due to Generics) -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: deriving- | perf, Generics Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9583, #10293 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.4.1 Comment: Sadly we seem to have lost steam on this. Bumping off to 8.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 20 01:17:22 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Dec 2016 01:17:22 -0000 Subject: [GHC] #11568: Regression in nofib/shootout/k-nucleotide In-Reply-To: <047.d9404b64e39ef5028df3b630d601b854@haskell.org> References: <047.d9404b64e39ef5028df3b630d601b854@haskell.org> Message-ID: <062.6871ffd4842cdd141b1c882237db8c17@haskell.org> #11568: Regression in nofib/shootout/k-nucleotide -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.10.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): * failure: None/Unknown => Runtime performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 20 01:18:09 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Dec 2016 01:18:09 -0000 Subject: [GHC] #12088: Type/data family instances in kind checking In-Reply-To: <048.155fdb7e7ce6e09c92258c376a6950ab@haskell.org> References: <048.155fdb7e7ce6e09c92258c376a6950ab@haskell.org> Message-ID: <063.8aec6646edd46aafb44bc22939eaa8ec@haskell.org> #12088: Type/data family instances in kind checking -------------------------------------+------------------------------------- Reporter: alexvieth | Owner: Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #11348, #12239 | Differential Rev(s): Phab:D2272 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.4.1 Comment: This sounds like something that will not be happening for 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 20 01:23:24 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Dec 2016 01:23:24 -0000 Subject: [GHC] #10915: Statistical profiling support in the RTS In-Reply-To: <046.7220ccda33e87c4faaaf43cf13abd1b6@haskell.org> References: <046.7220ccda33e87c4faaaf43cf13abd1b6@haskell.org> Message-ID: <061.70154571c60648776c1351ac8f440c3b@haskell.org> #10915: Statistical profiling support in the RTS -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: feature request | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1215, Wiki Page: | Phab:D1214 -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.4.1 Comment: While DWARF support will be much better in 8.2, I don't think I'll have time to get my statistical profiling work into shape as well. Bumping to 8.4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 20 01:23:30 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Dec 2016 01:23:30 -0000 Subject: [GHC] #10915: Statistical profiling support in the RTS In-Reply-To: <046.7220ccda33e87c4faaaf43cf13abd1b6@haskell.org> References: <046.7220ccda33e87c4faaaf43cf13abd1b6@haskell.org> Message-ID: <061.7b3e9f1a1c6dc6646c6b5077f3f8ada4@haskell.org> #10915: Statistical profiling support in the RTS -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: feature request | Status: patch Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1215, Wiki Page: | Phab:D1214 -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 20 01:24:43 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Dec 2016 01:24:43 -0000 Subject: [GHC] #11598: Cache coercion kinds and roles In-Reply-To: <047.56bbfff0d86db02c37b25ddc698d48a1@haskell.org> References: <047.56bbfff0d86db02c37b25ddc698d48a1@haskell.org> Message-ID: <062.4adec0432f968b2dfa97f11b7bf011a5@haskell.org> #11598: Cache coercion kinds and roles -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8095 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * type: bug => task * milestone: 8.2.1 => Comment: Richard, what do we want to do about this? It sounds like this approach didn't really work out. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 20 01:25:55 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Dec 2016 01:25:55 -0000 Subject: [GHC] #13008: Cleanup backwards compatibility ifdefs due to stage1 external interpreter work In-Reply-To: <045.2ac2011cab453571e7594dd8ee92efe0@haskell.org> References: <045.2ac2011cab453571e7594dd8ee92efe0@haskell.org> Message-ID: <060.7f0610f32ef2d3ae2affd4725405eee9@haskell.org> #13008: Cleanup backwards compatibility ifdefs due to stage1 external interpreter work -------------------------------------+------------------------------------- Reporter: shlevy | Owner: Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Tamar Christina ): In [changeset:"27f79255634d9789f367273504545c1ebfad90a0/ghc" 27f79255/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="27f79255634d9789f367273504545c1ebfad90a0" Allow use of the external interpreter in stage1. Summary: Now that we have -fexternal-interpreter, we can lose most of the GHCI ifdefs. This was originally added in https://phabricator.haskell.org/D2826 but that led to a compatibility issue with ghc 7.10.x on Windows. That's fixed here and the revert reverted. Reviewers: goldfire, hvr, austin, bgamari, Phyx Reviewed By: Phyx Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2884 GHC Trac Issues: #13008 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 20 01:26:18 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Dec 2016 01:26:18 -0000 Subject: [GHC] #12218: Implement -fexternal-interpreter via static linking In-Reply-To: <047.d2ead1284e240e7bcc878975afeb5ae1@haskell.org> References: <047.d2ead1284e240e7bcc878975afeb5ae1@haskell.org> Message-ID: <062.717d4ef8a03b8fa38dc0952f91374cf8@haskell.org> #12218: Implement -fexternal-interpreter via static linking -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.4.1 @@ -3,1 +3,1 @@ - iconv binary, and use that as our external interpreter. + `iserv` binary, and use that as our external interpreter. New description: An interesting idea from @hvr. When using `-fexternal-interpreter`, we can statically link the required packages and object files into a new `iserv` binary, and use that as our external interpreter. This would mean we could support TH and even limited GHCi without needing a dynamic linker of any kind, which is extremely cool. Apparently this would be useful for AIX where doing dynamic linking is hard. -- Comment: It doesn't look like this will happen for 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 20 01:34:02 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Dec 2016 01:34:02 -0000 Subject: [GHC] #13006: Possible program should type check but does not using Implicit Parameters and Vectors In-Reply-To: <046.d11a545658da6a3ca94932f012a2e6ea@haskell.org> References: <046.d11a545658da6a3ca94932f012a2e6ea@haskell.org> Message-ID: <061.3e6b795dcb0de829a9dfafbef77c5c40@haskell.org> #13006: Possible program should type check but does not using Implicit Parameters and Vectors -------------------------------------+------------------------------------- Reporter: clinton | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2-rc2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by clinton): @simonpj: I'm not sure if I should put in a separate bug report or if I'm completely confused, but when I compile the following: {{{#!hs {-# LANGUAGE TypeFamilyDependencies #-} type family F x = t | t -> x myId :: (F a ~ F b) => a -> b myId = id main = pure () }}} I get the error: {{{ Could not deduce: a ~ b from the context: F a ~ F b }}} Isn't this what ticket #10833 discusses, namely that GHC does not derive `a ~ b` from `F a ~ F b`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 20 03:47:24 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Dec 2016 03:47:24 -0000 Subject: [GHC] #13010: module imports form a cycle instead of failing to parse Message-ID: <050.51acf3f724603f8b15d59c42a9741908@haskell.org> #13010: module imports form a cycle instead of failing to parse -------------------------------------+------------------------------------- Reporter: MarcelineVQ | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Some issue of parsing is causing certain module imports not to respect the proper format for a module name: `modid → {conid .} conid (modules)` A module import ending in numbers or a dot may be treated as if the . or . weren't there. I would expect these to be parse errors instead of falling back to their 'parent', that's surely vague so here's examples. Minimally: `echo "module Lib where import Lib. " > test.hs && ghc test.hs` `echo "module Lib where import Lib.123 " > test.hs && ghc test.hs` Will both result in: {{{ Module imports form a cycle: module ‘Lib’ (test.hs) imports itself }}} This is an error because it's not importing itself, it's importing Lib. or Lib.123 which are invalid module names. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 20 08:44:32 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Dec 2016 08:44:32 -0000 Subject: [GHC] #13009: Hierarchical Module Structure for GHC In-Reply-To: <045.859215149771e4346ac45f933feca22e@haskell.org> References: <045.859215149771e4346ac45f933feca22e@haskell.org> Message-ID: <060.bab422e78f06d45afca16d31767a4bde@haskell.org> #13009: Hierarchical Module Structure for GHC -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ModuleDependencies/Hierarchical | -------------------------------------+------------------------------------- Comment (by simonpj): I'm not against this. Why will it make "better integration" with other packages? I think by "better documentation" you perhaps mean "easier to navigate". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 20 08:56:29 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Dec 2016 08:56:29 -0000 Subject: [GHC] #13006: Possible program should type check but does not using Implicit Parameters and Vectors In-Reply-To: <046.d11a545658da6a3ca94932f012a2e6ea@haskell.org> References: <046.d11a545658da6a3ca94932f012a2e6ea@haskell.org> Message-ID: <061.64f3bd298867fa2fe91a83125c9e8dbc@haskell.org> #13006: Possible program should type check but does not using Implicit Parameters and Vectors -------------------------------------+------------------------------------- Reporter: clinton | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.2-rc2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): It depends what you mean by "derive". Injectivity gives rise to so-called "Derived equalities" which guide unification (often called "improvement"). They do not provide ''evidence'' in the sense of System FC. So, with your type family {{{ f :: F a -> F a f x = x }}} would not be reported as an ambiguous type; without the injectivity constraint it would. I wish there was a comprehensive writeup about this... it's too much folk lore. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 20 09:11:01 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Dec 2016 09:11:01 -0000 Subject: [GHC] #13009: Hierarchical Module Structure for GHC In-Reply-To: <045.859215149771e4346ac45f933feca22e@haskell.org> References: <045.859215149771e4346ac45f933feca22e@haskell.org> Message-ID: <060.487a129f3cc515bc78ea837934139423@haskell.org> #13009: Hierarchical Module Structure for GHC -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ModuleDependencies/Hierarchical | -------------------------------------+------------------------------------- Comment (by hsyl20): Replying to [comment:1 simonpj]: > Why will it make "better integration" with other packages? Because most other multi-module packages don't put modules directly in the "root namespace". It feels a little bit unusual that GHC modules in an import list don't share a common prefix (especially for utility modules like FastString whose package is not obvious). > I think by "better documentation" you perhaps mean "easier to navigate". Yes indeed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 20 10:35:28 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Dec 2016 10:35:28 -0000 Subject: [GHC] #12996: Memory leak in recursion when switching from -O1 to -O2 In-Reply-To: <047.d6ab448efd91a6aa33b2e8a0065bc482@haskell.org> References: <047.d6ab448efd91a6aa33b2e8a0065bc482@haskell.org> Message-ID: <062.9b0eb1c1c1fb3bb6017549fa23065b7c@haskell.org> #12996: Memory leak in recursion when switching from -O1 to -O2 -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Memory leak, | optimization 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: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"4535fa2646fb0df753165ecbad25be53318ec123/ghc" 4535fa2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4535fa2646fb0df753165ecbad25be53318ec123" Test Trac #12996 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 20 10:42:42 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Dec 2016 10:42:42 -0000 Subject: [GHC] #12996: Memory leak in recursion when switching from -O1 to -O2 In-Reply-To: <047.d6ab448efd91a6aa33b2e8a0065bc482@haskell.org> References: <047.d6ab448efd91a6aa33b2e8a0065bc482@haskell.org> Message-ID: <062.2bf9c39dd729950ef8717c95e91d6361@haskell.org> #12996: Memory leak in recursion when switching from -O1 to -O2 -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Memory leak, | optimization Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | testsuite/tests/perf/should_run/T12996 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => testsuite/tests/perf/should_run/T12996 * resolution: => fixed Comment: Thank you AndreasK. It's hard to tickle this bug, but when tickled it can make things exponentially expensive as you discovered. Thanks for the nice test case. I'll close this, leaving #11731 open so that we remember to merge to 8.0.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 20 10:46:29 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Dec 2016 10:46:29 -0000 Subject: [GHC] #12949: Pattern coverage mistake In-Reply-To: <045.3db1ccae2330725ee6ce9cf1d67c2922@haskell.org> References: <045.3db1ccae2330725ee6ce9cf1d67c2922@haskell.org> Message-ID: <060.8e59055603ed279e03cd68d005249478@haskell.org> #12949: Pattern coverage mistake -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: gkaracha Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by gkaracha): Replying to [comment:1 dfeuer]: > Note that everything works as expected if I pass in the `Boolly` values explicitly. Perhaps the pattern coverage checker is confusing `knownBool` called at different types? Indeed you are right, this is not a bug in the type constraints that the checker generates but the term constraints. I expected the `knownBool`s to be already desugared to `(knownBool $dKnownBool_a)` and `(knownBool $dKnownBool_b)` since they are overloaded but I was mistaken. Hence, it now (wrongly) generates `{knownBool ~ Falsey, knownBool ~ Truey}` which is of course unsatisfiable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 20 10:57:42 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Dec 2016 10:57:42 -0000 Subject: [GHC] #12989: ($) can have a more general type In-Reply-To: <045.48fb17a262faf4da952ae03116f5bd7c@haskell.org> References: <045.48fb17a262faf4da952ae03116f5bd7c@haskell.org> Message-ID: <060.871ef94c8c68534a7e2313f0ac7927ce@haskell.org> #12989: ($) can have a more general type -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => LevityPolymorphism Comment: Worth reading our [https://www.microsoft.com/en-us/research/publication /levity-polymorphism/ levity polymorphism paper]. `good` is OK because no value of type `a` is manipulated by the code for `good` (see the paper). NB: care is needed during optimisation: eta expansion (to get `bad`) is not allowed. So, yes, perhaps `($)` could be defied like `good`, as an arity-1 function. Then it could have the more generous type. I'll add this to the levity-polymorphism pile; see [wiki:LevityPolymorphism] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 20 11:09:55 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Dec 2016 11:09:55 -0000 Subject: [GHC] #12949: Pattern coverage mistake In-Reply-To: <045.3db1ccae2330725ee6ce9cf1d67c2922@haskell.org> References: <045.3db1ccae2330725ee6ce9cf1d67c2922@haskell.org> Message-ID: <060.39768a253feb264da9884c786395b47f@haskell.org> #12949: Pattern coverage mistake -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: gkaracha Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by gkaracha): I guess I could fix this by - Turning `Name` back into `Id` in the checker (incl. the term oracle) - Checking equality on term variables taking their type into account, something like this: {{{#!hs tmEqVar :: Id -> Id -> Bool tmEqVar x1 x2 = (idName x1 == idName x2) && (idType x1 `eqType` idType x2) }}} Does that make sense? PS. I am not happy to have types in the term oracle (it's not as modular as I liked it to be) but I don't know of any other way to "restore" the implicit invariant that each variable has only **one type**. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 20 11:13:30 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Dec 2016 11:13:30 -0000 Subject: [GHC] #12990: Partially applied constructors with unpacked fields simplified badly In-Reply-To: <045.525d0610bc9f5daed2ba04304bf44d04@haskell.org> References: <045.525d0610bc9f5daed2ba04304bf44d04@haskell.org> Message-ID: <060.4e7aba44a79ec3f6061d3d43328581a8@haskell.org> #12990: Partially applied constructors with unpacked fields simplified badly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 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: | -------------------------------------+------------------------------------- Comment (by simonpj): In `MkId` line 511 we have {{{ wrap_unf = mkInlineUnfolding (Just wrap_arity) wrap_rhs }}} The `Just wrap_arity` is what prevents GHC inlining the wrapper until it is saturated. Change it to `Nothing` to allow a partially-applied wrapper to inline. Worth a try. I doubt it'd have any bad effects. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 20 11:32:17 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Dec 2016 11:32:17 -0000 Subject: [GHC] #12990: Partially applied constructors with unpacked fields simplified badly In-Reply-To: <045.525d0610bc9f5daed2ba04304bf44d04@haskell.org> References: <045.525d0610bc9f5daed2ba04304bf44d04@haskell.org> Message-ID: <060.929f9db14d8ca5e2ea2218fc85c84837@haskell.org> #12990: Partially applied constructors with unpacked fields simplified badly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Inlining 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 mpickering): * keywords: => Inlining -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 20 11:59:55 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Dec 2016 11:59:55 -0000 Subject: [GHC] #12985: GHCi incorrectly reports the kind of unboxed tuples spliced in from Template Haskell In-Reply-To: <050.ad0392c4ae751e995d3259a41b13bc35@haskell.org> References: <050.ad0392c4ae751e995d3259a41b13bc35@haskell.org> Message-ID: <065.f396b19dfada08f6c26e8f2a9a30c95d@haskell.org> #12985: GHCi incorrectly reports the kind of unboxed tuples spliced in from Template Haskell -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.2 Component: Template Haskell | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #12976 | Differential Rev(s): Phab:D2886 Wiki Page: | -------------------------------------+------------------------------------- Changes (by facundo.dominguez): * status: new => patch * cc: bgamari (added) * differential: => Phab:D2886 * milestone: => 8.0.2 Comment: That patch is particularly fragile with functions which have a default case which doesn't fail. {{{ f :: HsType name -> ... f (HsTyVar ...) = f (HsAppTy ...) = f _ = do not fail and continue }}} As the patch introduces a new case to all functions traversing types between renaming and typechecking, functions in the style of `f` make the omissions have surprising effects, of which this ticket was an instance. I submitted a fixup to phabricator. bgamari, this patch would have low risk to include in GHC 8.0.2 I think. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 20 12:04:05 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Dec 2016 12:04:05 -0000 Subject: [GHC] #13011: Simplifier ticks exhausted: a 10-line case Message-ID: <052.bf42032c1e22b5cab8fc1d52eefb6688@haskell.org> #13011: Simplifier ticks exhausted: a 10-line case -------------------------------------+------------------------------------- Reporter: L.K.Rebellion | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 Keywords: Simplifier | Operating System: Linux ticks exhausted | Type of failure: Compile-time Architecture: x86 | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: #8319 #12776 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I was trying to define a function that could take itself as an argument. {{{#!hs newtype MobiusFn a = MobiusFn { func :: MobiusFn a -> a } spin :: MobiusFn a -> a spin mf = func mf mf }}} Use it to find suffixes of a `String` {{{#!hs suffixes :: String -> [String] suffixes = spin $ MobiusFn suffixesMF where suffixesMF _ [] = [] suffixesMF mf s@(_:xs) = s : spin mf xs }}} Add `main` and compile {{{#!hs main = readLn >>= (print . suffixes) }}} The compiler panicked with {{{ [1 of 1] Compiling Main ( test.hs, test.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for i386-unknown-linux): Simplifier ticks exhausted When trying UnfoldingDone mf_s1UD }}} But if we ignore the empty string case, it works well with non-empty strings. {{{#!hs suffixes :: String -> [String] suffixes = spin $ MobiusFn suffixesMF where suffixesMF _ s@[_] = [s] suffixesMF mf s@(_:xs) = s : spin mf xs }}} Two versions tested. {{{ GHC version 8.0.1 for i386-unknown-linux GHC version 7.10.3 for i386-unknown-linux }}} Thank you for reading. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 20 12:47:38 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Dec 2016 12:47:38 -0000 Subject: [GHC] #12990: Partially applied constructors with unpacked fields simplified badly In-Reply-To: <045.525d0610bc9f5daed2ba04304bf44d04@haskell.org> References: <045.525d0610bc9f5daed2ba04304bf44d04@haskell.org> Message-ID: <060.fb3b24e5c4a0a000ae965d0920c6ddfe@haskell.org> #12990: Partially applied constructors with unpacked fields simplified badly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Inlining 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 RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 20 12:54:01 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Dec 2016 12:54:01 -0000 Subject: [GHC] #13011: Simplifier ticks exhausted: a 10-line case In-Reply-To: <052.bf42032c1e22b5cab8fc1d52eefb6688@haskell.org> References: <052.bf42032c1e22b5cab8fc1d52eefb6688@haskell.org> Message-ID: <067.c80fa7398b4e702c0c3ea6dbb1288bdf@haskell.org> #13011: Simplifier ticks exhausted: a 10-line case -------------------------------------+------------------------------------- Reporter: L.K.Rebellion | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Simplifier | ticks exhausted Operating System: Linux | Architecture: x86 Type of failure: Compile-time | Test Case: crash or panic | Blocked By: | Blocking: Related Tickets: #8319 #12776 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Alas see [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/bugs.html #bugs-in-ghc known bugs]. And #11240, #8833, #3872, #5400, #5448, #5722, #7057, #7369, #9235. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 20 15:19:35 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Dec 2016 15:19:35 -0000 Subject: [GHC] #11126: Entered absent arg in a Repa program In-Reply-To: <049.08d17e678ab01e39cf7b040134e05fa3@haskell.org> References: <049.08d17e678ab01e39cf7b040134e05fa3@haskell.org> Message-ID: <064.0d7c84cc849ac0b5f8973e7f1f525d62@haskell.org> #11126: Entered absent arg in a Repa program -------------------------------------+------------------------------------- Reporter: tuplanolla | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Simon says, * It's rather rare so we just want to always account for unfolding's free variables in absence analysis * "When doing strictness analysis we don't want to make it appear that it will be used lazily if it's used strictness" -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 20 15:26:44 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Dec 2016 15:26:44 -0000 Subject: [GHC] #5302: Unused arguments in join points In-Reply-To: <046.cf5974b653f31c9d2579761e55f13501@haskell.org> References: <046.cf5974b653f31c9d2579761e55f13501@haskell.org> Message-ID: <061.ff1867556658aa63e66e40265f24ae5f@haskell.org> #5302: Unused arguments in join points -------------------------------------+------------------------------------- Reporter: reinerp | Owner: simonpj Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.0.3 Resolution: | Keywords: JoinPoints 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 simonpj): * keywords: => JoinPoints -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 20 15:27:01 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Dec 2016 15:27:01 -0000 Subject: [GHC] #6087: Join points need strictness analysis In-Reply-To: <046.87e3f1b25b2500e98f2a686fd50954f8@haskell.org> References: <046.87e3f1b25b2500e98f2a686fd50954f8@haskell.org> Message-ID: <061.b453eb76dbe1521afdaa74b3697f342a@haskell.org> #6087: Join points need strictness analysis -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.1 Resolution: | Keywords: JoinPoints 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 simonpj): * keywords: => JoinPoints -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 20 15:28:05 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Dec 2016 15:28:05 -0000 Subject: [GHC] #9688: Improve the interaction between CSE and the join point transformation In-Reply-To: <045.ad5940048773c77749dabb4d904f5fb8@haskell.org> References: <045.ad5940048773c77749dabb4d904f5fb8@haskell.org> Message-ID: <060.281a7e24c508751c1b9263f020517ecf@haskell.org> #9688: Improve the interaction between CSE and the join point transformation -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: CSE, | JoinPoints 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 simonpj): * keywords: CSE => CSE, JoinPoints -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 20 16:36:13 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Dec 2016 16:36:13 -0000 Subject: [GHC] #12985: GHCi incorrectly reports the kind of unboxed tuples spliced in from Template Haskell In-Reply-To: <050.ad0392c4ae751e995d3259a41b13bc35@haskell.org> References: <050.ad0392c4ae751e995d3259a41b13bc35@haskell.org> Message-ID: <065.39f12312e6a7a045c2f4f50058856ca8@haskell.org> #12985: GHCi incorrectly reports the kind of unboxed tuples spliced in from Template Haskell -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.2 Component: Template Haskell | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #12976 | Differential Rev(s): Phab:D2886 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I'm afraid the 8.0.2 ship has already sailed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 20 16:43:34 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Dec 2016 16:43:34 -0000 Subject: [GHC] #12985: GHCi incorrectly reports the kind of unboxed tuples spliced in from Template Haskell In-Reply-To: <050.ad0392c4ae751e995d3259a41b13bc35@haskell.org> References: <050.ad0392c4ae751e995d3259a41b13bc35@haskell.org> Message-ID: <065.5bbe795a9497ba90f4fdc6074f6e256a@haskell.org> #12985: GHCi incorrectly reports the kind of unboxed tuples spliced in from Template Haskell -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.3 Component: Template Haskell | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #12976 | Differential Rev(s): Phab:D2886 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * milestone: 8.0.2 => 8.0.3 Comment: ...8.0.3 then? :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 20 16:47:41 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Dec 2016 16:47:41 -0000 Subject: [GHC] #12103: Typed Template Haskell missing utilities provided by untyped variant In-Reply-To: <046.b18752b937f18b0d4fa594e84b29566e@haskell.org> References: <046.b18752b937f18b0d4fa594e84b29566e@haskell.org> Message-ID: <061.a05aa7fa96b713fec360d9c1f2222637@haskell.org> #12103: Typed Template Haskell missing utilities provided by untyped variant -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: Template Haskell | Version: 8.0.1 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * type: bug => feature request * resolution: => wontfix Comment: "Push to use quotes" sounds reasonable to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 20 17:57:21 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Dec 2016 17:57:21 -0000 Subject: [GHC] #13012: ApiAnnotations comments are not machine checked Message-ID: <045.29c231983181cabaa5efff2e5290e458@haskell.org> #13012: ApiAnnotations comments are not machine checked -------------------------------------+------------------------------------- Reporter: ezyang | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Parser) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Sprinkled throughout the codebase are comments like this: {{{ -- | let(rec) -- -- - 'ApiAnnotation.AnnKeywordId' : 'ApiAnnotation.AnnLet', -- 'ApiAnnotation.AnnOpen' @'{'@, -- 'ApiAnnotation.AnnClose' @'}'@,'ApiAnnotation.AnnIn' }}} The comments are intended to describe the set of annotations that might be possibly associated with an AST node of this constructor. However, the source of truth about these comments is the Parser itself. It's not difficult to imagine that these comments might get out of date if changes are made to the Parser. Nor does the comment in `ApiAnnotations` nor the wiki page (https://ghc.haskell.org/trac/ghc/wiki/ApiAnnotations) explain what the comments are for, and I only recently figured out what they actually mean. (I'm working on a doc patch to improve this.) Ideally, the set of permissible annotations would be encoded in *machine- readable* form, as a contract that we can use to check that the parser upholds the contract. Here is my suggestion: we create a function to recursively traverse a parsed module, and verify that the only annotations associated with any given SrcSpan are the "valid" ones for that AST element. We can enable this extra pass as an "annotation lint" and turn it on for all tests in the test suite. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 20 17:57:43 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Dec 2016 17:57:43 -0000 Subject: [GHC] #13012: ApiAnnotations comments are not machine checked In-Reply-To: <045.29c231983181cabaa5efff2e5290e458@haskell.org> References: <045.29c231983181cabaa5efff2e5290e458@haskell.org> Message-ID: <060.1616977ba5bffa9c2ec0f99bfaf2f049@haskell.org> #13012: ApiAnnotations comments are not machine checked -------------------------------------+------------------------------------- Reporter: ezyang | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Parser) | Resolution: | Keywords: easy Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * keywords: => easy -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 20 18:19:54 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Dec 2016 18:19:54 -0000 Subject: [GHC] #13012: ApiAnnotations comments are not machine checked In-Reply-To: <045.29c231983181cabaa5efff2e5290e458@haskell.org> References: <045.29c231983181cabaa5efff2e5290e458@haskell.org> Message-ID: <060.7bb2afead37825d1a9e75a29fa789b19@haskell.org> #13012: ApiAnnotations comments are not machine checked -------------------------------------+------------------------------------- Reporter: ezyang | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: easy => Comment: This exact information already exists in ghc-exactprint - https://github.com/alanz/ghc- exactprint/blob/master/src/Language/Haskell/GHC/ExactPrint/Annotate.hs - and we tested it by running it on the whole of hackage. I agree that the comments are useless, any consumers should just use `ghc- exactprint` as it performs a lot of utility with the annotations. There haven't been many people who have used it though as the API is not great and balancing everything is quite complicated. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 20 20:14:16 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Dec 2016 20:14:16 -0000 Subject: [GHC] #13013: Add readMaybe to Prelude (possibly readEither too), make Haddocks for read more cautionary Message-ID: <046.3d6f3ae3075d3638bfdec9ce7d4dde8f@haskell.org> #13013: Add readMaybe to Prelude (possibly readEither too), make Haddocks for read more cautionary -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Core | Version: Libraries | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- = Motivation = `read` is an easy way to introduce runtime exceptions into programs, but its documentation doesn't sufficiently warn of this danger. `read`'s safe alternatives, `Text.Read.readMaybe` and `Text.Read.readEither`, are relatively unknown and too hard to find. = Proposal = == Summary == 1. Add `readMaybe` to the `Prelude` 2. Add `readEither` to the `Prelude` 3. Change the documentation for `read` to point out the partiality and to recommend the above alternatives. == 3. Improve the documentation for `read` == The haddocks for `read` currently read: > The `read` function reads input from a string, which must be completely consumed by the input process. I propose to add the following paragraph: > Note: `read` will throw an error if the parse fails. > If there's any uncertainty w.r.t. the shape of the input, `readMaybe` or `readEither` should be used instead. == Qualifications == Ragarding point 2 (`readEither`), I have some qualms whether `readEither` ([http://hackage.haskell.org/package/base-4.9.0.0/docs/Text- Read.html#v:readEither docs]) offers sufficient additional benefit over `readMaybe` to also warrant inclusion in `Prelude`. While `readEither` does give additional info on the kind of parse failures, that information is encoded in a `String` error message, from which it must be parsed if it is needed in the program. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 20 20:22:16 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Dec 2016 20:22:16 -0000 Subject: [GHC] #13014: Seemingly unnecessary marking of a SpecConstr specialization as a loopbreaker Message-ID: <046.bf71fcf5057ea2abf5b697ab6f020f45@haskell.org> #13014: Seemingly unnecessary marking of a SpecConstr specialization as a loopbreaker -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: SpecConstr | 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: -------------------------------------+------------------------------------- !SpecConstr creates the following rules, with the right cajoling. (I've used unboxed integers merely to avoid w/w, which only adds noise in this example.) {{{#!hs data VL :: [k] -> * where VLZ :: VL '[] VLS :: VL as -> VL (a ': as) lengthVL :: GHC.Types.SPEC -> VL as -> Int# {-# INLINABLE lengthVL #-} lengthVL !sPEC VLZ = 0# lengthVL !sPEC (VLS vl) = 1# +# lengthVL sPEC vl ==================== Tidy Core rules ==================== "SC:lengthVL0" [ALWAYS] forall (@ a) (@ (as :: [*])) (sc :: VL as). lengthVL @ (a : as) SPEC (VLS @ * @ (a : as) @ as @ a @~ (_N :: (a : as) ~ (a : as)) sc) = lengthVL_$slengthVL1 @ a @ as sc "SC:lengthVL1" [ALWAYS] forall (sc :: VL '[]). lengthVL @ '[] SPEC sc = lengthVL_$slengthVL sc }}} But the cons-case specialization, `lengthVL_$slengthVL1`, is marked as a loopbreaker. Consider the following idiomatic usage to see why that is problematic. {{{#!hs class KnownSpine (as :: [k]) where sing :: VL as instance KnownSpine '[] where -- ' {-# INLINE sing #-} sing = VLZ instance KnownSpine as => KnownSpine (a ': as) where -- ' {-# INLINE sing #-} sing = VLS sing example :: Int example = I# $ lengthVL SPEC (sing :: VL '[Int,Char,Bool]) }}} The right-hand side of `example` would ideally be simplified to `3`. It's not, ultimately because the specialization is marked as a loopbreaker. I switched on `-dverbose-core2core` to track the simplification of the right-hand side of `example`. 1) The `sing` dictionary is unfolded to constructor applications. 2) Those are floated out but then pre-inlined- unconditionally right back in before CSE gets a chance to spoil it. 3) Thus the VLS rule fires. But it only fires once, because of the loopbreaker designation! I have not yet investigated why the specialization in the cons-case is marked a loopbreaker. (Even if the specialization wasn't being considered a loopbreaker --- which immediately makes this approach to optimization a dead-end --- I don't know with any certainty how to force the specialization to be inlined in those cases where its right-hand side was relatively large.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 20 20:24:48 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Dec 2016 20:24:48 -0000 Subject: [GHC] #13014: Seemingly unnecessary marking of a SpecConstr specialization as a loopbreaker In-Reply-To: <046.bf71fcf5057ea2abf5b697ab6f020f45@haskell.org> References: <046.bf71fcf5057ea2abf5b697ab6f020f45@haskell.org> Message-ID: <061.0eeb18618ff051deb472642a0176c6a0@haskell.org> #13014: Seemingly unnecessary marking of a SpecConstr specialization as a loopbreaker -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: SpecConstr 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: | -------------------------------------+------------------------------------- Comment (by nfrisby): I anticipate that the specialization would be marked a loopbreaker if it were created in a downstream module (i.e. as an orphan rule). But my naive attempt at that didn't work, so I'm suspecting that !SpecConstr doesn't consider imported ids (even `INLINABLE` ones)? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 20 20:41:54 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Dec 2016 20:41:54 -0000 Subject: [GHC] #13015: Remove as much Haskell code as we can from Lexer.x Message-ID: <045.1f5b24922333de889e924193dcfeea87@haskell.org> #13015: Remove as much Haskell code as we can from Lexer.x -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Parser) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I want to reduce the code in Lexer.x so (1) when I use hasktags I jump to some real source, not the postprocess output, and (2) so that I can avoid suppressing warnings on our Haskell source code, and not just the lexer code. If we are willing to introduce an hs-boot file with the following signatures: {{{ bol :: Int layout :: Int layout_do :: Int layout_if :: Int layout_left :: Int option_prags :: Int }}} We can do quite well; the only functions we can't extract are: begin, pop, multiline_doc_comment, lineCommentToken, nested_doc_comment, withLexedDocType, do_bol, setLine, setFile, warnTab, addTabWarning, lexer, lexTokenAlr, lexToken, lexTokenStream, linePrags, fileHeaderPrags, ignoredPrags, oneWordPrags, twoWordPrags, dispatch_pragmas and known_pragma. Some of these, like lexToken, we can't expect to be able to move to a separate file, as they depend on Alex generated data types and functions (AlexRoutine, alexScanUser). But if we boot-ify lexToken, we can move even more code out. One question, however, is the performance cost of going through an hs-boot file, as these don't inline. I think the constants are fairly safe (inlining opportunities should only occur when we compile Lexer.x, at which point we will have unfoldings for them), but I am less certain about lexToken. Any advice? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 20 21:34:36 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Dec 2016 21:34:36 -0000 Subject: [GHC] #13014: Seemingly unnecessary marking of a SpecConstr specialization as a loopbreaker In-Reply-To: <046.bf71fcf5057ea2abf5b697ab6f020f45@haskell.org> References: <046.bf71fcf5057ea2abf5b697ab6f020f45@haskell.org> Message-ID: <061.6c320a2fedc69272430e1118aaaa1000@haskell.org> #13014: Seemingly unnecessary marking of a SpecConstr specialization as a loopbreaker -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: SpecConstr 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: | -------------------------------------+------------------------------------- Comment (by simonpj): Where does the specialisation come from? You can't be showing us all the code to reproduce! Can you do that? Then I can answer about the loop breaker stuff. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 20 21:52:08 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Dec 2016 21:52:08 -0000 Subject: [GHC] #13014: Seemingly unnecessary marking of a SpecConstr specialization as a loopbreaker In-Reply-To: <046.bf71fcf5057ea2abf5b697ab6f020f45@haskell.org> References: <046.bf71fcf5057ea2abf5b697ab6f020f45@haskell.org> Message-ID: <061.4539520c1721edf95ca01f125c2d2ee5@haskell.org> #13014: Seemingly unnecessary marking of a SpecConstr specialization as a loopbreaker -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: SpecConstr 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 nfrisby): * Attachment "T13014.tar.gz" added. A demonstration for ticket #13014 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 20 21:56:56 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Dec 2016 21:56:56 -0000 Subject: [GHC] #13014: Seemingly unnecessary marking of a SpecConstr specialization as a loopbreaker In-Reply-To: <046.bf71fcf5057ea2abf5b697ab6f020f45@haskell.org> References: <046.bf71fcf5057ea2abf5b697ab6f020f45@haskell.org> Message-ID: <061.594c82bb7a775e58e237375a2a593f84@haskell.org> #13014: Seemingly unnecessary marking of a SpecConstr specialization as a loopbreaker -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: SpecConstr 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: | -------------------------------------+------------------------------------- Comment (by nfrisby): I've attached three `hs` files as `T13014.tar.gz`. They demonstrate the issue when they're all compiled with `-O`. (The second module specifies `OPTIONS_GHC -fspec-constr`.) The characteristic of this ticket is that the `-ddump-simpl` for the `GADTSpecConstr3.hs` module does not define `test` as simply `3`. Embarassingly and frustratingly, I've lost the `VLZ` rule with my interim edits and I can't get it back. Thankfully, it's not actually necessary for this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 20 22:28:52 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Dec 2016 22:28:52 -0000 Subject: [GHC] #13013: Add readMaybe to Prelude (possibly readEither too), make Haddocks for read more cautionary In-Reply-To: <046.3d6f3ae3075d3638bfdec9ce7d4dde8f@haskell.org> References: <046.3d6f3ae3075d3638bfdec9ce7d4dde8f@haskell.org> Message-ID: <061.74e26b153e0d7700eea3168f579013f7@haskell.org> #13013: Add readMaybe to Prelude (possibly readEither too), make Haddocks for read more cautionary -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sjakobi): For context, the idea for this proposal came up in [https://www.reddit.com/r/haskell/comments/5j8mpx/haskell_pitfalls/dben8h2/ this discussion on r/haskell]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 20 22:37:10 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Dec 2016 22:37:10 -0000 Subject: [GHC] #13013: Add readMaybe to Prelude (possibly readEither too), make Haddocks for read more cautionary In-Reply-To: <046.3d6f3ae3075d3638bfdec9ce7d4dde8f@haskell.org> References: <046.3d6f3ae3075d3638bfdec9ce7d4dde8f@haskell.org> Message-ID: <061.ca7130b95ed8af07aac9cd6153d96e2d@haskell.org> #13013: Add readMaybe to Prelude (possibly readEither too), make Haddocks for read more cautionary -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): This would be a good addition -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 20 22:41:01 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Dec 2016 22:41:01 -0000 Subject: [GHC] #13013: Add readMaybe to Prelude (possibly readEither too), make Haddocks for read more cautionary In-Reply-To: <046.3d6f3ae3075d3638bfdec9ce7d4dde8f@haskell.org> References: <046.3d6f3ae3075d3638bfdec9ce7d4dde8f@haskell.org> Message-ID: <061.a8352220a3f65eee55721366e4fe4661@haskell.org> #13013: Add readMaybe to Prelude (possibly readEither too), make Haddocks for read more cautionary -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by sjakobi: @@ -32,1 +32,1 @@ - Ragarding point 2 (`readEither`), I have some qualms whether `readEither` + Regarding point 2 (`readEither`), I have some qualms whether `readEither` New description: = Motivation = `read` is an easy way to introduce runtime exceptions into programs, but its documentation doesn't sufficiently warn of this danger. `read`'s safe alternatives, `Text.Read.readMaybe` and `Text.Read.readEither`, are relatively unknown and too hard to find. = Proposal = == Summary == 1. Add `readMaybe` to the `Prelude` 2. Add `readEither` to the `Prelude` 3. Change the documentation for `read` to point out the partiality and to recommend the above alternatives. == 3. Improve the documentation for `read` == The haddocks for `read` currently read: > The `read` function reads input from a string, which must be completely consumed by the input process. I propose to add the following paragraph: > Note: `read` will throw an error if the parse fails. > If there's any uncertainty w.r.t. the shape of the input, `readMaybe` or `readEither` should be used instead. == Qualifications == Regarding point 2 (`readEither`), I have some qualms whether `readEither` ([http://hackage.haskell.org/package/base-4.9.0.0/docs/Text- Read.html#v:readEither docs]) offers sufficient additional benefit over `readMaybe` to also warrant inclusion in `Prelude`. While `readEither` does give additional info on the kind of parse failures, that information is encoded in a `String` error message, from which it must be parsed if it is needed in the program. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 20 22:46:12 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Dec 2016 22:46:12 -0000 Subject: [GHC] #13014: Seemingly unnecessary marking of a SpecConstr specialization as a loopbreaker In-Reply-To: <046.bf71fcf5057ea2abf5b697ab6f020f45@haskell.org> References: <046.bf71fcf5057ea2abf5b697ab6f020f45@haskell.org> Message-ID: <061.8c948bb2d0df66edf15c84f8084cbf99@haskell.org> #13014: Seemingly unnecessary marking of a SpecConstr specialization as a loopbreaker -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: SpecConstr 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: | -------------------------------------+------------------------------------- Comment (by nfrisby): I'm seeing the same behavior if I disable `-fspec-constr` and instead declare. {{{#!hs {-# SPECIALIZE INLINE lengthVL :: SPEC -> VL (a ': as) -> Int# #-} }}} I get the expected rule. {{{#!hs ==================== Tidy Core rules ==================== "SPEC lengthVL" [ALWAYS] forall (@ k) (@ (a :: k)) (@ (as :: [k])). lengthVL @ k @ (a : as) = lengthVL_$slengthVL @ k @ a @ as }}} but the specialization `lengthVL_$slengthVL` is again marked as a loopbreaker, and so it only fires once in the definition of `test`, as with the `-fspec-constr` route. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 20 22:51:04 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Dec 2016 22:51:04 -0000 Subject: [GHC] #12363: Type application for infix In-Reply-To: <051.833fc99ca846ecc78974bf61eb05e05f@haskell.org> References: <051.833fc99ca846ecc78974bf61eb05e05f@haskell.org> Message-ID: <066.311edfb071b4cf5e1d5d8e04d3d99128@haskell.org> #12363: Type application for infix -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 8.0.1 (Parser) | Keywords: Resolution: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Fits well with `catch`, `catchIO`, `catchSTM` idiom {{{#!hs -- do print (a ! 5) `catch` \e -> print (e :: SomeException) -- print (b ! (0,5)) `catch` \e -> print (e :: SomeException) do print (a ! 5) `catch` @SomeException print print (b ! (0,5)) `catch` @SomeException print }}} In that case you could write `print @SomeException` but that will not work if the handler doesn't mention the exception at all {{{#!hs -- rmDir :: FilePath -> IO () -- rmDir dir = removeDirectoryRecursive dir `catch` (const $ return () :: IOException -> IO ()) rmDir :: FilePath -> IO () rmDir dir = removeDirectoryRecursive dir `catch` @IOException const (return ()) }}} (granted `const @_ @IOException` works here, but having a singular place for the type application is nice) and from [http://hsyl20.fr/home/posts/2016-12-12-control-flow-in-haskell- part-3.html Control Flow in Haskell (3) - Flow with Variant] {{{#!hs -- test = f 5 >%~=> (\(a :: A) -> putStrLn "An A has been returned") -- >%~=> (\(b :: B) -> putStrLn "A B has been returned") -- >%~=> (\(c :: C) -> putStrLn "A C has been returned") test = f 5 >%~=> @A \_ -> putStrLn "An A has been returned" >%~=> @B \_ -> putStrLn "A B has been returned" >%~=> @C \_ -> putStrLn "A C has been returned" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 20 23:28:45 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Dec 2016 23:28:45 -0000 Subject: [GHC] #13014: Seemingly unnecessary marking of a SpecConstr specialization as a loopbreaker In-Reply-To: <046.bf71fcf5057ea2abf5b697ab6f020f45@haskell.org> References: <046.bf71fcf5057ea2abf5b697ab6f020f45@haskell.org> Message-ID: <061.296c790c3c5ad0aa7f7d75d43abc351c@haskell.org> #13014: Seemingly unnecessary marking of a SpecConstr specialization as a loopbreaker -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: SpecConstr 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: | -------------------------------------+------------------------------------- Comment (by simonpj): Ah I see. Consider {{{ f [] = 0 f (x:xs) = f xs boo = f [1,2,3,4,5,6,6] }}} Would you expect `f` to inline 7 times in the RHS of `boo` yielding `0`? Maybe it'd be good, but GHC doesn't do that, because inlining a recursive function repeatedly can make the compiler loop at compile time, or just to arbitrary code growth. Yet in this case it's good. In your example we have {{{ lengthVL_$slengthVL = ... case lengthVL @ k @ as sPEC_XyR sc_sCE of wild_Xc { __DEFAULT -> ... }}} and a RULE {{{ "SC:lengthVL0" forall ... lengthVL @ k @ (a : as) sc1_sCC (GADTSpecConstr.VLS ...) = lengthVL_$slengthVL @ k @ a @ as sc_sCE sc1_sCC }}} So if I inline `lengthVL_$slengthVL` I might create an opportunity for the RULE to fire; which gives ries to a new call of `lengthVL_$slengthVL`, and the whole process repeasts. Perhpas indefinitely. It's all very much like the `f/boo` case above, and for that reason GHC marks `lengthVL_$slengthVL` as a loop breaker. There is extensive commentary under `Note [Choosing loop breakers]` in `OccurAnal`. I wish I knew how to make this better, but I don't. Yet anyway. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 21 00:01:08 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Dec 2016 00:01:08 -0000 Subject: [GHC] #13014: Seemingly unnecessary marking of a SpecConstr specialization as a loopbreaker In-Reply-To: <046.bf71fcf5057ea2abf5b697ab6f020f45@haskell.org> References: <046.bf71fcf5057ea2abf5b697ab6f020f45@haskell.org> Message-ID: <061.ce784b72d452895cd0168b5c171ade10@haskell.org> #13014: Seemingly unnecessary marking of a SpecConstr specialization as a loopbreaker -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: SpecConstr 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: | -------------------------------------+------------------------------------- Description changed by nfrisby: @@ -4,0 +4,2 @@ + + (See comment:3 for a Minimal Working Example.) New description: !SpecConstr creates the following rules, with the right cajoling. (I've used unboxed integers merely to avoid w/w, which only adds noise in this example.) (See comment:3 for a Minimal Working Example.) {{{#!hs data VL :: [k] -> * where VLZ :: VL '[] VLS :: VL as -> VL (a ': as) lengthVL :: GHC.Types.SPEC -> VL as -> Int# {-# INLINABLE lengthVL #-} lengthVL !sPEC VLZ = 0# lengthVL !sPEC (VLS vl) = 1# +# lengthVL sPEC vl ==================== Tidy Core rules ==================== "SC:lengthVL0" [ALWAYS] forall (@ a) (@ (as :: [*])) (sc :: VL as). lengthVL @ (a : as) SPEC (VLS @ * @ (a : as) @ as @ a @~ (_N :: (a : as) ~ (a : as)) sc) = lengthVL_$slengthVL1 @ a @ as sc "SC:lengthVL1" [ALWAYS] forall (sc :: VL '[]). lengthVL @ '[] SPEC sc = lengthVL_$slengthVL sc }}} But the cons-case specialization, `lengthVL_$slengthVL1`, is marked as a loopbreaker. Consider the following idiomatic usage to see why that is problematic. {{{#!hs class KnownSpine (as :: [k]) where sing :: VL as instance KnownSpine '[] where -- ' {-# INLINE sing #-} sing = VLZ instance KnownSpine as => KnownSpine (a ': as) where -- ' {-# INLINE sing #-} sing = VLS sing example :: Int example = I# $ lengthVL SPEC (sing :: VL '[Int,Char,Bool]) }}} The right-hand side of `example` would ideally be simplified to `3`. It's not, ultimately because the specialization is marked as a loopbreaker. I switched on `-dverbose-core2core` to track the simplification of the right-hand side of `example`. 1) The `sing` dictionary is unfolded to constructor applications. 2) Those are floated out but then pre-inlined- unconditionally right back in before CSE gets a chance to spoil it. 3) Thus the VLS rule fires. But it only fires once, because of the loopbreaker designation! I have not yet investigated why the specialization in the cons-case is marked a loopbreaker. (Even if the specialization wasn't being considered a loopbreaker --- which immediately makes this approach to optimization a dead-end --- I don't know with any certainty how to force the specialization to be inlined in those cases where its right-hand side was relatively large.) -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 21 00:11:09 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Dec 2016 00:11:09 -0000 Subject: [GHC] #12971: Paths are encoded incorrectly when invoking GCC In-Reply-To: <051.d90144b3c0ebb71e2cb75f2b09f4ef06@haskell.org> References: <051.d90144b3c0ebb71e2cb75f2b09f4ef06@haskell.org> Message-ID: <066.06150fee62425aa42621cc20e9cb028d@haskell.org> #12971: Paths are encoded incorrectly when invoking GCC ---------------------------------+---------------------------------------- Reporter: erikprantare | Owner: Phyx Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by Phyx-): Ok, this issue is an upstream one. The problem is with how the response files are read into GCC. We write out a UTF8 file but the relevant code in `libiberty`[1] assumes 1 byte per character. It works fine if response files aren't used since the rest of the argument handling code seems to work fine with utf-16 and utf-8. Assuming we want to keep the response files, one possible work around would be to convert all paths to the dos short paths. [1] https://github.com/gcc-mirror/gcc/blob/master/libiberty/argv.c#L420 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 21 00:52:01 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Dec 2016 00:52:01 -0000 Subject: [GHC] #13016: SPECIALIZE INLINE doesn't necessarily inline specializations of a recursive function Message-ID: <046.2aa9b52ee76a4c5247a957951dd35986@haskell.org> #13016: SPECIALIZE INLINE doesn't necessarily inline specializations of a recursive function -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: #13014 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html #specialize-inline The user's guide] for `SPECIALIZE INLINE` states it will do a "type-based unrolling" of a recursive function over GADTs. It gives an example, which I've munged a bit to simplify and listed here. {{{#!hs {-# Language GADTs #-} module C where data Arr e where ArrInt :: !Int -> Arr Int ArrPair :: Arr e1 -> Arr e2 -> Arr (e1, e2) (!:) :: Arr e -> Int -> e {-# SPECIALISE INLINE (!:) :: Arr Int -> Int -> Int #-} {-# SPECIALISE INLINE (!:) :: Arr (a, b) -> Int -> (a, b) #-} (ArrInt ba) !: i = ba * i (ArrPair a1 a2) !: i = (a1 !: i, a2 !: i) }}} {{{#!hs module D where import C example = ArrPair (ArrInt 2) (ArrInt 3) !: 5 }}} The specialize rule for pairs fires, but it does not get inlined. This is because the specialization for pairs is marked as a loopbreaker. This behavior contradicts the text from the users guide, emphasis mine: Here, `(!:)` is a recursive function that indexes arrays of type `Arr e`. Consider a call to `(!:)` at type `(Int,Int)`. The second specialisation will fire, ''and the specialised function will be inlined''. It has two calls to `(!:)`, both at type `Int`. Both these calls fire the first specialisation, whose body is also inlined. The result is a type-based unrolling of the indexing function. If I move the `SPECIALIZE INLINE` pragma to the downstream module, then it is not marked as a loopbreaker and we see the expected type-based unrolling. Two possible ways to resolve this ticket: * `SPECIALIZE INLINE` should always achieve supercompilation even if declared in the defining module; the specialization should not be marked as a loopbreaker. * The docs should be updated to say the pragma must be declared in a separate module. I suggest the former. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 21 00:57:51 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Dec 2016 00:57:51 -0000 Subject: [GHC] #13014: Seemingly unnecessary marking of a SpecConstr specialization as a loopbreaker In-Reply-To: <046.bf71fcf5057ea2abf5b697ab6f020f45@haskell.org> References: <046.bf71fcf5057ea2abf5b697ab6f020f45@haskell.org> Message-ID: <061.0326cea5c382332d6540a2876fcfb53e@haskell.org> #13014: Seemingly unnecessary marking of a SpecConstr specialization as a loopbreaker -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: SpecConstr 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: | -------------------------------------+------------------------------------- Comment (by nfrisby): Thank you for your attention, Simon. I've confirmed your example: these modules `A` and `B` give the same behavior: the specialization in `A` is a loopbreaker and the rule only fires once in `B`. {{{#!hs {-# Language MagicHash #-} {-# OPTIONS_GHC -fspec-constr #-} module A where import GHC.Prim import GHC.Types f :: [a] -> Int# f [] = 0# f (x:xs) = f xs f' a b = f (a:b) -- a call pattern to specialize }}} {{{#!hs {-# Language MagicHash #-} module B where import GHC.Types import A boo = I# (f [1,2,3,4,5,6,6]) }}} And your explanation makes total sense: unexpected supercompilation could have terrible consequences. Also, that's something I'm usually aware of, when I'm not wearing my blinders :). ---- The `SPECIALIZE INLINE` alternative I mentioned in comment:4 is interesting. It's possible as a "workaround" for `lengthVL` precisely because the type constructors (of the spine) are 1-to-1 with the data constructors; thus `SPECIALIZE` can be used to emulate `-fspec-constr`. ---- I opened #13016 regarding the `SPECIALIZE INLINE` specialization being a loopbreaker -- that seems like a bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 21 01:00:14 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Dec 2016 01:00:14 -0000 Subject: [GHC] #13017: GHC panics during build of etkmett/free Message-ID: <047.eaea3642af74a01d8da738049f8757aa@haskell.org> #13017: GHC panics during build of etkmett/free -------------------------------------+------------------------------------- Reporter: jbayardo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While using stack, I get the following error: {{{ -- While building package free-4.12.4 using: /home/user/.stack/setup-exe-cache/x86_64-linux/Cabal- simple_mPHDZzAJ_1.24.0.0_ghc-8.0.1 --builddir=.stack- work/dist/x86_64-linux/Cabal-1.24.0.0 build --ghc-options " -ddump-hi -ddump-to-file" Process exited with code: ExitFailure 1 Logs have been written to: /home/user/dev/haskellito/.stack- work/logs/free-4.12.4.log Configuring free-4.12.4... Building free-4.12.4... Preprocessing library free-4.12.4... [ 1 of 16] Compiling Control.Monad.Free.TH ( src/Control/Monad/Free/TH.hs, .stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build/Control/Monad/Free/TH.o ) [ 2 of 16] Compiling Control.Monad.Free.Class ( src/Control/Monad/Free/Class.hs, .stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build/Control/Monad/Free/Class.o ) [ 3 of 16] Compiling Control.Monad.Trans.Iter ( src/Control/Monad/Trans/Iter.hs, .stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build/Control/Monad/Trans/Iter.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): Ix{Int}.index: Index (16777216) out of range ((0,392)) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 21 01:01:53 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Dec 2016 01:01:53 -0000 Subject: [GHC] #13017: GHC panics during build of etkmett/free In-Reply-To: <047.eaea3642af74a01d8da738049f8757aa@haskell.org> References: <047.eaea3642af74a01d8da738049f8757aa@haskell.org> Message-ID: <062.1119171a3c45c880d663d63c83c921a1@haskell.org> #13017: GHC panics during build of etkmett/free -------------------------------------+------------------------------------- Reporter: jbayardo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by jbayardo: @@ -34,0 +34,4 @@ + + This reproduced even with a clean ~/.stack (this includes downloading the + GHC binaries again), and the only necessary condition to reproduce for me + was having lens as a dependency. New description: While using stack, I get the following error: {{{ -- While building package free-4.12.4 using: /home/user/.stack/setup-exe-cache/x86_64-linux/Cabal- simple_mPHDZzAJ_1.24.0.0_ghc-8.0.1 --builddir=.stack- work/dist/x86_64-linux/Cabal-1.24.0.0 build --ghc-options " -ddump-hi -ddump-to-file" Process exited with code: ExitFailure 1 Logs have been written to: /home/user/dev/haskellito/.stack- work/logs/free-4.12.4.log Configuring free-4.12.4... Building free-4.12.4... Preprocessing library free-4.12.4... [ 1 of 16] Compiling Control.Monad.Free.TH ( src/Control/Monad/Free/TH.hs, .stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build/Control/Monad/Free/TH.o ) [ 2 of 16] Compiling Control.Monad.Free.Class ( src/Control/Monad/Free/Class.hs, .stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build/Control/Monad/Free/Class.o ) [ 3 of 16] Compiling Control.Monad.Trans.Iter ( src/Control/Monad/Trans/Iter.hs, .stack- work/dist/x86_64-linux/Cabal-1.24.0.0/build/Control/Monad/Trans/Iter.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): Ix{Int}.index: Index (16777216) out of range ((0,392)) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} This reproduced even with a clean ~/.stack (this includes downloading the GHC binaries again), and the only necessary condition to reproduce for me was having lens as a dependency. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 21 01:07:55 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Dec 2016 01:07:55 -0000 Subject: [GHC] #13017: GHC panics during build of etkmett/free In-Reply-To: <047.eaea3642af74a01d8da738049f8757aa@haskell.org> References: <047.eaea3642af74a01d8da738049f8757aa@haskell.org> Message-ID: <062.b61b9d3f0c0d226104cdd591a03199f4@haskell.org> #13017: GHC panics during build of etkmett/free -------------------------------------+------------------------------------- Reporter: jbayardo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): What version of the compiler is this with? These kind of errors are usually to do with stale interface files (.hi)). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 21 01:13:19 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Dec 2016 01:13:19 -0000 Subject: [GHC] #13017: GHC panics during build of etkmett/free In-Reply-To: <047.eaea3642af74a01d8da738049f8757aa@haskell.org> References: <047.eaea3642af74a01d8da738049f8757aa@haskell.org> Message-ID: <062.bc5013dbae1ef8545b9327a084adc387@haskell.org> #13017: GHC panics during build of etkmett/free -------------------------------------+------------------------------------- Reporter: jbayardo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jbayardo): This is GHC 8.0.1. Is there any command or anything I should run in order to provide you with more information? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 21 01:15:52 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Dec 2016 01:15:52 -0000 Subject: [GHC] #13017: GHC panics during build of etkmett/free In-Reply-To: <047.eaea3642af74a01d8da738049f8757aa@haskell.org> References: <047.eaea3642af74a01d8da738049f8757aa@haskell.org> Message-ID: <062.5e8060eb8db4b8ed78d1935a02d256e0@haskell.org> #13017: GHC panics during build of etkmett/free -------------------------------------+------------------------------------- Reporter: jbayardo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by jbayardo): * failure: None/Unknown => Compile-time crash or panic * os: Unknown/Multiple => Linux * architecture: Unknown/Multiple => x86_64 (amd64) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 21 01:18:28 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Dec 2016 01:18:28 -0000 Subject: [GHC] #12623: Make Harbormaster less terrible in the face of submodule updates In-Reply-To: <046.6ed234b0aab5561063eed563f1a09702@haskell.org> References: <046.6ed234b0aab5561063eed563f1a09702@haskell.org> Message-ID: <061.90dceedaf800a059a6d51e1a0628cb88@haskell.org> #12623: Make Harbormaster less terrible in the face of submodule updates -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: highest | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * owner: bgamarii => bgamari -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 21 01:19:46 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Dec 2016 01:19:46 -0000 Subject: [GHC] #13017: GHC panics during build of etkmett/free In-Reply-To: <047.eaea3642af74a01d8da738049f8757aa@haskell.org> References: <047.eaea3642af74a01d8da738049f8757aa@haskell.org> Message-ID: <062.9d76e1673ce66c903ac825ebf66d94b5@haskell.org> #13017: GHC panics during build of etkmett/free -------------------------------------+------------------------------------- Reporter: jbayardo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): I feel this is unlikely to be a GHC bug as this such a common package. Maybe try deleting the local .stack-work directory as well? I don't know where stack puts interface files by default. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 21 01:26:33 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Dec 2016 01:26:33 -0000 Subject: [GHC] #13014: Seemingly unnecessary marking of a SpecConstr specialization as a loopbreaker In-Reply-To: <046.bf71fcf5057ea2abf5b697ab6f020f45@haskell.org> References: <046.bf71fcf5057ea2abf5b697ab6f020f45@haskell.org> Message-ID: <061.26071fbafda5156b94134b3c7dbb8df8@haskell.org> #13014: Seemingly unnecessary marking of a SpecConstr specialization as a loopbreaker -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: SpecConstr 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: | -------------------------------------+------------------------------------- Comment (by nfrisby): Replying to [comment:5 simonpj]: > [snip] > > ... > > I wish I knew how to make this better, but I don't. Yet anyway. One quick idea: introduce `GHC.Types.DEEP_SPEC` alongside `SPEC`. The key difference is that the occurrence analyzer would try very hard to not mark specializations involving `DEEP_SPEC` as loopbreakers. The docs for this would likely emphasize some of the potential downsides of this unbounded inlining. Unless you think that's promising, let's close this ticket as "Not a Bug". I don't recall wanting aggressive inlining of a recursive function that wasn't driven by a type-refining GADT, so #13016 ought to handle my needs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 21 03:08:45 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Dec 2016 03:08:45 -0000 Subject: [GHC] #12990: Partially applied constructors with unpacked fields simplified badly In-Reply-To: <045.525d0610bc9f5daed2ba04304bf44d04@haskell.org> References: <045.525d0610bc9f5daed2ba04304bf44d04@haskell.org> Message-ID: <060.00d7c711d1f9e49f0e2db966bcbaf22f@haskell.org> #12990: Partially applied constructors with unpacked fields simplified badly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Inlining 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: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:3 simonpj]: > In `MkId` line 511 we have > {{{ > wrap_unf = mkInlineUnfolding (Just wrap_arity) wrap_rhs > }}} > The `Just wrap_arity` is what prevents GHC inlining the wrapper until it is saturated. Change it to `Nothing` to allow a partially-applied wrapper to inline. > > Worth a try. I doubt it'd have any bad effects. There's a comment right above that I don't know enough about GHC to interpret: > The Cpr info can be important inside INLINE rhss, where the > wrapper constructor isn't inlined. > And the argument strictness can be important too; we > may not inline a constructor when it is partially applied. > For example: > {{{#!hs > data W = C !Int !Int !Int > ...(let w = C x in ...(w p q)...)... > }}} > we want to see that w is strict in its two arguments Does this point to a reason not to inline partially-applied wrappers? If not, does it point to some additional change that should be made in parallel? Or does it become obsolete with this change? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 21 03:20:52 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Dec 2016 03:20:52 -0000 Subject: [GHC] #13017: GHC panics during build of etkmett/free In-Reply-To: <047.eaea3642af74a01d8da738049f8757aa@haskell.org> References: <047.eaea3642af74a01d8da738049f8757aa@haskell.org> Message-ID: <062.8798d75375d49502ffa7217855a77046@haskell.org> #13017: GHC panics during build of etkmett/free -------------------------------------+------------------------------------- Reporter: jbayardo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jbayardo): Replying to [comment:5 mpickering]: > I feel this is unlikely to be a GHC bug as this such a common package. Maybe try deleting the local .stack-work directory as well? I don't know where stack puts interface files by default. I did, but this did not produce any change whatsoever. Any other idea as to what may be causing this issue? I do not have ghc installed globally, only through stack, so there (shouldn't) be interference between the different ghc versions that stack has. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 21 04:01:41 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Dec 2016 04:01:41 -0000 Subject: [GHC] #13017: GHC panics during build of etkmett/free In-Reply-To: <047.eaea3642af74a01d8da738049f8757aa@haskell.org> References: <047.eaea3642af74a01d8da738049f8757aa@haskell.org> Message-ID: <062.93a4c3e4718afd387fd67faf409dbcc0@haskell.org> #13017: GHC panics during build of etkmett/free -------------------------------------+------------------------------------- Reporter: jbayardo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hsyl20): Please show us the stack log obtained with `stack -v` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 21 04:14:57 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Dec 2016 04:14:57 -0000 Subject: [GHC] #13018: TH-spliced pattern synonym declaration fails to typecheck Message-ID: <050.321896de80824d0ab018c753e6e2c2e9@haskell.org> #13018: TH-spliced pattern synonym declaration fails to typecheck -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.1 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This pattern synonyms typechecks without issue: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE PatternSynonyms #-} module Works where data T a where MkT :: Eq b => b -> T a pattern P :: b -> T a pattern P x <- MkT x }}} But if you try to create `P` from a Template Haskell splice, it will fail to typecheck: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE PatternSynonyms #-} {-# LANGUAGE TemplateHaskell #-} module Bug where data T a where MkT :: Eq b => b -> T a $([d| pattern P :: b -> T a; pattern P x <- MkT x |]) }}} {{{ $ /opt/ghc/head/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:9:3: error: • Couldn't match expected type ‘b0’ with actual type ‘b’ ‘b’ is a rigid type variable bound by a pattern with constructor: MkT :: forall a b. Eq b => b -> T a, in a pattern synonym declaration at Bug.hs:9:3-52 ‘b0’ is a rigid type variable bound by the signature for pattern synonym ‘P’ at Bug.hs:9:3-52 • In the declaration for pattern synonym ‘P’ • Relevant bindings include x_a4tP :: b (bound at Bug.hs:9:3) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 21 04:16:48 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Dec 2016 04:16:48 -0000 Subject: [GHC] #13019: 'stack upgrade' failed with the message "ghc: panic! (the 'impossible' happened)" Message-ID: <043.6c9cba859558a3730a8b418b5cf7746f@haskell.org> #13019: 'stack upgrade' failed with the message "ghc: panic! (the 'impossible' happened)" -------------------------------------+------------------------------------- Reporter: welf | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: stack upgrade | Operating System: MacOS X Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- MacBook Pro, MacOS Sierra 10.12.2 $ stack upgrade Fetched package index. http-client-0.5.3.3: configure http-client-0.5.3.3: build pid1-0.1.0.0: configure pid1-0.1.0.0: build optparse-applicative-0.13.0.0: configure optparse-applicative-0.13.0.0: build text-metrics-0.1.0: configure pid1-0.1.0.0: copy/register text-metrics-0.1.0: build aeson-1.0.2.1: configure aeson-1.0.2.1: build th-orphans-0.13.1: configure text-metrics-0.1.0: copy/register th-orphans-0.13.1: build store-core-0.3: configure store-core-0.3: build store-core-0.3: copy/register th-orphans-0.13.1: copy/register th-utilities-0.2.0.1: configure th-utilities-0.2.0.1: build optparse-applicative-0.13.0.0: copy/register optparse-simple-0.0.3: configure optparse-simple-0.0.3: build optparse-simple-0.0.3: copy/register http-client-0.5.3.3: copy/register http-client-tls-0.3.3: configure http-client-tls-0.3.3: build th-utilities-0.2.0.1: copy/register store-0.3: configure store-0.3: build http-client-tls-0.3.3: copy/register store-0.3: copy/register aeson-1.0.2.1: copy/register binary-tagged-0.1.4.1: configure binary-tagged-0.1.4.1: build yaml-0.8.20: configure yaml-0.8.20: build path-0.5.9: configure path-0.5.9: build aeson-compat-0.3.6: configure aeson-compat-0.3.6: build http-conduit-2.2.3: configure http-conduit-2.2.3: build persistent-2.6: configure path-0.5.9: copy/register persistent-2.6: build path-io-1.1.0: configure aeson-compat-0.3.6: copy/register path-io-1.1.0: build binary-tagged-0.1.4.1: copy/register http-conduit-2.2.3: copy/register path-io-1.1.0: copy/register yaml-0.8.20: copy/register hpack-0.15.0: configure hpack-0.15.0: build persistent-2.6: copy/register persistent-template-2.5.1.6: configure persistent-template-2.5.1.6: build persistent-sqlite-2.6: configure hpack-0.15.0: copy/register persistent-sqlite-2.6: build persistent-template-2.5.1.6: copy/register persistent-sqlite-2.6: copy/register stack-1.3.0: configure [1 of 1] Compiling Main ( /private/var/folders/b2/q9qtc29x3m542jp596km0lgw0000gn/T/stack- upgrade83426/stack-1.3.0/Setup.hs, /private/v ar/folders/b2/q9qtc29x3m542jp596km0lgw0000gn/T/stack- upgrade83426/stack-1.3.0/.stack- work/dist/x86_64-osx/Cabal-1.22.5.0/setup/Main.o ) Linking /private/var/folders/b2/q9qtc29x3m542jp596km0lgw0000gn/T/stack- upgrade83426/stack-1.3.0/.stack- work/dist/x86_64-osx/Cabal-1.22.5.0/setup/s etup ... Configuring stack-1.3.0... stack-1.3.0: build Preprocessing library stack-1.3.0... [ 1 of 121] Compiling Text.PrettyPrint.Leijen.Extended ( src/Text/PrettyPrint/Leijen/Extended.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/buil d/Text/PrettyPrint/Leijen/Extended.o ) [ 2 of 121] Compiling Stack.Ghci.Script ( src/Stack/Ghci/Script.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/Stack/Ghci/Script.o ) [ 3 of 121] Compiling Stack.FileWatch ( src/Stack/FileWatch.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Stack/FileWatch.o ) [ 4 of 121] Compiling System.Process.PagerEditor ( src/System/Process/PagerEditor.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/System/Pro cess/PagerEditor.o ) [ 5 of 121] Compiling System.Process.Log ( src/System/Process/Log.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/System/Process/Log.o ) [ 6 of 121] Compiling Paths_stack ( .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/autogen/Paths_stack.hs, .stack- work/dist/x86_64-osx/Cab al-1.22.5.0/build/Paths_stack.o ) [ 7 of 121] Compiling Path.Find ( src/Path/Find.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Path/Find.o ) [ 8 of 121] Compiling Path.Extra ( src/Path/Extra.hs, .stack- work/dist/x86_64-osx/Cabal-1.22.5.0/build/Path/Extra.o ) [ 9 of 121] Compiling System.Process.Read ( src/System/Process/Read.hs, .stack-work/dist/x86_64-osx/Cabal-1.22.5.0/build/System/Process/Read.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.3 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/b2/q9qtc29x3m542jp596km0lgw0000gn/T/ghc85411_0/libghc_57.dylib, 5): no suitable image found. Did find: /var/folders/b2/q9qtc29x3m542jp596km0lgw0000gn/T/ghc85411_0/libghc_57.dylib: malformed mach-o: load commands size (47464) > 32768 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Completed 22 action(s). -- While building package stack-1.3.0 using: /private/var/folders/b2/q9qtc29x3m542jp596km0lgw0000gn/T/stack- upgrade83426/stack-1.3.0/.stack- work/dist/x86_64-osx/Cabal-1.22.5.0/setup/setup --builddir=.stack- work/dist/x86_64-osx/Cabal-1.22.5.0 build lib:stack exe:stack --ghc- options " -ddump-hi -ddump-to-file" Process exited with code: ExitFailure 1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 21 08:23:06 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Dec 2016 08:23:06 -0000 Subject: [GHC] #13014: Seemingly unnecessary marking of a SpecConstr specialization as a loopbreaker In-Reply-To: <046.bf71fcf5057ea2abf5b697ab6f020f45@haskell.org> References: <046.bf71fcf5057ea2abf5b697ab6f020f45@haskell.org> Message-ID: <061.1e3ea6fa176769a77adfc208535c0536@haskell.org> #13014: Seemingly unnecessary marking of a SpecConstr specialization as a loopbreaker -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: SpecConstr 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: | -------------------------------------+------------------------------------- Comment (by simonpj): Can you be more specific about "try very hard"? The thing is, as far as I can see, it ''is'' loop breaker, as my comment shows. That is, not marking it as such would allow arbitrary inlining. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 21 10:14:49 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Dec 2016 10:14:49 -0000 Subject: [GHC] #13019: 'stack upgrade' failed with the message "ghc: panic! (the 'impossible' happened)" In-Reply-To: <043.6c9cba859558a3730a8b418b5cf7746f@haskell.org> References: <043.6c9cba859558a3730a8b418b5cf7746f@haskell.org> Message-ID: <058.8e0b942e14cc93c54d5de8f5d4ef1f1b@haskell.org> #13019: 'stack upgrade' failed with the message "ghc: panic! (the 'impossible' happened)" -------------------------------------+------------------------------------- Reporter: welf | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: duplicate | Keywords: stack upgrade Operating System: MacOS X | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #12479 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => closed * resolution: => duplicate * related: => #12479 Comment: This has been fixed. See #12479 for the details. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 21 10:15:24 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Dec 2016 10:15:24 -0000 Subject: [GHC] #13018: TH-spliced pattern synonym declaration fails to typecheck In-Reply-To: <050.321896de80824d0ab018c753e6e2c2e9@haskell.org> References: <050.321896de80824d0ab018c753e6e2c2e9@haskell.org> Message-ID: <065.bc1da2f43f27f52d1a40bc57366ba6c7@haskell.org> #13018: TH-spliced pattern synonym declaration fails to typecheck -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * cc: PatternSynonyms (removed) * keywords: => PatternSynonyms -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 21 10:53:47 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Dec 2016 10:53:47 -0000 Subject: [GHC] #12991: panic when using IrredPreds in a type checker plugin. In-Reply-To: <043.3217b821d2aaafeace19f4825d72c2ca@haskell.org> References: <043.3217b821d2aaafeace19f4825d72c2ca@haskell.org> Message-ID: <058.6b1ddd36ff4f663744be1bf7848ed5b7@haskell.org> #12991: panic when using IrredPreds in a type checker plugin. -------------------------------------+------------------------------------- Reporter: owen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Works ok in HEAD and the 8.0 branch, so maybe it's fixed. {{{ ~/5builds/ghc-8.0-branch/inplace/bin/ghc-stage2 -dynamic --make -dcore- lint -package ghc *hs [1 of 3] Compiling Test.Plugin ( Plugin.hs, Plugin.o ) [2 of 3] Compiling Test.Compare ( Compare.hs, Compare.o ) [3 of 3] Compiling Test.Fails ( Fails.hs, Fails.o ) irred compare [W] irred_aaYl :: l_aaVc[tau:3] ≽ l'_aaVd[tau:3] (CNonCanonical) irred compare [W] irred_aaYm :: l'_aaVd[tau:3] ≽ l_aaVc[tau:3] (CNonCanonical) simonpj at cam-05-unx:~/tmp/ghc-plugin-test/Test$ }}} I had to change `import Data.Constraint` to `import GHC.Exts`. Where is the "right" place to import `Constraint` from? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 21 11:43:41 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Dec 2016 11:43:41 -0000 Subject: [GHC] #13020: Use a fixed SDK for Mac OS X builds Message-ID: <046.40e9861ee77c2ecd2222e3331c425747@haskell.org> #13020: Use a fixed SDK for Mac OS X builds -------------------------------------+------------------------------------- Reporter: gracjan | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: MacOS X Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Apple releases new systems with new SDK versions. Official documentation says that it is enough to use newest SDK with MACOSX_TARGET set to lowest supported version of Mac OS X. This is not always true, as they try to keep all new features conditionally included, but they sometimes fail. For example `/usr/include/sys/mman.h` file has been changed between SDK10.10 and SDK10.11 without any compatibility flags and resulted in #13005 (Mac OSX uses `MAP_ANON` in place of `MAP_ANONYMOUS`). The solution is: - download the lowest supported SDK from https://github.com/phracker /MacOSX-SDKs - set the path using -isysroot param to gcc Overall would be best to compile using all supported SDKs, but given lack of CI machines I think it is better to build with minimum version. Apple is pretty good at keeping backward compatibility on source level. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 21 13:28:43 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Dec 2016 13:28:43 -0000 Subject: [GHC] #13021: Inaccessible RHS warning is confusing for users Message-ID: <049.555b28c752b0039d3740af545c7af8be@haskell.org> #13021: Inaccessible RHS warning is confusing for users -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple PatternMatchWarnings | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The pattern match checker makes the distinction between redundant matches and matches with an inaccessible right hand side. A pattern with an inaccessible RHS, is a redundant pattern which forces the argument so affects strictness. I think this is confusing for users as most of the time you write programs assuming totality but the error message doesn't make it clear why the two warnings are different. I think that instead they should both be called redundant but a note added to the inaccessible case explaining that removing it could affect strictness. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 21 13:49:49 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Dec 2016 13:49:49 -0000 Subject: [GHC] #13021: Inaccessible RHS warning is confusing for users In-Reply-To: <049.555b28c752b0039d3740af545c7af8be@haskell.org> References: <049.555b28c752b0039d3740af545c7af8be@haskell.org> Message-ID: <064.5eae7cba182695cadb0f883b523c4a8b@haskell.org> #13021: Inaccessible RHS warning is confusing for users -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by gkaracha): Even though I understand that the message can be confusing, I disagree with calling it in any way "redundant". Pattern matching is side-effectful in a lazy language and in fact we often use it just to force evaluation, so I would not consider it a minor thing. Before GHC 8, both redundant and with-inaccessible-rhs clauses where called "overlapping" which may be more appropriate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 21 14:06:17 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Dec 2016 14:06:17 -0000 Subject: [GHC] #12968: GHC crash with TypeInType and pattern synonym In-Reply-To: <045.e5902e755bebc0a0dcc9bf7badbe59f9@haskell.org> References: <045.e5902e755bebc0a0dcc9bf7badbe59f9@haskell.org> Message-ID: <060.ac915dc168ae5cad72272aa25da2c242@haskell.org> #12968: GHC crash with TypeInType and pattern synonym -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #12489 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"f97d489911aabd2396f5df87efd7d1d164017142/ghc" f97d4899/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f97d489911aabd2396f5df87efd7d1d164017142" Test Trac #12968, plus some comments }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 21 14:06:17 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Dec 2016 14:06:17 -0000 Subject: [GHC] #12969: Rebindable enumFrom etc. syntax In-Reply-To: <045.5772062aa85023583167120cc509b98f@haskell.org> References: <045.5772062aa85023583167120cc509b98f@haskell.org> Message-ID: <060.af14e0e85bf07f4e8bceb0e754f63a89@haskell.org> #12969: Rebindable enumFrom etc. syntax -------------------------------------+------------------------------------- Reporter: cactus | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: | RebindableSyntax Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"c73a982bc49a234a030cea2496b70829c98b1e10/ghc" c73a982/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c73a982bc49a234a030cea2496b70829c98b1e10" Add note for rebindable syntax of [a..b] See Trac #12969 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 21 14:06:17 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Dec 2016 14:06:17 -0000 Subject: [GHC] #12444: Regression: panic! on inaccessible code with constraint In-Reply-To: <045.55648cb12988a97c56d5e3236e93c6be@haskell.org> References: <045.55648cb12988a97c56d5e3236e93c6be@haskell.org> Message-ID: <060.f1ba8bddd19f2fef713a1cbc4817b714@haskell.org> #12444: Regression: panic! on inaccessible code with constraint -------------------------------------+------------------------------------- Reporter: zilinc | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | polykinds/T12444 Blocked By: | Blocking: Related Tickets: #12526 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"c48595eef2bca6d91ec0a649839f8066f269e6a4/ghc" c48595ee/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c48595eef2bca6d91ec0a649839f8066f269e6a4" Never apply worker/wrapper to DFuns While fixing Trac #12444 I found an occasion on which we applied worker/wrapper to a DFunId. This is bad: it destroys the magic DFunUnfolding. This patch is a minor refactoring that stops this corner case happening, and tidies up the code a bit too. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 21 14:06:17 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Dec 2016 14:06:17 -0000 Subject: [GHC] #12944: ghc master (8.1.20161206) panics with assertion failure with devel2 flavor and -O In-Reply-To: <044.3fe8817d41680dd8c67e674ebd7c6a0f@haskell.org> References: <044.3fe8817d41680dd8c67e674ebd7c6a0f@haskell.org> Message-ID: <059.d67932bb5dbf7621d013ee948910b906@haskell.org> #12944: ghc master (8.1.20161206) panics with assertion failure with devel2 flavor and -O -------------------------------------+------------------------------------- Reporter: pacak | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 (CodeGen) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2844 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"0a18231b9c62c9f773a5c74f7cc290416fbbb655/ghc" 0a18231b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0a18231b9c62c9f773a5c74f7cc290416fbbb655" Lint DFunUnfoldings Previously we simply failed to Lint these DFunUnfoldings, which led to a very delayed error message for Trac #12944 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 21 14:06:17 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Dec 2016 14:06:17 -0000 Subject: [GHC] #9509: No automatic specialization of inlinable imports in 7.8 In-Reply-To: <044.78a0dc81057ff6a68effbbb3815481da@haskell.org> References: <044.78a0dc81057ff6a68effbbb3815481da@haskell.org> Message-ID: <059.3a643154bb6ec9159ba6828eba48b95a@haskell.org> #9509: No automatic specialization of inlinable imports in 7.8 -------------------------------------+------------------------------------- Reporter: dolio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.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: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"e07ad4db75885f6e3ff82aa3343999f2af39a16d/ghc" e07ad4d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e07ad4db75885f6e3ff82aa3343999f2af39a16d" Don't eta-expand in stable unfoldings See SimplUtils Note [No eta expansion in stable unfoldings], and Trac #9509 for an excellend diagnosis by Nick Frisby }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 21 14:06:17 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Dec 2016 14:06:17 -0000 Subject: [GHC] #12944: ghc master (8.1.20161206) panics with assertion failure with devel2 flavor and -O In-Reply-To: <044.3fe8817d41680dd8c67e674ebd7c6a0f@haskell.org> References: <044.3fe8817d41680dd8c67e674ebd7c6a0f@haskell.org> Message-ID: <059.c1c5a2489d711a7c4994f438d48d4a04@haskell.org> #12944: ghc master (8.1.20161206) panics with assertion failure with devel2 flavor and -O -------------------------------------+------------------------------------- Reporter: pacak | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 (CodeGen) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2844 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"1a4c04b13a695a530ee24835a7550a8c9ed2d37a/ghc" 1a4c04b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1a4c04b13a695a530ee24835a7550a8c9ed2d37a" Fix 'SPECIALISE instance' Trac #12944 showed that the DsBinds code that implemented a SPECIALISE pragma was inadequate if the constraints solving added let-bindings for dictionaries. The result was that we ended up with an unbound dictionary in a DFunUnfolding -- and Lint didn't even check for that! Fixing this was not entirely straightforward * In DsBinds.dsSpec we use a new function TcEvidence.collectHsWrapBinders to pick off the lambda binders from the HsWapper * dsWrapper now returns a (CoreExpr -> CoreExpr) function * CoreUnfold.specUnfolding now takes a (CoreExpr -> CoreExpr) function it can use to specialise the unfolding. On the whole the code is simpler than before. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 21 14:06:17 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Dec 2016 14:06:17 -0000 Subject: [GHC] #12950: Unnecessarily complicated left-hand side for SPECIALIZE pragma causing RULE left-hand side too complicated to desugar In-Reply-To: <046.22b3b53414e7ce2af2682aabd50cd43c@haskell.org> References: <046.22b3b53414e7ce2af2682aabd50cd43c@haskell.org> Message-ID: <061.01004a2101ddd356dbdc4a5f23722fef@haskell.org> #12950: Unnecessarily complicated left-hand side for SPECIALIZE pragma causing RULE left-hand side too complicated to desugar -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: worksforme | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): #10555,#12074,#12649 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"c469db4e5e8814e4a4f1ed7f648514bedb800c25/ghc" c469db4e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c469db4e5e8814e4a4f1ed7f648514bedb800c25" Test Trac #12950 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 21 14:07:15 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Dec 2016 14:07:15 -0000 Subject: [GHC] #13022: Pattern Synonyms using other synonyms causes ghc panic Message-ID: <050.9e35fd6c60d661c77b52156a617da416@haskell.org> #13022: Pattern Synonyms using other synonyms causes ghc panic -------------------------------------+------------------------------------- Reporter: AveryGlitch | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Here's a (somewhat) minimal example: {{{#!hs {-# LANGUAGE PatternSynonyms #-} data Some = Thing Int Int pattern A x = Thing x 0 pattern B x = Thing x 1 pattern C x = Thing x 2 pattern D = C 3 }}} And here's what happened when I tried to load this into ghci: {{{ *Main> :l ghc_bug.hs [1 of 1] Compiling Main ( ghc_bug.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.1 for x86_64-unknown-linux): kindPrimRep.go rep_a3fP Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 21 14:12:07 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Dec 2016 14:12:07 -0000 Subject: [GHC] #13022: Pattern Synonyms using other synonyms causes ghc panic In-Reply-To: <050.9e35fd6c60d661c77b52156a617da416@haskell.org> References: <050.9e35fd6c60d661c77b52156a617da416@haskell.org> Message-ID: <065.05b8fada898390b0f7f4ba0a52163653@haskell.org> #13022: Pattern Synonyms using other synonyms causes ghc panic -------------------------------------+------------------------------------- Reporter: AveryGlitch | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: | PatternSynonyms Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => PatternSynonyms * status: new => closed * resolution: => duplicate Comment: This is fixed in HEAD. Duplicate of #12007 . Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 21 14:18:51 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Dec 2016 14:18:51 -0000 Subject: [GHC] #11598: Cache coercion kinds and roles In-Reply-To: <047.56bbfff0d86db02c37b25ddc698d48a1@haskell.org> References: <047.56bbfff0d86db02c37b25ddc698d48a1@haskell.org> Message-ID: <062.c79c3af6b7165f8a648f146b9d29e3f7@haskell.org> #11598: Cache coercion kinds and roles -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8095 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => wontfix Comment: That's true. I'm abandoning this attempt, though the knowledge I gained and recorded above will be helpful in tackling #8095, which is still very much on the table. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 21 14:18:55 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Dec 2016 14:18:55 -0000 Subject: [GHC] #9509: No automatic specialization of inlinable imports in 7.8 In-Reply-To: <044.78a0dc81057ff6a68effbbb3815481da@haskell.org> References: <044.78a0dc81057ff6a68effbbb3815481da@haskell.org> Message-ID: <059.e90c66f495f59aa77763fa29d63f6efd@haskell.org> #9509: No automatic specialization of inlinable imports in 7.8 -------------------------------------+------------------------------------- Reporter: dolio | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | simplCore/should_compile/T9509 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => simplCore/should_compile/T9509 * status: new => closed * resolution: => fixed Comment: Thanks for the analysis! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 21 14:19:20 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Dec 2016 14:19:20 -0000 Subject: [GHC] #12968: GHC crash with TypeInType and pattern synonym In-Reply-To: <045.e5902e755bebc0a0dcc9bf7badbe59f9@haskell.org> References: <045.e5902e755bebc0a0dcc9bf7badbe59f9@haskell.org> Message-ID: <060.57f7ac139171d17db236654e18e0746c@haskell.org> #12968: GHC crash with TypeInType and pattern synonym -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | patsyn/should_compile/T12968 Blocked By: | Blocking: Related Tickets: #12489 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => patsyn/should_compile/T12968 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 21 14:21:19 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Dec 2016 14:21:19 -0000 Subject: [GHC] #12944: ghc master (8.1.20161206) panics with assertion failure with devel2 flavor and -O In-Reply-To: <044.3fe8817d41680dd8c67e674ebd7c6a0f@haskell.org> References: <044.3fe8817d41680dd8c67e674ebd7c6a0f@haskell.org> Message-ID: <059.3e3531e59166fd54687198977359e517@haskell.org> #12944: ghc master (8.1.20161206) panics with assertion failure with devel2 flavor and -O -------------------------------------+------------------------------------- Reporter: pacak | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 (CodeGen) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2844 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Also relevant (the commit message should say #12944 not #12444): {{{ revision="c48595eef2bca6d91ec0a649839f8066f269e6a4" Never apply worker/wrapper to DFuns While fixing Trac #12444 I found an occasion on which we applied worker/wrapper to a DFunId. This is bad: it destroys the magic DFunUnfolding. This patch is a minor refactoring that stops this corner case happening, and tidies up the code a bit too. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 21 14:22:46 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Dec 2016 14:22:46 -0000 Subject: [GHC] #12944: ghc master (8.1.20161206) panics with assertion failure with devel2 flavor and -O In-Reply-To: <044.3fe8817d41680dd8c67e674ebd7c6a0f@haskell.org> References: <044.3fe8817d41680dd8c67e674ebd7c6a0f@haskell.org> Message-ID: <059.ab18b42224a5bc5ee8c155b8637c4bab@haskell.org> #12944: ghc master (8.1.20161206) panics with assertion failure with devel2 flavor and -O -------------------------------------+------------------------------------- Reporter: pacak | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.1 (CodeGen) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | deSugar/should_compile/T12944 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2844 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => deSugar/should_compile/T12944 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 21 14:24:40 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Dec 2016 14:24:40 -0000 Subject: [GHC] #12944: ghc master (8.1.20161206) panics with assertion failure with devel2 flavor and -O In-Reply-To: <044.3fe8817d41680dd8c67e674ebd7c6a0f@haskell.org> References: <044.3fe8817d41680dd8c67e674ebd7c6a0f@haskell.org> Message-ID: <059.2ae2da9978e57fb79893c0333e820009@haskell.org> #12944: ghc master (8.1.20161206) panics with assertion failure with devel2 flavor and -O -------------------------------------+------------------------------------- Reporter: pacak | Owner: Type: bug | Status: merge Priority: highest | Milestone: 8.0.3 Component: Compiler | Version: 8.1 (CodeGen) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | deSugar/should_compile/T12944 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2844 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: closed => merge * milestone: 8.2.1 => 8.0.3 Comment: The main patch here, in comment:13, is a candidate for 8.0.3 since it fixes an outright bug. So I'll switch to merge status. But it may depend (in a trivial and easily-avoidable way) on an earlier commit {{{ 05d233e8e18284cb98dc320bf58191ba4d86c754 Move InId/OutId to CoreSyn }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 21 14:25:18 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Dec 2016 14:25:18 -0000 Subject: [GHC] #12950: Unnecessarily complicated left-hand side for SPECIALIZE pragma causing RULE left-hand side too complicated to desugar In-Reply-To: <046.22b3b53414e7ce2af2682aabd50cd43c@haskell.org> References: <046.22b3b53414e7ce2af2682aabd50cd43c@haskell.org> Message-ID: <061.7bd83b3ca4f9a7372016bc67e7b36efb@haskell.org> #12950: Unnecessarily complicated left-hand side for SPECIALIZE pragma causing RULE left-hand side too complicated to desugar -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: worksforme | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: error/warning at compile-time | deSugar/should_compile/T12950 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): #10555,#12074,#12649 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => deSugar/should_compile/T12950 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 21 14:25:38 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Dec 2016 14:25:38 -0000 Subject: [GHC] #12969: Rebindable enumFrom etc. syntax In-Reply-To: <045.5772062aa85023583167120cc509b98f@haskell.org> References: <045.5772062aa85023583167120cc509b98f@haskell.org> Message-ID: <060.be46bdd6cf0647cf8f33aca41ca5dee8@haskell.org> #12969: Rebindable enumFrom etc. syntax -------------------------------------+------------------------------------- Reporter: cactus | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: fixed | RebindableSyntax Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 21 14:30:53 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Dec 2016 14:30:53 -0000 Subject: [GHC] #12990: Partially applied constructors with unpacked fields simplified badly In-Reply-To: <045.525d0610bc9f5daed2ba04304bf44d04@haskell.org> References: <045.525d0610bc9f5daed2ba04304bf44d04@haskell.org> Message-ID: <060.30a29b0bc926f4a6607f96988cca60c6@haskell.org> #12990: Partially applied constructors with unpacked fields simplified badly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Inlining 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: | -------------------------------------+------------------------------------- Comment (by simonpj): No, it's fine. In the example, if we inline C we get {{{ ...(let w = \pq. case x of I# x1 case p of I# p1 -> case q of I# q1 -> C x1 p1 q1 in ...(w p q)...)... }}} which is fine. The comment was just saying that if we choose ''not'' to inline then we do want `w` to see the strictness via `C`'s strictness signature. So please do give it a try. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 21 14:33:03 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Dec 2016 14:33:03 -0000 Subject: [GHC] #13021: Inaccessible RHS warning is confusing for users In-Reply-To: <049.555b28c752b0039d3740af545c7af8be@haskell.org> References: <049.555b28c752b0039d3740af545c7af8be@haskell.org> Message-ID: <064.c2e3e8eefe27afec25754acc4f37a817@haskell.org> #13021: Inaccessible RHS warning is confusing for users -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I'm with @gkaracha here in that I would want these messages to remain separate. On the other hand, I'd love it if we could put URLs in error messages (perhaps enabled by a `-fprint-info-links` flag or some such) so that confused users can get more information. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 21 14:39:06 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Dec 2016 14:39:06 -0000 Subject: [GHC] #13021: Inaccessible RHS warning is confusing for users In-Reply-To: <049.555b28c752b0039d3740af545c7af8be@haskell.org> References: <049.555b28c752b0039d3740af545c7af8be@haskell.org> Message-ID: <064.106cc229074405380bb97c1f73f13575@haskell.org> #13021: Inaccessible RHS warning is confusing for users -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): How is a user expected to react to this warning? It seems that they can't act on it without changing the semantics of their program. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 21 14:46:06 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Dec 2016 14:46:06 -0000 Subject: [GHC] #13021: Inaccessible RHS warning is confusing for users In-Reply-To: <049.555b28c752b0039d3740af545c7af8be@haskell.org> References: <049.555b28c752b0039d3740af545c7af8be@haskell.org> Message-ID: <064.8e704f6965a73318e4c65e553958255d@haskell.org> #13021: Inaccessible RHS warning is confusing for users -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Do you have an example that we could contemplate? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 21 14:57:50 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Dec 2016 14:57:50 -0000 Subject: [GHC] #12985: GHCi incorrectly reports the kind of unboxed tuples spliced in from Template Haskell In-Reply-To: <050.ad0392c4ae751e995d3259a41b13bc35@haskell.org> References: <050.ad0392c4ae751e995d3259a41b13bc35@haskell.org> Message-ID: <065.c81e6f6a5459d95ae01b10c2a183a3a5@haskell.org> #12985: GHCi incorrectly reports the kind of unboxed tuples spliced in from Template Haskell -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.3 Component: Template Haskell | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #12976 | Differential Rev(s): Phab:D2886 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Sure. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 21 14:59:58 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Dec 2016 14:59:58 -0000 Subject: [GHC] #12997: Build broken on OpenBSD In-Reply-To: <046.c0878bd6997bef3bde75ecc5cab79db4@haskell.org> References: <046.c0878bd6997bef3bde75ecc5cab79db4@haskell.org> Message-ID: <061.204f3a336882ffd536bab1a0db8fa81a@haskell.org> #12997: Build broken on OpenBSD -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.2-rc2 Resolution: fixed | Keywords: Operating System: OpenBSD | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.0` as c5f375c53671130c79713800b13a1da53d070b84. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 21 15:10:00 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Dec 2016 15:10:00 -0000 Subject: [GHC] #13021: Inaccessible RHS warning is confusing for users In-Reply-To: <049.555b28c752b0039d3740af545c7af8be@haskell.org> References: <049.555b28c752b0039d3740af545c7af8be@haskell.org> Message-ID: <064.9e327e6b1e10feb4d46dc029f5cc0815@haskell.org> #13021: Inaccessible RHS warning is confusing for users -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): It is easy to trigger cases like this with `COMPLETE` signatures as they are currently designed. For example, {{{ data T = A | B | C {-# COMPLETE B #-} foo :: T -> () foo A = () foo B = () }}} Then the first match is reported as having an inaccessible RHS. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 21 15:22:40 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Dec 2016 15:22:40 -0000 Subject: [GHC] #13021: Inaccessible RHS warning is confusing for users In-Reply-To: <049.555b28c752b0039d3740af545c7af8be@haskell.org> References: <049.555b28c752b0039d3740af545c7af8be@haskell.org> Message-ID: <064.05bed7142d46818719aad91d2355a792@haskell.org> #13021: Inaccessible RHS warning is confusing for users -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by gkaracha): Yes, it makes sense in these cases, since they are actually semantically wrong. But is there an example for a meaningful `COMPLETE` set? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 21 16:00:12 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Dec 2016 16:00:12 -0000 Subject: [GHC] #12846: On Windows, runtime linker can't find function defined in GHC's RTS In-Reply-To: <050.6e89ccdbaa0dc1f00c00cc79c48b1c94@haskell.org> References: <050.6e89ccdbaa0dc1f00c00cc79c48b1c94@haskell.org> Message-ID: <065.3cd016512a16e8407d334f09d29e1dd7@haskell.org> #12846: On Windows, runtime linker can't find function defined in GHC's RTS -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.3 Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: fixed | Keywords: Operating System: Windows | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #12891 | Differential Rev(s): Phab:D2727 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: closed => merge * milestone: => 8.0.3 Comment: In case we don't get a more comprehensive solution, could we merge this into GHC 8.0.3? This patch allows the `atomic-primops` package to have API parity on Windows. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 21 16:13:51 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Dec 2016 16:13:51 -0000 Subject: [GHC] #13023: strange behaviour of GHCi when int value exceed int range Message-ID: <044.6c26709c1f5fe32a3b8edc6a044cecf4@haskell.org> #13023: strange behaviour of GHCi when int value exceed int range -------------------------------------+------------------------------------- Reporter: vanto | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHCi crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- import Data.Char type Bit = Int int2bin :: Int -> [Bit] int2bin 0 = [] int2bin n = reverse (n `mod`2 : (reverse (int2bin (n `div`2)))) When n = 4200000000, GHCi crash with "out of memory" but if n = 4300000000 GHCi send a result as [1,0,0,1,1,0,0,1,1,0,0,1,0,1,1,0,0,0,0,0,0,0,0] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 21 16:38:27 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Dec 2016 16:38:27 -0000 Subject: [GHC] #13021: Inaccessible RHS warning is confusing for users In-Reply-To: <049.555b28c752b0039d3740af545c7af8be@haskell.org> References: <049.555b28c752b0039d3740af545c7af8be@haskell.org> Message-ID: <064.d1ee78b699e3da3d36fdb498e6ab23bc@haskell.org> #13021: Inaccessible RHS warning is confusing for users -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): I don't understand what is going on in this example. Suppose `B` was a pattern synonym and we couldn't see its definition. Then the `COMPLETE` pragma could be semantically correct. But if we match `A` before `B` then the match isn't redundant, the behavior of the function could be different in the `A` case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 21 16:42:55 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Dec 2016 16:42:55 -0000 Subject: [GHC] #13023: strange behaviour of GHCi when int value exceed int range In-Reply-To: <044.6c26709c1f5fe32a3b8edc6a044cecf4@haskell.org> References: <044.6c26709c1f5fe32a3b8edc6a044cecf4@haskell.org> Message-ID: <059.33a8fc801e8a0bcd341ad3407948056a@haskell.org> #13023: strange behaviour of GHCi when int value exceed int range -------------------------------------+------------------------------------- Reporter: vanto | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => closed * resolution: => invalid Comment: I assume this is on a 32-bit system. Consider the fact that {{{(-1) `div` 2 = -1}}} and that repeatedly applying {{{`div` 2}}} to a negative `Int` (like `4200000000 = -94967296`) will eventually reach `-1`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 21 16:48:35 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Dec 2016 16:48:35 -0000 Subject: [GHC] #13024: T12877 intermittently fails Message-ID: <045.3c59c53df50d34990b5db3912b14b08f@haskell.org> #13024: T12877 intermittently fails -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Test Suite | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I recently ran a validate where this failed: {{{ bytes allocated value is too high: Expected T12877(normal) bytes allocated: 135979000 +/-5% Lower bound T12877(normal) bytes allocated: 129180050· Upper bound T12877(normal) bytes allocated: 142777950· Actual T12877(normal) bytes allocated: 143317872· Deviation T12877(normal) bytes allocated: 5.4 % *** unexpected stat test failure for T12877(normal) }}} When I reran the test by itself, it passed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 21 16:49:21 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Dec 2016 16:49:21 -0000 Subject: [GHC] #12485: -package-db flags now need to be sorted by dependency order In-Reply-To: <046.f45f4e1dd51039e21d0c213551e30b34@haskell.org> References: <046.f45f4e1dd51039e21d0c213551e30b34@haskell.org> Message-ID: <061.c1b37fd9ac226077a8901d60ef75ea3d@haskell.org> #12485: -package-db flags now need to be sorted by dependency order -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.3 Component: Package system | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D2613 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"ee4e1654c31b9c6f6ad9b19ece25f040bbbcbd72/ghc" ee4e165/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ee4e1654c31b9c6f6ad9b19ece25f040bbbcbd72" Support for abi-depends for computing shadowing. Summary: This is a complete fix based off of ed7af26606b3a605a4511065ca1a43b1c0f3b51d for handling shadowing and out-of-order -package-db flags simultaneously. The general strategy is we first put all databases together, overriding packages as necessary. Once this is done, we successfully prune out broken packages, including packages which depend on a package whose ABI differs from the ABI we need. Our check gracefully degrades in the absence of abi-depends, as we only check deps which are recorded in abi-depends. Contains time and Cabal submodule update. Signed-off-by: Edward Z. Yang Test Plan: validate Reviewers: niteria, austin, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2846 GHC Trac Issues: #12485 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 21 16:56:05 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Dec 2016 16:56:05 -0000 Subject: [GHC] #12485: -package-db flags now need to be sorted by dependency order In-Reply-To: <046.f45f4e1dd51039e21d0c213551e30b34@haskell.org> References: <046.f45f4e1dd51039e21d0c213551e30b34@haskell.org> Message-ID: <061.5c8b24bafac959433717570433cbf2da@haskell.org> #12485: -package-db flags now need to be sorted by dependency order -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.3 Component: Package system | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D2613 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * status: patch => closed * resolution: => fixed Comment: Now fixed in HEAD! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 21 17:02:40 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Dec 2016 17:02:40 -0000 Subject: [GHC] #13018: TH-spliced pattern synonym declaration fails to typecheck In-Reply-To: <050.321896de80824d0ab018c753e6e2c2e9@haskell.org> References: <050.321896de80824d0ab018c753e6e2c2e9@haskell.org> Message-ID: <065.169eb5750ea19294b35d474b9b9eac74@haskell.org> #13018: TH-spliced pattern synonym declaration fails to typecheck -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): The quoting mechanism doesn't appear to be at fault here, since you can trigger the same bug using only `Language.Haskell.TH`: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE PatternSynonyms #-} {-# LANGUAGE TemplateHaskell #-} module Bug where import Language.Haskell.TH data T a where MkT :: Eq b => b -> T a $(do pName <- newName "P" aName <- newName "a" bName <- newName "b" xName <- newName "x" return [ PatSynSigD pName (ForallT [PlainTV bName,PlainTV aName] [] (ForallT [] [] (AppT (AppT ArrowT (VarT bName)) (AppT (ConT ''T) (VarT aName))))) , PatSynD pName (PrefixPatSyn [xName]) Unidir (ConP 'MkT [VarP xName]) ] ) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 21 17:11:46 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Dec 2016 17:11:46 -0000 Subject: [GHC] #13024: T12877 intermittently fails In-Reply-To: <045.3c59c53df50d34990b5db3912b14b08f@haskell.org> References: <045.3c59c53df50d34990b5db3912b14b08f@haskell.org> Message-ID: <060.d0872acaf4bd89affc657efd67f1d494@haskell.org> #13024: T12877 intermittently fails -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: patch Priority: low | Milestone: Component: Test Suite | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2883 Wiki Page: | -------------------------------------+------------------------------------- Changes (by hsyl20): * status: new => patch * differential: => Phab:D2883 Comment: There is already a patch for this one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 21 17:12:00 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Dec 2016 17:12:00 -0000 Subject: [GHC] #13021: Inaccessible RHS warning is confusing for users In-Reply-To: <049.555b28c752b0039d3740af545c7af8be@haskell.org> References: <049.555b28c752b0039d3740af545c7af8be@haskell.org> Message-ID: <064.2d49c0ff5a4ed767608c843643084254@haskell.org> #13021: Inaccessible RHS warning is confusing for users -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): The `COMPLETE` pragma is an assertion that writing a function which matches on each of the constructors in the set is total. In this example, for this to be true, there can be no `A` values as if there were, no function just matching on `B` would be total. Thus, the warning about the inaccessible RHS is correct wrt the assertion made by the programmer. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 21 17:28:05 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Dec 2016 17:28:05 -0000 Subject: [GHC] #13021: Inaccessible RHS warning is confusing for users In-Reply-To: <049.555b28c752b0039d3740af545c7af8be@haskell.org> References: <049.555b28c752b0039d3740af545c7af8be@haskell.org> Message-ID: <064.9e11925dec0a4b18f06cfee698857553@haskell.org> #13021: Inaccessible RHS warning is confusing for users -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): My confusion here is at a very basic level. `_` is a pattern such that any set of pattern matches which includes `_` is total. Yet in a function like {{{ f :: Maybe a -> Int f Nothing = 0 f _ = 1 }}} the first equation is not redundant in a practical sense, even though the pattern match would still be total without it. There's more to life than totality of pattern matches. I thought that a `{-# COMPLETE p1, ..., pn #-}` pragma was just supposed to mean that a function that matches all of the `pi` should be regarded as total. It doesn't make any sense to me for the compiler to use this knowledge plus the definitions of the `pi` to make any conclusions about whether other values are possible or not. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 21 17:39:03 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Dec 2016 17:39:03 -0000 Subject: [GHC] #13025: Type family reduction irregularity (change from 7.10.3 to 8.0.1) Message-ID: <046.8df164442eeb4f6a3254ed537eb97826@haskell.org> #13025: Type family reduction irregularity (change from 7.10.3 to 8.0.1) -------------------------------------+------------------------------------- Reporter: acowley | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: TypeFamilies | 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: -------------------------------------+------------------------------------- I was recently made aware that [http://hackage.haskell.org/package/vinyl vinyl]'s performance dramatically deteriorated with GHC 8.0.1 when compared to GHC 7.x. Vinyl is an extensible records library that's been around for about four years; the aspect of its design relevant here is the basic HList-style indexed GADT. Care was taken in the past so that working with, say, a `Storable` `Vector` of records would suffer no overhead from `vinyl` when compared with standard records, and we have a benchmark suite to spot check this. In the move to GHC-8.0.1, it turns out that we do introduce overhead. Inspecting the Core reveals that the benchmark inner loop includes a `case` match on an `HEq_sc` value whose presence I would not expect, and that is not present when compiling with GHC-7.10.3: {{{ case HEq_sc @ Nat @ Nat @ ('S 'Z) @ (RIndex '("normal", V3 Float) '['("tex", V2 Float), '("normal", V3 Float)]) ($s$fRElemar:S_$s$fRElemar:S_$cp1RElem `cast` (N:~[0] _N <'S 'Z>_N _N :: (('S 'Z :: Nat) ~ (RIndex '("normal", V3 Float) '['("tex", V2 Float), '("normal", V3 Float)] :: Nat) :: Constraint) ~R# (('S 'Z :: Nat) ~~ (RIndex '("normal", V3 Float) '['("tex", V2 Float), '("normal", V3 Float)] :: Nat) :: Constraint))) of cobox0 { __DEFAULT -> }}} I have since made an effort to reproduce the issue, and discovered more fragility than I expected. I am attaching two modules: `Rec.hs` defines a kind of record type, `Main.hs` is a test program that I will reproduce here, {{{ {-# LANGUAGE DataKinds #-} module Main where import Rec type MyRec = Rec '[ '("A",Int), '("B",Int), '("C",Int) ] getC :: MyRec -> Int getC = getField (Proxy::Proxy '("C",Int)) doubleC :: MyRec -> MyRec doubleC r = setC (2 * (getC r)) r where setC = set . (Field :: Int -> Field '("C",Int)) main :: IO () main = print (getC (Field 1 :& Field 2 :& Field 3 :& Nil :: MyRec)) }}} If the `doubleC` definition is present, the Core emitted (with `-O2`) includes an `HEq_sc` case in the RHS of `getC`. If `doubleC` is commented out, that `case HEq_sc ...` is no longer present. In this example, the offending piece of Core is, {{{ case HEq_sc @ Nat @ Nat @ (Index '("C", Int) '['("B", Int), '("C", Int)]) @ ('S 'Z) ($s$fHasFieldkr:S_$s$fHasFieldkr:S_$cp1HasField `cast` (N:~[0] _N _N <'S 'Z>_N :: ((Index '("C", Int) '['("B", Int), '("C", Int)] :: Nat) ~ ('S 'Z :: Nat) :: Constraint) ~R# ((Index '("C", Int) '['("B", Int), '("C", Int)] :: Nat) ~~ ('S 'Z :: Nat) :: Constraint))) of cobox1 { __DEFAULT -> }}} If the contents of `Rec.hs` are included in `Main.hs`, the `case HEq_sc ...` is not present in the resulting Core. The result of what looks like a failure to normalize the `Index` type family (or `RIndex` in `vinyl`) manifests as a 2x slowdown in the benchmark available in the `vinyl` repository. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 21 17:39:38 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Dec 2016 17:39:38 -0000 Subject: [GHC] #13025: Type family reduction irregularity (change from 7.10.3 to 8.0.1) In-Reply-To: <046.8df164442eeb4f6a3254ed537eb97826@haskell.org> References: <046.8df164442eeb4f6a3254ed537eb97826@haskell.org> Message-ID: <061.55f9e457831b4f8a47ebe1d19cc0f512@haskell.org> #13025: Type family reduction irregularity (change from 7.10.3 to 8.0.1) -------------------------------------+------------------------------------- Reporter: acowley | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeFamilies 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 acowley): * Attachment "Rec.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 21 17:40:02 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Dec 2016 17:40:02 -0000 Subject: [GHC] #13025: Type family reduction irregularity (change from 7.10.3 to 8.0.1) In-Reply-To: <046.8df164442eeb4f6a3254ed537eb97826@haskell.org> References: <046.8df164442eeb4f6a3254ed537eb97826@haskell.org> Message-ID: <061.d324fc9af5c587416ab245241401e483@haskell.org> #13025: Type family reduction irregularity (change from 7.10.3 to 8.0.1) -------------------------------------+------------------------------------- Reporter: acowley | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeFamilies 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 acowley): * Attachment "Main.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 21 18:06:46 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Dec 2016 18:06:46 -0000 Subject: [GHC] #13025: Type family reduction irregularity (change from 7.10.3 to 8.0.1) In-Reply-To: <046.8df164442eeb4f6a3254ed537eb97826@haskell.org> References: <046.8df164442eeb4f6a3254ed537eb97826@haskell.org> Message-ID: <061.20cc17e9cfb102ac227a0e999049f840@haskell.org> #13025: Type family reduction irregularity (change from 7.10.3 to 8.0.1) -------------------------------------+------------------------------------- Reporter: acowley | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeFamilies 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 kosmikus): * cc: kosmikus (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 21 18:24:26 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Dec 2016 18:24:26 -0000 Subject: [GHC] #12983: Loading temp shared object failed: TemplateHaskell and recompilation In-Reply-To: <049.2c68231d33bee80b5ff9e32f112656cd@haskell.org> References: <049.2c68231d33bee80b5ff9e32f112656cd@haskell.org> Message-ID: <064.27d1030db88d4ad1c3d65f5b47c17646@haskell.org> #12983: Loading temp shared object failed: TemplateHaskell and recompilation -------------------------------------+------------------------------------- Reporter: StefanWehr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: template | haskell, recompilation Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by tvh): * cc: tvh (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 21 18:48:44 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Dec 2016 18:48:44 -0000 Subject: [GHC] #12990: Partially applied constructors with unpacked fields simplified badly In-Reply-To: <045.525d0610bc9f5daed2ba04304bf44d04@haskell.org> References: <045.525d0610bc9f5daed2ba04304bf44d04@haskell.org> Message-ID: <060.387c5816108feeb9216e319ebad472c9@haskell.org> #12990: Partially applied constructors with unpacked fields simplified badly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D2891 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => patch * differential: => D2891 Comment: The change Simon suggests does indeed seem to work. I get the code I want from my `Traversable` test case now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 21 18:49:37 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Dec 2016 18:49:37 -0000 Subject: [GHC] #13025: Type family reduction irregularity (change from 7.10.3 to 8.0.1) In-Reply-To: <046.8df164442eeb4f6a3254ed537eb97826@haskell.org> References: <046.8df164442eeb4f6a3254ed537eb97826@haskell.org> Message-ID: <061.9401e286f9dea1b36897b75eadd3177a@haskell.org> #13025: Type family reduction irregularity (change from 7.10.3 to 8.0.1) -------------------------------------+------------------------------------- Reporter: acowley | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeFamilies 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 int-index): * cc: int-index (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 21 19:58:22 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Dec 2016 19:58:22 -0000 Subject: [GHC] #13014: Seemingly unnecessary marking of a SpecConstr specialization as a loopbreaker In-Reply-To: <046.bf71fcf5057ea2abf5b697ab6f020f45@haskell.org> References: <046.bf71fcf5057ea2abf5b697ab6f020f45@haskell.org> Message-ID: <061.c58233c80af596f0492a6d579beda393@haskell.org> #13014: Seemingly unnecessary marking of a SpecConstr specialization as a loopbreaker -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: SpecConstr 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: | -------------------------------------+------------------------------------- Comment (by nfrisby): Replying to [comment:9 simonpj]: > Can you be more specific about "try very hard"? The thing is, as far as I can see, it ''is'' loop breaker, as my comment shows. That is, not marking it as such would allow arbitrary inlining. My basic thought is that `DEEP_SPEC` is to `SPEC` as `SPECIALIZE INLINE` is to `SPECIALIZE`. (Thus, `SPEC_INLINE` might be a better/more consistent name than `DEEP_SPEC`.) The hypothetical power user would intentionally choose `DEEP_SPEC` instead of `SPEC` specifically to allow arbitrary inlining. With `SPEC` (i.e. normal `-fspec-constr`), GHC assumes the burden of ensuring that the specialization cannot lead to an infinite loop. By choosing `DEEP_SPEC`, the user intentionally transfers this burden from GHC to themselves. The docs for `DEEP_SPEC` would include a warning similar to those already present for `SPECIALIZE INLINE` ("Warning: you can make GHC diverge by using SPECIALISE INLINE on an ordinarily-recursive function") and `RULES` ("GHC makes no attempt to make sure that the rules are confluent or terminating. For example: ... This rule will cause the compiler to go into an infinite loop."). `DEEP_SPEC` would be a tool for the power user who wrote the `f` and `boo` functions you came up with and ''did'' want GHC to inline `f` 7 times so that `boo` was identified as `0` at compile-time. In terms of mechanism, I don't have enough command of `OccAnal` to be much more specific. My basic idea is that it wouldn't mark the specializations as a loopbreaker unless 1) the specialization ''directly calls itself by name'' or 2) for whatever reason, `OccAnal` has no other choice. In other words, GHC would only mark a `DEEP_SPEC` specialization as a loopbreaker if it concluded that not doing so would ''always'' lead to an infinite inlining --- "possibly infinite inlining" would no longer be cause enough to mark a particular specialization as a loopbreaker. I'll mention one last time that I do not have a real-world motivation for this new behavior in-hand. It doesn't seem like an obviously bad idea (buoyed by saying "power user" and "warnings in the docs"). But it's also not obviously better than all currently existing choices for this hypothetical power user! I just haven't thought about this long enough yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 21 22:14:01 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Dec 2016 22:14:01 -0000 Subject: [GHC] #11216: RebindableSyntax with pattern guards needs `fail` In-Reply-To: <047.a0c77911e1a5729e917abc9d45aa382b@haskell.org> References: <047.a0c77911e1a5729e917abc9d45aa382b@haskell.org> Message-ID: <062.e21e9dd18c5b86a08bdb0a2d3053c685@haskell.org> #11216: RebindableSyntax with pattern guards needs `fail` -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: | RebindableSyntax Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T11216 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by cdsmith): This also applies to bindings in list comprehensions, and is still happening as of GHC 8.0.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 21 22:35:55 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Dec 2016 22:35:55 -0000 Subject: [GHC] #13014: Seemingly unnecessary marking of a SpecConstr specialization as a loopbreaker In-Reply-To: <046.bf71fcf5057ea2abf5b697ab6f020f45@haskell.org> References: <046.bf71fcf5057ea2abf5b697ab6f020f45@haskell.org> Message-ID: <061.8640b3a07675c24916c9cfc9c7aed45a@haskell.org> #13014: Seemingly unnecessary marking of a SpecConstr specialization as a loopbreaker -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: SpecConstr 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: | -------------------------------------+------------------------------------- Comment (by simonpj): OK fine. Let's leave this thread open and return to it if we have applications. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 21 23:12:01 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Dec 2016 23:12:01 -0000 Subject: [GHC] #13025: Type family reduction irregularity (change from 7.10.3 to 8.0.1) In-Reply-To: <046.8df164442eeb4f6a3254ed537eb97826@haskell.org> References: <046.8df164442eeb4f6a3254ed537eb97826@haskell.org> Message-ID: <061.e964610c068abb23ab74b185da05b1f8@haskell.org> #13025: Type family reduction irregularity (change from 7.10.3 to 8.0.1) -------------------------------------+------------------------------------- Reporter: acowley | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeFamilies 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 RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 21 23:36:48 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Dec 2016 23:36:48 -0000 Subject: [GHC] #13018: TH-spliced pattern synonym declaration fails to typecheck In-Reply-To: <050.321896de80824d0ab018c753e6e2c2e9@haskell.org> References: <050.321896de80824d0ab018c753e6e2c2e9@haskell.org> Message-ID: <065.1695de266536e8f2b6c864ddf08d8a30@haskell.org> #13018: TH-spliced pattern synonym declaration fails to typecheck -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * component: Template Haskell => Compiler (Type checker) Comment: It turns out this has nothing whatsoever to do with Template Haskell. The real culprit is `forall`. That is, while this program compiles without issue: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE PatternSynonyms #-} {-# LANGUAGE ScopedTypeVariables #-} module M where data T a where MkT :: Eq b => b -> T a pattern P :: b -> T a pattern P x <- MkT x }}} Changing the pattern signature to this: {{{#!hs pattern P :: forall b a. b -> T a }}} causes the error to appear: {{{ Bug.hs:10:20: error: • Couldn't match expected type ‘b’ with actual type ‘b1’ ‘b1’ is a rigid type variable bound by a pattern with constructor: MkT :: forall a b. Eq b => b -> T a, in a pattern synonym declaration at Bug.hs:10:16-20 ‘b’ is a rigid type variable bound by the signature for pattern synonym ‘P’ at Bug.hs:9:21 • In the declaration for pattern synonym ‘P’ • Relevant bindings include x :: b1 (bound at Bug.hs:10:20) }}} It turns out that when you quote a pattern synonym declaration with TH quotes, it implicitly adds the `forall` behind the scenes, triggering this bug when you try to splice it back in. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 21 23:43:09 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Dec 2016 23:43:09 -0000 Subject: [GHC] #13018: TH-spliced pattern synonym declaration fails to typecheck In-Reply-To: <050.321896de80824d0ab018c753e6e2c2e9@haskell.org> References: <050.321896de80824d0ab018c753e6e2c2e9@haskell.org> Message-ID: <065.2295044174ec0bd32188771cfdf3b38f@haskell.org> #13018: TH-spliced pattern synonym declaration fails to typecheck -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * version: 8.1 => 8.0.1 Comment: It turns out this is a regression, since this program: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE PatternSynonyms #-} {-# LANGUAGE ScopedTypeVariables #-} module M where data T a where MkT :: Eq b => b -> T a pattern P :: forall b a. b -> T a pattern P x <- MkT x }}} compiles with GHC 7.10.3, but not with GHC 8.0.1, 8.0.2, or HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 22 00:36:43 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Dec 2016 00:36:43 -0000 Subject: [GHC] #13018: TH-spliced pattern synonym declaration fails to typecheck In-Reply-To: <050.321896de80824d0ab018c753e6e2c2e9@haskell.org> References: <050.321896de80824d0ab018c753e6e2c2e9@haskell.org> Message-ID: <065.f46822db89797816465935da60802434@haskell.org> #13018: TH-spliced pattern synonym declaration fails to typecheck -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): It's not a regression; it's a bug-fix! See Trac #11224. Here's the note from `TcTySigs`: {{{ Note [The pattern-synonym signature splitting rule] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Given a pattern signature, we must split the kind-generalised variables, and the implicitly-bound variables into universal and existential. The rule is this (see discussion on Trac #11224): The universal tyvars are the ones mentioned in - univ_tvs: the user-specified (forall'd) universals - req_theta - res_ty The existential tyvars are all the rest }}} If you provide an explicit forall, they are all universals; but in this case we wanted 'b' to be an existential. According to these rules you can say {{{ pattern P :: b -> T a or pattern P :: forall a. () => forall b. b -> T a }}} We neglected to put this rule in the user manual: that should be fixed. '''Matthew or Ryan, might you do that?''' The TH problem is that TH is taking a quote with an implicit forall, and turning it into a TH data structure with an explicit forall. When that is converted back into `HsSyn` it has an explicit forall, so we get `pattern P :: forall b a. b -> T a`. So the round trip is not faithful. I wonder if we could just genertate TH syntax with an implicit forall? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 22 00:57:00 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Dec 2016 00:57:00 -0000 Subject: [GHC] #13018: TH-spliced pattern synonym declaration fails to typecheck In-Reply-To: <050.321896de80824d0ab018c753e6e2c2e9@haskell.org> References: <050.321896de80824d0ab018c753e6e2c2e9@haskell.org> Message-ID: <065.72581543dc0f47579bc81d413140885e@haskell.org> #13018: TH-spliced pattern synonym declaration fails to typecheck -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Thank you Simon, that's very helpful. I forgot about the need for two `forall`s, and it turns out that as a workaround, you can fix the issue by specifying the `forall`s manually. As evidence, this compiles: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE PatternSynonyms #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TemplateHaskell #-} module M where data T a where MkT :: Eq b => b -> T a $([d| pattern P :: forall a. forall b. b -> T a pattern P x <- MkT x |]) }}} So the only issue to investigate is why this: {{{#!hs $([d| pattern P :: b -> T a pattern P x <- MkT x |]) }}} fails to infer the `forall`s correctly. Replying to [comment:5 simonpj]: > I wonder if we could just genertate TH syntax with an implicit forall? TH is already coming up with an implicit `forall`, just in an incorrect way. Note that this: {{{#!hs $([d| pattern P :: b -> T a pattern P x <- MkT x |]) }}} gets turned into this (as reported by `-ddump-splices`): {{{#!hs [d| pattern P_a1iH :: b_a1iI -> T a_a1iJ pattern P_a1iH x_a1iK <- MkT x_a1iK |] ======> pattern P_a4tM :: forall b_a4tN a_a4tO. b_a4tN -> T a_a4tO pattern P_a4tM x_a4tP <- MkT x_a4tP }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 22 01:14:38 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Dec 2016 01:14:38 -0000 Subject: [GHC] #13026: RFC functions for sums and products Message-ID: <051.dcc6584e5b5e34920ae3e9c70dbd6181@haskell.org> #13026: RFC functions for sums and products -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: | Version: 8.0.1 libraries/base | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'll ask on the libraries mailing list depending on feedback. Adding these to `Data.Functor.Sum`, `Data.Functor.Product` a la `Control.Arrow` {{{!hs (||||) :: (f a -> b) -> (g a -> b) -> ((Sum f g) a -> b) f |||| g = \case InL fa -> f fa InR ga -> g ga (&&&&) :: (a -> f b) -> (a -> g b) -> (a -> (Product f g) b) (f &&&& g) a = f a `Pair` g a }}} `||||` is used in "Monad transformers and modular algebraic effects: What binds them together" in section 2.4, the names are up for discussion -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 22 01:15:21 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Dec 2016 01:15:21 -0000 Subject: [GHC] #13026: RFC functions for sums and products In-Reply-To: <051.dcc6584e5b5e34920ae3e9c70dbd6181@haskell.org> References: <051.dcc6584e5b5e34920ae3e9c70dbd6181@haskell.org> Message-ID: <066.7395f8b7fb771bf39b7c04bd52047b26@haskell.org> #13026: RFC functions for sums and products -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: @@ -6,1 +6,1 @@ - {{{!hs + {{{#!hs New description: I'll ask on the libraries mailing list depending on feedback. Adding these to `Data.Functor.Sum`, `Data.Functor.Product` a la `Control.Arrow` {{{#!hs (||||) :: (f a -> b) -> (g a -> b) -> ((Sum f g) a -> b) f |||| g = \case InL fa -> f fa InR ga -> g ga (&&&&) :: (a -> f b) -> (a -> g b) -> (a -> (Product f g) b) (f &&&& g) a = f a `Pair` g a }}} `||||` is used in "Monad transformers and modular algebraic effects: What binds them together" in section 2.4, the names are up for discussion -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 22 01:33:42 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Dec 2016 01:33:42 -0000 Subject: [GHC] #13026: RFC functions for sums and products In-Reply-To: <051.dcc6584e5b5e34920ae3e9c70dbd6181@haskell.org> References: <051.dcc6584e5b5e34920ae3e9c70dbd6181@haskell.org> Message-ID: <066.e007abe2d4c5e19e42ddc10efc47654f@haskell.org> #13026: RFC functions for sums and products -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Some other {{{#!hs type f ~> g = forall x. f x -> g x (****) :: f ~> f' -> g ~> g' -> Product f g ~> Product f' g' (f **** g) (fa `Pair` ga) = f fa `Pair` g ga first' :: f ~> f' -> Product f g ~> Product f' g first' = (**** id) second' :: g ~> g' -> Product f g ~> Product f g' second' = (id ****) (++++) :: f ~> f' -> g ~> g' -> Sum f g ~> Sum f' g' f ++++ g = \case InL fa -> InL (f fa) InR ga -> InR (g ga) left' :: f ~> f' -> Sum f g ~> Sum f' g left' = (++++ id) right' :: g ~> g' -> Sum f g ~> Sum f g' right' = (id ++++) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 22 01:56:55 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Dec 2016 01:56:55 -0000 Subject: [GHC] #13027: Core lint errors compiling containers HEAD with GHC HEAD Message-ID: <044.039b1d41ac9eefe9789d53b67dd9193b@haskell.org> #13027: Core lint errors compiling containers HEAD with GHC HEAD -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Git HEAD of containers compiles fine with ghc-8.0.1, but when compiling with GHC git HEAD gives core lint errors: {{{ *** Core Lint errors : in result of Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) *** : warning: In the expression: tagToEnum# @ Bool (reallyUnsafePtrEquality# @ (Set a) l'_a4Fk l_a4Fi) This argument does not satisfy the let/app invariant: reallyUnsafePtrEquality# @ (Set a) l'_a4Fk l_a4Fi *** Offending Program *** Rec { $dTypeable_s9vn :: Proxy# Set -> TypeRep }}} This issue can be reproduced using: {{{ (cd libraries/containers ; git checkout master ; git pull) perl boot && ./configure && make clean && make -j }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 22 02:34:59 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Dec 2016 02:34:59 -0000 Subject: [GHC] #13018: TH-spliced pattern synonym declaration fails to typecheck In-Reply-To: <050.321896de80824d0ab018c753e6e2c2e9@haskell.org> References: <050.321896de80824d0ab018c753e6e2c2e9@haskell.org> Message-ID: <065.8e674d86ee9ca8b6dd4f6bdd531540f7@haskell.org> #13018: TH-spliced pattern synonym declaration fails to typecheck -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): From a quick investigation, the problematic code seems to be [http://git.haskell.org/ghc.git/blob/41ade95c068e77b916ff17865515eadb353a2358:/compiler/deSugar/DsMeta.hs#l904 repHsPatSynSigType] in `DsMeta`: {{{#!hs repHsPatSynSigType :: LHsSigType Name -> DsM (Core TH.TypeQ) repHsPatSynSigType (HsIB { hsib_vars = implicit_tvs , hsib_body = body }) = addTyVarBinds (newTvs (impls ++ univs)) $ \th_univs -> addTyVarBinds (newTvs exis) $ \th_exis -> do { th_reqs <- repLContext reqs ; th_provs <- repLContext provs ; th_ty <- repLTy ty ; repTForall th_univs th_reqs =<< (repTForall th_exis th_provs th_ty) } where impls = map (noLoc . UserTyVar . noLoc) implicit_tvs newTvs tvs = HsQTvs { hsq_implicit = [] , hsq_explicit = tvs , hsq_dependent = emptyNameSet } (univs, reqs, exis, provs, ty) = splitLHsPatSynTy body }}} In this particular example, all of `univs`, `reqs`, `exis`, and `provs` are `[]`. But `impls` is `[b,a]`, which causes `th_univs` to be `[b,a]` as well. In other words, that's why we see the incorrect `forall b a. forall. b -> T a` type signature. Is there a way to partition up `impls` to get `a` in `th_univs` and `b` in `th_exis`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 22 02:41:04 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Dec 2016 02:41:04 -0000 Subject: [GHC] #12939: ghc-8.0.1.20161117 did not install ghc.1 manpage In-Reply-To: <050.1a6f83d836fa085ef75b0067487924cd@haskell.org> References: <050.1a6f83d836fa085ef75b0067487924cd@haskell.org> Message-ID: <065.87f57c9848b938cb9361321d90887b03@haskell.org> #12939: ghc-8.0.1.20161117 did not install ghc.1 manpage ---------------------------------+---------------------------------------- Reporter: juhpetersen | Owner: bgamari Type: bug | Status: infoneeded Priority: normal | Milestone: 8.0.2 Component: Build System | Version: 8.0.2-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by bgamari): * status: new => infoneeded Comment: So I'm rather perplexed. I checked the rc2 binary distributions and found that the `i386-deb8-linux`, `x86_64-deb8-linux`, `x86_64-unknown-mingw32`, and `x86_64-apple-darwin` distributions all contain a `ghc.1` manpage. I also verified that `ghc.1` was installed to `$prefix/share/man/man1` as expected. Finally, I checked the rc1 `x86_64-deb8-linux` tarball and confirmed that it too has a `ghc.1`. What am I missing here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 22 03:04:53 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Dec 2016 03:04:53 -0000 Subject: [GHC] #13027: Core lint errors compiling containers HEAD with GHC HEAD In-Reply-To: <044.039b1d41ac9eefe9789d53b67dd9193b@haskell.org> References: <044.039b1d41ac9eefe9789d53b67dd9193b@haskell.org> Message-ID: <059.1f853d20bc7266b9d99bc20b337c3229@haskell.org> #13027: Core lint errors compiling containers HEAD with GHC HEAD -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: dfeuer (added) Comment: I'm not entirely sure if this is a GHC bug. For one thing, you don't need GHC HEAD to reproduce this - you could just as well use GHC 8.0.1. Here is a minimized test case (taken from the source code of `containers` HEAD): {{{#!hs {-# LANGUAGE BangPatterns #-} {-# LANGUAGE MagicHash #-} module Containers (insert) where import GHC.Exts (isTrue#, reallyUnsafePtrEquality#) data Set a = Bin {-# UNPACK #-} !Size !a !(Set a) !(Set a) | Tip type Size = Int insert :: Ord a => a -> Set a -> Set a insert = go where go :: Ord a => a -> Set a -> Set a go !x Tip = Bin 1 x Tip Tip go !x t@(Bin sz y l r) = case compare x y of LT | l' `ptrEq` l -> t | otherwise -> undefined -- balanceL y l' r where !l' = go x l GT | r' `ptrEq` r -> t | otherwise -> undefined -- balanceR y l r' where !r' = go x r EQ | x `ptrEq` y -> t | otherwise -> Bin sz x l r {-# INLINABLE insert #-} ptrEq :: a -> a -> Bool ptrEq x y = isTrue# (reallyUnsafePtrEquality# x y) {-# INLINE ptrEq #-} }}} If you compile this with `/opt/ghc/8.0.1/bin/ghc Containers.hs -dcore-lint -O2`, you'll get a very similar Core Lint error. The culprit seems to be the suspicious use of `reallyUnsafePtrEquality#` in `ptrEq`. Any thoughts on this, David? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 22 03:40:53 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Dec 2016 03:40:53 -0000 Subject: [GHC] #13027: Core lint errors compiling containers HEAD with GHC HEAD In-Reply-To: <044.039b1d41ac9eefe9789d53b67dd9193b@haskell.org> References: <044.039b1d41ac9eefe9789d53b67dd9193b@haskell.org> Message-ID: <059.4896aefef68f8520b1a94548f91f1c3f@haskell.org> #13027: Core lint errors compiling containers HEAD with GHC HEAD -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Based on my extremely naive reading of the let/app invariant note, I'm *guessing* that the simplifier may be doing something weird like {{{#!hs ptrEq x y = let r = reallyUnsafePtrEquality# x y in isTrue# r }}} when it really should be doing {{{#!hs ptrEq x y = case reallyUnsafePtrEquality# x y of r -> isTrue# r }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 22 03:59:46 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Dec 2016 03:59:46 -0000 Subject: [GHC] #13027: Core lint errors compiling containers HEAD with GHC HEAD In-Reply-To: <044.039b1d41ac9eefe9789d53b67dd9193b@haskell.org> References: <044.039b1d41ac9eefe9789d53b67dd9193b@haskell.org> Message-ID: <059.fe57438980fc29f254b09fbc4d03c2ac@haskell.org> #13027: Core lint errors compiling containers HEAD with GHC HEAD -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): A workaround is to define your own `isTrue#` function: {{{#!hs isTrue# :: Int# -> Bool isTrue# 1# = True isTrue# _ = False {-# INLINE isTrue# #-} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 22 04:01:33 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Dec 2016 04:01:33 -0000 Subject: [GHC] #8107: need types to express constant argument for primop correctness In-Reply-To: <045.7a159c5513dff4683fe6798d6101cb07@haskell.org> References: <045.7a159c5513dff4683fe6798d6101cb07@haskell.org> Message-ID: <060.08481ae7c5f2dd7664b17c2ff1582a88@haskell.org> #8107: need types to express constant argument for primop correctness -------------------------------------+------------------------------------- Reporter: carter | Owner: carter Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 8252 Related Tickets: #8131 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * cc: Iceland_jack (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 22 04:40:31 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Dec 2016 04:40:31 -0000 Subject: [GHC] #13027: Core lint errors compiling containers HEAD with GHC HEAD In-Reply-To: <044.039b1d41ac9eefe9789d53b67dd9193b@haskell.org> References: <044.039b1d41ac9eefe9789d53b67dd9193b@haskell.org> Message-ID: <059.96ff1457af2492d5b753e5d43403965e@haskell.org> #13027: Core lint errors compiling containers HEAD with GHC HEAD -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): It also gives a core lint error as early as 7.10.1. I found that early on the simplifier produces {{{ case x_a3Iw of x_X3IE { __DEFAULT -> ... case GHC.Prim.tagToEnum# @ Bool (reallyUnsafePtrEquality# @ a x_X3IE y_a3IA) of { ... } } }}} This is apparently okay: the application of `tagToEnum#` to the `reallyUnsafePtrEquality#` call is okay because `reallyUnsafePtrEquality#` is safe for speculation and the arguments `x_X3IE` and `y_a3IA` are known to be evaluated (`x_X3IE` came from evaluating the scrutinee of a case and `y_a3IA` came from the strict field of `Bin`). However the FloatOut pass does a "binder swap" (https://github.com/ghc/ghc/blob/master/compiler/simplCore/SetLevels.hs#L37) where it turns the reference to `x_X3IE` into a reference to `x_a3Iw`. Now `x_a3Iw` is not known to be evaluated so `reallyUnsafePtrEquality#` is no longer considered to be safe for speculation. (Even though `reallyUnsafePtrEquality#` doesn't actually evaluate its arguments.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 22 04:43:55 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Dec 2016 04:43:55 -0000 Subject: [GHC] #13027: Core lint errors compiling containers HEAD with GHC HEAD In-Reply-To: <044.039b1d41ac9eefe9789d53b67dd9193b@haskell.org> References: <044.039b1d41ac9eefe9789d53b67dd9193b@haskell.org> Message-ID: <059.71ec44efa43e0bcfc8ba32f8b80fb835@haskell.org> #13027: Core lint errors compiling containers HEAD with GHC HEAD -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): It doesn't fail before 7.10.1 because earlier versions didn't check the let/app invariant in core lint. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 22 04:47:58 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Dec 2016 04:47:58 -0000 Subject: [GHC] #13027: Core lint errors compiling containers HEAD with GHC HEAD In-Reply-To: <044.039b1d41ac9eefe9789d53b67dd9193b@haskell.org> References: <044.039b1d41ac9eefe9789d53b67dd9193b@haskell.org> Message-ID: <059.93bd7a3a88ce80ec1a1fd69d5f4ad5ce@haskell.org> #13027: Core lint errors compiling containers HEAD with GHC HEAD -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): I want to be able to test for equal thunks too. Is there something I can do to make this just work? Should I work around it by using `case` instead of `isTrue#`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 22 06:51:04 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Dec 2016 06:51:04 -0000 Subject: [GHC] #13025: Type family reduction irregularity (change from 7.10.3 to 8.0.1) In-Reply-To: <046.8df164442eeb4f6a3254ed537eb97826@haskell.org> References: <046.8df164442eeb4f6a3254ed537eb97826@haskell.org> Message-ID: <061.fb90b090c3f46aa745f482176309a7a7@haskell.org> #13025: Type family reduction irregularity (change from 7.10.3 to 8.0.1) -------------------------------------+------------------------------------- Reporter: acowley | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeFamilies 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 RyanGlScott): * cc: simonpj (added) Comment: Simon, this regression was caused by commit ff752a1a5eb69955c0e4fda8647f495409a2c384. Thoughts? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 22 07:42:38 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Dec 2016 07:42:38 -0000 Subject: [GHC] #13025: Type family reduction irregularity (change from 7.10.3 to 8.0.1) In-Reply-To: <046.8df164442eeb4f6a3254ed537eb97826@haskell.org> References: <046.8df164442eeb4f6a3254ed537eb97826@haskell.org> Message-ID: <061.03715b7846d57927b707436bdd8ebfa6@haskell.org> #13025: Type family reduction irregularity (change from 7.10.3 to 8.0.1) -------------------------------------+------------------------------------- Reporter: acowley | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeFamilies 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 RyanGlScott): * cc: simonpj (removed) * cc: goldfire (added) Comment: Ack, I was looking at the wrong commit previously. Apologies. It turns out the real culprit behind this regression is 1722fa106e10e63160bb2322e2ccb830fd5b9ab3 (by Richard). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 22 08:45:21 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Dec 2016 08:45:21 -0000 Subject: [GHC] #13028: Compile-time validation of literals in IsString instances Message-ID: <042.c6b5c8529e767d5ca99bfcc90fb560c4@haskell.org> #13028: Compile-time validation of literals in IsString instances -------------------------------------+------------------------------------- Reporter: jml | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I would like to be able to make `IsString` instances using the `OverloadedStrings` extension such that my instance rejects some literals as being invalid and such that that rejection happens at compile time, so that programming mistakes don't make it into the code I give to my users. I have a couple of use cases where I have a `Name` type that only admits certain strings. e.g. {{{#!hs module Name (Name(getName), makeName) where import Data.Text (Text) import qualified Data.Text as Text -- | A guaranteed non-empty name. newtype Name = Name { getName :: Text } deriving (Eq, Show, Ord) makeName :: Text -> Maybe Name makeName name | Text.null name = Nothing | otherwise = Just name }}} In a real use case, I'd check for valid characters, not starting with a digit, that sort of thing. The idea is that we don't export the `Name` constructor, which means anyone using a `Name` value can trust that it has certain properties (in this case, non-empty). My problem is that I'd like to use literal names in many places. e.g. {{{#!hs programName :: Name programName = fromJust $ makeName "the-great-and-powerful-turtle" }}} Because I do this a lot, I've defined an `unsafeMakeName` helper that does pretty much the same thing: {{{#!hs unsafeMakeName :: Text -> Name unsafeMakeName name = fromMaybe (error $ "Invalid name: " <> Text.unpack name) (makeName name) }}} The problem with this approach is that even though the cause of the mistake is a programming error, I don't find out about it until run time. What I'd like to do is write an `IsString` instance for `Name` which does that validation, e.g. {{{#!hs instance IsString Name where fromString = unsafeMakeName . Text.pack }}} ... but to get the error about invalid names in literals at compile-time. This doesn't seem logically impossible to me, since the compiler could know the values of literals with certainty. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 22 11:15:12 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Dec 2016 11:15:12 -0000 Subject: [GHC] #12999: Investigate use of floating-point arithmetic in I/O Event-handler In-Reply-To: <042.d9e72583afa2ded1431f4a089ec3a9ba@haskell.org> References: <042.d9e72583afa2ded1431f4a089ec3a9ba@haskell.org> Message-ID: <057.53f442d6d31dc875d78197e156e28610@haskell.org> #12999: Investigate use of floating-point arithmetic in I/O Event-handler -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by winter): Recently when i'm digging into RTS's code, this design confused me too. After some research it seems there's a much better plan: [https://www.reddit.com/r/haskell/comments/28vev9/announcing_psqueues_faster_priority_search_queues/cif87km/]. I'll looking into it when i got time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 22 11:34:44 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Dec 2016 11:34:44 -0000 Subject: [GHC] #12999: Investigate use of floating-point arithmetic in I/O Event-handler In-Reply-To: <042.d9e72583afa2ded1431f4a089ec3a9ba@haskell.org> References: <042.d9e72583afa2ded1431f4a089ec3a9ba@haskell.org> Message-ID: <057.7b76af4d394b86828d498d4d5428172f@haskell.org> #12999: Investigate use of floating-point arithmetic in I/O Event-handler -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by davean): That is just a faster version of the wrong thing. This bug was filed because I was working on fixing it correctly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 22 12:33:39 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Dec 2016 12:33:39 -0000 Subject: [GHC] #11501: Building nofib/fibon returns permission denied In-Reply-To: <042.7732253ef90810c7acc41907aecb19ff@haskell.org> References: <042.7732253ef90810c7acc41907aecb19ff@haskell.org> Message-ID: <057.60049ae996efaddb74111b03b59a23d0@haskell.org> #11501: Building nofib/fibon returns permission denied -------------------------------------+------------------------------------- Reporter: rem | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: NoFib benchmark | Version: 7.10.3 suite | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: gracjanpolak@… (added) Comment: Gracjan says (email to ghc-devs): I went into the rabbit hole that starts here So far I know that: 1. fibon is not built regularly by any CI and it bitrotted significantly. 2. Makefile's for fibon use undefined variables like INPLACE_HSC2HS_PGM. Probably those were sourced from ghc/mk/*.mk, but not now. 3. Haskell courses are pre-AMP (this is easiest to fix). 4. Makefile's build object files one by one and that fails in case modules depend on each other. ghc-paths.mk sorts objects and that gives wrong compile order. Does anybody know a commit-hash or date when it did compile last time? Knowing that this module (fibon) wasn't used for so long does it make sense to fix it? How about removing it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 22 12:34:31 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Dec 2016 12:34:31 -0000 Subject: [GHC] #11501: Building nofib/fibon returns permission denied In-Reply-To: <042.7732253ef90810c7acc41907aecb19ff@haskell.org> References: <042.7732253ef90810c7acc41907aecb19ff@haskell.org> Message-ID: <057.15a3b8970eb18a258bd9384c618773f2@haskell.org> #11501: Building nofib/fibon returns permission denied -------------------------------------+------------------------------------- Reporter: rem | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: NoFib benchmark | Version: 7.10.3 suite | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * cc: gracjanpolak@… (removed) * cc: gracjan (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 22 12:34:37 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Dec 2016 12:34:37 -0000 Subject: [GHC] #11501: Building nofib/fibon returns permission denied In-Reply-To: <042.7732253ef90810c7acc41907aecb19ff@haskell.org> References: <042.7732253ef90810c7acc41907aecb19ff@haskell.org> Message-ID: <057.71b14a26ec5f85cddf38280af23a8187@haskell.org> #11501: Building nofib/fibon returns permission denied -------------------------------------+------------------------------------- Reporter: rem | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: NoFib benchmark | Version: 7.10.3 suite | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: gracjan (removed) * cc: gracjanpolak@… (added) Comment: I have no idea when it last worked. Below is a log of the most commits.. mostly back in 2014. The `nofib/fibon/shootout` programs are (I think) also in `nofib/shootout`. Worth checking. The `nofib/fibon/Repa` and `Hackage` programs look quite useful. `nofib` is old, and we could really do with more. So the ones in there might be jolly useful. Let's resurrect it not kill it! THANK YOU! Simon {{{ git log -8 fibon commit 35fc121fc8cc501ea2713c579a053be7ea65b16e Author: Seraphime Kirkovski Date: Sun May 22 17:47:26 2016 +0200 Fix: #12084 deprecate old profiling flags commit f9a577973edf6976e4c0703bf2afac900d7b6fd8 Author: Gabor Greif Date: Fri Jul 31 00:43:38 2015 +0200 Typos in comments commit c9c20d477088a8a7d5747f16afdf0652fba6dadf Author: Joachim Breitner Date: Tue Sep 2 17:53:52 2014 +0200 Hide Word from Prelude in benchmarks where Word is used. This fixes fall-out from #9531. commit 77a87f18166aa4c806e33b0adf4c2fbe40551a4f Author: Gabor Greif Date: Fri Jan 10 12:02:06 2014 +0100 fix some typos commit b9d8bcdd929d664539843f96e56b50800f623891 Author: Krzysztof Gogolewski Date: Tue Sep 3 21:23:09 2013 +0200 Remove deprecated _scc_ (#8170) commit eb9f4a3ff7f3b24896534011717099c9d61e146d Author: Johan Tibell Date: Tue Feb 5 15:50:23 2013 -0800 Removed some shootout benchmarks from under fibon Newer versions (corresponding to what's currently on the shootout page) have been added under nofib/shootout in an attempt to make these easier to run. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 22 12:44:12 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Dec 2016 12:44:12 -0000 Subject: [GHC] #11501: Building nofib/fibon returns permission denied In-Reply-To: <042.7732253ef90810c7acc41907aecb19ff@haskell.org> References: <042.7732253ef90810c7acc41907aecb19ff@haskell.org> Message-ID: <057.cbfc4f4ed9de787ead73e2294a7e9edf@haskell.org> #11501: Building nofib/fibon returns permission denied -------------------------------------+------------------------------------- Reporter: rem | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: NoFib benchmark | Version: 7.10.3 suite | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by gracjan): How `nofib/fibon` is supposed to be used? I tried to understand `README` but I still do not know. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 22 14:58:11 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Dec 2016 14:58:11 -0000 Subject: [GHC] #13029: Dead code in DsCCall? Message-ID: <047.81a7bd71039b9caebe1d23ea4c77fb14@haskell.org> #13029: Dead code in DsCCall? -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Simon and I were poring over `DsCCall.mk_alt`, and we seem to think that the first case (for unboxed tuples) is dead code. If it's live, it's utterly broken because it ignores the `RuntimeRep` args to an unboxed tuple. This ticket is to remind us to continue investigating. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 22 15:00:14 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Dec 2016 15:00:14 -0000 Subject: [GHC] #13025: Type family reduction irregularity (change from 7.10.3 to 8.0.1) In-Reply-To: <046.8df164442eeb4f6a3254ed537eb97826@haskell.org> References: <046.8df164442eeb4f6a3254ed537eb97826@haskell.org> Message-ID: <061.388a07f38624b71d9ebe3232227994a3@haskell.org> #13025: Type family reduction irregularity (change from 7.10.3 to 8.0.1) -------------------------------------+------------------------------------- Reporter: acowley | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeFamilies 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: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): acowley, you mentioned that there was a "2x slowdown in the benchmark available in the `vinyl` repository". But I see [https://github.com/VinylRecords/Vinyl/blob/7f436533ba0680434053629df1f844fdb58cb4fe/vinyl.cabal#L37-L51 two benchmarks]. Which benchmark suffered the slowdown? I'd like to verify the change in runtime speed before and after commit 1722fa106e10e63160bb2322e2ccb830fd5b9ab3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 22 15:05:43 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Dec 2016 15:05:43 -0000 Subject: [GHC] #13017: GHC panics during build of etkmett/free In-Reply-To: <047.eaea3642af74a01d8da738049f8757aa@haskell.org> References: <047.eaea3642af74a01d8da738049f8757aa@haskell.org> Message-ID: <062.56a56d760e3aa557063b988d1bb0f3ae@haskell.org> #13017: GHC panics during build of etkmett/free -------------------------------------+------------------------------------- Reporter: jbayardo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by jbayardo): * Attachment "stack.log" added. Log for `stack -v ghci` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 22 15:11:29 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Dec 2016 15:11:29 -0000 Subject: [GHC] #13025: Type family reduction irregularity (change from 7.10.3 to 8.0.1) In-Reply-To: <046.8df164442eeb4f6a3254ed537eb97826@haskell.org> References: <046.8df164442eeb4f6a3254ed537eb97826@haskell.org> Message-ID: <061.ae6766487bae63e3830b3fc578afc801@haskell.org> #13025: Type family reduction irregularity (change from 7.10.3 to 8.0.1) -------------------------------------+------------------------------------- Reporter: acowley | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeFamilies 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: | -------------------------------------+------------------------------------- Comment (by acowley): Thank you for taking a look, @RyanGIScott! It is the first benchmark there, with the unfortunate name `bench-builder-all`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 22 16:38:27 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Dec 2016 16:38:27 -0000 Subject: [GHC] #13030: Build error from following default nixos instructions and -Werror Message-ID: <049.20a4710cafa8774d956b68fa7b88d146@haskell.org> #13030: Build error from following default nixos instructions and -Werror -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When building the RTS with the nixos instructions from the wiki (https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Linux#NixNixOS) if you enable `Werror` then the build fails with warnings from the rts. For example {{{ rts/Interpreter.c: In function ‘interpretBCO’: rts/Interpreter.c:593:41: error: warning: ‘obj’ may be used uninitialized in this function [-Wmaybe- uninitialized] debugBelch("Returning: "); printObj(obj); }}} Is this something I should worry about? Are there additional flags that I should pass to gcc in order to turn these warnings off? The workaround is compile without `-Werror` and then turn it on once the `rts` has been compiled. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 22 16:45:36 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Dec 2016 16:45:36 -0000 Subject: [GHC] #12981: SMP never enabled on ARMv7 In-Reply-To: <044.559338d739806b65d1855740c8ce12dd@haskell.org> References: <044.559338d739806b65d1855740c8ce12dd@haskell.org> Message-ID: <059.bfc9878b6b7349306c856f1ef550c500@haskell.org> #12981: SMP never enabled on ARMv7 ----------------------------------------+------------------------------ Reporter: orion | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Build System | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------ Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged in 7b4ab5bde04c2cd49681068c290a3a19111ea401. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 22 18:22:16 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Dec 2016 18:22:16 -0000 Subject: [GHC] #13026: RFC functions for sums and products In-Reply-To: <051.dcc6584e5b5e34920ae3e9c70dbd6181@haskell.org> References: <051.dcc6584e5b5e34920ae3e9c70dbd6181@haskell.org> Message-ID: <066.a9106a133d7549d9d8fc06f9b098542e@haskell.org> #13026: RFC functions for sums and products -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Stolen from `Data.Tuple`, I have never needed them but who knows {{{#!hs fst' :: Product f g ~> f fst' (Pair fa _) = fa snd' :: Product f g ~> g snd' (Pair _ ga) = ga curry' :: (Product f g ~> h) -> (forall a. f a -> g a -> h a) curry' nat fa ga = nat (Pair fa ga) uncurry' :: (forall a. f a -> g a -> h a) -> (Product f g ~> h) uncurry' f (Pair fa ga) = f fa ga swap' :: Product f g ~> Product g f swap' (Pair fa ga) = Pair ga fa }}} and from `Data.Either` {{{#!hs lefts' :: [(Sum f g) a] -> [f a] lefts' sums = [ fa | InL fa <- sums ] rights' :: [(Sum f g) a] -> [g a] rights' sums = [ ga | InR ga <- sums ] isInL :: Sum f g a -> Bool isInL InL{} = True isInL _ = False isInR :: Sum f g a -> Bool isInR InR{} = True isInR _ = False sum' :: (f a -> c) -> (g a -> c) -> (Sum f g a -> c) sum' f _ (InL x) = f x sum' _ g (InR y) = g y partitionSums :: [Sum f g a] -> ([f a], [g a]) partitionSums = foldr (sum' left right) ([], []) where left a ~(l, r) = (a:l, r) right a ~(l, r) = (l, a:r) }}} With the `lens` vocabulary we could write {{{#!hs _InL :: Prism (Sum f g a) (Sum f' g a) (f a) (f' a) _InL = prism InL (\case InL fa -> Right fa InR ga -> Left (InR ga)) _InR :: Prism (Sum f g a) (Sum f g' a) (g a) (g' a) _InR = prism InR (\case InR ga -> Right ga InL fa -> Left (InL fa)) instance Field1 (Product f g a) (Product f' g a) (f a) (f' a) where _1 :: Lens (Product f g a) (Product f' g a) (f a) (f' a) _1 = lens fst' (\(Pair _ ga) fa -> Pair fa ga) instance Field2 (Product f g a) (Product f g' a) (g a) (g' a) where _2 :: Lens (Product f g a) (Product f g' a) (g a) (g' a) _2 = lens snd' (\(Pair fa _) ga -> Pair fa ga) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 22 19:16:13 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Dec 2016 19:16:13 -0000 Subject: [GHC] #11216: RebindableSyntax with pattern guards needs `fail` In-Reply-To: <047.a0c77911e1a5729e917abc9d45aa382b@haskell.org> References: <047.a0c77911e1a5729e917abc9d45aa382b@haskell.org> Message-ID: <062.ac36aac60871c04e2a446cbc3804c96c@haskell.org> #11216: RebindableSyntax with pattern guards needs `fail` -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: | RebindableSyntax Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T11216 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2896 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D2896 * milestone: => 8.2.1 Comment: Quickly knocked this one off while waiting for a GHC 8.0.2 build. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 22 19:16:40 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Dec 2016 19:16:40 -0000 Subject: [GHC] #11216: RebindableSyntax with pattern guards needs `fail` In-Reply-To: <047.a0c77911e1a5729e917abc9d45aa382b@haskell.org> References: <047.a0c77911e1a5729e917abc9d45aa382b@haskell.org> Message-ID: <062.d484e84bbd064057fe7397d12827a4ae@haskell.org> #11216: RebindableSyntax with pattern guards needs `fail` -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: | RebindableSyntax Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T11216, | T11216A Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2896 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * testcase: T11216 => T11216, T11216A -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 22 19:32:15 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Dec 2016 19:32:15 -0000 Subject: [GHC] #11501: Building nofib/fibon returns permission denied In-Reply-To: <042.7732253ef90810c7acc41907aecb19ff@haskell.org> References: <042.7732253ef90810c7acc41907aecb19ff@haskell.org> Message-ID: <057.e1f73a344ac66e0dddca429852480af3@haskell.org> #11501: Building nofib/fibon returns permission denied -------------------------------------+------------------------------------- Reporter: rem | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: NoFib benchmark | Version: 7.10.3 suite | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): As far as `fibon` is concerned, I get the impression that it may be easier and perhaps more useful to start with a clean slate or concentrate on `nofib` itself. The `fibon` [[https://hackage.haskell.org/package/fibon|tools]] themselves haven't been touched in nearly half a decade and it looks like the tests are similarly on life support. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 22 21:45:55 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Dec 2016 21:45:55 -0000 Subject: [GHC] #13025: Type family reduction irregularity (change from 7.10.3 to 8.0.1) In-Reply-To: <046.8df164442eeb4f6a3254ed537eb97826@haskell.org> References: <046.8df164442eeb4f6a3254ed537eb97826@haskell.org> Message-ID: <061.f179de808cef0bac3a216ab3aaa2347f@haskell.org> #13025: Type family reduction irregularity (change from 7.10.3 to 8.0.1) -------------------------------------+------------------------------------- Reporter: acowley | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeFamilies 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: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): There does appear to be a difference in the `bench-builder-all` benchmark suite. The full results are available at https://gist.github.com/RyanGlScott/386da12bc71fd2fadae2362b257c41bc. The most noticeable differences come in the `vinyl` and `vinyl-plus` benchmarks. On GHC HEAD, I get: {{{ benchmarking vinyl time 106.9 µs (106.7 µs .. 107.0 µs) 1.000 R² (1.000 R² .. 1.000 R²) mean 106.7 µs (106.5 µs .. 106.9 µs) std dev 653.4 ns (506.9 ns .. 847.7 ns) benchmarking vinyl-lens time 83.98 µs (83.97 µs .. 84.00 µs) 1.000 R² (1.000 R² .. 1.000 R²) mean 83.97 µs (83.96 µs .. 83.98 µs) std dev 40.09 ns (33.48 ns .. 47.87 ns) }}} After reverting 1722fa106e10e63160bb2322e2ccb830fd5b9ab3, you get: {{{ benchmarking vinyl time 62.27 µs (62.25 µs .. 62.28 µs) 1.000 R² (1.000 R² .. 1.000 R²) mean 62.28 µs (62.26 µs .. 62.30 µs) std dev 58.65 ns (47.95 ns .. 71.78 ns) benchmarking vinyl-lens time 62.07 µs (62.01 µs .. 62.13 µs) 1.000 R² (1.000 R² .. 1.000 R²) mean 62.02 µs (61.98 µs .. 62.05 µs) std dev 122.0 ns (106.2 ns .. 144.8 ns) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 22 22:48:10 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Dec 2016 22:48:10 -0000 Subject: [GHC] #13013: Add readMaybe to Prelude (possibly readEither too), make Haddocks for read more cautionary In-Reply-To: <046.3d6f3ae3075d3638bfdec9ce7d4dde8f@haskell.org> References: <046.3d6f3ae3075d3638bfdec9ce7d4dde8f@haskell.org> Message-ID: <061.099d800e21ddacfd02a9fbfd75d3c4b4@haskell.org> #13013: Add readMaybe to Prelude (possibly readEither too), make Haddocks for read more cautionary -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): I'm personally weakly against this proposal as names are very much not taken by `Prelude` lightly. To put things in perspective, we've had precisely one wave of additions to the names taken by the Prelude in 18 years, and then it was part of a very contentious and public process. That said, this belongs as a `libraries@` mailing list proposal at this stage, rather than as a ticket here. If clear consensus arises from the `libraries@` proposal, ''then'' this would become the correct venue to put the feet of the core libraries committee to the fire to get it implemented. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 22 23:33:09 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Dec 2016 23:33:09 -0000 Subject: [GHC] #13013: Add readMaybe to Prelude (possibly readEither too), make Haddocks for read more cautionary In-Reply-To: <046.3d6f3ae3075d3638bfdec9ce7d4dde8f@haskell.org> References: <046.3d6f3ae3075d3638bfdec9ce7d4dde8f@haskell.org> Message-ID: <061.34b0981423ab09c6b22e263481df7c72@haskell.org> #13013: Add readMaybe to Prelude (possibly readEither too), make Haddocks for read more cautionary -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sjakobi): Replying to [comment:4 ekmett]: > I'm personally weakly against this proposal as names are very much not taken by `Prelude` lightly. To be clear, the issue is that the newly exposed `readMaybe` and `readEither` names could clash with pre-existing definitions that use the same names, right? > That said, this belongs as a `libraries@` mailing list proposal at this stage, rather than as a ticket here. If clear consensus arises from the `libraries@` proposal, ''then'' this would become the correct venue to put the feet of the core libraries committee to the fire to get it implemented. Actually I wanted to send this proposal directly to the libraries mailing list, but then decided otherwise after reading [https://wiki.haskell.org/Library_submissions#Guide_to_proposers this "guide for proposers"]. If that guide is out of date, it would be great if someone could update it to reflect the current practice. I'll write the email in a few days once I'm back from Christmas holidays. Would a discussion period of 4 weeks be appropriate? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 23 00:45:00 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Dec 2016 00:45:00 -0000 Subject: [GHC] #13025: Type family reduction irregularity (change from 7.10.3 to 8.0.1) In-Reply-To: <046.8df164442eeb4f6a3254ed537eb97826@haskell.org> References: <046.8df164442eeb4f6a3254ed537eb97826@haskell.org> Message-ID: <061.dc9fbe162dfcd791ebcb388851bd0fc7@haskell.org> #13025: Type family reduction irregularity (change from 7.10.3 to 8.0.1) -------------------------------------+------------------------------------- Reporter: acowley | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeFamilies 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: | -------------------------------------+------------------------------------- Comment (by acowley): All the benchmarks in that suite should result in similar times. The idea is that it tests different representations and ways of accessing fields of records. The times you have there look somewhat suspicious to me. Here are my results, With GHC-8.0.1, {{{ benchmarking flat time 6.851 μs (6.658 μs .. 7.040 μs) 0.995 R² (0.993 R² .. 0.996 R²) mean 6.912 μs (6.757 μs .. 7.093 μs) std dev 577.7 ns (480.4 ns .. 799.9 ns) variance introduced by outliers: 82% (severely inflated) benchmarking vinyl time 7.081 μs (6.912 μs .. 7.240 μs) 0.995 R² (0.992 R² .. 0.997 R²) mean 7.116 μs (6.970 μs .. 7.308 μs) std dev 555.6 ns (437.9 ns .. 710.6 ns) variance introduced by outliers: 80% (severely inflated) benchmarking vinyl-lens time 17.55 μs (17.15 μs .. 18.01 μs) 0.995 R² (0.994 R² .. 0.997 R²) mean 17.84 μs (17.42 μs .. 18.47 μs) std dev 1.709 μs (1.244 μs .. 2.326 μs) variance introduced by outliers: 84% (severely inflated) benchmarking reasonable time 7.250 μs (7.069 μs .. 7.403 μs) 0.996 R² (0.994 R² .. 0.997 R²) mean 7.070 μs (6.931 μs .. 7.245 μs) std dev 502.5 ns (428.5 ns .. 586.9 ns) variance introduced by outliers: 77% (severely inflated) }}} While with GHC-7.10.3, I get, {{{ benchmarking flat time 7.107 μs (6.964 μs .. 7.265 μs) 0.995 R² (0.993 R² .. 0.997 R²) mean 7.241 μs (7.087 μs .. 7.431 μs) std dev 592.3 ns (498.5 ns .. 754.0 ns) variance introduced by outliers: 82% (severely inflated) benchmarking vinyl time 7.426 μs (7.295 μs .. 7.586 μs) 0.995 R² (0.993 R² .. 0.997 R²) mean 7.404 μs (7.230 μs .. 7.612 μs) std dev 648.7 ns (530.0 ns .. 800.1 ns) variance introduced by outliers: 83% (severely inflated) benchmarking vinyl-lens time 7.256 μs (7.097 μs .. 7.414 μs) 0.995 R² (0.992 R² .. 0.998 R²) mean 7.281 μs (7.119 μs .. 7.418 μs) std dev 507.4 ns (410.6 ns .. 651.8 ns) variance introduced by outliers: 76% (severely inflated) benchmarking reasonable time 7.231 μs (7.055 μs .. 7.385 μs) 0.995 R² (0.993 R² .. 0.997 R²) mean 7.221 μs (7.069 μs .. 7.388 μs) std dev 540.9 ns (453.3 ns .. 635.3 ns) variance introduced by outliers: 79% (severely inflated) }}} The `vinyl-lens` time going from 7.2 μs to 17.84 μs is representative of what I referred to as a 2x slowdown. This is on a 1.3 GHz Intel Core i5. It doesn't seem likely that you are running on that much of a slower CPU, but it is possible. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 23 02:51:18 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Dec 2016 02:51:18 -0000 Subject: [GHC] #11375: Type aliases twice as slow to compile as closed type families. In-Reply-To: <046.b9a65a6abe1ded76296050051ccc54f5@haskell.org> References: <046.b9a65a6abe1ded76296050051ccc54f5@haskell.org> Message-ID: <061.f0c3ab99070df23f73fb4252793cbf89@haskell.org> #11375: Type aliases twice as slow to compile as closed type families. -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: infoneeded Priority: high | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: TypeFamilies Operating System: MacOS X | Architecture: aarch64 Type of failure: Compile-time | Test Case: performance bug | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => infoneeded Comment: danilo2, any word on this? It would be great to have a lead on this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 23 03:19:58 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Dec 2016 03:19:58 -0000 Subject: [GHC] #10818: GHC 7.10.2 takes much longer to compile some packages In-Reply-To: <052.bbf8ed2f6a4e18f5bbbbe47aede56c86@haskell.org> References: <052.bbf8ed2f6a4e18f5bbbbe47aede56c86@haskell.org> Message-ID: <067.cf7bd280b8438d0f96be1361ee77cdff@haskell.org> #10818: GHC 7.10.2 takes much longer to compile some packages -------------------------------------+------------------------------------- Reporter: kazu-yamamoto | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I'm having a look at this now; it seems culprit in `iproute` is the `Data.IP.Addr`, whose compilation time has increased by the better part of a second with `-O1` between 7.8.4 and 7.10.3. I'll try to look into why tomorrow. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 23 08:34:38 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Dec 2016 08:34:38 -0000 Subject: [GHC] #13025: Type family reduction irregularity (change from 7.10.3 to 8.0.1) In-Reply-To: <046.8df164442eeb4f6a3254ed537eb97826@haskell.org> References: <046.8df164442eeb4f6a3254ed537eb97826@haskell.org> Message-ID: <061.dc33419f030af1e659b142707a00fd5b@haskell.org> #13025: Type family reduction irregularity (change from 7.10.3 to 8.0.1) -------------------------------------+------------------------------------- Reporter: acowley | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeFamilies 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: | -------------------------------------+------------------------------------- Comment (by simonpj): This `HEq_sc` stuff is thoroughly bogus. Nice small test case thank you. I'll investigate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 23 08:50:09 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Dec 2016 08:50:09 -0000 Subject: [GHC] #11501: Building nofib/fibon returns permission denied In-Reply-To: <042.7732253ef90810c7acc41907aecb19ff@haskell.org> References: <042.7732253ef90810c7acc41907aecb19ff@haskell.org> Message-ID: <057.63d49422b3721d1541ae24809e6c94fc@haskell.org> #11501: Building nofib/fibon returns permission denied -------------------------------------+------------------------------------- Reporter: rem | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: NoFib benchmark | Version: 7.10.3 suite | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by gracjan): `shootout` and `fibon/Shootout` are different: {{{ $ ls shootout/ Makefile fannkuch-redux n-body spectral-norm README.md fasta pidigits binary-trees k-nucleotide reverse-complement $ ls fibon/Shootout/ ChameneosRedux Fannkuch Makefile Mandelbrot }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 23 09:44:07 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Dec 2016 09:44:07 -0000 Subject: [GHC] #13031: Bogus calculation of bottoming arity Message-ID: <046.66ebdccd31ef14e2ada2ac1e40f2225b@haskell.org> #13031: Bogus calculation of bottoming arity -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In `CoreArity` we see {{{ andArityType (ABot n1) (ABot n2) = ABot (n1 `min` n2) }}} If you look at the documentation for `ABot` (which is about functions that are ''guaranteed'' to diverge) this is obviously bogus. The `min` should be `max`! Here's a test case: {{{ {-# LANGUAGE MagicHash #-} module Foo( f ) where import GHC.Prim f True = raise# True f False = \p q -> raise# False }}} If you compile (with GHC 8.0) `-ddump-simpl` you'll see {{{ f :: forall a p1 p2. Bool -> p2 -> p1 -> a [GblId, Arity=1, Caf=NoCafRefs, Str=x] }}} That `Str=x` is totally bogus; it claims that `f` will always diverge given one argument. The fix is easy. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 23 10:45:04 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Dec 2016 10:45:04 -0000 Subject: [GHC] #11501: Building nofib/fibon returns permission denied In-Reply-To: <042.7732253ef90810c7acc41907aecb19ff@haskell.org> References: <042.7732253ef90810c7acc41907aecb19ff@haskell.org> Message-ID: <057.8449257a910178bd21c8ed0e07a1ad10@haskell.org> #11501: Building nofib/fibon returns permission denied -------------------------------------+------------------------------------- Reporter: rem | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: NoFib benchmark | Version: 7.10.3 suite | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by gracjan): After some research I have some insights to share. Looks like nofib is used for two distinct purposes: 1. To test speed of generated code. 2. To test compilation speed. `nofib` setup is geared towards interactive use, that is to be able to run speed experiments and compare them pair-wise. Running `make` runs both compilation speed and execution speed tests at the same time. There is also a way to run `valgrind`s `cachegrind` at the same time. Major problems with the test suite I see now are: 1. Only a handful of speed tests are enabled, everything else bitrots. 2. Build system compiles objects and links them, does not use `--make`. 3. Build system is ill suited for tests extracted from cabal projects. 4. There is a confusion between compilation speed tests and execution speed tests. The way forward as I see: 1. Enable all tests by default, but make it easy to select a subset for interactive work. 2. Use `ghc --make` for builds of simpler cases (no dependencies besiades what is shipped with ghc). 3. Use `cabal install` for more complicated cases (with more dependencies). 4. Clearly separate compilation speed tests from execution speed tests. And in distant future: 1. Run execution speed tests on TravisCI in multiple combinations of os/ghc/flags/test. 2. Run compilation speed tests on TravisCI in multiple combinations of os/ghc/flags/test. 3. Run incremental compilation speed tests on TravisCI in multiple combinations of os/ghc/flags/test. 4. Publish metrics to some kind of timeseries database. 5. Let Grafana show some nice graphs. Graphana is here: http://grafana.org/ I'd like to hear from people that use nofib in daily work how do they do this so that we do not skip any important use cases. Can you guys chime in and describe your workflow? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 23 11:56:14 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Dec 2016 11:56:14 -0000 Subject: [GHC] #13004: Timeout no longer kills processes on timeout In-Reply-To: <044.a6877c959d19da5e9ab8a3dcab34e50f@haskell.org> References: <044.a6877c959d19da5e9ab8a3dcab34e50f@haskell.org> Message-ID: <059.6213743f503db40890ff84239ba04f17@haskell.org> #13004: Timeout no longer kills processes on timeout -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Test Suite | Version: 8.1 Resolution: fixed | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2880 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Tamar Christina ): In [changeset:"efc4a1661f0fc1004a4b7b0914f3d3a08c2e791a/ghc" efc4a16/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="efc4a1661f0fc1004a4b7b0914f3d3a08c2e791a" Allow timeout to kill entire process tree. Summary: we spawn the child processes with handle inheritance on. So they inherit the std handles. The problem is that the job handle gets inherited too. So the `JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE` doesn't get used since there are open handles to the job in the children. We then terminate the top level process which is `sh` but leaves the children around. This explicitly disallows the inheritance of the job and events handle. Test Plan: ./validate Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D2895 GHC Trac Issues: #13004 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 23 12:34:46 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Dec 2016 12:34:46 -0000 Subject: [GHC] #13031: Bogus calculation of bottoming arity In-Reply-To: <046.66ebdccd31ef14e2ada2ac1e40f2225b@haskell.org> References: <046.66ebdccd31ef14e2ada2ac1e40f2225b@haskell.org> Message-ID: <061.6b6991c8695193fbc7426a1d4c2ce0fc@haskell.org> #13031: Bogus calculation of bottoming arity -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"f06b71ae2e76ec81a618bc8bb0409b3fc6a7ebbe/ghc" f06b71a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f06b71ae2e76ec81a618bc8bb0409b3fc6a7ebbe" Fix a bug in ABot handling in CoreArity See Note [ABot branches: use max] in CoreArity. I stumbled on this when investigating something else, and opened Trac #13031 to track it. It's very hard to tickle the bug, which is why it has lurked so long, but the test stranal/should_compile/T13031 does so Oddly, the testsuite framework doesn't actually run the test; I have no idea why. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 23 12:34:46 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Dec 2016 12:34:46 -0000 Subject: [GHC] #12603: INLINE and manually inlining produce different code In-Reply-To: <046.944cd4788eed55470361e7f38358ac43@haskell.org> References: <046.944cd4788eed55470361e7f38358ac43@haskell.org> Message-ID: <061.5889b83157e4510cf87d8b31f1d5bb1a@haskell.org> #12603: INLINE and manually inlining produce different code -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #12747 #12781 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"432f952ef64641be9f32152a0fbf2b8496d8fe9c/ghc" 432f952/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="432f952ef64641be9f32152a0fbf2b8496d8fe9c" Float unboxed expressions by boxing This patch makes GHC's floating more robust, by allowing it to float unboxed expressions of at least some common types. See Note [Floating MFEs of unlifted type] in SetLevels. This was all provoked by Trac #12603 In working this through I also made a number of other corner-case changes in SetLevels: * Previously we inconsistently use exprIsBottom (which checks for bottom) instead of exprBotStrictness_maybe (which checks for bottoming functions). As well as being inconsistent it was simply less good. See Note [Bottoming floats] * I fixed a case where were were unprofitably floating an expression because we thought it escaped a value lambda (see Note [Escaping a value lambda]). The relevant code is float_me = (dest_lvl `ltMajLvl` (le_ctxt_lvl env) && not float_is_lam) -- NEW * I made lvlFloatRhs work properly in the case where abs_vars is non-empty. It wasn't wrong before, but it did some stupid extra floating. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 23 14:57:27 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Dec 2016 14:57:27 -0000 Subject: [GHC] #12603: INLINE and manually inlining produce different code In-Reply-To: <046.944cd4788eed55470361e7f38358ac43@haskell.org> References: <046.944cd4788eed55470361e7f38358ac43@haskell.org> Message-ID: <061.c039c3a9eb8b917643311a3c9a0aa5a1@haskell.org> #12603: INLINE and manually inlining produce different code -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #12747 #12781 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): The patch was reverted because (oddly) it made a couple of GHCi-debugger tests behave differently. I worked some more on it, fixing some extra things as above, and behold the debugger problems went away. So I've re-pushed is: commend:33. I still want to try the effect of earlier inlining of INLINE things... working on that now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 23 15:01:01 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Dec 2016 15:01:01 -0000 Subject: [GHC] #11501: Building nofib/fibon returns permission denied In-Reply-To: <042.7732253ef90810c7acc41907aecb19ff@haskell.org> References: <042.7732253ef90810c7acc41907aecb19ff@haskell.org> Message-ID: <057.583798de2a237a97334d19fa976e6afe@haskell.org> #11501: Building nofib/fibon returns permission denied -------------------------------------+------------------------------------- Reporter: rem | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: NoFib benchmark | Version: 7.10.3 suite | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I use nofib a lot to check for performance regressions: * `make -k >& log-baseline` using a baseline compiler * `make -k >& log-new` using a compiler modified from the baseline with some new feature * `nofib-analyse log-baseline log-new` to see the differences The more programs we have in `nofib`, and the more varied they are, the better. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 23 15:02:35 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Dec 2016 15:02:35 -0000 Subject: [GHC] #13027: Core lint errors compiling containers HEAD with GHC HEAD In-Reply-To: <044.039b1d41ac9eefe9789d53b67dd9193b@haskell.org> References: <044.039b1d41ac9eefe9789d53b67dd9193b@haskell.org> Message-ID: <059.e790e454ffc4e2c1f6bdf272e398dc44@haskell.org> #13027: Core lint errors compiling containers HEAD with GHC HEAD -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"75e8c305a497ec5ad3e5a5d9ff73bbf6f7a8a000/ghc" 75e8c305/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="75e8c305a497ec5ad3e5a5d9ff73bbf6f7a8a000" Propagate evaluated-ness a bit more faithfully This was provoked by Trac #13027. The fix in Simplify actually cures the reported bug; see Note [Case binder evaluated-ness] in Simplify. The fix in CoreTidy looks like an omission that I fixed while I was at it. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 23 15:02:35 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Dec 2016 15:02:35 -0000 Subject: [GHC] #13029: Dead code in DsCCall? In-Reply-To: <047.81a7bd71039b9caebe1d23ea4c77fb14@haskell.org> References: <047.81a7bd71039b9caebe1d23ea4c77fb14@haskell.org> Message-ID: <062.15e4802af403fb912823982fae4d7fcf@haskell.org> #13029: Dead code in DsCCall? -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"ee872d32e024a65d0d7fdd55515262f5d4aecb24/ghc" ee872d3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ee872d32e024a65d0d7fdd55515262f5d4aecb24" Removed dead code in DsCCall.mk_alt Fixes Trac #13029 by deleting code and adding comments }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 23 15:02:35 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Dec 2016 15:02:35 -0000 Subject: [GHC] #13025: Type family reduction irregularity (change from 7.10.3 to 8.0.1) In-Reply-To: <046.8df164442eeb4f6a3254ed537eb97826@haskell.org> References: <046.8df164442eeb4f6a3254ed537eb97826@haskell.org> Message-ID: <061.5f1b2ce935ec8f53a0e1dd674f5f8701@haskell.org> #13025: Type family reduction irregularity (change from 7.10.3 to 8.0.1) -------------------------------------+------------------------------------- Reporter: acowley | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeFamilies 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: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"b4c3a66872a2b6e64fea9cc1f20ef4c8921ef7b6/ghc" b4c3a66/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b4c3a66872a2b6e64fea9cc1f20ef4c8921ef7b6" Push coercions in exprIsConApp_maybe Trac #13025 showed up the fact that exprIsConApp_maybe isn't clever enough: it didn't push coercions through applicatins, and that meant we weren't getting as much superclass selection as we should. It's easy to fix, happily. See Note [Push coercions in exprIsConApp_maybe] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 23 15:03:16 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Dec 2016 15:03:16 -0000 Subject: [GHC] #13029: Dead code in DsCCall? In-Reply-To: <047.81a7bd71039b9caebe1d23ea4c77fb14@haskell.org> References: <047.81a7bd71039b9caebe1d23ea4c77fb14@haskell.org> Message-ID: <062.c60d6ea36c46152cbec633d200fef650@haskell.org> #13029: Dead code in DsCCall? -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 23 15:06:51 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Dec 2016 15:06:51 -0000 Subject: [GHC] #13025: Type family reduction irregularity (change from 7.10.3 to 8.0.1) In-Reply-To: <046.8df164442eeb4f6a3254ed537eb97826@haskell.org> References: <046.8df164442eeb4f6a3254ed537eb97826@haskell.org> Message-ID: <061.19ea3854d1b67e80fc26961f11a139f3@haskell.org> #13025: Type family reduction irregularity (change from 7.10.3 to 8.0.1) -------------------------------------+------------------------------------- Reporter: acowley | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.3 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | simplCore/should_compile/T13025 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge * testcase: => simplCore/should_compile/T13025 * milestone: => 8.0.3 Comment: Fixed. Probably worth pushing the fix to 8.0.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 23 15:07:15 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Dec 2016 15:07:15 -0000 Subject: [GHC] #13027: Core lint errors compiling containers HEAD with GHC HEAD In-Reply-To: <044.039b1d41ac9eefe9789d53b67dd9193b@haskell.org> References: <044.039b1d41ac9eefe9789d53b67dd9193b@haskell.org> Message-ID: <059.58581ac18dea001e22abbe55dffa9803@haskell.org> #13027: Core lint errors compiling containers HEAD with GHC HEAD -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Building GHC | Test Case: failed | simplCore/should_compile/T13027 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => simplCore/should_compile/T13027 Comment: Probably not worth merging to 8.0... I think it's only a Lint complaint and it's fine without. Thanks for reporting this! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 23 15:13:42 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Dec 2016 15:13:42 -0000 Subject: [GHC] #13032: Redundant forcing of Given dictionaries Message-ID: <046.811080f481e777da656f14add09b1cc8@haskell.org> #13032: Redundant forcing of Given dictionaries -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If you look at the test case for #13025 you'll see code like {{{ f :: (a~~b) => a -> b -> Bool f d x y = case HEq_sc d of (cobox :: a ~# b) -> True }}} From the Given dictionary `(a~~b)`, the contraint solver generates a given binding, just in case {{{ (cobox :: a~# b) = HEq_sc d }}} But because `cobox` is a ''coercion'' we evaluate this binding strictly, and so the desugarer produces the case expression above. Most redundant Given bindings are let-bound and hence discarded quickly by the occurrence analyser, but GHC doesn't discard cases (termination worries). So the task here is to remove the redundant Given in some way. (Of course, if the equality is actually used, we need to keep it.) NB: See `Note [The equality types story]` in `TysPrim` for the meanagerie of equality types. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 23 15:34:11 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Dec 2016 15:34:11 -0000 Subject: [GHC] #12997: Build broken on OpenBSD In-Reply-To: <046.c0878bd6997bef3bde75ecc5cab79db4@haskell.org> References: <046.c0878bd6997bef3bde75ecc5cab79db4@haskell.org> Message-ID: <061.26f4ac9d534a509f6fdaf67942dd0644@haskell.org> #12997: Build broken on OpenBSD -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.2-rc2 Resolution: | Keywords: Operating System: OpenBSD | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by hvr): * status: closed => new * resolution: fixed => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 23 15:34:35 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Dec 2016 15:34:35 -0000 Subject: [GHC] #13027: Core lint errors compiling containers HEAD with GHC HEAD In-Reply-To: <044.039b1d41ac9eefe9789d53b67dd9193b@haskell.org> References: <044.039b1d41ac9eefe9789d53b67dd9193b@haskell.org> Message-ID: <059.75f14e246782fd15b2d7b33c4e8651a9@haskell.org> #13027: Core lint errors compiling containers HEAD with GHC HEAD -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Building GHC | Test Case: failed | simplCore/should_compile/T13027 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:7 Simon Peyton Jones ]: > In [changeset:"75e8c305a497ec5ad3e5a5d9ff73bbf6f7a8a000/ghc" 75e8c305/ghc]: > {{{ > #!CommitTicketReference repository="ghc" revision="75e8c305a497ec5ad3e5a5d9ff73bbf6f7a8a000" > Propagate evaluated-ness a bit more faithfully > }}} If this is about tracking that the arguments to `reallyUnsafePtrEquality#` have been evaluated, then I fear it may not fix the problem in all contexts. The equality test should be seen as safe to speculate even when its arguments have not been evaluated. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 23 15:36:14 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Dec 2016 15:36:14 -0000 Subject: [GHC] #12997: Build broken on OpenBSD In-Reply-To: <046.c0878bd6997bef3bde75ecc5cab79db4@haskell.org> References: <046.c0878bd6997bef3bde75ecc5cab79db4@haskell.org> Message-ID: <061.f70c20d289b9f52ff27ce84e81e5b338@haskell.org> #12997: Build broken on OpenBSD -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.2-rc2 Resolution: | Keywords: Operating System: OpenBSD | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): When trying to build GHC 8.0.2rc2 on AIX, I ran into {{{ gcc: error: unrecognized command line option '-Wl-optl-Wl,-bnotextro' }}} when the build was trying to build `hsc2hs` early on. @slyfox suggested cherry-picking a6657bd0d6b9949098021d89ed3cd8a943bdd3b6, which I did, and it fixed that issue for me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 23 15:40:34 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Dec 2016 15:40:34 -0000 Subject: [GHC] #13027: Core lint errors compiling containers HEAD with GHC HEAD In-Reply-To: <044.039b1d41ac9eefe9789d53b67dd9193b@haskell.org> References: <044.039b1d41ac9eefe9789d53b67dd9193b@haskell.org> Message-ID: <059.acd89d31fc36617aa2fb62f90d7a5e43@haskell.org> #13027: Core lint errors compiling containers HEAD with GHC HEAD -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Building GHC | Test Case: failed | simplCore/should_compile/T13027 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): That is, if the bang pattern on `x` is removed, I fear we'll still have an error, although the code is reasonable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 23 15:50:36 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Dec 2016 15:50:36 -0000 Subject: [GHC] #13018: TH-spliced pattern synonym declaration fails to typecheck In-Reply-To: <050.321896de80824d0ab018c753e6e2c2e9@haskell.org> References: <050.321896de80824d0ab018c753e6e2c2e9@haskell.org> Message-ID: <065.dbafea8bc673fd6bbb2507131251b966@haskell.org> #13018: TH-spliced pattern synonym declaration fails to typecheck -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I made some progress in investigating the pattern synonyms codebase. This "partitioning" I wondered about in comment:7 is [http://git.haskell.org/ghc.git/blob/b4c3a66872a2b6e64fea9cc1f20ef4c8921ef7b6:/compiler/typecheck/TcSigs.hs#l303 described] in `Note [The pattern-synonym signature splitting rule]`: {{{ Note [The pattern-synonym signature splitting rule] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Given a pattern signature, we must split the kind-generalised variables, and the implicitly-bound variables into universal and existential. The rule is this (see discussion on Trac #11224): The universal tyvars are the ones mentioned in - univ_tvs: the user-specified (forall'd) universals - req_theta - res_ty The existential tyvars are all the rest }}} And in [http://git.haskell.org/ghc.git/blob/b4c3a66872a2b6e64fea9cc1f20ef4c8921ef7b6:/compiler/typecheck/TcPatSyn.hs#l102 tcCheckPatSynDecl], this is implemented [http://git.haskell.org/ghc.git/blob/b4c3a66872a2b6e64fea9cc1f20ef4c8921ef7b6:/compiler/typecheck/TcPatSyn.hs#l135 like so]: {{{#!hs let univ_fvs = closeOverKinds $ (tyCoVarsOfTypes (pat_ty : req_theta) `extendVarSetList` explicit_univ_tvs) (extra_univ, extra_ex) = partition ((`elemVarSet` univ_fvs) . binderVar) implicit_tvs univ_bndrs = extra_univ ++ mkTyVarBinders Specified explicit_univ_tvs ex_bndrs = extra_ex ++ mkTyVarBinders Specified explicit_ex_tvs univ_tvs = binderVars univ_bndrs ex_tvs = binderVars ex_bndrs }}} So I think in order to fix this bug, we'd just need to implement something analogous to the above in `repHsPatSynSigType`. But I'm stuck: the code above requires calculating free variables using `tyCoVarsOfTypes`, which takes `[Type]` as an argument. But in `repHsPatSynSigType`, we don't have `Type`s, we have `HsType`s! Is there an `HsType` counterpart to `tyCoVarsOfTypes` somewhere in the GHC codebase? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 23 15:56:45 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Dec 2016 15:56:45 -0000 Subject: [GHC] #13027: Core lint errors compiling containers HEAD with GHC HEAD In-Reply-To: <044.039b1d41ac9eefe9789d53b67dd9193b@haskell.org> References: <044.039b1d41ac9eefe9789d53b67dd9193b@haskell.org> Message-ID: <059.4d7e2c782190c26f0806c27040556fe2@haskell.org> #13027: Core lint errors compiling containers HEAD with GHC HEAD -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Building GHC | Test Case: failed | simplCore/should_compile/T13027 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Its not about that. Lint is just blindly checking the let/app invariant. We might additionally want to check that the arguments to `reallyUnsafePtrEquality#` are indeed guaranteed evaluated... Lint could do that I suppose but it might well be a USER error not a GHC error. We don't have a good way to check for that; hence really unsafe. But I have fixed GHC's internal consistency check, which is what Lint is about -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 23 16:02:47 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Dec 2016 16:02:47 -0000 Subject: [GHC] #13027: Core lint errors compiling containers HEAD with GHC HEAD In-Reply-To: <044.039b1d41ac9eefe9789d53b67dd9193b@haskell.org> References: <044.039b1d41ac9eefe9789d53b67dd9193b@haskell.org> Message-ID: <059.5028d1f602e1bbb99f25f8d95789865a@haskell.org> #13027: Core lint errors compiling containers HEAD with GHC HEAD -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Building GHC | Test Case: failed | simplCore/should_compile/T13027 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:11 simonpj]: > > We might additionally want to check that the arguments to `reallyUnsafePtrEquality#` are indeed guaranteed evaluated... Lint could do that I suppose but it might well be a USER error not a GHC error. We don't have a good way to check for that; hence really unsafe. Why would we want to check that? One nice thing about the equality test us that it can be applied to things not known to be evaluated, and sometimes even catch equality between thunks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 23 17:00:54 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Dec 2016 17:00:54 -0000 Subject: [GHC] #11501: Building nofib/fibon returns permission denied In-Reply-To: <042.7732253ef90810c7acc41907aecb19ff@haskell.org> References: <042.7732253ef90810c7acc41907aecb19ff@haskell.org> Message-ID: <057.231be1d66920be76980e949658bf4b89@haskell.org> #11501: Building nofib/fibon returns permission denied -------------------------------------+------------------------------------- Reporter: rem | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: NoFib benchmark | Version: 7.10.3 suite | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I have also used `nofib` a great deal to locate past regressions in compiler performance regressions. Your observations are generally correct. I think it would be great to enable more tests by default. However, it's not at all clear to me that we necessarily always want to use `--make`. The current use of one-shot mode makes it significantly easier to narrow down what code in particular GHC has regressed on. Moving to `--make` may better reflect `Cabal`'s usage, but I think it would make the common case of locating compiler performance regressions a bit harder. In general I think there is certainly room for a broader performance testsuite consisting of a sampling of packages from Hackage. However, I'm not sure that `nofib` is that place. Keeping `nofib` a set of standalone tests without dependencies makes it a significantly smaller maintenance burden that the Cabal-centric approach that you describe. We as a community (myself included!) have had a poor record of following through with maintaining our performance infrastructure. Consequently I think there is value in keeping at least one testsuite which "just works" with minimal maintenance. I gave a talk at HIW this year describing a very rough tool that I developed while tracking down performance regressions in nofib using the performance build bot which nomeata stood up to server [[http://perf.haskell.org/|gipeda]]. It essentially provides the nice(?) graphs which you describe. Sadly, I've not had a chance to put it up in a publicly accessible location. In the meantime it can be found at http://home.smart-cactus.org/~ben/ghc-perf/. The source is available [[https://github.com/bgamari/ghc-perf-import/|here]]. The general workflow is, 1. navigate to http://home.smart-cactus.org/~ben/ghc-perf/ 2. stand in awe of my poor front-end design aesthetic 3. select a test environment on the right-hand pane (e.g. my own build bot or nomeata's; the latter has better coverage). 4. select a set of tests to plot from the left-hand pane. The tests list can be filtered by substring match using the text field at the top; I usually filter by `compile-allocs`. Loading the results may take a while, sadly. 5. select a change threshold percentage such that commits which exhibit large changes in the selected tests show up in the commit list at the bottom This is how I typically find a starting point to dive into performance work. There are several types of tests captured, * Characterizing GHC's performance * `compile-allocs`: These are the compiler allocations for compiling each module of each test * `compile-time`: These are the compiler runtimes for compiling each module of each test * Compiled code characteristics * `binary-size`: This is the size of the produced executable * `module-size`: The size of each module's object file * Characterizing compiled code performance * `allocs`: This is the runtime allocations of each test * `gc-time`: The time spent in garbage collection while running the test * `elapsed-time`: The wall-clock time of the test run * `mut-elapsed-time`: The wall-clock time spent in the mutator * `mut-time`: CPU time spent in the mutator * `run-time`: The overall CPU time spent in the test Note that in general runtimes are very unstable. I find it most helpful to first identify potential regressions by looking at allocations, then look at runtime to see which allocations changes actually move real runtime. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 23 17:08:46 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Dec 2016 17:08:46 -0000 Subject: [GHC] #11501: Building nofib/fibon returns permission denied In-Reply-To: <042.7732253ef90810c7acc41907aecb19ff@haskell.org> References: <042.7732253ef90810c7acc41907aecb19ff@haskell.org> Message-ID: <057.4b9f4595c884790143fab22322215204@haskell.org> #11501: Building nofib/fibon returns permission denied -------------------------------------+------------------------------------- Reporter: rem | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: NoFib benchmark | Version: 7.10.3 suite | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I should note, however, that after some of the work I did last summer most of the major, consistent compiler regressions have been fixed or accounted for. I have some notes at https://ghc.haskell.org/trac/ghc/wiki/Performance/Compiler/BenNotes and https://ghc.haskell.org/trac/ghc/wiki/Performance/Compiler. I think there still are issues which can be fixed with the approach described above, but the lowest pickings are likely exhausted. Regardless, the more eyes the better! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 23 17:24:16 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Dec 2016 17:24:16 -0000 Subject: [GHC] #13027: Core lint errors compiling containers HEAD with GHC HEAD In-Reply-To: <044.039b1d41ac9eefe9789d53b67dd9193b@haskell.org> References: <044.039b1d41ac9eefe9789d53b67dd9193b@haskell.org> Message-ID: <059.b715c0cd07e80da155e4cdef1091e590@haskell.org> #13027: Core lint errors compiling containers HEAD with GHC HEAD -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Building GHC | Test Case: failed | simplCore/should_compile/T13027 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: I agree. Fine, so we can close this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 23 19:01:34 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Dec 2016 19:01:34 -0000 Subject: [GHC] #12948: Implement unwind rules for non-Intel architectures In-Reply-To: <046.8f503227fa066851e13a6dcbab195691@haskell.org> References: <046.8f503227fa066851e13a6dcbab195691@haskell.org> Message-ID: <061.1f914da76c9746f0a78f40d748caedd8@haskell.org> #12948: Implement unwind rules for non-Intel architectures -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11261 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by trommler): * related: => #11261 Comment: PowerPC 64-bit is tracked in #11261. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 23 19:50:25 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Dec 2016 19:50:25 -0000 Subject: [GHC] #8779: Exhaustiveness checks for pattern synonyms In-Reply-To: <046.b910d807e2ecf5838df4d05d7ec88278@haskell.org> References: <046.b910d807e2ecf5838df4d05d7ec88278@haskell.org> Message-ID: <061.d4fe54f5bda3bb712809ba1f8869a382@haskell.org> #8779: Exhaustiveness checks for pattern synonyms -------------------------------------+------------------------------------- Reporter: nomeata | Owner: mpickering Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.1 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2669 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Somehow I've not looked at this thread, finding this only by a mention of `COMPLETE` elsewhere. (This is my fault -- just explaining my silence on this topic which is in my area of interest.) A few nitpicks about the specification: - The wiki page uses "total" in several places, but I think you mean "covering". I use "total" to refer to functions that are both covering and terminating. - Would the following be acceptable? {{{ data Void data T = T1 Int | T2 Bool | T3 Void {-# COMPLETE T1, T2 #-} }}} It would seem so. I'm happy for this to be accepted; I'm just stress- testing the spec. - The argument for not having the pattern-match checker look through pattern synonyms is reasonable. But is there a way to have GHC do some checking on `COMPLETE` declarations? It would be great -- especially if the `COMPLETE` pragma were in the synonyms' defining module -- to check these declarations. Of course, GHC will issue false negatives (that is, say that a set is not complete when it actually is) but some checking is better than none. - How does this interact with GADTs? For example, load this code into your head: {{{ data G a where GInt :: G Int GBool :: G Bool pattern PInt :: forall a. () => a ~ Int => G a pattern PInt = GInt f1 :: G a -> () f1 GInt = () f2 :: G Int -> () f2 GInt = () f3 :: G Int -> () f3 PInt = () }}} By default, `f1` and `f3` will get incomplete match warnings, and `f2` does not. a. If I say `{-# COMPLETE GInt, GBool #-}`, does this change the default warning behavior? b. How can I have GHC notice that `f3` is a complete match? Saying `{-# COMPLETE PInt #-}` would seem disastrous. - What if multiple conflicting `COMPLETE` pragmas are in scope? For example, I have `{-# COMPLETE A, B #-}` and `{-# COMPLETE A #-}` in scope. Is a match over `A` complete? Is a warning/error issued about the pragmas? - The spec says "We verify that the result types of each constructor in a complete match agrees with each other." What does this sentence mean? Consider the possibility of pattern synonyms that match against functions, polymorphic patterns, and possibly even higher-rank patterns. I've not looked at all at the implementation, wanting to nail down the spec before considering any implementation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 23 19:55:12 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Dec 2016 19:55:12 -0000 Subject: [GHC] #13021: Inaccessible RHS warning is confusing for users In-Reply-To: <049.555b28c752b0039d3740af545c7af8be@haskell.org> References: <049.555b28c752b0039d3740af545c7af8be@haskell.org> Message-ID: <064.dd724dde62a1f1b1af331580181e702b@haskell.org> #13021: Inaccessible RHS warning is confusing for users -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I'm with @rwbarton. The fact that `B` is `COMPLETE` in comment:5 does not make the first match redundant or inaccessible. His suggestion to consider `pattern B <- _` (which is indeed a complete pattern) is instructive. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 23 20:15:20 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Dec 2016 20:15:20 -0000 Subject: [GHC] #11501: Building nofib/fibon returns permission denied In-Reply-To: <042.7732253ef90810c7acc41907aecb19ff@haskell.org> References: <042.7732253ef90810c7acc41907aecb19ff@haskell.org> Message-ID: <057.147fb50823060876a1850155737c0c6b@haskell.org> #11501: Building nofib/fibon returns permission denied -------------------------------------+------------------------------------- Reporter: rem | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: NoFib benchmark | Version: 7.10.3 suite | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by gracjan): @simonpj: Do you also use nofib to test speed of compilation or just efficiency of generated code? @bgamari: `ghc --make` will only be used to test generated code. Compilation speed will have own tests that compile single files. Unless we will want to test compilation speed for many modules at once. We can also go full high level and see if compiling programs with latest complier and latest package set got suddenly slower than previous compiler and previous package set. This is very high level, but this is what constitutes the perception 'GHC compiles slower than it used to'. > However, I'm not sure that nofib is that place. This is what `fibon` is and I'm not sure either if this a good place. I like gipeda very much, this is more or less what I had in mind. I would advise using off-the-shelf tools for this purpose, as it is a lot of work to create one from scratch. There is a relevant industry that is very concerned with performance and performance variations in time. They have developed a lot of tools to collect performance data points and then be able to dig into the issues by finding exceptional value, high variation, correlating causes and effects and so on. This industry is network monitoring and operations in general. And tools I like are Graphana and a backend database for data points, could be ElasticSearch or InfluxDB. Those more or less form gipeda, well, rather more than gipeda :) Anyway I was thinking of a datapoint that will be a tuple: (operating system, machine arch, ghc version, test name, date of last merged commit, and METRIC) where METRIC is one of metrics you listed. Can you share database of results? I'd like to try to import data into InfluxDB, connect Graphana, see if this is useful. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 23 20:39:03 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Dec 2016 20:39:03 -0000 Subject: [GHC] #11501: Building nofib/fibon returns permission denied In-Reply-To: <042.7732253ef90810c7acc41907aecb19ff@haskell.org> References: <042.7732253ef90810c7acc41907aecb19ff@haskell.org> Message-ID: <057.449fe399690f6b75a700b61453aa89a4@haskell.org> #11501: Building nofib/fibon returns permission denied -------------------------------------+------------------------------------- Reporter: rem | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: NoFib benchmark | Version: 7.10.3 suite | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Replying to [comment:19 gracjan]: > @bgamari: `ghc --make` will only be used to test generated code. Compilation speed will have own tests that compile single files. Unless we will want to test compilation speed for many modules at once. > Alright, that sounds reasonable to me. > We can also go full high level and see if compiling programs with latest complier and latest package set got suddenly slower than previous compiler and previous package set. This is very high level, but this is what constitutes the perception 'GHC compiles slower than it used to'. > > > However, I'm not sure that nofib is that place. > > This is what `fibon` is and I'm not sure either if this a good place. > Indeed; I've largely written `fibon` off. > I like gipeda very much, this is more or less what I had in mind. I would advise using off-the-shelf tools for this purpose, as it is a lot of work to create one from scratch. There is a relevant industry that is very concerned with performance and performance variations in time. They have developed a lot of tools to collect performance data points and then be able to dig into the issues by finding exceptional value, high variation, correlating causes and effects and so on. This industry is network monitoring and operations in general. And tools I like are Graphana and a backend database for data points, could be ElasticSearch or InfluxDB. Those more or less form gipeda, well, rather more than gipeda :) > Before setting out to write my hack I did a survey of the tools available and was pretty disappointed in what I found. While there are many tools which can give you a qualitative sense for the behavior a small number of performance metrics over the course of a day or so, I found nothing which gave me the quantitative insight which I needed. > Anyway I was thinking of a datapoint that will be a tuple: (operating system, machine arch, ghc version, test name, date of last merged commit, and METRIC) where METRIC is one of metrics you listed. > That is similar to the encoding I use. I call the tuple of `(operating system, machine arch, ghc version)` a "test environment". Instead of "date of last merged commit" I use commit sequence number with respect to a topologically linearized view of git history. > Can you share database of results? I'd like to try to import data into InfluxDB, connect Graphana, see if this is useful. > Of course. It's backed by PostgreSQL. I've uploaded a dump [[http://home .smart-cactus.org/~ben/ghc_perf.sql|here]]. Note that it's rather big. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 23 22:12:22 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Dec 2016 22:12:22 -0000 Subject: [GHC] #13033: GHC Panics with "colorGraph: trivially colorable nodes didn't color!" on PPC Message-ID: <042.4e47f55bc923968731a525ef1cc09806@haskell.org> #13033: GHC Panics with "colorGraph: trivially colorable nodes didn't color!" on PPC -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.2-rc2 Keywords: | Operating System: AIX Architecture: powerpc | Type of failure: Compile-time | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I was finally able to build GHC 8.0.2rc2 (or rather, c5f375c53671130c79713800b13a1da53d070b84 + a minor buildsys fix) on AIX/PPC; most packages seem to work as they did with GHC 8.0.1, however, `unordered-containers` now panics with: {{{ $ cabal get unordered-containers && cd unordered-containers-0.2.7.1/ $ cabal new-build -j1 Resolving dependencies... In order, the following will be built (use -v for more details): - unordered-containers-0.2.7.1 (lib) (first run) Configuring component lib from unordered-containers-0.2.7.1... Preprocessing library unordered-containers-0.2.7.1... [1 of 8] Compiling Data.HashMap.UnsafeShift ( Data/HashMap/UnsafeShift.hs, /home/hvr/unordered-containers-0.2.7.1/dist-newstyle/build/ppc- aix/ghc-8.0.1.20161223/unordered- containers-0.2.7.1/build/Data/HashMap/UnsafeShift.o ) [2 of 8] Compiling Data.HashMap.Unsafe ( Data/HashMap/Unsafe.hs, /home/hvr /unordered-containers-0.2.7.1/dist-newstyle/build/ppc- aix/ghc-8.0.1.20161223/unordered- containers-0.2.7.1/build/Data/HashMap/Unsafe.o ) [3 of 8] Compiling Data.HashMap.PopCount ( Data/HashMap/PopCount.hs, /home/hvr/unordered-containers-0.2.7.1/dist-newstyle/build/ppc- aix/ghc-8.0.1.20161223/unordered- containers-0.2.7.1/build/Data/HashMap/PopCount.o ) [4 of 8] Compiling Data.HashMap.Array ( Data/HashMap/Array.hs, /home/hvr /unordered-containers-0.2.7.1/dist-newstyle/build/ppc- aix/ghc-8.0.1.20161223/unordered- containers-0.2.7.1/build/Data/HashMap/Array.o ) [5 of 8] Compiling Data.HashMap.Base ( Data/HashMap/Base.hs, /home/hvr /unordered-containers-0.2.7.1/dist-newstyle/build/ppc- aix/ghc-8.0.1.20161223/unordered- containers-0.2.7.1/build/Data/HashMap/Base.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.0.1.20161223 for powerpc-ibm-aix): colorGraph: trivially colorable nodes didn't color! ksTriv = [%vHi_HCRu, %vHi_HCRA, %vI_nGN7, %vI_nGNh, %vI_sCRp, %vI_sCRr, %vHi_HCRt, %vHi_HGNi, %vHi_HGNj, %vI_nGN3, %vI_nGN4, %vI_nGN5, %vI_nGN6, %vI_nGN8, %vI_nGN9, %vI_nGNa, %vI_nGNb, %vI_nGNc, %vI_nGNd, %vI_nGNe, %vI_nGNf, %vI_nGNi, %vI_nGNj, %vI_nGNk, %vI_nGNl, %vI_nGNm, %vI_nGNn, %vI_nGNo, %vI_nGNp, %vI_nGNq, %vI_nGNr, %vI_nGNs, %vI_nGNt, %vI_sCRH, %vI_sCRM] ksNoTriv = [%vI_sCRr] colors = [L0 :-> [R3 :-> %r3, R4 :-> %r4, R5 :-> %r5, R6 :-> %r6, R7 :-> %r7, R8 :-> %r8, R9 :-> %r9, Ra :-> %r10, Rb :-> %r11, Rc :-> %r12, Rn :-> %r23, Rq :-> %r26, Rs :-> %r28, Rt :-> %r29, Rv :-> %r31], L2 :-> [Rw :-> %r32, Rx :-> %r33, Ry :-> %r34, Rz :-> %r35, RA :-> %r36, RB :-> %r37, RC :-> %r38, RD :-> %r39, RE :-> %r40, RF :-> %r41, RG :-> %r42, RH :-> %r43, RI :-> %r44, RJ :-> %r45, RQ :-> %r52, RR :-> %r53, RS :-> %r54, RT :-> %r55, RU :-> %r56, RV :-> %r57, RW :-> %r58, RX :-> %r59, RY :-> %r60, RZ :-> %r61, R10 :-> %r62, R11 :-> %r63]] graph G { node [label="%vHi_HCRt :: I\n(%r3)" style=filled fillcolor="white"] "%vHi_HCRt"; node [label="%vHi_HCRu :: I\n-%r3 -%r4 -%r5 -%r6 -%r7 -%r8 -%r9 -%r10 -%r11 -%r12 -%r32 -%r33 -%r34 -%r35 -%r36 -%r37 -%r38 -%r39 -%r40 -%r41 -%r42 -%r43 -%r44 -%r45 +%r3\n(%r23)" style=filled fillcolor="white"] "%vHi_HCRu"; node [label="%vHi_HCRA :: I\n-%r3 -%r4 -%r5 -%r6 -%r7 -%r8 -%r9 -%r10 -%r11 -%r12 -%r32 -%r33 -%r34 -%r35 -%r36 -%r37 -%r38 -%r39 -%r40 -%r41 -%r42 -%r43 -%r44 -%r45 +%r5\n(%r26)" style=filled fillcolor="white"] "%vHi_HCRA"; node [label="%vHi_HGNi :: I\n+%r3\n(%r3)" style=filled fillcolor="white"] "%vHi_HGNi"; node [label="%vHi_HGNj :: I\n-%r3 -%r4 +%r5\n(%r5)" style=filled fillcolor="white"] "%vHi_HGNj"; node [label="%vI_nGN3 :: I\n(%r3)" style=filled fillcolor="white"] "%vI_nGN3"; node [label="%vI_nGN4 :: I\n(%r3)" style=filled fillcolor="white"] "%vI_nGN4"; node [label="%vI_nGN5 :: I\n(%r3)" style=filled fillcolor="white"] "%vI_nGN5"; node [label="%vI_nGN6 :: I\n(%r4)" style=filled fillcolor="white"] "%vI_nGN6"; node [label="%vI_nGN7 :: I\n-%r3 -%r4 -%r5 -%r6 -%r7 -%r8 -%r9 -%r10 -%r11 -%r12 -%r32 -%r33 -%r34 -%r35 -%r36 -%r37 -%r38 -%r39 -%r40 -%r41 -%r42 -%r43 -%r44 -%r45 +%r4\n(%r28)" style=filled fillcolor="white"] "%vI_nGN7"; node [label="%vI_nGN8 :: I\n(%r5)" style=filled fillcolor="white"] "%vI_nGN8"; node [label="%vI_nGN9 :: I\n(%r3)" style=filled fillcolor="white"] "%vI_nGN9"; node [label="%vI_nGNa :: I\n(%r3)" style=filled fillcolor="white"] "%vI_nGNa"; node [label="%vI_nGNb :: I\n(%r3)" style=filled fillcolor="white"] "%vI_nGNb"; node [label="%vI_nGNc :: I\n(%r3)" style=filled fillcolor="white"] "%vI_nGNc"; node [label="%vI_nGNd :: I\n(%r3)" style=filled fillcolor="white"] "%vI_nGNd"; node [label="%vI_nGNe :: I\n(%r3)" style=filled fillcolor="white"] "%vI_nGNe"; node [label="%vI_nGNf :: I\n(%r3)" style=filled fillcolor="white"] "%vI_nGNf"; node [label="%vI_nGNh :: I\n-%r3 -%r4 -%r5 -%r6 -%r7 -%r8 -%r9 -%r10 -%r11 -%r12 -%r32 -%r33 -%r34 -%r35 -%r36 -%r37 -%r38 -%r39 -%r40 -%r41 -%r42 -%r43 -%r44 -%r45 +%r6\n(%r29)" style=filled fillcolor="white"] "%vI_nGNh"; node [label="%vI_nGNi :: I\n-%r3 +%r4\n(%r4)" style=filled fillcolor="white"] "%vI_nGNi"; node [label="%vI_nGNj :: I\n-%r3 -%r4 -%r5 +%r6\n(%r6)" style=filled fillcolor="white"] "%vI_nGNj"; node [label="%vI_nGNk :: I\n(%r3)" style=filled fillcolor="white"] "%vI_nGNk"; node [label="%vI_nGNl :: I\n(%r3)" style=filled fillcolor="white"] "%vI_nGNl"; node [label="%vI_nGNm :: I\n(%r3)" style=filled fillcolor="white"] "%vI_nGNm"; node [label="%vI_nGNn :: I\n(%r3)" style=filled fillcolor="white"] "%vI_nGNn"; node [label="%vI_nGNo :: I\n(%r3)" style=filled fillcolor="white"] "%vI_nGNo"; node [label="%vI_nGNp :: I\n(%r3)" style=filled fillcolor="white"] "%vI_nGNp"; node [label="%vI_nGNq :: I\n(%r3)" style=filled fillcolor="white"] "%vI_nGNq"; node [label="%vI_nGNr :: I\n(%r3)" style=filled fillcolor="white"] "%vI_nGNr"; node [label="%vI_nGNs :: I\n(%r3)" style=filled fillcolor="white"] "%vI_nGNs"; node [label="%vI_nGNt :: I\n(%r3)" style=filled fillcolor="white"] "%vI_nGNt"; node [label="%vI_sCRo :: I\n-%r3 -%r4 -%r5 -%r6 -%r7 -%r8 -%r9 -%r10 -%r11 -%r12 -%r32 -%r33 -%r34 -%r35 -%r36 -%r37 -%r38 -%r39 -%r40 -%r41 -%r42 -%r43 -%r44 -%r45\n(spill?)" style=filled fillcolor=white] "%vI_sCRo"; node [label="%vI_sCRp :: I\n-%r3 -%r4 -%r5 -%r6 -%r7 -%r8 -%r9 -%r10 -%r11 -%r12 -%r32 -%r33 -%r34 -%r35 -%r36 -%r37 -%r38 -%r39 -%r40 -%r41 -%r42 -%r43 -%r44 -%r45\n(%r31)" style=filled fillcolor="white"] "%vI_sCRp"; node [label="%vI_sCRr :: I\n-%r3 -%r4 -%r5 -%r6 -%r7 -%r8 -%r9 -%r10 -%r11 -%r12 -%r32 -%r33 -%r34 -%r35 -%r36 -%r37 -%r38 -%r39 -%r40 -%r41 -%r42 -%r43 -%r44 -%r45\n(spill?)" style=filled fillcolor=white] "%vI_sCRr"; node [label="%vI_sCRH :: I\n+%r3\n(%r3)" style=filled fillcolor="white"] "%vI_sCRH"; node [label="%vI_sCRM :: I\n+%r3\n(%r3)" style=filled fillcolor="white"] "%vI_sCRM"; "%vHi_HCRt" -- "%vHi_HCRu"; "%vHi_HCRt" -- "%vI_nGN6"; "%vHi_HCRt" -- "%vI_nGN7"; "%vHi_HCRt" -- "%vI_nGN8"; "%vHi_HCRu" -- "%vHi_HCRA"; "%vHi_HCRu" -- "%vHi_HGNi"; "%vHi_HCRu" -- "%vHi_HGNj"; "%vHi_HCRu" -- "%vI_nGN6"; "%vHi_HCRu" -- "%vI_nGN7"; "%vHi_HCRu" -- "%vI_nGN8"; "%vHi_HCRu" -- "%vI_nGNh"; "%vHi_HCRu" -- "%vI_nGNi"; "%vHi_HCRu" -- "%vI_nGNj"; "%vHi_HCRu" -- "%vI_sCRo"; "%vHi_HCRu" -- "%vI_sCRp"; "%vHi_HCRu" -- "%vI_sCRr"; "%vHi_HCRu" -- "%vI_sCRH"; "%vHi_HCRA" -- "%vHi_HGNi"; "%vHi_HCRA" -- "%vHi_HGNj"; "%vHi_HCRA" -- "%vI_nGN7"; "%vHi_HCRA" -- "%vI_nGNh"; "%vHi_HCRA" -- "%vI_nGNi"; "%vHi_HCRA" -- "%vI_nGNj"; "%vHi_HCRA" -- "%vI_sCRo"; "%vHi_HCRA" -- "%vI_sCRp"; "%vHi_HCRA" -- "%vI_sCRr"; "%vHi_HCRA" -- "%vI_sCRH"; "%vHi_HGNi" -- "%vI_nGN7"; "%vHi_HGNi" -- "%vI_nGNh"; "%vHi_HGNi" -- "%vI_nGNi"; "%vHi_HGNi" -- "%vI_sCRo"; "%vHi_HGNi" -- "%vI_sCRp"; "%vHi_HGNi" -- "%vI_sCRr"; "%vHi_HGNj" -- "%vI_nGN7"; "%vHi_HGNj" -- "%vI_nGNh"; "%vHi_HGNj" -- "%vI_nGNj"; "%vHi_HGNj" -- "%vI_sCRo"; "%vHi_HGNj" -- "%vI_sCRp"; "%vHi_HGNj" -- "%vI_sCRr"; "%vI_nGN6" -- "%vI_nGN7"; "%vI_nGN6" -- "%vI_nGN8"; "%vI_nGN7" -- "%vI_nGN8"; "%vI_nGN7" -- "%vI_nGNh"; "%vI_nGN7" -- "%vI_nGNi"; "%vI_nGN7" -- "%vI_nGNj"; "%vI_nGN7" -- "%vI_sCRo"; "%vI_nGN7" -- "%vI_sCRp"; "%vI_nGN7" -- "%vI_sCRr"; "%vI_nGN7" -- "%vI_sCRH"; "%vI_nGNh" -- "%vI_nGNi"; "%vI_nGNh" -- "%vI_nGNj"; "%vI_nGNh" -- "%vI_sCRo"; "%vI_nGNh" -- "%vI_sCRp"; "%vI_nGNh" -- "%vI_sCRr"; "%vI_nGNh" -- "%vI_sCRH"; "%vI_nGNi" -- "%vI_sCRo"; "%vI_nGNi" -- "%vI_sCRp"; "%vI_nGNi" -- "%vI_sCRr"; "%vI_nGNj" -- "%vI_sCRo"; "%vI_nGNj" -- "%vI_sCRp"; "%vI_nGNj" -- "%vI_sCRr"; "%vI_nGNo" -- "%vI_sCRo"; "%vI_nGNo" -- "%vI_sCRp"; "%vI_nGNo" -- "%vI_sCRr"; "%vI_nGNp" -- "%vI_sCRo"; "%vI_nGNp" -- "%vI_sCRp"; "%vI_nGNp" -- "%vI_sCRr"; "%vI_sCRo" -- "%vI_sCRp"; "%vI_sCRo" -- "%vI_sCRr"; "%vI_sCRo" -- "%vI_sCRH"; "%vI_sCRo" -- "%vI_sCRM"; "%vI_sCRp" -- "%vI_sCRr"; "%vI_sCRp" -- "%vI_sCRH"; "%vI_sCRp" -- "%vI_sCRM"; "%vI_sCRr" -- "%vI_sCRH"; "%vI_sCRr" -- "%vI_sCRM"; } Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 23 22:14:04 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Dec 2016 22:14:04 -0000 Subject: [GHC] #13033: GHC Panics with "colorGraph: trivially colorable nodes didn't color!" on PPC In-Reply-To: <042.4e47f55bc923968731a525ef1cc09806@haskell.org> References: <042.4e47f55bc923968731a525ef1cc09806@haskell.org> Message-ID: <057.37dc70d9bddc8880f481f450ca79e69a@haskell.org> #13033: GHC Panics with "colorGraph: trivially colorable nodes didn't color!" on PPC -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.2-rc2 Resolution: | Keywords: Operating System: AIX | Architecture: powerpc Type of failure: Compile-time | Test Case: crash or panic | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by hvr): * cc: ptrommler (removed) * cc: trommler (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 23 22:25:34 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Dec 2016 22:25:34 -0000 Subject: [GHC] #11501: Building nofib/fibon returns permission denied In-Reply-To: <042.7732253ef90810c7acc41907aecb19ff@haskell.org> References: <042.7732253ef90810c7acc41907aecb19ff@haskell.org> Message-ID: <057.57f484c6650fd432a94a4a2f729dd9eb@haskell.org> #11501: Building nofib/fibon returns permission denied -------------------------------------+------------------------------------- Reporter: rem | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: NoFib benchmark | Version: 7.10.3 suite | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > @simonpj: Do you also use nofib to test speed of compilation or just efficiency of generated code? Primarily the latter; but the former might be good too, esp if it was a new column in the table at the top of `nofib-analyse`'s output. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 23 22:37:14 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Dec 2016 22:37:14 -0000 Subject: [GHC] #13033: GHC Panics with "colorGraph: trivially colorable nodes didn't color!" on PPC In-Reply-To: <042.4e47f55bc923968731a525ef1cc09806@haskell.org> References: <042.4e47f55bc923968731a525ef1cc09806@haskell.org> Message-ID: <057.1957e728f27fd830311c950b1409f9df@haskell.org> #13033: GHC Panics with "colorGraph: trivially colorable nodes didn't color!" on PPC -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: AIX | Architecture: powerpc Type of failure: Compile-time | Test Case: crash or panic | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * version: 8.0.2-rc2 => 8.1 Comment: This is due to 6a5d13c4ade5bbb84873970065a1acd1546f6c31, which restored the function of `-fregs-graph`, which was previously broken due to #7679 and #8657. Given that `-fregs-graph` is broken-ish anyways (see #7679) I'm going to revert on `ghc-8.0`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 23 22:48:03 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Dec 2016 22:48:03 -0000 Subject: [GHC] #13005: Mac OSX uses MAP_ANON in place of MAP_ANONYMOUS In-Reply-To: <046.d43a09b5f43348df6b22d776514a766b@haskell.org> References: <046.d43a09b5f43348df6b22d776514a766b@haskell.org> Message-ID: <061.04b11f0a3cf5fb71ad273aa130195917@haskell.org> #13005: Mac OSX uses MAP_ANON in place of MAP_ANONYMOUS -------------------------------------+------------------------------------- Reporter: gracjan | Owner: Type: bug | Status: patch Priority: high | Milestone: Component: Compiler | Version: 8.0.1 (Linking) | Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2881 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"2689a1692636521777f007861a484e7064b2d696/ghc" 2689a169/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2689a1692636521777f007861a484e7064b2d696" Define MAP_ANONYMOUS on systems that only provide MAP_ANON Reviewers: simonmar, erikd, austin, bgamari Reviewed By: bgamari Subscribers: gracjan, rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D2881 GHC Trac Issues: #13005 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 23 22:48:03 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Dec 2016 22:48:03 -0000 Subject: [GHC] #11216: RebindableSyntax with pattern guards needs `fail` In-Reply-To: <047.a0c77911e1a5729e917abc9d45aa382b@haskell.org> References: <047.a0c77911e1a5729e917abc9d45aa382b@haskell.org> Message-ID: <062.591b6c26eb979fd46b8ae29e6f2070f3@haskell.org> #11216: RebindableSyntax with pattern guards needs `fail` -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: | RebindableSyntax Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T11216, | T11216A Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2896 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"8f89e76389569b73ce0d7550302641bbea438dfc/ghc" 8f89e76/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8f89e76389569b73ce0d7550302641bbea438dfc" rename: Don't require 'fail' in non-monadic contexts Fixes #11216. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 23 22:48:03 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Dec 2016 22:48:03 -0000 Subject: [GHC] #8809: Prettier error messages? In-Reply-To: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> References: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> Message-ID: <062.940ff7f9e7b47aa6b648ec17526ee4c1@haskell.org> #8809: Prettier error messages? -------------------------------------+------------------------------------- Reporter: joelteon | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): #8809,#10073,#10179,#12906 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"158530a5450b27eb5ae2d75b7895fd1662dde13b/ghc" 158530a5/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="158530a5450b27eb5ae2d75b7895fd1662dde13b" Add caret diagnostics This is controlled by -f[no-]diagnostics-show-caret. Example of what it looks like: ``` | 42 | x = 1 + () | ^^^^^^ ``` This is appended to each diagnostic message. Test Plan: testsuite/tests/warnings/should_fail/CaretDiagnostics1 testsuite/tests/warnings/should_fail/CaretDiagnostics2 Reviewers: simonpj, austin, bgamari Reviewed By: simonpj, bgamari Subscribers: joehillen, mpickering, Phyx, simonpj, alanz, thomie Differential Revision: https://phabricator.haskell.org/D2718 GHC Trac Issues: #8809 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 23 22:53:56 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Dec 2016 22:53:56 -0000 Subject: [GHC] #13005: Mac OSX uses MAP_ANON in place of MAP_ANONYMOUS In-Reply-To: <046.d43a09b5f43348df6b22d776514a766b@haskell.org> References: <046.d43a09b5f43348df6b22d776514a766b@haskell.org> Message-ID: <061.b648798dd15584eecd220be23f713fc4@haskell.org> #13005: Mac OSX uses MAP_ANON in place of MAP_ANONYMOUS -------------------------------------+------------------------------------- Reporter: gracjan | Owner: Type: bug | Status: merge Priority: high | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 (Linking) | Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2881 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge * milestone: => 8.0.2 Comment: Did you really observe this on 8.0.1, gracjan? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 23 23:07:35 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Dec 2016 23:07:35 -0000 Subject: [GHC] #13013: Add readMaybe to Prelude (possibly readEither too), make Haddocks for read more cautionary In-Reply-To: <046.3d6f3ae3075d3638bfdec9ce7d4dde8f@haskell.org> References: <046.3d6f3ae3075d3638bfdec9ce7d4dde8f@haskell.org> Message-ID: <061.22fcf01ea3a9c1f4e2a5807d658be3d4@haskell.org> #13013: Add readMaybe to Prelude (possibly readEither too), make Haddocks for read more cautionary -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): > To be clear, the issue is that the newly exposed `readMaybe` and `readEither` names could clash with pre-existing definitions that use the same names, right? Yep. Four weeks with the holidays probably makes sense. The phrasing in that section was largely put together to encourage folks patching the larger diaspora of packages that fall under the core libraries committee preview to actually use the issue trackers in question -- mostly because `libraries@` won't care about, say, minutiae about how some combinators in the `unix` package behave on OpenBSD. I probably should add some language encouraging `base`- and especially `Prelude`-affecting proposals to expect to always have to go through `libraries@` as the impact spreads to everyone. Anything submitted here is likely to get maybe 5-10 pairs of eyeballs on it. Submitting to `libraries@` enables a lot more feedback. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 23 23:19:56 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Dec 2016 23:19:56 -0000 Subject: [GHC] #8809: Prettier error messages? In-Reply-To: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> References: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> Message-ID: <062.73f9feab622221520558baea860298ba@haskell.org> #8809: Prettier error messages? -------------------------------------+------------------------------------- Reporter: joelteon | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): #8809,#10073,#10179,#12906 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): One step closer to prettiness! However, I still think having more semantically rich messages would be great for tooling authors. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 23 23:35:15 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Dec 2016 23:35:15 -0000 Subject: [GHC] #13027: Core lint errors compiling containers HEAD with GHC HEAD In-Reply-To: <044.039b1d41ac9eefe9789d53b67dd9193b@haskell.org> References: <044.039b1d41ac9eefe9789d53b67dd9193b@haskell.org> Message-ID: <059.f69c460d24bef1be01bcfa0575777baf@haskell.org> #13027: Core lint errors compiling containers HEAD with GHC HEAD -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Building GHC | Test Case: failed | simplCore/should_compile/T13027 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by erikd): I tried building with [changeset:"75e8c305a497ec5ad3e5a5d9ff73bbf6f7a8a000/ghc" 75e8c305/ghc] and it still fails. Does that meant this needs to be fixed in containers? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 23 23:48:52 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Dec 2016 23:48:52 -0000 Subject: [GHC] #13027: Core lint errors compiling containers HEAD with GHC HEAD In-Reply-To: <044.039b1d41ac9eefe9789d53b67dd9193b@haskell.org> References: <044.039b1d41ac9eefe9789d53b67dd9193b@haskell.org> Message-ID: <059.a80ebba8ccd2a6b87c7c4a926b1e00f6@haskell.org> #13027: Core lint errors compiling containers HEAD with GHC HEAD -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Building GHC | Test Case: failed | simplCore/should_compile/T13027 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): That's odd. I didn't test with containers, only with the test in comment:1. In pinrciple I can try to look, but not over Christmas. Anything anyone can do to narrow it down to a repro case would be very helpful. > Does that meant this needs to be fixed in containers? No: Lint errors are alwyas GHC bugs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 24 00:23:08 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Dec 2016 00:23:08 -0000 Subject: [GHC] #13026: RFC functions for sums and products In-Reply-To: <051.dcc6584e5b5e34920ae3e9c70dbd6181@haskell.org> References: <051.dcc6584e5b5e34920ae3e9c70dbd6181@haskell.org> Message-ID: <066.32ddca9d0ebae9d284dee0b49ab9514a@haskell.org> #13026: RFC functions for sums and products -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): [https://mail.haskell.org/pipermail/libraries/2016-December/027489.html libraries discussion] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 24 02:17:40 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Dec 2016 02:17:40 -0000 Subject: [GHC] #8809: Prettier error messages? In-Reply-To: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> References: <047.4dbdad421fcd945584d210433034ccb5@haskell.org> Message-ID: <062.1df54cadb44d7634035597f13a6cd74f@haskell.org> #8809: Prettier error messages? -------------------------------------+------------------------------------- Reporter: joelteon | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): #8809,#10073,#10179,#12906 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:45 bgamari]: > However, I still think having more semantically rich messages would be great for tooling authors. I have a student doing an independent study with me next semester who has expressed an interest in doing this. We've only really started the conversations on what she will work on, but at the moment, refactoring `SDoc` along the lines of comment:3 seems like the leading candidate. So there is reason to be hopeful about this! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 24 02:26:20 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Dec 2016 02:26:20 -0000 Subject: [GHC] #13018: TH-spliced pattern synonym declaration fails to typecheck In-Reply-To: <050.321896de80824d0ab018c753e6e2c2e9@haskell.org> References: <050.321896de80824d0ab018c753e6e2c2e9@haskell.org> Message-ID: <065.6e5634de791df86dcf072dc090516ada@haskell.org> #13018: TH-spliced pattern synonym declaration fails to typecheck -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Agreed that the splitting rule must be implemented in the TH quoting mechanism. Check out `RnTypes.extractHsTyRdrTyVars` and friends. If you have `HsType Name` (instead of `HsType RdrName`), you may be able to generalize these functions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 24 03:18:29 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Dec 2016 03:18:29 -0000 Subject: [GHC] #13025: Type family reduction irregularity (change from 7.10.3 to 8.0.1) In-Reply-To: <046.8df164442eeb4f6a3254ed537eb97826@haskell.org> References: <046.8df164442eeb4f6a3254ed537eb97826@haskell.org> Message-ID: <061.9754b6dcfd588234fdbeb6ed5d08f55c@haskell.org> #13025: Type family reduction irregularity (change from 7.10.3 to 8.0.1) -------------------------------------+------------------------------------- Reporter: acowley | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.3 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | simplCore/should_compile/T13025 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I don't think your patch is quite right, Simon. Here is the main payload: {{{ pushCoArg :: Coercion -> CoreArg -> Maybe (CoreArg, Coercion) -- We have (fun |> co) arg, and we want to transform it to -- (fun arg) |> co -- This may fail, e.g. if (fun :: N) where N is a newtype -- C.f. simplCast in Simplify.hs pushCoArg co arg = case arg of Type ty | isForAllTy tyL -> ASSERT2( isForAllTy tyR, ppr co $$ ppr ty ) Just (Type ty, mkInstCo co (mkNomReflCo ty)) _ | isFunTy tyL , [co1, co2] <- decomposeCo 2 co -- If co :: (tyL1 -> tyL2) ~ (tyR1 -> tyR2) -- then co1 :: tyL1 ~ tyR1 -- co2 :: tyL2 ~ tyR2 -> ASSERT2( isFunTy tyR, ppr co $$ ppr arg ) Just (mkCast arg (mkSymCo co1), co2) _ -> Nothing where Pair tyL tyR = coercionKind co }}} This implements two of the push rules from every FC paper. But note that forall-types can now be heterogeneous. That is, `fun` and `fun |> co` might expect types of different kinds. Your patch does not take this possibility into account. I recommend this: {{{ case arg of Type ty | isForAllTy tyL -> ASSERT2( isForAllTy tyR, ppr co $$ ppr ty ) -- co :: (forall (a1 :: k1). ty1) ~ (forall (a2 :: k2). ty2) let co1 = mkSymCo (mkNthCo 0 co) -- co1 :: k2 ~ k1 ty' = ty `mkCastTy` co1 co2 = mkInstCo co (mkCoherenceLeftCo (mkNomReflCo ty) (mkSymCo co1)) -- co2 :: ty1[ty |> co1 / a1] ~ ty2[ty / a2] in Just (Type ty', co2) }}} Note that `NthCo` can extract an equality between the kinds of the types related by a coercion between forall-types. See the `NthCo` case in !CoreLint. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 24 03:20:04 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Dec 2016 03:20:04 -0000 Subject: [GHC] #13032: Redundant forcing of Given dictionaries In-Reply-To: <046.811080f481e777da656f14add09b1cc8@haskell.org> References: <046.811080f481e777da656f14add09b1cc8@haskell.org> Message-ID: <061.c5adee99ce9131435a19d8d10f4def2a@haskell.org> #13032: Redundant forcing of Given dictionaries -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): How can we know, though, that the equality isn't bottom? The "simple optimizer" used to indeed throw such `case`s away, but then #11230 was reported, and I wrote 1722fa106e10e63160bb2322e2ccb830fd5b9ab3. So we should proceed carefully here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 24 11:15:07 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Dec 2016 11:15:07 -0000 Subject: [GHC] #11501: Building nofib/fibon returns permission denied In-Reply-To: <042.7732253ef90810c7acc41907aecb19ff@haskell.org> References: <042.7732253ef90810c7acc41907aecb19ff@haskell.org> Message-ID: <057.983dc377dae9ef48f846f9e37fb753dc@haskell.org> #11501: Building nofib/fibon returns permission denied -------------------------------------+------------------------------------- Reporter: rem | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: NoFib benchmark | Version: 7.10.3 suite | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Replying to [comment:15 gracjan]: > And in distant future: > > 1. Run execution speed tests on TravisCI in multiple combinations of os/ghc/flags/test. > 2. Run compilation speed tests on TravisCI in multiple combinations of os/ghc/flags/test. I am pessimistic about this part. It is already hard to get stable speed test results on a single real dedicated hardware machine. Getting useful data out of random virtual machines provided for free online will unfortunately not work well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 24 14:22:12 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Dec 2016 14:22:12 -0000 Subject: [GHC] #12837: KnownNat and KnownSymbol should be abstract In-Reply-To: <049.214432e5cb536d2a77e4b4992c98f5b4@haskell.org> References: <049.214432e5cb536d2a77e4b4992c98f5b4@haskell.org> Message-ID: <064.e878855dc50dd8a8877c8e08e094be77@haskell.org> #12837: KnownNat and KnownSymbol should be abstract -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: sean Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sean): * owner: => sean Comment: Also a newbie but I've managed to get this working in the way you described. I'll start following the submission instructions by making myself the owner, apologies if I'm mistaken in doing this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 24 16:04:08 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Dec 2016 16:04:08 -0000 Subject: [GHC] #13034: clean memory in GHCi Message-ID: <044.49433b006c9e0b96f956935cd2b35747@haskell.org> #13034: clean memory in GHCi -------------------------------------+------------------------------------- Reporter: vanto | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Suppose you have a program that fills all memory up so what GHCi crash by displaying the "out of memory" error. But you don't know. You run the programm and a few seconds after you stop it by pressing ctrl-c. Then you start another programm that is correct like computing a factorial and suddenly GHCi crash. GHCi crash because there is not enough memory. All the values of the first program remained in memory and have not been deleted. Can we have a command available from the prompt that clean the memory? For example, Prelude> :clean memory or Prelude> :clm in order to avoid restart GHCi. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 24 16:17:35 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Dec 2016 16:17:35 -0000 Subject: [GHC] #12837: KnownNat and KnownSymbol should be abstract In-Reply-To: <049.214432e5cb536d2a77e4b4992c98f5b4@haskell.org> References: <049.214432e5cb536d2a77e4b4992c98f5b4@haskell.org> Message-ID: <064.1727a7c23bf398966ef2c6c04373bad9@haskell.org> #12837: KnownNat and KnownSymbol should be abstract -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: sean Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): No problems so far Sean! If you need any help then feel free to ask here or on the IRC channel. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 24 16:48:21 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Dec 2016 16:48:21 -0000 Subject: [GHC] #12837: KnownNat and KnownSymbol should be abstract In-Reply-To: <049.214432e5cb536d2a77e4b4992c98f5b4@haskell.org> References: <049.214432e5cb536d2a77e4b4992c98f5b4@haskell.org> Message-ID: <064.63957badaf8127cc306ac272ce01ccbd@haskell.org> #12837: KnownNat and KnownSymbol should be abstract -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: sean Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2898 Wiki Page: | -------------------------------------+------------------------------------- Changes (by sean): * differential: => Phab:D2898 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 24 17:34:55 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Dec 2016 17:34:55 -0000 Subject: [GHC] #12837: Disallow users to write instances for KnownNat and KnownSymbol (was: KnownNat and KnownSymbol should be abstract) In-Reply-To: <049.214432e5cb536d2a77e4b4992c98f5b4@haskell.org> References: <049.214432e5cb536d2a77e4b4992c98f5b4@haskell.org> Message-ID: <064.188abfe1a9c63305b3452123fdeb994d@haskell.org> #12837: Disallow users to write instances for KnownNat and KnownSymbol -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: sean Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2898 Wiki Page: | -------------------------------------+------------------------------------- Description changed by sean: @@ -9,3 +9,3 @@ - This is accepted (albeit with a warning about the missing `natSing` - method). I think it should be rejected, as should an instance of - `KnownSymbol`. Compare doing the same thing with `Typeable`, which says: + Originally this was accepted (albeit with a warning about the missing + `natSing` method). It is now rejected, as with instances of `KnownSymbol`, + in the same way as instances of `Typeable`, which says: New description: Consider the following patent nonsense: {{{#!hs {-# LANGUAGE FlexibleInstances #-} import GHC.TypeLits instance KnownNat n }}} Originally this was accepted (albeit with a warning about the missing `natSing` method). It is now rejected, as with instances of `KnownSymbol`, in the same way as instances of `Typeable`, which says: {{{ Class ‘Typeable’ does not support user-specified instances }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 25 02:37:07 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Dec 2016 02:37:07 -0000 Subject: [GHC] #13035: GHC enters a loop when partial type signatures and advanced type level code mix Message-ID: <043.73bcb566c7aa5daa0f1f227af5f74322@haskell.org> #13035: GHC enters a loop when partial type signatures and advanced type level code mix -------------------------------------+------------------------------------- Reporter: xcmw | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC loops when compiling this code. Replacing the _ with the actual type fixes the error. {{{#!hs {-# LANGUAGE PolyKinds, DataKinds, TypeOperators, TypeFamilies, TemplateHaskell, GADTs, PartialTypeSignatures #-} import Data.Vinyl import Data.Singletons.TH newtype MyAttr a b = MyAttr { _unMyAttr :: MyFun (a b) } type MyRec a b = Rec (MyAttr a) b type family MyFun (a :: k1) :: k2 data GY (a :: k1) (b :: k2) (c :: k1 -> k3) (d :: k1) data GNone (a :: k1) type family GYTF a where GYTF (GY a b _ a) = b GYTF (GY _ _ c d) = MyFun (c d) type instance MyFun (GY a b c d) = GYTF (GY a b c d) type family GNoneTF (a :: k1) :: k2 where type instance MyFun (GNone a) = GNoneTF a type (a :: k1) =: (b :: k2) = a `GY` b type (a :: j1 -> j2) $ (b :: j1) = a b infixr 0 $ infixr 9 =: data FConst (a :: *) (b :: Fields) data FApply (a :: * -> * -> *) b c (d :: Fields) data FMap (a :: * -> *) b (d :: Fields) type instance MyFun (FConst a b) = a type instance MyFun (FApply b c d a) = b (MyFun (c a)) (MyFun (d a)) type instance MyFun (FMap b c a) = b (MyFun (c a)) data Fields = Name | Author | Image | Description | Ingredients | Instructions | CookTime | PrepTime | TotalTime | Yield | Nutrition | Tags | Url | Section | Items | Subsections | Calories | Carbohydrates | Cholesterol | Fat | Fiber | Protien | SaturatedFat | Sodium | Sugar | TransFat | UnsaturatedFat | ServingSize genSingletons [ ''Fields ] (=::) :: sing f -> MyFun (a f) -> MyAttr a f _ =:: x = MyAttr x type NutritionT = Calories =: Maybe Int $ Carbohydrates =: Maybe Int $ Cholesterol =: Maybe Int $ Fat =: Maybe Int $ Fiber =: Maybe Int $ Protien =: Maybe Int $ SaturatedFat =: Maybe Int $ Sodium =: Maybe Int $ Sugar =: Maybe Int $ TransFat =: Maybe Int $ UnsaturatedFat =: Maybe Int $ ServingSize =: String $ GNone type NutritionRec = MyRec NutritionT ['Calories, 'Carbohydrates, 'Cholesterol, 'Fat, 'Fiber, 'Protien, 'SaturatedFat, 'Sodium, 'Sugar, 'TransFat, 'UnsaturatedFat, 'ServingSize] type RecipeT = Name =: String $ Author =: String $ Image =: String $ Description =: String $ CookTime =: Maybe Int $ PrepTime =: Maybe Int $ TotalTime =: Maybe Int $ Yield =: String $ Nutrition =: NutritionRec $ Tags =: [String] $ Url =: String $ GNone type RecipeFormatter = FApply (->) (FConst [String]) (FMap IO RecipeT) g :: MyRec RecipeFormatter _ --'[ 'Author ] Uncomment to prevent loop g = SAuthor =:: (\a -> return "Hi") :& RNil main = putStrLn "Hi" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 25 06:45:01 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Dec 2016 06:45:01 -0000 Subject: [GHC] #11501: Building nofib/fibon returns permission denied In-Reply-To: <042.7732253ef90810c7acc41907aecb19ff@haskell.org> References: <042.7732253ef90810c7acc41907aecb19ff@haskell.org> Message-ID: <057.2f0555920e3b23baa7d3e5ff6021ebdc@haskell.org> #11501: Building nofib/fibon returns permission denied -------------------------------------+------------------------------------- Reporter: rem | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: NoFib benchmark | Version: 7.10.3 suite | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by gracjan): @bgamari: Your database contains many duplicate results: {{{ ghc_perf=# select * from results where commit_id = 1481 and test_id = 14005; result_id | commit_id | test_env_id | test_id | result_value -----------+-----------+-------------+---------+-------------- 2666081 | 1481 | 1 | 14005 | 68981392 16414734 | 1481 | 1 | 14005 | 68981392 27735337 | 1481 | 1 | 14005 | 68981392 29330138 | 1481 | 1 | 14005 | 68981392 29950528 | 1481 | 1 | 14005 | 68981392 30987336 | 1481 | 1 | 14005 | 68981392 32588450 | 1481 | 1 | 14005 | 68981392 35533576 | 1481 | 1 | 14005 | 68981392 37080771 | 1481 | 1 | 14005 | 68981392 38801911 | 1481 | 1 | 14005 | 68981392 38869658 | 1481 | 1 | 14005 | 68981392 38871489 | 1481 | 1 | 14005 | 68981392 38873320 | 1481 | 1 | 14005 | 68981392 (13 rows) }}} I'm not sure why is this. Have you been testing same (commit,env,test) configuration multiple times? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 25 06:48:28 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Dec 2016 06:48:28 -0000 Subject: [GHC] #11501: Building nofib/fibon returns permission denied In-Reply-To: <042.7732253ef90810c7acc41907aecb19ff@haskell.org> References: <042.7732253ef90810c7acc41907aecb19ff@haskell.org> Message-ID: <057.b12d4931b8a71e9e4f84a409dffccd21@haskell.org> #11501: Building nofib/fibon returns permission denied -------------------------------------+------------------------------------- Reporter: rem | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: NoFib benchmark | Version: 7.10.3 suite | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by gracjan): @nomeata: I was thinking about Travis as provider for data points that are more stable, like valgrinds instruction count or cache misses. I know that TravisCI changed to GCE recently and that should provide more stable results. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 25 08:03:54 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Dec 2016 08:03:54 -0000 Subject: [GHC] #11501: Building nofib/fibon returns permission denied In-Reply-To: <042.7732253ef90810c7acc41907aecb19ff@haskell.org> References: <042.7732253ef90810c7acc41907aecb19ff@haskell.org> Message-ID: <057.f45a76da2ff094a1a8d06ea051b9587b@haskell.org> #11501: Building nofib/fibon returns permission denied -------------------------------------+------------------------------------- Reporter: rem | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: NoFib benchmark | Version: 7.10.3 suite | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by gracjan): If you cared to deduplicate: {{{ begin; delete from results where exists (select true from results s2 where s2.result_id < results.result_id and s2.commit_id = results.commit_id and s2.test_env_id = results.test_env_id and s2.test_id = results.test_id and s2.result_value = results.result_value); -- DELETE 24126761 alter table results add constraint results_unique unique (test_env_id,commit_id,test_id); commit; }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 25 11:00:13 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Dec 2016 11:00:13 -0000 Subject: [GHC] #13036: educational purpose Message-ID: <044.8c15894968b6cebbc497e8dc88d5e8f1@haskell.org> #13036: educational purpose -------------------------------------+------------------------------------- Reporter: vanto | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- For educational purpose : can we have in GHCi time set by a function to run as well as its occupation of memory by typing a command available from the prompt? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Dec 25 14:38:20 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Dec 2016 14:38:20 -0000 Subject: [GHC] #13037: educational purpose 2 Message-ID: <044.2b99dbcf24e1229ef5c6820c7cb7241f@haskell.org> #13037: educational purpose 2 -------------------------------------+------------------------------------- Reporter: vanto | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The goal is to have, in GHCi, the interim results provided by the function before the end result by a command available from the prompt, like this: for example:[[BR]] Prelude> g op n [] = n ; g op n (h:t) = h `op` g op n t[[BR]] Prelude> :stp[[BR]] Prelude> g (*) 2 [1..3][[BR]] 1* (*) 2 [2,3][[BR]] 1*2 (*) 2 [3][[BR]] 1*2*3 (*) 2 [][[BR]] 1*2*3*2[[BR]] 12[[BR]] Prelude>[[BR]] And to quit the mode we write from the prompt a command like this[[BR]] Prelude> :quitstp -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 26 00:39:37 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Dec 2016 00:39:37 -0000 Subject: [GHC] #13026: RFC functions for sums and products In-Reply-To: <051.dcc6584e5b5e34920ae3e9c70dbd6181@haskell.org> References: <051.dcc6584e5b5e34920ae3e9c70dbd6181@haskell.org> Message-ID: <066.55ef7818f7e43deed33d29fc30231dac@haskell.org> #13026: RFC functions for sums and products -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Some more functions (would be `Iso`s in lens) {{{#!hs runSum :: Sum f g a -> Either (f a) (g a) runSum = Left |||| Right runProduct :: Product f g a -> (f a, g a) runProduct (Pair fa ga) = (fa, ga) }}} Used [https://github.com/bitemyapp/nt-in- haskell/blob/2563047caaffa1a88c540128424a250f0d267aaf/answers/src/NT/Answers/D.hs here]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 26 01:11:08 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Dec 2016 01:11:08 -0000 Subject: [GHC] #13026: RFC functions for sums and products In-Reply-To: <051.dcc6584e5b5e34920ae3e9c70dbd6181@haskell.org> References: <051.dcc6584e5b5e34920ae3e9c70dbd6181@haskell.org> Message-ID: <066.1bda4d6462573bd83a0c02ab2a477341@haskell.org> #13026: RFC functions for sums and products -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): These functions and more are defined [https://github.com/sboosali /commands- core/blob/6bcfe72aef9b55f366a4e215720a9475de2d2e6f/sources/Data/HTypes.hs here] {{{#!hs (.|||.) :: (f1 :~> g) -> (f2 :~> g) -> ((f1 :+: f2) :~> g) (<|||>) :: (f1 :~> (m :. g)) -> (f2 :~> (m :. g)) -> ((f1 :+: f2) :~> (m :. g) getFirst, outL :: (f :*: g) :~> f getSecond, inL :: (f :*: g) :~> g getSecond (Pair _ g) = g (.&&&.) :: (f :~> g1) -> (f :~> g2) -> (f :~> (g1 :*: g2)) (<&&&>) :: (Applicative m) => (f :~> (m :. g1)) -> (f :~> (m :. g2)) -> (f :~> (m :. (g1 :*: g2))) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 26 01:36:43 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Dec 2016 01:36:43 -0000 Subject: [GHC] #13026: RFC functions for sums and products In-Reply-To: <051.dcc6584e5b5e34920ae3e9c70dbd6181@haskell.org> References: <051.dcc6584e5b5e34920ae3e9c70dbd6181@haskell.org> Message-ID: <066.f3b999854112467786e12e4fedfc5b4b@haskell.org> #13026: RFC functions for sums and products -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Purescript also includes this function for `Data.Functor.Compose` {{{#!hs bihoistCompose :: forall f g h i . Functor f => (f ~> h) -> (g ~> i) -> Compose f g ~> Compose h i bihoistCompose natF natG (Compose fga) = Compose (natF (map natG fga)) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 26 03:23:10 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Dec 2016 03:23:10 -0000 Subject: [GHC] #13001: EnumFromThenTo is is not a good producer In-Reply-To: <045.652a4f5a016a7134707107ddee18203b@haskell.org> References: <045.652a4f5a016a7134707107ddee18203b@haskell.org> Message-ID: <060.a2bbbd09f7e06abe4795f062dae9c8d9@haskell.org> #13001: EnumFromThenTo is is not a good producer -------------------------------------+------------------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by akio): * cc: akio (added) Comment: I have a fix to this problem locally, but I've never got around to submitting a patch. I believe the problem is that `efdtIntFB` is not marked `INLINE [0]`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 26 05:26:39 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Dec 2016 05:26:39 -0000 Subject: [GHC] #229: Integer overflow in array allocation In-Reply-To: <045.791e3ea8f042e6c7d57ae4cd25dec693@haskell.org> References: <045.791e3ea8f042e6c7d57ae4cd25dec693@haskell.org> Message-ID: <060.cfa5ab7228ec981156f06cc3142d09ad@haskell.org> #229: Integer overflow in array allocation -------------------------------------+------------------------------------- Reporter: josefs | Owner: bgamari Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Core Libraries | Version: 7.9 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by akio): * cc: akio (added) Comment: Sorry if I'm missing something, but the overflow check looks like it may be incorrect. For example, if `Int` is 32 bits wide, `0x58000000 * 4 :: Int` is greater than `0x58000000`, so it passes the test, but the multiplication is still overflowing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 26 14:56:01 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Dec 2016 14:56:01 -0000 Subject: [GHC] #11216: RebindableSyntax with pattern guards needs `fail` In-Reply-To: <047.a0c77911e1a5729e917abc9d45aa382b@haskell.org> References: <047.a0c77911e1a5729e917abc9d45aa382b@haskell.org> Message-ID: <062.8932385bbc6324a4adc91980eff8300f@haskell.org> #11216: RebindableSyntax with pattern guards needs `fail` -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: | RebindableSyntax Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T11216, | T11216A Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2896 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"48a5da9ac6abd42e713402bd38612ce6624cac1b/ghc" 48a5da9a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="48a5da9ac6abd42e713402bd38612ce6624cac1b" rename: Add note describing #11216 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 26 14:56:22 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Dec 2016 14:56:22 -0000 Subject: [GHC] #11216: RebindableSyntax with pattern guards needs `fail` In-Reply-To: <047.a0c77911e1a5729e917abc9d45aa382b@haskell.org> References: <047.a0c77911e1a5729e917abc9d45aa382b@haskell.org> Message-ID: <062.2bcb95017d758a48fefdcf7d3817b462@haskell.org> #11216: RebindableSyntax with pattern guards needs `fail` -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: | RebindableSyntax Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T11216, | T11216A Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2896 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 26 18:00:20 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Dec 2016 18:00:20 -0000 Subject: [GHC] #229: Integer overflow in array allocation In-Reply-To: <045.791e3ea8f042e6c7d57ae4cd25dec693@haskell.org> References: <045.791e3ea8f042e6c7d57ae4cd25dec693@haskell.org> Message-ID: <060.066b39f47b948d445818eb724196c408@haskell.org> #229: Integer overflow in array allocation -------------------------------------+------------------------------------- Reporter: josefs | Owner: bgamari Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Core Libraries | Version: 7.9 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Ugh, yes, of course. Silly me. Fix coming. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 26 22:07:21 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Dec 2016 22:07:21 -0000 Subject: [GHC] #13037: Single-Stepping evaluation in GHCi (was: educational purpose 2) In-Reply-To: <044.2b99dbcf24e1229ef5c6820c7cb7241f@haskell.org> References: <044.2b99dbcf24e1229ef5c6820c7cb7241f@haskell.org> Message-ID: <059.38c6fcdf665eaa21f8915a0546f6e1b0@haskell.org> #13037: Single-Stepping evaluation in GHCi -------------------------------------+------------------------------------- Reporter: vanto | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: new => closed * resolution: => invalid Comment: As great as it would be to have this, I believe it is unrealistic within the scope of GHC. The code that is run by GHC has little resemblance with the original source code, and `[1..3]` does not step to `[2,3]`, for example. The closest support for this is the GHCi debugger, see the user’s guide for it. But it is more suited for experienced developers. There might be dedicated tools for teaching out there that do that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 26 23:00:39 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Dec 2016 23:00:39 -0000 Subject: [GHC] #12990: Partially applied constructors with unpacked fields simplified badly In-Reply-To: <045.525d0610bc9f5daed2ba04304bf44d04@haskell.org> References: <045.525d0610bc9f5daed2ba04304bf44d04@haskell.org> Message-ID: <060.e89378d7871e43350112940fec268d78@haskell.org> #12990: Partially applied constructors with unpacked fields simplified badly -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Inlining Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D2891 Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: @@ -13,1 +13,1 @@ - {{{ + {{{#!hs New description: When a constructor is partially applied to at least one unpacked field, the simplifier produces pretty lousy results. {{{#!hs data Foo a = Foo !Int a silly :: ((a -> Foo a) -> r) -> r silly f = f (Foo 3) }}} compiles to {{{#!hs -- RHS size: {terms: 9, types: 7, coercions: 0} $WFoo :: forall a. Int -> a -> Foo a $WFoo = \ (@ a_aqI) (dt_ayl :: Int) (dt_aym :: a_aqI[sk:1]) -> case dt_ayl of { I# dt_ayn -> Foo dt_ayn dt_aym } -- RHS size: {terms: 2, types: 0, coercions: 0} silly2 :: Int silly2 = I# 3# -- RHS size: {terms: 3, types: 3, coercions: 0} silly1 :: forall a. a -> Foo a silly1 = \ (@ a_ayG) -> $WFoo silly2 -- RHS size: {terms: 5, types: 9, coercions: 0} silly :: forall a r. ((a -> Foo a) -> r) -> r silly = \ (@ a_ayG) (@ r_ayH) (f_axY :: (a -> Foo a) -> r) -> f_axY silly1 }}} That is, GHC represents `Foo 3` as a closure containing a ''boxed'' `Int`. Manually eta-expanding would fix it. {{{#!hs silly :: ((a -> Foo a) -> r) -> r silly f = f (\x -> Foo 3 x) }}} compiles to {{{#!hs -- RHS size: {terms: 5, types: 4, coercions: 0} silly1 :: forall a. a -> Foo a silly1 = \ (@ a_ayO) (x_ay9 :: a) -> Foo 3# x_ay9 -- RHS size: {terms: 5, types: 9, coercions: 0} silly :: forall a r. ((a -> Foo a) -> r) -> r silly = \ (@ a_ayO) (@ r_ayP) (f_ay8 :: (a -> Foo a) -> r) -> f_ay8 silly1 }}} in which the `Int` is unpacked into the closure. This transformation is valid whenever the value to be stored unpacked is known not to be bottom, and is certainly a good idea if it's known to have been forced. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Dec 26 23:39:46 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Dec 2016 23:39:46 -0000 Subject: [GHC] #13035: GHC enters a loop when partial type signatures and advanced type level code mix In-Reply-To: <043.73bcb566c7aa5daa0f1f227af5f74322@haskell.org> References: <043.73bcb566c7aa5daa0f1f227af5f74322@haskell.org> Message-ID: <058.09e5eadeba9e902837f916cba1a9af47@haskell.org> #13035: GHC enters a loop when partial type signatures and advanced type level code mix -------------------------------------+------------------------------------- Reporter: xcmw | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Here is a version which doesn't have any dependencies on `singletons` or `vinyl`: {{{#!hs {-# LANGUAGE PolyKinds, DataKinds, TypeOperators, TypeFamilies, GADTs, PartialTypeSignatures #-} newtype MyAttr a b = MyAttr { _unMyAttr :: MyFun (a b) } type MyRec a b = Rec (MyAttr a) b type family MyFun (a :: k1) :: k2 data GY (a :: k1) (b :: k2) (c :: k1 -> k3) (d :: k1) data GNone (a :: k1) type family GYTF a where GYTF (GY a b _ a) = b GYTF (GY _ _ c d) = MyFun (c d) type instance MyFun (GY a b c d) = GYTF (GY a b c d) type family GNoneTF (a :: k1) :: k2 where type instance MyFun (GNone a) = GNoneTF a type (a :: k1) =: (b :: k2) = a `GY` b type (a :: j1 -> j2) $ (b :: j1) = a b infixr 0 $ infixr 9 =: data FConst (a :: *) (b :: Fields) data FApply (a :: * -> * -> *) b c (d :: Fields) data FMap (a :: * -> *) b (d :: Fields) type instance MyFun (FConst a b) = a type instance MyFun (FApply b c d a) = b (MyFun (c a)) (MyFun (d a)) type instance MyFun (FMap b c a) = b (MyFun (c a)) data Fields = Name | Author | Image | Description | Ingredients | Instructions | CookTime | PrepTime | TotalTime | Yield | Nutrition | Tags | Url | Section | Items | Subsections | Calories | Carbohydrates | Cholesterol | Fat | Fiber | Protien | SaturatedFat | Sodium | Sugar | TransFat | UnsaturatedFat | ServingSize data Rec :: (u -> *) -> [u] -> * where RNil :: Rec f '[] (:&) :: !(f r) -> !(Rec f rs) -> Rec f (r ': rs) data family Sing (a :: k) data instance Sing (z_a6bn :: Fields) = z_a6bn ~ Name => SName | z_a6bn ~ Author => SAuthor | z_a6bn ~ Image => SImage | z_a6bn ~ Description => SDescription | z_a6bn ~ Ingredients => SIngredients | z_a6bn ~ Instructions => SInstructions | z_a6bn ~ CookTime => SCookTime | z_a6bn ~ PrepTime => SPrepTime | z_a6bn ~ TotalTime => STotalTime | z_a6bn ~ Yield => SYield | z_a6bn ~ Nutrition => SNutrition | z_a6bn ~ Tags => STags | z_a6bn ~ Url => SUrl | z_a6bn ~ Section => SSection | z_a6bn ~ Items => SItems | z_a6bn ~ Subsections => SSubsections | z_a6bn ~ Calories => SCalories | z_a6bn ~ Carbohydrates => SCarbohydrates | z_a6bn ~ Cholesterol => SCholesterol | z_a6bn ~ Fat => SFat | z_a6bn ~ Fiber => SFiber | z_a6bn ~ Protien => SProtien | z_a6bn ~ SaturatedFat => SSaturatedFat | z_a6bn ~ Sodium => SSodium | z_a6bn ~ Sugar => SSugar | z_a6bn ~ TransFat => STransFat | z_a6bn ~ UnsaturatedFat => SUnsaturatedFat | z_a6bn ~ ServingSize => SServingSize (=::) :: sing f -> MyFun (a f) -> MyAttr a f _ =:: x = MyAttr x type NutritionT = Calories =: Maybe Int $ Carbohydrates =: Maybe Int $ Cholesterol =: Maybe Int $ Fat =: Maybe Int $ Fiber =: Maybe Int $ Protien =: Maybe Int $ SaturatedFat =: Maybe Int $ Sodium =: Maybe Int $ Sugar =: Maybe Int $ TransFat =: Maybe Int $ UnsaturatedFat =: Maybe Int $ ServingSize =: String $ GNone type NutritionRec = MyRec NutritionT ['Calories, 'Carbohydrates, 'Cholesterol, 'Fat, 'Fiber, 'Protien, 'SaturatedFat, 'Sodium, 'Sugar, 'TransFat, 'UnsaturatedFat, 'ServingSize] type RecipeT = Name =: String $ Author =: String $ Image =: String $ Description =: String $ CookTime =: Maybe Int $ PrepTime =: Maybe Int $ TotalTime =: Maybe Int $ Yield =: String $ Nutrition =: NutritionRec $ Tags =: [String] $ Url =: String $ GNone type RecipeFormatter = FApply (->) (FConst [String]) (FMap IO RecipeT) g :: MyRec RecipeFormatter _ --'[ 'Author ] Uncomment to prevent loop g = SAuthor =:: (\a -> return "Hi") :& RNil main = putStrLn "Hi" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 27 04:58:08 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Dec 2016 04:58:08 -0000 Subject: [GHC] #13037: Single-Stepping evaluation in GHCi In-Reply-To: <044.2b99dbcf24e1229ef5c6820c7cb7241f@haskell.org> References: <044.2b99dbcf24e1229ef5c6820c7cb7241f@haskell.org> Message-ID: <059.70e245c2ea106859b4298ae9adb2e032@haskell.org> #13037: Single-Stepping evaluation in GHCi -------------------------------------+------------------------------------- Reporter: vanto | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): You can get somewhat close using libraries like [https://hackage.haskell.org/package/simple-reflect-0.3.2/docs/Debug- SimpleReflect.html simple-reflect] (or [https://hackage.haskell.org/package/ap-reflect ap-reflect]) {{{ > import Debug.SimpleReflect > g op n [] = n ; g op n (h:t) = h `op` g op n t > g (*) 2 [1..3] :: Expr 1 * (2 * (3 * 2)) }}} you can even `reduce` {{{ > reduce (g (*) 2 [1..3]) 1 * (2 * 6) > reduce (reduce (g (*) 2 [1..3])) 1 * 12 > reduce (reduce (reduce (g (*) 2 [1..3]))) 12 }}} {{{ > traverse_ print $ reduction (g (*) 2 [1..3]) 1 * (2 * (3 * 2)) 1 * (2 * 6) 1 * 12 12 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 27 14:14:13 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Dec 2016 14:14:13 -0000 Subject: [GHC] #13038: implementation of Modus ponens and Modus tollens Message-ID: <044.ee87b0a017d5b08f838549b48bb4f0cf@haskell.org> #13038: implementation of Modus ponens and Modus tollens -------------------------------------+------------------------------------- Reporter: vanto | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: | Version: 8.0.1 libraries/base | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Can we have in Prelude - Booleans, Modus ponens and Modus tollens implemented? Or in another module? reminder:[[BR]] P is a proposition and v(p) is the logic value of P.[[BR]] P is true, v(P) = 1[[BR]] P is false, v(P) = 0[[BR]] P -> Q is always true in propositional logic. Modus ponens:[[BR]] v(P) = 1[[BR]] v(P -> Q) = 1[[BR]] v(Q) = 1[[BR]] v(P) and v(P -> q) are premiss, v(q) is the conclusion.[[BR]] or in a more general form[[BR]] P : X is A[[BR]] P -> Q : A -> B[[BR]] Q : X is B[[BR]] Modus tollens:[[BR]] v(Q) = 0[[BR]] v(P -> Q) = 1[[BR]] v(P) = 0[[BR]] v(Q) and v(P -> Q) are premiss, v(P) is the conclusion.[[BR]] or in a more general form[[BR]] not Q : X is not B[[BR]] P -> Q : A -> B[[BR]] not P : X is not A[[BR]][[BR]] As well as using the numbers 0 and 1 for the respective values false and true, we'll use the letters F for False and T for True.[[BR]] We are always:[[BR]] v(F) = 0[[BR]] v(T) = 1[[BR]] v(P -> Q) = 1[[BR]] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 27 16:06:25 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Dec 2016 16:06:25 -0000 Subject: [GHC] #13018: TH-spliced pattern synonym declaration fails to typecheck In-Reply-To: <050.321896de80824d0ab018c753e6e2c2e9@haskell.org> References: <050.321896de80824d0ab018c753e6e2c2e9@haskell.org> Message-ID: <065.59b084922f5e6dd4ca8949b773913c09@haskell.org> #13018: TH-spliced pattern synonym declaration fails to typecheck -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I'm not sure if the advice in comment:9 is feasible, sadly. Not only would you need to generalize `extractHsTyRdrTyVars` to work over `RdrName`s and `Name`s (which I was able to do), you also have to overcome the issue that `repHsPatSynSigType` lives in `DsM` (i.e., `TcRnIf DsGblEnv DsLclEnv`) but `extractHsTyRdrTyVars` lives in `RnM` (i.e., `TcRnIf TcGblEnv TcLclEnv`). I don't see a way to generalize the return type of `extractHsTyRdrTyVars` in a way that wouldn't have an enormous ripple effect across tons of GHC API functions, so I'm giving up on this for now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 27 16:30:09 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Dec 2016 16:30:09 -0000 Subject: [GHC] #13038: implementation of Modus ponens and Modus tollens In-Reply-To: <044.ee87b0a017d5b08f838549b48bb4f0cf@haskell.org> References: <044.ee87b0a017d5b08f838549b48bb4f0cf@haskell.org> Message-ID: <059.19701a00ddf749e1b83f75082ccb15bd@haskell.org> #13038: implementation of Modus ponens and Modus tollens -------------------------------------+------------------------------------- Reporter: vanto | Owner: Type: feature request | Status: infoneeded Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => infoneeded Comment: I have no idea what you are proposing in terms of Haskell code. What are the functions' names, type signatures, and implementations? Moreover, Trac is not the place to be making proposals for API additions in core libraries like `base`. Please propose these functions at the [https://mail.haskell.org/mailman/listinfo/libraries Haskell libraries mailing list] first to see if there is a consensus that these functions really should be added in the first place. If there is community support, we can revisit this idea. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 27 16:45:44 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Dec 2016 16:45:44 -0000 Subject: [GHC] #13035: GHC enters a loop when partial type signatures and advanced type level code mix In-Reply-To: <043.73bcb566c7aa5daa0f1f227af5f74322@haskell.org> References: <043.73bcb566c7aa5daa0f1f227af5f74322@haskell.org> Message-ID: <058.ebf98d0dbf0db7b4d1f54892f2af904f@haskell.org> #13035: GHC enters a loop when partial type signatures and advanced type level code mix -------------------------------------+------------------------------------- Reporter: xcmw | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): FWIW, I don't think this is causing the typechecker to loop, but rather it causes it to take an extremely long time to complete. I discovered this by trying to minimize the test case by commenting some lines in the definition of `RecipeT`: {{{#!hs type RecipeT = Name =: String $ Author =: String {- $ Image =: String $ Description =: String $ CookTime =: Maybe Int $ PrepTime =: Maybe Int $ TotalTime =: Maybe Int $ Yield =: String -} $ Nutrition =: NutritionRec {- $ Tags =: [String] $ Url =: String -} $ GNone }}} When I compiled this, it lagged noticeably, but it completed in finite time: {{{ $ time /opt/ghc/8.0.1/bin/ghc -fforce-recomp Wat.hs[1 of 1] Compiling Wat ( Wat.hs, Wat.o ) Wat.hs:140:28: warning: [-Wpartial-type-signatures] • Found type wildcard ‘_’ standing for ‘'['Author]’ • In the type signature: g :: MyRec RecipeFormatter _ • Relevant bindings include g :: MyRec RecipeFormatter '['Author] (bound at Wat.hs:141:1) real 0m1.973s user 0m1.940s sys 0m0.028s }}} I then uncommented one more line (`Image := String`): {{{#!hs type RecipeT = Name =: String $ Author =: String $ Image =: String {- $ Description =: String $ CookTime =: Maybe Int $ PrepTime =: Maybe Int $ TotalTime =: Maybe Int $ Yield =: String -} $ Nutrition =: NutritionRec {- $ Tags =: [String] $ Url =: String -} $ GNone }}} And that contributed to the compilation time significantly (almost doubling it): {{{ $ time /opt/ghc/8.0.1/bin/ghc -fforce-recomp Wat.hs[1 of 1] Compiling Wat ( Wat.hs, Wat.o ) Wat.hs:140:28: warning: [-Wpartial-type-signatures] • Found type wildcard ‘_’ standing for ‘'['Author]’ • In the type signature: g :: MyRec RecipeFormatter _ • Relevant bindings include g :: MyRec RecipeFormatter '['Author] (bound at Wat.hs:141:1) real 0m3.635s user 0m3.564s sys 0m0.068s }}} Similarly, uncommented out more and more lines seems to approximately double the compilation time for each line. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 27 17:27:17 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Dec 2016 17:27:17 -0000 Subject: [GHC] #13035: GHC enters a loop when partial type signatures and advanced type level code mix In-Reply-To: <043.73bcb566c7aa5daa0f1f227af5f74322@haskell.org> References: <043.73bcb566c7aa5daa0f1f227af5f74322@haskell.org> Message-ID: <058.5f9f98185d69f087ffefe4349d93e6e8@haskell.org> #13035: GHC enters a loop when partial type signatures and advanced type level code mix -------------------------------------+------------------------------------- Reporter: xcmw | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): According to a profiled build of GHC HEAD, `TcRnDriver.tc_rn_src_decls` is taking up almost 100% of the time and alloc when compiling the program above. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 27 17:28:23 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Dec 2016 17:28:23 -0000 Subject: [GHC] #11501: Building nofib/fibon returns permission denied In-Reply-To: <042.7732253ef90810c7acc41907aecb19ff@haskell.org> References: <042.7732253ef90810c7acc41907aecb19ff@haskell.org> Message-ID: <057.d2f06705a104c03dc47d8b3536f366e3@haskell.org> #11501: Building nofib/fibon returns permission denied -------------------------------------+------------------------------------- Reporter: rem | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: NoFib benchmark | Version: 7.10.3 suite | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Replying to [comment:23 gracjan]: > @bgamari: Your database contains many duplicate results: > > ... > > I'm not sure why is this. Have you been testing same (commit,env,test) configuration multiple times? Oh dear; thanks for pointing this out. This appears to be a bug in the import script. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Dec 27 17:44:55 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Dec 2016 17:44:55 -0000 Subject: [GHC] #229: Integer overflow in array allocation In-Reply-To: <045.791e3ea8f042e6c7d57ae4cd25dec693@haskell.org> References: <045.791e3ea8f042e6c7d57ae4cd25dec693@haskell.org> Message-ID: <060.3bea6ad0515a520f066658e18ee3c5af@haskell.org> #229: Integer overflow in array allocation -------------------------------------+------------------------------------- Reporter: josefs | Owner: bgamari Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Core Libraries | Version: 7.9 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"f3b99c75fef7fc946a27de63edb5e6d6ad5a22be/ghc" f3b99c75/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f3b99c75fef7fc946a27de63edb5e6d6ad5a22be" Bump array submodule Fixes overflow check from fix to #229. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 28 00:04:22 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Dec 2016 00:04:22 -0000 Subject: [GHC] #7930: Nested STM Invariants are lost In-Reply-To: <048.13ce218649616d55ea8d6d48035a1772@haskell.org> References: <048.13ce218649616d55ea8d6d48035a1772@haskell.org> Message-ID: <063.b2d852c0bf8a860577903a626281f08f@haskell.org> #7930: Nested STM Invariants are lost -------------------------------------+------------------------------------- Reporter: fryguybob | Owner: fryguybob Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: STM Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by int-e): Replying to [comment:1 fryguybob]: I believe the analysis is excellent. I only have some minor additional comments: > 2. The delay does not make sense because there are other effects that can > intervene before the transaction is committed! Indeed, it could be that > it will not hit the retry later on. Or an exception could happen due to > the very invariant property being checked (See example below). In fact, the effect does not even have to be external to the transaction, as demonstrated by the following single threaded example, which completes successfully instead of getting stuck retrying the transaction: {{{ import Control.Concurrent.STM main = do atomically $ do t <- newTVar True alwaysSucceeds $ do b <- readTVar t if b then retry else return () writeTVar t False putStrLn "Success" }}} Interestingly, there is no CHECK rule for the `retry` case in the operational semantics (Figure 4 of [1]), which could well explain this oversight. > This definition attempts to reuse the `retry` mechanism to handle the rollback of the initial run of the invariant. The rollback is (also?) necessary to ensure [D6]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 28 03:36:29 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Dec 2016 03:36:29 -0000 Subject: [GHC] #13039: Add options to select GHCi prompt type errors Message-ID: <045.db3bd3b6d2d0399e73fac5ef5ff73689@haskell.org> #13039: Add options to select GHCi prompt type errors -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Priority: low | Milestone: 8.4.1 Component: GHCi | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- [This SO post](http://stackoverflow.com/questions/41354231/how-can-i-set- up-haskells-ghci-to-interactively-evaluate-functions-to-their-sig) implicitly suggests some extra options for reporting type errors for expressions typed into GHCi. When GHCi reports a type error for an expression `e` typed at the prompt, it has effectively failed to check `void e :: IO ()` and `print e :: IO ()`. It always reports the error for the latter. There are three things a user may want, and I think options should control which ones are shown: 1. Why didn't `void e :: IO ()` check? 2. Why didn't `print e :: IO ()` check? 3. If any type could be inferred for `e`, what was it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 28 04:23:00 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Dec 2016 04:23:00 -0000 Subject: [GHC] #13013: Add readMaybe to Prelude (possibly readEither too), make Haddocks for read more cautionary In-Reply-To: <046.3d6f3ae3075d3638bfdec9ce7d4dde8f@haskell.org> References: <046.3d6f3ae3075d3638bfdec9ce7d4dde8f@haskell.org> Message-ID: <061.5d0b91eee85b8cf298c891e3e682eeb4@haskell.org> #13013: Add readMaybe to Prelude (possibly readEither too), make Haddocks for read more cautionary -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sjakobi): Here is the my email to the libraries mailing list: https://mail.haskell.org/pipermail/libraries/2016-December/027496.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 28 04:28:30 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Dec 2016 04:28:30 -0000 Subject: [GHC] #13039: Add options to select GHCi prompt type errors In-Reply-To: <045.db3bd3b6d2d0399e73fac5ef5ff73689@haskell.org> References: <045.db3bd3b6d2d0399e73fac5ef5ff73689@haskell.org> Message-ID: <060.6111fdecb297662243d0e79e80793b36@haskell.org> #13039: Add options to select GHCi prompt type errors -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: low | Milestone: 8.4.1 Component: GHCi | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * cc: Iceland_jack (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 28 04:52:07 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Dec 2016 04:52:07 -0000 Subject: [GHC] #13039: Add options to select GHCi prompt type errors In-Reply-To: <045.db3bd3b6d2d0399e73fac5ef5ff73689@haskell.org> References: <045.db3bd3b6d2d0399e73fac5ef5ff73689@haskell.org> Message-ID: <060.f13080ff66b99b3959778c6fd337052b@haskell.org> #13039: Add options to select GHCi prompt type errors -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: low | Milestone: 8.4.1 Component: GHCi | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by dfeuer: @@ -1,2 +1,2 @@ - [This SO post](http://stackoverflow.com/questions/41354231/how-can-i-set- - up-haskells-ghci-to-interactively-evaluate-functions-to-their-sig) + [http://stackoverflow.com/questions/41354231/how-can-i-set-up-haskells- + ghci-to-interactively-evaluate-functions-to-their-sig This SO post] New description: [http://stackoverflow.com/questions/41354231/how-can-i-set-up-haskells- ghci-to-interactively-evaluate-functions-to-their-sig This SO post] implicitly suggests some extra options for reporting type errors for expressions typed into GHCi. When GHCi reports a type error for an expression `e` typed at the prompt, it has effectively failed to check `void e :: IO ()` and `print e :: IO ()`. It always reports the error for the latter. There are three things a user may want, and I think options should control which ones are shown: 1. Why didn't `void e :: IO ()` check? 2. Why didn't `print e :: IO ()` check? 3. If any type could be inferred for `e`, what was it? -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 28 06:40:13 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Dec 2016 06:40:13 -0000 Subject: [GHC] #13026: RFC functions for sums and products In-Reply-To: <051.dcc6584e5b5e34920ae3e9c70dbd6181@haskell.org> References: <051.dcc6584e5b5e34920ae3e9c70dbd6181@haskell.org> Message-ID: <066.17a017960a3f593a562a328495eb0db8@haskell.org> #13026: RFC functions for sums and products -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: @@ -18,0 +18,4 @@ + + **Edit**: [http://hackage.haskell.org/package/comonad- + transformers-3.1/docs/Data-Functor-Coproduct.html coproduct] is one name + for `||||` New description: I'll ask on the libraries mailing list depending on feedback. Adding these to `Data.Functor.Sum`, `Data.Functor.Product` a la `Control.Arrow` {{{#!hs (||||) :: (f a -> b) -> (g a -> b) -> ((Sum f g) a -> b) f |||| g = \case InL fa -> f fa InR ga -> g ga (&&&&) :: (a -> f b) -> (a -> g b) -> (a -> (Product f g) b) (f &&&& g) a = f a `Pair` g a }}} `||||` is used in "Monad transformers and modular algebraic effects: What binds them together" in section 2.4, the names are up for discussion **Edit**: [http://hackage.haskell.org/package/comonad- transformers-3.1/docs/Data-Functor-Coproduct.html coproduct] is one name for `||||` -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 28 08:02:44 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Dec 2016 08:02:44 -0000 Subject: [GHC] #13040: realToFrac into Complex Double has no specialization Message-ID: <043.c94211249f15fe3699809040311c3bb2@haskell.org> #13040: realToFrac into Complex Double has no specialization -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: | Version: 8.0.1 libraries/base | 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: -------------------------------------+------------------------------------- Example: {{{#!hs module Foo where import Data.Complex f :: Double -> Complex Double f x = realToFrac x }}} `ghc -O -ddump-simpl` gives: {{{ f = \ (w_s17v :: Double) -> case w_s17v of _ [Occ=Dead] { GHC.Types.D# ww1_s17y -> case GHC.Float.$w$ctoRational ww1_s17y of _ [Occ=Dead] { (# ww3_a152, ww4_a153 #) -> case GHC.Float.rationalToDouble ww3_a152 ww4_a153 of dt_a15c { GHC.Types.D# ipv_a15g -> Data.Complex.:+ @ Double dt_a15c Data.Complex.$fFloatingComplex1 } } } }}} This means the conversion goes through Rational. However, in this case, the conversion could be done much more efficiently with `(:+0)`. It would be nice if this happened automatically. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 28 08:07:04 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Dec 2016 08:07:04 -0000 Subject: [GHC] #13040: realToFrac into Complex Double has no specialization In-Reply-To: <043.c94211249f15fe3699809040311c3bb2@haskell.org> References: <043.c94211249f15fe3699809040311c3bb2@haskell.org> Message-ID: <058.e7ddf07a02093e44ce676b7cd46fcdce@haskell.org> #13040: realToFrac into Complex Double has no specialization -------------------------------------+------------------------------------- Reporter: akio | Owner: akio Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 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): Phab:D2901 Wiki Page: | -------------------------------------+------------------------------------- Changes (by akio): * owner: => akio * differential: => Phab:D2901 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 28 08:09:51 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Dec 2016 08:09:51 -0000 Subject: [GHC] #13026: RFC functions for sums and products In-Reply-To: <051.dcc6584e5b5e34920ae3e9c70dbd6181@haskell.org> References: <051.dcc6584e5b5e34920ae3e9c70dbd6181@haskell.org> Message-ID: <066.a2bab123f3010f053b7edaa91450d4ac@haskell.org> #13026: RFC functions for sums and products -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Here is an interesting one, witnessing the isomorphism between `Sum Identity` and [https://hackage.haskell.org/package/transformers-0.3.0.0/docs/Control- Applicative-Lift.html Control.Applicative.Lift.Lift] {{{#!hs toLift :: Sum Identity g ~> Lift g toLift = \case InL (Identity a) -> Pure a InR ga -> Other ga }}} if it ever gets added to ''base''. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 28 10:34:20 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Dec 2016 10:34:20 -0000 Subject: [GHC] #11317: Test prog003 fails with segfault on Windows (GHCi) In-Reply-To: <046.e04825e713c12f85562a518dea8fe3f3@haskell.org> References: <046.e04825e713c12f85562a518dea8fe3f3@haskell.org> Message-ID: <061.bfe0b6eee51e4c741b22167292bd5be0@haskell.org> #11317: Test prog003 fails with segfault on Windows (GHCi) ---------------------------------+---------------------------------------- Reporter: rdragon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.11 Resolution: | Keywords: GC Operating System: Windows | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: prog003 Blocked By: | Blocking: Related Tickets: #11234 #3408 | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by Tamar Christina ): In [changeset:"a3704409acc3bd237d3e872f640686918fb51f5f/ghc" a3704409/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a3704409acc3bd237d3e872f640686918fb51f5f" Fix various issues with testsuite code on Windows Summary: Previously we would make direct calls to `diff` using `os.system`. On Windows `os.system` is implemented using the standard idiom `CreateProcess .. WaitForSingleObject ..`. This again runs afoul with the `_exec` behaviour on Windows. So we ran into some trouble where sometimes `diff` would return before it's done. On tests which run multiple ways, such as `8086` what happens is that we think the diff is done and continue. The next way tries to set things up again by removing any previous directory. This would then fail with and error saying the directory can't be removed. Which is true, because the previous diff code/child is still running. We shouldn't make any external calls to anything using `os.system`. Instead just use `runCmd` which uses `timeout`. This also ensures that if we hit the cygwin bug where diff or any other utility hangs, we kill it and continue and not hang the entire test and leave hanging processes. Further more we also: Ignore error lines from `removeFile` from tools in the testsuite. This is a rather large hammer to work around the fact that `hsc2hs` often tries to remove it's own file too early. When this is patched the workaround can be removed. See Trac #9775 We mark `prog003` as skip. Since this test randomly fails and passes. For stability it's disabled but it is a genuine bug which we should find. It's something with interface files being overwritten. See Trac #11317 when `rmtree` hits a readonly file, the `onerror` handler is raised afterwards but not during the tree walk. It doesn't allow you to recover and continue as we thought. Instead you have to explicitly start again. This is why sometimes even though we call `cleanup` before `os.mkdirs`, it would sometimes fail with an error that the folder already exists. So we now do a second walk. A new verbosity level (4) will strip the silent flags from `MAKE` invocations so you can actually see what's going on. Test Plan: ./validate on build bots. Reviewers: bgamari, austin Reviewed By: bgamari Subscribers: mpickering, thomie, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D2894 GHC Trac Issues: #12661, #11317, #9775 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 28 10:34:20 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Dec 2016 10:34:20 -0000 Subject: [GHC] #12661: Testsuite driver fails on Windows In-Reply-To: <046.7b51ac842485db4ec1506a907d0c7e13@haskell.org> References: <046.7b51ac842485db4ec1506a907d0c7e13@haskell.org> Message-ID: <061.f8dfff9e136ce9446f44b4868cf04d1e@haskell.org> #12661: Testsuite driver fails on Windows ---------------------------------+-------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Test Suite | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by Tamar Christina ): In [changeset:"a3704409acc3bd237d3e872f640686918fb51f5f/ghc" a3704409/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a3704409acc3bd237d3e872f640686918fb51f5f" Fix various issues with testsuite code on Windows Summary: Previously we would make direct calls to `diff` using `os.system`. On Windows `os.system` is implemented using the standard idiom `CreateProcess .. WaitForSingleObject ..`. This again runs afoul with the `_exec` behaviour on Windows. So we ran into some trouble where sometimes `diff` would return before it's done. On tests which run multiple ways, such as `8086` what happens is that we think the diff is done and continue. The next way tries to set things up again by removing any previous directory. This would then fail with and error saying the directory can't be removed. Which is true, because the previous diff code/child is still running. We shouldn't make any external calls to anything using `os.system`. Instead just use `runCmd` which uses `timeout`. This also ensures that if we hit the cygwin bug where diff or any other utility hangs, we kill it and continue and not hang the entire test and leave hanging processes. Further more we also: Ignore error lines from `removeFile` from tools in the testsuite. This is a rather large hammer to work around the fact that `hsc2hs` often tries to remove it's own file too early. When this is patched the workaround can be removed. See Trac #9775 We mark `prog003` as skip. Since this test randomly fails and passes. For stability it's disabled but it is a genuine bug which we should find. It's something with interface files being overwritten. See Trac #11317 when `rmtree` hits a readonly file, the `onerror` handler is raised afterwards but not during the tree walk. It doesn't allow you to recover and continue as we thought. Instead you have to explicitly start again. This is why sometimes even though we call `cleanup` before `os.mkdirs`, it would sometimes fail with an error that the folder already exists. So we now do a second walk. A new verbosity level (4) will strip the silent flags from `MAKE` invocations so you can actually see what's going on. Test Plan: ./validate on build bots. Reviewers: bgamari, austin Reviewed By: bgamari Subscribers: mpickering, thomie, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D2894 GHC Trac Issues: #12661, #11317, #9775 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 28 10:34:20 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Dec 2016 10:34:20 -0000 Subject: [GHC] #9775: "Failed to remove" errors during Windows build from hsc2hs In-Reply-To: <045.a3bc7893c1159a7aa08bb934a48297de@haskell.org> References: <045.a3bc7893c1159a7aa08bb934a48297de@haskell.org> Message-ID: <060.9464285ee482fa4db95f71842119c5c5@haskell.org> #9775: "Failed to remove" errors during Windows build from hsc2hs ---------------------------------+---------------------------------------- Reporter: gintas | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: hsc2hs | Version: 7.8.3 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by Tamar Christina ): In [changeset:"a3704409acc3bd237d3e872f640686918fb51f5f/ghc" a3704409/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a3704409acc3bd237d3e872f640686918fb51f5f" Fix various issues with testsuite code on Windows Summary: Previously we would make direct calls to `diff` using `os.system`. On Windows `os.system` is implemented using the standard idiom `CreateProcess .. WaitForSingleObject ..`. This again runs afoul with the `_exec` behaviour on Windows. So we ran into some trouble where sometimes `diff` would return before it's done. On tests which run multiple ways, such as `8086` what happens is that we think the diff is done and continue. The next way tries to set things up again by removing any previous directory. This would then fail with and error saying the directory can't be removed. Which is true, because the previous diff code/child is still running. We shouldn't make any external calls to anything using `os.system`. Instead just use `runCmd` which uses `timeout`. This also ensures that if we hit the cygwin bug where diff or any other utility hangs, we kill it and continue and not hang the entire test and leave hanging processes. Further more we also: Ignore error lines from `removeFile` from tools in the testsuite. This is a rather large hammer to work around the fact that `hsc2hs` often tries to remove it's own file too early. When this is patched the workaround can be removed. See Trac #9775 We mark `prog003` as skip. Since this test randomly fails and passes. For stability it's disabled but it is a genuine bug which we should find. It's something with interface files being overwritten. See Trac #11317 when `rmtree` hits a readonly file, the `onerror` handler is raised afterwards but not during the tree walk. It doesn't allow you to recover and continue as we thought. Instead you have to explicitly start again. This is why sometimes even though we call `cleanup` before `os.mkdirs`, it would sometimes fail with an error that the folder already exists. So we now do a second walk. A new verbosity level (4) will strip the silent flags from `MAKE` invocations so you can actually see what's going on. Test Plan: ./validate on build bots. Reviewers: bgamari, austin Reviewed By: bgamari Subscribers: mpickering, thomie, #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D2894 GHC Trac Issues: #12661, #11317, #9775 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 28 16:05:33 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Dec 2016 16:05:33 -0000 Subject: [GHC] #13018: TH-spliced pattern synonym declaration fails to typecheck In-Reply-To: <050.321896de80824d0ab018c753e6e2c2e9@haskell.org> References: <050.321896de80824d0ab018c753e6e2c2e9@haskell.org> Message-ID: <065.fb1ad70041858225b0593c78d3191d57@haskell.org> #13018: TH-spliced pattern synonym declaration fails to typecheck -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I made these functions monadic not too long ago. Looking back through, it seems the only `RnM` action taken is `addErrAt` from `mixedVarsErr` (and the related `xoptM` call). It wouldn't be hard to augment the `FreeKiTyVars` structure to include a list of errors generated. Then, the whole lot of these functions could be made pure. This would seem to be an improvement -- especially in your case when you are not interested in error messages. Alternatively, I've recently run into the need to have functions be used in both `TcM` and `DsM`, but the only monadic action, again, was error generation. It might be reasonable to have a `ErrMonad` class with instances for both `TcM` and `DsM`; then these `extractXXX` functions could be generalized over that class. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 28 19:49:18 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Dec 2016 19:49:18 -0000 Subject: [GHC] #12791: Superclass methods could be more aggressively specialised. In-Reply-To: <049.67ba67008b7e7aca654f97100047ee77@haskell.org> References: <049.67ba67008b7e7aca654f97100047ee77@haskell.org> Message-ID: <064.94965377c9c2bada198e5af0f958b850@haskell.org> #12791: Superclass methods could be more aggressively specialised. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: danharaj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #5835 | Differential Rev(s): Phab:D2714 Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Another potential instance of this spotted in the wild: `MonadBaseControl IO m => m ()`, where `MonadBaseControl b m` has indirect superclasses including `Applicative b` and `Monad b`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 28 20:34:57 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Dec 2016 20:34:57 -0000 Subject: [GHC] #13039: Add options to select GHCi prompt type errors In-Reply-To: <045.db3bd3b6d2d0399e73fac5ef5ff73689@haskell.org> References: <045.db3bd3b6d2d0399e73fac5ef5ff73689@haskell.org> Message-ID: <060.363a2ef974f64f23f7324854365df9f7@haskell.org> #13039: Add options to select GHCi prompt type errors -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: low | Milestone: 8.4.1 Component: GHCi | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): I don't like the idea of adding options here since they will only benefit those who know about them; and I don't think those will be the same people as the people who have trouble with the existing behavior. (And if you really want to know why `void e :: IO ()` didn't type check then you can enter `void e :: IO ()` into ghci; and that's much more obvious than turning on an option.) I do think that it'd be reasonable to improve the (default) behavior when `e` type checks but `print e` does not (presumably due to a missing `Show` instance). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Dec 28 20:35:33 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Dec 2016 20:35:33 -0000 Subject: [GHC] #13036: educational purpose In-Reply-To: <044.8c15894968b6cebbc497e8dc88d5e8f1@haskell.org> References: <044.8c15894968b6cebbc497e8dc88d5e8f1@haskell.org> Message-ID: <059.4b7798cd41e17efb500154234e32bbfd@haskell.org> #13036: educational purpose -------------------------------------+------------------------------------- Reporter: vanto | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): How is this different from `:set +s`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 29 01:21:16 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Dec 2016 01:21:16 -0000 Subject: [GHC] #11342: Character kind In-Reply-To: <048.855ee5d87e4065ad6e74a034645189d9@haskell.org> References: <048.855ee5d87e4065ad6e74a034645189d9@haskell.org> Message-ID: <063.f8df13ad273f41eb366fb923e4642c8e@haskell.org> #11342: Character kind -------------------------------------+------------------------------------- Reporter: alexvieth | Owner: alexvieth Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: DataKinds Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10776, #12162 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by int-index): * cc: int-index (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 29 02:43:14 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Dec 2016 02:43:14 -0000 Subject: [GHC] #11080: Open data kinds In-Reply-To: <047.64e06093644ddd3cb76b94e28bef420a@haskell.org> References: <047.64e06093644ddd3cb76b94e28bef420a@haskell.org> Message-ID: <062.2f76c70c03f59dc0177d1c9974b5987d@haskell.org> #11080: Open data kinds -------------------------------------+------------------------------------- Reporter: dmcclean | Owner: jstolarek Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #6024 | Differential Rev(s): Phab:D1778 Wiki Page: | GhcKinds/KindsWithoutData | -------------------------------------+------------------------------------- Changes (by int-index): * cc: int-index (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 29 05:03:55 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Dec 2016 05:03:55 -0000 Subject: [GHC] #12984: Missed constant folding oportunities (associativity) In-Reply-To: <045.0a42c32dd482b39428ca2268278e9f14@haskell.org> References: <045.0a42c32dd482b39428ca2268278e9f14@haskell.org> Message-ID: <060.c584b37703711d830d0a3dd6ac94a2fe@haskell.org> #12984: Missed constant folding oportunities (associativity) -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2858 Wiki Page: | -------------------------------------+------------------------------------- Changes (by akio): * cc: akio (added) Comment: #9136 is about the same problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 29 07:53:56 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Dec 2016 07:53:56 -0000 Subject: [GHC] #12984: Missed constant folding oportunities (associativity) In-Reply-To: <045.0a42c32dd482b39428ca2268278e9f14@haskell.org> References: <045.0a42c32dd482b39428ca2268278e9f14@haskell.org> Message-ID: <060.63b40589f7e701a7a9ba4758a6953d7b@haskell.org> #12984: Missed constant folding oportunities (associativity) -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9136 | Differential Rev(s): Phab:D2858 Wiki Page: | -------------------------------------+------------------------------------- Changes (by hsyl20): * status: patch => closed * resolution: => duplicate * related: => #9136 Comment: @akio Indeed. Let's continue the discussion on the original ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 29 07:59:33 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Dec 2016 07:59:33 -0000 Subject: [GHC] #9136: Constant folding in Core could be better In-Reply-To: <046.597f40143bfc9d7f6c9f647fe93147a2@haskell.org> References: <046.597f40143bfc9d7f6c9f647fe93147a2@haskell.org> Message-ID: <061.752e99125f44fa55dd04f25eb34d06d6@haskell.org> #9136: Constant folding in Core could be better -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 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): Phab:D2858 Wiki Page: | -------------------------------------+------------------------------------- Changes (by hsyl20): * differential: => Phab:D2858 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 29 09:05:24 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Dec 2016 09:05:24 -0000 Subject: [GHC] #13034: clean memory in GHCi In-Reply-To: <044.49433b006c9e0b96f956935cd2b35747@haskell.org> References: <044.49433b006c9e0b96f956935cd2b35747@haskell.org> Message-ID: <059.00a18c7018ab80f2d1fe9ad6754d1865@haskell.org> #13034: clean memory in GHCi -------------------------------------+------------------------------------- Reporter: vanto | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by codygman): I've been loading large datasets into ghci lately for data analysis and frequently have to restart ghci. This feature would be very convenient. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 29 09:43:34 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Dec 2016 09:43:34 -0000 Subject: [GHC] #13034: clean memory in GHCi In-Reply-To: <044.49433b006c9e0b96f956935cd2b35747@haskell.org> References: <044.49433b006c9e0b96f956935cd2b35747@haskell.org> Message-ID: <059.5cb8caaedbc38ff0363fbecc88c0adbc@haskell.org> #13034: clean memory in GHCi -------------------------------------+------------------------------------- Reporter: vanto | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by codygman): Related to #9765. See the useful analysis by nomeata. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 29 09:43:48 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Dec 2016 09:43:48 -0000 Subject: [GHC] #13041: Type classes in Backpack signatures are dodgy Message-ID: <045.0599d648d354370105bdf23e7a8406b6@haskell.org> #13041: Type classes in Backpack signatures are dodgy -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: backpack | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- At the moment, we allow exactly the same type class declarations in hsig files as we do in hs-boot files, and matching requires the type class definitions to match up exactly. But this is quite questionable. First, this means that I can't write this in a signature: {{{ class K a where f :: a -> Bool }}} but then implement K with a type class that provides a default. The matching code will say these are not compatible. That's not so useful. Second, it means that I can WRITE a default implementation in a signature file. That seems like a step too far: there are many things I might like to write in a specification of a type class, but what the default methods are seems like a step too far. So it seems we need to fix two things: 1. Relax matching so that you can add defaults post-facto in the implementation of the type class 2. Make hsig more restrictive w.r.t. what class definitions it will accept. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 29 10:05:26 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Dec 2016 10:05:26 -0000 Subject: [GHC] #12939: ghc-8.0.1.20161117 did not install ghc.1 manpage In-Reply-To: <050.1a6f83d836fa085ef75b0067487924cd@haskell.org> References: <050.1a6f83d836fa085ef75b0067487924cd@haskell.org> Message-ID: <065.9a82d6836f5807202bd20ffa778acf2b@haskell.org> #12939: ghc-8.0.1.20161117 did not install ghc.1 manpage ---------------------------------+---------------------------------------- Reporter: juhpetersen | Owner: bgamari Type: bug | Status: infoneeded Priority: normal | Milestone: 8.0.2 Component: Build System | Version: 8.0.2-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by domenkozar): Most probably fedora build needs to be fixed, we've added sphinx as dependency to generate the manpages in Nixpkgs https://github.com/NixOS/nixpkgs/pull/21434/files -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 29 10:54:54 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Dec 2016 10:54:54 -0000 Subject: [GHC] #13036: educational purpose In-Reply-To: <044.8c15894968b6cebbc497e8dc88d5e8f1@haskell.org> References: <044.8c15894968b6cebbc497e8dc88d5e8f1@haskell.org> Message-ID: <059.9c16a24c908fb6ee49ea7910caacf5ac@haskell.org> #13036: educational purpose -------------------------------------+------------------------------------- Reporter: vanto | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by vanto): This is correct. I did not pay attention enough by reading the assistance in GHCi. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 29 11:17:52 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Dec 2016 11:17:52 -0000 Subject: [GHC] #11501: Building nofib/fibon returns permission denied In-Reply-To: <042.7732253ef90810c7acc41907aecb19ff@haskell.org> References: <042.7732253ef90810c7acc41907aecb19ff@haskell.org> Message-ID: <057.d270409aac82f6fc2c6d279cdd592f53@haskell.org> #11501: Building nofib/fibon returns permission denied -------------------------------------+------------------------------------- Reporter: rem | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: NoFib benchmark | Version: 7.10.3 suite | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by gracjan): * Attachment "grafana-ghc-perf.png" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 29 11:37:50 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Dec 2016 11:37:50 -0000 Subject: [GHC] #11501: Building nofib/fibon returns permission denied In-Reply-To: <042.7732253ef90810c7acc41907aecb19ff@haskell.org> References: <042.7732253ef90810c7acc41907aecb19ff@haskell.org> Message-ID: <057.c0b5478264f8eb59d113a4e9a522daf9@haskell.org> #11501: Building nofib/fibon returns permission denied -------------------------------------+------------------------------------- Reporter: rem | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: NoFib benchmark | Version: 7.10.3 suite | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by gracjan): I had some fun with Grafana. A screenshot of potential interaction attached: [[Image(grafana-ghc-perf.png, 500px)]] What I like about Grafana: - use interface is slick and interactive - graphs are nice to work with - it is rather easy to setup a graph/dashboard after a little practice - it is easy to change time period observed, narrow down or widen - time-based navigation is intuitive - it was easy to annotate points with commit hashes and titles What I did not like about Grafana: - it is hard to observe more than one branch - we have a huge amount of collected metrics, it is hard to know what to observe - Grafana does not connect to PostgreSQL - Grafana can connect to InfluxDB - InfluxDB has strange import format, but some SQL magic can convert psql to theirs (attached) - InfluxDB needs 5GB of memory to import the data, otherwise it dies - docker has default limit of 2GB, silently kills Influx if not extended - docker option `--memory 8GB` is ignored unless changed in some config - ElasticSearch might have been a better option instead of InfluxDB What I see as a fundamental problem: - we have way to many metrics to reasonably expect people to catch issues - most of the metrics are correlated, most of nofib is Haskell98 programs Summary: - Grafana the UI is really good - time-based drill down is great - all the tooling around is really problematic, compared to PostgreSQL at least -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 29 11:38:42 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Dec 2016 11:38:42 -0000 Subject: [GHC] #11501: Building nofib/fibon returns permission denied In-Reply-To: <042.7732253ef90810c7acc41907aecb19ff@haskell.org> References: <042.7732253ef90810c7acc41907aecb19ff@haskell.org> Message-ID: <057.85ae096cde9635a9ab560c33272e7f2a@haskell.org> #11501: Building nofib/fibon returns permission denied -------------------------------------+------------------------------------- Reporter: rem | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: NoFib benchmark | Version: 7.10.3 suite | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by gracjan): * Attachment "get_all_as_line_protocol.sql" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 29 15:26:20 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Dec 2016 15:26:20 -0000 Subject: [GHC] #13036: educational purpose In-Reply-To: <044.8c15894968b6cebbc497e8dc88d5e8f1@haskell.org> References: <044.8c15894968b6cebbc497e8dc88d5e8f1@haskell.org> Message-ID: <059.c013d6cd328fc8ed0ccad71b6acbda44@haskell.org> #13036: educational purpose -------------------------------------+------------------------------------- Reporter: vanto | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Resolution: worksforme | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => closed * resolution: => worksforme -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 29 22:39:36 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Dec 2016 22:39:36 -0000 Subject: [GHC] #13042: Allow type annotations / visible type application in pattern synonyms Message-ID: <051.f33c40ad84d4e359a5f17d37eb1718de@haskell.org> #13042: Allow type annotations / visible type application in pattern synonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple TypeApplications, PatternSynonyms | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs data Lift f a = Pure a | Other (f a) data V0 a }}} To make a pattern synonym for `a -> Lift V0 a` I would like to be able to write either {{{#!hs pattern A a = Pure @V0 a }}} or {{{#!hs pattern B a = (Pure :: _ -> _ V0 _) a }}} to be equivalent to {{{#!hs pattern C :: a -> Lift V0 a pattern C a = Pure a }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 29 23:32:33 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Dec 2016 23:32:33 -0000 Subject: [GHC] #13042: Allow type annotations / visible type application in pattern synonyms In-Reply-To: <051.f33c40ad84d4e359a5f17d37eb1718de@haskell.org> References: <051.f33c40ad84d4e359a5f17d37eb1718de@haskell.org> Message-ID: <066.2e3918ee2f9c7b056bce6c1e2fc757b7@haskell.org> #13042: Allow type annotations / visible type application in pattern synonyms -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: | TypeApplications, PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Is this not a duplicate of your other ticket about type application in patterns? How is it different? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Dec 29 23:42:47 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Dec 2016 23:42:47 -0000 Subject: [GHC] #13003: improve documentation for typed TH and make it more discoverable In-Reply-To: <045.be56361ab1e3677f8b5beb473b90b5fb@haskell.org> References: <045.be56361ab1e3677f8b5beb473b90b5fb@haskell.org> Message-ID: <060.8a2943c58c0ea133bc16c519c3617110@haskell.org> #13003: improve documentation for typed TH and make it more discoverable -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Documentation | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by carter): I'm not sure if this really needs library list discussion. as for the docs, yeah, i'll see about a teeny patch that perhaps makes it a clear subsection? or something. not sure, but its definitely hidden there. Also its kinda an implementation detail/ quirk that they're under the same language flag too... it does make sense that theres some coercion functions between the underlying reps, but its quite odd that they're all under the same flag i think? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 30 01:10:24 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Dec 2016 01:10:24 -0000 Subject: [GHC] #12999: Investigate use of floating-point arithmetic in I/O Event-handler In-Reply-To: <042.d9e72583afa2ded1431f4a089ec3a9ba@haskell.org> References: <042.d9e72583afa2ded1431f4a089ec3a9ba@haskell.org> Message-ID: <057.b69ab9790b64106eabb3afd8879d07b2@haskell.org> #12999: Investigate use of floating-point arithmetic in I/O Event-handler -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by winter): Replying to [comment:2 davean]: > That is just a faster version of the wrong thing. Can you explain what is the problem with an IntPSQ? > This bug was filed because I was working on fixing it correctly. Nice! If there any possibility we can get a stripped TimerManager(like the IOManager) which use a PSQ per core? It will help under high contention situation s. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 30 01:30:38 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Dec 2016 01:30:38 -0000 Subject: [GHC] #12241: Surprising constructor accumulation In-Reply-To: <045.b094d056b768120afa6b9d14aa3617d0@haskell.org> References: <045.b094d056b768120afa6b9d14aa3617d0@haskell.org> Message-ID: <060.7f081832aa0b4b42d4c3a1d27c03cbdd@haskell.org> #12241: Surprising constructor accumulation -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 7.10.3 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #2607 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => closed * resolution: => duplicate * related: => #2607 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 30 01:33:21 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Dec 2016 01:33:21 -0000 Subject: [GHC] #2607: Inlining defeats selector thunk optimisation In-Reply-To: <047.c7531631c6a975d610c9a2ecacd7519d@haskell.org> References: <047.c7531631c6a975d610c9a2ecacd7519d@haskell.org> Message-ID: <062.0af1d7520e1dd955d93aed846d82d5d3@haskell.org> #2607: Inlining defeats selector thunk optimisation -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #12241 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * related: => #12241 Comment: #12241 provides another example of the selector thunk trick being defeated by the simplifier. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 30 03:02:02 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Dec 2016 03:02:02 -0000 Subject: [GHC] #13035: GHC enters a loop when partial type signatures and advanced type level code mix In-Reply-To: <043.73bcb566c7aa5daa0f1f227af5f74322@haskell.org> References: <043.73bcb566c7aa5daa0f1f227af5f74322@haskell.org> Message-ID: <058.68321d98f9207c9249282e31600f76f9@haskell.org> #13035: GHC enters a loop when partial type signatures and advanced type level code mix -------------------------------------+------------------------------------- Reporter: xcmw | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by xcmw): For some reason this similar code works fine. The only change I made was creating and using NutritionW. {{{ {-# LANGUAGE PolyKinds, DataKinds, TypeOperators, TypeFamilies, GADTs, PartialTypeSignatures, UndecidableInstances #-} newtype MyAttr a b = MyAttr { _unMyAttr :: MyFun (a b) } type MyRec a b = Rec (MyAttr a) b type family MyFun (a :: k1) :: k2 data GY (a :: k1) (b :: k2) (c :: k1 -> k3) (d :: k1) data GNone (a :: k1) type family GYTF a where GYTF (GY a b _ a) = b GYTF (GY _ _ c d) = MyFun (c d) type instance MyFun (GY a b c d) = GYTF (GY a b c d) type family GNoneTF (a :: k1) :: k2 where type instance MyFun (GNone a) = GNoneTF a type (a :: k1) =: (b :: k2) = a `GY` b type (a :: j1 -> j2) $ (b :: j1) = a b infixr 0 $ infixr 9 =: data FConst (a :: *) (b :: Fields) data FApply (a :: * -> * -> *) b c (d :: Fields) data FMap (a :: * -> *) b (d :: Fields) type instance MyFun (FConst a b) = a type instance MyFun (FApply b c d a) = b (MyFun (c a)) (MyFun (d a)) type instance MyFun (FMap b c a) = b (MyFun (c a)) data Fields = Name | Author | Image | Description | Ingredients | Instructions | CookTime | PrepTime | TotalTime | Yield | Nutrition | Tags | Url | Section | Items | Subsections | Calories | Carbohydrates | Cholesterol | Fat | Fiber | Protien | SaturatedFat | Sodium | Sugar | TransFat | UnsaturatedFat | ServingSize data Rec :: (u -> *) -> [u] -> * where RNil :: Rec f '[] (:&) :: !(f r) -> !(Rec f rs) -> Rec f (r ': rs) data family Sing (a :: k) data instance Sing (z_a6bn :: Fields) = z_a6bn ~ Name => SName | z_a6bn ~ Author => SAuthor | z_a6bn ~ Image => SImage | z_a6bn ~ Description => SDescription | z_a6bn ~ Ingredients => SIngredients | z_a6bn ~ Instructions => SInstructions | z_a6bn ~ CookTime => SCookTime | z_a6bn ~ PrepTime => SPrepTime | z_a6bn ~ TotalTime => STotalTime | z_a6bn ~ Yield => SYield | z_a6bn ~ Nutrition => SNutrition | z_a6bn ~ Tags => STags | z_a6bn ~ Url => SUrl | z_a6bn ~ Section => SSection | z_a6bn ~ Items => SItems | z_a6bn ~ Subsections => SSubsections | z_a6bn ~ Calories => SCalories | z_a6bn ~ Carbohydrates => SCarbohydrates | z_a6bn ~ Cholesterol => SCholesterol | z_a6bn ~ Fat => SFat | z_a6bn ~ Fiber => SFiber | z_a6bn ~ Protien => SProtien | z_a6bn ~ SaturatedFat => SSaturatedFat | z_a6bn ~ Sodium => SSodium | z_a6bn ~ Sugar => SSugar | z_a6bn ~ TransFat => STransFat | z_a6bn ~ UnsaturatedFat => SUnsaturatedFat | z_a6bn ~ ServingSize => SServingSize (=::) :: sing f -> MyFun (a f) -> MyAttr a f _ =:: x = MyAttr x type NutritionT = Calories =: Maybe Int $ Carbohydrates =: Maybe Int $ Cholesterol =: Maybe Int $ Fat =: Maybe Int $ Fiber =: Maybe Int $ Protien =: Maybe Int $ SaturatedFat =: Maybe Int $ Sodium =: Maybe Int $ Sugar =: Maybe Int $ TransFat =: Maybe Int $ UnsaturatedFat =: Maybe Int $ ServingSize =: String $ GNone data NutritionW (x :: Fields) type instance MyFun (NutritionW x) = MyFun (NutritionT x) type NutritionRec = MyRec NutritionW ['Calories, 'Carbohydrates, 'Cholesterol, 'Fat, 'Fiber, 'Protien, 'SaturatedFat, 'Sodium, 'Sugar, 'TransFat, 'UnsaturatedFat, 'ServingSize] type RecipeT = Name =: String $ Author =: String $ Image =: String $ Description =: String $ CookTime =: Maybe Int $ PrepTime =: Maybe Int $ TotalTime =: Maybe Int $ Yield =: String $ Nutrition =: NutritionRec $ Tags =: [String] $ Url =: String $ GNone type RecipeFormatter = FApply (->) (FConst [String]) (FMap IO RecipeT) g :: MyRec RecipeFormatter _ --'[ 'Author ] Uncomment to prevent loop g = SAuthor =:: (\a -> return "Hi") :& RNil main = putStrLn "Hi" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 30 04:44:51 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Dec 2016 04:44:51 -0000 Subject: [GHC] #12999: Investigate use of floating-point arithmetic in I/O Event-handler In-Reply-To: <042.d9e72583afa2ded1431f4a089ec3a9ba@haskell.org> References: <042.d9e72583afa2ded1431f4a089ec3a9ba@haskell.org> Message-ID: <057.b6dcb2bd154f84276c5e0e708c5b0353@haskell.org> #12999: Investigate use of floating-point arithmetic in I/O Event-handler -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by winter): * cc: winter (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 30 07:06:46 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Dec 2016 07:06:46 -0000 Subject: [GHC] #12999: Investigate use of floating-point arithmetic in I/O Event-handler In-Reply-To: <042.d9e72583afa2ded1431f4a089ec3a9ba@haskell.org> References: <042.d9e72583afa2ded1431f4a089ec3a9ba@haskell.org> Message-ID: <057.87e3b912852827521f1957ab39841793@haskell.org> #12999: Investigate use of floating-point arithmetic in I/O Event-handler -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by winter): Replying to [comment:2 davean]: I think i understand your comments now :) It seems structures in psqueues package doesn't provide a key function `atMost`, which prevent us from find expired timers. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 30 07:16:01 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Dec 2016 07:16:01 -0000 Subject: [GHC] #12767: Pattern synonyms for Cont, Writer, Reader, State, ... In-Reply-To: <051.2af0a5f02bf7b6e30ff673f49db00cb4@haskell.org> References: <051.2af0a5f02bf7b6e30ff673f49db00cb4@haskell.org> Message-ID: <066.9d14403e093a996de8c36e1659add43d@haskell.org> #12767: Pattern synonyms for Cont, Writer, Reader, State, ... -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12001 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): There wasn't much of a response but what little it got was positive, how should I proceed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 30 09:20:21 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Dec 2016 09:20:21 -0000 Subject: [GHC] #13043: GHC 7.10->8.0 regression: GHC code-generates duplicate _closures Message-ID: <042.7c615feebb0ec46d5ffec4f15f9937d0@haskell.org> #13043: GHC 7.10->8.0 regression: GHC code-generates duplicate _closures -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.2-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Giving GHC 8.0.2rc2 a closer look I stumbled over this one: This works fine in GHC 7.10.3, but fails to compile with GHC 8.0.2rc2: {{{ Resolving dependencies... In order, the following will be built (use -v for more details): - vivid-0.1.0.3 {vivid-0.1.0.3-inplace} (lib) (first run) Configuring component lib from vivid-0.1.0.3... Preprocessing library vivid-0.1.0.3... [ 1 of 10] Compiling Vivid.SynthDef.Types ( Vivid/SynthDef/Types.hs, /tmp/vivid-0.1.0.3/dist- newstyle/build/x86_64-linux/ghc-8.0.1.20161213/vivid-0.1.0.3/build/Vivid/SynthDef/Types.o ) [ 2 of 10] Compiling Vivid.SynthDef.CrazyTypes ( Vivid/SynthDef/CrazyTypes.hs, /tmp/vivid-0.1.0.3/dist- newstyle/build/x86_64-linux/ghc-8.0.1.20161213/vivid-0.1.0.3/build/Vivid/SynthDef/CrazyTypes.o ) [ 3 of 10] Compiling Vivid.OSC.Util ( Vivid/OSC/Util.hs, /tmp/vivid-0.1.0.3/dist- newstyle/build/x86_64-linux/ghc-8.0.1.20161213/vivid-0.1.0.3/build/Vivid/OSC/Util.o ) [ 4 of 10] Compiling Vivid.SynthDef.Literally ( Vivid/SynthDef/Literally.hs, /tmp/vivid-0.1.0.3/dist- newstyle/build/x86_64-linux/ghc-8.0.1.20161213/vivid-0.1.0.3/build/Vivid/SynthDef/Literally.o ) [ 5 of 10] Compiling Vivid.OSC ( Vivid/OSC.hs, /tmp/vivid-0.1.0.3 /dist- newstyle/build/x86_64-linux/ghc-8.0.1.20161213/vivid-0.1.0.3/build/Vivid/OSC.o ) [ 6 of 10] Compiling Vivid.SCServer ( Vivid/SCServer.hs, /tmp/vivid-0.1.0.3/dist- newstyle/build/x86_64-linux/ghc-8.0.1.20161213/vivid-0.1.0.3/build/Vivid/SCServer.o ) /tmp/ghc12095_0/ghc_27.s: Assembler messages: /tmp/ghc12095_0/ghc_27.s:5860:0: error: Error: symbol `vividzm0zi1zi0zi3zminplace_VividziSCServer_scServerState_closure' is already defined /tmp/ghc12095_0/ghc_27.s:10988:0: error: Error: symbol `vividzm0zi1zi0zi3zminplace_VividziSCServer_scServerState_closure' is already defined /tmp/ghc12095_0/ghc_27.s:11751:0: error: Error: symbol `vividzm0zi1zi0zi3zminplace_VividziSCServer_scServerState_closure' is already defined `gcc' failed in phase `Assembler'. (Exit code: 1) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 30 10:43:27 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Dec 2016 10:43:27 -0000 Subject: [GHC] #9221: (super!) linear slowdown of parallel builds on 40 core machine In-Reply-To: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> References: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> Message-ID: <060.fe7ce86abd36783e67b3ac9220364c4a@haskell.org> #9221: (super!) linear slowdown of parallel builds on 40 core machine -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #910, #8224 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sjakobi): * cc: sjakobi (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 30 13:09:05 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Dec 2016 13:09:05 -0000 Subject: [GHC] #13044: make it possible to apply GHC rewrite rules to class methods Message-ID: <045.b28d35c50b82843a8167a01ab643175e@haskell.org> #13044: make it possible to apply GHC rewrite rules to class methods -------------------------------------+------------------------------------- Reporter: George | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Make it possible to apply GHC rewrite rules to class methods. As Conal wrote in a discussion on glasgow-haskell-users, it is too bad that we can't use class laws as optimizations in the form of rewrite rules. In that same thread Simon PJ referenced https://ghc.haskell.org/trac/ghc/ticket/11688, esp comment:7 which gives links to similar examples. https://ghc.haskell.org/trac/ghc/ticket/10528 comment:13 gives more background. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 30 14:40:43 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Dec 2016 14:40:43 -0000 Subject: [GHC] #13045: LLVM code generation causes segfaults on FreeBSD Message-ID: <043.3e9aa2477ba70b06e3bd2c5b68a086fe@haskell.org> #13045: LLVM code generation causes segfaults on FreeBSD ---------------------------------------+--------------------------------- Reporter: emc2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 7.10.2 Keywords: | Operating System: FreeBSD Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ---------------------------------------+--------------------------------- Steps to reproduce: 1. Install lang/ghc from ports, select LLVM option 1. Install devel/hs-cabal-install from ports, select LLVM option on all Haskell packages 1. Attempt to run cabal update This was seemingly introduced in 7.10.* The FreeBSD ports based on 7.8.3 worked perfectly with LLVM. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 30 14:55:49 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Dec 2016 14:55:49 -0000 Subject: [GHC] #13045: LLVM code generation causes segfaults on FreeBSD In-Reply-To: <043.3e9aa2477ba70b06e3bd2c5b68a086fe@haskell.org> References: <043.3e9aa2477ba70b06e3bd2c5b68a086fe@haskell.org> Message-ID: <058.67692059548de70b1fd0a91560bcfc1a@haskell.org> #13045: LLVM code generation causes segfaults on FreeBSD ------------------------------------+-------------------------------------- Reporter: emc2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 7.10.2 Resolution: | Keywords: Operating System: FreeBSD | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ------------------------------------+-------------------------------------- Description changed by emc2: @@ -10,0 +10,3 @@ + + Cabal binary and core file can be found here: + http://www.metricspace.net/files/cabal_crash.tar.bz2 New description: Steps to reproduce: 1. Install lang/ghc from ports, select LLVM option 1. Install devel/hs-cabal-install from ports, select LLVM option on all Haskell packages 1. Attempt to run cabal update This was seemingly introduced in 7.10.* The FreeBSD ports based on 7.8.3 worked perfectly with LLVM. Cabal binary and core file can be found here: http://www.metricspace.net/files/cabal_crash.tar.bz2 -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 30 14:58:24 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Dec 2016 14:58:24 -0000 Subject: [GHC] #13045: LLVM code generation causes segfaults on FreeBSD In-Reply-To: <043.3e9aa2477ba70b06e3bd2c5b68a086fe@haskell.org> References: <043.3e9aa2477ba70b06e3bd2c5b68a086fe@haskell.org> Message-ID: <058.0907563eb8854bd7714826fe7ed4ec9d@haskell.org> #13045: LLVM code generation causes segfaults on FreeBSD ------------------------------------+-------------------------------------- Reporter: emc2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 7.10.2 Resolution: | Keywords: Operating System: FreeBSD | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ------------------------------------+-------------------------------------- Changes (by emc2): * failure: None/Unknown => Runtime crash -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 30 16:49:05 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Dec 2016 16:49:05 -0000 Subject: [GHC] #13038: implementation of Modus ponens and Modus tollens In-Reply-To: <044.ee87b0a017d5b08f838549b48bb4f0cf@haskell.org> References: <044.ee87b0a017d5b08f838549b48bb4f0cf@haskell.org> Message-ID: <059.2219083c8c4eedc2f9577f704bb71659@haskell.org> #13038: implementation of Modus ponens and Modus tollens -------------------------------------+------------------------------------- Reporter: vanto | Owner: Type: feature request | Status: infoneeded Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by vanto): Here is the code[[BR]] a is v(p) and b is v(q) and the implies function is separate and can be used independently of the other functions.[[BR]] {{{ implies::Bool->Bool->Bool implies a b = (||) (not a) b mod_ponens :: Bool -> Bool -> Bool mod_ponens a b = if a==True && implies a b == True then True else False mod_tollens :: Bool -> Bool -> Bool mod_tollens a b = if b==False && implies a b == True then True else False }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 30 18:26:57 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Dec 2016 18:26:57 -0000 Subject: [GHC] #13046: TH Names can't be used in patterns Message-ID: <051.6b918802431f3b3824cb72da4e1396b6@haskell.org> #13046: TH Names can't be used in patterns -------------------------------------+------------------------------------- Reporter: Artyom.Kazak | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Here's an example where I try to use a `Name` (with double ticks) as a pattern: {{{#!hs {-# LANGUAGE TemplateHaskell #-} foo :: Name -> () foo ''Int = () }}} It fails with this error: {{{#!text test.hs:4:5-9: Parse error in pattern: ''Int }}} Seems like a bug to me (if we can compare `Name`s, why can't we pattern- match on them?). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 30 22:07:54 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Dec 2016 22:07:54 -0000 Subject: [GHC] #7161: hSetNewlineMode and hSetEncoding can be performed on closed and semi-closed handles In-Reply-To: <045.7e6a94d263b25a206477fac55bd4f0ca@haskell.org> References: <045.7e6a94d263b25a206477fac55bd4f0ca@haskell.org> Message-ID: <060.2dd1450fa69841768c94104bdd95f4e1@haskell.org> #7161: hSetNewlineMode and hSetEncoding can be performed on closed and semi-closed handles -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.6.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by joeyhess): I reproduced this bug in the wild today. Here is my test case: import GHC.IO.Encoding import System.IO main = do e <- getFileSystemEncoding hClose stdin hSetEncoding stdin e ghc 8.0.1 on Linux. For me, the crash only occurs with LANG=C. With my usual locale of en_US.utf8 there is no crash. Perhaps this is why there was a problem reproducing it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 30 22:10:09 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Dec 2016 22:10:09 -0000 Subject: [GHC] #7161: hSetNewlineMode and hSetEncoding can be performed on closed and semi-closed handles In-Reply-To: <045.7e6a94d263b25a206477fac55bd4f0ca@haskell.org> References: <045.7e6a94d263b25a206477fac55bd4f0ca@haskell.org> Message-ID: <060.2733d9802f29f5702405fabd4b453da5@haskell.org> #7161: hSetNewlineMode and hSetEncoding can be performed on closed and semi-closed handles -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.6.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by joeyhess): And here is the segfault info: {{{ *** Error in `./foo': double free or corruption (top): 0x0000000000b7b620 *** ======= Backtrace: ========= /lib/x86_64-linux-gnu/libc.so.6(+0x70bcb)[0x7f042ba4bbcb] /lib/x86_64-linux-gnu/libc.so.6(+0x76fa6)[0x7f042ba51fa6] /lib/x86_64-linux-gnu/libc.so.6(+0x7779e)[0x7f042ba5279e] /lib/x86_64-linux-gnu/libc.so.6(+0x21226)[0x7f042b9fc226] /lib/x86_64-linux-gnu/libc.so.6(iconv_close+0xf)[0x7f042b9fbabf] ./foo[0x40ef80] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 30 23:16:21 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Dec 2016 23:16:21 -0000 Subject: [GHC] #12767: Pattern synonyms for Cont, Writer, Reader, State, ... In-Reply-To: <051.2af0a5f02bf7b6e30ff673f49db00cb4@haskell.org> References: <051.2af0a5f02bf7b6e30ff673f49db00cb4@haskell.org> Message-ID: <066.9818fea3afed512042a378483ee3b4e4@haskell.org> #12767: Pattern synonyms for Cont, Writer, Reader, State, ... -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12001 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): I for one am enthusiastic about the idea. You may want to concoct a patch and see if you can get Ross to merge it as a next step. As he is the maintainer of `transformers`, it is ultimately up to him to decide what to do here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Dec 30 23:18:04 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Dec 2016 23:18:04 -0000 Subject: [GHC] #12767: Pattern synonyms for Cont, Writer, Reader, State, ... In-Reply-To: <051.2af0a5f02bf7b6e30ff673f49db00cb4@haskell.org> References: <051.2af0a5f02bf7b6e30ff673f49db00cb4@haskell.org> Message-ID: <066.efb37d3ef9e3faee4055342a3b584c3c@haskell.org> #12767: Pattern synonyms for Cont, Writer, Reader, State, ... -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12001 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): FWIW- I'd be happy to merge a pull request to add similar pattern synonyms to on the `comonad` side. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 31 04:16:07 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 31 Dec 2016 04:16:07 -0000 Subject: [GHC] #12994: Module and export level signature thinning in Backpack In-Reply-To: <045.f43d28ea2478374c1ae4ae4760dece5e@haskell.org> References: <045.f43d28ea2478374c1ae4ae4760dece5e@haskell.org> Message-ID: <060.bb0173fd55041b491360aa53694b6d58@haskell.org> #12994: Module and export level signature thinning in Backpack -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by ezyang: @@ -17,2 +17,1 @@ - it does not have any modules, and itself depends only on fully - instantiated packages or signature packages. + it does not export any modules. @@ -29,2 +28,3 @@ - By default, all signatures in scope at a name get merged to a name. We add - a pragma for controlling what declarations from packages get merged in: + By default, all signatures in scope at a name get merged to a name. + However, by specifying the export list of a signature, we can control + which declarations from signature packages come into scope: @@ -33,2 +33,1 @@ - signature A where - {-# MERGE "sig-pkg" (T, S, foo, bar, baz) #-} + signature A (T, foo) where @@ -36,1 +35,0 @@ - qux :: T -> T @@ -39,2 +37,4 @@ - This line means, "merge in the declarations T, foo, bar, baz from the - signature in sig-pkg." Two things to note: + Notice that `foo` is not mentioned in the body of the signature A: in this + case, foo is expected to come from a signature from a signature package. + If the signature from the signature package also require bar, that + requirement is NOT included in A. @@ -42,1 +42,3 @@ - 1. If `foo :: S`, you're obligated to also declare `S` in the import list, + Two things to note: + + 1. If `foo :: S`, you're obligated to also declare `S` in the export list, @@ -44,1 +46,2 @@ - always explicit what is going to be required in the end. + always explicit what is going to be required in the end. GHC will give an + error if this is not true. @@ -46,13 +49,5 @@ - 2. Even if `T` is in the merge list, you still have to declare it locally - if you want to make use of it. These are not imports! - - (:TODO: There is no provision for disambiguating between two signatures - from the same package, but mix-linked differently. This seems like a - pretty rare case.) - - The semantics is that we proceed as we do now, but when merging, we apply - the explicit import list to reduce the set of entities we actually - typecheck and merge in (checking, however, to ensure that these are all - well-formed.) - - That's it, I think. + 2. If you depended upon a library that had requirements and exposed + modules, you can't thin declarations from the signature this way: they are + always exported, no matter if they're specified in the export list or not. + But we'll attach warnings to these if you actually try to use them. (Maybe + we really should filter them out of things that are brought into scope) New description: **The problem.** We want to write signature packages to allow us to reuse signatures, but Backpack in its current incarnation forces us to depend on ALL of the signatures from the signature package. This is troublesome if we only really needed a subset of the signatures from the package. What we'd like is a way to "thin" out the signatures, keeping only the ones we need. In the original design of Backpack, this was not allowed, because if a signature was requiring a function so that a module from that package could use it, you're not permitted to just drop that requirement (someone really needs it!) But signature packages: packages that consist of only signatures (no modules) do not have any such requirement. So let's allow module and export level signature thinning here. **Design.** First, during the course of mix-in linking we infer if a package is a signature package or not. A package is a signature package if it does not export any modules. A signature package is eligible for requirement thinning. A signature package can be thinned at the module level using the `signature-mixins` field, by saying `include-signatures: sig-pkg (A)` (we don't reuse `mixins` field to distinguish signature packages from regular indefinite packages); this means that we only are bringing the signature `A` into scope. If `A` imports another signature `B`, the user is obligated to also bring that signature into scope (if they do not, we will error, although this can only be done by GHC.) By default, all signatures in scope at a name get merged to a name. However, by specifying the export list of a signature, we can control which declarations from signature packages come into scope: {{{ signature A (T, foo) where data T }}} Notice that `foo` is not mentioned in the body of the signature A: in this case, foo is expected to come from a signature from a signature package. If the signature from the signature package also require bar, that requirement is NOT included in A. Two things to note: 1. If `foo :: S`, you're obligated to also declare `S` in the export list, even if you are not otherwise using it. The reason for this is to make it always explicit what is going to be required in the end. GHC will give an error if this is not true. 2. If you depended upon a library that had requirements and exposed modules, you can't thin declarations from the signature this way: they are always exported, no matter if they're specified in the export list or not. But we'll attach warnings to these if you actually try to use them. (Maybe we really should filter them out of things that are brought into scope) -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 31 08:12:22 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 31 Dec 2016 08:12:22 -0000 Subject: [GHC] #605: Optimisation: strict enumerations In-Reply-To: <047.930f12dd9816334e7bac59b319734f38@haskell.org> References: <047.930f12dd9816334e7bac59b319734f38@haskell.org> Message-ID: <062.93e50b3ecddbde1c3c13f3b4976025a5@haskell.org> #605: Optimisation: strict enumerations -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: None Resolution: None | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: N/A Blocked By: | Blocking: Related Tickets: #6135 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): FWIW we can currently store strict enumerations as `Int#`s with Phab:D2424. Phab:D2436 allows returning `Int#` when returned enumeration is used strictly. Another patch is needed for extending demand analysis and passing `Int#` for strict enumerations. I actually have most of the code ready, but it needs rebasing it on current HEAD. IIRC some parts of the demand analysis were missing, but I can't remember exactly which parts. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 31 08:18:05 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 31 Dec 2016 08:18:05 -0000 Subject: [GHC] #5075: CPR optimisation for sum types if only one constructor is used In-Reply-To: <053.3ffd551e0053819cbbe3bb221ae15b3f@haskell.org> References: <053.3ffd551e0053819cbbe3bb221ae15b3f@haskell.org> Message-ID: <068.c7c1824bda145caa9515c5bd4779da25@haskell.org> #5075: CPR optimisation for sum types if only one constructor is used -------------------------------------+------------------------------------- Reporter: batterseapower | Owner: simonpj Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.0.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: | -------------------------------------+------------------------------------- Comment (by osa1): Related: Phab:D2436 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 31 08:33:51 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 31 Dec 2016 08:33:51 -0000 Subject: [GHC] #7647: UNPACK polymorphic fields In-Reply-To: <045.8091f80cf766b683cf12520609e77aee@haskell.org> References: <045.8091f80cf766b683cf12520609e77aee@haskell.org> Message-ID: <060.60e2e6057144101cb3461d3f4d1a1ebf@haskell.org> #7647: UNPACK polymorphic fields -------------------------------------+------------------------------------- Reporter: liyang | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #3990 #9655 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * cc: osa1 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 31 11:13:58 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 31 Dec 2016 11:13:58 -0000 Subject: [GHC] #13044: make it possible to apply GHC rewrite rules to class methods In-Reply-To: <045.b28d35c50b82843a8167a01ab643175e@haskell.org> References: <045.b28d35c50b82843a8167a01ab643175e@haskell.org> Message-ID: <060.d4595c557eb749b1c414ff3d85ee2d42@haskell.org> #13044: make it possible to apply GHC rewrite rules to class methods -------------------------------------+------------------------------------- Reporter: George | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * cc: nomeata (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 31 17:06:58 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 31 Dec 2016 17:06:58 -0000 Subject: [GHC] #13047: Can create bindings of kind Constraint without ConstraintKind, only TypeFamilies Message-ID: <050.cebb66ee7ce4ffcdcc0e08483f43fed8@haskell.org> #13047: Can create bindings of kind Constraint without ConstraintKind, only TypeFamilies -------------------------------------+------------------------------------- Reporter: pggiarrusso | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This code compiles with GHC 8.0.1 (in either variant, with or without the definition of ApplyCtx Int in Foo Int. I think it shouldn't according to the docs in http://ghc.readthedocs.io/en/master/glasgow_exts.html?highlight=constraintKinds #the-constraint-kind. If this is intended, I guess documenting it is acceptable. {{{ {-# LANGUAGE TypeFamilies #-} module Foo where import GHC.Exts (Constraint) class Foo a where type ApplyCtx a :: Constraint type ApplyCtx a = () instance Foo Int where type ApplyCtx Int = Show Int -- Commenting this out makes no difference. f :: ApplyCtx Int => Int f = 0 }}} Googling found https://mail.haskell.org/pipermail/glasgow-haskell- users/2016-February/026151.html, but seems a different issue (and a non- bug). Also found https://ghc.haskell.org/trac/ghc/ticket/11715, which might be relevant (or not). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 31 17:13:39 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 31 Dec 2016 17:13:39 -0000 Subject: [GHC] #13048: Splitter is O(n^2) Message-ID: <047.258e7fedc937d14bf117b1fb536967dd@haskell.org> #13048: Splitter is O(n^2) -------------------------------------+------------------------------------- Reporter: dobenour | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: split-objs | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The splitter is O(local constants * total size of code), which is O(n^2^). This can be dealt with by not looping over each local constant, and instead scraping the local constants used from the assembler code and then looking them up in the hashtable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 31 17:15:04 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 31 Dec 2016 17:15:04 -0000 Subject: [GHC] #8629: Option 'split-objs' being ignored when trying to reduce object code size in iOS cross-compilation In-Reply-To: <051.7f175708aaf58854c5eeaa60c17f6275@haskell.org> References: <051.7f175708aaf58854c5eeaa60c17f6275@haskell.org> Message-ID: <066.6d560a25239a605449037520e629b731@haskell.org> #8629: Option 'split-objs' being ignored when trying to reduce object code size in iOS cross-compilation ---------------------------------+---------------------------------------- Reporter: f1rstmistake | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: ios Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 8300 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by dobenour): I think that the problem is that `-dead_strip` isn't doing its job. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 31 17:25:50 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 31 Dec 2016 17:25:50 -0000 Subject: [GHC] #13049: Make `-dead_strip` the default on Darwin Message-ID: <047.db5905269068938cc53fd620b92bef9f@haskell.org> #13049: Make `-dead_strip` the default on Darwin -------------------------------------+------------------------------------- Reporter: dobenour | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- We should make `-dead_strip` the default on Darwin. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 31 17:54:59 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 31 Dec 2016 17:54:59 -0000 Subject: [GHC] #13038: implementation of Modus ponens and Modus tollens In-Reply-To: <044.ee87b0a017d5b08f838549b48bb4f0cf@haskell.org> References: <044.ee87b0a017d5b08f838549b48bb4f0cf@haskell.org> Message-ID: <059.410ec5873584aa8d777b4abd584c723b@haskell.org> #13038: implementation of Modus ponens and Modus tollens -------------------------------------+------------------------------------- Reporter: vanto | Owner: Type: feature request | Status: infoneeded Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Thanks. You'll notice that if you examine the truth tables for `mod_ponens` and `mod_tollens`, you'll notice that: {{{#!hs mod_ponens = (&&) }}} and {{{#!hs mod_tollens x y = not (x || y) }}} I don't think either of these things break the Fairbairn threshold. The `implies` function [https://mail.haskell.org/pipermail/libraries/2016-January/026559.html Haskell has been proposed before on the libraries mailing list]. The consensus seemed to be that folks were generally supportive of the idea of introducing an `implies` function to `Data.Bool` (though the idea did have some detractors). You might wish to start a new libraries mailing list thread to see if that's still the case. If there's clear support, then feel free to submit a patch that adds `implies` to `base` via Phabricator. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 31 18:19:23 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 31 Dec 2016 18:19:23 -0000 Subject: [GHC] #13044: make it possible to apply GHC rewrite rules to class methods In-Reply-To: <045.b28d35c50b82843a8167a01ab643175e@haskell.org> References: <045.b28d35c50b82843a8167a01ab643175e@haskell.org> Message-ID: <060.00ad15e464b7ece3fd6bf89626c7504f@haskell.org> #13044: make it possible to apply GHC rewrite rules to class methods -------------------------------------+------------------------------------- Reporter: George | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by snowleopard): * cc: snowleopard (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 31 20:42:10 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 31 Dec 2016 20:42:10 -0000 Subject: [GHC] #12767: Pattern synonyms for Cont, Writer, Reader, State, ... In-Reply-To: <051.2af0a5f02bf7b6e30ff673f49db00cb4@haskell.org> References: <051.2af0a5f02bf7b6e30ff673f49db00cb4@haskell.org> Message-ID: <066.5379c36f52d089bbd3c085b0752e647e@haskell.org> #12767: Pattern synonyms for Cont, Writer, Reader, State, ... -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12001 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I too would like to see this! Iceland_jack, do you mind opening the pull request for `transformers`? The `transformers` repo is located [http://hub.darcs.net/ross/transformers/issues here]. It uses darcs, which can be a bit tricky to navigate if you haven't used it before. If you have any difficulties, feel free to ping me for help. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 31 21:15:30 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 31 Dec 2016 21:15:30 -0000 Subject: [GHC] #13050: Holes don't work infix Message-ID: <051.70c7d13e7c9b3f46f47723dc2c858f74@haskell.org> #13050: Holes don't work infix -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- As pointed out in this [https://twitter.com/deech/status/815294260115369985 tweet], holes don't work infix {{{ #Haskell holes don't work with infixed functions, eg. _ 1 1 (Hole found: Integer -> Integer -> ...) 1 `_` 1 (parse error) 1 `_x` 1 (same) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 31 21:40:09 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 31 Dec 2016 21:40:09 -0000 Subject: [GHC] #13043: GHC 7.10->8.0 regression: GHC code-generates duplicate _closures In-Reply-To: <042.7c615feebb0ec46d5ffec4f15f9937d0@haskell.org> References: <042.7c615feebb0ec46d5ffec4f15f9937d0@haskell.org> Message-ID: <057.b2952c0fb25dc5b0535429252c9ce294@haskell.org> #13043: GHC 7.10->8.0 regression: GHC code-generates duplicate _closures -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.2-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Here's a minimized version with no dependencies: {{{#!hs {-# LANGUAGE BangPatterns #-} module Bug (foo, bar) where import Data.IORef (IORef, newIORef, readIORef, writeIORef) import System.IO.Unsafe (unsafePerformIO) {-# NOINLINE scServerState #-} scServerState :: SCServerState scServerState = unsafePerformIO (return undefined) data SCServerState = SCServerState { scServer_socket :: IORef (Maybe Int) } foo :: IO Int foo = do let !_ = scServerState readIORef (scServer_socket scServerState) >>= \xs -> case xs of Nothing -> do s <- undefined writeIORef (scServer_socket scServerState) (Just s) return s Just s -> return s bar :: IO () bar = do let !_ = scServerState return () }}} You can get this error message with GHC 8.0.1, 8.0.2, or HEAD: {{{ $ /opt/ghc/8.0.1/bin/ghc -fforce-recomp -O1 Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) /tmp/ghc654_0/ghc_2.s: Assembler messages: /tmp/ghc654_0/ghc_2.s:562:0: error: Error: symbol `Bug_scServerState_closure' is already defined `gcc' failed in phase `Assembler'. (Exit code: 1) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 31 21:48:52 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 31 Dec 2016 21:48:52 -0000 Subject: [GHC] #13043: GHC 7.10->8.0 regression: GHC code-generates duplicate _closures In-Reply-To: <042.7c615feebb0ec46d5ffec4f15f9937d0@haskell.org> References: <042.7c615feebb0ec46d5ffec4f15f9937d0@haskell.org> Message-ID: <057.1b1ac8061e1d6f7a7066878bfc620bd7@haskell.org> #13043: GHC 7.10->8.0 regression: GHC code-generates duplicate _closures -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.2-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): I think this is a duplicate of an existing ticket, the `let !_ = ...` "pattern" looks familiar. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Dec 31 23:33:32 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 31 Dec 2016 23:33:32 -0000 Subject: [GHC] #13043: GHC 7.10->8.0 regression: GHC code-generates duplicate _closures In-Reply-To: <042.7c615feebb0ec46d5ffec4f15f9937d0@haskell.org> References: <042.7c615feebb0ec46d5ffec4f15f9937d0@haskell.org> Message-ID: <057.4f0947ae9f7a1cfd9b0687fac754efc4@haskell.org> #13043: GHC 7.10->8.0 regression: GHC code-generates duplicate _closures -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.2-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: simonpj (added) Comment: Simon's commit 649cb346a38684df2e932987065817c5cafc2d90 is responsible for this regression. Reid, do you know which ticket this is a dupe of? If so, I'll close this in favor of that one. -- Ticket URL: GHC The Glasgow Haskell Compiler